Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

Opis wymagań formalnych, technicznych i funkcjonalnych Elektronicznego Systemu Obiegu Dokumentów i Archiwizacji (ESODIA)

W ramach realizacji przedmiotu zamówienia Wykonawca musi dostarczyć Elektroniczny System Obiegu Dokumentów i Archiwizacji (ESODIA) spełniający co najmniej wymagania formalne, techniczne i funkcjonalne opisane w niniejszym załączniku i w Załączniku nr 3 SIWZ.

1. Dostawa Elektronicznego Systemu Obiegu Dokumentów i Archiwizacji obejmuje:1.1. Dostarczenie i udzielnie bezterminowych licencji na cały Elektroniczny System

Obiegu Dokumentów i Archiwizacji oraz, jeżeli takowe będą konieczne, licencje na inne komponenty programowe wykorzystane przez Wykonawcę w celu zapewnienia prawidłowego działania oferowanego Systemu (zgodnego z wymaganiami określonymi przez Zamawiającego w SIWZ). Licencje muszą być licencjami bezterminowymi. Powinny zapewnić legalne korzystanie z systemu na co najmniej 250 (dwustu pięćdziesięciu) stacjach klienckich i przez nieograniczoną liczbę użytkowników.

1.2. Dostarczenie Zamawiającemu dokumentacji przygotowanej zgodnie z ogólnie akceptowalnymi standardami w dziedzinie dokumentowania.

1.2.1. Dokumentacja musi składać się z:a) dokumentacji administratora, zawierającej co najmniej:

opis funkcjonalny Systemu (w zwarty sposób opisane przeznaczenie i główne możliwości systemu),

opis wymagań sprzętowych i programowych, opis instalacji (procedury instalacji i dostrojenia Systemu do

środowiska, w którym ma pracować), opis możliwości konfiguracji wszystkich elementów systemu, opis zarządzania bezpieczeństwem, opis zarządzania użytkownikami, opis funkcji specjalnych (administracyjnych), opis szczegółowy wszystkich funkcji Systemu, opis i specyfikację interfejsów, opis i specyfikację (zasady) tworzenia dodatkowych funkcjonalności

w Systemie (dot. rozbudowy Systemu), Opis szczegółowych warunków implementacji nowych

funkcjonalności w Systemie (dot. rozbudowy Systemu), b) dokumentacji użytkownika (podręcznik użytkownika) zawierającej co

najmniej: opis funkcjonalny Systemu (w zwarty sposób opisane przeznaczenie

i główne możliwości systemu), sposoby rozpoczynania i kończenia pracy z Systemem, opis dostępnych funkcji z uwzględnieniem ról użytkowników, metody obsługi błędów,

1.2.2. Zamawiający wymaga, aby dokumentacja charakteryzowała się wysoką jakością tzn. posiadała nast. cechy:

Czytelna i zrozumiała struktura zarówno poszczególnych dokumentów jak i całej dokumentacji z podziałem na rozdziały, podrozdziały i sekcje,

Jednolita i spójna struktura, forma i sposób prezentacji treści poszczególnych dokumentów, fragmentów tego samego dokumentu oraz całej dokumentacji.

Kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego

Strona 1 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

zagadnienia. Oznacza to w szczególności jednoznaczne i wyczerpujące przedstawienie wszystkich zagadnień w odniesieniu do Systemu.

Spójność dokumentu, rozumiana jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie - brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu.

1.2.3. Wykonawca dostarczy każdą z wymienionych dokumentacji w języku polskim w sześciu wydrukowanych egzemplarzach oraz w wersji elektronicznej w formacie DOC (lub DOCX) oraz PDF.

1.2.4. Zamawiający wymaga aby Wykonawca wszelkie zmiany dokonane w Systemie w czasie trwania gwarancji nanosił w dokumentacji i w okresach co najwyżej 30-dniowych przekazywał uaktualnioną dokumentację Zamawiającemu w sześciu wydrukowanych egzemplarzach oraz w wersji elektronicznej w formacie DOC oraz PDF.

1.3. Dostarczenie Zamawiającemu nośników instalacyjnych (CD lub DVD) w ilości 3 kpl. zawierających uporządkowany zbiór wszystkich komponentów systemu ESODIA, pozwalający na zainstalowanie kompletnego Systemu w wersji takiej jak wersja dostarczona Zamawiającemu .

1.3.1. W przypadku zmian w zbiorach instalacyjnych komponentów Systemu, Zamawiający wymaga od Wykonawcy dostarczania w czasie trwania gwarancji jakości i rękojmi w okresach co najwyżej 3-miesięcznych aktualnych nośników instalacyjnych w ilościach 3 kpl.

1.4. Uruchomienie Systemu w zakresie określonym w załączniku nr 4 SIWZ.

2. Udzielenie 12 miesięcznej gwarancji (liczonej od dnia podpisania protokołu odbioru końcowego prac oraz udzielnie 3 miesięcznej rękojmi po upływie okresu gwarancji jakości) obejmującej realizację usług aktualizacji (Opieka Autorska) i serwisu, tj:

a) Dostarczanie nowych wersji oraz instalację/aktualizację ESODIA. Wykonawca gwarantuje rozwój oferowanego Systemu zgodnie ze zmieniającymi się przepisami obowiązującego porządku prawnego w Unii Europejskiej, w tym: rozporządzeniami, ustawami, obowiązującymi wykładniami prawnymi oraz wskazówkami jednostek nadrzędnych (np. Ministerstwo Zdrowia, Organ Założycielski, Narodowy Fundusz Zdrowia, itp.),

b) Przystosowanie Systemu do warunków organizacyjnych Zamawiającego - 160 roboczodni. Pod pojęciem jeden roboczodzień Zamawiający rozumie jeden 6-cio-godzinny dzień pracy jednej osoby realizującej usługi z ramienia Wykonawcy z wyłączeniem czasu dojazdów do lokalizacji Zamawiającego.

c) Szkolenia użytkowników i administratorów w zakresie korzystania z systemu zgodnie z ich rolami i zakresem obowiązków - 20 dni szkoleniowych rozumianych jako roboczodni określone w pkt. j.w..

d) Przyjmowanie zgłoszeń błędów i awarii Systemu, żądań modyfikacji i propozycji modyfikacji Systemu. W przypadku zgłoszenia przez Zamawiającego błędu w funkcjonowaniu Systemu (tzn. błędu powtarzalnego, pojawiającego się za każdym razem w tym samym miejscu działania programu i prowadzącego w każdym przypadku do otrzymywania błędnych wyników działania oprogramowania) lub żądania modyfikacji – maksymalny czas dokonania modyfikacji Systemu wynosi:

2 dni robocze od chwili wpłynięcia zgłoszenia - w przypadku tzw. „poważnego problemu” (tzn. problemu, który w istotny sposób zakłóca lub uniemożliwia prawidłową pracę Systemu),

7 dni roboczych od chwili wpłynięcia zgłoszenia - w przypadku „mniej poważnego problemu”.

Strona 2 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

W wyjątkowych przypadkach czas dokonania modyfikacji oprogramowania będzie uzgodniony pomiędzy Wykonawcą i Zamawiającym. Koszt usługi związanej z instalacją poprawionej wersji Systemu ponosi Wykonawca.

2.1. Zasady ogólne serwisu:a) Usługi będą świadczone w dni robocze w godzinach od 8.00 do

16:00.b) Przyjmowanie zgłoszeń przez Wykonawcę (telefon, faks, e-mail)

będzie realizowane w dni robocze w godzinach 8:00 – 16:00 pod numerem telefonu, faksu i adresem e-mail wskazanymi przez Wykonawcę w umowie (Załącznik nr 6 SIWZ).

c) Przystąpienie do usuwania problemów po zgłoszeniu serwisowym: W ciągu maksymalnie 6-ciu godzin - w przypadku usterki

uniemożliwiającej pracę całego Systemu lub jego kluczowej funkcjonalności – czas jest liczony od momentu zgłoszenia usterki w odniesieniu do czasu roboczego ( dni robocze, godz. od 08:00 do 16:00),

W ciągu maksymalnie 2 dni roboczych - w przypadku pozostałych usterek.

3. W poniższej tabeli ujęte są wymagania, które muszą być spełnione przez dostarczany w ramach niniejszego zamówienia System. Oferowany System musi spełniać wszystkie wymagania opisane w niniejszym załączniku.

Strona 3 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

Lp. Wymagania 1. Architektura Systemu1.1 Architektura systemu musi być oparta o Windows SharePoint Services, Microsoft Office SharePoint Server 2007 lub inną równoważną platformę portalową

(serwer usług) zintegrowaną na poziomie co najmniej: użytkowników (profile), zabezpieczeń (uprawnień), i zasobów ze środowiskiem Active Directory (Windows 2003 Server) funkcjonującym u Zamawiającego i posiadającą co najmniej następujące cechy:

1) Pozwala na organizację informacji w biblioteki dokumentów i listy (mogące przechowywać co najmniej: terminy kalendarza, zadania, kontakty), umożliwiając ich wymianę w portalu lub poprzez MS Outlook 2007. Umożliwia tworzenie zestawów dokumentów o wspólnym zbiorze atrybutów. Udostępnia widoki typu drzewo oraz umożliwia przydzielanie metadanych do dokumentów i folderów.

2) Dysponuje wbudowanym mechanizmem wyewidencjonowania, zatwierdzania i wersjonowania treści ułatwiającym pracę nad jednym dokumentem zabezpieczając wyłączny dostęp do edycji dokumentu oraz uniemożliwiając publikację bez uprzedniej akceptacji, a w razie potrzeby pozwala na porównanie wersji dokumentów z możliwością przywrócenia wersji archiwalnej. Pozwala na numerowanie i śledzenie wersji głównych i pomocniczych. Umożliwia obsługę bibliotek dokumentów w trybie offline w programie MS Office Outlook 2007.

3) Umożliwia tworzenie stron html, które mogą zawierać treści z bibliotek dokumentów i list; udostępnia strukturę witryn typu blog i wiki.

4) Pozwala zapisywać utworzone w portalu witryny jako szablony wykorzystywane do tworzenia nowych witryn.

5) Pozwala na otwieranie i zapisywanie dokumentów bezpośrednio do portalu z programów pakietu MS Office 2007 (co najmniej: Word, Excel, PowerPoint) zainstalowanych na stacjach klienckich Zamawiającego.

6) Umożliwia pełnotekstowe wyszukiwanie w treści dokumentów co najmniej typu DOC, XLS, PPT oraz listach znajdujących się w bibliotekach, witrynie czy grupie witryn. Pozwala udostępnić opcję wyszukiwania na każdej stronie portalu. Umożliwia kojarzenie alertów mailowych oraz mechanizmu RSS z wynikami wyszukiwania w celu informowania użytkownika o pojawieniu się treści spełniającej zadane kryteria.

7) Jest zgodna z silnikiem Windows Workflow Foundation i wykorzystuje go do obsługi przepływów pracy w osadzonych na niej (platformie portalowej) witrynach.

8) Umożliwia wykorzystanie SQL Server Reporting Services do wyświetlania raportów w osadzonych na niej (platformie portalowej) witrynach.

9) W zakresie współdziałania i integracji z innymi usługami i aplikacjami:a) wspiera język XML,b) wspiera protokół SOAP,

Strona 4 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

c) posiada otwarty interfejs API,1.2 System jako bazę danych musi wykorzystywać co najmniej: Oracle Database 10g (lub nowszy) lub MS SQL 2008 będące w posiadaniu Zamawiającego.

Sposób organizacji wykorzystywanej bazy oraz jej zarządzania powinien spełniać wymóg Generalnego Inspektora Ochrony Danych Osobowych. Wymagania dotyczące struktur baz danych osobowych oraz funkcjonalności zarządzających nimi aplikacji (w świetle ustawy o ochronie danych osobowych z dnia 29 sierpnia 1997 r. ( Dz. U. z 2002 r. Nr 101, poz. 926, z pózn. zm).

2. Wymagania podstawowe:2.1 System ESODIA musi spełniać wymogi formalno- prawne określone w Załączniku nr 3 SIWZ2.2 ESODIA musi uwzględniać wzorce postępowania obowiązujące u Zamawiającego w ramach uregulowań określonych w procesach związanych

z funkcjonowaniem Systemu Zarządzania Jakością. Zamawiający dopuszcza zmiany w istniejących uregulowaniach organizacyjnych i procesach realizowanych w komórkach organizacyjnych Zamawiającego o ile uzna je za korzystniejsze od obecnych.

2.3 Wszystkie elementy ESODIA muszą posiadać interfejs w języku polskim. W języku polskim muszą być wyświetlane wszystkie komunikaty przekazywane przez ESODIA, włącznie z komunikatami o błędach.

2.4 Konstrukcja Systemu musi zapewniać realizację wymagań funkcjonalnych dla oprogramowania przetwarzającego dane osobowe wynikające z Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych(Dz. U. 2004 nr 100 poz. 1024)

2.5 System musi umożliwiać odwzorowanie zmian organizacyjnych jednostki, bez utraty dotychczas zgromadzonych danych, oraz zapewniać możliwość przypisania uprawnień do tych danych innym użytkownikom systemu. Zmiany, które powinien uwzględniać system to co najmniej:

a) zmiany stanowiska pracy,b) rozszerzenie zakresu wykonywanych obowiązków,c) rozszerzenie zakresu działań komórek organizacyjnych w jednostce.d) utworzenie nowej komórki organizacyjnej

2.6 System musi być nowoczesny i zgodny ze stosowanymi na dzień zawarcia umowy aktami i rozporządzeniami w zakresie wymiany informacji a w szczególności z Rozporządzeniem Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz. U. 2005 nr 212 poz. 1766).

2.7 System musi umożliwiać generowanie raportu danych osobowych oraz prowadzenie ewidencji udostępnianych danych osobowych zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych(Dz. U. 2004 nr 100 poz. 1024).

2.8 ESODIA musi umożliwiać tworzenie niezależnych, indywidualnych witryn np. witryny przyporządkowane zespołowi lub komórce organizacyjnej, konstruowane w różnych celach np. w celu zapewnienie współpracy podczas realizacji danego zadania, czy projektu.

Strona 5 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

2.9 System po stronie użytkownika musi wykorzystywać standard aplikacyjny przyjęty u Zamawiającego tzn. system Windows XP oraz Vista Business zainstalowany na stacjach roboczych wraz z pakietem biurowym MS Office 2003/2007 z wchodzącymi w jego skład aplikacjami: MS Word, MS Excel, MS Outlook, MS PowerPoint.

2.10 System musi zapewnić jednolity interfejs dla obsługi poczty elektronicznej (tj. skrzynki pocztowej, kalendarza, książki adresowej), jak również aplikacji pracy grupowej osadzonych na wspólnej platformie systemowej. Musi posiadać spójny wygląd oraz jednolitą metodykę korzystania z interfejsu użytkownika w pełnym zakresie funkcjonalnym systemu.

2.11 System musi zapewnić możliwość rozbudowy i integrację z kolejnymi serwerami usług, przy zachowaniu wydajnej synchronizacji danych pomiędzy poszczególnymi serwerami (np. serwer pocztowy itp.).

2.12 Autoryzacja użytkowników (intranetowych) musi być zintegrowana z usługą katalogową Active Directory na której opiera się środowisko informatyczne Zamawiającego– użytkownik raz zalogowany z poziomu systemu operacyjnego stacji roboczej musi być automatycznie rozpoznawany we wszystkich modułach oferowanego rozwiązania bez potrzeby oddzielnego monitowania go o ponowne uwierzytelnienie się. Autoryzacja w Systemie z zewnętrznych lokalizacji musi się odbywać co najmniej za pomocą poświadczeń z bazy danych.

2.13 Dostęp do aplikacji musi odbywać się ze stacji klienckiej przy użyciu przeglądarki internetowej. Zamawiający nie dopuszcza konieczności instalacji dodatkowego oprogramowania w celu zapewnienia dostępu do systemu.

2.14 Interfejs aplikacji musi być zgodny ze standardem minimum XHTML 1.0 Transitional, a na potrzeby prezentacji treści musi wykorzystywać arkusze stylów CSS, tak by korzystanie z niego było możliwe za pomocą przeglądarek WWW obsługujących te standardy.

2.15 System musi cechować prostota i intuicyjność obsługi, pozwalające na pracę w systemie osobom nie posiadającym umiejętności technicznych oraz wykorzystywać mechanizmy znane użytkownikom pakietu biurowego MS Office – jako standardu aplikacji biurowych Zamawiającego.

2.16 Praca z dokumentami typu co najmniej PPT, XLS, DOC przechowywanymi w repozytoriach portalu musi odbywać się bezpośrednio z aplikacji pakietu biurowego (co najmniej: otwieranie/zapisywanie dokumentów, podgląd wersji, mechanizmy ewidencjonowania i wyewidencjonowania dokumentów, edycja metryki dokumentu).

2.17 System musi zapewnić możliwość zdefiniowania przynajmniej dwóch poziomów uprawnień edytorów (edytor i redaktor), przy czym treści publikowane przez edytorów muszą uzyskać pozytywną akceptację redaktora przed udostępnieniem jej wszystkim użytkownikom intranetu.

2.18 ESODIA musi umożliwiać zarządzanie kontami użytkowników z poziomu użytkownika uprzywilejowanego – Administratora Systemu polegające na:a) dodawaniu nowych kont,b) edycji kont,c) blokowaniu kont,d) uzupełnianiu danych osobowych danego użytkownika,e) definiowaniu ról użytkownika.

2.19 Przypisywanie użytkowników do ról musi odbywać się w oparciu o ich konta lub grupy w usłudze katalogowej Active Directory, na której oparte jest środowisko informatyczne Zamawiającego.

Strona 6 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

2.20 1) Systemu musi integrować się z MS Outlook 2007 co najmniej na poziomie:a) terminarzy, b) dokumentów, c) kontaktów..

2) System integrując się z MS Outlook musi udostępnić co najmniej następujące funkcjonalności: a) automatyczną synchronizację z dokonanymi zmianami w Systemie ESODIA przy wywołaniu polecenia Wyślij/Odbierz,b) udostępnianie w witrynach Systemu wiadomości, kontaktów, zadań i list dyskusyjnych,c) jednakowy sposób śledzenia zadań Systemu i programu Outlook, każde zadanie programu systemu ESODIA przypisane do użytkownika musi

zostać automatycznie wyświetlone w programach pakietu MS Office na pasku zadań do wykonania oraz na dziennej liście zadań w kalendarzu.2.21 System musi automatycznie dostosowywać sposób wyświetlania treści do rozdzielczości ekranu stacji klienckiej2.22 System musi umożliwiać prowadzenie co najmniej następujących ewidencji:

a) struktury organizacyjnej Szpitala i stanowisk pracy,b) pracowników , c) Jednolitego Rzeczowego Wykazu Akt (JRWA),d) spraw, dokumentów archiwalnych,e) ścieżek przetwarzania spraw,f) rejestrów obiegu dokumentów papierowych.

2.23 System musi zapewnić możliwość przydzielenia praw dostępu dowolnej grupie użytkowników do konkretnej grupy dokumentów, co najmniej:a) dokumenty przypisane grupie,b) dokumenty przypisane zespołowi projektowemu,c) dokumenty dotyczące ogłoszeń oraz informacji w jednostce.

2.24 System musi obsługiwać elektroniczny podpis kwalifikowany oraz niekwalifikowany, musi umożliwić jego użycie oraz automatyczną weryfikacje.2.25 System musi zapewnić możliwość dostosowania wyświetlanych elementów do indywidualnych (definiowanych) preferencji użytkowników.2.26 System musi zapewnić możliwość modyfikowania szablonu metryczki dokumentów - dodawanie nowych metadanych z poziomu administratora i

automatyczne uwzględnianie tak dodanych dodatkowych pól w funkcjach wyszukujących dokumenty.2.27 System musi umożliwić import informacji z bazy danych GUS TERYT (Krajowy Rejestr Urzędowy Podziału Terytorialnego Kraju). System musi umożliwić co

najmniej:a) stosowanie słownika TERYT - możliwość wyboru korzystania ze słownika lub nie,b) przy stosowaniu słownika TERYT - możliwość wprowadzania danych, których nie ma w słowniku.

2.27 System musi umożliwiać skanowanie dokumentów papierowych i zapisywanie ich wersji elektronicznej w repozytorium systemu.

3. Archiwum3.1 System musi zapewniać funkcjonalność pozwalającą na przechowywanie dokumentów podpisanych kwalifikowanym podpisem cyfrowym zgodnie z

Strona 7 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

obowiązującymi normami prawnymi.3.2 System musi zapewnić możliwość zarządzania co najmniej nast. słownikami:

a) kategorie akt,b) JRWA,c) rejestry dokumentów

3.3 System musi zapewnić możliwość ewidencji dokumentów archiwalnych, pozwalającej na zapisywanie informacji o lokalizacji fizycznego miejsca składowania papierowych wersji materiałów archiwalnych.

3.4 System musi umożliwić stworzenie pełnej struktury archiwum zakładowego w formie elektronicznej. System musi umożliwić prowadzenie archiwum zakładowego zgodnie z Rozporządzeniem MSWIA w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz. U. 2006 nr 206 poz. 1518), a w szczególności powinien umożliwiać co najmniej:

a) archiwizowanie spraw (przekazywanie do archiwum zakładowego),b) generowanie potwierdzeń przekazania akt do archiwum zakładowego,c) potwierdzanie przejęcia akt do archiwum zakładowego,d) generowanie spisów dokumentacji nie archiwalnej przeznaczonej do zbrakowania, brakowanie dokumentów ewidencjonowanych,e) tworzenie „paczki archiwalnej” dla dokumentacji archiwalnej.

3.5 Wszelkie generowane spisy dokumentów oraz zawartość „paczki archiwalnej” powinny być zgodne z obowiązującym formatem wymiany danych udostępnionym przez Naczelną Dyrekcję Archiwów Państwowych.

3.6System musi umożliwić opisanie skanowanych dokumentów poprzez metadane zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z 2 listopada 2006 roku w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz. U. 2006 Nr 206, poz. 1519),

3.7 System musi umożliwiać wyszukiwanie zeskanowanych dokumentów maszynowych zachowanych w elektronicznym archiwum na podstawie ich zawartości (na zasadzie OCR).

Strona 8 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

3.8 System musi umożliwiać wyszukiwanie zarchiwizowanych dokumentów na podstawie co najmniej nast. wprowadzonych metadanych:a) Identyfikator - jednoznaczny w danym zbiorze dokumentów znacznik dokumentu, który umożliwia jego identyfikację,b) Twórca – podmiot odpowiedzialny za treść dokumentu, z podaniem jego roli w procesie tworzenia lub akceptacji dokumentu,c) Tytuł - nazwa nadana dokumentowi,d) Data- data zdarzenia związanego z tworzeniem dokumentu,e) Format- nazwa formatu danych zastosowanego przy tworzeniu dokumentu,f) Dostęp- określenie komu, na jakich zasadach i w jakim zakresie można udostępnić dokument,g) Typ - określenie podstawowego typu dokumentu (np. tekst, dźwięk, obraz, obraz ruchomy, kolekcja) w oparciu o listę typów Dublin Core

Metadata Initiative i jego ewentualne dookreślenie (np. prezentacja, faktura, ustawa, notatka, rozporządzenie, pismo),h) Relacja- określenie bezpośredniego powiązania z innym dokumentem i rodzaju tego powiązania,i) Odbiorca- podmiot, do którego dokument jest adresowany,j) Grupowanie– wskazanie przynależności do zbioru dokumentów,k) Kwalifikacja- kategoria archiwalna dokumentu,l) Język- kod języka naturalnego zgodnie z normą ISO-639-2 lub inne określenie języka, o ile nie występuje w normie,m) Opis- streszczenie, spis treści lub krótki opis treści dokumentu,n) Uprawnienia- wskazanie podmiotu uprawnionego do dysponowania dokumentem.

3.9 System musi być zgodny z Rozporządzeniem Ministra Zdrowia z 21 grudnia 2006 roku W sprawie rodzajów i zakresu dokumentacji medycznej w zakładach opieki zdrowotnej oraz sposobu jej przetwarzania (Dz. U. 2006 Nr 207, poz. 1819) oraz innymi aktualnie obowiązującymi ustawami, rozporządzeniami i normami dotyczącymi archiwizacji dokumentów oraz dokumentacji medycznej w formie elektronicznej.

3.10 System musi zapewnić integralność dokumentów i przypisanych do nich metadanych (ochrona przed wprowadzaniem zmian poza ustalonymi procedurami).

3.11 System powinien wspomagać czynności związane z przygotowaniem dokumentów stanowiących materiały archiwalne i ich metadane („paczka archiwalna”) do przekazania do Archiwum Państwowego zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji)z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych, a w tym:

a) wyodrębnić automatycznie dokumenty przeznaczone do przekazania,b) przygotować automatyczne spis zdawczo - odbiorczy w postaci dokumentu elektronicznego,c) wyeksportować dokumenty i ich meta dane,d) oznaczyć dokumenty przekazane do Archiwum Państwowego w sposób umożliwiający ich odróżnienie od dokumentów nieprzekazanych.

4.1. Wersjonowanie i historia dokumentów oraz innych elementów systemu4.1.1 ESODIA musi być wyposażony w mechanizmy umożliwiające wersjonowanie co najmniej:

a) pism,b) załączników do pismc) spraw.

Strona 9 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

4.1.2 ESODIA musi przechowywać informację o historii wszystkich czynności wykonanych przez użytkowników podczas pracy z dokumentami oraz podczas prowadzenia spraw.

4.1.3 System musi umożliwiać cofanie aktualnej wersji załączników do pism do wersji archiwalnej.4.2. Interfejs użytkownika4.2.1 W głównym oknie powinny znajdować się pisma, którymi ma zająć się zalogowana osoba z możliwością przefiltrowania tej listy według kryteriów dotyczących

sposobu dekretacji / przekazania pisma. W głównym oknie powinno znaleźć się również pole szybkiego wyszukania pisma.4.2.2 Użytkownik musi mieć dostęp do wszystkich spraw, w których realizacji brał udział, a które zostały zakończone.4.2.3 Użytkownik musi mieć możliwość sortowania wszystkich prezentowanych list.4.2.4 W głównym oknie powinno znajdować się pole wyszukiwania prostego oraz przycisk lub link umożliwiający przejście do formatki wyszukiwania

zaawansowanego.4.2.5 System musi informować użytkownika o zbliżającym się upływie terminu lub przekroczeniu go dla co najmniej następujących czynności:

a) odpowiedzi na pismo,b) opracowywania w ramach projektu,c) załatwieniu sprawy.

4.2.6 System musi informować użytkownika poprzez e-mail co najmniej o:a) przypisaniu pisma do realizacji,b) terminie realizacji pisma (pisma zagrożone),c) zbliżającym się terminie załatwienia sprawy.

4.2.7 ESODIA musi zawierać funkcje wspierające przygotowanie korespondencji seryjnej (również elektronicznej), co najmniej:a) dołączanie utworzonych (w MS Word) szablonów pism i etykiet oraz wydruk na etykietach adresowych i kopertach,b) automatyczne generowanie listów w ramach opracowania odpowiedzi na pisma na podstawie przygotowanych szablonów,

tworzenie i podłączania list adresowych.

4.3. Rejestracja pism4.3.1 System musi zapewnić co najmniej następujące tryby rejestrowania pism:

a) skanowanie bezpośrednio przed zarejestrowaniem pisma,b) skanowanie masowe, z późniejszym określaniem metryczki dla pisma.

4.3.2 ESODIA musi zapewnić jednoczesne wielostanowiskowe rejestrowanie pism.4.3.3 System musi zapewnić możliwość wprowadzenia do systemu kolejno kilku dokumentów wielostronicowych.4.3.4 Podczas rejestracji dokumentu ESODIA musi umożliwiać przechodzenie między polami formularza przy pomocy przycisku tabulacji (TAB).4.3.5 System musi zapewnić operatorowi rejestrującemu dokument w systemie możliwość wprowadzenia jako metadane co najmniej następujących informacji w

formie odrębnych pól:a) data wpływu,

Strona 10 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

b) typ pisma (wybór ze słownika),c) komórka, która zajmie się przetworzeniem pisma (wybór ze słownika),d) sygnatura nadawcy,e) numer nadawczy,f) nadawca (wybór ze słownik),g) adresat - w przypadku korespondencji imiennej, data pisma, załączniki do pisma głównego.

4.3.6 Dane teleadresowe muszą być osłownikowane i wprowadzane do oddzielnych pól, co powinno mieć odzwierciedlenie w bazie danych systemu.4.3.7 Podczas rejestracji dokumentu użytkownik musi mieć możliwość dodania załącznika – w postaci pliku z dysku lub ze skanera.4.3.8 System musi zapewnić możliwość skanowania bezpośrednio z aplikacji, przy czym wymagana jest współpraca ze skanerami sieciowymi i standardowymi

(interfejs TWAIN)4.3.9 Dla wybranych atrybutów pisma system posiada mechanizm wspierający wyszukiwanie kontekstowe podczas wprowadzania danych dotyczących pism i spraw

dla wybranych atrybutów (np. komórka organizacyjna, nadawca/odbiorca itp.). Mechanizm ten musi pozwalać na szybkie odszukanie żądanych danych poprzez ograniczanie w kontekstowym okienku wyboru danych spełniających określone kryterium (np. fragment nazwiska lub też nazwisko i miasto itp.). Użytkownik wybiera żądaną pozycję z wyświetlonej listy, na której prezentowane są szczegółowe dane (np. imię, nazwisko, adres) bez potrzeby przechodzenia na inny ekran.

4.3.10 ESODIA powinien umożliwiać ciągłość rejestrowania korespondencji przychodzącej, tzn. po wprowadzeniu w podstawowy formularz do rejestrowania korespondencji przychodzącej koniecznych danych – charakteryzujących dany dokument i zapisaniu ich - powinien otworzyć się nowy formularz do rejestrowania następnego pisma.

4.3.11 System musi umożliwiać wydruk kodu paskowego dla zarejestrowanego pisma lub dla poszczególnych załączników pisma oraz musi mieć możliwość przeszukiwania repozytorium dokumentów po tym kodzie.

4.4. Ekspedycja pism4.4.1 System musi zapewnić wsparcie dla procesu ekspedycji przesyłek.4.4.2 System musi zapewnić możliwość wycofania pisma z ekspedycji przez osobę odpowiedzialną za pismo.4.4.3 System musi umożliwić anulowanie ekspedycji pisma.4.4.4 System musi zapewnić możliwość rejestracji zwrotki.4.4.5 System musi umożliwić określenie sposobu dostarczenia pisma (wybór ze słownika).4.4.6 System musi umożliwić określenie kosztów przesyłki na podstawie wprowadzonej wagi oraz cennika.4.4.7 System musi zapewnić tworzenie paczek korespondencji.4.4.8 System musi umożliwić grupowanie pism do jednego kontrahenta.4.5. Obsługa pism4.5.1 System musi umożliwiać prezentację szczegółów pisma. Na ekranie szczegółów pisma wymagana jest prezentacja co najmniej następujących informacji:

a) danych podstawowych pisma (wszystkie metadane wprowadzone podczas rejestracji pisma),b) atrybutów określających aktualny stan pisma, co najmniej: „do realizacji”, „przeterminowane”,

Strona 11 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

c) atrybutów określających rodzaj (typ) pisma, co najmniej: „wewnętrzne”. „informacyjne”d) informacji kontekstowej dla osoby, dla której pismo jest prezentowane o dalszych krokach, które musi wykonać z danym pismem,e) danych szczegółowych pisma - czego dotyczy dane pismo,f) aktualnej dekretacji,g) informacji, kto aktualnie zajmuje się dokumentem,h) listy załączników do pisma,i) listy operacji wykonanych na piśmie,j) listy komentarzy do pisma z oznaczeniem komentarzy prywatnych.

4.5.2 System musi zapewnić obsługę dowolnej ilości pism przychodzących, wychodzących i wewnętrznych.4.5.3 ESODIA musi być wyposażony w możliwość wyszukiwania pełno tekstowego zarówno w metadanych dokumentów, jak i w treści dokumentów w formatach co

najmniej: RTF, DOC, PPT, XLS, CSV, PDF.4.5.4 System musi zapewnić możliwość wyszukiwania według wielu kryteriów jednocześnie m.in.: data wpływu pisma, status pisma, załączniki4.5.5 System musi zapewnić możliwość eksportu wyników wyszukiwania do pliku (w postaci dokumentu XML).

4.5.6 System musi zapewnić możliwość edycji zawartości pól metadanych pisma przez uprawnionych użytkowników.4.5.7 System musi zapewnić możliwość wysłania linku do pisma wraz z automatycznym dodaniem do treści wiadomości informacji o piśmie (z metryczki pisma).

4.5.8 System musi zapewnić możliwość wysłania pisma zewnętrznym adresatom wraz z automatycznym dodaniem do treści wiadomości informacji o piśmie (z metryczki pisma) oraz możliwością określenia wysyłanych załączników.

4.5.9 System musi zapewnić możliwość tworzenia komentarzy do pism (prywatnych – widocznych przez użytkownika tworzącego notatkę i publicznych – widocznych przez wszystkich uprawnionych użytkowników).

4.5.10 System musi zapewnić mechanizmy dostępu do pism:a) automatycznie – na podstawie ścieżki przetwarzania,b) automatycznie – na podstawie roli w systemie ,c) automatycznie – na podstawie struktury organizacyjnej,d) ręcznie – nadawanie uprawnień do przeglądania pism określonym osobom.

4.5.11 System musi zapewnić możliwość eksportu metryczki pisma w postaci dokumentu XML.4.5.12 System musi zapewnić możliwość utworzenia pisma na wzór (zawierającego te same dane).4.5.13 System musi zapewnić możliwość podjęcia najczęściej wykonywanych operacji przez daną grupę użytkowników bezpośrednio ze strony szczegółów pisma

(tzw. szybkie akcje). Szybkie akcje powinny obejmować co najmniej: a) dekretację, b) akceptację, c) oznaczenie pisma jako wykonanego, d) dekretację w imieniu przełożonego.

Strona 12 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

4.5.14 System musi umożliwiać przypisanie pism do wielu spraw (możliwość określenia osobno sprawy w różnych komórkach org.).4.5.15 System musi umożliwiać anulowanie/usunięcie pisma. Operacja ta nie może powodować fizycznego usunięcia pisma z bazy, a jedynie oznaczenie pisma jako

usuniętego. Na wynikach wyszukiwania pismo musi być prezentowane w wyróżniony sposób (np. przekreślone lub oznaczone czerwonym kolorem).4.5.16 System musi zapewnić mechanizmy pracy grupowej nad projektami dokumentów (wychodzących i wewnętrznych). W szczególności system zapewni

możliwość tworzenia witryn pracy grupowej nad dokumentem posiadających co najmniej możliwości:a) określenia harmonogramu prac nad dokumentem,b) przypisania zadań,c) tworzenia dokumentów roboczych, załączników, d) określenie norm jakim powinien odpowiadać dokument.

4.6. Obsługa korespondencji przychodzącej i wewnętrznej4.6.1 System musi zapewnić możliwość określenia co najmniej:

a) sposobu przekazania – wybór: dekretacja, przekazanie, przekazanie kopii, powiadomienie,b) komórki i osób, do których następuje przekazanie,c) komentarza do dekretacji,d) dyspozycji.

4.6.2 ESODIA musi umożliwiać rejestrowanie korespondencji użytkownikom posiadającym odpowiednie uprawnienia w zakresie określonym instrukcją kancelaryjną.

4.6.3 System musi zapewnić możliwość przekazania lub dekretacji pisma do wielu osób jednocześnie z określeniem zakresu dekretacji (np. odpowiedzialny za całość, odpowiedzialny za wykonanie, do wiadomości).

4.6.4 System musi umożliwiać anulowanie przekazania (dekretacji) lub zmianę dekretacji przez uprawnione osoby.4.6.5 System musi umożliwiać wykonanie dekretacji w imieniu szefa jednostki przez pracowników kancelarii.4.6.6 System musi zapewnić możliwość odesłania błędnie przekazanego pisma.4.6.7 System musi zapewnić możliwość odnotowania otrzymania papierowej wersji pisma.4.6.8 System musi zapewniać wsparcie podczas rejestracji w zakresie szybkiego odszukania pisma o tym samym numerze nadawczym (np. faks, a później oryginał).

W takim przypadku, przy rejestracji pisma o numerze nadawczym system powinien poinformować, że pismo o podanym numerze już istnieje w bazie i zapewnić możliwość przejścia na szczegóły tego pisma.

4.6.9 System musi zapewnić możliwość odnotowania co najmniej:a) czy pismo wymaga / nie wymaga odpowiedzi,b) czy pismo ma charakter informacyjny.

4.6.10 System musi zapewnić możliwość określenia maksymalnego czasu na realizację pisma. System musi wysyłać powiadomienia do osób odpowiedzialnych za realizację pisma o zbliżającym się terminie odpowiedzi na pismo oraz o przekroczonym terminie odpowiedzi na pismo.

4.6.11 System w wynikach wyszukiwania musi graficznie (poprzez wyróżnienie kolorami) prezentować pisma, które wymagają realizacji, dla których zbliża się termin realizacji oraz dla których ten termin minął, przy czym dla każdej z powyższej sytuacji powinien zostać wykorzystany inny kolor (np. kolejno: zielony, niebieski

Strona 13 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

i czerwony).4.6.12 Dla korespondencji wewnętrznej system musi zapewniać mechanizm tworzenia wersji roboczej oraz funkcjonalność zatwierdzania pism. 4.7. Obsługa korespondencji wychodzącej4.7.1 ESODIA musi zapewnić jednoczesne wielostanowiskowe rejestrowanie pism wychodzących.4.7.2 System musi zapewnić możliwość tworzenia pism roboczych. Pismem roboczym jest pismo, które nie zostało przekazane do akceptacji, nad którym

użytkownik jeszcze pracuje.4.7.3 System musi umożliwić przekazanie pisma roboczego do akceptacji (wybranej osobie) lub oznaczenie, że pismo nie wymaga akceptacji. System musi zapewnić

możliwość wieloetapowej akceptacji.4.7.4 System musi umożliwić przekazanie zaakceptowanego pisma do ekspedycji (wysyłka), przy czym powinna być możliwość określenia komórki organizacyjnej

realizującej wysyłkę.4.7.5 System musi zapewnić możliwość określenia sposobu obsługi pisma (pismo na które oczekiwana jest odpowiedzi, pismo nie wymagające odpowiedzi).4.7.6 System musi zapewnić możliwość określenia maksymalnego czasu oczekiwania na wpłynięcie odpowiedzi. System musi wysyłać powiadomienia do osób

odpowiedzialnych za realizację pisma o zbliżającym się terminie odpowiedzi na pismo oraz o przekroczonym terminie odpowiedzi na pismo.5. Funkcjonalność wspomagająca pracę Działu Zamówień Publicznych5.1 System musi być zgodny z ustawą z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. 2007 nr 223 poz. 1655, z późn. zm.) System musi zapewnić

możliwość aktualizacji w celu zapewnienia zgodność programu ze znowelizowaną ustawą Prawo zamówień publicznych i aktami wykonawczymi.5.2 System musi mieć możliwość wygenerowania dokumentu projektu zakupowego wraz ze zdefiniowaniem:

a) celów,b) zadań,c) terminów realizacji zadań.

5.3 System musi umożliwiać przydzielanie zadań w ramach projektów wraz z określaniem terminów:a) Monitorowanie terminów realizacji poszczególnych zadań oraz powiadamianie o zbliżających się terminach realizacji,b) Powiadamianie o zadaniach zagrożonych.

5.4 System musi umożliwiać sprawne przeprowadzenie oceny złożonych ofert - funkcje przeliczające automatycznie punktację.5.5 System musi mieć możliwość tworzenia zespołów roboczych projektów oraz musi umożliwiać przypisywanie ról użytkownikom zgodnie z wykonywaną funkcją

w zespole np. „przewodniczący komisji przetargowej”.5.6 System musi umożliwić funkcję powiadamiania członków zespołów roboczych wraz z potwierdzeniem odbioru powiadomienia.5.7 System musi umożliwiać publikowanie dokumentów przetargowych na stronach WWW i BIP.

5.8 System musi umożliwiać zdefiniowana ścieżki zatwierdzania dokumentu zakupowego.5.9 System musi umożliwiać przydzielanie zadań i aktualizacja terminów dla osób zespołu projektowego.5.10 System musi umożliwić monitorowanie terminów realizacji poszczególnych zadań oraz powiadamianie o zbliżających się terminach realizacji.5.11 System musi być oparty o aktualne drzewo procesów dotyczące zamówień publicznych .

Strona 14 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

5.12 System musi posiadać wbudowany słownik CPV, który będzie można aktualizować.5.13 System musi pozwalać grupować zamówienia i ich wartości według grup (dostawy) i kategorii (usługi) Wspólnego Słownika Zamówień (CPV).5.14 System musi umożliwiać integrację z FK programu InfoMedica, jeżeli zajdzie taka potrzeba również z modułem GM i Środki Trwałe. Wykonawca zobowiąże się

do integracji systemu po wcześniejszej analizie przedwdrożeniowej.5.15 System musi umożliwiać rejestracje wszelkiej korespondencji związanej z zamówieniem publicznym.5.16 System musi zapamiętywać wszystkie dokumenty związane z postępowaniem oraz ewidencjonować wszystkie złożone oferty, podpisane umowy wraz z

aneksami.5.17 System musi posiadać funkcję pomocy w której znajdzie się opis działania.5.18 System musi udostępniać funkcjonalność sporządzania raportów i zestawień, obejmujących przetargi wybrane zgodnie ze zdefiniowanymi kryteriami

wyszukiwania, co najmniej według:a) trybu,b) wartości,c) sposobu zakończenia postępowania,d) uczestnictwa biegłych i członków komisji,e) nazw oferentów.f) dat i ich zakresów – co najmniej: data ogłoszenia i data rozstrzygnięcia.

5.19 System musi umożliwiać zapamiętywanie postępowań jako wzorzec. System musi potraktować je tak jak wzorce już zdefiniowane i przy tworzeniu nowego postępowania umożliwić wybór zapamiętanego postępowania jako wzorzec. System musi umożliwić modyfikowanie wszystkich dokumentów wzorców postępowania i druków niezbędnych dla danego trybu postępowania. System musi umożliwić stworzenie wzorców postępowań o zamówienie publiczne określonych w ustawie prawo zamówień publicznych, w szczególności:

a) przetarg nieograniczony,b) przetarg ograniczony ,c) negocjacje z ogłoszeniem,d) negocjacje bez ogłoszenia,e) Dialog konkurencyjny,f) zapytanie o cenę,g) zamówienie z wolnej rękih) licytacja elektroniczna.i) Prekwalifikacja do trybów konkurencyjnych

System musi uwzględniać wzorce postępowania obowiązujące u Zamawiającego w ramach uregulowań określonych w procesach związanych z realizacją systemu Zarządzania Jakością obowiązującego w jednostkach organizacyjnych Zamawiającego.

5.20 System musi umożliwiać z tego poziomu publikowanie informacji o przetargach na oficjalnej stronie www oraz BIP (pkt. 11). Ten sposób publikowania Informacji musi zapewnić możliwość przeglądania i przeszukiwania listy przetargów (aktualnej i archiwalnej) co najmniej wg kryteriów określonych w pkt. 5.18,

Strona 15 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

6. Raporty6.1 Raporty z funkcjonowania systemu muszą być podzielone na co najmniej trzy podstawowe grupy:

a) bezpieczeństwa – informacje o próbach naruszenia bezpieczeństwa danych, próbach nieautoryzowanego dostępu, próbach włamań do sytemu itd.,b) aktywności użytkowników – informacje o ilości logowań do systemu, czasie logowań, itp.,c) realizacji spraw – informacja o poziomie zaawansowania realizacji sprawy, uczestnikach itp

6.2 ESODIA musi umożliwiać generowanie raportów ze wszystkich danych przechowywanych w systemie.6.3 Zamawiający wymaga, aby narzędzie służące do generowania raportów stanowiło osobną witrynę.6.4 Raporty z danych muszą być tworzone według wcześniej zdefiniowanych szablonów.6.5 Zamawiający wymaga, aby dane z raportów można było zapisać w postaci plików MS Excel XLS i CSV, PDF, XML.6.6 Zamawiający wymaga, aby system pozwalał na generowanie raportów z funkcjonowania systemu.6.7 Dostęp do mechanizmu sprawozdawczości z funkcjonowania systemu musi być nadawany na poziomie definiowania uprawnień użytkownika.6.8 System z chwilą uruchomienia powinien zawierać co najmniej następujące raporty i zestawienia:

a) dziennik doręczeń korespondencji,b) zestawienie wysłanych przesyłek,c) książka pocztowa,d) pisma przychodzące, na które jeszcze nie odpowiedziano,e) pisma nieprzypisane do spraw,f) pisma nieobsłużone,g) pisma nierozpatrzone,h) pisma, na które oczekiwana jest odpowiedź,i) pisma w obiegu.

7.1 Struktura organizacyjna jednostki musi być oparta o model drzewa i zawierać podstawowe dane na temat komórek.7.2 Definiowanie drzewa struktury oraz wszelkie zmiany w strukturze mogą być wykonywane przez użytkowników z odpowiednimi uprawnieniami.

7.3 Struktura powinna jak najwierniej oddawać rzeczywisty stan organizacji w Szpitalu.7.4 Użytkownikom w strukturze powinno się definiować oprócz podstawowych informacji , również dane adresowe oraz kontakty.7.5 System musi umożliwiać prowadzenie ewidencji pracowników oraz definiowanie relacji pomiędzy pracownikami (przełożony – podwładny).7.6 ESODIA musi umożliwiać przypisanie użytkownikowi wielu ról spośród ról zdefiniowanych w ich systemie uprawniających do wykonywania określonych w ich

ramach czynności.7.7 Struktura powinna zostać całkowicie stworzona przez Wykonawcę w toku konsultacji z Zamawiającym.8. Funkcjonalność ewidencji zgłoszeń8.1 System musi umożliwić zarządzanie zgłoszeniami i przekazywanie ich w ramach procesu do wskazanych pracowników w celu realizacji.8.2 System musi umożliwić obsługę zgłoszeń w ramach procesu obiegu dokumentów.8.3 System musi umożliwić automatyczne powiadamianie o zgłoszeniu.

Strona 16 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

8.4 System musi udostępniać statystykę rejestrowanych zgłoszeń w formie arkusza oraz wykresu.8.5 System musi udostępniać bazę wiedzy do zapisywania rozwiązanych już problemów.8.6 System musi umożliwiać nadawanie statusów zgłoszeniom, np.: „nowe”, „realizowane”, „zakończone”, „wycofane”, „wstrzymane”8.7 System musi umożliwiać określanie wymaganego czasu na realizację zadań.

System musi umożliwiać podczas rejestracji zgłoszenia określenie za pomocą wbudowanych i konfigurowalnych słowników co najmniej następujące informacje:

a) priorytet zgłoszenia (pilne, normalne),b) datę oraz godzinę zgłoszenia,c) kategorię zgłoszenia (np. zgłoszenie serwisowe),d) komórkę organizacyjną,e) osobę zgłaszającą,f) numer kontaktowy,g) termin realizacji

9.1 System musi umożliwić tworzenie bazy danych aparatury medycznej.9.2 System musi umożliwić tworzenie zestawów aparatury.9.3 System musi umożliwić gromadzenie i zarządzanie danymi dotyczącymi aparatury oraz zestawów w zakresie co najmniej:

a) producentów,b) kontrahentów (dostawców i firm serwisujących),c) awarii sprzętu,d) zleceń serwisowych,e) przeglądów okresowych,f) umów serwisowych,

9.4 System musi umożliwiać generowanie oraz składanie podpisu elektronicznego na co najmniej następujących dokumentach:a) protokół instalacji,b) protokół kasacji,c) protokół serwisowy,d) protokół kontrolny,e) orzeczenie techniczne.

9.5 System musi umożliwić gromadzenie informacji oraz dokumentów związanych z aparatura medyczną które wpływają z zewnątrz do Szpitala, również dokumentów podpisanych podpisem elektronicznym.

9.6 System musi umożliwić opisanie aparatury zgodnie ze wcześniej zdefiniowanymi polami co najmniej takimi jak:a) identyfikator urządzenia,b) grupa (kategoria),c) producent,

Strona 17 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

d) nazwa,e) model,f) numer seryjny,g) rok i miesiąc produkcji,h) atesty,i) certyfikaty,j) daty ostatniego przeglądu (w przypadku zakupu aparatury używanej)k) lokalizacja (kom. organizacyjna oraz lokalizacja fizyczna – co najmniej: nr/nazwa budynku, nr/nazwa części budynku, kondygnacja, nr/nazwa

pomieszczenia),l) osoby odpowiedzialne,m) operatorzy,n) kontrahent (dostawca),o) nr dokumentu zakupu.

9.7 W celu zapewnienia elastyczności system musi umożliwić definiowanie formularzy za pomocą których opisywana będzie aparatura medyczna.

9.8 System musi zapewnić współpracę funkcjonalności ewidencji sprzętu medycznego z funkcjonalnością zgłoszeń (pkt 8). Podczas rejestracji zgłoszenia musi być możliwość (w przypadku zgłoszeń serwisowych aparatury medycznej) wybrania z bazy sprzętu aparatury której dotyczy zgłoszenie.

9.9 System musi umożliwić co najmniej następującą funkcjonalność:a) rozszerzanie i zarządzanie słownikami, kontrahentów (firmy serwisujące i dostarczające aparaturę medyczną),b) dołączanie załączników w postaci dokumentów do opisywanego sprzętu,c) automatyczne generowanie kodów kreskowych oraz identyfikatorów urządzeń,d) raportowanie (co najmniej: z wykonanych działań serwisowych dla wybranego: sprzętu, dostawcy, firmy serwisującej, umowy serwisowej, komórki

organizacyjnej, w której sprzęt się znajduje; zestawienia kosztów napraw dla wybranego: sprzętu, firmy serwisującej, dostawcy, umowy serwisowej, komórki organizacyjnej, w której sprzęt się znajduje)

9.10 Funkcjonalność w zakresie ewidencji sprzętu medycznego musi być nierozerwalnym elementem systemu ESODIA i działać w jego ramach.10. Funkcjonalność modelowania ścieżek procesów (WorkFlow)10.1 System musi zawierać narzędzia do tworzenia ścieżek procesu. Musi umożliwiać obsługę przepływu pracy (WorkFlow) czyli automatyczne przemieszczanie

sprawy pomiędzy użytkownikami systemu w ustalonej dla danej kategorii spraw kolejności (zgodnie ze zdefiniowaną uprzednio ścieżką procedowania sprawy).

10.2 Dostęp do funkcjonalności modelowania ścieżek procesów tyko dla użytkowników z odpowiednimi uprawnieniami. Wykonawca zdefiniuje ścieżki procesów na podstawie przeprowadzonej analizy obiegu informacji w jednostce.

10.3 System musi mieć możliwość przechowywania projektowanych procesów.10.4 System podczas tworzenia procesu musi umożliwiać zdefiniowanie co najmniej:

a) warunków rozpoczęcia procesu, (wyzwalacze),

Strona 18 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

b) warunków zakończenia procesu,c) działań (aktywności) wchodzących w skład procesu – pojedyncze zdarzenia, oraz zasady regulujące przepływy (przejścia) miedzy nimi,d) zadań dla uczestników procesu, które mają zostać wykonane,e) powiązań z aplikacjami zewnętrznymi,f) definicji metadanych wykorzystywanych przez system, które mogą być wykorzystywane w czasie realizacji procesu.

10.5 System musi umożliwiać automatyczną weryfikację poprawności i kompletności zaprojektowanego procesu, tj. sprawdzenie logiczne, czy procedura nie zawiera martwych punktów albo zakleszczeń.

10.6

System musi posiadać (zgodnie ze standardem WFMC ) co najmniej następujące funkcjonalności Workflow:a) Odwzorowanie struktury organizacyjnej jednostki - w ramach tej funkcjonalności musi być możliwość: tworzenia komórek organizacyjnych, zależności

między nimi, przypisywania pracowników do komórek, określania ich kompetencji oraz przypisywania stanowisk.b) Rozdzielanie pracy, równoległe wykonywanie zadań – w przypadku, kiedy określona praca jest dzielona na zadania, a te są wykonywane w ramach

kolejnych etapów procesu pracy. Aby skrócić czas wykonywania procesu, powinna być możliwość równoległego wykonywania części przez kilka osób.c) Łączenie pracy, synchronizacja wykonanych zadań - w przypadku łączenia wykonanych zadań trzeba uwzględnić sytuację, w której część wykonanych

prac zostaje wykonana szybciej, a część z opóźnieniem - po terminie.d) Warunkowe wykonywanie etapów prac – w przypadku, kiedy istnieje potrzeba, aby dany etap prac był wykonywany w zależności od pewnego

warunku w taki lub inny sposób.e) Przypisywanie osób - zadania mogą być wykonywane przez konkretne osoby, komórki organizacyjne, dynamiczne tworzone grupy osób.f) Określanie czasu wykonywania etapu prac oraz całego procesu - w przypadku rygorystycznych ograniczeń czasowych na wykonywanie danej pracy,

kiedy istnieje potrzeba ścisłej kontroli czasu wykonania poszczególnych etapów pracy.g) Dowiązywanie informacji do przebiegu procesu - przesyłanie grupy danych pomiędzy wykonywanymi zadaniami.

11. Oficjalna strona www , BIP, Elektroniczna Skrzynka Podawcza:11.1 System ESODIA musi współpracować z Elektroniczna Skrzynka Podawcza.11.2 System musi umożliwiać wystawianie urzędowego poświadczenia odbioru (UPO) .

Wykonawca dostarczy, zainstaluje oraz skonfiguruje moduł kryptograficzny (HSM). Gwarancja wraz z dokumentem zakupu zostanie przekazana Zamawiającemu. Zgodnie z Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 27 listopada 2006 r. w sprawie sporządzania i doręczania pism w formie dokumentów elektronicznych( Dz. U. 2006 nr 227 poz. 1664) dostarczony moduł kryptograficzny (HSM) musi spełniać wymagania normy FIPS 140-2 poziom 3 lub CEN-CWA 14167-2 lub nowszej i m.in. powinien zapewnić:

a) generowanie i przechowywanie materiału kryptograficznego służącego do oznaczania danymi stwierdzającymi ważność certyfikatów kwalifikowanych,b) ochronę przed nieuprawnionym dostępem, w bezpiecznej obudowie odpornej na nieuprawnioną ingerencję z zewnątrz,c) zabezpieczenie przed nieuprawnioną ingerencją polegające na zniszczeniu materiału kryptograficznego w przypadku wykrycia takiej ingerencji;

11.3 System musi umożliwiać automatyczne przekazywanie dokumentów pomiędzy skrzynką a ESP za pośrednictwem Web Services.11.4 System musi umożliwiać składowanie i archiwizowanie wygenerowanych poświadczeń przedłożenia.11.5 System musi umożliwiać powiadomienie Adresata o oczekującym piśmie (wraz z informacją, gdzie można pismo odebrać).

Strona 19 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

11.6 System musi umożliwiać przesyłanie elektronicznego poświadczenia doręczenia do Nadawcy dokumentu.11.7 System musi umożliwiać ewidencjonowanie urzędowego poświadczenia doręczenia.11.8 System musi udostępniać funkcjonalność Elektronicznej Skrzynki Podawczej zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia

27 listopada 2006 r. w sprawie sporządzania i doręczania pism w formie dokumentów elektronicznych (Dz. U. 2006.227.1664),11.9 Od strony klienta system musi zapewnić możliwość składania pism z wykorzystaniem Internetu i późniejsze śledzenie toku sprawy oraz prowadzenie

korespondencji ze Szpitalem.11.10 System musi umożliwiać złożenie podpisu elektronicznego z poziomu ESP na przekazywanych poprzez ESP dokumentach.11.11 System musi udostępnić do pobrania zaświadczenie w postaci elektronicznej, z uwzględnieniem pozyskania Urzędowego Poświadczenia Doręczenia.11.12 System musi umożliwiać przyjmowanie danych pochodzących z administracyjnych źródeł danych.

11.13 System musi zapewniać możliwość podpisywania bezpiecznym podpisem elektronicznym dokumentów przeznaczonych do wysłania na zewnątrz przez wyznaczonych w Szpitalu pracowników.

11.14 System musi zapewniać możliwość podpisywania niekwalifikowanym podpisem elektronicznym dokumentów wytworzonych w Szpitalu, przeznaczonych do obiegu wewnętrznego.

11.15 System musi zapewniać kontrolę dokumentów, które wpłynęły do systemu, w zakresie posiadania przez te dokumenty podpisu elektronicznego (kwalifikowanego i niekwalifikowanego)

11.16 System musi zapewniać weryfikację bezpiecznego podpisu elektronicznego.11.17 System musi zapewniać weryfikację niekwalifikowanego podpisu elektronicznego.11.18 System musi umożliwiać podpisywanie dokumentów dowolną liczbą podpisów elektronicznych.11.19 System musi umożliwiać integrację z platformą ePUAP.

11.20System musi udostępniać za pomocą protokołu SOAP funkcję umożliwiającą zachowanie w repozytorium systemu podpisanych elektronicznie dokumentów XML. Sposób obsługi takich dokumentów zaimplementowany w systemie powinien spełniać wymagania określone w Rozporządzeniu Prezesa Rady Ministrów z dnia 29 września 2005 roku w sprawie warunków organizacyjno-technicznych doręczania dokumentów elektronicznych podmiotom publicznym.

11.21Wykonawca w ramach niniejszego zamówienia zaprojektuje i wykona dwie strony internetowe:

a) BIP- Biuletyn Informacji Publicznej,b) oficjalną stronę Internetową.

11.22 Strona oficjalna będzie miała 3 wersje językowe - polską, angielska i niemiecką na stronie będzie odnośnik do wersji językowej.

11.23 Wykonawca w ramach niniejszego zamówienia wykona projekt stron (pkt. 11.21) w formie elektronicznej wraz z zawartością merytoryczną i graficzną, zarówno strony głównej oraz podstron, a ponadto systemu linków i banerów wraz z ich wzajemną hierarchią powiązań.

11.24 Strona BIP oraz oficjalna zostanie zaprojektowana w czasie realizacji projektu.11.25 Strona internetowa- informacyjna BIP musi zostać sporządzona zgodnie z ustawą o BIP.

11.26 Wygląd, funkcjonalność oraz treść Wykonawca uzgodni z Zamawiającym podczas realizacji projektu. Strony powinny prezentować spójną szatę graficzną oraz wykorzystane elementy animacyjne.

Strona 20 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

11.27 System musi umożliwić zarządzanie treścią obu stron z poziomu portalu ESODIA.11.28 Logowanie na stronie powinno umożliwiać również połączenie się za pomocą witryny do zasobów portalu ESODIA.

11.29 Logowanie z zewnętrznej lokalizacji powinno odbywać się z wykorzystaniem aktualnie obowązujących technicznych standardów bezpieczeństwa w zakresie dostępu.

11.30

Z poziomu funkcjonalności do zarządzania stronami internetowymi powinna być możliwość:a) dodawania informacji (podstron), edytowania i usuwania ich (przenoszenia do rejestru stron usuniętych),b) dodawania i edycji informacji o przetargach (ta funkcjonalność jest powiązania funkcjonalnością określoną w pkt. 5). Ten sposób publikowania

Informacji musi zapewnić możliwość przeglądania i przeszukiwania listy przetargów (aktualnej i archiwalnej) co najmniej wg kryteriów określonych w pkt. 5.18,

c) automatycznej archiwizacji stron edytowanych oraz kasowanych (rejestr zmian oraz rejestr stron usuniętych),d) zapisu kto i kiedy się logował lub próbował się logować do części administracyjnej i z jakim skutkiem- w postaci logu,e) edytowania kompletnej instrukcji obsługi BIP,f) wyszukiwania,g) aktualizowania metryczki dokumentów,h) kodowania polskich znaków diakrytycznych w standardzie UTF-8,i) przeglądania statystyki odwiedzin z wykresem graficznym,j) dodawania i edycji aktualności.

11.31 Strona główna może zawierać elementy animowane wykonane w technologii Flash/GIF. Wykonawca zobowiązuje się do przekazania źródeł plików graficznych w formatach *.psd, *.cdr, *.fla (dla gif-ów animowanych plik źródłowy).

11.32 Prawa autorskie do design-u strony pozostaną własnością Zamawiającego.

11.33 Składniki strony muszą być dostosowane do co najmniej Internet Explorer w wersji 6.0 i nowszej oraz Firefox w wersji 3.0 i nowszej oraz być dostosowana do rozdzielczości monitora 1024x768 pikseli, kolor- 32 bity.

11.34

Strony (oficjalna i BIP) muszą być wykonane z wykorzystaniem Content Managment System (CMS):a) Warstwa zarządzania treścią musi być całkowicie oddzielona od warstwy prezentacji danych,b) Zarządzanie treścią strony musi być możliwe bez konieczności pracy na otwartym kodzie HTML,c) System musi umożliwiać zarządzanie zespołem redakcyjnym strony,d) Wykonawca zobowiązuje się do przekazania dokumentacji związanej z CMS, tj. ilustrowana instrukcja obsługi (szczególnie do zainstalowanych

komponentów, modułów, pluginów).

Oświadczam, że oferowany system spełnia wszystkie wyżej wymienione wymagania.

Strona 21 z 22

Nr sprawy: 90/D/ESODIA/2009 Załącznik nr 2 SIWZ

. . . . . . . . . . . . . . . dnia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (miejscowość) (podpis i pieczęć Wykonawcy)

Strona 22 z 22