szpital-ostroda.plszpital-ostroda.pl/userfiles/attachments/tenders/232/2... · Web viewMorfologia...

SZOSA/DZP/3321-01/2020 r. Załącznik nr 2 do SIWZ

OPIS PRZEDMIOTU ZAMÓWIENIA DLA CZĘŚCI I

Wdrożenie systemu informatycznego wraz z dostawą infrastruktury serwerowej i oprogramowania oraz przeszkoleniem personelu

1


Spis treściUżywane terminy........................................................................................................................5Określenie przedmiotu zamówienia............................................................................................7

Opis stanu bieżącego...............................................................................................................8Harmonogram prac projektowych..........................................................................................9Wymagania dotyczące wdrożenia.........................................................................................11Analiza przedwdrożeniowa...................................................................................................12Warunki licencyjne...............................................................................................................13Zasady gwarancji..................................................................................................................14

Gwarancja w zakresie wdrożonego systemu informatycznego........................................14Gwarancja w zakresie sprzętu komputerowego, oprogramowania systemowego i narzędziowego................................................................................................................15

Przebieg wdrożenia...............................................................................................................16Wymagania ogólne...........................................................................................................16Wdrożenie modułów oprogramowania aplikacyjnego.....................................................16

Wymagania w zakresie szkoleń użytkowników:..................................................................17Wymagania dotyczące opracowania planu testów i scenariuszy testów akceptacyjnych oraz przeprowadzenia według nich testów akceptacyjnych:........................................................19Wymagania dotyczące personelu Wykonawcy:...................................................................19Opis wymagań dla oprogramowania aplikacyjnego.............................................................20

Moduł Apteka Centralna...................................................................................................21Recepty.............................................................................................................................25Rehabilitacja.....................................................................................................................28Moduł Laboratorium.........................................................................................................30Moduł Sterylizatornii........................................................................................................36Moduł Integracji HL7-......................................................................................................40System Informacji Menadżerskiej....................................................................................41Raporty Zarządcze dla Kierownictwa...............................................................................41System Bi..........................................................................................................................43

Dostawa systemu ERP..........................................................................................................50Wymagania dla modułu Finanse i Księgowość (FK).......................................................51Wymagania dla modułu Rejestr Sprzedaży......................................................................56Wymagania dla modułu Środki Trwałe oraz Wyposażenie (wraz obsługą kolektora danych)..............................................................................................................................57Wymagania dla modułu gospodarka materiałowa............................................................59Wymagania dla modułu kadry i płace..............................................................................60

Elektroniczna Dokumentacja Medyczna (EDM)..................................................................63Moduł integracji z P1........................................................................................................67

2


Archiwum (repozytorium) Elektronicznej Dokumentacji Medycznej.............................69E-usługi.................................................................................................................................74

e-Rejestracja......................................................................................................................76e-Wyniki...........................................................................................................................76e-Wywiad..........................................................................................................................78Usługa e-obchód...............................................................................................................79e-Kontrahent.....................................................................................................................81e-Dokumentacja................................................................................................................83

Wymagania dla oprogramowanie motor bazy danych..........................................................85Warunki integracji dostarczanych rozwiązań z oprogramowaniem użytkowanym przez Zmawiającego.......................................................................................................................87Migracja bazy danych systemu HIS użytkowanego przez Zamawiającego.........................88

Organizacja prac migracyjnych........................................................................................89Odbiór procesu migracji...................................................................................................96

Wymagania dla systemu elektronicznego obiegu dokumentów (SEOD).............................96Proces odbiorowy Systemu.................................................................................................102

Odbiór produktu typu dokument.....................................................................................103Odbiór produktu typu migracja systemu.........................................................................103Odbiór produktu typu szkolenia......................................................................................104Odbiór produktów typu licencje.....................................................................................104Odbiór etapu / umowy....................................................................................................104

Testy....................................................................................................................................104Dokumentacja testowa....................................................................................................105Kryteria akceptacji dla scenariuszy i przypadków testowych........................................106Kryteria zakończenia testów sukcesem..........................................................................106Kryteria akceptacji testów funkcjonalnych.....................................................................107Kryteria akceptacji testów wydajnościowych.................................................................107Kryteria akceptacji testów integracji..............................................................................107

Wymagania dla sprzętu komputerowego............................................................................107Macierz dyskowa............................................................................................................108Serwer Typu 1.................................................................................................................112Oprogramowanie systemowe..........................................................................................114Serwer typu 2..................................................................................................................114UPS.................................................................................................................................116Switch dostępowy...........................................................................................................116FireWall (UTM)..............................................................................................................118Oprogramowanie do wirtualizacji...................................................................................121

3


Używane terminy Zamawiający - oznacza Szpital w Ostródzie

Wykonawca - Należy przez to rozumieć osobę fizyczną, osobę prawną albo jednostkę organizacyjną nieposiadającą osobowości prawnej, która ubiega się o udzielenie zamówienia publicznego, złożyła ofertę lub zawarła umowę w sprawie zamówienia publicznego.

Użytkownik - Oznacza osobę należąca do personelu Zamawiającego, posiadającą uprawnienia do korzystania z danego Modułu Oprogramowania Aplikacyjnego, nadane jej przez Wykonawcę lub Zamawiającego.

Producent Systemu Informatycznego - Należy przez to rozumieć osobę fizyczną, osobę prawną albo jednostkę organizacyjną nieposiadającą osobowości prawnej, która posiada autorskie prawa majątkowe do Oprogramowania Aplikacyjnego.

Umowa - Ilekroć w tekście niniejszego dokumentu zostanie przywołany wyraz “umowa” bez wyraźnego wskazania jej numeru lub daty zawarcia, należy go interpretować, jako odwołanie bezwzględne do umowy zawartej w ramach tego postępowania.

Moduł (Aplikacja) Oprogramowania Aplikacyjnego - Program komputerowy będący częścią składową Oprogramowania Aplikacyjnego, charakteryzujący się spójnym zakresem merytorycznym realizowanych funkcji, wykonujący swoje procedury w interakcji z innymi Aplikacjami wchodzącymi w skład Systemu Informatycznego

Szpitalny System Informatyczny (HIS) - Zbiór programów komputerowych (Aplikacji) wykonujących swoje procedury w interakcji ze sobą, składających się na produkt chroniony znakiem towarowym, będący w rozumieniu ustawy z dnia 4 lutego 1994 r. “o prawie autorskim i prawach pokrewnych” utworem, do którego prawa autorskie i majątkowe przysługują autorowi lub/i wykonawcy o właściwościach i konfiguracji określonych w SIWZ.

System ERP - Systemy Planowania Zasobów Przedsiębiorstwa (z ang. Enterprise Resource Planning - ERP), grupa zintegrowanych systemów informatycznych (modułowo zorganizowanych systemów informatycznych) integrujących tradycyjne funkcje zarządcze związane z księgowością finansową i zarządczą, finansami, kadrami i płacami, zaopatrzeniem, gospodarką magazynową, planowaniem i realizacją sprzedaży oraz logistyką. W obecnym opracowaniu stanowi synonim „części szarej”

Portal pacjenta - moduł przez, który udostępniane będą przez sieć Internet w technologii WWW nowoczesne e-usługi on-line opisane w OPZ.

Oprogramowanie aplikacyjne – w rozumieniu tego opracowania obejmuje: Szpitalny System Informatyczny (HIS) System ERP Portal Pacjenta Repozytorium EDM

Oprogramowanie Bazodanowe (Motor bazy danych) - Oznacza program komputerowy umożliwiający gromadzenie danych, produkcji strony trzeciej, stanowiące podstawę działania systemu Wykonawcy o właściwościach i konfiguracji określonych w SIWZ

Oprogramowanie Systemowe - odrębne od oprogramowania aplikacyjnego i bazodanowego oprogramowanie zainstalowane na Serwerze lub/i stacjach roboczych umożliwiające Użytkownikowi korzystanie z Systemu (np. system operacyjny).

Błąd aplikacji - Oznacza działanie powtarzalne, pojawiające się za każdym razem w tym samym miejscu w Aplikacji i prowadzące w każdym przypadku do otrzymywania błędnych wyników jej działania.

Dokumentacja Użytkownika - oznacza dostarczany Zamawiającemu materiał objaśniający sposób i zasady prawidłowego korzystania z Systemu.

4


Błąd blokujący (Very High) – usterka powodująca całkowite zatrzymanie Systemu albo uniemożliwiająca korzystanie przez Zamawiającego z Funkcji Podstawowych Systemu, występująca na każdej stacji roboczej skonfigurowanej do pracy z Systemem i dotycząca każdego użytkownika indywidualnego Systemu.

Błąd krytyczny (High) – usterka uniemożliwiająca korzystanie przez Zamawiającego z Funkcji Krytycznych Systemu lub powodująca nieprawidłowe przetwarzanie danych przez System w zakresie Funkcji Krytycznych występująca na każdej stacji roboczej, skonfigurowanej do pracy z Systemem.

Usterka – nie będąca Błędem Krytycznym albo Błędem Blokującym, niezdolność pracy Systemu zgodnie z Dokumentacją Użytkownika, zgłoszona przez Zamawiającego, a wcześniej zweryfikowana wstępnie pod kątem zasadności, która występuje na każdej Stacji Roboczej

Wdrożenie - szereg uporządkowanych i zorganizowanych działań mających na celu wprowadzenie do użytkowania przez Zamawiającego opisanych w niniejszym dokumencie modułów oprogramowania.

Funkcje krytyczne – funkcje Systemu dotyczące szczególnie istotnych (krytycznych) funkcjonalności Systemu. Należą do nich funkcje:I. w zakresie systemu HIS :

• zlecenia leków na pacjenta • wydanie leków na oddział • Wydanie leków pacjentowi • Wypisanie recepty pacjentowi • Przekazanie e-recepty do systemu P1 • Przyjęcie pacjenta i rejestracja wykonanych procedur • Zlecanie badań • Przekazanie wyników badań

II. w zakresie e-usług • logowania pacjenta do portalu • rejestracja pacjenta do poradni • odbiór wyników badań

III. w zakresie systemu ERP • dekretacja zapisów księgowych • realizacja wypłat wynagrodzeń

Funkcje podstawowe - wyliczone funkcje Systemu niezbędne do prawidłowego korzystania z Systemu zgodnie z jego przeznaczeniem. Należą do nich funkcje:

• logowanie do Systemu;• przyjęcie pacjenta;• przeniesienie pacjenta;• wypis pacjenta (z wyłączeniem funkcjonalności wydruku karty wypisowej);• rejestracja zgonu.

Funkcjonalność - wydzielony fragment Systemu pozwalający na realizację przez Użytkownika czynności wprowadzania, przechowywania, zmiany lub przeglądania danych. Zakres oraz sposób realizacji czynności w ramach danej funkcjonalności opisuje Dokumentacja Użytkownika.

Łącze serwisowe – połączenie teleinformatyczne, wraz z koniecznym sprzętem i oprogramowaniem, umożliwiające zdalne połączenie z serwerami i systemami Zamawiającego oraz podjęcie działań serwisowych Systemu z siedziby Wykonawcy.

Obejście – dostarczone przez Wykonawcę rozwiązanie zgłoszenia serwisowego (Błędu blokującego/ Błędu krytycznego) umożliwiające korzystanie z funkcjonalności, której dotyczyło zgłoszenie, w sposób inny od standardowego. W przypadku dostarczenia Obejścia, od momentu jego udostępnienia status zgłoszenia zostaje obniżony o jeden poziom.

5


Określenie przedmiotu zamówienia

Przedmiotem zamówienia jest:

1. Rozbudowa /dostawa Modułów Zintegrowanego Szpitalnego Systemu Informatycznego (HIS) wraz z bezterminowymi licencjami płatnymi jednorazowo na użytkowanie systemu spełniającego wymagania funkcjonalne i pozafunkcjonalne określone w Specyfikacji Istotnych Warunków Zamówienia (SIWZ) w zakresie następujących modułów:

a. Apteka Centralna oraz Moduł Obsługi Przetargów b. Recepty c. Rehabilitacja d. Laboratorium e. Sterylizatorniaf. Integracja HL7 pomiędzy modułami szpitalnymig. System Informacji Menadżerskiej

i. Raporty Zarządcze dla Kierownictwa - obszar statystyka, rozliczenia, finansowe, kadrowe).

ii. System BI 2. Dostawa systemu ERP wraz z bezterminowymi licencjami płatnymi jednorazowo na użytkowanie

systemu spełniającego wymagania funkcjonalne i pozafunkcjonalne określone w Specyfikacji Istotnych Warunków Zamówienia (SIWZ) (cześć szara) w zakresie następujących modułów :

a. Finanse i Księgowość (wraz z Rejestrem Zakupów, Kasą i Windykacją)b. Rejestr Sprzedażyc. Gospodarka materiałowad. Środki Trwałe oraz Wyposażenie (wraz obsługą kolektora danych)e. Kadry i Płace

3. Dostawa systemu Archiwum Elektronicznej Dokumentacji Medycznej Elektroniczna Dokumentacja Medyczna (EDM) wraz z bezterminowymi licencjami płatnymi jednorazowo na użytkowanie systemu spełniającego wymagania funkcjonalne i pozafunkcjonalne określone w Specyfikacji Istotnych Warunków Zamówienia

4. Dostawa systemu/portalu realizującego e-usługi określone w Specyfikacji Istotnych Warunków Zamówienia to jest:

a. e-Wynikib. e-dokumentacjac. e-Wywiad d. e-Kontrahente. e-Obchód

5. Dostawa systemu obiegu dokumentów elektronicznych (EOD) raz z bezterminowymi licencjami płatnymi jednorazowo na użytkowanie systemu spełniającego wymagania funkcjonalne i pozafunkcjonalne określone w Specyfikacji Istotnych Warunków Zamówienia

6. Dostawa silnika bazy danych w oparciu o które to oprogramowanie ma działać system HIS wraz z niezbędną liczbą licencji do pracy wyżej wymienionego oprogramowania na serwerach dostarczanych w ramach zamówienia oraz migracja danych z obecnego silnika bazy danych SYBASE dla systemu CliniNet firmy CGM obecnie użytkowanego przez Zamawiającego.

7. Dostawa oprogramowania systemowego 8. Instalacja, wdrożenie, konfiguracja i uruchomienie w/w oprogramowania na dostarczanym sprzęcie

informatycznym. 9. Szkolenia personelu Zamawiającego z obsługi w/w oprogramowania aplikacyjnego oraz

oprogramowania bazodanowego, systemów operacyjnych serwerów

6


10. Przeniesienie danych z obecnie użytkowanego przez Zamawiającego oprogramowania w zakresie umożliwiającym zachowanie ciągłości pracy Zamawiającego to jest:

System FK, Środki Trwałe, Gospodarka Magazynowa firmy SAGE Kadry i płace firmy Asseco WF-GANG

11. Dostawa sprzętu komputerowego zgodnie z wymaganiami określonymi w SIWZ

Oferowany system informatyczny musi działać zgodnie z następującymi aktami prawnymi i ich późniejszymi aktualizacjami oraz aktami normatywnymi niższego rzędu wydanymi na ich podstawie

1. Ustawy z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz. U. z 2019 r. poz.

1127, 1128.)2. Ustawy z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz. U. z 2019 r. poz. 408,

730)3. Ustawy z dnia 5 grudnia 1996 r. o zawodach lekarza i lekarza dentysty (Dz. U. z 2018 r. poz. 617);4. Ustawa z dnia 15 lipca 2011 r. o zawodach pielęgniarki i położnej (Dz. U. 2018 r. poz. 123 z późn. zm.);5. Ustawa z dnia 15 kwietnia 2011 r. o działalności leczniczej (Dz. U. z 2018 r. poz. 160 z późn. zm.);6. Ustawy z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz. U. z 2018 r. poz. 1000);7. Ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania

publiczne (Dz. U. z 2017 r. poz. 570 z poźń. zm.);8. Ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz. U. z 2017 r. poz. 1219, tj. z

późn. zm.);9. Ustawy z dnia 5 września 2016 r. o usługach zaufania, identyfikacji elektronicznej (Dz. U. poz. 1579 z

późn. zm.);10. Rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 910/2014 w sprawie identyfikacji

elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE (Dz. Urz. UE C z 2012 r.);

11. Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych)

12. Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. z 2017 r., poz. 2247);

13. Rozporządzeniem Ministra Zdrowia z dnia 9 listopada 2015 r. w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania

14. Rozporządzeniem Ministra Zdrowia z dnia 8 maja 2018 r. w sprawie rodzajów elektronicznej dokumentacji medycznej

W okresie gwarancji Wykonawca zobowiązuje się dostosować system do zmian przepisów prawa w ramach kwoty ustalonej w umowie będącej efektem tego postępowania w terminie uzgodnionym z Zamawiającym nie zakłócającym jego pracy jednak nie dłuższym niż 90 dni. W szczególności zobowiązuje się do dostosowania systemu do wymiany informacji z systemami centralnymi projektowanymi w ramach Ustawy o Systemie Informacji w Ochronie Zdrowia.

Opis stanu bieżącego Zamawiający użytkuje obecnie system klasy HIS (Hospital Information System) o nazwie CGM

CLININET, którego producentem jest CompuGroup Medical Polska sp. z.o.o. (CGM)

7


Lista modułów posiadanych przez Zamawiającego HIS - CliniNET: 1) Izba przyjęć2) Oddział3) Poradnia 4) Diagnostyka5) Blok Operacyjny6) Administracja7) Recepcja 8) Umowy9) STER-Rozliczenia

System jest uruchomiony i wdrożony w następujących lokalizacjach Zamawiającego - Szpital w Ostródzie S.A ul. Wł. Jagiełły 1 Ostróda

Na bieżąco jest wykorzystywany przez następujące kategorie użytkowników:

Kategoria użytkowników Liczba użytkownikówLekarze 83Pielęgniarki 165Pracownicy rozliczeń 10Administratorzy 2Pozostali użytkownicy 20

Zamawiający w zakresie systemu Finansowo Księgowego wykorzystuje system Symfonia w zakresie programu Kadry i Płace system WF-GANG

Harmonogram prac projektowych Projekt podzielony będzie na następujące etapy:

Etap I - Analiza przedwdrożeniowa - w terminie nie dłuższym niż 90 dni kalendarzowych od podpisania umowy. Etap będzie zawierał następujące elementy:

Uruchomienie projektu po stronie Wykonawcy w terminie 7 dni od podpisania umowy, Przedstawienie szczegółowego harmonogramu prac projektowych (do 14 dni od podpisania umowy), Powołanie struktury projektowej po stronie Wykonawcy i przedstawienie jej Zamawiającemu do 10

dni od podpisania umowy, Opracowanie przy współpracy z Zamawiającym szczegółowych zasad organizacji i zarządzania

Projektem do 30 dni od podpisania umowy, Opracowanie dokumentu analizy przedwdrożeniowej Odbiór etapu - podpisanie protokołu odbioru.

Etap II - Dostawa i instalacja sprzętu zakupionego w ramach projektu w terminie nie dłuższym niż 120 dni od podpisania umowy. Etap będzie obejmował następujące elementy:

Dostawa, instalacja i konfiguracja następującego sprzętu informatycznego:

Wyszczególnienie Liczba sztuk Serwery typ 1 4Serwery typ 2 2Macierz dyskowa 1UPS 3Switch dostępowy 3FireWall 1

8


Dostawa następujących licencji oprogramowania firm trzecich tzn. oprogramowania gotowego, oprogramowania związanego nieodłącznie z dostarczanym sprzętem:

Wyszczególnienie Liczba sztuk Oprogramowanie bazy danych 1Oprogramowanie systemowe 4Oprogramowanie do wirtualizacji 3

Odbiór etapu II – podpisanie protokołu odbioru.

Etap III - Wykonanie, dostawa i zainstalowanie oprogramowania aplikacyjnego i przeszkolenie użytkowników, dostarczenie dokumentacji - w terminie nie dłuższym niż 240 dni od podpisania umowy. Etap będzie obejmował następujące zagadnienia:

Wyszczególnienie Liczba sztuk Typ licencji SYSTEM HIS Apteka Centralna oraz Moduł Obsługi Przetargów : W tym Apteka CentralnaApteczki oddziałowe Moduł Obsługi przetargów

3

111

Licencja na moduł

Recepty 1 Licencja na modułRehabilitacja 1 Licencja na modułLaboratorium 1 Licencja na modułSterylizatornia 1 Licencja na modułIntegracja HL7 pomiędzy modułami szpitalnymi 2 Licencja na integrację 2

systemów SYSTEM ADMINISTRACYJNY ERP Finanse i Księgowość (wraz z Rejestrem Zakupów, Kasą i Windykacją) 3 Licencja na

równoległych użytkowników

Rejestr Sprzedaży 2 Licencja na równoległych

użytkownikówGospodarka materiałowa 2 Licencja na


Środki Trwałe oraz Wyposażenie (wraz obsługą kolektora danych) 2 Licencja na równoległych

użytkownikówKadry i płace 2 Licencja na


Elektroniczna Dokumentacja Medyczna (EDM) Archiwum Elektronicznej Dokumentacji Medycznej 1 Licencja na modułModuł integracji z P1 elektroniczna karta informacyjna z wizyty (dokumenty HL7 CDA , skierowania, , recepty )

1 Licencja na moduł

e-USŁUGI e-Rejestracja - dostosowanie do WCAG 2.0 1 licencja otwartae-Wyniki 1 licencja otwartae-dokumentacja 1 licencja otwartae-Wywiad 1 licencja otwartae-Kontrahent 1 licencja otwartae-Obchód 1 licencja otwartaSYSTEM INFORMACJI MENADŻERSKIEJ

9


Raporty Zarządcze dla Kierownictwa - obszar statystyka, rozliczenia, finansowe, kadrowe).

1 Licencja na moduł

System BI 1 Licencja na modułSystem Elektronicznego Obiegu Dokumentów 1 Licencja na moduł

Etap kończy się ostatecznym odbiorem systemu. Na koniec etapu Wykonawca dostarczy wymaganą dokumentację systemu, to jest:

Dokumentacja powykonawczą; Procedury eksploatacyjne; Procedury serwisowe; Dokumentacja użytkownika; Dokumentację administratora.

Wymagania dotyczące wdrożenia

1. Dostawa i instalacja modułów oprogramowania jest zadaniem, mającym na celu dostarczenie licencji, instalację i wdrożenie modułów oprogramowania, które będą uzupełnieniem i poszerzeniem posiadanego przez Zamawiającego systemu o dodatkowe funkcjonalności.

2. Zamawiający wymaga pełnej wzajemnej interoperacyjności nowo wdrażanych modułów oraz zachowania pełnej interoperacyjności z modułami oprogramowania już funkcjonującymi u Zamawiającego.

3. Wykonawca zobowiązany jest do dostarczenia dokumentacji technicznej dla dostarczanych modułów oprogramowania.

4. Wykonawca zobowiązany jest do dostarczenia dokumentacji dla administratora wraz z opisem procedury instalacji i aktualizacji modułów.

5. Dostawca musi zagwarantować dostarczenie dokumentacji użytkowej, systemowej i instalacyjnej, zgodnej ze stanem faktycznym.

6. Zamawiający wymaga aby wszystkie moduły i elementy oferowanego oprogramowania zostały dostarczone w najnowszych opublikowanych wersjach.

7. Zamawiający wymaga, aby wszystkie moduły oferowanego oprogramowania miały interfejs graficzny.

8. Zamawiający wymaga, aby wszystkie dostarczane moduły oferowanego oprogramowania pracowały w posiadanym przez Zamawiającego środowisku graficznym MS Windows na stanowiskach użytkowników (Windows 7, Windows 8, Windows 10).

9. Wszystkie dostarczone produkty i komponenty podlegają usłudze instalacji, konfiguracji i wdrożenia.

10. Usługi instalacji, konfiguracji i wdrożenia Wykonawca przeprowadzi zgodnie z zapisami niniejszego Opisu Przedmiotu zamówienia w uzgodnieniu z Zamawiającym oraz najlepszymi praktykami w projektach informatycznych.

11. Wszystkie nazwy własne oprogramowania i sprzętu użyte w opisie przedmiotu zamówienia należy traktować, jako określenie standardów parametrów technicznych, użytkowych, funkcjonalnych i jakościowych oczekiwanych przez Zamawiającego i należy odczytywać wraz z wyrazami „lub równoważne”.

12. Zamawiający dopuszcza zastosowanie przez Wykonawcę rozwiązań równoważnych rozwiązaniom wskazanym w opisie przedmiotu zamówienia.

13. Wykonawca oferując rozwiązanie równoważne do opisanego w specyfikacji jest zobowiązany wykazać równoważność w zakresie parametrów technicznych, użytkowych, funkcjonalnych i jakościowych, które muszą być spełnione na poziomie nie niższym niż parametry wskazane przez Zamawiającego.

10


14. Projekt będzie realizowany w oparciu przedstawiony przez Wykonawcę i zaakceptowany przez Zamawiającego Harmonogram wdrożenia zgodnie z etapami wyznaczonymi przez Umowę i OPZ.

15. Wykonawca w harmonogramie wdrożenia musi uwzględnić w szczególności podział na zadania takie jak analiza przedwdrożeniowa, dostawy, instalacja, testowanie, wdrożenie, szkolenie i odbiory.

16. Wykonawca umożliwi Zamawiającemu udział we wszystkich pracach realizowanych przez Wykonawcę w ramach realizacji przedmiotu zamówienia (m.in. w czasie instalacji, konfiguracji i wdrożenia).

17. Wykonawca zobowiązany jest do wykonania przedmiotu zamówienia z należytą starannością, efektywnością oraz zgodnie z najlepszą praktyką i wiedzą zawodową.

18. Wykonawca zobowiązany jest do wykonania w całości przedmiotu zamówienia w zakresie określonym w opisie przedmiotu zamówienia.

19. Wykonawca zobowiązany jest do dokonania z Zamawiającym wszelkich koniecznych ustaleń mogących wpłynąć na przedmiot zamówienia i sposób jego realizacji oraz ciągłą współpracę z Zamawiającym na każdym etapie wykonania przedmiotu zamówienia.

Analiza przedwdrożeniowaWykonawca zobowiązany jest do przeprowadzenia Analizy Przedwdrożeniowej. Zamawiający wymaga, aby:

1. Analiza Przedwdrożeniowa została opracowana w oparciu o Opis Przedmiotu Zamówienia (OPZ), Harmonogram wdrożenia oraz funkcjonalności i procesy będące w standardzie oferowanego Systemu.

2. Wykonawca przekaże Zamawiającemu Analizę Przedwdrożeniową w formie elektronicznej (.pdf, .doc /.docx), a ponadto przedstawi jej założenia w formie prezentacji w siedzibie Zamawiającego. Prezentacja musi objąć swoim zakresem co najmniej elementy wskazane w pkt.3 niniejszego rozdziału.

3. Analiza Przedwdrożeniowa zawierała co najmniej:1) szczegółowy opis oraz harmonogram dostawy i wdrożenia, w tym:

a) metodykę zarządzania Projektem;b) szczegółowy harmonogram dostawy;c) szczegółowy harmonogram wdrożenia;

2) wykaz procesów realizowanych przez Zamawiającego poddanych analizie przedwdrożeniowej oraz opis ich realizacji w oferowanym Systemie;

3) opis w jaki sposób funkcjonalności wymagane w OPZ będą realizowane w oferowanym Systemie;4) założenia integracji wewnętrznej i integracji zewnętrznej z systemami wraz ze specyfikacją

funkcjonalną usług integracyjnych i identyfikacją punktów styku,5) wykaz oraz szczegółowy opis wykonania niezbędnych prac związanych z instalacją, dostosowaniem,

modyfikacją i parametryzacją oferowanego Systemu;6) założenia konfiguracji i parametryzacji oferowanego Systemu;7) analizę środowiska technicznego oraz funkcjonalnego systemów informatycznych funkcjonujących

u Zamawiającego i procesów obsługiwanych przez te systemy;8) diagnoza oraz identyfikacja przewidzianych do wytworzenia produktów w ramach realizacji

przedmiotu zamówienia,9) wykaz licencji na System i jego komponenty oraz na oprogramowanie narzędziowe,10)zakres i tematykę szkoleń stanowiskowych z funkcjonowania oferowanego Systemu,11)podejście do testów oraz scenariusze testów funkcjonalnych i testów wydajności wdrożonego

Systemu,12)plan komunikacji stron oraz zasady zgłaszania błędów,13)skład zespołu wdrożeniowego z podziałem na role i zadania poszczególnych członków zespołu.

4. Wykonawca dokona uzgodnień dotyczących integracji systemów obecnie eksploatowanych przez Zamawiającego z oferowanym Systemem wraz ze szczegółowym harmonogramem prac integracyjnych. Uzgodnienia zostaną przedstawione w formie dokumentu zawierającego: 1) zakres i sposób integracji poszczególnych komponentów oferowanego Systemu,

11


2) zakres scenariuszy testowych integracji.

Warunki licencyjne1. Wszystkie dostarczone licencje nie mogą nakładać ograniczeń czasowych na prawo do użytkowania

oprogramowania.

2. Wykonawca zobowiązany jest udzielić licencji na czas nieokreślony z minimum 5. letnim okresem wypowiedzenia na wszystkie moduły dostarczanego oprogramowania. Udzielane licencje mogą być licencjami niewyłącznymi.

3. Udzielona licencja otwarta musi umożliwiać Zamawiającemu przygotowanie nieograniczonej liczby kont użytkownika w systemie, nie może wprowadzać ograniczenia na jednoczesny dostęp i tzw. „nazwanych użytkowników”.

4. Udzielona licencja na moduł musi umożliwiać Zamawiającemu przygotowanie nieograniczonej liczby kont użytkownika w systemie u musi umożliwiać pracę do 100 jednocześnie zalogowanych użytkowników w systemie. Licencja nie może wprowadzać ograniczenia na dostęp tzw. „nazwanych użytkowników”.

5. Licencje obejmą również wszelkie nowe wersje, poprawki i aktualizacje systemu pojawiające się w trakcie obowiązywania umowy, a także w okresie gwarancji.

6. Wykonawca przekaże Zamawiającemu dokument licencyjny dla oferowanych modułów oprogramowania. Przekazanie licencji jest warunkiem koniecznym do otrzymania przez Wykonawcę Ostatecznego odbioru.

7. Dla oprogramowania wymagającego licencji obcych, niebędącego własnością Wykonawcy, ma on dostarczyć oryginalne nośniki, dokumentację, licencje oraz wszelkie inne składniki dołączone do oprogramowania przez jego producenta.

8. Licencje muszą być wystawione na Zamawiającego, a Wykonawca dopełni wszystkich formalności wymaganych prawem, licencją i innymi wymogami producenta zapewniających, że Zamawiający będzie pełnoprawnym użytkownikiem dostarczonego oprogramowania.

9. Wykonawca oświadcza, że przysługują mu prawa do udzielania licencji/sublicencji lub posiada nadane przez autora oprogramowania aplikacyjnego prawo do udzielania licencji/sublicencji na użytkowanie tego programowego usługowego rozwiązania informatycznego i udzieli Zamawiającemu takich licencji/sublicencji.

10. Zamawiający ma prawo do przygotowywania kopii modułów oprogramowania aplikacyjnego, które są niezbędne do zapewnienia bezpieczeństwa działania tych modułów.

11. Zamawiający nie ma prawa do sprzedaży, odsprzedaży, wypożyczania, użyczania, powielania, odstępowania lub rozpowszechniania w innej formie, zmieniania, dekompilacji, tłumaczenia oprogramowania aplikacyjnego.

12. Zamawiający nie ma prawa do usuwania bądź zmiany znaków handlowych i informacji o Wykonawcy bądź producencie podanym w oprogramowaniu aplikacyjnym i materiałach towarzyszących.

13. Zamawiający ma prawo do rozpowszechniania bez ograniczeń rezultatów wykonywania oprogramowania aplikacyjnego oraz danych i zestawień utworzonych za jego pomocą.

Zasady gwarancjiGwarancja w zakresie wdrożonego systemu informatycznego

1. Wykonawca musi zapewnić świadczenie dla oferowanych modułów usług gwarancyjnych, przez okres zaoferowany przez Wykonawcę w ofercie, jednak nie krótszy niż min. 36 miesięcy, liczonych od momentu pozytywnego odbioru końcowego potwierdzonego podpisaniem Protokołu końcowego.

12


2. Zamawiający wymaga, aby Wykonawca posiadał aplikację internetową do przyjmowania i obsługi zgłoszeń, będącej podstawą komunikacji między Zamawiającym i Wykonawcą w zakresie zgłoszeń. Aplikacja musi posiadać możliwość wysyłania powiadomień na temat zgłoszeń na podany adres e-mail oraz musi posiadać możliwość generowania raportów związanych ze zgłoszeniami.

3. Usuwanie błędów oprogramowania aplikacyjnego będzie realizowane przy następujących parametrach usługi.

a. Gwarantowany czas reakcji na Błędy blokujące - 2 godziny robocze

b. Gwarantowany czas reakcji na Błędy krytyczne - 4 godziny robocze

c. Gwarantowany czas reakcji na usterki - 8 godzin roboczych

d. Gwarantowany czas naprawy Błędów blokujących - 8 godzin roboczych

e. Gwarantowany czas naprawy Błędów krytycznych - 24 godzin roboczych

f. Gwarantowany czas naprawy Usterki- 160 godzin roboczych

4. Zamawiający dopuszcza rozwiązanie błędu blokującego lub krytycznego przez zastosowanie rozwiązania tymczasowego (tzw. obejście). Rozwiązanie tymczasowe musi zostać uruchomione w okresie przewidzianym na naprawę danego typu błędu, a następnie błąd musi zostać rozwiązany w 7 dni od zgłoszenia.

5. Czas usunięcia awarii zostaje automatycznie wydłużony o czas przetwarzania na komputerze, jeżeli czas ten przekracza 8 (osiem) godzin (np. archiwizacja lub kopiowanie baz danych. Zamawiający wymaga, aby Wykonawca posiadał aplikację internetową do przyjmowania i obsługi zgłoszeń, będącej podstawą komunikacji między Zamawiającym i Wykonawcą w zakresie zgłoszeń. Aplikacja musi posiadać możliwość wysyłania powiadomień na temat zgłoszeń na podany adres e-mail oraz musi posiadać możliwość generowania raportów związanych ze zgłoszeniami.

6. Wymagany zakres usług gwarancyjnych w zakresie wdrożonych modułów oprogramowania/systemu, to:1) gotowość Wykonawcy do usuwania błędów wdrożonego oprogramowania,2) wprowadzanie zmian w oprogramowaniu w zakresie dotyczącym istniejących funkcjonalności,

objętych umową, w zakresie wymaganym zmianami powszechnie obowiązujących przepisów prawa lub przepisów prawa wewnętrznie obowiązujących Zamawiającego, wydanych na podstawie delegacji ustawowej,

3) zagwarantowanie prowadzenia rejestru zgłaszanych przez użytkowników błędów wdrożonego oprogramowania,

4) wprowadzanie do oprogramowania nowych funkcji oraz usprawnień już istniejących, stanowiących wynik zaakceptowanych przez Wykonawcę sugestii użytkowników Zamawiającego,

5) wprowadzanie do oprogramowania zmian stanowiących konsekwencję wejścia w życie nowych aktów prawnych lub aktów prawnych zmieniających obowiązujący stan prawny, opublikowanych w postaci ustaw, rozporządzeń, itp.

6) wprowadzanie do oprogramowania aplikacyjnego zmian wymaganych przez wyszczególnione organizacje, w stosunku do których Zamawiający ma obowiązek prowadzenia sprawozdawczości: Ministerstwa Zdrowia, NFZ, Urzędu Wojewódzkiego,

7) wprowadzanie w trybie pilnym do oprogramowania zmian i poprawek usuwających stwierdzone błędy i luki we wbudowanych mechanizmach i funkcjach zabezpieczeń,

8) gotowość do odpłatnego wykonania na zlecenie Zamawiającego zaproponowanych przez niego modyfikacji we wdrożonym oprogramowaniu.

7. Wykonawca w szczególności musi dostosować oferowane oprogramowanie do wymiany informacji z systemami centralnymi projektowanymi w ramach Ustawy o Systemie Informacji w Ochronie Zdrowia (P1, P2).

8. Wykonawca w czasie gwarancji musi przekazać bezpłatnie Zamawiającemu nowe wersje systemu, jeżeli będzie to związane z podniesieniem jakości i funkcjonalności oprogramowania lub usuwających wykryte przez Wykonawcę błędy w działaniu oprogramowania.

13


9. Gwarancja musi polegać na dostosowaniu parametrów systemu oraz zmieniających się potrzeb zamawiającego metod i sposobów przeliczania i prezentacji danych oraz innych zaawansowanych czynności administracyjnych wymagających wiedzy merytorycznej i informatycznej w danej dziedzinie systemu, naprawa błędów powstających podczas pracy użytkowników, których nie obejmuje gwarancja dla systemu, tworzenie zaawansowanych zestawień.

Gwarancja w zakresie infrastruktury serwerowej, oprogramowania systemowego i narzędziowego

1. Wykonawca musi zapewnić świadczenie dla oferowanej infrastruktury serwerowej, oprogramowania systemowego i narzędziowego usług gwarancyjnych przez okres 36 miesięcy, liczony od momentu pozytywnego odbioru końcowego potwierdzonego podpisaniem Protokołu końcowego.

2. Dla sprzętu określonego jako serwer:1) w przypadku awarii dysków twardych dysk pozostaje u Zamawiającego,2) czas przystąpienia do naprawy gwarancyjnej - do końca następnego dnia roboczego,

3) Wykonawca naprawę gwarancyjną musi świadczyć w miejscu instalacji urządzenia,4) Wykonawca musi zapewnić możliwość szybkiego zgłaszania usterek przez portal internetowy,5) Zamawiający wymaga aby Wykonawca zapewnił opiekę kierownika technicznego ds. Eskalacji,6) dostępność wsparcia technicznego przez 24 godziny 7 dni w tygodniu przez cały rok,7) dostęp do portalu technicznego producenta, który umożliwi zamawianie części zamiennych i/lub

wizyt technika serwisowego, mający na celu przyśpieszenie i procesu diagnostyki i skrócenia czasu usunięcia usterki,

8) szybkie wsparcie telefoniczne świadczone przez wyszkolonych inżynierów, a nie przez call center bazujące na skryptach rozmów telefonicznych,

9) w przypadku wystąpienia usterki wsparcie techniczne ma rozwiązywać problemy z fabrycznie zainstalowanym oprogramowaniem,

10) w przypadku wystąpienia usterki wymagana jest natychmiastowa reakcja wsparcia technicznego (diagnostyka zaraz po wystąpieniu awarii).

3. Dla sprzętu określonego jako switch dostępowy sieci:1) gwarancja czasu życia (Limited Lifetime warranty) obejmująca:

a) przełącznik,b) zasilacze i wiatraki,c) moduły SFP, SFP+ i QSFP+,d) bezterminowy dostęp do nowych wersji oprogramowania,

2) czas przystąpienia do naprawy gwarancyjnej do następnego dnia roboczego od przyjęcia zgłoszenia,

3) możliwość zgłaszania awarii w trybie 24x7x365 poprzez ogólnopolską linię telefoniczną producenta.

4. Dla sprzętu określonego jako macierz dyskowa:1) czas przystąpienia do naprawy gwarancyjnej do następnego dnia roboczego od przyjęcia

zgłoszenia, 2) możliwość zgłaszania awarii w trybie 365x7x24 poprzez ogólnopolską linię telefoniczną

producenta,3) możliwość sprawdzenia statusu gwarancji poprzez stronę producenta podając unikatowy numer

urządzenia, 4) w przypadku awarii dysków twardych dysk pozostaje u Zamawiającego,5) Wykonawca ponosi koszty napraw gwarancyjnych, włączając w to koszt części I transportu.6) W czasie obowiązywania gwarancji Wykonawca zobowiązany jest do udostępnienia

Zamawiającemu nowych wersji BIOS, firmware i sterowników (na płytach CD lub stronach internetowych).

5. Dla sprzętu określonego jako Firewall Zamawiający wymaga wsparcia technicznego dla zaoferowanej gwarancji w trybie 24 godziny 7 dni w tygodniu przez cały rok

14


Przebieg wdrożeniaWymagania ogólne

1. Uruchomienie produkcyjne musi zostać poprzedzone przeprowadzeniem przez Wykonawcę szkoleń.

10. Przed przystąpieniem do szkoleń Wykonawca uruchomi kopię testową oferowanego rozwiązania programowego, tak by umożliwić jego administratorom i użytkownikom testowanie funkcjonalności dostarczanego rozwiązania.

11. Przygotowania w grupach muszą odbywać się w podziale na moduły i grupy zawodowe, a tym samym w podziale na poszczególną funkcjonalność oprogramowania aplikacyjnego.

12. Czas przygotowań dla danego modułu i danej grupy zawodowej musi uwzględniać stopień złożoności oprogramowania aplikacyjnego.

13. Dla przeprowadzenia szkoleń Wykonawca nieodpłatnie zapewni 12 stanowisk roboczych (stacje komputerowe/laptopy). Zamawiający zapewni odpowiednie pomieszczenie wraz z infrastrukturą transmisji danych umożliwiającą dostęp do oprogramowania aplikacyjnego. Odpowiedzialność za przygotowanie stanowisk do przeprowadzenia przygotowania leży po stronie Wykonawcy.

14. Każdy cykl szkoleń należy musi zostać zakończony ćwiczeniem sprawdzającym wiedzę uzyskaną podczas przygotowania oraz podpisaniem protokołu z realizacji szkolenia, zawierającym: czas trwania przygotowania, jego zakres merytoryczny, wykaz osób objętych tym przygotowaniem. Protokół musi być podpisany przez osoby odpowiedzialne za przygotowanie i osoby objęte tym przygotowaniem.

15. Wykonawca po zawarciu umowy dostarczy harmonogram przygotowań administratorów i użytkowników do akceptacji Zamawiającego.

Wdrożenie modułów oprogramowania aplikacyjnego1. Wdrożenie musi obejmować oprogramowanie aplikacyjne wskazane w SIWZ.

2. W zakres usług wdrożeniowych wchodzić muszą w szczególności:1) przeprowadzenie analizy przedwdrożeniowej,2) instalacja oprogramowania aplikacyjnego,3) konfiguracja oraz parametryzacja oprogramowania aplikacyjnego,4) wdrożenie personelu obejmujące przeszkolenia w zakresie administracji i użytkowania

oprogramowania aplikacyjnego,5) opracowanie planu testów i scenariuszy testów akceptacyjnych oprogramowania aplikacyjnego,6) przeprowadzenie testów akceptacyjnych według opracowanego planu i scenariuszy

oprogramowania aplikacyjnego.

3. Zamawiający oczekuje dostarczenia kompletnego oprogramowania aplikacyjnego usług elektronicznych, tj. zawierającego wszystkie składniki wymagane do jego zainstalowania, wdrożenia i eksploatacji – w tym systemy operacyjne i bazodanowe jeśli to konieczne.

16. Zamawiający nie przewiduje pośredniczenia w rozmowach z firmami trzecimi dotyczących integracji z ich systemami. Koszty integracji są częścią kosztu oferty składanej przez Wykonawcę w niniejszym postępowaniu.

17. Wykonawca musi zapewnić zgodność oprogramowania aplikacyjnego z wymaganiami prawnymi dotyczącymi prowadzenia Elektronicznej Dokumentacji Medycznej.

18. Wykonawca przed zawarciem umowy musi dostarczyć wykaz dokumentów, których oczekuje od Zamawiającego do przeprowadzenia analizy przedwdrożeniowej.

19. Zamawiający wymaga, aby moduły oprogramowania aplikacyjnego, wdrożone przez Wykonawcę w ramach realizacji przedmiotu zamówienia, były wdrożone w pełnej ich funkcjonalności opisanej w SIWZ.

15


20. Instalacja i wdrożenie muszą odbywać się w godzinach pracy pracowników Zamawiającego tj. w dni robocze (od poniedziałku do piątku), w godz. 7:30-15:00. Zamawiający dopuszcza wykonywanie prac w innym czasie niż wskazany, po odpowiednim uzgodnieniu i jego akceptacji przez Zamawiającego.

21. Wdrażanie dostarczanego oprogramowania aplikacyjnego musi uwzględniać ciągłość funkcjonowania Zamawiającego i eksploatacji posiadanego przez niego systemu. Wszelkie przerwy w tym zakresie wynikające z prowadzonych przez Wykonawcę prac wdrożeniowych muszą zostać uzgodnione i zatwierdzone przez Zamawiającego.

22. Po zainstalowaniu i wdrożeniu oprogramowania aplikacyjnego muszą zostać spełnione:1) wymagania określone niniejszą SIWZ,2) uwzględnienie charakteru prowadzonej przez Zamawiającego działalności oraz spełnianie wymagań

obowiązujących przepisów prawa, w szczególności ustaw i rozporządzeń dotyczących:a) podmiotów objętych ustawą o działalności leczniczej,b) rozliczeń i sprawozdawczości do NFZ,c) rodzaju i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania,d) ochrony danych osobowych,e) informatyzacji podmiotów realizujących zadania publiczne,f) rachunkowości i sposobu liczenia kosztów u Zamawiającego,g) systemu informacji w ochronie zdrowia.

23. Zamawiający wymaga spełnienia następujących warunków przez wdrożone oprogramowanie aplikacyjne:1) zachowanie ciągłości obecnie posiadanych danych przez Zamawiającego2) zapewnienie możliwości wykonywania kopii zapasowych struktur danych w trakcie ich pracy,3) posiadanie sprawnego mechanizmu archiwizacji danych i mechanizmów gwarantujących spójność

danych. Wymagane jest wzajemne współdziałanie modułów systemu poprzez powiązania logiczne i korzystanie ze wspólnych danych przechowywanych na serwerach,

4) komunikaty systemowe i komunikacja z użytkownikiem w języku polskim,5) możliwość korzystania z rozbudowanych podpowiedzi.

24. Zamawiający wymaga od Wykonawcy przekazania przed podpisaniem Protokołu Odbioru Końcowego - bezusterkowego:1) 2 egzemplarzy aktualnej dokumentacji administratora w języku polskim w formie papierowej,2) 2 egzemplarzy aktualnej dokumentacji użytkownika w języku polskim w formie papierowej,3) 2 zestawów egzemplarzy dokumentacji administratora i użytkownika w formie elektronicznej, na

niezależnych nośnikach z aktywną blokadą zapisu na każdym z tych nośników, umożliwiającej Zamawiającemu wprowadzanie do niej korekt, zmian i uzupełnień.

Wymagania w zakresie szkoleń użytkowników: W ramach realizacji zamówienia Wykonawca przeszkoli użytkowników dostarczanych systemów z następujących zagadnień:

1) Szkolenia użytkowników systemów (personelu Zamawiającego) - przekazanie użytkownikom pełnej wiedzy niezbędnej do poprawnego użytkowania oprogramowania aplikacyjnego, potrzebną do wykonywania obowiązków służbowych na zajmowanym stanowisku pracy

2) Szkolenia dla administratorów systemów administrowanie oprogramowaniem aplikacyjnym oraz systemowym i eksploatację oprogramowania aplikacyjnego,

3) Szkolenia z zakresu systemu BI 4) przeszkolenie 2 osób z zakresu profilu IHE-XDS.b oraz HL7 CDA – czas szkolenia dwa dni.

Szkolenia dla użytkowników

16


W ramach szkoleń Wykonawca przekaże użytkownikom pełną wiedzę niezbędną do poprawnego użytkowania oprogramowania aplikacyjnego, potrzebną do wykonywania obowiązków służbowych na zajmowanym stanowisku pracy. Zakłada się przeszkolenie 120 osób. Każde szkolenie powinno trwać minimum 4 godz. a grupy szkoleniowe nie powinny być większe niż 12 osób. Szkolenia mają być przeprowadzone w siedzibie Zamawiającego w uzgodnionych terminach tak, by nie zakłóciły one bieżącej pracy. Dopuszczalne jest szkolenie poza siedzibą Zamawiającego, w takim przypadku Wykonawca ponosi koszty zakwaterowania uczestników szkolenia. Szkolenie ma wyczerpywać zakres funkcjonalności niezbędnych do realizacji zadań wynikających z ról pracowników/

Szkolenia dla administratorów

Zamawiający oczekuje, że Wykonawca przeszkoli 2 pracowników Zamawiającego z zagadnień technicznej administracji dostarczanymi systemami. Szkolenie powinno trwać minimum 16 godzin (2 dni roboczych) i obejmować całość zagadnień niezbędnych do samodzielnej administracji. W szczególności będzie ono obejmować: • Omówienie konfiguracji poszczególnych elementów systemu; • Procedurę tworzenia kopii awaryjnej i odtwarzania systemu. • Administrację użytkownikami • Administrację systemem

W ramach szkoleń dla administratorów Wykonawca przeszkoli 2 pracowników Zamawiającego z zagadnień administracji dostarczanym systemem bazy danych. Szkolenie powinno trwać minimum 3 dni robocze (24 godz.) W ramach szkoleń dla administratorów Wykonawca przeszkoli 2 pracowników Zamawiającego z zagadnień administracji dostarczanym urządzeniem FireWall /UTM . Szkolenie powinno trwać minimum 2 dni robocze (16 godz.)

Szkolenie z Systemu BI

Zamawiający oczekuje, że Wykonawca przeszkoli 6 użytkowników z zakresu oprogramowania do analiz danych Szkolenie powinno trwać min. 16 godzin (2 dni robocze) i będzie obejmować następujące zagadnienia:

Tworzenie, modyfikacja i współdzielenie analiz w tym: wybieranie kolumn do raportu, filtrowanie wyników, wybór metody prezentacji, zmiana domyślnych parametrów prezentacji,

Zarządzanie Zarządzanie uprawnieniami dostępu do raportów i pulpitów, Zarządzanie uprawnieniami dostępu do obiektów analitycznych, Zarządzanie uprawnieniami dostępu do danych, Elementy składowe modelu danych

Omówienie modelu danych w szczególności: Schematu danych Miar, wymiarów itp.

Szkolenia z zakresu profilu IHE-XDS.b oraz HL7 CDA

17


Zamawiający oczekuje, że Wykonawca przeszkoli 2 pracowników Zamawiającego z zagadnień profilu integracyjnego IHE-XDS.b oraz standardów HL7 CDA. Szkolenie powinno trwać minimum 16 godzin (2 dni roboczych) W szczególności będzie ono obejmować:

1. Wprowadzenie do standardu HL7 CDA2. Polska Implementacja Krajowa HL7 CDA3. Wymiana dokumentów medycznych zgodnie z profilem IHE XDS.b4. Wymiana dokumentów medycznych w ramach Systemu Informacji Medycznej

W przypadku szkoleń odbywających się poza miejscowością w której znajduje się siedziba Zamawiającego, Wykonawca pokryje koszty zakwaterowania i dojazdu uczestników. Odbycie szkolenia powinno być potwierdzone imiennym dokumentem/zaświadczeniem dla użytkowników. Grupy szkoleniowe nie mogą liczyć więcej niż 12 osób. Zamawiający może udostępnić salę szkoleniową. Wykonawca ma obowiązek zaplanować szkolenia i prowadzić ewidencję osób uczestniczących w szkoleniu. Wykonawca opracuje harmonogram szkoleń i uzgodni go z Zamawiającym. Zamawiający zastrzega sobie prawo do żądania, by szkolenia odbywały się poza normalnymi godzinami pracy (po 15.30).

Wymagania dotyczące opracowania planu testów i scenariuszy testów akceptacyjnych oraz przeprowadzenia według nich testów akceptacyjnych:

1. Dokumentacja testowa musi obejmować:1) plan testowania (Symbol dokumentu, Obiekt testowania, Cechy podlegające testowaniu, Cechy nie

podlegające testowaniu, Sposób wykonania testowania, Kryteria zaliczenia/nie zaliczenia testu, Kryteria zawieszenia i odwieszenia testu, Dokumenty i dane dostarczone w wyniku testowania, Zadania testowe, Wymagania środowiskowe, Odpowiedzialność, Harmonogram);

2) specyfikacje struktury testów (Symbol dokumentu, Cechy systemu podlegające testowaniu, Uszczegółowiony sposób testowania, Lista przypadków i procedur testowych, Kryteria zaliczenia i nie zaliczenia testu);

3) arkusze przypadków testowych (Symbol dokumentu, Zestaw danych wejściowych, Zestaw danych wyjściowych);

4) instrukcje wykonania testów (Symbol dokumentu, Cele przeprowadzenia procedury, Wymagania szczegółowe, Czynności podejmowane w ramach testu);

5) rejestry błędów;6) dzienniki wykonywania testów;7) raporty podsumowujące (Symbol dokumentu, Podsumowanie testów, Realizacja wymagań

środowiskowych, Statystyka wykonania, Zatwierdzenie dokumentu);8) protokół akceptacji;

25. Przed przystąpieniem do wykonywania testów, plany testów i scenariusze testów muszą zostać zaakceptowane przez Zamawiającego.

Wymagania dotyczące personelu Wykonawcy:1) wdrożenie muszą realizować osoby wymienione w ofercie Wykonawcy w Wykazie osób,2) Zamawiający wymaga, by prace instalacyjne i wdrożeniowe oraz przygotowania personelu

Zamawiającego przeprowadzały osoby posiadające doświadczenie w zakresie produktów, których dotyczyć będzie instalacja oraz wdrożenie,

3) osoby wykonujące prace instalacyjne i wdrożeniowe oraz realizujące przygotowania personelu Zamawiającego muszą być dyspozycyjne w trakcie trwania prac instalacyjnych, wdrożeniowych oraz szkoleń. Wymagany jest stały kontakt roboczy z Zamawiającym,

18


4) Wykonawca najpóźniej w dniu zawarcia umowy przekaże Zamawiającemu wykaz numerów telefonów kontaktowych do osób wykonujących prace instalacyjne, wdrożeniowe i szkolenia. Stały kontakt oznacza dyspozycyjność osób wykonujących prace instalacyjne i wdrożeniowe w trakcie trwania prac instalacyjnych i wdrożeniowych w godzinach pracy Zamawiającego tj. 7:30 do 15: 00

5) Zamawiający wymaga, by wszelkie zastępstwa lub trwała zmiana w osobach instalujących i wdrażających zgłaszana była niezwłocznie przez Wykonawcę, z zastrzeżeniem, że osoba zastępująca musi posiadać niemniejsze kwalifikacje niż osoba zastępowana. Zastępstwo lub trwała zmiana danej osoby wymaga akceptacji ze strony Zamawiającego.

Opis wymagań dla oprogramowania aplikacyjnego Głównym celem projektu jest dostosowanie zintegrowanego systemu HIS do prowadzenia

elektronicznej dokumentacji medycznej (EDM) zgodnie z wymogami ustawy o systemie informacji w ochronie zdrowia oraz udostępnienie e-usług dla pacjentów i personelu medycznego Powiatowego Zespołu Opieki Zdrowotnej w Ostródzie celem poprawy, jakości i dostępności świadczeń zdrowotnych na terenie powiatu Ostródzkiego. W ramach realizacji inwestycji planuje się uzyskanie następujących celów:

Zwiększenie dostępności usług zdrowotnych poprzez wdrożenie e-usług, które pozwolą na ich realizację niezależnie od miejsca zamieszkania, stopnia niepełnosprawności czy też płci pacjenta.

Polepszenie ciągłość opieki poprzez wdrożenie systemu do przechowywania elektronicznej dokumentacji medycznej, udostępnienie EDM personelowi szpitala oraz umożliwienie wymiany tej dokumentacji pomiędzy podmiotami leczniczymi w ramach systemów regionalnych i krajowych

Zwiększenie stopnia usamodzielnienia pacjentów poprzez uzyskanie dostępu do elektronicznej dokumentacji medycznej, wyników badań oraz e-usług wdrażanych w ramach projektu

Zwiększenie bezpieczeństwo pacjenta poprzez udostępnienie EDM personelowi medycznemu, co pozwoli na podejmowania decyzji klinicznych w oparciu o zgromadzone w niej dane

Zwiększenie, Jakość opieki i zadowolenia pacjenta poprzez możliwość realizacji e-usług z dowolnego miejsca

Osiągnięcie powyższych celów przyczyni się do: Poprawy, jakości udzielanych świadczeń; Poprawy dostępu do dokumentacji medycznej pacjenta (np. dane opisowe, liczbowe, obrazowe); Poprawy, jakości, kompletności gromadzonych danych; Zredukowania czasu potrzebnego na wypełnienie dokumentacji medycznej, wzrost czasu

poświęcanego pacjentowi; Zredukowania ilości papieru używanego do wytworzenia dokumentacji medycznej Zmniejszenia liczby błędów w dokumentacji medycznej; Skrócenia czasu rejestracji pacjenta; Zapewnienia bezpieczeństwa przechowywanych danych dotyczących stanu zdrowia pacjentów; Dostosowanie posiadanych przez Szpital rozwiązań informatycznych do wymogów Prawa

Rozbudowa systemu HIS o moduły niezbędne do kompleksowego dokumentowania i nadzoru procesu leczenia

Dla celów realizacji projektu niezbędny jest uzupełnienie zakresu posiadanych modułów systemu szpitalnego CliniNet tak by proces leczenia, rozliczeń i nadzoru mógł być w pełni wspierany przez system informatyczny W ramach projektu Wykonawca dostarczy następujące moduły:

Apteka Centralna oraz Moduł Obsługi Przetargów Recepty Rehabilitacja

19


Laboratorium Strylizatornia Raporty Zarządcze dla Kierownictwa - obszar statystyka, rozliczenia, finansowe, kadrowe). System BI

Uzupełnienie modułów Systemu HIS jest niezbędne by całościowo zrealizować dokumentowanie procesu leczenia i prowadzenia Elektronicznej Dokumentacji Medycznej (EDM) zgodnie z Rozporządzeniem w sprawie dokumentacji medycznej i będzie integrować wszystkie aplikacje medyczne w jeden organizm. Taki kompleksowy System HIS będzie stanowił podstawę do zasilenia Repozytorium Elektronicznej Dokumentacji Medycznej oraz uruchomienia e-usług publicznych świadczonych za pomocą e-Portalu. Zamawiający oczekuje by dostarczane moduły były zintegrowanie z użytkowanym systemem HIS w taki sposób by raz wprowadzone do systemu dane będą w nim widoczne na różnych poziomach i nie było konieczne wprowadzanie ich kilkukrotnie, czy przepisywanie do odseparowanych modułów.

Moduł Apteka Centralna

Stanowi kompleksowe rozwiązanie umożliwiające informatyzację wszystkich obszarów funkcjonalnych związanych z apteką szpitalną. Umożliwi prowadzenie dystrybucji leków na oddziały, notowanie zamówień i zakupów, zarządzanie magazynem, tworzenie zestawień, analiz oraz prowadzenie rozliczeń, wraz z wyznaczaniem kosztów zużycia leków na pacjenta i lekarza

Moduł powinien spełniać następujące wymagania:

Kod wymagania Opis wymagania

WYM.APT.001 Moduł działa w oparciu o przeglądarkę stron WWW będącą klientem końcowym aplikacji w architekturze trójwarstwowej na co najmniej dwóch wiodących przeglądarkach internetowych (minimum Mozilla Firefox), bez konieczności instalowania dodatkowych klientów terminalowych do tych przeglądarek, z identyczną funkcjonalnością na systemach Windows i Linux.

WYM.APT.002 Aktualizacja oprogramowania jednocześnie na wszystkich stacjach roboczych bez konieczności fizycznej obecności przy tych stacjach.

WYM.APT.003 Możliwość obsługi wielu magazynów centralnych oraz magazynów oddziałowych

WYM.APT.004 Pełna integracja pomiędzy magazynami centralnymi i oddziałowymi w ramach jednego modelu bazy danych

WYM.APT.005 Obsługa miejsc składowania w obrębie magazynu

WYM.APT.006 Możliwość definiowania i przypisywania asortymentu do miejsca składowania

WYM.APT.007 Możliwość powiązania magazynów z jednostkami organizacyjnymi szpitala

WYM.APT.008 Możliwość zdefiniowania wielu OPK/MPK dla jednego magazynu

WYM.APT.009 Automatyczne numerowanie dokumentów magazynowych według ustalonego wzorca

WYM.APT.010 Możliwość rozdzielenia numerowania dokumentacji magazynowej dla każdego magazynu

WYM.APT.011 Zarządzanie słownikami Producentów, Dostawców, Kontrahentów

WYM.APT.012 Możliwość definiowania nazw asortymentu dla poszczególnych dostawców tak, że użytkownik może wprowadzać na fakturze VAT (FV) od dostawcy asortyment według zdefiniowanej nazwy.

WYM.APT.013 Obsługa receptariusza szpitalnego oraz receptariuszy oddziałowych

WYM.APT.014 Mechanizm blokad asortymentu.

WYM.APT.015 Możliwe zablokowanie asortymentu z danej serii bądź FV/dostawy

WYM.APT.016 Ewidencja działań niepożądanych leków, przynajmniej z dokładnością do: asortymentu, serii, oddziału, pacjenta

WYM.APT.017 Możliwość definiowania grup asortymentu

20


WYM.APT.018 Możliwość definiowania klas leków

WYM.APT.019 Możliwość obsługi różnych typów asortymentu

WYM.APT.020 Możliwość definiowania asortymentu, którego nie ma w bazie leków

WYM.APT.021 Kontrola przeterminowania leków

WYM.APT.022 Możliwość definiowania stanów minimalnych i maksymalnych dla danego asortymentu w magazynie

WYM.APT.023 Obsługa jednostek bazowych asortymentu (tabletka, ampułka), jednostek opakowań (OP. 10 tab.), ml, mg

WYM.APT.024 Wsparcie dla wyszukiwania asortymentu za pomocą nazwy handlowej, nazwy międzynarodowej, kodów EAN

WYM.APT.025 Ewidencja leków pacjenta

WYM.APT.026 Obsługa inwentaryzacji magazynu: spis z natury i wykonanie remanentu

WYM.APT.027 Obsługa bilansu otwarcia magazynu

WYM.APT.028 Obsługa przychodów z użyciem Faktur VAT

WYM.APT.029 Obsługa importu elektronicznych faktur VAT

WYM.APT.030 Obsługa przychodów bezfakturowych (np. dary)

WYM.APT.031 Obsługa przesunięć międzymagazynowych (MM+, MM-)

WYM.APT.032 Obsługa przesunięć między miejscami składowania w obrębie jednego magazynu

WYM.APT.033 Obsługa ubytków i strat nadzwyczajnych włącznie ze wsparciem dla protokołu utylizacji

WYM.APT.034 Obsługa wydań do jednostek/kontrahentów zewnętrznych (RZ)

WYM.APT.035 Obsługa zwrotów z oddziałów

WYM.APT.036 Obsługa zamówień do magazynów centralnych

WYM.APT.037 Ewidencja i obsługa zamówień do dostawców

WYM.APT.038 Ewidencja zużycia asortymentu

WYM.APT.039 Ewidencja przesunięć asortymentu

WYM.APT.040 Ewidencja wydań na pacjenta

WYM.APT.041 Ewidencja wydań na jednostkę organizacyjną

WYM.APT.042 Możliwość definiowania receptur

WYM.APT.043 Ewidencja leków produkowanych w aptece szpitalnej

WYM.APT.044 Automatyczne wyliczanie ceny produkowanych leków

WYM.APT.045 Obsługa importu docelowego

WYM.APT.046 Automatyczne generowanie dokumentów magazynowych po zatwierdzeniu faktury

WYM.APT.047 Obsługa korekt faktur

WYM.APT.048 Ewidencja umów przetargowych

WYM.APT.049 Kontrola ilościowa i jakościowa realizacji przetargu

WYM.APT.050 Możliwość ewidencji asortymentu przysłanego przez dostawcę, z którym nie jest zawarta umowa przetargowa.

WYM.APT.051 System umożliwia kontrolę realizacji przetargu, nawet gdy dostawca dostarcza fizycznie inny asortyment niż zobowiązał się umową; asortyment zastępczy musi być w takiej samej cenie i jakościowo odpowiadać asortymentowi z umowy

WYM.APT.052 Kontrola minimalnej daty ważności w dostarczanym asortymencie, w szczególności kontrola minimalnej daty ważności w przypadku zapisu w umowie przetargowej: następuje weryfikacja czy dostarczany asortyment ma datę ważności nie mniejszą niż np.. 3mce od dostawy.

WYM.APT.053 Kontrola wymaganego czasu realizacji zamówienia do dostawcy

WYM.APT.054 Obsługa sposobów obliczania wartości faktury VAT: faktura netto i faktura brutto, tj. SUMA (pozycja netto) + vat LUB SUMA (pozycja netto +VAT)

WYM.APT.055 Weryfikacja zgodności cen w stosunku do umowy przetargowej

WYM.APT.056 Weryfikacja przekroczenia ilości lub wartości z umowy przetargowej

WYM.APT.057 Obsługa wewnętrznych kodów kreskowych: drukowanie i czytanie

21


WYM.APT.058 Możliwość zapisu operacji i dokumentów BO, PZ, MM, Zamówienia z oddziału w trybie szkicu

WYM.APT.059 Możliwość zarządzania uprawnieniami do magazynów, typów asortymentu, konkretnych grup asortymentu

WYM.APT.060 Obsługa raportów magazynowych

WYM.APT.061 Wbudowana baza leków dostępnych na terytorium RP z możliwością aktualizacji

WYM.APT.062 Możliwość rozszerzania dostępnych w aplikacji słowników

WYM.APT.063 Możliwość przypisywania rodzajów kosztów do typów asortymentu

WYM.APT.064 Możliwość odnotowania wydania i podania leku

WYM.APT.065 Możliwość informowania użytkownika od razu po zalogowaniu o asortymencie przeterminowanym

WYM.APT.066 Możliwość informowania użytkownika od razu po zalogowaniu o asortymencie poniżej stanów minimalnych

WYM.APT.067 Możliwość podglądu stanu na magazynach w zależności od uprawnień

WYM.APT.068 Możliwość definiowania i kontroli limitów kosztowych na poszczególne magazyny

Moduł Apteczki Oddziałowe daje możliwość: wprowadzania zleceń, przyjmowania leków z apteki, rozdziału leków do dyżurek, przyjęcia środka od pacjenta, definiowania mechanizmu stop-order na poziomie pacjenta, wprowadzania dodatkowych informacji związanych z terapią antybiotykową, odnotowania podania leków pacjentom.


Kod wymagania

Opis wymagania

WYM.APT.069 Składanie zamówień na leki do apteki centralnej w formie elektronicznej.

WYM.APT.070 Możliwość jednoczesnego złożenia zamówień do wielu magazynów.

WYM.APT.071 Na jednym ekranie możliwość wyboru apteczki zamawiającej oraz wprowadzenia listy środków do zamówienia. System automatycznie rozbija listę zamawianych środków na osobne zamówienia wysyłane do odpowiedniego magazynu, jeśli system skonfigurowano do obsługi wielu magazynów lub wielu rodzajów zamówień.

WYM.APT.072 Składanie zamówień na leki pomiędzy poszczególnymi Podręcznymi Magazynami Leków.

WYM.APT.073 Możliwość zapisania zamówienia na leki w trybie szkicu z możliwością późniejszej edycji.

WYM.APT.074 Możliwość utworzenia nowego zamówienia na leki na bazie wcześniej zrealizowanego zamówienia (kopiowanie zamówienia)

WYM.APT.075 Odbieranie informacji o realizacji zamówienia leków z apteki centralnej.

WYM.APT.076 Przy współpracy z modułem Zleceń Leków na Pacjenta system posiada możliwość ewidencji rozchodu leków na oddziały i na pacjenta.

WYM.APT.077 Ewidencja ubytków i strat nadzwyczajnych.

WYM.APT.078 Ewidencja przesunięć między magazynami apteczek oddziałowych.

WYM.APT.079 Generowanie arkusza do spisu z natury.

WYM.APT.080 Korekta stanów magazynowych (ilościowa i jakościowa) na podstawie arkusza spisu z natury.

WYM.APT.081 Mechanizm „stop-order” (blokowanie serii leków - np. w odpowiedzi na komunikat GIF).

WYM.APT.082 Przegląd bieżących stanów magazynowych (dla wybranego magazynu lub zbiorczo - dla wszystkich magazynów).

WYM.APT.083 Przegląd stanów magazynowych na zadany dzień (dla wybranego magazynu).

WYM.APT.084 Kontrola dat ważności leków znajdujących się na stanie apteczek oddziałowych (z możliwością ustawienia wyprzedzenia z jakim mają być prezentowane dane leków o kończącym się okresie ważności).

WYM.APT.085 Podgląd przechowywanych w systemie informacji o leku (m.in. nazwa, jednostki, producent, opakowanie).

22


WYM.APT.086 Możliwość tworzenia „aliasów” leków i przypisywania do nich rzeczywiście znajdujących się w obrocie leków.

WYM.APT.087 Wykorzystanie słowników: leków, nazw międzynarodowych, słownik jednostek miar.

WYM.APT.088 Komunikacja z modułem Ruch Chorych w zakresie aktualizacji stanu Apteczki Oddziałowej, zgodnie z ewidencją podań środków farmaceutycznych odnotowywanych w Ruchu Chorych.

WYM.APT.089 Aktualizacja stanu leku (zdjęcie ze stanu) w podręcznym oddziałowym magazynie leków w ramach odnotowania zużycia zasobów w związku z wizytą / hospitalizacją / badaniem pacjenta.

WYM.APT.090 Aktualizacja stanu leku (zdjęcie ze stanu) w podręcznym oddziałowym magazynie leków w ramach obsługi zlecenia podania leku.

WYM.APT.091 Dostęp do zdefiniowanych raportów z poziomu menu funkcji „Apteczki oddziałowe”.

WYM.APT.092 Składanie zamówień na leki do apteki centralnej na podstawie zleceń dokonanych w module Zleceń Leków na Pacjenta (o ile do zleceń użyte były leki obecne w słowniku Apteki Szpitalnej).

WYM.APT.093 Możliwość przechowywania informacji o stanie leków własnych pacjenta (stanowiących własność pacjenta).

WYM.APT.094 Możliwość definiowania różnych rodzajów zamówień składanych na leki (np. odrębnego zamówienia na leki narkotyczne) oraz powiązania rodzajów leków w systemie z poszczególnymi wydrukami.

WYM.APT.095 Możliwość zdefiniowania ilościowych stanów minimalnych dla poszczególnych leków w kontekście każdej z apteczek.

WYM.APT.096 Prezentowanie podczas składania zamówienia do dostawcy cen zamawianych leków z umowy.

WYM.APT.097 Możliwość wykorzystania czytników kodów kreskowych podczas inwentaryzacji oraz odnotowania zużycia leków / materiałów.

WYM.APT.098 Możliwość określenia relacji „może zamawiać z” oraz „nie może zamawiać z” pomiędzy dowolnymi apteczkami.

WYM.APT.099 Możliwość jednokrotnego złożenia zamówienia do kilku magazynów (zamówienie takie zostaje rozbite na mniejsze zamówienia, skierowane do odpowiednich magazynów).

Wymagania w zakresie integracji modułów aptecznych z posiadanym systemem HIS:

Kod wymagania

Opis wymagania

WYM.INT.001 Wspólne baz użytkowników oraz funkcje logowania z systemem HIS

WYM.INT.002 Działanie na jednym motorze bazy danych z systemem HIS

WYM.INT.003 Wymiana informacji o zamówieniach, zleceniach, wydaniach leków z systemem HIS

WYM.INT.004 Dostęp w Aptece do informacji wydań i podań leków na podstawie zleceń w HIS

WYM.INT.005 Możliwość odnotowania wydania i podania leku na podstawie zlecenia z HIS

WYM.INT.006 Możliwość automatycznego wczytania niezbędnych informacji z FV za leki w przypadku rozliczeń z NFZ programów lekowych i chemioterapii do systemu HIS

WYM.INT.007 Wspólny słownik lekarzy, oddziałów, pacjentów z systemem HIS

Recepty

Moduł pozwoli na wystawianie i zapisywanie dokumentów recept w formatach wymaganych przez Ustawę o SIOZ czyli HL7 CDA oraz docelowo (po uruchomieniu e-recepty w P1) wymianę recept z systemem centralnym co pozwoli na realizację recept wyłączenie w wersji elektronicznej co stanie się wymogiem prawnym w 2019 roku.


23


WYM.REP.001 Moduł umożliwia wystawianie recept dla wskazanego pacjenta wybranego z bazy pacjentów systemu.

WYM.REP.002 Moduł dostępny jest co najmniej z modułów obsługujących gabinet lekarski, izbę przyjęć, oddział.

WYM.REP.003 Wydruk recepty lekarskiej jest zgodny z rozporządzeniem Ministra Zdrowia z dnia 8 marca 2012 r. w sprawie recept lekarskich (Dz. U. z 2017 r. poz. 1570).

WYM.REP.004 Moduł umożliwia wyszukiwanie leków z następujących słowników: baza leków, leków recepturowych, leków preferowanych.

WYM.REP.005 Moduł umożliwia wyszukiwanie leków według nazwy handlowej lub nazwy międzynarodowej.

WYM.REP.006 Na liście wyszukanych leków, moduł prezentuje co najmniej: nazwę handlową, nazwę międzynarodową, postać, dawkę, opakowanie. Dla leków refundowanych prezentowane są możliwe wartości odpłatności, sugerowana cena oraz wskazania do stosowania odpłatności. W przypadku leków recepturowych, moduł prezentuje co najmniej: nazwę oraz kategorię dostępności.

WYM.REP.007 Moduł umożliwia tworzenie słownika leków recepturowych i zarządzania tym słownikiem. Słownik zawiera co najmniej: nazwę leku, skład chemiczny, kategorię dostępności.

WYM.REP.008 Moduł umożliwia automatyczną aktualizację słownika leków wykorzystywanych do wypisywania recept. Dodatkowo z poziomu modułu administracyjnego istnieje możliwość wykonania importu słownika leków.

WYM.REP.009 Moduł prezentuje użytkownikowi wystawiającemu receptę informację o wersji słownika leków oraz dacie wydanie słownika.

WYM.REP.010 Moduł umożliwia zawężenia listy wyszukanych leków - do samych leków refundowanych.WYM.REP.011 Moduł umożliwia tworzenie podręcznego słownika leków preferowanych przez użytkownika. Dodanie

nowej pozycji słownika jest możliwe z poziomu listy wyszukanych leków z bazy leków lub leków recepturowych.

WYM.REP.012 Moduł umożliwia tworzenie podręcznego słownika leków preferowanych dla jednostki organizacyjnej. Dodanie nowej pozycji do słownika jest możliwe z poziomu listy wyszukanych leków z bazy leków lub leków recepturowych.

WYM.REP.013 Podczas dodawania leku do listy leków preferowanych, moduł umożliwia konfigurację domyślnego dawkowania wskazanego leku. Dzięki temu podczas wystawiania kolejnej recepty moduł umożliwia wybór leku preferowanego i ustawienie domyślnego dawkowania.

WYM.REP.014 Podczas dodawania leku do listy leków preferowanych, moduł umożliwia konfigurację domyślnego dawkowania leku dla pacjenta, któremu wystawiana jest recepta. Dzięki temu przy kolejnym wystawianiu recepty dla danego pacjenta moduł umożliwia wybór leku preferowanego i ustawienie domyślnego dawkowania.

WYM.REP.015 Moduł umożliwia wybór leku oraz wskazanie liczby opakowań (także niepełnych opakowań), dawkowania, odpłatności, dodania komentarza, zastrzeżenia zamiany leku.

WYM.REP.016 Moduł umożliwia przeliczanie dobowej liczby dawek oraz liczby dni kuracji.WYM.REP.017 Moduł automatycznie nanosi na receptę oddział NFZ lub kod państwa w przypadku pacjentów

zagranicznych, a także niezbędne dane pacjenta. W przypadkach, gdy pacjent jest nieubezpieczony, automatycznie ustawiany jest brak ubezpieczenia.

WYM.REP.018 Moduł nanosi automatycznie na formularz i wydruk recepty dane świadczeniodawcy. Odpowiedni świadczeniodawca wybierany jest automatycznie na podstawie miejsca pobytu pacjenta (oddział/poradnia).

WYM.REP.019 Moduł automatycznie nanosi na receptę zalogowanego lekarza, datę wystawienia oraz termin realizacji. Jeśli zalogowany użytkownik nie jest lekarzem, na receptę wstawia się lekarz prowadzący (oddział) lub lekarz z wizyty. Użytkownik może te dane zmieniać, przy czym lekarza może wybrać ze słownika lekarzy w systemie.

WYM.REP.020 Moduł umożliwia oznaczenia pilności recepty.

WYM.REP.021 Moduł umożliwia wybór drukarki, na której nastąpi wydruk.

WYM.REP.022 Moduł umożliwia zdefiniowanie zakresu numerów recept dla lekarza poprzez import z pliku xml lub poprzez ręczne zdefiniowanie zakresu.

WYM.REP.023 Moduł zapisuje numery recept na lekarza i świadczeniodawcę.

24


WYM.REP.024 Jeśli placówka medyczna ma wiele lokalizacji i na każdą oddzielną umowę z NFZ, wskazany we wprowadzaniu zakresów recept lekarz może mieć oddzielną pulę numerów na każdą z przychodni, w których udziela świadczeń.

WYM.REP.025 Podczas wprowadzania numerów recept moduł automatycznie weryfikuje poprawność wprowadzonego numeru recepty.

WYM.REP.026 Moduł automatycznie rejestruje i numeruje recepty ze zdefiniowanej listy numerów recept lekarza.

WYM.REP.027 Moduł umożliwia zdefiniowanie zakresu numerów recept dla lekarza z uwzględnieniem świadczeniodawcy wybieranego ze słownika jednostek organizacyjnych szpitala w Systemie

WYM.REP.028 Moduł automatycznie wyświetla licznik numerów recept pozostałych do wykorzystania.

WYM.REP.029 Moduł ewidencjonuje wszystkie leki przepisywane pacjentowi.

WYM.REP.030 W przypadku wystawiania recept dla dzieci nieposiadających numeru PESEL, na wydruku umieszczany jest PESEL opiekuna zapisany w systemie.

WYM.REP.031 Moduł umożliwia zapis recepty w celu późniejszego jej wydrukowania lub modyfikacji.

WYM.REP.032 Moduł blokuje możliwość edycji lekarza na recepcie, gdy został wykorzystany numer recepty z puli danego lekarza.

WYM.REP.033 Moduł umożliwia usuwanie zapisanych recept. Usunięcie recepty skutkuje odzyskaniem numeru recepty i włączeniu go do puli numerów recept do wykorzystania.

WYM.REP.034 Usunięcie recept wydrukowanych jest możliwe tylko da użytkowników z dodatkowymi uprawnieniami.

WYM.REP.035 Moduł ostrzega użytkownika w przypadku próby edycji wydrukowanej recepty.

WYM.REP.036 Moduł ostrzega przed próbą ponownego wydrukowania tej samej recepty

WYM.REP.037 Moduł ostrzega przed usunięciem zapisanej/wydrukowanej recepty

WYM.REP.038 W momencie wydruku moduł automatycznie zapisuje receptę.

WYM.REP.039 Moduł umożliwia ewidencjonowanie leków przypisywanych pacjentowi bez recepty.

WYM.REP.040 Moduł prezentuje zapisane recepty po ponownym uruchomieniu funkcji.

WYM.REP.041 Moduł prezentuje zachowane recepty i listy leków bez recepty w postaci zakładek i zapisuje je na pobyt/wizytę.

WYM.REP.042 Moduł umożliwia wydrukowanie listy leków dla pacjenta z dawkowaniem.

WYM.REP.043 Moduł umożliwia kopiowanie recept i leków na podstawie historii wystawionych recept.

25


WYM.REP.044 Moduł prezentuje leki, które przyjmuje pacjent. Prezentowane są one w dodatkowej zakładce z możliwością wyboru i naniesienia na receptę.

WYM.REP.045 Moduł umożliwia wydruk pustych recept dla pacjenta (recept, na których lekarz będzie mógł ręcznie wprowadzić same nazwy leków, odpłatność i dawkowanie).

WYM.REP.046 Moduł umożliwia wydruk pustych recept bez danych pacjenta (recept, na których lekarz będzie mógł ręcznie wprowadzić dane pacjenta, nazwy leków, odpłatność i dawkowanie).

WYM.REP.047 Moduł umożliwia wyszukiwanie zamienników leków (zamienniki, zamienniki tańsze, zamienniki dawka, zamienniki dawka tańsze).

WYM.REP.048 Moduł umożliwia zdefiniowanie minimalnej ilości recept, której przekroczenie skutkowało będzie pojawianiem się komunikatu ostrzegawczego podczas wejścia przez użytkownika do modułu recept.

WYM.REP.049 Moduł udostępnia funkcję zarządzania pulami recept. Uprawniony użytkownik ma możliwość wyszukania lekarzy o dowolnej ilości pozostałych recept. Funkcjonlaność prezentuje w postaci listy co najmniej następujące informacje: lekarz / pielęgniarka / położna, nazwa świadczeniodawcy, dostępna ilość recept, kategoria recept, oznaczenie czy pula recept została zablokowana, informacj czy jest to pula numerów komercyjnych, informacje czy jest to pula numerów indywidulnej praktyki lekarskiej, pierwszy numer puli recept, ostatni numer puli, data od, data do.

WYM.REP.050 Moduł umożliwia wgląd do listy leków podawanych pacjentowi podczas pobytu w szpitalu i zapisania ich na recepcie.

WYM.REP.051 Moduł umożliwia wprowadzanie i sprawdzanie interakcji pomiędzy lekami.

WYM.REP.052 Moduł umożliwia duplikację recepty. Użytkownik ma możliwość wskazania liczby duplikowanych recept oraz ilości dni, co które powinna być możliwia ich realizacja. Moduł automatycznie ustawia datę realizacji od dnia, według ustawionej ilości dni.

WYM.REP.053 Moduł umożliwia wystawienie recepty na leki psychotropowe i odurzające. Moduł ogranicza ilość leków na recepcie do jednego, przelicza ilość substancji czynnej i wskazuje ją w postaci opisu słownego.

WYM.REP.054 Moduł umożliwia wystawienia recept pielęgniarkom i położnym.

WYM.REP.055 Moduł umożliwia wystawienie recepty transgranicznej.

WYM.REP.056 Moduł ostrzega użytkownika w przypadku braku adresu pacjenta.

WYM.REP.057 Moduł ostrzega użytkownika w przypadku braku kodu administracyjnego w adresie pacjenta.

WYM.REP.058 Moduł ostrzega użytkownika w przypadku braku aktualnego ubezpieczenie pacjenta.

Rehabilitacja

26


Moduł służy do dokumentowanie procesu rehabilitacji pacjentów szpitala. Wdrożenie modułu jest niezbędne by kompleksowo można było oferować usługę e-rejestracji w obszarze rehabilitacji pacjentów.

Moduł powinien spełniać następujące wymagania: Kod wymagania REHABILITACJA

WYM.REH.001 Możliwość rejestrowania pacjenta na rehabilitację w trybie ambulatoryjnym i szpitalnym.

WYM.REH.002 Korzystanie ze wspólnego z modułami oddział i poradnia skorowidza pacjentów.

WYM.REH.003 Gromadzenie niezbędnych informacji wymaganych przez NFZ.

WYM.REH.004 Korzystanie ze skorowidza pacjentów z możliwością wyszukiwania wg zadanych kryteriów: nazwisko, imię; PESEL, numer kartoteki.

WYM.REH.005 Tworzenie i wydrukowanie skierowania na zabiegi rehabilitacyjne. Dokument zawiera:- dane pacjenta,- rozpoznanie,- cel zabiegów,- rodzaj zabiegów (w tym kody ICD, opisy),- planowana data rozpoczęcia,- planowane daty wykonania zabiegów,- ilość powtórzeń,- parametry dodatkowe,- okolice ciała.

WYM.REH.006 Rejestracja pacjenta na zabiegi z automatycznym proponowaniem możliwych terminów zabiegów.WYM.REH.007 Podpowiadając możliwe terminy zabiegów system uwzględnia czynniki takie jak:

- dostępność zasobów (np. rehabilitant, urządzenie, sala),- łączenie zabiegów w grupy z wymaganymi przerwami i wybraną kolejnością,- możliwość wyszukania terminów całego cyklu w wybranym przedziale godzinowym,- różne czasy trwania poszczególnych zabiegów.

WYM.REH.008 Ręczna modyfikacja zaproponowanych terminów.

WYM.REH.009 Wydruk karty z harmonogramem zabiegów pacjenta.

WYM.REH.010 Przy dokonaniu rezerwacji terminu system automatycznie uzupełnia terminarze dostępności zasobów o dokonaną rezerwację.

WYM.REH.011 Anulowanie z określeniem powodu ze słownika dla zarezerwowanego cyklu zabiegów automatycznie dla wszystkich terminów lub dla pojedynczych zabiegów.

WYM.REH.012 Modyfikacja zarezerwowanych terminów zabiegów.

WYM.REH.013 Tworzenie własnego słownika powodów anulowania zarezerwowanych zabiegów.

WYM.REH.014 Tworzenie kolejki oczekujących na rehabilitację.

WYM.REH.015 Rozliczanie rehabilitacji z NFZ.

WYM.REH.016 Planowanie czasu pracy, dostępności sal, urządzeń, personelu.

WYM.REH.017 Tworzenie planu zabiegów pacjenta.

WYM.REH.018 Odnotowanie wykonania zabiegu pacjenta przez użytkownika.

WYM.REH.019 Automatyczne odnotowanie wykonania zabiegu z użyciem czytnika kodów kreskowych.

WYM.REH.020 Wydruk karty zabiegowej z danymi i kodami kreskowymi pacjenta oraz zabiegów.

WYM.REH.021 W pierwszym dniu zabiegu skreślenie pacjenta z listy oczekujących na zabiegi rehabilitacyjne.

WYM.REH.022 Możliwość uzupełnienia zabiegów zlecanych z oddziału i ośrodka rehabilitacji dziennej.

WYM.REH.023 Możliwość zmiany rodzaju zabiegu po terminie zakończenia.

WYM.REH.024 Przy potwierdzeniu wykonania zabiegów automatyczne sumowanie ilości zabiegów i punktów.

WYM.REH.025 Tworzenie własnych słowników posiadanych zasobów (urządzenia, personel, sale).

27


WYM.REH.026 Możliwość rozróżnienia czasu trwania zabiegu dla typu zabiegu: np. zabiegi domowe, zabiegi ambulatoryjne, fizykoterapia, kinezyterapia.

WYM.REH.027 Możliwość stworzenia własnego słownika typów zabiegów: np. zabiegi domowe, zabiegi ambulatoryjne.

WYM.REH.028 Definiowanie czasu niedostępności personelu, sal, urządzeń.

WYM.REH.029 Definiowanie słownika powodów niedostępności.

WYM.REH.030 Blokowanie terminarza realizacji zabiegów rehabilitacyjnych.

WYM.REH.031 Przeglądanie grafików pracy poszczególnych zasobów.

WYM.REH.032 Możliwość kodowania całego cyklu zabiegów dla danego pacjenta.

WYM.REH.033 Wyróżnienie zabiegów, które zostały wykonane.

WYM.REH.034 Obsługa elektronicznych zleceń w ramach całego systemu.

WYM.REH.035 Wysłanie zlecenia wykonania elementu leczenia (badania) do jednostki realizującej (np. pracownia diagnostyczna).

WYM.REH.036 Możliwość śledzenia stanu wykonania zlecenia.

WYM.REH.037 Zwrotne otrzymanie wyniku realizacji zlecenia (np. wyniku badania).

WYM.REH.038 Wydruk rezerwacji terminu wykonania zabiegu dla pacjenta z oznaczeniem daty, godziny i miejsca wykonywania zabiegów.

WYM.REH.039 Raportowanie dotyczące zabiegów: - ilość zabiegów, - rodzaje zabiegów, - punktacja z rozbiciem na działy i rodzaje zabiegów,- ilości pacjentów i osobodni.

WYM.REH.040 Tworzenie zestawień statystycznych z ilości zaplanowanych zabiegów z uwzględnieniem dodatkowych kryteriów: zabiegi na dany dzień, wybrany zabieg.

WYM.REH.041 Zestawienie listy zaplanowanych zabiegów w danych dniu dla pracowni, personelu.

WYM.REH.042 System umożliwia jednoczesne wyszukanie zrealizowanych cykli wielu pacjentów a następnie pozwala jednocześnie przypisać świadczenia NFZ do wybranych przez użytkownika wielu cykli.

WYM.REH.043 System umożliwia przypisanie lekarza/rehabilitanta prowadzącego dla cyklu zabiegów.

WYM.REH.044 Moduł posiada możliwość konfiguracji przez administratora systemu maksymalnej ilości wykonań zabiegu.

WYM.REH.045 System w ramach jednego ekranu umożliwia wyszukania cykli według statusu (np. zrealizowane, w trakcie realizacji, zaplanowane), typu zlecenia (np. zlecenie z poradnie, zlecenie z oddziału, zlecenie z ośrodka), przedziału czasu (od - do), zlecenia których termin realizacji upłynął.

Moduł Laboratorium Moduł gromadzi dane z badań laboratoryjnych oraz prowadzi kontrolę ilości odczynników, materiałów zużywalnych, kalibratorów będących na stanie magazynu. Moduł zapewni m.in. automatyczne kierowanie badań do stanowisk, na których mają być wykonane, z uwzględnieniem alternatywnych metod wykonywania, w tym możliwość przekierowywania badań do innej pracowni oraz zapewni archiwizację pełnych wyników diagnostycznych wraz z opisami i uwagami, kontrolę jakości i wiarygodności wyników.Moduł powinien spełniać następujące wymagania: Dostarczany system powinien spełniać następujące wymagania

Kod wymagania

Opis wymagania

WYM.LAB.001 Oprogramowanie w języku polskim z graficznym interfejsem użytkownika.

28


WYM.LAB.002 System ma możliwość pracy co najmniej w środowisku graficznym MS Windows na stanowiskach użytkowników XP/VISTA/WINDOWS 7/WINDOWS 8/WINDOWS 10

WYM.LAB.003 System typu gruby klient ("Fat Client") zbudowany w architekturze klient-serwer, bez konieczności posiadania serwera aplikacji do obsłużenia procesów biznesowych zachodzących wewnątrz laboratorium.

WYM.LAB.004 Całość systemu i wszystkie jego moduły takie jak (analityka, mikrobiologia, raportowanie, epidemiologia) muszą stanowić integralną całość która została napisana z wykorzystaniem jednej platformy programistycznej.

WYM.LAB.005 System powinien posiadać wbudowany moduł do edycji raportów oraz wyników w programie typu "End-User Designer" dostępnym z każdego stanowiska roboczego

WYM.LAB.006 System powinien mieć możliwość pracy na przynajmniej 2 różnych systemach baz danych (jedna darmowa, jedna komercyjna)

WYM.LAB.007 System bazy danych powinien posiadać możliwość pełno tekstowego wyszukiwania ("full-text search") obsługiwanego przez główny silnik bazy danych

WYM.LAB.008 System bazy danych musi wspierać wiele schematów (schmas) bądź przestrzeni nazw (namespaces)

WYM.LAB.009 Baza danych nie może posiadać ograniczenia co liczby danych przechowywanych w pojedynczej tabeli

WYM.LAB.010 Baz danych musi wspierać proceduralny język proceduralny PL/SQL bądź PL/pgSQL

WYM.LAB.011 System bazy danych musi posiadać możliwość pracy w środowiskach windows oraz linux

RejestracjaWYM.LAB.012 System powinien umożliwiać rejestrację pacjentów i zleceń diagnostycznych.

WYM.LAB.013 System powinien posiadać możliwość rejestracji wielu badań analitycznych oraz mikrobiologicznych na tym samym zleceniu

WYM.LAB.014 Równoczesna rejestracja na wielu komputerach

WYM.LAB.015 Wyszukiwanie pacjenta na podstawie różnych danych (nazwisko, pesel, nr karty dostępu do wyników indywidualnego) z jednego pola edycyjnego bez potrzeby wyboru typu danych do wyszukania

WYM.LAB.016 System powinien posiadać wbudowany mechanizm wykrywania błędów w numerach PESEL wraz z podpowiadaniem na jakiej pozycji wystąpił błąd (dotyczy pacjentów zarejestrowanych już w systemie)

WYM.LAB.017 Pełna obsługa z klawiatury nie wymagająca używania myszki podczas rejestracji zleceń.

WYM.LAB.018 Możliwość automatycznej współpracy w zakresie przyjmowania zleceń i odsyłania wyników, wg standardu HL7, z systemem HIS, satelitarnymi LSI oraz z oprogramowaniem zewnętrznych, niezależnych punktów pobrań.

WYM.LAB.019 Rejestrowanie manualne badań na podstawie kodów lub nazw badań, możliwość wyboru badania z listy, rejestrację w trybie mieszanym (kody i nazwy badan ) z jednego pola np. Morfologia ,6,7,9,OB , wyszukiwania po dowolnej frazie nazwy badania.

WYM.LAB.020 Zapisywanie błędów przed laboratoryjnych do zlecenia z późniejszą ich statystyką ilościową i lista błędów ( zapisywanie błędów musi udostępniać dodatkowo moduł walidacji i komunikacji z aparatem), wizualizacja zarejestrowanego błędu

WYM.LAB.021 Program musi posiadać system uprawnień przyznawanych poszczególnym użytkownikom systemu, umożliwiający ochronę konfiguracji systemu, danych osobowych, medycznych i finansowych, nie utrudniający jednak normalnej pracy poszczególnych stanowisk, pozwalający na jednoznaczne zidentyfikowanie osoby rejestrującej zlecenia, wykonującej badanie i zatwierdzającej wyniki.

WYM.LAB.022 Konfiguracja połączeń analizatorów musi być przechowywana w głównej bazie danych.

WYM.LAB.023 System znakowania kodami paskowymi („oklejanie” w punktach pobrań, nie w laboratorium) nie wymagający drukarek tych kodów w punktach pobrań,

29


WYM.LAB.024 Możliwość wprowadzenie dla każdego badania daty godziny pobrania oraz daty godziny przyjęcia materiału do laboratorium

WYM.LAB.025 Możliwość globalnej zmiany dat godzin przyjęcia oraz pobrania dla wszystkich zarejestrowanych badań

WYM.LAB.026 Możliwość automatycznej współpracy w zakresie przyjmowania zleceń i odsyłania wyników, wg standardu HL7, z systemem HIS, satelitarnymi LSI oraz z oprogramowaniem zewnętrznych, niezależnych punktów pobrań.

WYM.LAB.027 System umożliwia zapisywanie wszystkich wydrukowanych wyników w formie pdf i późniejszego oddrukowania ich z zapisanej kopii.

WYM.LAB.028 Możliwość konfiguracji wymaganych pól (oddział,lekarz,punkt pobrań, miejsce odbioru wyniku, podjednostka) dla każdego kontrahenta indywidualnie, wraz z możliwością zawężenia listy wyboru dostępnych danych dla każdego kontrahenta, możliwość zdefiniowania wartości domyślnej

WYM.LAB.029 Rejestracja "serią" grupy zleceń od tego samego zleceniodawcy (brak konieczności wybory kontrahenta)

WYM.LAB.030 System podpowiadania przy nazwiskach dwuczłonowych ułatwiający wyszukanie pacjenta np (BACHLEDA-CURUŚ) przy wpisaniu dowolnego nazwiska

WYM.LAB.031 Obsługa płatników na poziome badań zlecenia

WYM.LAB.032 Możliwość pokazania lub ukrywania cen wraz z ich podsumowaniem w rejestracji zleceń

WYM.LAB.033 Możliwość automatycznej rejestracji zleceń poprzez skaner z rozwiązaniem OCR bądź OMR

WYM.LAB.034 Wbudowana obsługa powiadomień o wartościach wyników badań zbierająca dokładne informacje odnośnie zdarzenia tj. osoba powiadomiona, numer telefonu, komentarz , data godzina powiadomienia, znacznik powiadomienia powinien być przypisywany do konkretnego wyniku. Wizualizacja powiadomień z poziomu rejestracji zleceń

WYM.LAB.035 Możliwość powrotu do 5 poprzednio zarejestrowanych zleceń za pomocą jednego kliknięcia z poziomu rejestracji , bez konieczność posiadania skierowania w wersji papierowej

WYM.LAB.036 Weryfikacja zleceń OCR odbywająca się w module rejestracji zleceń na podstawie fragmentów skanów, nie wymagająca posiadania zlecenia w wersji papierowej

PracowniaWYM.LAB.037 Moduł wspomagający wpisywanie Osadów moczu z możliwością obsługi na ekranie dotykowym

WYM.LAB.038 Funkcja wspomagająca zliczanie Rozmazu manualnego krwi

WYM.LAB.039 Obsługa pracowni: Hematologii, Koagulologii, Analityki ogólnej, Biochemii, Serologii

WYM.LAB.040 Możliwość obsługi histogramów

WYM.LAB.041 Autoryzacja wyników, w tym walidacja wyniku, wspólny widok wyników ze wszystkich pracowni, walidowanych poprzednich wyników pacjenta, funkcje „delta check”

WYM.LAB.042 Możliwość wprowadzania wyników rozmazów krwi obwodowej za pomocą zmapowanych klawiszy komputera.

WYM.LAB.043 Automatyczna identyfikacja materiału po numerze zlecenia

Przyjęcie materiału WYM.LAB.044 Możliwość przypisania w laboratorium dodatkowego kodu do materiału przyjętego z innym kodem

(dotyczy rozdziału materiału na pracownie – stanowiska) lub wygenerowanie nowego kodu wg konfiguracji oraz jego wydruk,

WYM.LAB.045 Obsługa centralnej rozdzielni materiałów do badań(np. rejestracja i wstępne opracowanie materiału, podział próbek, możliwość dodrukowania dodatkowej etykiety kodu kreskowego).

WYM.LAB.046 Funkcja „przyjęcia materiału”, umożliwiająca rejestrację materiału z równoczesną weryfikacją zlecenia (wykrycie zleceń, do których brak materiału, ), uwzględnienie tego faktu w procesie analitycznym

WYM.LAB.047 Jednoznaczna identyfikacja pacjenta, zlecenia i materiału w oparciu o kod paskowy

Komunikacja z aparatami

30


WYM.LAB.048 Pełna automatyka sterowania analizatorami diagnostycznymi (programowanie, wysyłanie zleceń, odbiór wyników, przesłanie informacji technicznych – komunikacja dwukierunkowa lub jednokierunkowa, uwzględniająca specyfikę urządzeń)

WYM.LAB.049 Możliwość jednoczesnego odbioru wyników z kilku aparatów na jednych stanowisku

WYM.LAB.050 Przyspieszona, automatyczna obsługa zleceń pilnych,

WYM.LAB.051 Automatyczny dobór wartości referencyjnych i automatyczne flagowanie wyników, w tym flagowanie wyników będących tekstowymi opisami, z możliwością dowolnej liczby zakresów referencyjnych, osobno dla każdej metody wykonania badania oraz osobno dla każdego aparatu

WYM.LAB.052 Możliwość automatycznego zastępowania wyniku liczbowego (poza wskazanym zakresem lub w wskazanym zakresie) odpowiednim tekstem, komentarzem lub możliwość wykonania prostych operacji matematycznych (+,-,*) konfiguracja dostępna dla użytkowników systemu

WYM.LAB.053 System powinien umożliwiać wykorzystanie kodów kreskowych we współpracy z analizatorami.

WYM.LAB.054 Możliwość dopisania indywidualnych komentarzy do uzyskanych wyników w module komunikacji.

WYM.LAB.055 Wszystkie połączenia pomiędzy analizatorami i systemem muszą przekazywać dane w czasie rzeczywistym bezpośrednio do bazy danych z pominięciem jakichkolwiek metod pośrednich takich jak na przykład przechowywanie danych na lokalnych komputerach (hostach).

WYM.LAB.056 System musi zapewnić komunikację z analizatorami zarówno dla połączenia RS-232 oraz TCP/IP.

WYM.LAB.057 Dostęp do raportów badań niezrealizowanych w module komunikacji

WYM.LAB.058 Powiadamianie użytkownika o badaniach do powtórzenia skierowanych z walidacji

WYM.LAB.059 System podczas walidacji wyników przez osobę uprawnioną musi generować podgląd wyników archiwalnych do właśnie zatwierdzanych.

WYM.LAB.060 Możliwość zdefiniowania reguł wyliczających wynik badania z zestawu innych badań oraz zasad automatycznego opisu wyniku poprzez dołączanie zdefiniowanych wcześniej komentarzy,

WYM.LAB.061 System umożliwia określenie postępu wykonania badania

KonfiguracjaWYM.LAB.062 Konfiguracja oraz mapowanie pól dla skierowań rozpoznawanych przez skaner OCR dostępne dla

każdego użytkownika systemu, bezpośrednio w programie

WYM.LAB.063 Konfiguracja norm z automatycznym systemem wykrywanie luk w przedziałach czasowych zdefiniowanej normy. Np. brak normy dla badania Morfologia w zakresie 8 lata - 8 lata 6 miesięcy jedeń dzień

WYM.LAB.064 Pełna archiwizacja wszystkich zmian dotyczących badań tj. parametrów, materiałów oraz norm z możliwością śledzenia zmienianej wartości oraz dokładnym zapisem daty, godziny oraz użytkownika zmieniającego

WYM.LAB.065 Pełna archiwizacja wszystkich zmian dotyczących słowników prostych tj. lekarzy, jednostek, opisów dotycząca zmienianej wartości oraz dokładnym zapisem daty, godziny oraz użytkownika zmieniającego

WYM.LAB.066 Możliwość personalizacji menu głównego programu co do kolorystyki oraz grafiki.

Kontrola jakości

31


WYM.LAB.067 Kontrola jakości i wiarygodności wyników: · kartoteka materiałów kontrolnych i procedur ( SOP), · automatyczne przygotowywanie Kart Kontroli, · rejestracja i ewidencja wyników prób kontrolnych, · poprawność, precyzja (odtwarzalność, powtarzalność), · wykresy LJ, · analiza Westgarda (w seriach i pomiędzy, reguły proste i złożone, indywidualny dobór reguł), · oznaczanie jakości stosowanych metod pomiarowych (kontrolnych) na znormalizowanych kartach OPS · obsługa różnych typów prowadzenia kontroli jakości ( precyzji, powtarzalności: okresy wstępne i robocze, metoda nieznanego dubletu) · prowadzenie kontroli wg danych od producentów odczynników lub danych wprowadzonych przez pracownika laboratorium · możliwość definiowania i ewidencji działań naprawczych, · możliwość wprowadzania indywidualnych komentarzy do uzyskanych wyników kontroli· możliwość automatycznego odbioru wyników kontroli jakości, zapis wyników w bazie danych

WalidacjaWYM.LAB.068 Możliwość definicji zakresów wyników o które system dodatkowo monituje podczas walidacji

WYM.LAB.069 Możliwość definicji zakresów wyników które system blokuje

WYM.LAB.070 Możliwość definicji wartości krytycznych dla parametrów

WYM.LAB.071 Autoryzacja wyników, w tym walidacja wyniku, wspólny widok wyników ze wszystkich pracowni, z walidowanych poprzednio wyników pacjenta, funkcje ”delta check",

WYM.LAB.072 Możliwość jednym przyciskiem walidacji i natychmiastowego wydruku

WYM.LAB.073 Zabezpieczenie niepozwalające zwalidować zlecenia bez podejrzenia wszystkich wartości

WYM.LAB.074 Możliwość wybrania do walidacji badań tylko zrealizowanych przez osobę walidującą

WYM.LAB.075 Możliwość zawężania listy badań do walidacji (np. wybrani kontrahenci, wybrane grupy badań, wybrane badania

WYM.LAB.076 W module przeglądania wyników z walidacji powinien być dostęp do historii wyników pacjenta

WYM.LAB.077 Możliwość autoryzacji wyników za pomocą podpisu elektronicznego certyfikatem kwalifikowanym

WYM.LAB.078 System LSI musi umożliwiać składanie podpisu elektronicznego na wszystkich stacjach roboczych bez konieczność posiadania dostępu do Internetu

WYM.LAB.079 Możliwość logowania do aplikacji za pomocą karty z elektronicznym certyfikatem kwalifikowanym

WYM.LAB.080 Pełna możliwość personalizacji wygładu modułu walidacji wyników co do kolorystyki, rodzaju oraz wielkości czcionki, wyglądu formularza (tabela, listing) dla każdego użytkownika systemu z osobna

MagazynWYM.LAB.081 Zintegrowany w systemie moduł magazynu pozwalający na prowadzenie wewnętrznego magazynu na

potrzebę laboratorium

Serologia z Bankiem KrwiWYM.LAB.082 Moduł serologiczny z bankiem krwi musi być jednolity z częścią analityczną

WYM.LAB.083 Moduł serologii z bankiem krwi umożliwia równorzędne korzystanie z systemu więcej niż jednej pracowni serologii np. w przypadku fuzji szpitali, gdzie pracownia serologii wraz z bankiem krwi znajduje się w kilku lokalizacjach. Proces ten, w zależności od specyfiki placówki, może odbywać się z jednoczesnym zachowaniem ciągłości wszelkich numeracji serologicznych oraz osobnym (lub wspólnym) generowaniem ksiąg serologicznych i/lub wszelkich raportów niezbędnych do funkcjonowania pracowni;

WYM.LAB.084 System musi obsługiwać automatyczną lub manualną rejestrację zleceń badań serologicznych.

WYM.LAB.085 System musi zapewnić możliwość wpisania wyniku serologicznego manualnie oraz automatycznie z analizatora serologicznego

32


WYM.LAB.086 Manualne wprowadzanie wyników serologicznych musi:– umożliwić wprowadzenie pełnego protokołu wraz ze stopniami aglutynacji;– posiadać automatyczną weryfikację zgodności protokołu z wydawanym wynikiem i znaną z historii pacjenta jego dotychczasową grupą krwi i Rh;– umożliwić dodawanie komentarzy do wyników;- informować o grupie krwi pacjenta, jeśli została ona wcześniej ustalona (w badaniach serologicznych wykonywanych w laboratorium lub placówkach zewnętrznych);- informować o wcześniej ustalonych przeciwciałach odpornościowych;

WYM.LAB.087 Automatyczne wprowadzanie wyników serologicznych z aparatu musi umożliwić:- wprowadzenie pełnego protokołu wraz ze stopniami aglutynacji;- dodawanie komentarzy do wyników;

WYM.LAB.088 System musi umożliwiać z poziomu rejestracji oraz walidacji wyników szybki dostęp do historii serologicznej pacjenta w tym do:- ustalonej wcześniej grupy krwi;- ustalonych wcześniej przeciwciał odpornościowych;- grupie krwi oznaczonej w placówce zewnętrznej jeżeli takie oznaczenie miało miejsce;- historii wszystkich badań serologicznych zleconych pacjentowi zawierającej: datę zlecenia, numer zlecenia, nazwę badania, informację o wykonaniu badania i autoryzacji wyniku, podgląd wpisanego protokołu oraz szybki wydruk wyniku;- historię badań serologicznych pacjenta zawierających oznaczenie grupy krwi;- historię wydanych z banku krwi składników wraz z numerem donacji;- zlecenia wykonania badania konsultacyjnego;

WYM.LAB.089 Podczas walidacji wyników system musi informować o sprzecznej grupie krwi, jeżeli aktualnie walidowany wynik nie jest zgodny z historią grup krwi pacjenta;

WYM.LAB.090 System musi posiadać możliwość generowania i wydruku ksiąg serologicznych (grup krwi, grup krwi noworodków, prób zgodności serologicznych, przeciwciał odpornościowych, kwalifikacji do podania immunoglobuliny) za wskazany przez użytkownika okres, a ich forma musi być zgodna z wymogami Regionalnych Centrów Krwiodawstwa i Krwiolecznictwa;

WYM.LAB.091 System musi mieć możliwość podglądu aktualnego stanu magazynowego w banku krwi (z datą ważności preparatu, informacją które preparaty są zarezerwowane oraz ilością godzin od zarezerwowania preparatu);

WYM.LAB.092 Możliwość przyjęcia preparatów do banku krwi z uwzględnieniem czy jest to krew, osocze, płytki krwi czy krioprecypitat. W trakcie przyjmowania preparatu muszą być odnotowane następujące informacje:- data i godzina przyjęcia;- rodzaj preparatu;- numer donacji;- grupa krwi oraz Rh jeśli ustalono;- informacja o suffixie określającym podział pediatryczny (np. A0, B0, C0 itd.);- data pobrania;- data wykonania preparatu;- data ważności preparatu;- ilość preparatu w ml;- numer faktury;- dostawca preparatów;- cena z uwzględnieniem podziałów pediatrycznych;- dane osoby przyjmującej;

33


WYM.LAB.093 Przyjęcie preparatów do banku krwi musi być możliwe przy pomocy skanera kodów kreskowych odczytującego informacje zawarte w kodach ISBT 128, lub manualnie;

WYM.LAB.094 System musi mieć możliwość rezerwowania krwi dla wskazanego pacjenta;

WYM.LAB.095 System musi informować o próbie wydania składnika po 48 godzinach od wykonania próby zgodności;

WYM.LAB.096 Możliwość zwolnienia rezerwacji preparatu;

WYM.LAB.097 Bank krwi musi umożliwiać rozchodowanie preparatów. W trakcie zapisywania rozchodu muszą być odnotowane następujące informacje:- Data i godzina wydania;- Dane pacjenta (imię, nazwisko, identyfikator) - Oddział odbierający;- Lista wydanych preparatów;- Osoba wydająca;

WYM.LAB.098 System musi umożliwić utworzenie dokumentu wydania preparatu dla szczególnych przypadków (wydanie próby zgodności noworodka, wydanie do pilnej transfuzji, wydanie z uwzględnieniem grupy krwi z placówki zewnętrznej). Forma wydruku tych dokumentów musi być zgodna z obowiązującą ustawą;

WYM.LAB.099 System bez wyraźnego zezwolenia nie może pozwolić na wydanie preparatu o niezgodnej grupie krwi z wynikiem pacjenta;

WYM.LAB.100 System musi blokować możliwość wydania preparatu, jeżeli wynik próby zgodności dla danej donacji został zautoryzowany jako niezgodny;

WYM.LAB.101 Możliwość przeglądu oraz wydruk przychodów i rozchodów preparatów w wybranym okresie czasu;

WYM.LAB.102 Możliwość zwrotu preparatów do banku krwi z oddziałów co umożliwia ponowną ich rezerwację i wydanie;

WYM.LAB.103 Obsługa elektronicznych zamówień z oddziałów szpitalnych na preparaty obsługiwane przez bank krwi;

WYM.LAB.104 Tworzenie zamówień na preparaty do dostawców zewnętrznych;

WYM.LAB.105 System musi informować o zbliżającym się upływie terminu ważności preparatów w banku krwi;

WYM.LAB.106 System musi umożliwić sporządzenie protokołu strat wraz ze wskazaniem przyczyny i jednostki odpowiedzialnej za stratę preparatu;

WYM.LAB.107 System musi umożliwić wielokrotny wydruk każdego z dokumentów utworzony w banku krwi;

WYM.LAB.108 Możliwość kasowania poszczególnych dokumentów w banku krwi;

WYM.LAB.109 Możliwość monitorowania historii każdej z donacji;

WYM.LAB.110 Możliwość przypisania do każdego z dokumentów dodatkowych informacji o warunkach przechowywania oraz transporcie i uwzględnienie tych informacji na protokołach wydania;

WYM.LAB.111 Możliwość szybkiego dodania konkretnego preparatu na dowolny dokument poprzez sczytanie kodu kreskowego z numerem donacji;

WYM.LAB.112 Możliwość zlecania w systemie serologicznych badań konsultacyjnych oraz wpisywanie uzyskanego wyniku;

WYM.LAB.113 Możliwość generowania i drukowania ksiąg przychodów i rozchodów (zarówno osobno jak i zbiorczej księgi zawierającej wszystkie dane o przyjęciu i rozchodzie na jednym wydruku), a ich forma musi być zgodna z wymogami Regionalnych Centrów Krwiodawstwa i Krwiolecznictwa;

WYM.LAB.114 Możliwość tworzenia raportów z ilości wykonanych badań serologicznych oraz raportów z banku krwi z możliwością uwzględnienia każdej z informacji zawartych podczas tworzenia poszczególnych dokumentów;

WYM.LAB.115 Możliwość podglądu oraz realizacji zleceń pilnych lub dyżurowych;

W ramach wdrożenia Wykonawca będzie zobowiązany dokonać integracji oprogramowania z posiadanymi przez Zmawiającego aparatami diagnostycznymi:

34


1. BioSystems BA 400 2. BioSystems BA 200 3. SYSYMEX XN 550 – 2 szt. 4. SYSMEX CA 560 – 2 szt. 5. URISCAN PRO 6. GEM PREMIER 4000 7. PROLYTE 8. VIDAS 9. TECAN PROFIBLOT 10. DYNEX DS211. SRS 20-2

Moduł Sterylizatornii Dostarczany moduł powinien spełniać następujące wymagania:

Kod wymagania

Opis wymagania

WYM.STE.001 Rejestracja wszystkich istotnych czynności personelu przeprowadzającego dekontaminację wyrobów oraz ich automatyczna archiwizacja w postaci bazy danych ( przyjęcie, rejestracja dezynfekcji wstępnej, zwolnienie po dezynfekcji wstępnej, rejestracja załadunku myjni, zwolnienie po dezynfekcji, pakowanie i weryfikacja, rejestracja załadunku sterylizatorów, zwolnienie po sterylizacji, wydanie na zewnątrz sterylizatorni, przyjęcie u klienta, wydanie od klienta)

WYM.STE.002 Rejestracja oraz graficzna prezentacja, przechowywanie wykresów i danych cyfrowych parametrów uzyskiwanych podczas pracy maszyn technologicznych podczas obróbki wyrobów dekontaminowanych – myjni dezynfektorów oraz sterylizatorów oraz ich automatyczna archiwizacja w postaci bazy danych. Podłączenie bezpośrednio do sterownika urządzenia bądź poprzez program pośredniczący.

WYM.STE.003 Drukowanie przynajmniej dwóch typów etykiet: 1) podzielonych na trzy rozdzielne części samoprzylepnych etykiet typu „Sandwich” umożliwiających identyfikację zawartości opakowania, zwrot do Centralnej Sterylizacji ( pierwsza część), dołączenie do dokumentacji pacjenta ( druga część) oraz dokumentacji oddziału-odbiorcy (trzecia część) i 2) podzielonych na dwie rozdzielne części samoprzylepnych etykiet typu „Sandwich” umożliwiających identyfikację zawartości opakowania, zwrot do Centralnej Sterylizacji ( pierwsza część), dołączenie do dokumentacji pacjenta ( druga część)

WYM.STE.004 Możliwość umieszczenia na nalepce w obu opcjach skróconej nazwy klienta z możliwością blokowania możliwości wydania produktu dla innego odbiorcy.

WYM.STE.005 Predefiniowany typ etykiet przydzielony w definicji produktu pozwalający na wydruk określonego typu na odpowiedniej drukarce podłączonej do systemu.

WYM.STE.006 Możliwość jednoczesnego podłączenia i używania dwóch drukarek kodów do jednego stanowiska pakowania.

WYM.STE.007 Wydruk nalepki z odpowiednim zapisem ( sterylne, wysterylizowano, zdezynfekowano)

WYM.STE.008 Drukowanie spisu zawartości zestawów wraz z dodatkowymi informacjami ( typu zdjęcia wybranych narzędzi, dodatkowe informacje o narzędziach składowych i produktach).na drukarkach laserowych na stanowiskach pakowania. Drukowanie uwag oraz aktualnych list narzędziowych ( po weryfikacji składu)

WYM.STE.009 Możliwość dopisania uwag i wykonywania zdjęć dotyczących produkowanych zestawów czy narzędzi na bieżąco bez potrzeby używania aplikacji administracyjnej przez pracowników stref – brudnej, czystej i sterylnej. Dostęp do obrazów i treści multimedialnych oraz dokumentacji zewnętrznej w trakcie interaktywnego pakowania przez użytkownika oraz informacji o dostępności takich materiałów.

WYM.STE.010 Możliwość interaktywnego pakowania zestawu przez użytkownika, przy wykorzystaniu wyświetlanej na ekranie listy pakowania wraz z zdjęciami oraz filmami, weryfikowanie każdego rodzaju narzędzi, modyfikowanie składu ilościowego z uwzględnieniem rzeczywistych ilości narzędzi – podanie przyczyny braku narzędzia, definicja kolejności pakowania narzędzi.

35


WYM.STE.011 Śledzenie drogi konkretnego zestawu lub narzędzia w obrębie Centralnej Sterylizatorni oraz do odbiorcy i z powrotem ( odebranie przez klienta i wydanie przez klienta)

WYM.STE.012 Przedstawianie w postaci informacji na ekranie na wszystkich stanowiskach w CS:1) składowych narzędzi produktu oraz ich zdjęć a także ich ułożenia, kolejności układania w zestawach w tym przedstawienie krótkich filmów dotyczących procedury obróbki ( np. przygotowania do sterylizacji ( np. rozkładania) poszczególnych narzędzi i zestawów), definicja kolejności układania narzędzi na tacy, 2) przyjęć i wydań materiałów do/ z CS, 3) procesów technologicznych z maszyn ( myjnie dezynfektory, sterylizatory) 4) zamówień od klientów z funkcją CITO oraz uwagami5) reklamacji od klientów z uwagami6) historii danych produkowanych jednostek i przypisanych procesów technologicznych, błędów, uwag przypisanych przez pracowników, aktualnych zdjęć wykonanych przez pracownika, braków w narzędziach pakowanych.

WYM.STE.013 Dokumentacja przyjęcia materiału do Centralnej Sterylizatorni, dokumentacja wydania na zewnątrz do klienta a także przez używanie skanerów kodów kreskowych- protokoły wydania i przyjęcia. Możliwość wykonywania dokumentacji zdjęciowej przyjęcia i wydawania ( np. zdjęcia uszkodzonych narzędzi) i dodawanie opisów (uwag) do przyjęcia/wydania przez pracowników centralnej sterylizatorni, możliwość skanowania i wykonania zdjęcia kamerą papierowego zlecenia.

WYM.STE.014 Przechowywanie wszystkich informacji o pojedynczych narzędziach, zestawach narzędziowych, materiałach opakowaniowych, testach, mediach, personelu, urządzeniach oraz procesach na nich przeprowadzanych, klientach, obiegach produktów w bazie danych na serwerze.

WYM.STE.015 Identyfikacja wsadu sterylizatorów oraz myjni dezynfektorów oraz jego korelacja z danymi dotyczącymi danego procesu, w którym zestaw czy pojedyncze narzędzie było myte-dezynfekowane, sterylizowane z wykorzystaniem oznaczników koszy, tac, kontenerów oraz wózków wsadowych wyposażonych w kod kreskowy.

WYM.STE.016 Wykorzystywania tych samych oznaczników w myjniach oraz sterylizatorach oraz podczas kompletacji załadunków. Oznaczniki wykonane ze stali kwasoodpornej ze sprężynującym uchwytem umożliwiającym umocowanie na rogach tacy narzędziowej ( 100 sztuk) odporne na temperaturę sterylizacji oraz środki chemiczne podczas dezynfekcji. Możliwość bezpośredniego drukowania oznaczników z oferowanego oprogramowania.

WYM.STE.017 Automatyczna rejestracja i archiwizacja parametrów mycia i dezynfekcji ( automatycznej i ręcznej) kontenerów sterylizacyjnych (osobny proces mycia i dezynfekcji) , wózków transportowych , opakowań transportowych. Brak możliwości zapakowania zestawu w kontener sterylizacyjny bez prawidłowo zakończonego procesu mycia i dezynfekcji kontenera. Brak możliwości wydania materiału na wózku lub w opakowaniu bez prawidłowo zakończonego procesu mycia i dezynfekcji opakowania lub wózka. Powiązanie procesów obróbki kontenerów sterylizacyjnych z konkretnymi produkowanymi zestawami czy pojedynczymi narzędziami. Możliwość automatycznego wyszukiwania wsadów przez system po zdefiniowaniu parametrów min.: data i godzina, nazwa maszyny, nazwa programu, status wsadu, numer wsadu.

WYM.STE.018 Automatyczne tworzenie wsadu i rejestracja danych dla uruchomionego procesu myjni – dezynfektora, sterylizatora, bez inicjowania wsadu w systemie przez personel (funkcja zapobiegająca utracenia rejestracji danych procesów, które omyłkowo nie zostały zainicjowane w systemie przez personel w szczególności procesy typu np.: rozgrzewający, test Bowie – Dick).

WYM.STE.019 Funkcja CITO pozwalająca na śledzenie zestawów do których przypisano znacznik CITO ( nadawane z zamówienia oraz przez pracowników sterylizatorni) przypominająca obsłudze o konieczności jak najszybszej obróbki oznaczonych narzędzi oraz automatycznie przypominająca o konieczności podjęcia kroków obróbki w przypadku bezczynności personelu.

WYM.STE.020 Tworzenie własnych zapytań/reguł do załadunku, wyładunku programów myjni – dezynfektorów, sterylizatorów w systemie, mających na celu potwierdzenie spełnienia określonych procedur obowiązujących w Centralnej Sterylizatorni przez pracujący personel, na które odpowiedzi są rejestrowane w systemie.

WYM.STE.021 Automatyczne określanie terminu ważności materiału produkowanego w zależności od wyboru wzorca pakowania, możliwość określania terminu ważności indywidualnie podczas pakowania niezależnie od wzorca pakowania.

WYM.STE.022 Budowa systemu umożliwiająca dalszą automatyczną pracę na innym komputerze systemowym bez konieczności wprowadzania danych ręcznie w przypadku awarii jednego lub kilku komputerów stanowiskowych bez użycia aplikacji administracyjnej.

36


WYM.STE.023 System pracy ręcznej z dostępem dla upoważnionych osób umożliwiający pracę w przypadku awarii lub pominięcia zapisu obróbki technologicznej narzędzi ulokowany w aplikacji administracyjnej.

WYM.STE.024 Informacja o tym gdzie jest i co się dzieje z danym zestawem lub narzędziem (status), dostępna na wszystkich stanowiskach. Informacja u klienta co dzieje się z danym zestawem którego jest właścicielem – status obróbki

WYM.STE.025 Inwentaryzacja magazynu materiałów wyprodukowanych za pomocą skanera bezprzewodowego i kodów kreskowych na towarach w magazynach czystym i sterylny

WYM.STE.026 Magazyn materiałów zużywalnych ( testy, rękawy, papier, chemia do maszyn technologicznych, komponenty takie jak itd. gaza, itd.) potrzebnych do produkcji z możliwością wprowadzenia stanów minimalnych. Informacja o datach ważności materiałów w magazynie z przypominaniem o konieczności zużycia z powodu potencjalnego przeterminowania. Przyjęcia towarów magazynowych od różnych poddostawców w różnych ilościach i cenach Magazyn prowadzony w oparciu o zasadę FIFO.

WYM.STE.027 Automatyczne wydawanie z magazynu materiałów zużywalnych i przypisywania do konkretnego narzędzia lub zestawu ( produktu).

WYM.STE.028 Wyliczanie kosztów procesów technologicznych w oparciu o koszty mediów zasilających, ścieków technologicznych oraz środków chemicznych i materiałów. Możliwość aktualizacji cen mediów zasilających oraz ścieków technologicznych, środków chemicznych i materiałów w oparciu o rzeczywiste dane ( w oparciu o umowy i terminy umów z dostawcami) i na bieżąco przeliczanie kosztów procesów technologicznych w oparciu o nie. ( cena wody, prądu ścieków itd.)

WYM.STE.029 Informacja o możliwości przyszłego przeterminowania się artykułów z możliwością automatycznego wysyłana informacji oraz przedstawiana w aplikacji administracyjnej dla administratora oraz odbiorcy ( właściciela) materiału, informacja dostępna w aplikacji zainstalowanej u klienta materiału.

WYM.STE.030 Brak możliwości wydania artykułów do odbiorcy - przeterminowanych, bez poprawnego zwolnienia wsadów, bez poprawnie zaliczonego testu biologicznego, obarczonych błędami technologicznymi lub innymi błędami blokującymi wydanie z powodu niekompletności dokumentacji lub innych nieprawidłowości.

WYM.STE.031 Prowadzenie dokumentacji programów testowych wraz z rejestracją skanów testów ( Bowie&Dick, test mycia, testy biologiczne, itd)

WYM.STE.032 Tworzenie bilingów do faktur dla odbiorców zewnętrznych i wewnętrznych szpitala w oparciu o automatycznie wyliczane kosztów oraz cen dla danego cyklu obróbki. Wyliczanie kosztów bieżących bezpośrednich oraz cen które uwzględniają: amortyzację narzędzi, koszty mycia i dezynfekcji ( w tym wstępnej) w zależności od wielkości pakietu w bieżącym wsadzie, koszty sterylizacji w zależności od wielkości pakietu w bieżącym wsadzie, koszty materiałów opakowaniowych zewnętrznych i wewnętrznych, koszty testów, koszty czasu obróbki osobowej. Wyliczanie kosztów wyprodukowania danego narzędzia czy zestawu ( produktu). Wyliczanie faktycznych kosztów obróbki uwzględniające powtórzenie procesu technologicznego, powtórne pakowanie, opcję CITO ( zwiększenie ceny), nie pełny załadunek maszyn technologicznych itd.

WYM.STE.033 Cennik kwotowy lub punktowy do wyboru.

WYM.STE.034 Tworzenie sprawozdań dotyczących wykorzystania sprzętu, kosztów serwisowych (myjnie, sterylizatory, stacja przygotowania wody, myjnie ultradźwiękowe itd).

WYM.STE.035 Identyfikacja wraz z kodami dostępu do odpowiednich poziomów kompetencji dla personelu obsługującego system wraz z logowaniem do systemu pracy stanowiskowej przy użyciu skanera kodów kreskowych i wpisaniu z klawiatury ( w tym ekranowej)

WYM.STE.036 Hasła do aplikacji administracyjnej w postaci alfanumerycznej.

WYM.STE.037 Książka serwisowa maszyn ( myjni, sterylizatorów, stacji przygotowania wody itd.) prowadzona w systemie- automatyczne przypominanie i informowanie o konieczności wykonania przeglądów i obsługi technicznej, rejestracja kart pracy serwisu technicznego, wyliczanie kosztów obsługi serwisowej maszyn, planowanie terminów przeglądów – harmonogram przeglądów i obsługi technicznej

WYM.STE.038 Możliwość wewnętrznego przesyłania informacji (możliwość dołączenia załączników) pomiędzy użytkownikami systemu. Informacja powinna być przedstawiana po zalogowaniu do systemu z potwierdzeniem odczytania. Przesyłanie informacji o odbiorze i przeczytaniu informacji przez osobę wysyłającą informację. Skrzynki danych odebranych, wysłanych.

37


WYM.STE.039 Instrukcja obsługi oprogramowania w języku polskim dostępna bezpośrednio w uruchomionej aplikacji ( administracja, użytkownik) bezpośrednio na stanowisku pracy. Możliwość wydruku instrukcji obsługi.

WYM.STE.040 Język wszystkich komunikatów, opisów potrzebnych do komunikacji systemu z obsługą – polski.

WYM.STE.041 System pracy stanowiskowej ma być przystosowany (gotowy) do stosowania równolegle trzech metod wprowadzania danych przez pracowników obsługujących na stanowiskach pracy systemu- przy pomocy ekranów dotykowych,- skanerów,- myszy i klawiatury.

WYM.STE.042 Na komputerze Administratora oraz na komputerach stanowiskowych wyświetlanie jednocześnie informacji o ilości jednostek procesowanych w poszczególnych urządzeniach technologicznych z informacją o czasie do końca procesu i rodzaju uruchomionego programu, jednostek przyjętych, poddanych dezynfekcji wstępnej, odrzuconych z mycia i dezynfekcji oraz sterylizacji, przyjętych na strefę czystą do zapakowania, zapakowanych- oczekujących na sterylizację, w magazynie sterylnym, zamówionych i w transporcie, u klientów.

WYM.STE.043 Możliwość obróbki narzędzi wypożyczonych ( sterylizacja lub sama dezynfekcja w zależności od odpowiedniego przypadku).Wydruk nalepki z odpowiednim zapisem ( sterylne, wysterylizowano, zdezynfekowano).

WYM.STE.044 System przystosowany do identyfikacji pojedynczego narzędzia za pomocą skanera 2D DPM -funkcje zawarte w oprogramowaniu . Możliwość skanowania kodów 2D z powierzchni narzędzia w celu kontroli i weryfikacji składów zestawów. Oprogramowanie powinno umożliwiać weryfikację narzędzi na stanowisku pakowania.

WYM.STE.045 Baza danych typu SQL stosowana w systemie komputerowym bez ograniczeń funkcjonalnych oraz pojemnościowych. ( w tym brak ograniczeń wielkości rocznej produkcji lub produkcji ilości jednostek docelowej

WYM.STE.046 Aplikacja na oddziały umożliwiająca: przyjęcie i wydanie materiału, sprawdzenie stanu magazynu u klienta i swojego towaru w sterylizatorni, zamawianie towaru ( przesyłanie informacji CITO, informacji od klienta do zamówienia) , wysyłanie reklamacji dotyczących przekazywanego do klienta materiału ( dodawanie komentarzy do reklamacji) , informacji o terminie ważności i pozostałym do zakończenia terminu ważności czasie, status towaru posiadanego przez klienta ( jako właściciela towaru), anulowanie zamówienia, potwierdzenie zużycia materiału i przypisanie nr ( operacji, pacjenta itp.).

Moduł Integracji HL7- Moduł niezbędny do zapewnienia integracji z zewnętrznymi systemami taki jak PACS lub Laboratorium w zakresie danych pacjentów oraz operacji ruchu chorych.


Kod wymagania Opis

WYM.HL7.001 Zgodność z wersją 2.x standardu HL7

WYM.HL7.002 Możliwość umieszczenia zleceń oczekujących w kolejce zleceń oczekujących do wysłania.

WYM.HL7.003 Minimalny zestaw transakcji HL7 obsługiwanych przez system HIS:Transakcje HIS -> Moduł dziedzinowyNowe zlecenie – ORMÔ01 Anulowanie zlecenia – ORMÔ01 Transakcje Moduł dziedzinowy -> HISNowe zlecenie – ORMÔ01 Zmiana danych zlecenia – ORMÔ01 Anulowanie zlecenia – ORMÔ01 Zmiana statusu zlecenia – ORMÔ01Wyniki – ORU^R01

38


WYM.HL7.004 Możliwość automatycznej synchronizacji danych pacjenta z danymi pacjenta w systemie zewnętrznym podczas dodawania nowego pacjenta oraz możliwość synchronizacji na żądanie użytkownika (transakcje ADT) min. :- aktualizacja danych pacjenta ADTÂ31- łączenie danych pacjentów ADTÂ40- zmiana identyfikatora pacjenta ADTÂ47

WYM.HL7.005 Możliwość generowania dziennego podsumowania przetwarzanych transakcji HL7 i wysyłania zestawienia e-mailem do wskazanych odbiorców. Możliwość definiowania osobnych list odbiorców dla każdego systemu, z którym występuje komunikacja.

WYM.HL7.006 Możliwość ponownego wygenerowania transakcji HL7 z poziomu aplikacji WWW w przypadku awarii komunikacji z systemami zewnętrznymi. Możliwość wskazania co najmniej numeru badania, typu transakcji (nowe zlecenie/wynik/anulowanie zlecenie), systemu którego dotyczy transakcja. Możliwość grupowego generowania transakcji ze zleceń dla wybranego okresu (od-do dd-mm-rrrr gg-mm) oraz z typu transakcji. Po użyciu funkcji wyświetlenie informacji o liczbie ponownie wygenerowanych transakcji.

WYM.HL7.007 Możliwość wczytywania do systemu dokumentów osadzonych w przesyłanych transakcjach HL7 np. raportów PDF z prób wysiłkowych i udostępnienie ich w systemie.

System Informacji MenadżerskiejRaporty Zarządcze dla Kierownictwa

Moduły niezbędny by zapewnić odpowiedni monitoring, organizację i stałe doskonalenie świadczonych usług zdrowotnych. Pozwala na bieżąco śledzić wykorzystanie świadczonych usług oraz dostosowywanie ich do potrzeb interesariuszy projektu.


Kod wymagania

Opis wymagania

WYM.SIK.001 Definiowanie, edycja i przeglądanie słownika miejsc powstawania kosztów (MPK).

WYM.SIK.002 Możliwość importu listy ośrodków kosztów z arkuszy MS Excel.

WYM.SIK.003 Definiowanie, edycja i przeglądanie słownika nośników kosztów (procedury medyczne, usługi niemedyczne).

WYM.SIK.004 Możliwość importu listy nośników kosztów z arkuszy MS Excel.

WYM.SIK.005 Definiowanie, edycja i przeglądanie słownika grup nośników kosztów.

WYM.SIK.006 Definiowanie, edycja i przeglądanie słownika składowych procedur medycznych (materiały, leki, personel, inne).

WYM.SIK.007 Możliwość importu: słownika materiałów, leków, grup zaszeregowania personelu z arkuszy MS Excel.

WYM.SIK.008 Możliwość wykorzystania opisu procedury w innej procedurze.

WYM.SIK.009 Przypisanie procedur /usług do miejsc wykonywania.

WYM.SIK.010 Definiowanie, edycja i przeglądanie wskaźników kosztowych (koszty rodzajowe).

WYM.SIK.011 Definiowanie, edycja i przeglądanie grup wskaźników kosztowych.

39


WYM.SIK.012 Tworzenie opisów procedur medycznych z uwzględnieniem składowych: materiały, leki, personel, inne.

WYM.SIK.013 Definiowanie okresów rozliczeniowych następujących po sobie o długości będącej wielokrotnością miesiąca kalendarzowego.

WYM.SIK.014 Możliwość zablokowania okresu kosztowego przed wprowadzaniem zmian i możliwość odblokowania okresu kosztowego. Założenie i zdjęcie blokady można wykonać dowolną ilość razy.

WYM.SIK.015 Wyliczenie kosztu normatywnego procedur medycznych w okresach rozliczeniowych na podstawie sporządzonych opisów procedur medycznych .

WYM.SIK.016 Import z systemu finansowo-księgowego (FK) kosztów MPK w układzie podmiotowym w okresach rozliczeniowych.

WYM.SIK.017 Modyfikacja kosztów w układzie podmiotowym w okresie rozliczeniowym.

WYM.SIK.018 Moduł umożliwia wykorzystanie dowolnych wskaźników kosztowych jako współczynników podziału kosztów.

WYM.SIK.019 Ewidencja ilości wystąpień procedur medycznych/usług w obrębie okresów rozliczeniowych.

WYM.SIK.020 Możliwość wprowadzania statystyki wykonanych nośników kosztów innych niż procedury medyczne, np.: osobodni, liczba leczonych, liczba porad.

WYM.SIK.021 Generowanie formularzy MS Excel do wprowadzania liczby wystąpień procedur medycznych/usług, które po wypełnieniu są importowane do programu.

WYM.SIK.022 Import z systemu szpitalnego ilości wystąpień procedur medycznych/usług w obrębie okresów rozliczeniowych.

WYM.SIK.023 Import z systemu szpitalnego wskaźników statystycznych ( ilość porad, ilość osobodni, ilość hospitalizacji) w okresach rozliczeniowych.

WYM.SIK.024 Możliwość przenoszenia liczby wykonanych procedur medycznych pomiędzy MPK oraz pomiędzy okresami rozliczeniowymi.

WYM.SIK.025 Raport ośrodków, których koszty nie zostaną rozdzielone z powodu braku wykonanych procedur/usług w okresie kosztowym.

WYM.SIK.026 Raport nośników kosztów, które nie zostaną uwzględnione w procesie kalkulacji kosztów z powodu braku kosztu normatywnego w okresie kosztowym.

WYM.SIK.027 Możliwość analizy kosztu normatywnego procedur medycznych wg minimalnych, maksymalnych, średnich (z podaniem wartości odchylenia standardowego) cen materiałów i leków w wybranym okresie czasu.

WYM.SIK.028 Raport kosztów całkowitych ośrodków kosztów działalności podstawowej po rozdziale kosztów.

WYM.SIK.029 Określenie planu rozdziału dla każdego ośrodka:- określenie ośrodków, na które będą rozliczone koszty ośrodka koszów,- możliwość wprowadzenia współczynników podziałowych ośrodka kosztów,- możliwość automatycznego wyliczania współczynników podziałowych ośrodka na podstawie dowolnej grupy kosztów rodzajowych.

WYM.SIK.030 Rozliczenie kosztów zaimportowanych z modułu Finansowo-Księgowego w układzie podmiotowym na procedury medyczne z uwzględnieniem współczynników podziałowych wyliczonych na podstawie kosztów normatywnych i ilości wystąpień procedur medycznych/usług w zdefiniowanym okresie

40


rozliczeniowym.WYM.SIK.031 Możliwość rozliczania kosztów metodą układu równań (metoda algebraiczna).

WYM.SIK.032 Możliwość rozliczania kosztów za zasadach sprzedaży wewnętrznej.

WYM.SIK.033 Możliwość wyliczenia średniego kosztu leczonego, osobodnia, porady.

WYM.SIK.034 Podział kosztów ośrodków działalności pomocniczej i zarządu na ośrodki działalności podstawowej:- proporcjonalnie do wartości dowolnej grupy kosztów rodzajowych,- proporcjonalnie do kosztów bezpośrednich,- proporcjonalnie do kosztów całkowitych (koszty bezpośrednie i pośrednie) ośrodków działalności podstawowej.

WYM.SIK.035 System generuje raporty ogólne definicyjne:- lista zdefiniowanych MPK,- lista nośników kosztów,- wydruk składowych procedur medycznych,- wydruk listy procedur medycznych wg wykonawcy,- wydruk opisów procedur medycznych,- wydruk listy nośników kosztów wg miejsca wykonywania,- cennik procedur/usług.

WYM.SIK.036 System generuje raporty kosztowe i statystyczne z możliwością wyboru:- okresu kosztowego,- okresu czasowego (od – do),- typu miejsca powstawania kosztów (zarząd, pomocniczy, podstawowy oddział, podstawowy nie oddział),- miejsc powstawania kosztów,- poziomu agregacji dla kont miejsc powstawania kosztów.

WYM.SIK.037 Raporty kosztowe przedstawiają:- koszty bezpośrednie, pośrednie, całkowite MPK po podziale kosztów z rozbiciem na koszty wg rodzaju, koszty zarządu, procedur medycznych,- koszty rzeczywiste procedur/usług wg wykonawców oraz zleceniodawców,,- koszty przekazane, koszty otrzymane podczas podziału kosztów,- średnie koszty hospitalizowanego, osobodnia i porady.

WYM.SIK.038 Raporty statystyczne zawierają: - liczba wykonanych procedur/usług wg zleceniodawców, wykonawców, zbiorczo, - raport zużycia składowych procedur medycznych (materiały, leki, nakład pracy personelu).

WYM.SIK.039 Definiowanie, edycja i przeglądanie cenników procedur medycznych/usług.

WYM.SIK.040 Moduł umożliwia wyliczenie kosztów leczenia pacjenta wg kosztów cennika z wyszczególnieniem kosztów: opieki medycznej, kosztów hotelowych, procedur medycznych, leków.

WYM.SIK.041 Wydruk okresowy średnich kosztów procedur.

WYM.SIK.042 Wydruk okresowy średnich kosztów leczenia jednostek chorobowych.

System Bi Pozwoli na samodzielne tworzenie raportów i analiz. W ramach realizacji Wykonawca dokona opracowania metod zaczytywania danych i zaczyta dane z systemów użytkowanych przez Zamawiającego to jest systemu Clininet firmy CGM oraz dostarczanego systemu ERP.

Procedury importu danych muszą spełniać następujące kryteria:

41


1. Zostaną opracowane i zaimplementowane w dostarczonym Systemie BI ;2. Każda procedura importu powinna uwzględniać identyfikację nowych danych oraz danych zmienionych lub

usuniętych w systemie lub pliku źródłowym;3. Importowane dane źródłowe powinny być zachowywane w postaci nieprzetworzonej w Repozytorium

Danych Nieprzetworzonych. Procedura składowania powinna zapewniać optymalizację zajętości przestrzeni dyskowej;

4. W ramach importu danych Wykonawca dokona jak najpełniejszego połączenia danych z systemów źrółowych z wymiarami Hurtowni.

5. Dokona odseparowania danych osobowych od danych medycznych i zapisu zdepersonalizowanych danych w repozytorium hurtowni danych.

Dla danych z systemu CliniNet oraz dostarczanego systemu ERP Wykonawca, oprócz opracowania procedur importu, dokona inicjalnego zasilenia systemu danymi z tych systemów. Wykonawca zapewni również procedury importu słowników niezbędnych do wykonania raportów zdefiniowanych w OPZ.

Import danych będzie przebiegał cyklicznie w interwałach czasowych ustalonych na etapie realizacji projektu w czasie najmniejszego obciążenia systemu (np. godziny najmniejszego obciążenia systemu 20.00-04.00) i powinien być zoptymalizowany pod względem czasu wykonania, ilości transferowanych danych, obciążenia systemu źródłowego. Harmonogram importu zostanie opracowany na etapie analizy przedwdrożeniowej. Zamawiający na chwilę obecną identyfikuje następujące możliwości importu danych z systemu CliniNet:

Poprzez pliki wymiany XML - w ramach systemu rozliczeń z NFZ okresowo generowane są informacje o wszystkich świadczeniach zrealizowanych w ramach umów na świadczenia zdrowotne. Strukturę komunikatów określa Rozporządzenie Ministra Zdrowia w sprawie zakresu niezbędnych informacji gromadzonych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeń ze środków publicznych z dnia 20 czerwca 2008 r. (Dz.U. Nr 123, poz. 801 z późn. zm.) oraz zarządzenia Prezesa NFZ. Wykonawca opracuje procedurę importu tych plików, która będzie czerpać automatycznie pliki z określonego miejsca w strukturze katalogów oraz będzie wykrywać nowe pliki i implementować je do Hurtowni Systemu BI .

Wykonawca przedstawi do akceptacji Zamawiającego koncepcję przenoszenia danych, a koncepcja musi uwzględniać minimum zakres danych niezbędny do wykonania zdefiniowanych w OPZ raportów.Szczegółowy wykaz słowników do importu zostanie opracowany na etapie projektu technicznego, ale musi uwzględniać co najmniej słowniki niezbędne do wykonania raportów określonych w OPZ.

Dane będą gromadzone w strukturach wspierających wydajne analizy danych, to jest w strukturze gwiazdy i/lub płatka śniegu zgodnie z najlepszymi praktykami w obszarze budowania hurtowni danych i wiedzą ekspercką Wykonawcy.

Jeżeli do hurtowni przenoszone będą dane pacjentów repozytorium Danych będzie zawierało jedynie Zdepersonalizowany Unikatowy Identyfikator Pacjenta (ZUIP). Budowa zdepersonalizowanego identyfikatora pacjenta będzie oparta o mechanizmy kryptograficzne, funkcje haszujące zgodnie z najlepszymi praktykami w tym zakresie. Wykonawca może zastosować w tym obszarze algorytmy kryptograficzne takie jak MD5, SHA2 lub RIPEMD. Na etapie analizy przedwdrożeniowej Wykonawca może zaproponować Zamawiającemu inne metody kryptograficzne pod warunkiem, że nie obniżą one poziomu bezpieczeństwa zbudowanego w ten sposób identyfikatora ZUIP. Dane osobowe pacjenta zostaną wydzielone do odrębnej struktury, przestrzeni fizycznej lub logicznej, do której dostęp będzie wymagał specjalnego uprawnienia.

W ramach projektu Wykonawca wykona następujące zestawy raportów : 1. Grafik absencji pracowników zawierający co najmniej:

42


okres (rok, miesiąc) imię i nazwisko pracownika jednostkę w której zatrudniony jest pracownik PESEL Data początku absencji Data końca absencji rodzaj nieobecności liczba dni absencji wg: rodzaju absencji, liczby dni kalendarzowych, liczby dni roboczych"

2. Grafik personelu zawierający co najmniej: datę (dzień, miesiąc, kwartał, półrocze, rok) jednostkę organizacyjną grupę pracowniczą podgrupę pracowniczą imię i nazwisko numer pracownika zaplanowaną godzinę rozpoczęcia i zakończenia pracy liczba godzin zaplanowanych rzeczywistą godzinę rozpoczęcia i zakończenia pracy rzeczywisty czas pracy"

3. Grupy personelu zawierający co najmniej: kod i nazwa grupy pracowniczej rodzaj zatrudnienia (umowa o pracę, kontrakt) Imię i nazwisko PESEL data zatrudnienia data zwolnienia wymiar zatrudnienia w pełnych etatach (tylko w przypadku umów o pracę)"

4. Raport z realizacji budżetu wg struktury budżetowej zdefiniowanej w module budżetowanie, zawierający: okres budżetowy (miesiąc, kwartał, półrocze, rok), ośrodek odpowiedzialności, pozycję budżetu, wartość planu, wartość wykonania, % realizacji budżetu

5. Bilans na podstawie definicji bilansu określonej w module finansowo-księgowym6. Rachunek zysków i strat na podstawie definicji określonej w module finansowo-księgowym7. Raport prezentujący koszty pośrednie zawierający:

okres (miesiąc, kwartał, półrocze, rok), nazwę i numer ośrodka kosztów przekazującego koszty, numer i nazwę ośrodka otrzymującego koszty"

8. Plany finansowe - na podstawie definicji określonych w module finansowo-księgowym9. Wskaźniki finansowe wg definicji określonej w systemie finansowo-księgowym. Raport zawiera następujące wskaźniki:

Wskaźnik bieżącej płynności (I stopnia) Wskaźnik bieżącej płynności (II stopnia) Wskaźnik bieżącej płynności (III stopnia)

43


Wskaźnik ogólnego zadłużenia Wskaźnik produktywności aktywów Wskaźnik zadłużenia długoterminowego Wskaźnik zadłużenia kapitału własnego Wskaźnik zyskowności działalności operacyjnej Wskaźnik zyskowności netto"

10. Wykaz stanu kont zawierający: okres (miesiąc, kwartał, półrocze, rok) Nr konta nazwa konta obroty WN obroty MA obroty WN narastająco od początku roku obroty MA narastająco od początku roku BO WN BO MA saldo BO WN saldo BO MA saldo WN saldo MA saldo WN narastająco od początku roku saldo MA narastająco od początku roku"

11. Dynamika czasu hospitalizacji zawierający: okres (miesiąc, kwartał, półrocze, rok) nazwa oddziału liczba osobodni liczba łóżek średni czas pobytu liczba leczonych

12. Dynamika obłożenia łóżek szpitalnych zawierający: okres (miesiąc, kwartał, półrocze, rok) Nazwa oddziału Liczba osobodni maksymalna liczba osobodni w okresie % wykonania liczba łóżek liczba pacjentów pozostałych z poprzedniego miesiąca liczba pacjentów przyjętych do szpitala liczba pacjentów przeniesionych z innego oddziału liczba leczonych średni czas pobytu średnie obłożenie liczba pacjentów przeniesionych na inny oddział liczba zgonów liczba wypisanych pacjentów liczba pacjentów pozostałych w oddziale"

13. Dynamika ruchu chorych zawierający::

44


okres (miesiąc, kwartał, półrocze, rok) nazwa oddziału liczba osobodni maksymalna liczba osobodni liczba łóżek w oddziale średni czas pobytu obłożenie przelotowość liczba leczonych

14. Raport wydanych leków z apteki zawierający: okres (miesiąc, kwartał, półrocze, rok) kod i nazwa jednostki organizacyjnej typ leku klasa leku nazwa leku ilość wydanych leków wartość wydanych leków"

15. Stan realizacji umów NFZ zawierający: okres (miesiąc, kwartał, półrocze, rok) nr umowy limit umowy w punktach limit umowy w zł wykonanie umowy w punktach wykonanie umowy punktach"

16. Stan realizacji umów NFZ (szczegóły realizacji produktów kontraktowych) zawierający: okres (miesiąc, kwartał, półrocze, rok) nr umowy kod produktu kontraktowego nazwa produktu kontraktowego wyróżnik limit produktu kontaktowego w punktach limit produktu kontaktowego w zł cena punktu wykonanie produktu w punktach wykonanie punktów narastająco od początku roku"

17. Stan realizacji umów z NFZ (szczegóły realizacji produktów szczegółowych) zawierający: okres (miesiąc, kwartał, półrocze, rok) nazwa oddziału kod produktu szczegółowego nazwa świadczenia liczba wykonanych świadczeń liczba wykonanych punktów liczba punktów zatwierdzonych liczba hospitalizacji

18. Zestawienie wyznaczonych JGP zawierający: - okres (miesiąc, kwartał, półrocze, rok)

45


- kod i nazwa oddziału - wersja grupera - kod grupy JGP - nazwa grupy JGP - liczba pobytów - liczba pacjentów - liczba pacjentów nieubezpieczonych - średni czas pobytu

19. Raport powtórnych hospitalizacji zawierający: okres (miesiąc, kwartał, półrocze, rok) nazwa oddziału kod grupy JGP imię i nazwisko pacjenta PESEL pacjenta informacja czy hospitalizacja wystąpiła do 14 dni informacja czy hospitalizacja wystąpiła do 30 dni informacja czy hospitalizacja wystąpiła do 60 dni czy pobyt ratujący życie kod świadczenia ICD10 nazwa świadczenia nr księgi głównej tryb przyjęcia tryb wypisu kod i nazwa grupy JGP

20. Raport z obłożenia łóżek w poszczególnych oddziałach: Parametry raportu: określenie początku i końca przedziału czasu, którego raport dotyczy, Prezentowane dane: nazwa oddziału, liczba hospitalizacji w okresie, liczba łóżek, suma liczby osobodni,

% obłożenia.21. Raport produktywności łóżek szpitalnych:

Parametry raportu: określenie początku i końca przedziału czasu, którego raport dotyczy, Prezentowane dane: nazwa oddziału, liczba hospitalizacji w okresie, liczba łóżek, wartość świadczeń,

wartość świadczeń na 1 łóżko, średnia wartość hospitalizacji.22. Raport z liczby zrealizowanych porad przez osobę personelu medycznego:

Parametry raportu: określenie początku i końca przedziału czasu, którego raport dotyczy, wskazanie komórki organizacyjnej,

Prezentowane: dla każdej poradni oddzielnie: nr prawa, liczba porad w okresie, % liczby porad w stosunku do wszystkich porad w komórce.

Wykonawca założy realizację 5 dodatkowych raportów o stopniu skomplikowania podobnym do powyższych raportów zdefiniowanych w OPZ. Zakres raportów zostanie uzgodniony z Zamawiającym na etapie realizacji projektu.

Dostarczany System BI powinien spełniać następujące wymagania:


46


WYM.BI.001 Dostęp do różnych typów źródeł danych: np. XML, stron internetowych, plików Excel, baz relacyjnych, baz wielowymiarowych, itp. obsługa m.in. następujących źródeł danych: Baza Oracle, Baza Microsoft SQL Server, Oracle OLAP Option.

WYM.BI.002 Zapewnia integrację danych z różnych systemów hurtowni danych, hurtowni tematycznych, systemów transakcyjnych, gromadzonych danych operacyjnych. Wykorzystanie natywnych funkcji bazy danych : Analysis Services, Oracle, MySQL, Terradata, XML.

WYM.BI.003 Tworzenie raportu przez użytkownika bez znajomości struktury i relacji danych, z automatycznym zachowaniem właściwych połączeń i reguł

WYM.BI.004 Możliwość definiowania własnych analiz w oparciu o dane załadowane do hurtowni danych.

WYM.BI.005 Ładowanie danych do hurtowni powinno odbywać się raz na dobę na koniec dnia.

WYM.BI.006 Zakres danych ładowanych do hurtowni danych obejmuje dane niezbędne do wykonania raportów.

WYM.BI.007 Dane prezentowane na raportach pochodzą wyłącznie z systemów objętych bieżącym postępowaniem.

WYM.BI.008 Możliwość budowy i edycji raportu za pomocą standardowej przeglądarki internetowej bez konieczności znajomości języka SQL

WYM.BI.009 Możliwość zakładania filtrów na dowolną liczbę kolumn raportu

WYM.BI.010 Możliwość wizualizacji danych za pomocą wykresów

WYM.BI.011 Możliwość formatowania warunkowego raportu w zależności od danych

WYM.BI.012 Możliwość wykorzystania dowolnej kolumny raportu do filtrowania danych na uruchomionym raporcie

WYM.BI.013 Zmiana nazw kolumn na raporcie uruchomionym w przeglądarce internetowej, na dowolnie wybrane przez użytkownika nagłówki i etykiety

WYM.BI.014 Możliwość sortowania danych na raporcie po dowolnie liczbie kolumn

WYM.BI.015 Możliwość tworzenia kolumn wyliczalnych z wykorzystaniem innych kolumn raportu i podstawowych operacji arytmetycznych

WYM.BI.016 Możliwość dodawania: kolumn, wyrażeń, obliczeń w przeglądarce internetowej

WYM.BI.017 Możliwość eksportu raportów do następujących formatów: pdf, xlx, xlsx, ppt, pptx, mht, csv, xml.

WYM.BI.018 System zawiera pomoc kontekstową dla użytkowników i administratorów.

WYM.BI.019 Umożliwia proces zewnętrznej autentykacji użytkowników. Wśród wspieranych sposobów autentykacji wymagana jest co najmniej autentykacja na podstawie danych w źródle danych, wykorzystanie serwera LDAP oraz wykorzystanie rozwiązania Active Directory.

WYM.BI.020 Wspiera wielopoziomowy model bezpieczeństwa jak użytkownik, grupa, itd.

WYM.BI.021 Potrafi ograniczać zapytania wykonywane przez użytkowników, grupę użytkowników lub źródło danych.

WYM.BI.022 Pozwala na administrację zapytaniami SQL z poziomu przeglądarki internetowej.

WYM.BI.023 Pozwala na zatrzymywanie zapytań SQL (“zabijanie”) na bazie danych poprzez przeglądarkę internetową.

47


WYM.BI.024 Dostarcza graficzne narzędzie administracyjne które tworzy metadane oraz modele danych w środowisku graficznym bez potrzeby ręcznego pisania SQL.

Dostawa systemu ERP W ramach realizacji zamówienia Wykonawca dostarczy, zainstaluje skonfiguruje i wdroży system ERP wraz z bezterminowymi licencjami płatnymi jednorazowo na użytkowanie systemu spełniającego wymagania funkcjonalne i pozafunkcjonalne określone w Specyfikacji Istotnych Warunków Zamówienia (SIWZ) (cześć szara) w zakresie następujących modułów :

a. Finanse i Księgowość (wraz z Rejestrem Zakupów, Kasą i Windykacją) – licencja dla 3 użytkowników

b. Rejestr Sprzedaży – Licencja dla 2 użytkowników c. Gospodarka materiałowa- Licencja dla 2 użytkowników d. Środki Trwałe oraz Wyposażenie (wraz obsługą kolektora danych) – Licencja dla 2

użytkowników e. Kadry i Płace – Licencja dla 2 użytkowników

W ramach wdrożenia Wykonawca dokona przeniesienia danych z obecnie funkcjonujących u Zmawiającego systemów, szczegółowy zakres danych zostanie opracowany na etapie analizy przedwdrożeniowej:

1. Symfonia – System Finansowo Księgowy2. Symfonia – Magazyn3. Asseco – WF-GANG

System ERP powinien spełniać następujące wymagania ogólne:

Kod wymagania

Opis wymagania

WYM.ERP.001 Stanowiska robocze pracują w trybie graficznym, na bazie systemów: MS Windows XP lub późniejszych wersji, w wersji 32 bitowej i 64 bitowej.

WYM.ERP.002 Licencjonowanie i możliwość pracy 2 instancji:- testowej- produkcyjnej

WYM.ERP.003 System działa opcjonalnie na dwóch bazach danych: My SQL, ORACLE.

WYM.ERP.004 Umożliwia pracę w trybie klient-serwer oraz pracę terminalową.

WYM.ERP.005 System komunikuje się z użytkownikiem tylko w języku polskim, udostępniając możliwość korzystania z pomocy kontekstowej.

WYM.ERP.006 Dokumentacja użytkowa zgodna ze stanem faktycznym.

WYM.ERP.007 Zgodność z obowiązującymi aktami prawnymi w tym:- gwarantuje stałą, pełną zgodność wszelkich realizowanych funkcji/algorytmów rozliczeń/formatów sprawozdań z obowiązującym prawem regulującym prowadzenie działalności gospodarczej, prawo podatkowe rachunkowość, sprawozdawczość finansowa, prawo bankowe, działalność jednostek służby zdrowia i in.,- dostosowywanie systemu do zmian przepisów obowiązującego odbywa się z odpowiednim wyprzedzeniem,

48


WYM.ERP.008 System posiada funkcjonalności zapewniające bezpieczeństwo informacji:- posiada wbudowany mechanizm autoryzacji,- posiada mechanizmy zabezpieczające przed nieautoryzowanym dostępem,- umożliwia planowe wykonywanie kopii zapasowych danych bez konieczności wylogowania użytkowników,- posiada mechanizm rejestrowania zmian wykonywanych na obiektach systemu przez użytkowników z poziomu aplikacji.

WYM.ERP.009 System pozwala na przekazywanie wyników sprawozdań i analiz w postaci elektronicznej do modułów pakietu MS Office, system przygotowuje wyniki sprawozdań i analiz w postaci plików MS Office 2000/2003 (np. MS Excel).

WYM.ERP.010 Posiada funkcjonalność zarządzania i administrowania uprawnieniami, w szczególności: - mechanizm nadawania uprawnień funkcjonalnych do poszczególnych obszarów, działań, obiektów, dokumentów, każdemu użytkownikowi z osobna, a także zdefiniowanym grupom użytkowników,- możliwość nadawanie użytkownikom i grupom użytkowników praw do wybranych zakresów danych (np. konkretnych kont księgowych, magazynów, komórek kosztowych, szablonów dokumentów itp.),- ograniczania uprawnień do wybranych działań, obiektów, dokumentów, poszczególnym użytkownikom bądź grupom użytkowników,

Wymaganie w zakresie integracji systemu ERP z systemem HIS

Kod Opis wymagania

WYM.ERP.011

Wspólna kartoteka kontrahentów, słowniki usług, ośrodki kosztów („5” i „7”), rodzaje kosztów („4”), słownik jednostek organizacyjnych, dane personelu z kartoteki osobowej

WYM.ERP.012

Dokumenty obrotowe magazynów leków i materiałów medycznych obsługiwane przez moduł APTEKA SZPITALNA widoczne w module F-K

WYM.ERP.013

Faktury przychodowe wystawione przez moduł ROZLICZENIA Z NFZ widoczne w F-K

WYM.ERP.014

Współpraca modułu KADRY i PŁACE z modułem RCP

WYM.ERP.015

Dokumenty sprzedaży usług medycznych wystawiane bezpośrednio z modułów REJESTRACJA PRZYCHODNI lub RECEPCJA SZPITALA automatycznie widoczne w księgowości

WYM.ERP.016

Obroty na kontach w module F-K wykorzystywane przez moduł Raportów Zarządczych dla Kierownictwa

Wymagania dla modułu Finanse i Księgowość (FK) Dostarczany system powinien spełniać następujące wymagania: kod wymagania

Opis wymagania

WYM.FK.001 System umożliwia prowadzenie księgi głównej (konta syntetyczne), ksiąg pomocniczych (konta analityczne) i ewidencji pozabilansowej (konta pozabilansowe)

WYM.FK.002 Możliwość określenia różnych planów kont dla kolejnych okresów obrotowych

WYM.FK.003 Możliwość określenia sposobu budowy kodów kont analitycznych (budowy segmentów kont) dla poszczególnych kont syntetycznych

WYM.FK.004 Możliwość określenia liczby i długości segmentów kont analitycznych

WYM.FK.005 Możliwość ręcznego kodowania segmentów kont analitycznych

49


WYM.FK.006 Możliwość automatycznego kodowania segmentów kont analitycznych na podstawie zdefiniowanych przez użytkownika grup analitycznych (katalog kontrahentów, pracowników, katalog ośrodków powstawania kosztów, rodzajów kosztów, stawek VAT i inne grupy analityczne)

WYM.FK.007 Bieżąca informacja o obrotach i stanie konta, z możliwością uwzględnienia obrotów nie zaksięgowanych

WYM.FK.008 Automatyczne przenoszenie bilansu otwarcia nowego roku obrotowego na podstawie bilansu zamknięcia poprzedniego roku

WYM.FK.009 Możliwość aktualizacji bilansu otwarcia (powtórnego naliczenia) dla wybranych kont (w szczególności w pełnym zakresie)

WYM.FK.010 Możliwość definiowania grup kont dla potrzeb sprawozdawczości

WYM.FK.011 Możliwość wprowadzania planów kont, grup kont księgi głównej dla celów budżetowania

WYM.FK.012 Miesięczne prowadzenie dziennika obrotów z możliwością prowadzenia dzienników cząstkowych (rejestrów dokumentów). Numeracja dokumentów odrębnie w poszczególnych rejestrach

WYM.FK.013 Definiowanie postaci numeru dokumentu w poszczególnych dziennikach częściowych z określeniem numeracji miesięcznej lub rocznej

WYM.FK.014 Możliwość wprowadzania dokumentów z ręcznym określeniem sposobu dekretacji

WYM.FK.015 Możliwość wprowadzania dokumentów z automatycznym określeniem sposobu dekretacji, poprzez zdefiniowane przez użytkownika schematy księgowania dokumentów dla określonych kategorii operacji gospodarczych

WYM.FK.016 Wyodrębnienie dziennika cząstkowego do prowadzenia obsługi kasowej

WYM.FK.017 Ewidencja operacji kasowych (dekretacja operacji kasowych)

WYM.FK.018 Kontrola poprawności wprowadzonych dokumentów zgodnie z zasadą podwójnego zapisu

WYM.FK.019 Kontrola poprawności dekretacji zgodnej z planem kont

WYM.FK.020 Kontrola domknięcia kręgu kosztowego

WYM.FK.021 Ostrzeżenie przed dwukrotnym wprowadzeniem dokumentu

WYM.FK.022 Bezpośredni dostęp do danych historycznych z poprzednich lat podatkowych

WYM.FK.023 Mechanizmy ułatwiające wprowadzanie dokumentów

WYM.FK.024 Tworzenie dokumentu na podstawie kopii wcześniej wybranego dokumentu

WYM.FK.025 Słownik opisu dekretu podczas księgowania

WYM.FK.026 Tworzenie dekretów na podstawie zaewidencjonowanych rozrachunków (kojarzenie rozrachunków)

WYM.FK.027 Automatyczne rozksięgowanie kosztów na konta ośrodków powstawania kosztów zgodnie z określonym kluczem rozdziału

WYM.FK.028 Wspomaganie rozksięgowania kosztów przy księgowaniu równoległym w układzie rodzajowym i kalkulacyjnym oraz sprawdzenie zgodności kręgu kosztowego

WYM.FK.029 Automatyczne przeksięgowania kosztów według zdefiniowanego przez użytkownika schematu

WYM.FK.030 Wspomaganie tworzenia dokumentów związanych z międzyokresowymi rozliczeniami kosztów zgodnie ze zdefiniowanym sposobem rozdziału

WYM.FK.031 Automatyczne przeksięgowanie kont kosztowych i przychodowych na wynik finansowy

WYM.FK.032 Przenoszenie dokumentów pomiędzy dziennikami częściowymi

WYM.FK.033 Możliwość dołączenia do dokumentu i podglądu dowolnego załącznika w postaci pliku (pdf, doc, jpg)

WYM.FK.034 System umożliwia wykorzystanie dodatkowych słowników niestanowiących analityki kont przy dekretacji dokumentów (np. do ewidencji kosztów wg samochodów służbowych, urządzeń medycznych)

WYM.FK.035 Możliwość rejestracji wartości dokumentu w walucie obcej z jednoczesnym wskazaniem kursu i przeliczeniem na PLN

50


WYM.FK.036 Wyszukiwanie dokumentów według dowolnego kryterium (data, treść, konto, kwota, numer dokumentu)

WYM.FK.037 Filtrowanie wg zawartości poszczególnych kolumn, które można ze sobą łączyć

WYM.FK.038 Księgowanie w buforze (dostępność edycji w otwartym okresie sprawozdawczym)

WYM.FK.039 Zamykanie okresów sprawozdawczych (miesięcy)

WYM.FK.040 Możliwość rozpoczęcia kolejnego miesiąca bez konieczności zamykania bieżącego

WYM.FK.041 Praca jednocześnie w dwóch otwartych okresach obrotowych (księgowanie w nowym roku bez konieczności zamknięcia starego)

WYM.FK.042 Gromadzenie informacji identyfikacyjnych kontrahentów (kartoteka kontrahentów)

WYM.FK.043 Mechanizm transakcji (szczegółowej identyfikacji rozrachunków z kontrahentem)

WYM.FK.044 Możliwość syntetycznej informacji o stanie transakcji z kontrahentem

WYM.FK.045 Możliwość analitycznej informacji o stanie transakcji z kontrahentem (zapisy szczegółowe kartoteki kontrahenta)

WYM.FK.046 Możliwość przeglądu stanu i historii poszczególnych transakcji z kontrahentem

WYM.FK.047 Możliwość przeglądu zapisów szczegółowych kartoteki kontrahenta według stanu na dowolny dzień

WYM.FK.048 Tworzenie bieżących raportów o należnościach i zobowiązaniach przeterminowanych

WYM.FK.049 Parametryzacja zestawień zobowiązań i należności według okresu przeterminowania, limitu salda

WYM.FK.050 Sortowanie zestawień zobowiązań i należności według kont, obrotów, salda

WYM.FK.051 Wiekowanie należności i zobowiązań w dowolnie definiowanych przedziałach czasowych

WYM.FK.052 Możliwość oceny płatników przez sporządzanie odpowiednich raportów prezentujących odchylenia faktycznych terminów płatności w stosunku do terminów wymagalnych

WYM.FK.053 Raportowanie spodziewanego spływu należności w przyszłych przedziałach czasowych

WYM.FK.054 Planowanie zapotrzebowania środków finansowych na spłatę przyszłych zobowiązań

WYM.FK.055 Możliwość wydruku dokumentu potwierdzenia sald dla kontrahenta

WYM.FK.056 Możliwość naliczenia odsetek i wydruku dokumentu noty odsetkowej dla wybranych należności od kontrahenta (w szczególności wszystkich)

WYM.FK.057 Automatyczne księgowanie noty odsetkowej zgodnie ze zdefiniowanym szablonem

WYM.FK.058 Możliwość stosowania różnych tabel stawek odsetkowych

WYM.FK.059 Możliwość wydruku dokumentu wezwania do zapłaty

WYM.FK.060 Możliwość przeksięgowania wierzytelności z kontrahenta na kontrahenta

WYM.FK.061 Możliwość przeksięgowania rozrachunków na inne konto rozrachunkowe

WYM.FK.062 Możliwość zmiany terminu płatności transakcji

WYM.FK.063 Możliwość naliczenia odsetek od zobowiązań

WYM.FK.064 Możliwość prowadzenia rejestru kontaktów windykatorskich z wyszukiwaniem wg numeru dokumentu, daty dokumentu, daty kontaktu, rodzaju kontaktu

WYM.FK.065 Możliwość automatycznego, ale potwierdzonego przez użytkownika, wpisu kontaktu do rejestru kontaktów windykatorskich w przypadku wygenerowania pisma noty odsetkowej, pisma wezwania do zapłaty, pisma potwierdzenia sald

WYM.FK.066 Gromadzenie informacji o stanie rozrachunków z pracownikami i ich obsługa

WYM.FK.067 Mechanizm szczegółowej identyfikacji rozrachunków z pracownikami

WYM.FK.068 Gromadzenie informacji identyfikacyjnych pracowników (kartoteka pracowników)

WYM.FK.069 Możliwość syntetycznej informacji o stanie rozrachunków z pracownikiem (kartoteka pracownika)

WYM.FK.070 Możliwość analitycznej informacji o stanie rozrachunków z pracownikiem (zapisy szczegółowe kartoteki pracownika)

WYM.FK.071 Możliwość przeglądu stanu i historii poszczególnych rozrachunków z pracownikiem

51


WYM.FK.072 Ewidencja informacji kosztowych dla potrzeb rachunku kosztów w układzie rodzajowym i kalkulacyjnym

WYM.FK.073 Gromadzenie informacji o schemacie organizacyjnym zakładu – ośrodkach powstawania kosztów (katalog Ośrodków Powstawania Kosztów)

WYM.FK.074 Możliwość ewidencji kosztów na kontach księgi głównej i ksiąg pomocniczych w układzie rodzajowym

WYM.FK.075 Możliwość ewidencji kosztów na kontach księgi głównej i ksiąg pomocniczych w układzie kalkulacyjnym

WYM.FK.076 System posiada możliwość uszczegółowienia ewidencji kosztów bez konieczności rozbudowy planu kont (prowadzenie kartotek kosztów szczegółowych)

WYM.FK.077 Możliwość bieżącej i okresowej informacji o poziomie kosztów na poszczególnych ośrodkach powstawania kosztów (OPK)

WYM.FK.078 Emisja zestawień i sprawozdań określonych w ustawie o rachunkowości

WYM.FK.079 Wydruk dziennika obrotów lub dzienników cząstkowych

WYM.FK.080 Wydruk księgi głównej (zestawienie stanu kont)

WYM.FK.081 Wydruk zestawienia obrotów i sald kont księgi głównej

WYM.FK.082 Wydruk zestawienia obrotów i sald ksiąg pomocniczych

WYM.FK.083 Możliwość wydruku sprawozdań rocznych:

WYM.FK.084 Bilansu

WYM.FK.085 Sprawozdania z przepływu środków pieniężnych (metoda bezpośrednia i pośrednia)

WYM.FK.086 Rachunku zysków i strat (wariant kalkulacyjny i porównawczy)

WYM.FK.087 Sprawozdanie F-01/I-01

WYM.FK.088 Zestawienie zmian w kapitale własnym

WYM.FK.089 Możliwość eksportu raportów w formatach PDF, RTF, TXT

WYM.FK.090 Obsługa rejestrów i deklaracji VAT

WYM.FK.091 Możliwość określenia dzienników cząstkowych (rejestrów dokumentów) dla dokumentów VAT zakupu i sprzedaży

WYM.FK.092 Możliwość jednoczesnego zapisu w rejestrze VAT, w księdze głównej i rozrachunkach

WYM.FK.093 Możliwość określenia sposobu dekretacji podatku dla poszczególnych stawek VAT w rejestrze VAT

WYM.FK.094 Dekretacja zakupów i sprzedaży VAT z określeniem pól deklaracji VAT dla poszczególnych zapisów, z możliwością określenia miesiąca rozliczenia VAT

WYM.FK.095 Możliwość określenia procentowej struktury sprzedaży VAT pozwalającej na wyznaczenie wysokości VAT z zakupów z podziałem na VAT do odliczenia i niepodlegający odliczeniu

WYM.FK.096 Automatyczne przypisanie pozycji rejestru VAT do rozliczenia w określonym miesiącu niezależnie od miesiąca księgowego

WYM.FK.097 Wydruk rejestru zakupów VAT

WYM.FK.098 Wydruk rejestru sprzedaży VAT

WYM.FK.099 Wydruk danych do deklaracji (zestawienia) VAT dla sprzedaży

WYM.FK.100 Wydruk danych do deklaracji (zestawienia) VAT dla zakupów

WYM.FK.101 Wydruk podsumowania rejestrów VAT

WYM.FK.102 Możliwość automatycznego tworzenia deklaracji UE i informacji podsumowujących

WYM.FK.103 System umożliwia emisję (eksport) przelewów w formie elektronicznej do systemu bankowości elektronicznej

WYM.FK.104 System umożliwia ręczne wprowadzanie dokumentów wyciągów bankowych do dziennika FK

WYM.FK.105 System umożliwia import wyciągów bankowych w formie elektronicznej poprzez system bankowości elektronicznej (w formacie MT940 lub XML)

WYM.FK.106 Możliwość budowania arkuszy kalkulacyjnych z funkcjami obrotów i sald

52


WYM.FK.107 Wykresy graficzne obrotów i sald kont w określonym czasie

WYM.FK.108 Graficzne porównanie obrotów kont w okresach rok do roku

WYM.FK.109 System umożliwia integrację z innymi modułami systemu, realizującymi funkcjonalność następujących zakresów: fakturowanie, obsługa kasy gotówkowej, obsługa magazynu leków, obsługa środków trwałych, obsługa wynagrodzeń

WYM.FK.110 Możliwość obsługi wielu rejestrów sprzedaży

WYM.FK.111 Dostęp do wszystkich rejestrów sprzedaży w placówkach medycznych Zamawiającego

WYM.FK.112 Współpraca z systemami zewnętrznymi na poziomie dekretów do Księgi Głównej

WYM.FK.113 Współpraca z arkuszem kalkulacyjnym w formacie MS Excel poprzez udostępnienie danych o obrotach i saldach kont

Rejestr zakupu

WYM.FK.114 Moduł powinien umożliwiać prowadzenie dowolnej ilości rejestrów zakupów,

WYM.FK.115 Moduł powinien umożliwiać dostęp do Kartoteki Kontrahentów i Kartoteki Pracowników ,

WYM.FK.116 Moduł powinien umożliwiać definiowanie rejestrów zakupów wraz z powiązaniem ich z innymi rejestrami systemu FK,

WYM.FK.117 Moduł powinien umożliwiać podczas wprowadzania dokumentów zakupu do rejestru:- obsługa VAT,- określenie sposobu i terminu płatności,- określenie typu wprowadzanego dokumentu zakupu,- rejestrowanie zakupów z uwzględnieniem słownika CPV,- rejestrowanie informacji o zamówieniu na podstawie którego nastąpił zakup, umowie w ramach której nastąpił zakup, oraz dokumentach przyjęć magazynowych. Możliwość importu pozycji z zamówienia lub przyjęcia magazynowego zarejestrowanych w innych zakresach funkcjonalnych systemu jako pozycji dla rejestrowanego zakupu,- określenie rozdziału stosunku wpływów z zakupów na ośrodki powstawania kosztów,- wprowadzenie sposobu otrzymania dokumentu zakupu, w przypadku otrzymania pocztą elektroniczną możliwość zarejestrowania informacji o adresie nadawcy ,

WYM.FK.118 Moduł powinien umożliwiać rejestrowanie zmian terminów płatności wraz z podaniem podstawy wykonania zmiany,

WYM.FK.119 Moduł powinien umożliwiać współpracę z zakresem Finansowo-Księgowym na poziomie dekretów do Księgi Głównej,

WYM.FK.120 Moduł powinien umożliwiać generowanie zestawień na podstawie wprowadzonych dokumentów zakupów: rejestr zakupów, zestawienia dokumentów zakupu,

WYM.FK.121 Moduł powinien umożliwiać śledzenie historii wypożyczeń faktur zakupowych w ramach jednostki,

WYM.FK.122 Moduł powinien umożliwiać monitorowanie osób/jednostek odpowiedzialnych za wypożyczone dokumenty,

WYM.FK.123 Moduł powinien umożliwiać wstępne zarejestrowanie wpływu faktury zakupowej i wskazanie jednostki odpowiedzialnej za jej opracowanie, a także informacji o zwrocie faktury,

WYM.FK.124 Moduł powinien umożliwiać import dokumentów zakupowych zarejestrowanych w innych zakresach funkcjonalnych systemu np. Apteka Centralna, Apteka Oddziałowa.

Wymagania dla modułu Rejestr Sprzedaży Dostarczany moduł powinien spełniać następujące wymagania


53


WYM.RSP.001Moduł powinien umożliwiać obsługę transakcji krajowych i zagranicznych (eksport, dostawy i wewnątrzunijne)

WYM.RSP.002 Moduł powinien umożliwiać obsługę wielu rejestrów sprzedaży

WYM.RSP.003 Moduł powinien umożliwiać wystawianie faktur dla pracowników – wykorzystanie KARTOTEKI OSOBOWEJ systemu kadrowo – płacowego

WYM.RSP.004 Moduł powinien umożliwiać wystawianie faktur dla odbiorcy jednorazowego

WYM.RSP.005 Moduł powinien umożliwiać prowadzenie KARTOTEKI ASORTYMENTOWEJ - kartoteka zawiera dane identyfikacyjne (indeks) i opisowe (nazwa, jm, PKWIU, SWW, PKOB, waga, powierzchnia, kod PCN, producent itp.), siedem poziomów cen, akcyza procentowa i kwotowa, kody kreskowe) sprzedawanych towarów i usług

WYM.RSP.006 Moduł powinien umożliwiać wykorzystanie KARTOTEKI INDEKSÓW MATERIAŁOWYCH oraz KARTOTEKI ŚRODKÓW TRWAŁYCH podczas fakturowania

WYM.RSP.007 Moduł powinien umożliwiać definiowanie elastycznego systemu rabatów

WYM.RSP.008 Moduł powinien umożliwiać wystawianie dokumentów sprzedażowych dowolnego typu - użytkownik ma możliwość definiowania typów faktur poprzez określenie następujących cech dokumentu: kod, nazwa , kierunek sprzedaży (kraj, eksport, dostawy unijne), typ dokumentu (faktura zaliczkowa, PROFORMA, dokument WZ ) itp.

WYM.RSP.009 Moduł powinien umożliwiać definiowanie przez użytkownika wyglądu faktury

WYM.RSP.010 Moduł powinien umożliwiać wystawianie faktur zbiorczych

WYM.RSP.011 Moduł powinien umożliwiać wystawianie faktur VAT RR (dla rolników ryczałtowych)

WYM.RSP.012 Moduł powinien umożliwiać wydruk dokumentu TAX FREE

WYM.RSP.013 Moduł powinien umożliwiać automatyczne generowanie faktur korygujących z faktur źródłowych

WYM.RSP.014 Moduł powinien umożliwiać automatyczne generowanie faktur z zamówień, faktur PROFORMA i innych typów faktur

WYM.RSP.015 Moduł powinien umożliwiać rozliczanie faktur zaliczkowych

WYM.RSP.016 Moduł powinien umożliwiać sprzedaż ratalną

WYM.RSP.017 Moduł powinien umożliwiać wystawianie faktur w dowolnej walucie

WYM.RSP.018 Moduł powinien umożliwiać wydruk faktury w języku angielskim

WYM.RSP.019 Moduł powinien umożliwiać eksport faktury do pliku XML

WYM.RSP.020 Moduł powinien umożliwiać wysyłanie faktur mailem

WYM.RSP.021 Moduł powinien umożliwiać prowadzenie rejestrów ewidencji VAT

WYM.RSP.022 Moduł powinien umożliwiać generowanie zestawień ze sprzedaży w formie tabelarycznej i graficznej

WYM.RSP.023 Moduł powinien umożliwiać eksport danych do EXCEL-a

WYM.RSP.024 Moduł powinien umożliwiać rozliczenie doradców klienta wg różnych kryteriów

WYM.RSP.025 Moduł powinien umożliwiać obsługę drukarki fiskalnej

WYM.RSP.026 Moduł powinien umożliwiać obsługę czytnika kodów kreskowych

WYM.RSP.027 Moduł powinien umożliwiać automatyczne przenoszenie danych o sprzedaży do programu finansowo-księgowego wraz z właściwym dekretem

Kasa

WYM.RSP.028 Możliwość obsługi wielu stanowisk kasowych

WYM.RSP.029 Możliwość dedykowania stanowisk kasowych do placówek medycznych

54


WYM.RSP.030 Dostęp do raportów kasowych wszystkich stanowisk

WYM.RSP.031 Dostęp do katalogu kontrahentów i pracowników zintegrowany z systemem Finansowo-Księgowym

WYM.RSP.032

Dostęp do katalogu pacjentów zintegrowanego z medycznymi zakresami funkcjonalnymi systemu

WYM.RSP.033

Automatyczne tworzenie raportu kasowego - praca w kontekście raportu kasowego

WYM.RSP.034 Możliwość prowadzenia jednocześnie kliku raportów kasowych z rozróżnieniem typu dla każdego z raportów

WYM.RSP.035

Wprowadzanie dokumentów operacji kasowych: gotówkowych, bezgotówkowych (np. karty płatnicze), walutowych,

WYM.RSP.036

Praca kasjera zawsze w kontekście otwartego raportu kasowego

WYM.RSP.037 Operacje otwarcia/zamknięcia raportu kasowego

WYM.RSP.038 Wprowadzanie dokumentów z ręcznym określeniem sposobu dekretacji FK

WYM.RSP.039 Automatyczne określenie sposobu dekretacji dokumentów kasowych

WYM.RSP.040 Wydruk dokumentów kasowych: raportu kasowego, rejestrów kasowych VAT, rejestru zakupów kasowych, rejestru sprzedaży kasowych, dokumentu KP, dokumentu KW

WYM.RSP.041

Wydruk raportu kasowego

WYM.RSP.042 Bieżące i wsteczne zestawienia stanu kasy na podstawie bieżących obrotów i raportów kasowych

WYM.RSP.043 Możliwość zapisu wartościowego operacji kasowych na kontach księgi głównej i ksiąg pomocniczych w module realizującym funkcjonalność w zakresie FK zgodnie z określonym sposobem dekretacji

Wymagania dla modułu Środki Trwałe oraz Wyposażenie (wraz obsługą kolektora danych) Kod wymagania

Opis wymagania

WYM.STR.001 Możliwość prowadzenie ewidencji majątku w podziale na: - własne środki trwałe - obce środki trwałe - wartości niematerialne i prawne - niskocenne środki trwałe - inwestycje w obcych środkach trwałych. - wyposażenie

55


WYM.STR.002 Prowadzenie kartoteki środków trwałych. Opis środka zawiera następujące informacje: - numer inwentarzowy - nazwa środka - grupa rodzajowa zgodna z Klasyfikacją Rodzajową Środków Trwałych - okres w którym środek użytkowany jest sezonowo - data produkcji - data przyjęcia do użytkowania - stawka amortyzacyjna, sposób amortyzacji - aktualna wartość brutto - aktualna wartość umorzeń - konta księgowe, miejsce powstawania kosztów - miejsce użytkowanie - źródło finansowania - kategoria - osoba odpowiedzialna - okres, w którym zostaje zawieszone naliczanie amortyzacji dla środka - przyczyna zawieszenia naliczania amortyzacji - okres, w którym środek podlega uldze inwestycyjnej - data ostatniej modyfikacji wartości środka - data całkowitego umorzenia środka - opis środka dowolnej długości - opis techniczny: numer fabryczny, numer silnika, numer nadwozia, termin następnego przeglądu , numer rejestracyjny- dane o zakupie : numer i data wystawienia faktury zakupowej, data zapłaty za fakturę, wartość netto i brutto faktury, nazwa dostawcy- ubezpieczenie: numer polisy ubezpieczeniowej, kwota polisy, termin zapłaty ubezpieczenia

WYM.STR.003 Możliwość dołączenia do kartoteki środka trwałego listy zewnętrznych plików powiązanych ze środkiem (zdjęcia, instrukcje, obsługi, karty gwarancyjne, faktury itp), możliwość przeglądania treści dokumentów lub ich edycja

WYM.STR.004 Wydruk etykiet z kodami kreskowymi, obsługa czytnika kodów kreskowych i kolektora danych

WYM.STR.005 Możliwość uzyskania informacji o stanie składników majątku trwałego - wydruk informacji z kartotek składników majątku w różnych układach i na dowolny dzień (np. wg grup rodzajowych, kategorii, miejsc użytkowania, źródeł finansowania, użytkowników)

WYM.STR.006 Możliwość generowania zestawień: - amortyzacja wg grup rodzajowych - amortyzacja w kont - umorzenia wg grup - umorzenia wg kont - przychód i rozchód środków trwałych wg kont i wg dokumentów - rozdzielnik amortyzacji wg miejsc powstawania kosztów - dokumentów obrotowych w różnych układach - środków umorzonych w okresie - wyodrębnień

WYM.STR.007 Tworzenie planu amortyzacji na dowolny okres wg grup rodzajowych lub kont kosztowych

WYM.STR.008 Możliwość przygotowania i wydruku dokumentów obrotowych (przyjęcie z inwestycji, przyjęcie nieodpłatne, aport, zwiększenie wartości środka, zmniejszenie wartości środka, sprzedaż, przekazanie nieodpłatne, likwidacja częściowa, wyodrębnienie, zmiana miejsca użytkowania)

WYM.STR.009 Możliwość wystawienia dokumentu korekty umorzenia i amortyzacji

WYM.STR.010 Możliwość tworzenia harmonogramów przeglądów.

WYM.STR.011 Możliwość tworzenia harmonogramów płatności ubezpieczeń

WYM.STR.012 Przygotowanie tabel amortyzacyjnych bilansowej i podatkowej

WYM.STR.013 Możliwość wprowadzenia bilansu otwarcia ilościowo-wartościowego stanu majątku trwałego na dzień startu systemu

WYM.STR.014 Naliczenia odpisów umorzeniowych składników majątku trwałego

56


WYM.STR.015 Wspieranie obsługi inwentaryzacji poprzez przygotowanie i wydruk arkusza spisu z natury , wykorzystanie kolektora danych

WYM.STR.016 Generowanie protokołów rozliczających inwentaryzację

WYM.STR.017 Możliwość wymiany danych z innymi programami (Finansowo-Księgowym, Gospodarka Materiałowa)

WYM.STR.018 Możliwość eksportu danych do EXCELA

WYM.STR.019 Możliwość podglądu zestawień na ekranie przed wydrukowaniem oraz eksportu zestawienia do plików PDF, RTF, TXT, EXCEL

Wymagania dla modułu gospodarka materiałowa

Kod wymagania

Opis wymagania

WYM.GM.001 Możliwość obsługi wielu magazynów

WYM.GM.002 Możliwość określenia asortymentu materiałów ewidencjonowanych w poszczególnych magazynach

WYM.GM.003 Elastyczne tworzenie indeksu materiałowego- dowolna budowa kodu indeksu materiałowego (ograniczenie jedynie na długość kodu)

WYM.GM.004 Możliwość przyporządkowania kodów klasyfikacyjnych (PKWiU, CPV)

WYM.GM.005 Obsługa kilku metod wyceny rozchodów materiałów: - ceny rzeczywiste LIFO- ceny rzeczywiste FIFO - ceny średnioważone - ceny ewidencyjne

WYM.GM.006 Ewidencja obrotu materiałowego w cyklu miesięcznym (prowadzenie dzienników wprowadzonych dokumentów)

WYM.GM.007 Rejestracja bilansu otwarcia dla magazynów - ilościowo-wartościowego stanu zapasów materiałowych na dzień rozpoczęcia pracy

WYM.GM.008 Korekty bilansu otwarcia: możliwość automatycznej korekty rozchodów dokonanych z bilansu otwarcia

WYM.GM.009 Ewidencja przychodów materiałów - różne typy przyjęcia (osobne typy dokumentów) np. związanych z różnymi typami działalności

WYM.GM.010 Korekty przychodów (ilościowe i wartościowe) - możliwość automatycznej korekty rozchodów dokonanych na podstawie skorygowanych dostaw

WYM.GM.011 Ewidencja rozchodów materiałów zgodnie z przyjętym sposobem wyceny - różne typy rozchodów (osobne typy dokumentów) np. związanych z różnymi typami działalności

WYM.GM.012 Możliwość powiązania dokumentów rozchodu materiałów z ośrodkami powstawania kosztów dla celów rachunku kosztów

WYM.GM.013 Dokument korekty rozchodów

WYM.GM.014 Ewidencja rozchodów zewnętrznych - możliwość ewidencjonowania różnych typów rozchodów (osobne typy dokumentów) np. ze względu na przyczynę przekazania materiałów

WYM.GM.015 Ewidencja zwrotów od odbiorcy

WYM.GM.016 Ewidencja przesunięć międzymagazynowych materiałów

WYM.GM.017 Wydruki dokumentów związanych z obrotem materiałowym

57


WYM.GM.018 Wspieranie obsługi inwentaryzacji stanów magazynowych: - przygotowanie i wydruk arkuszy spisu z natury - możliwość prowadzenia rzeczywistych wartości stanów magazynowych na podstawie spisu z natury i ich porównanie z wartościami księgowymi - możliwość rozliczenia różnic inwentaryzacyjnych – dokument niedoborów - możliwość rozliczenia różnic inwentaryzacyjnych – dokument nadwyżek

WYM.GM.019 Bieżąca informacja o stanach magazynowych: - podgląd i wydruk historii obrotu materiałowego dla poszczególnych asortymentów materiałów - podgląd i wydruk stanów magazynowych dla wybranych lub wszystkich magazynów - kontrola przekroczenia stanów minimalnych

WYM.GM.020 Wykazy i zestawienia: - na podstawie rozchodów: dla wybranych materiałów, dla wybranych grup materiałów - na podstawie przychodów: dla wybranych materiałów, dla wybranych grup materiałów, dla wybranych rodzajów kosztów

WYM.GM.021 Zestawienia dokumentów zaewidencjonowanych dla poszczególnych magazynów

WYM.GM.022 Karta materiałowa: ilościowa i ilościowo-wartościowa

WYM.GM.023 Wspieranie obsługi zamówień zewnętrznych

WYM.GM.024 Analizy zużycia: - wyliczanie daty, po upływie której skończy się bieżący zapas materiału (na podstawie średniego zużycia za wybrany okres czasu) - tworzenie wykazów towarów, których zapas wystarczy na dłużej niż zadana ilość dni

Wymagania dla modułu kadry i płace

Kod wymagania

Kadry i Płace

WYM.KP.001 Kartoteka pracowników z podstawowymi danymi: nr ewidencyjny, nazwisko i imiona, data zatrudnienia, podstawowe miejsce zatrudnienia, rodzaj pracy - z możliwością filtrowania po wybranych informacjach

WYM.KP.002 Dane personalne pracowników

WYM.KP.003 Dane meldunkowe zawierające 3 adresy uwzględniające podział terytorialny kraju (zameldowania, zamieszkania, do korespondencji i poczty elektronicznej)

WYM.KP.004 Słowniki terytorialne województwo, powiatów, gmin, miejscowości aktualizowane ze stron GUS

WYM.KP.005 Informacje o poziomie wykształcenia pracownika, tytule i stopniu naukowym, zawodach: wykonywanym i wyuczonych

WYM.KP.006 Informacje o trwających lub zakończonych kursach i studiach dokształcających

WYM.KP.007 Informacje o trwających i zakończonych specjalizacjach zawodowych,

WYM.KP.008 Informacje o posiadanych uprawnieniach do wykonywania czynności zawodowych,

WYM.KP.009 Informacje o posiadanym prawie do wykonywania zawodu

WYM.KP.010 Informacje o znajomości języków obcych

WYM.KP.011 Informacje o członkach rodziny pracownika (dzieci, współmałżonek) z informacją potrzebną do zgłoszenia do ubezpieczenia (adres, pesel)

WYM.KP.012 Informacje o stosunku do służby wojskowej

WYM.KP.013 Informacje o posiadanych kontach ROR z możliwością określenia (procentowego lub kwotowego) wysokości przelewanych wypłat na poszczególne konta ROR

WYM.KP.014 Informacje określające dane związane z przepisami prawa podatkowego i ubezpieczeniowego

WYM.KP.015 Informacje o stopie podatku dochodowego, kosztach uzyskania przychodu, ulgach podatkowych

WYM.KP.016 Informacje o ubezpieczeniach społecznych pracownika

WYM.KP.017 Informacja o przynależności do urzędu skarbowego

58


WYM.KP.018 Możliwość definiowania własnych dodatkowych informacji wg potrzeb działu kadr lub płac

WYM.KP.019 Dołączanie dowolnych zeskanowanych dokumentów lub innych dokumentów w formie elektronicznej dla każdego pracownika z możliwością szybkiego podglądu i edycji

WYM.KP.020 Informacje kodzie ubezpieczenia oraz nabytych prawach do świadczeń emerytalno-rentowych,

WYM.KP.021 Informacje o przysługującym urlopie wypoczynkowym oraz o wypoczynkowym dodatkowym: automatyczne wyliczanie urlopu w dniach i godzinach w zależności od normy dobowej czasu pracy pracownika, możliwość planowania urlopów

WYM.KP.022 Informacje o aktualnej umowie o pracę, warunkach płacowych (z możliwością przeglądania danych historycznych), z określonym podziałem procentowym etatu w podstawowym miejscu zatrudnienia i dodatkowych miejscach zatrudnienia oraz przypisanych kont kosztowych miejscom zatrudnienia.

WYM.KP.023 Informacje o stanowisku pracy, zawodzie, z informacją o klasyfikacji zawodów i specjalności

WYM.KP.024 Przynależność do grupy i podgrupy zatrudnienia - personel

WYM.KP.025 Dane historyczne o świadectwach pracy z poprzednich zakładów pracy oraz o umowach zawartych w tym zakładzie pracy z możliwością zaznaczania jak zaliczać dany staż, liczenie stażu pracy ze świadectw pracy i z obecnego zakładu, automatyczne wyliczanie dodatku stażowego

WYM.KP.026 Dane historyczne o zmianach warunków płacowych pracownika

WYM.KP.027 Dane historyczne o zmianach stanowisk pracy pracownika

WYM.KP.028 Dane historyczne o zmianach dobowego wymiaru czasu pracy pracownika

WYM.KP.029 Dane historyczne o zmianach podstawowego miejsca zatrudnienia i wykonywania pracy

WYM.KP.030 Dane historyczne zmian grupy i podgrupy zatrudnienia

WYM.KP.031 Dane historyczne o przyznanych nagrodach i świadczeniach socjalnych pracownika

WYM.KP.032 Informacje o pracy w szczególnych warunkach

WYM.KP.033 Informacje o okresowych, wstępnych, kontrolnych i specjalistycznych badaniach lekarskich pracowników

WYM.KP.034 Informacja o odbytych kursach BHP i PPOŻ

WYM.KP.035 Informacje o karach porządkowych

WYM.KP.036 Ocena okresowa pracownika

WYM.KP.037 Informacje o okresach nieobecności pracownika, informowanie o łącznej ilości dni zwolnienia chorobowego w danym roku oraz informowanie o ukończonym 50 roku życia. Automatyczna kontrola 33/14 dni zwolnień chorobowych płatnych przez zakład pracy

WYM.KP.038 Prowadzenie ewidencji czasu pracy pracowników - miesięczna i roczna karta ewidencji czasu pracy dla poszczególnych grup zatrudnienia (administracja, lekarze pielęgniarki itp.) zgodnie z wymogami prawa pracy

WYM.KP.039 Możliwość przygotowania i eksportu deklaracji zgłoszeniowej do programu ZUS - Płatnik.

WYM.KP.040 Możliwość definiowania własnych szablonów pism i druków dla pracownika wykorzystujących dane zawarte w systemie, możliwość wydruków seryjnych wybranego pisma dla określonej grupy pracowników

WYM.KP.041 Sprawozdania statystyczne GUS, ZUS i MZ zgodnie z powszechnie obowiązującymi przepisami prawa

WYM.KP.042 Analizy liczenia zatrudnienia, wykształcenia, struktury wiekowej, stażu pracy, absencji i czasu pracy na potrzeby GUS

WYM.KP.043 Możliwość własnego tworzenia szablonów wykazów pracowników spełniających zadane kryteria

WYM.KP.044 Możliwość eksportu każdego wydruku do formatu: pdf, xls, csv, txt

WYM.KP.045 Kartoteki osób zatrudnionych na umowy cywilno-prawne (umowa zlecenie, dzieło, kontrakt itp.)

WYM.KP.046 Kartoteka kart zbliżeniowych

WYM.KP.047 Możliwość aktywowania i deaktywowania przypisanej pracownikowi karty zbliżeniowej

WYM.KP.048 Możliwość wydruku dowolnej ilości kart zbliżeniowych dla pracownika

59


WYM.KP.049 Automatyczne przekazanie statusu kart zbliżeniowych do RCP

WYM.KP.050 Dodatkowa kartoteka pozostałych osób (wolontariat, studia doktoranckie, specjalizacja itp.)

Płace:

WYM.KP.051 Możliwość dowolnego definiowania składników płacowych i określania sposobu ich naliczania

WYM.KP.052 Możliwość definiowania szablonów list wypłat (miesięcznych, dodatkowych, umów cywilno-prawnych)

WYM.KP.053 Symulacja list wypłat

WYM.KP.054 Tworzenie podstawowych list wypłat miesięcznych wg szablonów list wypłat

WYM.KP.055 Automatyczne naliczenie wynagrodzeń pracowników na podstawie danych podatkowych i danych przygotowanych do list płacowych

WYM.KP.056 Naliczenie przychodów

WYM.KP.057 Naliczenie potrąceń wynikających z zobowiązań spłat raty kredytów wobec kas pożyczkowych, ubezpieczenia, zajęć komorniczych , z tytułu przynależności do związków zawodowych oraz innych organizacji, ….

WYM.KP.058 Naliczenie składek na ubezpieczenie społeczne

WYM.KP.059 Naliczenie składek na ubezpieczenie zdrowotne

WYM.KP.060 Naliczenie podatków

WYM.KP.061 Naliczenie odsetek ustawowych za nieterminowe wypłaty wynagrodzeń i zasiłków z ubezpieczenia chorobowego i wypadkowego

WYM.KP.062 Bieżąca kontrola i sygnalizacja poprawności dokonywanych naliczeń

WYM.KP.063 Możliwość ręcznej korekty, uzupełnienia wyliczeń dokonanych automatycznie

WYM.KP.064 Tworzenie dowolnej liczby list wypłat dodatkowych dla pracowników

WYM.KP.065 Tworzenie list wypłat korekcyjnych - korekta wynagrodzeń i zasiłków, korekta podstaw i wysokości składek na ubezpieczenia społeczne, zdrowotne, Fundusz Pracy i GFŚP - dotyczy wcześniej sporządzonych list płac

WYM.KP.066 Tworzenie list wypłat dla osób zatrudnionych na umowach cywilno-prawnych

WYM.KP.067 Możliwość dowolnej korekty na listach wypłat

WYM.KP.068 Możliwość dowolnego modyfikowania składników płacowych wybranym pracownikom z listy

WYM.KP.069 Możliwość grupowej zmiany danego składnika płacowego z listy wypłat

WYM.KP.070 Możliwość pobierania danych godzinowych z rozliczenia czasu pracy

WYM.KP.071 Możliwość rozliczania poszczególnych typów nieobecności na potrzeby naliczeń na liście wypłat

WYM.KP.072 Zatwierdzanie list wypłat z opcją zamykania miesiąca płacowego

WYM.KP.073 Możliwość przygotowania przelewów w formie elektronicznej dla programów bankowych

WYM.KP.074 Przygotowanie i eksport danych dla PFRON

WYM.KP.075 Przygotowanie i eksport danych do Urzędów Skarbowych wg podziału terytorialnego (e-deklaracje)

WYM.KP.076 Możliwość przygotowania i eksportu dokumentów rozliczeniowych ZUS do programu ZUS - Płatnik.

WYM.KP.077 Prowadzenie kart wynagrodzeń pracowników

WYM.KP.078 Automatyczne tworzenie kart wynagrodzeń w momencie naliczania listy wypłat

WYM.KP.079 Tworzenie rozdzielników kosztów z przekazywaniem ich do systemu finansowo-księgowego

WYM.KP.080 Wydruk podstawowych zestawień: listy wypłat, paski wynagrodzeń, karta wynagrodzeń pracownika, karta zasiłkowa, karta ubezpieczeniowa, karta wypadkowa, zaświadczenia o wynagrodzeniu, zestawień z list wypłat

WYM.KP.081 Formularze rozliczeniowe PIT

WYM.KP.082 Kontrola przekroczenia przez pracownika progów podatkowych

WYM.KP.083 Możliwość wypłaty dofinansowań z ZFŚS z kontrolą kwoty wolnej od podatku.

60


WYM.KP.084 Możliwość prowadzenia Kasy Zapomogowo-Pożyczkowej z automatycznym potrącaniem rat na listach wypłat

Kasa Zapomogowo-Pożyczkowa, Fundusz mieszkaniowy i Fundusz socjalny:

WYM.KP.085 Prowadzenie kartotek pożyczek, list spłat i pobrań pożyczek, listy potrąceń;

WYM.KP.086 Bilans otwarcia/zamknięcia roku na kartotekach pożyczek

WYM.KP.087 Współpraca z bankowością elektroniczną

WYM.KP.088 Prowadzenie księgowości na potrzeby kasy

WYM.KP.089 Zestawienie obrotów na kontach

WYM.KP.090 Obroty wybranego konta

WYM.KP.091 Raporty kasowe

WYM.KP.092 Rejestracja wypłat i dofinansowań z Funduszu Świadczeń Socjalnych

WYM.KP.093 Współpraca z modułem KADRY-PŁACE

Portal Pracowniczy

WYM.KP.094 Dane osobowe:- dane osobowe - adresy - wykształcenie - badania, kursy BHP/PPOŻ - rodzina

WYM.KP.095 Zatrudnienie- umowy o pracę - staż pracy, nagrody - zaświadczenia o zatrudnieniu, zarobkach

WYM.KP.096 Wynagrodzenie- paski wynagrodzeń - karta roczna wynagrodzeń - świadczenia socjalne - kasa zapomogowo-pożyczkowa - deklaracje podatkowe

WYM.KP.097 Czas pracy- harmonogram czasu pracy - roczna karta pracy - absencje - urlopy - wnioski urlopowe

Elektroniczna Dokumentacja Medyczna (EDM)Dostarczany moduł EDM w zakresie dokumentacji medycznej ma być zgodny Ustawą z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta oraz rozporządzeniem Ministra Zdrowia z dnia 9 listopada 2015 r. w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania. Oznacza to, ze dostarczany system powinien spełniać następujące wymagania:


WYM.EDM.001 System umożliwia prowadzenie dokumentacji elektronicznej i zapewnia:

WYM.EDM.002 1) zabezpieczenie dokumentacji przed uszkodzeniem lub utratą;

WYM.EDM.003 2) zachowanie integralności i wiarygodności dokumentacji;

61


WYM.EDM.004 3) stały dostęp do dokumentacji dla osób uprawnionych oraz zabezpieczenie przed dostępem osób nieuprawnionych;

WYM.EDM.005 4) identyfikację osoby udzielającej świadczeń zdrowotnych i rejestrowanych przez nią zmian, w szczególności dla odpowiednich rodzajów dokumentacji przyporządkowanie cech informacyjnych;

WYM.EDM.006 5) udostępnienie, w tym przez eksport w postaci elektronicznej dokumentacji albo części dokumentacji będącej formą dokumentacji określonej w rozporządzeniu, w formacie XML i PDF;

WYM.EDM.007 6) eksport całości danych w formacie XML, w sposób zapewniający możliwość odtworzenia tej dokumentacji w innym systemie teleinformatycznym;

WYM.EDM.008 7) wydrukowanie dokumentacji w formach określonych w rozporządzeniu

WYM.EDM.009 System dla dokumentacji prowadzonej w formie elektronicznej:

WYM.EDM.010 1) zapewnia jej dostępność wyłącznie dla osób uprawnionych;

WYM.EDM.011 2) chroni przed przypadkowym lub nieuprawnionym zniszczeniem;

WYM.EDM.012 3) stosuje metody i środki ochrony dokumentacji, których skuteczność w czasie ich zastosowania jest powszechnie uznawana

WYM.EDM.013 Dokumentację stanowi:

WYM.EDM.014 1) dokumentacja indywidualna — odnosząca się do poszczególnych pacjentów korzystających ze świadczeń zdrowotnych;

WYM.EDM.015 2) dokumentacja zbiorcza — odnosząca się do ogółu pacjentów lub określonych grup pacjentów korzystających ze świadczeń zdrowotnych

WYM.EDM.016 Dokumentacja indywidualna obejmuje:

WYM.EDM.017 1) dokumentację indywidualną wewnętrzną — przeznaczoną na potrzeby Zamawiającego;

WYM.EDM.018 2) dokumentację indywidualną zewnętrzną — przeznaczoną na potrzeby pacjenta korzystającego ze świadczeń zdrowotnych udzielanych przez Zamawiającego

WYM.EDM.019 Dokumentację indywidualną wewnętrzną stanowią w szczególności:

WYM.EDM.020 1) historia zdrowia i choroby;

WYM.EDM.021 2) historia choroby;

WYM.EDM.022 3) karta indywidualnej opieki pielęgniarskiej

WYM.EDM.023 Dokumentację indywidualną zewnętrzną stanowią w szczególności:

WYM.EDM.024 1) skierowanie do szpitala lub innego podmiotu udzielającego świadczeń zdrowotnych;

WYM.EDM.025 2) skierowanie na badanie diagnostyczne lub konsultację;

WYM.EDM.026 3) zaświadczenie, orzeczenie, opinia lekarska;

WYM.EDM.027 4) karta informacyjna z leczenia szpitalnego

WYM.EDM.028 W dokumentacji indywidualnej wewnętrznej system umożliwia dokonania wpisu o wydaniu dokumentacji indywidualnej zewnętrznej lub załączenia jej kopii

WYM.EDM.029 System umożliwia dokonanie wpisu w dokumentacji niezwłocznie po udzieleniu świadczenia zdrowotnego, w sposób czytelny i w porządku chronologicznym

WYM.EDM.030 Każdy wpis w dokumentacji system opatruje oznaczeniem osoby dokonującej wpisu. System opatruje dokumentację oznaczeniem osoby udzielającej świadczeń zdrowotnych. Minimalny zakres danych dla tych oznaczeń zawiera:

WYM.EDM.031 a) nazwisko i imię,

WYM.EDM.032 b) tytuł zawodowy,

WYM.EDM.033 c) uzyskane specjalizacje,

WYM.EDM.034 d) numer prawa wykonywania zawodu — w przypadku lekarza, pielęgniarki i innych zawodów medycznych, dla których wymagane jest PWZ

62


WYM.EDM.035 Wpis dokonany w dokumentacji nie może być z niej usunięty, a jeżeli został dokonany błędnie, system umożliwia tworzenie historii zmian i naniesienie adnotacji o przyczynie błędu oraz daty i oznaczenie osoby dokonującej adnotacji

WYM.EDM.036 W przypadku sporządzania wydruku z dokumentacji prowadzonej w postaci elektronicznej, strony wydruku są numerowane

WYM.EDM.037 W przypadku sporządzania wydruku z dokumentacji indywidualnej prowadzonej w postaci elektronicznej, każda strona wydruku oznaczona jest co najmniej imieniem i nazwiskiem pacjenta

WYM.EDM.038 Jeżeli nie jest możliwe ustalenie tożsamości pacjenta, w dokumentacji istnieje możliwość oznaczenia „NN”, z podaniem przyczyny i okoliczności uniemożliwiających ustalenie tożsamości

WYM.EDM.039 Do dokumentacji indywidualnej wewnętrznej możliwe jest włączenie kopii przedstawionej przez pacjenta dokumentacji lub wprowadzenia adnotacji zawartych w niej informacji istotnych dla procesu diagnostycznego, leczniczego lub pielęgnacyjnego

WYM.EDM.040 Dokument włączony w systemie do dokumentacji indywidualnej wewnętrznej nie może być z niej usunięty

WYM.EDM.041 Nazwa i numer statystyczny rozpoznania choroby, problemu zdrowotnego lub urazu są wpisywane w dokumentacji według Międzynarodowej Statystycznej Klasyfikacji Chorób i Problemów Zdrowotnych Rewizja Dziesiąta

WYM.EDM.042 System umożliwia prowadzenie dokumentacji indywidualnej wewnętrznej i zamieszczania w niej lub dołączania do niej:

WYM.EDM.043 1) cyfrowo odwzorowane oświadczenie pacjenta o upoważnieniu osoby bliskiej do uzyskiwania informacji o jego stanie zdrowia i udzielonych świadczeniach zdrowotnych, ze wskazaniem imienia i nazwiska osoby upoważnionej oraz danych umożliwiających kontakt z tą osobą, albo oświadczenie o braku takiego upoważnienia

WYM.EDM.044 2) cyfrowo odwzorowane oświadczenie pacjenta o upoważnieniu osoby bliskiej do uzyskiwania dokumentacji, ze wskazaniem imienia i nazwiska osoby upoważnionej, albo oświadczenie o braku takiego upoważnienia;

WYM.EDM.045 3) cyfrowo odwzorowane oświadczenie pacjenta o wyrażeniu zgody albo zezwolenie sądu opiekuńczego na przeprowadzenie badania lub udzielenie innego świadczenia zdrowotnego, na zasadach określonych w rozdziale 5 ustawy z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta

WYM.EDM.046 System osobie kierującej na badanie lub konsultację umożliwia zarejestrowanie na potrzeby przekazania podmiotowi, do którego kieruje pacjenta, wraz ze skierowaniem, informacji z dokumentacji indywidualnej wewnętrznej pacjenta niezbędnych do przeprowadzenia tego badania lub konsultacji

WYM.EDM.047 System umożliwia przeprowadzającemu badanie lub konsultację zarejestrowanie na potrzeby przekazania podmiotowi, który wystawił skierowanie, wyników tych badań lub konsultacji

WYM.EDM.048 System umożliwia Zamawiającemu rejestrowanie, prowadzenie danych w postaci elektronicznej niezbędnych, aby sporządzić w szczególności:

WYM.EDM.049 1) dokumentację indywidualną wewnętrzną w formie historii choroby;

WYM.EDM.050 2) dokumentację zbiorczą wewnętrzną w formie:

WYM.EDM.051 a) księgi głównej przyjęć i wypisów,

WYM.EDM.052 b) księgi odmów przyjęć i porad ambulatoryjnych udzielanych w izbie przyjęć,

WYM.EDM.053 c) listy oczekujących na udzielenie świadczenia zdrowotnego,

63


WYM.EDM.054 d) księgi chorych oddziału,

WYM.EDM.055 e) księgi raportów lekarskich,

WYM.EDM.056 f) księgi raportów pielęgniarskich,

WYM.EDM.057 g) księgi zabiegów,

WYM.EDM.058 h) księgi bloku operacyjnego albo sali operacyjnej,

WYM.EDM.059 i) księgi pracowni diagnostycznej;

WYM.EDM.060 3) dokumentację indywidualną zewnętrzną w formie karty informacyjnej z leczenia szpitalnego, skierowania lub zlecenia na świadczenia zdrowotne realizowane poza jednostkami Zamawiającego oraz z dokumentacji dla celów określonych w odrębnych przepisach;

WYM.EDM.061 4) dokumentację zbiorczą zewnętrzną składającą się z dokumentacji prowadzonej dla celów określonych w odrębnych przepisach

WYM.EDM.062 System rejestr danych Historii choroby zakłada niezwłocznie po przyjęciu pacjenta do szpitala

WYM.EDM.063 System wyświetla całą dokumentację medyczną pacjenta w sposób ustrukturyzowany, a prezentacja struktury odpowiada obowiązującym przepisom

WYM.EDM.064 System umożliwia przeglądanie zawartości dokumentacji medycznej przez uprawnionych użytkowników

WYM.EDM.065 Dostęp do dokumentów bezpośrednio ze skojarzonych z elektroniczną dokumentacją ekranów systemu medycznego mających taką możliwość

WYM.EDM.066 System przechowuje informacje w sposób dający możliwość udostępnienia, w tym przez eksport w postaci elektronicznej dokumentacji albo części dokumentacji będącej formą dokumentacji określonej w rozporządzeniu MINISTRA ZDROWIA z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania, w formacie XML i PDF

WYM.EDM.067 W przypadku, gdy do dokumentacji prowadzonej w postaci elektronicznej ma być dołączona dokumentacja utworzona w innej postaci, w tym zdjęcia radiologiczne lub dokumentacja utworzona w postaci papierowej, system daje możliwość korzystania z funkcji zintegrowanego modułu archiwum cyfrowej dokumentacji oraz zintegrowanego modułu archiwum PACS i przechowywania w systemie informatycznym wszystkich dokumentów w sposób zapewniający czytelność, dostęp i spójność dokumentacji medycznej

WYM.EDM.068 System umożliwia w przypadku wykonania odwzorowania cyfrowego dokumentacji wydawanie na życzenie pacjenta albo zniszczenie w sposób uniemożliwiający identyfikację pacjenta, a w przypadku oświadczeń pacjentów odnotowanie zarchiwizowania dokumentu w archiwum medycznym po wykonaniu cyfrowego odwzorowania i załączeniu go do archiwum elektronicznej dokumentacji medycznej

WYM.EDM.069 W przypadku, gdy istnieje potrzeba udostępniania w postaci papierowych wydruków dokumentacji prowadzonej w postaci elektronicznej, osoba upoważniona przez Zamawiającego ma możliwość potwierdzenia ich zgodności z dokumentacją w postaci elektronicznej i opatrzenia swoim oznaczeniem

WYM.EDM.070 Dokumentacja wydrukowana z systemu umożliwia identyfikację osoby udzielającej świadczeń zdrowotnych

WYM.EDM.071 W przypadku przeniesienia dokumentacji z innego systemu teleinformatycznego, do przeniesionej dokumentacji system przyporządkowuje datę przeniesienia oraz informację, z jakiego systemu została przeniesiona

WYM.EDM.072 System uprawnień pozwalający na precyzyjne definiowanie obszarów dostępnych dla danego użytkownika pełniącego określoną rolę.

64


WYM.EDM.073 Możliwość zarządzania uprawnieniami dostępu do określonych operacji w repozytorium. Przykłady uprawnień systemowych: uruchomienie systemu, zarządzanie uprawnieniami użytkowników, zarządzanie parametrami konfiguracyjnymi, zarządzanie typami dokumentów.

WYM.EDM.074 Możliwość zarządzania uprawnieniami do wykonywania operacji na poszczególnych typach dokumentów w ramach całej placówki lub poszczególnych jednostek organizacyjnych. Przykłady uprawnień do dokumentów: dodawanie dokumentów do repozytorium, odczyt dokumentu, podpisywanie dokumentu, znakowanie czasem dokumentu, import i eksport dokumentu, anulowanie dokumentu, wydruk dokumentu itd.

WYM.EDM.075 Możliwość definiowania nowych typów dokumentów obsługiwanych przez repozytorium dokumentów elektronicznych.

WYM.EDM.076 Zakłada się także możliwość indeksowania dokumentów, których elektroniczna postać nie jest przechowywana w Oprogramowaniu - np. indeksowanie dokumentów papierowych, obrazów radiologicznych przechowywanych w PACS.

WYM.EDM.077 PRZEGLĄDANIE ORAZ DOSTĘP DO DOKUMENTACJI MEDYCZNEJ

WYM.EDM.078 Dostęp do wybranych dokumentów bezpośrednio ze skojarzonych z dokumentami ekranów systemu medycznego

WYM.EDM.079 Przeglądanie zawartości dokumentów możliwych do wydrukowania wyłącznie w postaci plików PDF niedających możliwości nanoszenia przez użytkownika zmian bez wprowadzenia ich w systemie

WYM.EDM.080 Możliwość przeglądania zawartości archiwum dla uprawnionych użytkowników

WYM.EDM.081 Możliwość przeszukiwania zawartości archiwum według zdefiniowanych kryteriów

WYM.EDM.082 Dostęp do archiwum z poziomu systemu medycznego (minimum Oddział, Izba przyjęć, Poradnia, Gabinet) bez konieczności zmiany modułu i ponownego logowania się do systemu

WYM.EDM.083 Dostęp do zawartości archiwum z poziomu danych pobytu pacjenta

WYM.EDM.084 Możliwość wyszukiwania dokumentów za pomocą zaawansowanych kryteriów oraz meta danych.

WYM.EDM.085 System musi umożliwić udostępnianie dokumentacji:

WYM.EDM.086 - w celu realizacji procesów diagnostyczno-terapeutycznych w Zamawiającego

WYM.EDM.087 - pacjentom i ich opiekunom

WYM.EDM.088 - podmiotom upoważnionym (np. Prokurator)

Moduł integracji z P1

W ramach zamówienia Wykonawca dostarczy moduł odpowiedzialny za generowanie elektronicznej dokumentacji medycznej zgodnie z ustawą z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia. Moduł powinien umożliwiać generowanie oraz wymianę z P1 wszystkich dokumentów wyspecyfikowanych przez Centrum Systemów Informacyjnych Ochrony Zdrowia jako dokumenty zgodne z PIK HL7 CDA. Zgodnie z informacjami umieszczonymi na stronie CSIOZ dotyczy to w szczególności następujących dokumentów. Grupa pierwsza - Dokumenty przetwarzane na platformie P1

e-ReceptaSzablon CDA dokumentu receptySzablon CDA dokumentu recepty wystawionej przez farmaceutę w apteceSzablon CDA dokumentu recepty na import docelowySzablon CDA dokumentu recepty spełniającej wymagania związane z refundacjąe-SkierowanieSzablon CDA dokumentu skierowaniaSzablon CDA dokumentu skierowania do szpitala psychiatrycznego

65


Szablon CDA dokumentu skierowania do uzdrowiskaSzablon CDA dokumentu skierowania do zakładu opiekuńczegoSzablon CDA dokumentu skierowania na pielęgniarską opiekę długoterminowąSzablon CDA dokumentu skierowania na badania w związku z podejrzeniem choroby zawodowejInformacje o zdarzeniu medycznym

Grupa druga – dokumenty indeksowane na platformie P1, wytwarzane na podstawie jednostkowych danych medycznych przetwarzanych w systemach informatycznych Podmiotów Wykonujących Działalność Leczniczą

1. Karta informacyjna leczenia szpitalnego,2. Karta odmowy przyjęcia do szpitala, 3. Konsultację lekarską,4. Karta indywidualnej opieki pielęgniarskiej - zawiera szablony dokumentów:

o Kartę oceny stanu pacjenta,o Kartę wywiadu pielęgniarskiego,o Raport pielęgniarski, o Zalecenia pielęgniarskie przy wypisie ze szpitala,

5. Opis badania diagnostycznego, 6. Sprawozdanie z badania laboratoryjnego,7. Protokół operacyjny,8. Wpis do karty uodpornienia,

Moduł powinien spełniać następujące wymagania


WYM.EDM .089 Moduł tworzy dokumentację elektroniczną w oparciu o elektroniczny rekord pacjenta prowadzony w systemie HIS oraz archiwum badań obrazowych PACS

WYM.EDM.090 Interfejs użytkownika systemu jest zrealizowany jako aplikacja WWW

WYM.EDM .090 Wytworzona dokumentacja elektroniczna w każdym momencie jest zgodna z obowiązującym stanem prawnym; w szczególności na dzień prowadzenia postępowania przetargowego spełnia wszystkie wymagania Rozdziału 8 Rozporządzenia Ministra Zdrowia z dn. 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania

WYM.EDM.091 Wykonawca przygotuje dla Zamawiającego plany, o których mowa w §86 pkt. 2 ust. 5 Rozporządzenia Ministra Zdrowia z dn. 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania

WYM.EDM .091 Moduł pozwala na wygenerowanie dokumentów zgodny z PIK HL7 CDA

WYM.EDM.092 Moduł pozwala na przekazanie dokumentów do systemu P1 zgodnie ze specyfikacjami określonymi przez CSIOZ

WYM.EDM .092 Moduł pozwala na zindeksowanie dokumentu w Rjestrze IHE oraz zapis w repozytorium

WYM.EDM.093 Moduł pozwala na podpisanie wygenerowanych dokumentów podpisem elektronicznym

Archiwum (repozytorium) Elektronicznej Dokumentacji Medycznej

Podstawowym celem dostarczanego systemu jest możliwość gromadzenia i wymiany elektronicznej dokumentacji medycznej w standardach zgodnych z Ustawą o systemie informacji w ochronie zdrowia oraz aktami wykonawczymi do tej ustawy. Architektura systemu będzie zgodna ze standardem IHE-XDS.b. Repozytorium będzie przyjmować dokumenty zgodne ze standardem HL7 CDA v3 oraz DICOM, które to standardy zostały wskazane jako obowiązujące na stronach internetowych Centrum Systemów Informacyjnych Ochrony Zdrowia zgodnie Rozporządzeniem Ministra Zdrowia dnia 28 marca 2013 r. sprawie wymagań dla

66


Systemu Informacji Medycznej (Dz.U.13.463). Repozytorium musi pozwalać na gromadzenie również innych typów dokumentów, które zostały opatrzone zestawem metadanych zgodnych z IHE a które dopuszczone są Rozporządzeniem Ministra Zdrowia z dnia 9 listopada 2015 r. w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U. 2015 poz. 2069) wytwarzane przez Zamawiającego. Architekturę logiczną systemu przedstawia poniższy rysunek:

Rysunek Model logiczny repozytorium EDM

Docelowy proces generowania dokumentacji medycznej w formie elektronicznej zakłada generowania dokumentów wymaganych przez SIOZ w formacie HL7 CDA, podpisywanie ich za pomocą certyfikatów wygenerowanych w centrum certyfikacji lub innych udostępnianych dla lekarzy np. przez system KSI ZUS i przechowywanie w takiej formie. Podpis elektroniczny zapewni, że forma dokumentowa przechowywania EDM zapewni jej: Integralność – dane nie zostały zmienione w sposób nieautoryzowany, zostanie zapewnione poprzez podpis elektroniczny i cyfry kontrolne w nim zastosowane. Jakakolwiek modyfikacja danych po podpisie będzie wykryta. Dostępność – dokumentacja elektroniczna jest osiągalna i możliwa do wykorzystania na żądanie, w założonym czasie, przez autoryzowany podmiot. Cecha ta zostanie zapewniona poprzez zastosowanie rozwiązań technicznych polegających na redundancji zasobów i replikacji danych pomiędzy macierzami, które gwarantują i podnoszą bezpieczeństwo w zakresie ciągłości działania systemu repozytorium EDM. Dzięki zastosowaniu formy dokumentu tekstowego dokumentacja stanie się niezależna technologicznie to jest do jej odczytu nie będzie wymagana aplikacja w określonej wersji czy też silnik bazy danych co przyczyni się do możliwości prowadzenia i wymiany dokumentacji w długim okresie czasu.Rozliczalność – działania podmiotu mogą być przypisane w sposób jednoznaczny tylko temu podmiotowi. Cecha ta zostanie uzyskana poprzez zastosowanie systemów logów w zakresie działalności repozytoriów. Logi będą jednoznacznie wskazywać, komu została udostępniona dokumentacja medyczna, jak również kto kiedy przekazał dane do repozytorium. Dodatkowo na rozliczalność wpłynie zastosowania rozwiązań w zakresie synchronizacji czasu pomiędzy systemami tak by każdy wpis w repozytorium był również jednoznacznie identyfikowany pod kątem momentu jego wykonania. Autentyczność i niezaprzeczalność – tożsamość podmiotu lub zasobu jest taka, jak deklarowana (autentyczność dotyczy użytkowników, procesów, systemów i informacji) i istnieje brak możliwości wyparcia się swego uczestnictwa w całości lub w części wymiany danych przez jeden z podmiotów uczestniczących w tej wymianie. Cecha ta zostanie uzyskana poprzez odpowiednie procedury w zakresie przyznawania certyfikatów zarówno osobom uczestniczącym w procesie tworzenia dokumentacji medycznej w formie elektronicznej jak i systemom, które uczestniczą w jej wymianie.

Po przeprowadzaniu wdrożenia system EDM proces gromadzenia danych medycznych i tworzenia EDM będzie przebiegał w następujący sposób:

67


Opis procesu po wdrożeniu systemu w zakresie Repozytorium EDM. 1. Pacjent przychodzi do Szpitala celem leczenia 2. Personel medyczny na bieżąco dokumentuje przebieg procesu diagnostyczno-terapeutycznego w

systemach HIS i RIS. 3. PO zakończeniu procesu leczenia lekarz prowadzący generuje wymagany dokument medycznych np.

kartę informacyjną leczenia szpitalnego. 4. Podpisuje go za pomocą podpisu elektronicznego 5. Dokument wraz z zestawem metadanych zgodnym z IHE.XDS zostaje przekazany do repozytorium

E-usługi w standardzie SOA Service Oriented Architecture

System Archiwum Elektronicznej Dokumentacji Medycznej jest maksymalny stopień integracji z systemami dziedzinowymi w zakresie wymiany dokumentów medycznych. Taka integracja jest niezbędna dla zapewnienie maksymalnej użyteczności systemu repozytorium dla personelu medycznego gdyż pozwala na udostępnianie dokumentów medycznych bezpośrednio w środowisku pracy lekarza czyli w systemie HIS. Dlatego repozytorium będzie udostępniało usługi SOA zgodne ze standardem IHE-XDS czyli będzie udostępniało API zarówno dla systemów dziedzinowych w zakresie zapisu i odczytania dokumentów medycznych oraz API do wymiany danych z systemami centralnymi takimi jak P1. W ramach Zamówienia Wykonawca dostarczy API do wymiany dokumentów z dostarczanym systemem Archiwum Dokumentacji Medycznej wraz z opisem usług sieciowych (WSDL) schematami usług w standardzie XSD oraz przykładowymi wywołaniami usług. API musi obejmować operację zapisu, odczytu oraz wyszukiwania dokumentów w repozytorium. Dostarczana licencja na Archiwum Dokumentacji Medycznej nie może ograniczać liczby systemów do niego podłączonych. Wymiana zarówno wewnątrz podmiotu jak i na zewnątrz np. w ramach systemów regionalnych lub systemu P1 będzie odbywała się zgodnie ze standardem IHE XDS.

68


Podejście do budowy repozytorium EDM w oparciu o międzynarodowe standardy gromadzenia, przechowywania i wymiany dokumentacji medycznej (HL7 CDA i IHE XDS) gwarantuje możliwość długoterminowego przechowywania EDM oraz jej wymiany w ramach projektów regionalnych i krajowych takich jak system P1.

W ramach wdrożenie Wykonawca zobowiązany będzie dokonać integracji systemu Archiwum EDM z Systemem P1 w zakresie wymiany elektronicznej dokumentacji medycznej w ramach Systemu Informacji Medycznej. Jeżeli w momencie odbioru systemu funkcjonalność nie będzie udostępniana przez System P1 Wykonawca dokona tej integracji w okresie nadzoru gwarancyjnego niezwłocznie po jej udostępnieniu przez CSIOZ w terminach uzgodnionych z Zamawiającym.

Uwierzytelnienie użytkowników aplikacji webowych W ramach systemu zakładane jest wykorzystanie wspólnej bazy użytkowników z system dziedzinowych

HIS. Pozwoli to na zarządzanie uprawnieniami użytkowników z jednego miejsca a tym samym na zachowanie spójności w zakresie zarządzania tożsamością i rolami użytkowników. W procesie logowanie będą wykorzystywane certyfikaty wydane przez Szpital z centrum certyfikacji dostarczanego w ramach projektu.

Uwierzytelnienie systemów zewnętrznych usługodawców Systemy podmiotów leczniczych, które są zewnętrzne w stosunku do Systemu Archiwum EDM

korzystające z udostępnionych usług WS uwierzytelniane są na podstawie certyfikatów wydanych przez Szpital lub w zakresie systemu P1 za pomocą certyfikatów wydawanych przez CSIOZ.

System Archiwum EDM musi spełniać następujące wymagania:


WYM.ARC.001 System umożliwia składowanie dokumentów medycznych zgodnie ze standardem IHE-XDS.b

WYM.ARC.002 System umożliwia udostępnianie i wyszukiwanie dokumentów medycznych zgodnie ze standradem IHE-XDS.b

WYM.ARC.003 System umożliwia wymianę dokumentacji medycznej między jednostkami ochrony zdrowia zgodnie z wymogami określonymi dla Systemu Informacji Medycznej zgodnie z ustawą o SIOZ

WYM.ARC.004 Wymiana dokumentacji realizowana jest w poprzez elektroniczną wymianę komunikatów między systemami informatycznymi.

WYM.ARC.005 System umożliwia integrację między systemami medycznymi klasy HIS, AIS, LAB, RIS dowolnych producentów za pomocą API udostępnianych przez system

WYM.ARC.006 System umożliwia wymianę dokumentów medycznych w dowolnym formacie, w szczególności PDF, DOC, RTF, HL7 CDA

WYM.ARC.007 System umożliwia przekazywanie wyników badań obrazowych w formacie DICOM.

WYM.ARC.008 System umożliwia obsługę dokumentów medycznych zgodnych ze standardem HL7 CDA opisanym przez CSIOZ na stronie Polska Implementacja HL7 CDA (https://www.csioz.gov.pl/HL7POL/pl-cda-html-pl-PL/)

WYM.ARC.009 Wymiana dokumentacji realizowana jest w oparciu o otwarte, międzynarodowe standardy IHE XDS.

WYM.ARC.010 Komunikacja między placówkami może odbywać się za pomocą sieci Internet.

WYM.ARC.011 Przesyłane dane są szyfrowane i podpisywane podpisem elektronicznym co uniemożliwia odczytanie lub sfałszowanie komunikatu przez osoby nieuprawnione.

WYM.ARC.012 Podłączenie systemu zewnętrznego realizowane jest za pomocą protokołu IHE XDS

69


WYM.ARC.013 Wsparcie dla protokołu HL7 v3 w zakresie: - parsowanie i generowanie komunikatów - walidacja komunikatów - rejestr OID - generowanie wrapperów HL7 (ControlActWrapper i TransmisionWrapper) - generowanie potwierdzeń Ack

WYM.ARC.014 - parsowanie i generowanie komunikatów

WYM.ARC.015 Wsparcie dla protokołu DICOM

WYM.ARC.016 Dostęp do aplikacji zabezpieczony jest loginem i hasłem

WYM.ARC.017 Użytkownicy mogą być uwierzytelniani za pomocą:- lokalnej bazy danych użytkowników - baz danych użytkowników podłączonych systemów - lokalnego repozytorium LDAP - zdalnych repozytoriów LDAP

WYM.ARC.018 System umożliwia pobranie dokumentacji medycznej wybranego pacjenta

WYM.ARC.019 Repozytorium obsługuje profil integracyjny IHE XDS.b.

WYM.ARC.020 Dokumenty umieszczone Repozytorium EDM nie mogą być zmieniane ani usuwane przed upływem okresu retencji. Repozytorium umożliwia wykonywanie adnotacji do dokumentów oraz dodawanie kolejnych wersji dokumentu. Repozytorium przechowuje zarówno dokument oryginalny oraz wszystkie ewentualne wersje dokumentu. Repozytorium przechowuje relacje pomiędzy dokumentem oryginalnymi jego kolejnymi wersjami.

WYM.ARC.021 Repozytorium przechowuje informacje o zgodach na udostępnienie dokumentacji medycznej

WYM.ARC.022 Repozytorium ma możliwość przechowywania informacji o miejscu składowania dokumentu fizycznego.

WYM.ARC.023 Dokumenty przechowywane w Repozytorium mogą być podzielone na typy. Typ dokumentu jest opisywany za pomocą zestawu metadanych. Metadane dla każdego z typów mogą być wymagane lub opcjonalne.

WYM.ARC.024 Każdy dokument przechowywany w repozytorium musi być opatrzony co najmniej następującymi metadanymi:- unikalny identyfikator dokumentu- identyfikator pacjenta (dla dokumentacji indywidualnej)- identyfikator jednostki (dla dokumentacji zbiorczej)- data utworzenia dokumentu- data wprowadzenia dokumentu do repozytorium- nazwa i typ dokumentu- rodzaj i nazwa jednostki medycznej w której dokument został wytworzony- status dokumentu (aktualny, nie aktualny)- kategoria archiwalna/okres retencji dokumentu

WYM.ARC.025 Repozytorium umożliwia brakowanie dokumentów po upływie okresu retencji

WYM.ARC.026 Repozytorium przechowuje informacje o udostępnieniu dokumentu co najmniej przez okres retencji dokumentu.

WYM.ARC.027 Repozytorium przechowuje wszystkie dane związane z żądaniem udostępnienia dokument, bez względu na rezultat żądania (udostępnienie/odmowa dostępu).

WYM.ARC.028 Repozytorium weryfikuje metadane rejestrowanego dokumentu.

WYM.ARC.029 Wpisy w danych dokumentacji medycznej oznaczone są czasem wprowadzenia oraz opatrzone oznaczeniem osoby dokonującej wpisu lub zmian

WYM.ARC.030 System otwarty jest na możliwość opatrywania dokumentów podpisem elektronicznym oraz oznaczania czasem

70


WYM.ARC.031 System zapewnia automatyczne kopie bezpieczeństwa zawartości archiwum elektronicznego dokumentacji medycznej

WYM.ARC.032 Możliwość automatycznego zarchiwizowania dokumentacji medycznej na daną chwilę (w tym opcja automatycznego archiwizowania po elektronicznym podpisaniu) i przechowanie go w formacie PDF

WYM.ARC.033 Istnieje możliwość przygotowania eksportu całości danych dokumentacji medycznej w formacie XML, w sposób zapewniający możliwość odtworzenia tej dokumentacji w innym systemie teleinformatycznym

WYM.ARC.034 Możliwość archiwizacji dokumentacji medycznej w postaci elektronicznej.

WYM.ARC.035 Generowanie wydruków zgodnych z obowiązującymi przepisami prawa

WYM.ARC.036 Możliwość archiwizacji dokumentów złożonych, wieloczęściowych i przyrostowych tj. księgi

WYM.ARC.037 Możliwość rejestracji dokumentów elektronicznych utworzonych poza Oprogramowaniem Zamawiającego, manualna rejestracja dokumentów zewnętrznych

WYM.ARC.038 Cyfryzacja dokumentu papierowego i dołączanie go do dokumentacji elektronicznej

WYM.ARC.039 Możliwość weryfikacji podpisu

WYM.ARC.040 Możliwość weryfikacji integralności dokumentu

WYM.ARC.041 Możliwość wydruku dokumentu

WYM.ARC.042 Możliwość wersjonowania przechowywanych dokumentów z dostępem do pełnej historii poprzednich wersji.

WYM.ARC.043 Repozytorium EDM musi umożliwiać:- rejestrację dokumentu- pobieranie dokumentów w formacie XML- pobieranie dokumentów w formacie PDF- wyszukiwanie materializacji dokumentów

WYM.ARC.044 Repozytorium EDM musi współdzielić z Oprogramowaniem Zamawiającego:- słownik jednostek organizacyjnych,- rejestr użytkowników,- rejestr pacjentów,

WYM.ARC.045 Indeksowane powinny być wszystkie wersje dokumentu

WYM.ARC.046 Możliwość indeksowania dokumentów w celu łatwego jej wyszukiwania wg zadanych kryteriów

WYM.ARC.047 Indeks dokumentacji powinien być zorientowany na informacje o dokumencie: autor, data powstania, rozmiar, typ, data powstania.

WYM.ARC.048 Cyfrowe archiwum medycznej jest modułem zintegrowanym z modułem elektronicznej dokumentacji medycznej

WYM.ARC.049 Możliwość przechowywania dokumentów elektronicznych w dowolnym formacie, w tym PDF

WYM.ARC.050 Możliwość przechowywania dokumentów podpisanych lub niepodpisanych podpisem elektronicznym

WYM.ARC.051 Możliwość porządkowania dokumentacji w folderach w kontekście rekordu medycznego pacjenta

WYM.ARC.052 System zapewnia automatyczne kopie bezpieczeństwa zawartości archiwum dokumentów

WYM.ARC.053 System zapewnia oznaczenie czasu i jednoznaczne przypisanie osoby dodającej dokument cyfrowy

WYM.ARC.054 System zapewnia automatyczne kopie bezpieczeństwa zawartości archiwum dokumentów

WYM.ARC.055 Przechowywanie w systemie informatycznym wszystkich dokumentów w sposób zapewniający czytelność, dostęp i spójność z dokumentacją prowadzaną w module elektronicznej dokumentacji medycznej

WYM.ARC.056 Możliwość złożenia podpisu elektronicznego na dokumencie

WYM.ARC.057 Możliwość złożenia podpisu elektronicznego na zbiorze dokumentów

71


Centrum Certyfikacji – Wykonawca dostarczy, zainstaluje ,uruchomi i wdroży w ramach Archiwum EDM w centrum certyfikacji, które pozwoli wygenerowanie certyfikatów elektronicznych dla lekarzy i innego personelu medycznego, służących do podpisywania dokumentacji w wersji elektronicznej. Moduł będzie pozwalał również na uwierzytelnianie użytkowników za pomocą dostarczonych certyfikatów.

E-usługi W celu realizacji e-usług przewidzianych w projekcie Wykonawca dostarczy aplikację portalową, która umożliwi dostęp do oferowanych e –usług użytkownikom końcowym. Aplikacja będzie spełniała następujące założenia:

Założenia ogólne Portal pacjenta czyli moduł przez, który udostępniane będą nowoczesne e-usługi on-line dla pacjentów. Dostarczany Portal Pacjenta będzie niezależny technologicznie to znaczy będzie dostępny poprzez strony Internetowe WWW minimum na następujące przeglądarki(Internet Explorer, FireFox, Chrome, Safari). Będzie istniała możliwość korzystania z portalu poprzez urządzenia z systemem Android i iOS. Takie rozwiązanie pozwoli na korzystanie z usług publicznych będzie możliwe różnymi kanałami dostępu, niezależnie od miejsca przebywania i wykorzystywanej technologii. Dostarczone rozwiązanie zgodnie z wymaganiami rozporządzenia w sprawie krajowych ram interoperacyjności będzie zgodne z wymaganiami WCAG 2.0 (Web Content Accessibility Guidelines) na poziomie AA. Pozwoli to na pełniejsze wykorzystanie e-usług i sprawi że system nie będzie stwarzał barier w zakresie dostępności dla osób z niepełnosprawnościami. Najpóźniej w momencie odbioru systemu dostawca musi dysponować zaświadczeniem przyznawanym w wyniku badań opartych na dokumencie WCAG 2.0 w ramach WAI konsorcjum W3C wystawionym przez niezależnego audytora i potwierdzającym zgodność portalu oferującego wyżej wymienione e-usługi ze standardem WCAG 2.0 na odpowiednim poziomie. Dostarczone w ramach portalu informacje powinny być tworzone z użyciem języka łatwego do czytania i zrozumienia. W celu jak najszerszej dostępności dostarczanych rozwiązań, Portal pacjenta musi spełniać wymagania wykraczające poza zakres wytycznych WACG 2.0 w następujących elementach:

możliwość ustawienia wielkości głównego tekstu możliwość wykorzystania przez użytkownika specjalistycznego oprogramowanie do transkrypcji mowy

i odczytu ekranu dla osób z niepełnosprawnością . Oprogramowanie może być instalowane samodzielnie na komputerach osoby z niepełnosprawnością lub jako ogólnodostępne rozszerzenie przeglądarki internetowej

Dodatkowo w zakresie bezpieczeństwa oraz interoperacyjności rozwiązań dostarczany System powinien spełniać następujące wymagania:

Dostęp do e-usług musi być realizowany kanałami szyfrowanej komunikacji jak VPN i/lub HTTPS. E-usługi muszą być ściśle zintegrowane z częścią białą systemu, tj. HIS/RIS/PACS/WEB. E-usługi muszą korzystać z tego samego zbioru danych co część biała tj. HIS/RIS/PACS/WEB. Moduły e-usług dla pacjentów opublikowane w Internecie muszą korzystać z tej samej bazy danych (w

rozumieniu zbioru danych i modelu danych), co moduły systemu medycznego HIS i RIS, ale nie mogą łączyć się bezpośrednio do tej bazy, a jedynie poprzez dodatkowy zabezpieczony interfejs komunikacji (np. WebServices) w celu podniesienia bezpieczeństwa bazy danych osobowych i wrażliwych danych medycznych przetwarzanych w systemie HIS/RIS/PACS.

E-usługi nie mogą korzystać z dodatkowej bazy danych bezpośrednio dostępnej z poziomu aplikacji publikowanych w Internecie w celu udostępnienia pacjentom danych medycznych.

E-usługi dostępne w Internecie dla pacjentów do komunikacji z częścią systemu w intranecie placówki (system HIS/RIS/PACS) muszą wykorzystywać zabezpieczony kanał komunikacji dla podniesienia poziomu bezpieczeństwa Systemu.

Serwer WWW musi być udostępniony (chroniony) za dodatkowym serwerem proxy.

72


E-Portal Pacjenta umożliwiający dostęp do e-usług będzie wyposażony w certyfikat SSL. Będzie posiadał odpowiednią nazwę domenową

System musi automatycznie wylogować użytkownika po zdefiniowanym czasie barku aktywności dla sesji.

73


Dostarczane e-usługi

e-Rejestracja Szpital obecnie posiada udostępnioną usługę e-rejestracji w ramach tego projektu przewidziane jest dostosowanie tej usługi do wymogów WCAG 2.0 oraz integrację z dostarczanymi w ramach projektu e-usługami tak by stanowiły jedną spójną całość. Usługa ta zapewnia pacjentowi możliwość zarezerwowania terminów na usługi w poradniach oraz dostęp do wszystkich udostępnionych grafików Szpitala.Usługa zapewni automatyczne raportowanie o stanie kolejek oczekujących do Narodowego Funduszu Zdrowia za pomocą aplikacji AP-KOLCE.

e-Wyniki usługa umożliwiająca pacjentowi na elektroniczny odbiór wyników badań on-line. W ramach projektu planowane jest dostosowanie tej usługi do wymogów WCAG 2.0 oraz integrację z dostarczanymi w ramach projektu e-usługami tak by stanowiły jedną spójną całość. W szczególności w zakresie tej usługi planowana jest integracja z dostarczanym Repozytorium elektronicznej dokumentacji medycznej tak by możliwe było udostępnienie wyników w nim zgromadzonych. Po rozbudowie i połączeniu z e-rejestracją stanowią usługę na poziomie dojrzałości 4 – transakcja gdzie pacjent może zrealizować pełny obieg dokumentów za pomocą portalu pacjenta.Słowny opis procesu z wykorzystaniem e-usług. 1. Pacjent rejestruje się na wykonania określonego badania diagnostycznego 2. Badanie jest realizowane podczas umówionej wizyty 3. Personel medyczny szpitala wprowadza wynik badania w systemie HIS 4. Personel medyczny udostępnia wynik badania pacjentowi na portalu pacjenta 5. Pacjent odbiera wynik badania on-line

Dostarczane oprogramowanie powinno spełniać następujące wymagania:

Kod wymagania

Opis wymagania

WYM.EWY.001 Aplikacja umożliwia przeglądanie wyników badań i obrazów diagnostycznych w formacie DICOM/JPG przez pacjenta metodą zdalną za pośrednictwem Internetu.

WYM.EWY.002 Pacjent korzystając z przygotowanej witryny internetowej może się zalogować, wybrać na podstawie różnych kryteriów ( jednostka wykonująca, nazwa badania, status) interesujące go wyniki odczytać, pobrać lub wydrukować.

WYM.EWY.003 Wyniki mogą być prezentowane jako lista lub hierarchicznie z podziałem na jednostki zlecające.

74


WYM.EWY.004 Możliwość prezentowania wyników badań tylko i wyłącznie skonsultowanych podczas porady pacjenta.

WYM.EWY.005 Możliwość konfiguracji okresu widoczności danego wyniku na liście wyników pacjenta.

WYM.EWY.006 Pełna integracja z Elektronicznym Rekordem Medycznym Pacjenta systemu szpitalnego, korzystanie z tego samego źródła danych, wspólnego modułu administracyjnego oraz słowników.

Usługa e-wyników będzie umożliwiać pacjentowi również udostępniania dokumentacji medycznej, zarówno w postaci dokumentów np. karty informacyjnej leczenia szpitalnego jak i wyników badań obrazowych z możliwością ich przeglądania. Słowny opis procesu:

1. W pracowni szpitala zostaje wykonane usługa. System HIS generuje informację dla ePortalu o dostępnym dokumencie medycznym .

2. ePortal wysyła dostępnymi kanałami powiadomienie dla pacjenta o możliwości pobrania dokumentu; informacja może być przekazana bezpośrednio w ePortalu, za pośrednictwem maila lub smsa.

3. Pacjent loguje się do portalu.4. Pacjent wyszukuje dokument medyczny który został udostępniony.5. Pacjent uruchamia drukowanie dokumentu lub pobranie go w postaci pliku.6. ePortal pobiera dane dokument z repozytorium i zależnie od wyboru użytkownika: generuje wydruk

lub startuje pobieranie pliku z wynikiem.7. Pacjent kończy pracę z systemem.

Rysunek Diagram procesu biznesowego udostępniania dokumentacji

Kod wymagania Opis wymagania WYM.EWY.007 Aplikacja musi umożliwiać przeglądanie dokumentacji w tym wyników badań obrazowych w

formacie DICOM skonwertowanym do JPG przez pacjenta metodą zdalną za pośrednictwem Internetu.

WYM.EWY.008 Aplikacja musi umożliwiać pacjentowi wybranie na podstawie kryteriów ( jednostka wykonująca, typ dokumentu, status) interesujących go dokumentów.

WYM.EWY.009 Aplikacja musi umożliwiać pacjentowi odczytanie, pobranie lub wydruk wybranych dokumentów. WYM.EWY.010 Aplikacja musi umożliwiać prezentację wyników w postaci listy.

75


WYM.EWY.011 Aplikacja musi umożliwiać prezentację wyników pogrupowanych ze względu na jednostki wykonujące.

WYM.EWY.012 Aplikacja musi zapewniać pełną integrację z Elektronicznym Rekordem Medycznym Pacjenta, korzystać z tego samego źródła danych oraz słowników.

WYM.EWY.013 możliwość prezentowania wyników badań tylko i wyłącznie skonsultowanych podczas porady pacjenta (o odpowiednim statusie nadanym przez personel w systemie HIS/AIS),

WYM.EWY.014 możliwość konfiguracji okresu widoczności danego dokumentu na liście pacjenta przez administratora systemu,

WYM.EWY.015 pacjent ma możliwość załączenia dokumentacji medycznej w formie zeskanowanych załączników. Lekarz po stronie systemu medycznego HIS działającego w intranecie może zdecydować, które z załączników dołączyć do dokumentacji medycznej wizyty.

e-Wywiad (poziom 4 transakcja) daje możliwość skrócenia czasu wizyty w Poradni, poprzez pozyskanie od pacjenta w momencie rejestracji wizyty, informacji dotyczących zdrowia jego i rodziny przed wizytą. Dane wprowadzone na formularzach przy rejestracji wizyty, natychmiast są dostępne w systemie medycznym; Personel medyczny ma dostępne informacje o wywiadzie wprowadzone przez pacjenta jeszcze przed rozpoczęciem wizyty. Jeżeli są one nie wystarczające może zadać dodatkowe pytania i uzupełnić informacje. Ta usługa pozwala na poświęcenie większej ilości czasu pacjentowi podczas wizyty. Lekarz nie musi wypełniać wywiadu gdyż dane zostały uzupełnione przed wizytą i w jej trakcie można je tylko potwierdzić lub uzupełnić. Dane wprowadzone przez pacjenta są częścią rekordu medycznego w systemie HIS. Słowny opis procesu:

1. Pacjent loguje się do ePortalu.2. Pacjent wyszukuje i wybiera wizytę, do której uzupełni dane wywiadu lekarskiego.3. Pacjent uruchamia funkcję „Wywiad lekarski” i uzupełnia informacje, o które prosi system;

wprowadzone dane stają się dostępne w systemie HIS.4. Pacjent kończy pracę z systemem.5. Lekarz prowadzący weryfikuje informacje wprowadzone przez pacjenta; jeśli uzna to za stosowne,

zadaje dodatkowe pytania pacjentowi.6. ePortal wysyła do pacjenta powiadomienie o pytaniach zadanych przez lekarza.7. Pacjent ponownie loguje się do ePortalu i uzupełnia informacje w wywiadzie.8. Pacjent kończy pracę z systemem.

76


Usługa e-wywiad powinna spełniać następujące wymagania:

Kod wymagania

Opis wymagania

WYM.EWD.001 Moduł umożliwia przekazanie przez pacjenta istotnych informacji dotyczących stanu zdrowia przed wizytą.

WYM.EWD.002 Moduł umożliwia skorzystanie ze zdefiniowanych formularzy strukturyzowanych stworzonych w module Generator Formularzy.

WYM.EWD.003 Moduł umożliwia stworzenie różnych formularzy e-wywiadu dla poszczególnych jednostek organizacyjnych. Formularze mogą różnić się zawartością poszczególnych pól.

WYM.EWD.004 Wprowadzony przez pacjenta e-wywiad widoczny jest w dokumentacji formularzowej w gabinecie lekarskim.

WYM.EWD.005 Lekarz ma możliwość zapoznania się z e-wywiadem przed wizytą. System umożliwia poinformowanie lekarza o uzupełnieniu przez pacjenta e-wywiadu. Lekarz ma możliwość zadania dodatkowego pytania pacjentowi.

Usługa e-obchód Jest to usługa elektroniczna skierowana do lekarzy której ostatecznym odbiorcą jest pacjent, polegająca na stworzeniu indywidualnej dokumentacji medycznej podczas wizyty lekarskiej bezpośrednio przy łóżku pacjenta. Aplikacja musi być dostosowana do urządzeń mobilnych, tak aby lekarz mógł z niej korzystać bezpośrednio podczas wizyty lekarskiej.

Usługa e-obchód powinna spełniać następujące wymagania Kod wymagania Opis WYM.EOB.001 Aplikacja musi być zrealizowana jako dedykowana do pracy na urządzeniach mobilnych

wyposażonych wyłącznie w ekran dotykowy.

77


WYM.EOB.002 Aplikacja musi być zrealizowana w architekturze trójwarstwowej oraz mieć możliwość pracy z wykorzystaniem przeglądarki internetowej bez konieczności instalacji dodatkowej aplikacji.

WYM.EOB.003 Aplikacja musi być w pełni zint7egrowana z systemem szpitalnym i działać na tym samym motorze bazy danych co system szpitalny. Dane zapisane w Module są dostępne natychmiast także w systemie szpitalnym. Dane zapisane równolegle przez innych użytkowników w systemie szpitalnym są także natychmiast dostępne w Module.

WYM.EOB.004 Aplikacja musi poprawnie działać na urządzeniach typu tablet opartych na systemach operacyjnych Windows, iOS, Android.

WYM.EOB.005 Użyte w interfejsie graficznym aplikacji komponenty wprowadzania danych i nawigacji muszą być dostosowane do pracy z wykorzystaniem ekranu dotykowego (m.in. większe przyciski, pola edycyjne, zakładki, itp.). Wykorzystanie klawiatury ekranowej musi być ograniczone do niezbędnego minimum.

WYM.EOB.006 Aplikacja musi współpracować z Systemem Identyfikacji Pacjenta systemu HIS. W szczególności musi umożliwiać zidentyfikowanie pacjenta z opaski ze znakiem identyfikacyjnym, w którą został zaopatrzony pacjent w szpitalu.

WYM.EOB.007 Aplikacja na urządzeniu klienckim nie może trwale gromadzić przetwarzanych danych osobowych i medycznych. Musi być możliwość poprawnej pracy rozwiązania bez konieczności korzystania z lokalnej bazy danych na urządzeniu.

WYM.EOB.008 Do uruchomienia wystarczająca jest przeglądarka stron WWW (co najmniej Chrome, Safari).WYM.EOB.009 Aplikacja musi mieć możliwość podglądu danych pacjentów znajdujących się w szpitalu, na

poszczególnych oddziałach w zakresie:• data rozpoczęcia pobytu,• historia pobytu,• sala/oddział/izba przyjęć,• diagnoza,• lekarz prowadzący,• status pobytu,• zlecone badania i wyniki,• zlecone leki,• zdjęcia radiologiczne z PACS dla badań wraz z opisami,• opisowe dane dokumentacji medycznej,• podgląd graficzny karty gorączkowej.

WYM.EOB.010 Aplikacja musi mieć możliwość sprawdzenia wyników badań pacjenta w ramach pobytu.WYM.EOB.011 Aplikacja musi mieć możliwość wprowadzania danych:

•składanie zleceń nowych podań leków,•składanie zleceń badań,•składanie zleceń badań z panelów zleceń o wspólnej konfiguracji z modułem oddział,•składanie zleceń badań przez wyszukiwanie badań ze słownika,•odnotowanie podań zleconych leków,•odnotowanie czynności pielęgniarskich,•odnotowywanie parametrów życiowych i karty gorączkowej.

WYM.EOB.012 Aplikacja musi mieć możliwość prezentacji podręcznych informacji lekarskich/wbudowanych zestawień danych, z których można wybrać pacjenta i rozpocząć pracę na wybranym rekordzie z listy (co najmniej):•'moi pacjenci',•'moje dokumenty ',•'moje zadania na dziś'•'wyniki badań pacjentów'

WYM.EOB.013 Aplikacja musi mieć możliwość wyszukiwania pacjentów.WYM.EOB.014 Aplikacja musi mieć możliwość uruchomiania podglądu obrazów diagnostycznych w postaci

referencyjnej.WYM.EOB.015 Jednolity sposób logowania do aplikacji na urządzeniu mobilnym typu tablet oraz systemu

szpitalnego - za pomocą tego samego loginu i hasła.WYM.EOB.016 System szpitalny wraz z aplikacją E-Obchód korzystają ze wspólnej definicji wykorzystywanych w

systemie słowników (badania, użytkownicy, uprawnienia, lekarze zlecający, lekarze opisujący, inne wykorzystywane w systemie HIS oraz niezbędne w dostarczanym rozwiązaniu jak słownik leków, badań). Zmiana w jednym systemie powoduje automatyczną zmianę pozycji słownikowej w drugim systemie.

WYM.EOB.017 System szpitalny i aplikacja E-Obchód są zintegrowane w sposób umożliwiający ograniczenie wielokrotnego wpisywania tych samych danych. Dane wprowadzone w systemie tabletowym są natychmiast widoczne w systemie HIS i odwrotnie.

WYM.EOB.018 Aplikacja E-Obchód oraz system szpitalny korzystają z tego samego rejestru pacjentów.

78


WYM.EOB.019 Aplikacja E-Obchód prezentuje formularze dokumentacji medycznej systemu szpitalnego korzystając z tej samej definicji formularzy co system szpitalny.

e-KontrahentJest system udostępniającym lekarzom z jednostek współpracujących z szpitalem dostęp, za pomocą usług elektronicznych o wysokim stopniu zaawansowania, dokumentację medyczną pacjentów objętych np. opieką POZ i skierowanych na leczenie do Szpitala w Ostródzie. Jest to podstawowe narzędzie umożliwiające współpraca Szpitala z POZ lub AOS zarówno w zakresie wymiany elektronicznej dokumentacji medycznej EDM jak i w zakresie możliwości przeprowadzenia konsultacji pomiędzy POZ a Szpitalem w Ostródzie zarówno w zakresie opieki szpitalnej (SZP) jak ambulatoryjnej (AOS). Aplikacja ta umożliwi pełną obsługę transakcji pomiędzy Szpitalem a współpracującymi jednostkami w zakresie zlecenia badań, zapisania na wizytę, realizacji badania zwrotnego przesłania wyników, rozliczenie umowy (jeżeli występuje). Portal kontrahenta pozwoli również na przesłanie przez lekarza POZ lub AOS elektronicznej dokumentacji medycznej np. wyników badań pacjenta (zarówno obrazowych jak i innych diagnostycznych) do Szpitala w Ostródzie w celu konsultacji . Model procesu biznesowego – stan po realizacji projektu

Przedmiotowa usługa realizowana będzie w oparciu o następujące aktywności: 1. Podczas wizyty pacjenta w placówce współpracującej użytkownik loguje się do aplikacji E- Kontrahent. 2. Następuje wyszukanie kartoteki lub utworzenie kartoteki pacjenta w systemie. 3. Wybór/zaplanowanie usług do wykonania przez Szpital. 4. Oznaczenie, czy badanie/usługa będzie wymagała konsultacji 5. Wysłanie do pacjenta potwierdzenia rezerwacji usług. 6. Pacjent stawia się w placówce Szpitalnej, w wyznaczonym terminie, na wykonanie zaplanowanych usług. 7. Szpital wyszukuje w systemie HIS usługi zaplanowane przez podmiot współpracujący8. Szpital wykonuje zaplanowane usługi. 9. W przypadku konieczności przeprowadzenia konsultacji, do wykonanej usługi personel szpitala oraz personel Partnera realizują wideokonferencję za pomocą narzędzi udostępnianych przez Portal kontrahenta . 10. Pacjent stawia się na wizytę w placówce Partnera. 11. Partner w systemie E-Kontrahent wyświetla wyniki i omawia je z pacjentem. 12. Partner wyświetla raport wykonanych przez Szpital usług, na zlecenie partnera. Zgodnie z wygenerowanym raportem, Szpital rozliczy partnera za wykonane usługi.

Rysunek Diagram procesu E-Kontrahent

Kod wymagania

Opis wymagania

79


WYM.EKO.001 Moduł umożliwia dwustronną wymianę zleceń badań i konsultacji pomiędzy placówką i jej kontrahentami (np. innymi jednostkami medycznymi). Moduł również umożliwia kontrahentom rezerwowanie terminów wizyt dla pacjentów w placówce medycznej. Zlecenia badań i konsultacji oraz rezerwacje terminów wizyt odbywają się za pośrednictwem internetu. Kontrahenci korzystają ze specjalnie przygotowanej witryny internetowej.

WYM.EKO.002 E-Kontrahent posiada wspólny moduł administracyjny z systemem medycznym.

WYM.EKO.003 System prowadzi dziennik logowań do modułu.

WYM.EKO.004 Moduł korzysta z tej samej bazy danych (w rozumieniu zbioru danych i modelu danych) co system medyczny w intranecie, ale nie może łączyć się bezpośrednio do tej bazy (podniesienie bezpieczeństwa systemu).

WYM.EKO.005 Do komunikacji z systemem medycznym w intranecie placówki, moduł wykorzystuje zabezpieczony kanał komunikacji (podniesienie bezpieczeństwa systemu).

WYM.EKO.006 Moduł umożliwia określenie zakresu usług możliwych do rezerwacji i zlecania przez danego kontrahenta.

WYM.EKO.007 Moduł umożliwia kontrahentom rezerwacje wizyty, zlecanie badań i konsultacji zarówno dla pacjentów przypisanych do danego kontrahenta jak również dla innych pacjentów zapisanych w bazie systemu medycznego.

WYM.EKO.008 W przypadku wyszukiwania wśród pacjentów przypisanych do danego kontrahenta, istnieje możliwość wyszukiwania co najmniej według następujących kryteriów: pesel, imię, nazwisko, miasto, ulica, kod pocztowy.

WYM.EKO.009 W przypadku wyszukiwania wśród wszystkich pacjentów zapisanych w systemie medycznym - kontrahent musi wprowadzić poprawne: pesel lub datę urodzenia, imię, nazwisko. Wyszukanie pacjenta możliwe jest dopiero po wprowadzenia poprawnie łączenie trzech danych pacjenta.

WYM.EKO.010 Kontrahent ma możliwość dodania nowego pacjenta do bazy systemu medycznego wprowadzając co najmniej: imię, nazwisko, pesel, płeć, datę urodzenia. Możliwe jest również wprowadzenie: telefonu, adresu e-mail oraz pełnego adresu.

WYM.EKO.011 Moduł umożliwia kontrahentom rezerwacje terminów wizyty dla swoich pacjentów.

WYM.EKO.012 Kontrahent ma możliwość wyszukiwanie wolnych terminów dla wizyt co najmniej według: nazwy usługi, typu wizyty, lekarza, specjalności, jednostki organizacyjnej, daty i godziny.

WYM.EKO.013 Moduł e-Kontrahent korzysta z tej samej definicji grafików przychodni co system medyczny oraz moduł e-Rejestracja, dzięki czemu prezentowane są w nim tylko wolne terminy wizyt.

WYM.EKO.014 Podczas rezerwacji wizyty, kontrahent ma możliwość uzupełnienia danych skierowania co najmniej w zakresie: rodzaju skierowania, daty skierowania, lekarza kierującego, jednostki kierującej, rozpoznania. W celu usprawnienia wprowadzania danych skierowania, moduł powinien automatycznie podpowiadać datę skierowania jako bieżącą, lekarza kierującego jako zalogowanego użytkownika oraz jednostkę kierującą jako jednostkę w której zatrudniony jest zalogowany użytkownik.

WYM.EKO.015 Moduł umożliwia wydruk potwierdzenia rezerwacji wizyty.

WYM.EKO.016 Moduł umożliwia przegląd zaplanowanych wizyt dla wybranych pacjentów kontrahenta wraz z informacją o statusie wizyty.

WYM.EKO.017 Moduł umożliwia kontrahentom zlecenie badań i konsultacji, które zostają przesłane do systemu medycznego.

WYM.EKO.018 Podczas zlecenia badania lub konsultacji, kontrahent ma możliwość wskazania co najmniej: nazwy usługi, priorytetu zlecenia, preferowanej daty wykonania, jednostki wykonującej, lekarza kierującego.

WYM.EKO.019 Moduł umożliwia załączenie do zlecenia, obrazów w formie plików DICOM i przesłanie ich do konsultacji w systemie medycznym.

WYM.EKO.020 Zlecone przez kontrahenta badanie lub konsultacja trafia do systemu medycznego, gdzie może zostać wykonana. Po wykonaniu w systemie medycznym, wynik badania lub konsultacji wraca na listę zleceń wychodzących w module e-Kontrahent, gdzie możliwy jest przegląd wyniku.

80


WYM.EKO.021 Lista zleceń wychodzących w module e-Konrahent prezentuje co najmniej: datę zlecenia, nr zlecenia, nazwę usługi, priorytet, datę wykonania, status, pacjenta, pesel, datę urodzenia.

WYM.EKO.022 Kontrahent ma możliwość wyszukiwania zleceń na liście zleceń wychodzących co najmniej według: daty zlecenia od, daty zlecenia do, pacjenta (nazwisko, imię, pesel), statusu zlecenia, priorytetu, nazwy badania, nr zlecenia.

WYM.EKO.023 Moduł umożliwia kontrahentom przyjmowanie zleceń badań i konsultacji wychodzących z systemu medycznego.

WYM.EKO.024 Użytkownik po stronie systemu medycznego, do zlecania badań lub konsultacji kontrahentom, używa tego samego modułu zleceń, za pomocą którego zlecane są badania wewnątrz placówki.

WYM.EKO.025 Użytkownik zlecający badanie w systemie medycznym ma możliwość zadecydowania czy badanie lub konsultacja powinna być wykonana przez kontrahenta. Użytkownik ma możliwość wyboru konkretnego kontrahenta, do którego zlecenie zostanie przesłane.

WYM.EKO.026 Użytkownik zlecający badanie lub konsultacje w systemie medycznym ma możliwość załączenia poprzednich wyników badań pacjenta do tworzonego zlecenia. Mogą to być również badania posiadające obrazy w formie plików DICOM.

WYM.EKO.027 Użytkownik zlecający badanie lub konsultacje w systemie medycznym ma możliwość zanonimizowania danych pacjenta. W takiej sytuacji w module e-Kontrahent nie będą widoczne: imię, nazwisko i pesel pacjenta.

WYM.EKO.028 Zlecenie badanie lub konsultacji przekazywane jest do moduł e-Kontrahent, gdzie pojawia się na liście zleceń przychodzących.

WYM.EKO.029 Moduł e-Kontrahent weryfikuje uprawnienia użytkownika. Zalogowany użytkownik widzi na liście zleceń przychodzących tylko zlecenia kierowane do kontrahenta, gdzie jest zatrudniony.

WYM.EKO.030 Lista zleceń przychodzących w module e-Konrahent prezentuje co najmniej: datę zlecenia, nr zlecenia, nazwę usługi, priorytet, datę wykonania, status, imię i nazwisko pacjenta, pesel, datę urodzenia.

WYM.EKO.031 Kontrahent ma możliwość wyszukiwania zleceń na liście zleceń przychodzących co najmniej według: daty zlecenia od, daty zlecenia do, statusu zlecenia, priorytetu, nazwy badania, nr zlecenia.

WYM.EKO.032 Kontrahent ma możliwość podejrzenia danych zlecenia - a więc informacji uzupełnionych podczas zlecania badania w systemie medycznym placówki.

WYM.EKO.033 Kontrahent ma możliwość podglądu załączonych do zlecenia plików DICOM, za pomocą przeglądarki diagnostycznej dostępnej z poziomu modułu e-Kontrahent.

WYM.EKO.034 Kontrahent ma możliwość wprowadzenia wyniku badania lub konsultacji, który zostaje przesłany do systemu medycznego. Wynik wprowadzony przez kontrahenta, jest prezentowany w systemie medyczny w taki sam sposób jak wyniki pochodzące z systemów wewnętrznych placówki.

e-Dokumentacjae-Dokumentacja – e-usługa umożliwiająca udostępniania dokumentacji medycznej pacjentowi, zarówno w postaci dokumentów np. karty informacyjnej leczenia szpitalnego jak i wyników badań obrazowych z możliwością ich przeglądania. Słowny opis procesu:

1. W pracowni szpitala zostaje wykonane usługa. System HIS generuje informację dla ePortalu o dostępnym dokumencie medycznym.

2. ePortal wysyła dostępnymi kanałami powiadomienie dla pacjenta o możliwości pobrania dokumentu; informacja może być przekazana bezpośrednio w ePortalu, za pośrednictwem maila lub smsa.

3. Pacjent loguje się do portalu.4. Pacjent wyszukuje dokument medyczny, który został udostępniony.5. Pacjent uruchamia drukowanie dokumentu lub pobranie go w postaci pliku.6. ePortal pobiera dane dokument z repozytorium i zależnie od wyboru użytkownika: generuje wydruk

lub startuje pobieranie pliku z wynikiem.

81


7. Pacjent kończy pracę z systemem.

Rysunek Diagram procesu biznesowego E-Dokumentacja

Moduł powinien spełniać następujące wymagania

Kod wymagania

Opis

WYM.EDO.001 Moduł umożliwia pacjentowi przeglądanie dokumentacji medycznej zapisanej w systemie medycznym.

WYM.EDO.002 Moduł udostępnia dokumentację zapisaną w repozytorium dokumentacji medycznej w systemie medycznym.

WYM.EDO.003 Pacjent ma możliwość przejrzenia lub w razie potrzeby - wydruku dokumentacji medycznej.

WYM.EDO.004 Moduł prezentuje datę utworzenia dokumentacji medycznej.

WYM.EDO.005 Moduł umożliwia filtrowanie dokumentacji medycznej co najmniej według: nazwy dokumentacji, daty utworzenia od, daty utworzenia do.

WYM.EDO.006 Pacjent ma możliwość załączenia zeskanowanych załączników. Lekarz po stronie systemu medycznego może zdecydować, które z załączników dołączyć do dokumentacji medycznej wizyty.

WYM.EDO.007 Moduł umożliwia załączanie przez pacjenta zewnętrznej dokumentacji medycznej.

WYM.EDO.008 Moduł umożliwia załączanie dokumentów .pdf, .jpg, .png, .doc, .docx.

WYM.EDO.009 Podczas załączania dokumentu, pacjent ma możliwość dodania opisu dokumentu.

WYM.EDO.010 Załączone przez pacjenta dokumenty widoczne są w module.

WYM.EDO.011 Załączone przez pacjenta dokumenty widoczne są w systemie medycznym w rekordzie medycznym pacjenta.

WYM.EDO.012 Pacjent ma możliwość usuwania załączonych przez siebie dokumentów.

Wymagania dla oprogramowanie motor bazy danych Dostarczany w ramach zamówienia motor bazy danych powinien spełniać następujące wymagania:

82


Kod wymagania Opis

WYM.BAZ.001 Oferowany motor bazy danych musi być dostępny zarówno na platformy systemów operacyjnych Windows i Linux.

WYM.BAZ.002 Oferowany Motor bazy danych HIS musi mieć możliwość rozbudowy do wersji wspierającej możliwość synchronicznej replikacji danych w dwóch niezależnych centrach danych.

WYM.BAZ.003 Oferowany Motor bazy danych HIS posiada komercyjne wsparcie producenta. Nie dopuszcza się zastosowania RBD typu open-source.

WYM.BAZ.004 Oferowany Motor bazy danych HIS ma możliwość realizacji kopii bezpieczeństwa w trakcie działania (na gorąco).

WYM.BAZ.005 Oferowany Motor bazy danych generuje kopie bezpieczeństwa automatycznie (o określonej porze) i na żądanie operatora oraz umożliwia odtwarzanie bazy danych z kopii archiwalnej, w tym sprzed awarii.

WYM.BAZ.006 Oferowany Motor bazy danych umożliwia eksport i import danych z bazy danych w formacie tekstowym z uwzględnieniem polskiego standardu znaków.

WYM.BAZ.007 Administrator posiada możliwość wyboru danych, które mają być monitorowane w logach systemu z dokładnością do poszczególnych kolumn w tabelach danych, a zarządzanie nimi może odbywać się z poziomu narzędzi do zarządzania bazami danych (dopuszcza się narzędzie na poziomie motoru bazy danych).

WYM.BAZ.008 HIS posiada mechanizmy umożliwiające zapis i przeglądanie danych o logowaniu użytkowników do HIS pozwalające na uzyskanie informacji o czasie i miejscach ich pracy.

WYM.BAZ.009 Hasła użytkowników są przechowywane w bazie danych w postaci niejawnej (zaszyfrowanej).

WYM.BAZ.010 W HIS są zaimplementowane mechanizmy walidacji haseł zgodnie z wymaganiami ustawowymi przewidzianymi dla rodzaju danych przetwarzanych przez HIS.

WYM.BAZ.011 HIS umożliwia automatyczne wylogowanie użytkownika z systemu (przy przekroczeniu zadanego czasu bezczynności ustanowionego uprzednio przez Administratora).

WYM.BAZ.012 Dostępność oprogramowania na współczesne 64-bitowe platformy Unix (HP-UX dla procesorów PA-RISC i Itanium, Solaris dla procesorów SPARC i Intel/AMD, IBM AIX), Intel/AMD Linux 32-bit i 64-bit, MS Windows 32-bit i 64-bit. Identyczna funkcjonalność serwera bazy danych na ww. platformach

WYM.BAZ.013 Niezależność platformy systemowej dla oprogramowania klienckiego / serwera aplikacyjnego od platformy systemowej bazy danych

WYM.BAZ.014 Możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy ww. platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego

WYM.BAZ.015 Przetwarzanie z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych.

WYM.BAZ.016 Możliwość zagnieżdżania transakcji – powinna istnieć możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej. Przykładowo – powinien być możliwy następujący scenariusz: każda próba modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona czy wycofana.

WYM.BAZ.017 Wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode).

WYM.BAZ.018 Możliwość migracji zestawu znaków bazy danych do Unicode

WYM.BAZ.019 Możliwość redefiniowania przez klienta ustawień narodowych – symboli walut, formatu dat, porządku sortowania znaków za pomocą narzędzi graficznych.

WYM.BAZ.020 Skalowanie rozwiązań opartych o architekturę trójwarstwową: możliwość uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z serwera aplikacyjnego do serwera bazy danych

WYM.BAZ.021 Możliwość otworzenia wielu aktywnych zbiorów rezultatów (zapytań, instrukcji DML) w jednej sesji bazy danych

83


WYM.BAZ.022 Wsparcie protokołu XA

WYM.BAZ.023 Wsparcie standardu JDBC 3.0

WYM.BAZ.024 Zgodność ze standardem ANSI/ISO SQL 2003 lub nowszym.

WYM.BAZ.025 Motor bazy danych powinien umożliwiać wskazywanie optymalizatorowi SQL preferowanych metod optymalizacji na poziomie konfiguracji parametrów pracy serwera bazy danych oraz dla wybranych zapytań. Powinna istnieć możliwość umieszczania wskazówek dla optymalizatora w wybranych instrukcjach SQL.

WYM.BAZ.026 Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy).

WYM.BAZ.027 Wsparcie dla procedur i funkcji składowanych w bazie danych. Język programowania powinien być językiem proceduralnym, blokowym (umożliwiającym deklarowanie zmiennych wewnątrz bloku), oraz wspierającym obsługę wyjątków. W przypadku, gdy wyjątek nie ma zadeklarowanej obsługi wewnątrz bloku, w razie jego wystąpienia wyjątek powinien być automatycznie propagowany do bloku nadrzędnego bądź wywołującej go jednostki programu

WYM.BAZ.028 Procedury i funkcje składowane powinny mieć możliwość parametryzowania za pomocą parametrów prostych jak i parametrów o typach złożonych, definiowanych przez użytkownika. Funkcje powinny mieć możliwość zwracania rezultatów jako zbioru danych, możliwego do wykorzystania jako źródło danych w instrukcjach SQL (czyli występujących we frazie FROM). Ww. jednostki programowe powinny umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML, DDL), umożliwiać jednoczesne otwarcie wielu tzw. kursorów pobierających paczki danych (wiele wierszy za jednym pobraniem) oraz wspierać mechanizmy transakcyjne (np. zatwierdzanie bądź wycofanie transakcji wewnątrz procedury).

WYM.BAZ.029 Możliwość kompilacji procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej)

WYM.BAZ.030 Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba zalogowania użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto mechanizm wyzwalaczy powinien umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views).

WYM.BAZ.031 W przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza, wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy danych, zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed rozpoczęciem instrukcji w której wystąpił ww. błąd lub wyjątek

WYM.BAZ.032 Powinna istnieć możliwość autoryzowania użytkowników bazy danych za pomocą rejestru użytkowników założonego w bazie danych

WYM.BAZ.033 Baza danych powinna umożliwiać na wymuszanie złożoności hasła użytkownika, czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora bądź w przypadku przekroczenia limitu nieudanych logowań.

WYM.BAZ.034 Przywileje użytkowników bazy danych powinny być określane za pomocą przywilejów systemowych (np. prawo do podłączenia się do bazy danych - czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu / modyfikacji tabeli, wykonania procedury). Baza danych powinna umożliwiać nadawanie ww. przywilejów za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W danej chwili użytkownik może mieć aktywny dowolny podzbiór nadanych ról bazodanowych.

WYM.BAZ.035 Możliwość wykonywania i katalogowania kopii bezpieczeństwa bezpośrednio przez serwer bazy danych. Możliwość zautomatyzowanego usuwania zbędnych kopii bezpieczeństwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki nadmiarowości backup'ów. Możliwość integracji z powszechnie stosowanymi systemami backupu (Legato, Veritas, Tivoli, OmniBack, ArcServe itd). Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie offline oraz w trybie online

WYM.BAZ.036 Możliwość wykonywania kopii bezpieczeństwa w trybie online (hot backup).

84


WYM.BAZ.037 Odtwarzanie powinno umożliwiać odzyskanie stanu danych z chwili wystąpienia awarii bądź cofnąć stan bazy danych do punktu w czasie. W przypadku odtwarzania do stanu z chwili wystąpienia awarii odtwarzaniu może podlegać cała baza danych bądź pojedyncze pliki danych.

WYM.BAZ.038 W przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz danych mogą być dostępne dla użytkowników

WYM.BAZ.039 Wbudowana obsługa wyrażeń regularnych zgodna ze standardem POSIX dostępna z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych.

WYM.BAZ.040 Możliwość budowy klastra na węźle obsługiwanym przez maksymalnie 2 procesory

WYM.BAZ.041 Licencje motoru bazy danych nie mogą ograniczać ilości użytkowników

WYM.BAZ.042 Licencja motoru bazy danych nie może posiadać ograniczenia co do wielkości przechowywanych danych oraz nie może powodować dodatkowych opłat w przypadku przyrostu danych

WYM.BAZ.042 Wykonawca dostarczy licencję na motor bazy danych dla 1 fizycznego procesora w architekturze X86.

Warunki integracji dostarczanych rozwiązań z oprogramowaniem użytkowanym przez Zmawiającego

1. Zamawiający informuje, iż zgodnie z wiążącą go umową licencyjną z twórcami posiadanych systemów informatycznych, nie jest w posiadaniu kodów źródłowych modułów tych systemów.

2. Zamawiający jako załącznik nr 17 do SIWZ przedstawia opisy techniczne interfejsów uzyskane od dostawcy systemu CliniNet. Zamawiający informuje, że obowiązkiem Wykonawcy jest ich weryfikacja oraz wszystkie koszty związane z integracją z wymienionymi w SIWZ systemami w tym określenie wykonawcy lub wykonawców tych integracji jest obowiązkiem Wykonawcy.

3. Ustalenie kosztów integracji z systemami posiadanymi przez Zamawiającego jest obowiązkiem Wykonawcy.

4. Koszty integracji są częścią ceny, składanej przez Wykonawcę. Wykonawca zobowiązany jest uwzględnić w ofercie pełny koszt wykonania integracji uwzględniający również, o ile będzie to konieczne, wykonanie modyfikacji interfejsów wymiany danych posiadanych systemów oraz zakup niezbędnych do integracji licencji.

5. Zamawiający dopuszcza na podstawie art.75 ust.2 pkt 3 ustawy Prawo autorskie (Dz.U. 2006, nr 90, poz.631) - konieczność dokonania przez Wykonawcę dekompilacji modułów systemów, dotychczas wykorzystywanych przez Zamawiającego, poprzez zwielokrotnienie kodu lub tłumaczenie jego formy w rozumieniu art.74 ust.4 pkt 1 i 2 ustawy Prawo autorskie (Dz.U. 2006, nr 90, poz.631), jeżeli będzie to niezbędne do uzyskania informacji koniecznych do osiągnięcia współdziałania modułów tych systemów z ZSI dostarczonym w ramach realizacji zamówienia. Wykonawca będzie zobowiązany wykonać czynności dekompilacyjne na własny koszt i ryzyko, w pełnym koniecznym zakresie z zastrzeżeniem, że czynności te będą odnosiły się tylko do tych części modułów tych systemów, które będą niezbędne do osiągnięcia współdziałania tych modułów z ZSI dostarczonymi przez Wykonawcę, a uzyskane informacje nie będą:

a) wykorzystane do innych celów niż osiągnięcie współdziałania niezależnie stworzonego programu komputerowego;

b) przekazane innym osobom, chyba że jest to niezbędne do osiągnięcia współdziałania niezależnie stworzonego programu komputerowego;

c) wykorzystane do rozwijania, wytwarzania lub wprowadzania do obrotu programu komputerowego o istotnie podobnej formie wyrażenia lub do innych czynności naruszających prawa autorskie.

6. Informacje uzyskane przez Wykonawcę w toku wykonania czynności, o których mowa w art.75 ust.2 pkt 3 ustawy Prawo autorskie (Dz.U. 2006, nr 90, poz.631) stanowią tajemnicę przedsiębiorstwa, w rozumieniu Ustawy o zwalczaniu nieuczciwej konkurencji z dnia 16 kwietnia 1993 r. (Dz.U. Nr 47, poz. 211 z późn. zm.) i podlegają ochronie w niej przewidzianej.

85


7. Na prośbę Wykonawcy, Zamawiający umożliwi Wykonawcy dostęp do baz danych posiadanych systemów informatycznych, udzieli wsparcia Wykonawcy w dokonaniu integracji, poprzez nadanie wskazanym pracownikom Wykonawcy niezbędnych uprawnień do pracy w systemie oraz przekaże Wykonawcy posiadane instrukcje obsługi. Wykonawca ponosi odpowiedzialność za ewentualne szkody, wyrządzone przez jego pracowników w trakcie prac integracyjnych.

Migracja bazy danych systemu HIS użytkowanego przez Zamawiającego Przedmiotem zadania jest migracja z użytkowanego systemu CGM CLININET firmy CGM na wydajny silnik bazy danych, celem podniesienia wydajności i skalowalności systemu. Proces migracji musi odbywać się ze szczególnym uwzględnieniem zachowania ciągłości pracy Zamawiającego i w ramach tego procesu wszelkie przestoje systemu muszą być zaplanowane i uzgodnione z Zamawiającym. W ramach procesu migracji Wykonawca jest zobowiązany do przeniesienia danych z użytkowanych instancji systemu na nowy dostarczany w ramach zamówienia silnik bazy danych, podłączenia systemu HIS w konfiguracji funkcjonalnej jaka istniała u Zamawiającego oraz uruchomienia systemu we wszystkich użytkowanych obecnie przez Zamawiającego aspektach to jest:

1. System musi być uruchomiony w zakresie wszystkich modułów oraz we wszystkich lokalizacjach wymienionych w punkcie „Opis stanu bieżącego” tego dokumentu.

2. Musi mieć możliwość zachowania ciągłości pracy wszystkich użytkowników. Jeżeli elementy interfejsu graficznego systemu i/lub przebiegu procesu ulegną zmianie w wyniku migracji Wykonawca jest zobowiązany w tych obszarach przeszkolić wszystkich użytkowników systemu.

3. Wykonawca jest zobowiązany do uruchomienia pełnego zakresu integracji z systemami opisanymi w rozdziale „Opis stanu bieżącego”. Koszt ewentualnej modyfikacji integrowanych systemów stanowi koszt Wykonawcy i jest on w pełni odpowiedzialny za uruchomienie pełnych funkcjonalności integracji po wykonaniu migracji.

W ramach procesu migracji Wykonawca jest zobowiązany do wykonania następujących zadań:

1. Dostarczenia i instalacji systemów operacyjnych dla serwerów, biorąc pod uwagę specyfikę konfiguracyjną aktualnie funkcjonującego systemu i ustaloną na etapie analizy przedwdrożeniowej.

2. Dostarczenia i instalacji wydajnego silnika bazy danych.

3. Wykonania audytu bieżącej instalacji systemu celem określenia szczegółowej listy elementów niestandardowych, które będą podlegały odtworzeniu na nowym środowisku bazy danych w szczególności raportów i wydruków używanych przez Zamawiającego,

4. Przedstawienia planu, harmonogramu migracji i projektu technicznego migracji do akceptacji Zamawiającego

5. Wykonania zaakceptowanego planu migracji w szczególności zainstalowania, uruchomienia i wdrożenia systemu na nowej wydajnej bazie danych wraz ze wszystkimi elementami niezbędnymi do jego poprawnego funkcjonowania takimi jak: systemy operacyjne, serwery aplikacyjne, konfiguracja bazy danych.

6. Przeszkolenia administratorów Zamawiającego z nowej konfiguracji systemu oraz struktury bazy danych.

7. Przeniesienia wszystkich danych z użytkowanego systemu CGM CLININET na nową instancję bazy danych.

8. Wykonania testów potwierdzających poprawne funkcjonowanie wszystkich modułów aplikacji oraz potwierdzającymi prawidłowość działania raportów, wydruków i integracji z innymi systemami.

9. Przeszkolenia użytkowników w zakresie w jakim uległ modyfikacji interfejs graficzny użytkownika i/lub przebieg procesów w systemie.

10. Przedstawienie raportu z migracji zawierającego raporty z testów oraz potwierdzenie kompletnego przeniesienia danych pomiędzy systemami bazodanowymi (użytkowanym i zaoferowanym).

86


11. Uruchomienia i wdrożenia systemu Clininet na nowej wydajnej bazie danych wraz z asystą uruchomieniową w zakresie w jakim modyfikacji uległ interfejs graficzny użytkownika i/lub przebieg procesów w systemie.

Organizacja prac migracyjnych

W celu efektywnego prowadzenia prac projektowych w ramach migracji bazy HIS muszą zostać powołane odpowiednie struktury projektowe, zarówno po stronie Wykonawcy, jak również po stronie Zamawiającego, w skład której wejdą:

1. Kierownik Procesu migracji

2. Kierownik Zespołu ds. migracji danych

3. Kierownik Zespołu ds. testów

Kierownictwo Procesu migracjiW skład kierownictwa wchodzi Kierownik Procesu migracji ze strony Zamawiającego oraz Kierownik Procesu migracji ze strony Wykonawcy. Wykonawca i Zamawiający są zobowiązani do wskazania osób pełniących role Kierownika Procesu migracji.

Obowiązki Kierownika Procesu migracji ze strony Wykonawcy:

1. Wyznaczenie osób upoważnionych do realizacji przedmiotu umowy.

2. Lista osób upoważnionych zostanie przekazana Kierownikowi Procesu migracji ze strony Zamawiającego bezzwłocznie po podpisaniu umowy oraz bezzwłocznie po każdej zmianie osób upoważnionych.

3. Nadzór nad czynnościami realizowanymi, w ramach realizacji przedmiotu umowy, przez osoby upoważnione o których mowa w pkt. 1, w szczególności w zakresie zgodności z postanowieniami umowy.

4. Przygotowywanie planów etapów i ewentualnych planów awaryjnych dla Procesu migracji.

5. Przygotowywanie harmonogramu realizacji.

6. Zgłaszanie, zatwierdzanie gotowości do odbioru usług Kierownikowi Procesu migracji ze strony Zamawiającego.

7. Zgłaszanie potrzeby konsultacji i doradztwa w zakresie realizacji.

8. Nadzór i kontrola realizacji prac i zobowiązań zgodnie z uzgodnionymi terminami.

9. Prowadzenie i archiwizowanie dokumentacji zdarzeń i czynności wykonanych w ramach realizacji umowy, pozwalających na ustalenie faktów związanych m.in. ze zlecaniem, odbiorem i rozliczeniem usługi migracji.

10. Zapewnienie odpowiedniego zastępstwa na czas swojej nieobecności z poinformowaniem Kierownika Procesu migracji ze strony Zamawiającego.

11. Przedkładanie informacji Kierownikowi Procesu migracji ze strony Zamawiającego zgodnie z jego potrzebami.

12. Przedkładanie wniosków, sugestii i propozycji Kierownikowi Procesu migracji ze strony Zamawiającego zgodnie z potrzebami.

13. Realizowanie we współpracy z Kierownikiem ze strony Zamawiającego wszystkich zadań związanych z procesem zarządzania migracją.

14. Kontrola zakresu Procesu migracji.

15. Zarządzanie ryzykiem.

16. Wspólna z Kierownikiem Procesu migracji ze strony Zamawiającego kontrola realizacji Procesu migracji, w szczególności w obszarach prac wykonywanych przez pracowników Wykonawcy.

87


17. Wspólne z Kierownikiem Procesu migracji ze strony Zamawiającego rozwiązywane istotnych kwestii pojawiających się podczas prac procesowych; nadzór nad Liderami Zespołów Procesu migracji.

18. Koordynacja przeprowadzenia odbioru prac w Procesie migracji. W przypadku powstania kwestii spornych między stronami zaangażowanymi w realizację Procesu migracji Kierownik powinien być stroną rozstrzygającą o najlepszym rozwiązaniu.

Obowiązki Kierownika Procesu migracji ze strony Zamawiającego:

1. Współpraca z Wykonawcą w realizacji przedmiotu umowy.

2. Bezzwłoczne rozstrzyganie spraw spornych pomiędzy zespołami ze strony Zamawiającego oraz Wykonawcą.

3. Określenie formy sprawozdań przedstawianych przez Kierownika Projektu migracji ze strony Wykonawcy.

4. Zatwierdzanie planów etapów i ewentualnych planów awaryjnych.

5. Zatwierdzanie harmonogramu Procesu migracji.

6. Przyjmowanie i akceptacja protokołów odbioru z realizacji etapów migracji.

7. Prawo i obowiązek formalnego zgłoszenia żądania zmiany jeżeli uzna, że dla zapewnienia prawidłowej realizacji migracji konieczne jest podjęcie działań mających wpływ na ustalony zakres prac.

8. Przegląd, zgłaszanie uwag, akceptacja oraz odbiór poszczególnych etapów migracji.

9. Zarządzanie i kontrola zakresu Procesu migracji - wspólne z Kierownikiem Procesu migracji ze strony Wykonawcy zarządzanie zakresem prac realizowanych w ramach Procesu migracji.

10. Zarządzanie jakością - w rozumieniu jakości realizacji Procesu migracji oraz jakości dostarczanych produktów prac, w ścisłej współpracy z Kierownikiem Procesu migracji ze strony Wykonawcy

11. Nadzór nad pracownikami Zamawiającego.

12. Zarządzanie komunikacją - zapewnienie odpowiedniego procesu informacyjnego dotyczącego prowadzonych prac i ich wyników oraz wspólnego z Kierownikiem ze strony Wykonawcy.

13. Zarządzanie ryzykiem - w ścisłej współpracy z Zespołami Procesu migracji Zamawiającego i Kierownikiem Procesu migracji ze strony Wykonawcy.

14. Zapewnienie zasobów ze strony Zamawiającego koniecznych do terminowego i zgodnego z założeniami wykonania prac.

Do obowiązków Lidera Zespołu Procesu migracji należy koordynowanie prac w ramach zadań Zespołu zgodnie z przyjętym zakresem i harmonogramem zdefiniowanym dla danego obszaru prac. W szczególności do obowiązków Lidera należy:

1. Zarządzanie pracą specjalistów pracujących w ramach danego Zespołu poprzez precyzyjne wyznaczanie celów i zadań.

2. Informowanie Kierownictwa Procesu migracji o postępie prac oraz ewentualnych ryzykach związanych z ich realizacją w części, za którą odpowiada.

3. Opiniowanie i podejmowanie decyzji w zakresie założeń oraz koncepcji przedstawianych przez Zespół.

4. Ocena jakości realizowanych prac.

5. Operacyjne zarządzanie czasem pracy specjalistów Zespołu.

6. Zarządzanie harmonogramem pracy danego Zespołu.

7. Przekazywanie produktów do akceptacji Kierownictwa Procesu migracji.

8. Opiniowanie prac z zakresu pracy Zespołu wykonanych przez Wykonawcę.

Opis sposobu zarządzania ryzykiem w procesie migracjiKierownik procesu migracji ze strony Wykonawcy musi opracować i przedstawić Kierownikowi Procesu migracji ze strony Zamawiającego do akceptacji rejestr zagrożeń i środków zaradczych, gdzie identyfikowane

88


i kategoryzowane są poszczególne czynniki ryzyka za pomocą poziomu wpływu na proces migracji, prawdopodobieństwa wystąpienia, priorytetu, daty powstania i zamknięcia, właściciela ryzyka, opisu ryzyka, kategorii, wymaganych środków zaradczych, statusu. Rejestr ten musi być na bieżąco w ramach potrzeb aktualizowany.

Opis sposobu komunikacji Wykonawcy z Zamawiającym Podczas przeprowadzenia migracji bazy danych systemu HIS muszą obowiązywać następujące założenia dotyczące wzajemnej współpracy Zamawiającego i Wykonawcy:

1. Komunikacja między uczestnikami Procesu migracji po stronie Wykonawcy i Zamawiającego musi odbywać się na poziomie Kierowników Procesu migracji obu stron oraz Liderów Zespołów i wyznaczonych osób po stronie Zamawiającego.

2. Przewiduje się wykorzystanie różnych mediów komunikacyjnych uzależnionych od poziomu oraz wagi uzgodnień. Podstawowym środkiem komunikacji w ramach prac roboczych uczestników Procesu migracji musi być poczta elektroniczna, kontakt telefoniczny i telekonferencje, z zastrzeżeniem że jeżeli podczas rozmowy podjęte zostaną istotne ustalenia muszą one zostać potwierdzone poprzez e-mail.

3. Prace wspólne specjalistów po obu stronach (spotkania w ramach analizy przedwdrożeniowej, testy odbiorcze, szkolenia) muszą być każdorazowo potwierdzone przedstawioną przez Wykonawcę i podpisaną przez obie strony, notatką ze spotkania, zawierającą: listę uczestników, wykonanych zadań, opisem poruszanych zagadnień, czy ustaleniami.

4. Spotkania poświęcone kontroli realizacji wdrożenia muszą być organizowane w miarę bieżących potrzeb na życzenie Zamawiającego. Wykonawca będzie odpowiedzialny za przedstawienie raportu o bieżącym zaawansowaniu prac i informacji o zagrożeniach w realizacji procesu migracji oraz sposobach rozwiązywania tych problemów. Spotkania dotyczące kontroli realizacji Procesu migracji również muszą być potwierdzone notatką ze spotkania podpisaną przez Strony.

5. Zgłoszenie zagadnienia wymagającego decyzji Kierownika Procesu migracji przez Wykonawcę musi zachować formę pisemną.

Zgłoszenie zmiany w pracach migracyjnych

1. Potrzeba wprowadzenia zmian musi wynikać między innymi z:

1) potrzeb, które zostały błędnie zdefiniowane, nie zostały zdefiniowane lub uległy zmianie w trakcie przebiegu Procesu migracji. W szczególności dotyczy to potrzeby zmian lub rozszerzeń funkcjonalności systemu - związanych z dopasowaniem funkcjonalności systemu do specyficznych potrzeb Zamawiającego w zakresie realizacji procesów biznesowych,

2) zaakceptowanego przez strony sposobu neutralizacji ryzyka procesu migracji,

3) wprowadzenia w trakcie wdrożenia zmian organizacyjnych u Zamawiającego, które mają wpływ na zatwierdzony sposób realizacji procesów biznesowych,

4) konieczności wprowadzenia zmian w zatwierdzonych etapach przedmiotu umowy.

2. Potrzebę zmiany będą mieli prawo i obowiązek zgłosić Kierownicy Procesu migracji ze strony Zamawiającego i Wykonawcy, jeżeli uznają, że dla zapewnienia prawidłowej realizacji migracji konieczne jest podjęcie działań mających wpływ na ustalony zakres prac.

3. Żądanie zmiany musi być dokumentowane przez zgłaszającego za pomocą formularza żądania zmiany. Wykonawca w terminie 5 dni roboczych dokonuje analizy zmiany na dokumentację Procesu migracji i przedstawia ją Kierownikowi Procesu migracji ze strony Zamawiającego. Po zapoznaniu z analizą Kierownik Procesu migracji Zamawiającego ma prawo przyjąć bądź odrzucić zmianę. Zmiany dotyczące harmonogramu procesu migracji muszą być zatwierdzone przez Kierownika Procesu migracji po stronie Zamawiającego.

89


Przebieg procesu migracji

Harmonogram realizacji Procesu migracji bazy danych systemu CGM CLININET musi obejmować:

1. Analizę przedwdrożeniową migracji - opracowanie planu migracji i projektu technicznego migracji systemu HIS - w terminie nie dłuższym niż 14 dni kalendarzowych od dnia zawarcia Umowy.

Punkt ten musi zawierać następujące elementy:1) uruchomienie Procesu migracji po stronie Wykonawcy,2) przedstawienie harmonogramu prac procesowych,3) powołanie struktury procesowej po stronie Wykonawcy i przedstawienie jej.Przedstawienia planu migracji oraz projektu technicznego migracji zawierającego następujące elementy: 1) harmonogram procesu migracji danych,2) analizę ryzyka związanego z procesem migracji wraz z planami odpowiedzi minimalizującymi ich

wystąpienie,3) opis konfiguracji obecnego systemu,4) opis konfiguracji docelowego systemu,5) szczegółowy opis procesu migracji danych ze szczególnym uwzględnieniem sposobów w jaki sposób

Wykonawca chce zapewnić: - kompletność i wiarygodność danych podlegających migracji,- bezpieczeństwo danych podlegających migracji,- zabezpieczenie ciągłości pracy Zamawiającego,- integrację z innymi systemami,

6) przebieg i szczegółowy opis procedury testowej poprawności migracji,7) szablon raportu z migracji systemu.

2. Dostawę i instalacja oprogramowania zakupionego w ramach przedmiotu zamówienia w terminie uzgodnionym na etapie analizy przedwdrożeniowej. Punkt ten musi obejmować następujące elementy:1) instalacja i konfiguracja obejmie zarówno systemy operacyjne jak i serwery baz danych,2) dostawa, instalacja i konfiguracja oprogramowania.

3. Wykonanie procesu migracji bazy danych systemu CGM CLININET na wydajną bazę danych, uruchomienie i wdrożenie systemu w nowej konfiguracji w terminie uzgodnionym na etapie analizy przedwdrożeniowej.1. Wykonanie zaakceptowanego planu migracji w szczególności zainstalowania, uruchomienia

i wdrożenia systemu na nowej wydajnej bazie danych wraz ze wszystkimi elementami niezbędnymi do jego poprawnego funkcjonowania takimi jak: systemy operacyjne, serwery aplikacyjne, konfiguracja bazy danych, konfiguracja sieci, konfiguracja i wdrożenie backupów.

2. Przeniesienia wszystkich danych z użytkowanego systemu CGM CLININET na nową instancję bazy danych.

3. Wykonania testów potwierdzających poprawne funkcjonowanie wszystkich modułów systemu oraz potwierdzającymi prawidłowość działania raportów, wydruków i integracji z innymi systemami.

4. Przeszkolenie administratorów wskazanych przez Zamawiającego ze struktury nowej bazy danych i udostępnienie jej do odczytu, w celu konwersji obecnie istniejących raportów, formularzy i wydruków funkcjonujących u Zamawiającego.

5. Przeszkolenia użytkowników w zakresie w jakim modyfikacji uległ interfejs graficzny użytkownika i/lub przebieg procesów w systemie.

6. Przedstawienie raportu z migracji zawierającego raporty z testów oraz potwierdzenie przeniesienia danych pomiędzy systemami.

7. Uruchomienia i wdrożenia systemu na nowej wydajnej bazie danych wraz z asystą uruchomieniową w obszarach w jakich modyfikacji uległ interfejs graficzny użytkownika i/lub przebieg procesów w systemie.

8. Osiągnięcie średniego czasu reakcji Systemu równego lub niższego niż 1s. Analiza przedwdrożeniowa Procesu migracjiW zakresie analizy przedwdrożeniowej Procesu migracji Wykonawca zobowiązany będzie do:

1. Przeprowadzenia audytu istniejącego rozwiązania celem identyfikacji i inwentaryzacji konfiguracji elementów niestandardowych systemu HIS użytkowanego przez Zamawiającego w szczególności:

90


a) raportów,

b) wydruków,

c) formularzy,

d) integracji z innymi systemami,

e) bieżącej konfiguracji systemu HIS,

f) konfiguracji procedur backupu systemu HIS.

Wszystkie elementy wynikające z audytu muszą zostać uwzględnione w planie migracji systemu. Warunkiem zaakceptowania planu migracji a następnie jej realizacji jest pełne odtworzenie istniejącej funkcjonalności obecnego systemu również w zakresie elementów niestandardowych wymienionych w pkt a-f. Zamawiający zastrzega sobie prawo rezygnacji z przenoszenia wybranych raportów i wydruków. Decyzja w tym zakresie jest wyłączną kompetencją Zamawiającego i zostanie określona na etapie analizy przedwdrożeniowej Procesu migracji.

2. Opracowania planu migracji – Plan migracji musi opisywać proces migracji danych z obecnie użytkowanej bazy do wydajnej bazy danych dostarczanej w ramach tego zamówienia i musi zawierać minimum następujące elementy:

1) wskazanie osób odpowiedzialnych za realizację planu i poszczególnych zadań po stronie Wykonawcy,

2) wskazanie zadań leżących po stronie Wykonawcy,

3) wskazanie zadań leżących po stronie Zamawiającego,

4) szczegółowy harmonogram planowanych prac ze szczególnym uwzględnieniem sytuacji w której obecnie użytkowany system będzie niedostępny,

5) opracowanie projektu technicznego migracji systemu HIS.

3. Opracowanie planu testów akceptacyjnych migracji systemu zawierającego:

a) plan testów,

b) scenariusze testowe.

Migracja danych Wykonawca jest odpowiedzialny za przeprowadzenie pełnego procesu migracji danych pomiędzy

obecnie użytkowaną bazą SYBASE ASE systemu HIS a nową wydajną dostarczaną bazą danych.

Zamawiający na etapie realizacji umowy zapewni Wykonawcy dostęp do bazy danych obecnie użytkowanego systemu. Zamawiający zastrzega, że nie jest twórcą dokumentacji systemu HIS CGM CLINIENT i nie może odpowiadać za kompletność przekazanej dokumentacji. Zamawiający zastrzega, że ewentualne luki w dokumentacji struktury bazy danych nie stanowią podstawy dla Wykonawcy dla zaprzestania lub zmniejszenia zakresu migracji danych ani do przesunięcia wymaganych terminów realizacji zadania. Zamawiający do przeprowadzenia migracji bazy danych udostępni interfejs administracyjny serwerów baz danych w trybie odczytu. Wykonawca nie może ingerować w dane ani strukturę danych jak i samych baz danych obecnie użytkowanego systemu HIS CGM CLININET w celu przeprowadzenia procesu migracji danych.

Szczegółową konfigurację uwzględniającą również powiązanie z istniejącą infrastrukturą Zamawiającego Wykonawca zaprojektuje i przedstawi do akceptacji Zamawiającego w procesie analizy przedwdrożeniowej migracji w projekcie technicznym migracji.

W ramach konfiguracji środowiska systemu Wykonawca będzie odpowiedzialny za konfigurację serwerów i systemów zgodnie z uzgodnionym projektem technicznym migracji.

System HIS Wykonawca jest zobowiązany do odtworzenia w nowym środowisku wszystkie funkcjonalności

systemu posiadanego przez Zamawiającego w następujących obszarach: 1. System po migracji musi zachować pełną funkcjonalność użytkowaną obecnie przez

Zamawiającego.

91


2. System po migracji na wydajną bazę danych ma zachować możliwość użytkowania wszystkich wydruków, raportów oraz formularzy używanych obecnie przez Zamawiającego. Wykonawca w ramach etapu analizy przedwdrożeniowej Procesu migracji musi wykonać inwentaryzację tych elementów. Wykonawca ma obowiązek przeniesienia wszystkich tych elementów w ramach procesu migracji. Rezygnacja z przeniesienia jest wyłącznym prawem Zamawiającego.

3. System musi zostać uruchomiony i wdrożony we wszystkich komórkach organizacyjnych wymienionych w rozdziale „Opis stanu bieżącego” tego dokumentu.

4. Zamawiający musi mieć możliwość zachowania ciągłości pracy wszystkich użytkowników. Jeżeli elementy interfejsu graficznego systemu i/lub przebiegu procesu ulegną zmianie w wyniku migracji Wykonawca jest zobowiązany w tych obszarach przeszkolić wszystkich użytkowników systemu. Wymagania dla procesu szkoleń przedstawione są w akapicie „Szkolenie personelu w przypadku zmiany interfejsu graficznego lub przebiegu procesu”

5. Wykonawca jest zobowiązany do uruchomienia pełnego zakresu integracji z systemami opisanymi w rozdziale „Opis stanu bieżącego”. Koszt ewentualnej modyfikacji integrowanych systemów stanowi koszt Wykonawcy i jest on w pełni odpowiedzialny za uruchomienie pełnych funkcjonalności integracji po wykonaniu migracji w momencie startu produkcyjnego systemu po migracji.

Migracja danych

W procesie planowania i realizowania migracji danych wymagane jest planowanie i przeprowadzenie procesu migracji danych przez Wykonawcę przy uwzględnieniu minimum następujących faz/kroków:

1. Przygotowanie planu migracji danych ‐ ustalenie zakresu danych do migracji, sposoby i zakres danych do poprawienia, struktury pośrednich, sposobu przekazania danych, sposobów weryfikacji i innych szczegółów potrzebnych do prawidłowej migracji wszystkich danych wymaganych przez Zamawiającego. Szczegółowy opis wymagań dla planu migracji zawarto w rozdziale „Analiza przedwdrożeniowa Procesu migracji” 2. Pobranie danych do struktur pośrednich – czynność musi dotyczyć przygotowania i wykonania uzgodnionych w planie migracji skryptów pobierających dane do struktur pośrednich (np. testowa baza danych, pliki XML) i eksportu danych do tych struktur.3. Weryfikacja poprawności danych w strukturach pośrednich – weryfikacja poprawności procesu exportu danych z systemu źródłowego i importu do struktur pośrednich. W przypadku wystąpienia błędów przy weryfikacji danych w strukturach pośrednich, musi zostać ustalona przyczyna błędu. Jeżeli przyczyna leży w złym pobraniu danych z systemu źródłowego proces musi powrócić do kroku „Pobranie danych do struktur pośrednich”. Jeżeli problem dotyczy błędu w procedurach importu danych Wykonawca musi poprawić te procedury i ponownie dokonać importu i weryfikacji danych. 4. Migracja testowa - w celu realizacji migracji testowej Wykonawca zobowiązany jest do wykonania kopii docelowego środowiska wydajnej bazy danych na infrastrukturze Zamawiającego i przeprowadzenia kompletnego zasilania danymi tego środowiska za pomocą skryptów i algorytmów, które będą wykorzystywane przy docelowej migracji. Celem migracji testowej jest przetestowanie procedur eksportu/importu danych, procedur czyszczenia, uzupełniania, agregacji danych, procedur weryfikacji danych. Migracja testowa co do zasady musi być wykonywana na pełnych danych. Dopuszcza się w niektórych szczególnie wymagających obszarach (ze względu na liczbę danych) realizację migracji testowej na reprezentatywnej próbce danych, po wcześniejszym ustaleniu i zgodzie Zamawiającego. 5. Weryfikacja migracji testowej – w ramach procesu weryfikacji procesu migracji testowej Zamawiający wymaga wykorzystania następujących metod sprawdzania poprawności jej wykonania:

a) Szczegółowa weryfikacja zapis po zapisieZastosowanie jest możliwe tylko wtedy, jeżeli zbór migrowanych danych nie jest liczny i polega na porównaniu danych w starym rozwiązaniu oraz w nowym Systemie zapis po zapisie. Dla ułatwienia tego porównania Dostawca Systemu może przygotować zestawienia tabelaryczne danych z nowego systemu eksportowanie do arkusza kalkulacyjnego lub wydrukowane. Wtedy porównanie musi polegać na zaznaczeniu każdego poprawnego zapisu na wydruku lub w arkuszu.b) Porównanie skryptami Weryfikacja musi polegać na uruchomieniu napisanych wcześniej skryptów porównujących dane znajdujące się w nowym Systemie z danymi źródłowymi zapisanymi w tabelach systemu testowego

92


i źródłowego. W takim przypadku raport zgodności / różnic musi być automatycznie wygenerowany przez dostarczone skrypty.c) Wyrywkowa kontrola danych przez użytkownikówWeryfikacja musi zostać przeprowadzana przez użytkowników docelowych Systemu, mających dostęp do nowego środowiska testowego Systemu oraz Systemu źródłowego. Proces ten będzie polegał na wyszukaniu wybranych danych w jednym i drugim systemie oraz ich porównaniu. Wykonawca wykonana na środowisku testowym uzgodniony na etapie analizy przedwdrożeniowej zestaw testów funkcjonalnych systemu i przedstawi Zamawiającemu raport z ich realizacji. Dodatkowo Wykonawca udostępni wskazanym pracownikom Zamawiającego środowisko testowe na okres min. 2 tygodni tak by mogli oni sprawdzić poprawność działania systemu po migracji wyżej opisaną metodą. d) Porównanie raportów i wydruków z Systemu źródłowego oraz Systemu testowego Proces ten musi polegać na uruchomieniu i porównaniu wybranych raportów/wydruków wygenerowanych z Systemu testowego oraz Systemu źródłowego przez wskazane osoby przez Zamawiającego. e) Weryfikacja statystycznaProces ten musi polegać na przygotowaniu kryteriów poprawności dla migrowanych danych np. liczby rekordów w obydwu systemach dla konkretnych tabel w bazie danych, wartość i liczby świadczeń przekazanych do NFZ itp. Wykonaniu przez dostawcę zestawień porównawczych z obydwu systemów, które umożliwią stwierdzenie poprawności migracji. W ramach testowania poprawności migracji muszą zostać zrealizowane minimum następujące testy:

1. Testy funkcjonalne 2. Testy integracji

6. Migracja docelowa produkcyjna – właściwa migracja, po której musi rozpocząć się produkcyjna praca w nowym Systemie. W przypadku braku stwierdzonych istotnych problemów w trakcie wcześniejszych kroków procesu migracji Zamawiający podejmie decyzję o przeprowadzeniu procesu migracji do nowego, docelowego Systemu opartego o wydajną bazę danych. Wykonawca po procesie migracji jest zobowiązany do weryfikacji poprawności przeniesionych danych – końcowa weryfikacja danych poprzez wykonanie testów poprawności migracji (walidacji danych po migracji) oraz testów wydajności. Pozytywny wynik kończy proces migracji danych.

Wykonawca zobowiązany jest zabezpieczyć trwale dane z systemu źródłowego z momentu migracji danych w postaci kopii bezpieczeństwa danych systemu źródłowego i w przypadku niepowodzenia procesu migracji w założonym harmonogramie przywrócić działanie poprzedniego systemu. Kopie danych oraz systemu w wersji użytkowanej przez Zamawiającego w liczbie sztuk 2 muszą zostać przekazane Zamawiającemu.

Wykonawca musi przeprowadzać migracje w siedzibie Zamawiającego. W przypadku, gdy nie będzie to możliwe, Wykonawca zobowiązany jest do zabezpieczenia pozyskanych od Zamawiającego migrowanych danych w sposób uniemożliwiający wejście w ich posiadanie przez osoby nieupoważnione do ich przetwarzania. Po wykonaniu migracji, wszelkie dane pozyskane w toku migracji przez Wykonawcę zamówienia muszą zostać usunięte ze wszystkich nośników Wykonawcy w sposób uniemożliwiający ich odzyskanie. Jeżeli wystąpi konieczność przekazania Wykonawcy danych do migracji poza siedzibę Zamawiającego, przekazanie musi odbywać się protokolarnie upoważnionemu przedstawicielowi Wykonawcy, a prace związane z obróbką pozyskanych danych odbywać się muszą jedynie w siedzibie Wykonawcy. Wykonawca nie jest upoważniony do przekazywania danych z migracji innym podmiotom.

Dodatkowe wymagania dla procesu migracji zawiera poniższa tabela:

Nr wymagania Opis MIG.001 W ramach procesu migracji Wykonawca zobowiązany jest do zachowania ciągłości procedur i procesów

realizowanych przez Zamawiającego w szczególności musi zachować ciągłość i format wszystkich numeracji stosowanych w procesach leczenia (nr księgi głównej, ksiąg zabiegowych, nr kartotek pacjentów itp.)

MIG.002 W procesie migracji muszą zostać przeniesione wszystkie dane historyczne zgromadzone i przetwarzane obecnie przez Zamawiającego w systemie HIS CGM CLININET

MIG.003 Proces migracji musi zapewnić ciągłość rozliczeń z NFZ zarówno w zakresie nowych danych prowadzanych do zmigrowanego Systemu jak i korekty danych wcześniej przekazanych do płatnika.

MIG.004 Wykonawca musi wykonać migrację danych do nowej wydajnej bazy danych zgodnie z zaakceptowanym planem migracji danych. Wykonawca jest odpowiedzialny za wykonanie migracji wszystkich danych

93


potrzebnych do prawidłowego działania Systemu. MIG.005 Proces migracji nie może zaburzyć wzajemnych powiązań logicznych danych. Wzajemne relacje pomiędzy

danymi w systemie muszą być zachowane. MIG.006 Migracja musi być przeprowadzona w dwóch etapach:

• migracja testowa• migracja produkcyjna.

MIG.007 Warunkiem możliwości wykonania migracji produkcyjnej jest akceptacja przez Zamawiającego wyników migracji testowej na podstawie raportu z testów migracji przedstawionego przez Wykonawcę.

MIG.008 Wykonawca ponosi odpowiedzialność za poprawność danych migrowanych do nowego Systemu i jest zobowiązany bez zbędnej zwłoki usunąć wszelkie skutki wynikające z błędów migracji i dokonać naprawy danych i działania Systemu nawet w przypadku jeżeli nieprawidłowości wystąpią w procesie eksploatacji systemu po odbiorze procedury migracji. Zobowiązanie to dotyczy całości trwania okresu umowy

Odbiór procesu migracji

W ramach realizacji przedmiotu umowy Wykonawca zobowiązany jest przeprowadzić zestaw testów potwierdzających poprawność wykonania migracji. W skład testów realizowanych w ramach procesu migracji systemu HIS powinny zostać zrealizowane minimum następujące testy: Testy funkcjonalne – zestaw testów potwierdzających możliwość realizacji kluczowych procesów na środowisku systemu po migracji na nowy silnik bazy danych. Testy wydajnościowe – testy mające na celu potwierdzenie, że założone w procesie migracji wskaźniki zwiększenia wydajności systemu poprzez migrację na nowy silnik bazy danych zostały osiągnięte. Testy integracji – testy potwierdzające zdolność systemu po migracji do współpracy z innymi systemami dla których konieczność integracji została opisana OPZ.

Wymagania dla systemu elektronicznego obiegu dokumentów (SEOD)

Zadaniem systemu będzie sterowanie przepływem informacji i obsługa realizacji zadań Zamawiającego, jak też pomiędzy Zamawiającym, a otoczeniem.

Podstawowy zakres funkcjonalny systemu powinien umożliwić realizację następujących procesów: tworzenie/obsługa centralnej bazy/archiwum dokumentów zarządzanie/sterowanie przepływem dokumentów, informacji i zadań zarządzanie sprawami udostępnienie narzędzi do tworzenia dokumentów

Szczegółowe wymagania dla SEOD przedstawiono w poniższej tabeli:


Wymagania niefunkcjonalne

WYM.EOD.001 SEOD musi posiadać architekturę trójwarstwową: a. warstwa prezentacji, obejmująca interfejsy użytkownika klienta WWW,b. warstwa aplikacji, obejmującą serwer Systemu, c. warstwa danych, zawierającą serwer bazy danych

WYM.EOD.002 SEOD musi posiadać polskojęzyczny interfejs i polskojęzyczną instrukcję obsługi.

WYM.EOD.003 SEOD musi przechowywać wszystkie dane w bazie danych zgodnej ze standardem SQL oraz zapewniającej transakcyjność operacji. Dopuszcza się przechowywanie poza bazą danych plików, w postaci repozytorium dyskowego – ich integralność z systemem musi być zapewniona przez

94


metadane opisujące poszczególne pliki. Metadane muszą być przechowywane w bazie danych.WYM.EOD.004 SEOD musi działać w środowiskach systemowych bazujących na technologii Microsoft Windows oraz

w środowiskach opartych na systemie linux.

WYM.EOD.005 SEOD musi umożliwiać dostęp do systemu przez użytkownika końcowego z poziomu przeglądarki internetowej, co najmniej Internet Explorer, Firefox, Google Chrome, Opera w najnowszych wersjach.

WYM.EOD.006 SEOD musi cechować się interfejsem użytkownika opartym na nowoczesnych rozwiązaniach: wykorzystywać menu, listy, formularze, przyciski, referencje (linki), itp.

WYM.EOD.007 Wymaga się, aby interfejs użytkownika SEOD stosował oznaczanie pól wymaganych na formularzu ekranowym w sposób wyróżniający te pola a w przypadku ich błędnego wypełnienia jednoznacznie wskazywał na pola błędnie wypełnione.

WYM.EOD.008 SEOD musi cechować duża elastyczność, rozumiana jako możliwość dostosowania systemu do zmieniających się wymagań funkcjonalnych wynikających ze zmieniającego się stanu prawnego i zmieniających się warunków praktycznych i przepisów prawnych.

WYM.EOD.009 SEOD musi posiadać widok indywidualny, prezentujący tylko te składniki systemu, do których uprawniony jest dany użytkownik.

WYM.EOD.010 SEOD musi udostępniać API metodą REST, autentykacja musi odbywać się za pomocą tokenu indywidualnie przypisywanemu każdemu użytkownikowi, dzięki czemu systemy zewnętrzne komunikują się w imieniu tego użytkownika, a dany użytkownik w systemach zewnętrznych posiada te same uprawnienia i ograniczenia.

Wymagania funkcjonalne

WYM.EOD.011 SEOD musi obsługiwać rejestrację przesyłek przychodzących, w formie papierowej i elektronicznej (przekazywanych za pośrednictwem Elektronicznej Skrzynki Podawczej na ePUAP lub innych skrzynek podawczych oraz poczty elektronicznej).

WYM.EOD.012 Podczas procesu rejestracji przesyłek przychodzących w formie papierowej SEOD musi umożliwiać skanowanie z wykorzystaniem skanera zgodnego z TWAIN (z poziomu interfejsu aplikacji) poszczególnych dokumentów, wchodzących w skład przesyłki. Interfejs do skanowania musi posiadać, co najmniej narzędzia do edycji obrazu ze skanera poprzez: obrót o dowolny kąt, zmianę kolejności stron, zapis do PNG i PDF, zmiany kontrastu.

WYM.EOD.013 SEOD musi umożliwiać odebranie poczty elektronicznej za pomocą wbudowanego klienta pocztowego POP3 oraz SMTP i umożliwić rejestrację w rejestrze przesyłek wpływających.

WYM.EOD.014 SEOD musi umożliwiać opatrywanie przesyłek przychodzących metadanymi zgodnie z instrukcją kancelaryjną oraz dowolne rozszerzenie zbioru metadanych w oparciu o rodzaj rejestrowanego dokumentu.

WYM.EOD.015 System musi umożliwiać generowanie potwierdzenia przyjęcia przesyłki wpływającej przez punkt kancelaryjny, opatrzonego kodem kreskowym odpowiadającym kodowi kreskowemu przesyłki. Potwierdzenie przyjęcia wygenerowane przez SEOD musi być konfigurowalne i umożliwiać zamieszczenie, co najmniej daty wpływu, oznaczenia graficznego jednostki, nazwy jednostki.

WYM.EOD.016 SEOD musi umożliwiać rejestrację zwrotów przesyłek oraz pocztowych potwierdzeń odbioru (zwrotek).

WYM.EOD.017 SEOD musi umożliwiać zarządzanie zakresem zawartości słowników systemowych. Minimalna lista słowników to: JRWA, Rodzaje dokumentów, Sposoby dostarczania korespondencji, Sposoby wysyłania korespondencji, Statusy spraw, Sposoby płatności.

WYM.EOD.018 SEOD musi umożliwiać prowadzenie wielu punktów kancelaryjnych w zakresie rejestracji przesyłek.

WYM.EOD.019 SEOD musi umożliwiać użytkownikom dekretującym wskazanie jednej lub kilku komórek lub osób merytorycznych – odpowiedzialnych za prowadzenie i zakończenie sprawy.

WYM.EOD.020 SEOD musi umożliwić dodawanie przez użytkownika informacji opisujących poszczególne dokumenty lub sprawy w postaci komentarzy/notatek, zgodnie z instrukcją kancelaryjną.

WYM.EOD.021 Dla dokumentów papierowych niepodlegających skanowaniu oraz dokumentów na nośnikach elektronicznych niepodlegających kopiowaniu do systemu SEOD, system musi umożliwić sporządzenie metryki, zawierającej podstawowe informacje o dokumencie (co najmniej – tytuł, identyfikator, notatka).

WYM.EOD.022 SEOD musi umożliwiać dwustronną komunikację z systemem ePUAP (odbieranie – wysyłanie dokumentów).a. SEOD musi odbierać dokumenty z poszczególnych dedykowanych skrytek ESP przekazywanych z Systemu.b. SEOD musi wyświetlić informacje o wniesionej płatności, jeśli była wymagana przy danej e-usłudze. Sposób prezentowania informacji o płatności musi jednoznacznie identyfikować płatność we wpływach Urzędu.

WYM.EOD.023 SEOD musi ewidencjonuje zwrotki wysłanych dokumentów elektronicznych wysyłanych przez ePUAP.

95


WYM.EOD.024 SEOD oznacza dokumenty dostarczone, czyli te ze zwrotką oraz te w przypadku których minęło 14 dni od daty wysłania.

WYM.EOD.025 SEOD musi umożliwić wysyłanie jednego dokumentu do wielu adresatów.

WYM.EOD.026 SEOD musi wyciągać (wyłuskiwać) załączniki z dokumentów XMLowych i przestawiać je w formie do odczytu (jpg/png/pdf) bezpośrednio w przeglądarce.

WYM.EOD.027 SEOD musi być możliwość założenia sprawy lub dołączenia do istniejącej sprawy dokumentu wychodzącego.

WYM.EOD.028 SEOD już podczas uruchomienia musi posiadać pełną bazę adresów skrytek instytucji publicznych.

WYM.EOD.029 SEOD musi sprawdzać poprawność podpisu dokumentu XMLowego i zgodność dokumentu XMLowego ze schematem z CRWDE.

WYM.EOD.030 SEOD musi umożliwić podpisywanie wysyłanych dokumentów Profilem Zaufanym w tym również podpisywanie wielu dokumentów jednocześnie, czyli np. przy wysyłce jednego dokumentu do wielu adresatów.

WYM.EOD.031 Obsługa SEOD w zakresie obsługi korespondencji dokumentów XMLowych musi być podobna do obsługi klienta pocztowego – dotyczy wyglądu, nawigacji oraz obsługi podstawowych czynności – wysyłanie i odbieranie korespondencji.

WYM.EOD.032 SEOD musi automatyczne przypisywać UPP i UPD do wysłanych dokumentów przez ESP.

WYM.EOD.033 SEOD musi być zintegrowany z usługą eNadawca Poczty Polskiej.

WYM.EOD.034 SEOD musi umożliwić tworzenia dokumentów wewnątrz systemu, bez konieczności używania zewnętrznych aplikacji.

WYM.EOD.035 SEOD musi umożliwiać tworzenie szablonów dokumentów co najmniej w zakresie:

d) możliwości zdefiniowania szablonu dokumentu lokalnego i globalnego (wspólnego),

e) prowadzenia repozytorium szablonów, które umożliwia zarządzanie szablonami,

f) możliwości ograniczania wyświetlania szablonów do właściciela, komórki organizacyjnej,

g) możliwości wstawiania znaczników do szablonu. Minimalny zakres znaczników: i. dane nadawcy,

ii. dane adresata (min. imię, nazwisko, adres, nazwa instytucji), iii. kod kreskowy,

iv. pełne dane pracownika prowadzącego sprawę, v. znak pisma/sprawy,

vi. adresaci pisma, vii. data pisma,

viii. lista stron sprawy,

h) możliwości wykorzystania zdefiniowanego szablonu przy tworzeniu pism wychodzących z autouzupełnianiem zawartości w/w znaczników,

i) możliwości generowania korespondencji seryjnej

WYM.EOD.036 Każdy dokument opiera się o indywidualny szablon dokumentu, który jest definiowany w systemie.

WYM.EOD.037 Każdy szablon może posiadać dowolną liczbę kontrolek.

WYM.EOD.038 Każda kontrolka w szablonie dokumentu może posiadać własne definiowane mechanizmy walidacji.

WYM.EOD.039 W przypadku rejestracji dokumentu XML (zgodnego z CRD) system musi automatycznie kopiować dane z poszczególnych węzłów dokumentu XML do odpowiednich kontrolek.

WYM.EOD.040 System musi umożliwić eksport dokumentu systemowego do następujących formatów: XML (zgodnego z CRD), PDF, DOCX, ODT, XML.

WYM.EOD.041 SEOD musi mieć możliwość edytowania załączników (DOCX, XLSX) dołączonych do dokumentów oraz zapisania zmian bezpośrednio w systemie.

WYM.EOD.042 SEOD musi umożliwić generowanie i drukowanie nalepek z kodami kreskowymi na dokumenty papierowe oraz nośniki i odnajdywanie na podstawie zeskanowanej nalepki odwzorowania cyfrowego bądź metryki danego dokumentu.

WYM.EOD.043 SEOD musi umożliwić rejestrację obiegu (lokalizacja, czas przemieszczenia, użytkownik) dokumentów papierowych.

96


WYM.EOD.044 SEOD musi umożliwić sporządzanie odwzorowań cyfrowych dokumentów poprzez skanowanie dostępne z poziomu systemu, zgodnie z wymaganiami określonymi w instrukcji kancelaryjnej.

WYM.EOD.045 SEOD musi umożliwić wszczynanie, prowadzenie i załatwianie spraw, przechowywanie akt sprawy i prowadzenie spisów spraw zgodnie z obowiązującymi przepisami. System automatycznie musi nadawać znak sprawy i zapewnia jego zgodność z wymogami instrukcji kancelaryjnej.

WYM.EOD.046 SEOD musi umożliwić prowadzenie rejestrów kancelaryjnych, w tym rejestru przesyłek wpływających, wychodzących oraz pism wewnętrznych.

WYM.EOD.047 SEOD musi umożliwić numerację i klasyfikację spraw w oparciu o JRWA zgodnie z instrukcją kancelaryjną.

WYM.EOD.048 SEOD musi umożliwiać oddzielną rejestrację dokumentów nietworzących akt sprawy, w szczególności:

a. rejestru faktur – wyposażonego w opcję wieloetapowego zatwierdzania faktury i potwierdzania płatności faktury przez uprawnionych użytkowników wraz z mechanizmem wizualnego oznaczania faktur przeterminowanych,

b. definiowania z poziomu administratora systemu dowolnego rejestru poprzez:

i. definicję pól i typów pól dokumentów wchodzących w skład rejestru,

ii. definicję pól wchodzących w skład wydruku rejestru,

1. możliwość definiowania masek wprowadzanego tekstu w tekstowych polach rejestru.

2. definiowanie uprawnień (podglądu, edycji) na poziomie całego rejestru oraz jego pojedynczych kolumn

WYM.EOD.049 SEOD musi umożliwiać proces akceptacji dokumentów (zgodnie z instrukcją kancelaryjną podmiotu), z możliwością parametryzacji wymagalności akceptacji dla dokumentu przed jego wysłaniem do interesanta lub założeniem z niego sprawy. Użytkownik powinien mieć możliwość swobodnego definiowania ścieżek akceptacji (wskazania konkretnych osób).

WYM.EOD.050 SEOD musi umożliwić zapis projektów pism przekazywanych pomiędzy użytkownikami lub komórkami w trakcie załatwiania sprawy, a także zamieszczanie komentarzy odnoszących się do projektów pism.

WYM.EOD.051 SEOD musi zapewnić prowadzenie, podgląd oraz wydruk metryki sprawy zgodnie z obowiązującymi przepisami.

WYM.EOD.052 SEOD musi umożliwić opisywanie spraw i akt sprawy metadanymi zgodnie z obowiązującymi przepisami.

WYM.EOD.053 SEOD musi umożliwić odnotowanie wysyłki przesyłek wychodzących w rejestrze i opatrzenie ich metadanymi zgodnie z przepisami.

WYM.EOD.054 SEOD musi zapewnić przydzielanie spraw i korespondencji, przekazanych na dane stanowisko, konkretnym użytkownikom, pracującym na tym stanowisku.

WYM.EOD.055 SEOD musi umożliwić podgląd historii sprawy, ścieżki obiegu sprawy.

WYM.EOD.056 SEOD musi posiadać funkcjonalność obsługi kalendarzy. Każdy z użytkowników powinien posiadać dostęp do własnego kalendarza z możliwością dodawania do niego dowolnych zdarzeń. Użytkownik powinien mieć możliwość określenia typu zdarzenia oraz jego opisu. Użytkownik powinien mieć również możliwość definiowania zdarzeń całodniowych i dłuższych oraz cyklicznych. System ma umożliwiać przeglądanie kalendarzy podwładnych. Kalendarz musi umożliwiać dodawanie i edycję wpisów za pomocą mechanizmu „przeciągnij i upuść”.

WYM.EOD.057 SEOD musi umożliwiać zarządzanie zasobami poprzez ustalanie rezerwacji zasobów. System musi umożliwić definiowanie dowolnych zasobów. Każdy zasób musi być powiązany ze „swoim” terminarzem, w którym to uprawnieni użytkownicy mają wgląd. Ponadto tylko uprawnieni użytkownicy mogą rezerwować zasoby, a jej fakt jest odnotowywany w terminarzu zasobu. Musi również istnieć możliwość grupowania zasobów (np. grupa „pojazdy” zwierająca pojazdy, którymi dysponuje Zamawiający).

WYM.EOD.058 SEOD musi posiadać funkcjonalność pozwalającą na zbiorcze podejrzenie dostępności rezerwowanych zasobów i innych użytkowników. System musi umożliwiać rezerwację czasu innych użytkowników (jako współuczestników zdarzenia).

WYM.EOD.059 SEOD musi pozwalać każdemu użytkownikowi swobodnie decydować o tym, kto i w jakim zakresie ma dostęp do jego terminarza.

WYM.EOD.060 Każdy terminarz musi być możliwy do przeglądania w trybie dziennym, tygodniowym, miesięcznym.

97


WYM.EOD.061 SEOD musi być wyposażony w funkcjonalność komunikatora tekstowego. Komunikator musi być integralnym elementem SEOD. Komunikator musi umożliwić prowadzenie rozmów pomiędzy dwoma użytkownikami lub prowadzenie rozmów grupowych.

WYM.EOD.062 SEOD musi umożliwić użytkownikowi podgląd przypisanych do niego spraw i korespondencji, z możliwością sortowania, filtrowania i przeszukiwania.

WYM.EOD.063 System ma umożliwić również kadrze zarządzającej monitorowanie terminowości załatwiania spraw oraz generowania raportów dotyczących korespondencji wychodzącej, przychodzącej, spraw prowadzonych w Urzędzie.

WYM.EOD.064 SEOD musi umożliwiać podpisywanie dokumentów przy pomocy kwalifikowanego podpisu elektronicznego oraz Profilu Zaufanego.

WYM.EOD.065 SEOD musi umożliwić wprowadzanie zmian kadrowych, urlopów i zastępstw. Umożliwia przekazanie osobie zastępującej części lub całości uprawnień osoby zastępowanej. Uprawnienia muszą być przekazane na określony czas dat lub bezterminowo.

WYM.EOD.066 SEOD musi posiadać moduł urlopów umożliwiający co najmniej:a. obsługę wniosków urlopowych umożliwiający złożenie wniosku przez pracownika oraz późniejszą akceptację przez kierownika oraz ostateczne zatwierdzenie przez kadrową, b. wyznaczanie zastępstw na podstawie udzielonych urlopów

WYM.EOD.067 SEOD musi umożliwiać definiowanie zastępstw na czas nieobecności polegających na udzieleniu pełnomocnictwa innemu użytkownikowi do wykonywania czynności w imieniu użytkownika nieobecnego. Pełnomocnictwo powinno być definiowane w określonym przedziale czasu. Dostęp do danych nieobecnego użytkownika powinien być kontrolowany przez System i odbierany wraz z upłynięciem daty końcowej. W trakcie trwania zastępstwa w systemie jest prezentowana informacja o zastępowaniu jednej osoby przez drugą. Wszystkie operacje wykonywane w zastępstwie powinny być zapisane w sposób umożliwiający jednoznaczne określenie, kto wykonał daną operację.

WYM.EOD.068 SEOD musi umożliwić prowadzenie książki teleadresowej interesantów.

WYM.EOD.069 SEOD musi posiadać funkcjonalność wyszukania duplikatów w bazie interesantów i ich łatwego scalenia.

WYM.EOD.070 SEOD musi posiadać wewnętrzny edytor, służący do sporządzania notatek, załączanych do akt sprawy.

WYM.EOD.071 SEOD ma mieć możliwość importu skrytek podawczych podmiotów z platformy ePUAP.

WYM.EOD.072 SEOD musi umożliwić dokumentowanie wyjęcia dokumentacji ze składu chronologicznego lub ze składu informatycznych nośników danych oraz wydrukowanie karty zastępczej dla wypożyczanego nośnika. Procedura obsługi składów powinna być realizowana w następujący sposób: pracownik sprawdza dostępność nośnika a następnie składa wniosek o wypożyczenie, osoba obsługująca skład akceptuje wniosek i wypożycza nośnik, zwrot nośnika również jest potwierdzany przez osobę obsługującą skład.

WYM.EOD.073 SEOD musi zapewnić przejmowanie dokumentacji przez archiwum zakładowe po upływie okresu przewidzianego w instrukcji kancelaryjnej. Przejęcie dokumentacji musi polegać na przekazaniu archiwiście uprawnień do tej dokumentacji w systemie SEOD oraz ograniczeniu uprawnień komórki merytorycznej, zgodnie z instrukcją kancelaryjną.

WYM.EOD.074 SEOD musi posiadać dedykowane funkcje do udostępniania i wycofywania dokumentacji elektronicznej z archiwum zakładowego.

WYM.EOD.075 SEOD musi umożliwiać wypożyczanie spraw z archiwum, podgląd informacji o sprawie oraz zmianę kategorii archiwalnej sprawy przechowywanej w archiwum

WYM.EOD.076 SEOD musi posiadać funkcje wspierające proces porządkowania dokumentacji w archiwum zakładowym (wskazanie dokumentacji wymagającej uzupełnienia).

WYM.EOD.077 SEOD musi realizować brakowanie akt elektronicznych oraz przekazanie akt do archiwum państwowego oraz sporządzenie i przechowywanie odpowiedniej dokumentacji.

WYM.EOD.078 SEOD musi wspierać pracę archiwisty poprzez typowanie dokumentacji do brakowania lub przekazania do archiwum państwowego (po upływie terminów związanych z danymi kategoriami archiwalnymi).

WYM.EOD.079 SEOD musi umożliwiać sporządzenie pocztowej książki nadawczej dostosowanej do zróżnicowanych wymagań występujących w różnych urzędach pocztowych (konfiguracja domyślna dla Jednostki powinna być ustawiana przez administratora).

WYM.EOD.080 SEOD musi posiadać wbudowany mechanizm powiadomień, informujący o istotnych zdarzeniach związanych z jego aktywnością w systemie. Minimalny zbiór powiadomień powinien obejmować informowanie o: zadekretowaniu dokumentu na pracownika, przekazaniu dokumentu do akceptacji, akceptacji dokumentu, udostępnieniu dokumentu pracownikowi itp.

98


WYM.EOD.081 Zgłaszanie błędów dostępne jest z poziomu systemu.

WYM.EOD.082 Jako element zgłoszenia można załączyć plik graficzny ze schowka systemu operacyjnego.

WYM.EOD.083 Zgłoszenie w pierwszej kolejności ma być przekierowane do Administratora systemu w urzędzie.

WYM.EOD.084 Administrator ma możliwość przekazania zgłoszenia w pełnej postaci do wsparcia dostawcy systemu (np. przycisk przekaż zgłoszenie do producenta”)

WYM.EOD.085 Odpowiedź od wsparcia dostawcy SEOD przekazywana jest bezpośrednio do SEOD i z tego poziomu jest dostępna.

WYM.EOD.086 Opóźnienie w komunikacji pomiędzy SEOD a wsparciem dostawcy nie może być większe niż 5 min.

WYM.EOD.087 Dostawca SEOD udostępnia również Panel Klienta jako zewnętrzne narzędzie do zgłaszania błędów na wypadek całkowitego braku dostępu do SEOD zainstalowanego w urzędzie.

WYM.EOD.088 Zgłoszenia wprowadzone w SEOD i Panelu Klienta automatycznie się synchronizują w taki sposób, żeby nie powstawały duplikaty oraz żeby była zachowana ciągłość korespondencji niezależnie od miejsca wprowadzania zgłoszenia.

WYM.EOD.089 Błędu typu "Błąd krytyczny" są automatycznie wysyłane do producenta SEOD w celu podjęcia, bez zwłoki, działań naprawczych.

WYM.EOD.090 W ramach wdrożenia dostawca musi zapewnić Panel Klienta.

WYM.EOD.091 Panel Klienta musi udostępniać wszystkie niezbędne informacje dotyczące wdrożenia i działania SEOD w urzędzie.

WYM.EOD.092 Panel Klienta umożliwia zgłaszanie błędu do wsparcia dostawcy SEOD.

WYM.EOD.093 Panel Klienta udostępnia changelog SEOD – lista kolejnych wersji SEOD z opisem nowych funkcjonalności i poprawek dla każdej wersji.

WYM.EOD.094 Panel Klienta umożliwia zdalną aktualizację SEOD zainstalowanego w urzędzie – Administrator loguje się do Panelu Klienta, przegląda dostępne aktualizację, wybiera wersję, klika “Aktualizuj” i od tego momentu cały proces aktualizacji w urzędzie odbywa się automatycznie. Administrator ma mieć możliwość downgrade’u SEOD do poprzedniej wersji.

WYM.EOD.095 Portal Klienta umożliwia przeglądanie dostępnych szablonów dokumentów oraz instalowanie ich w SEOD urzędu bezpośrednio z poziomu Panelu Klienta.

Administracja systemie SEOD i warunki techniczne

WYM.EOD.096 SEOD musi umożliwić modelowanie wielopoziomowej struktury organizacyjnej instytucji, która umożliwi przypisanie pracowników do odpowiednich stanowisk.

WYM.EOD.097 SEOD musi umożliwić definiowanie uprawnień do poszczególnych funkcji systemu oraz grupowanie uprawnień w role w celu ułatwienia administracji systemem.

WYM.EOD.098 Uprawnienia i role przypisywane są do stanowiska, a nie do użytkownika systemowego.

WYM.EOD.099 Użytkownik logując się do systemu, ma dostęp do określonych obszarów systemu na podstawie uprawnień, które posiada stanowisko, do którego jest przypisany użytkownik.

WYM.EOD.100 SEOD musi umożliwiać delegowanie części lub całości posiadanych uprawnień.

WYM.EOD.101 System musi posiadać wyodrębniony moduł administracyjny. Dostęp do tego modułu mogą uzyskać jedynie użytkownicy z odpowiednimi uprawnieniami.

WYM.EOD.102 SEOD musi posiadać rozbudowany rejestr zdarzeń rejestrujący akcje użytkowników na obiektach systemowych, udane i nieudane próby logowania oraz typowe błędy aplikacji.

WYM.EOD.103 SEOD umożliwi zarządzanie uprawnieniami w oparciu o grupy uprawnień i grupy zasobów, jakich dotyczą. System uprawnień musi być zdolny do odzwierciedlenia uprawnień i odpowiedzialności poszczególnych pracowników wynikający z Instrukcji Kancelaryjnych oraz struktury stanowisk.

WYM.EOD.104 Hasła w SEOD muszą być przechowywane w systemie w formie zaszyfrowanej - nie może być możliwości ich odtworzenia, lecz jedynie zresetowania. Po zresetowaniu hasła użytkownika przez administratora system musi wymagać od użytkownika zdefiniowania nowego hasła przy pierwszym logowaniu.

WYM.EOD.105 SEOD musi umożliwiać swobodne definiowanie polityki uwierzytelniania i blokowania kont w oparciu o następujące parametry:a. Minimalna długość nazwy użytkownika i hasłab. Ilość dużych liter, cyfr, znaków specjalnych w haśle,c. Długość cyklu wymuszania zmiany hasła (w miesiącach),d. Ilość nieudanych prób logowania, po których następuje blokada konta,e. Czas blokady konta po przekroczeniu liczby nieudanych prób logowania

99


WYM.EOD.106 Zakres wartości w słownikach prowadzonych przez system powinien być konfigurowalny przez administratora lub pochodzić z rejestrów centralnych (np. TERYT).

Wdrożenie systemu będzie obejmować w szczególności:

1. Identyfikację schematów przepływu spraw zachodzących u zamawiającego

2. Szkolenie administratorów systemu (ilość osób 2) w wymiarze niezbędnym do zapoznania się z

funkcjami modułu do administracji. Szkolenie powinno obejmować min. Następujące zagadnienia:

tworzenie użytkowników, nadawanie uprawnień użytkownikom, konfiguracja systemu, tworzenie

modyfikowanie słowników, zakładanie struktury organizacyjnej, tworzenie formularzy aktywnych,

definiowanie i modyfikacja schemat obiegu spraw (workflow)

3. Szkolenie użytkowników aplikacji ( 120 osób). Szkolenie powinno obejmować min. Zagadnienia

opisane w specyfikacji istotnych warunków zamówienia.

4. Instalacja i konfiguracji aplikacji w szczególności implementacja schematów przepływu spraw,

struktury organizacyjnej podmiotu, użytkowników itp.

5. Roczne wsparcie dostawcy w zakresie administracji oraz konfiguracji systemów liczone od dnia

zakończenia wdrożenia.

6. Dokumentacje wdrożeniową która powinna zawierać

dokumentację administratora zawierającą: konfiguracje serwera, (pliki konfiguracyjne, ustawienia

parametrów niezbędnych do prawidłowej pracy systemów), wymaganą konfigurację stacji roboczej

(zainstalowane komponenty, dodatkowe wymagane ustawienia systemu), wskazanie zasobów do

archiwizacji, opis struktury baz danych w zakresie niezbędnym do administracji systemem.

instrukcję użytkownika w formie elektronicznej umożliwiającej wydruk.

Proces odbiorowy SystemuW ramach projektu dostarczane muszą być następujące typy produktów:

1. Produkt typu dokument (np. plan migracji, dokumentacja powykonawcza).2. Produkt typu licencje. 3. Produkt typu szkolenia 4. Produkt typu System

Odbiory poszczególnych produktów/etapów będą przeprowadzone zgodnie z założeniami opisanymi poniżej.Odbiór produktu typu dokument Zamawiający wymaga następującego przebiegu procedury odbiorowej produktu typu dokument.

1. Wykonawca musi przedstawić zamawiającemu produkty typu dokument w postaci edytowalnego pliku w formacie DOC w wersji 1.

2. Zamawiający naniesie swoje uwagi do dokumentu w trybie zmian w postaci dokumentu lub przedstawi je w postaci odrębnego pliku zawierającego listę uwag i przekaże je Wykonawcy w terminie 5 dni roboczych od dnia przekazania dokumentu (dzień przekazania nie jest uwzględniany w czasie Zamawiającego). Na życzenie Wykonawcy może być na tym etapie zorganizowana telekonferencja wyjaśniająca uwagi Zamawiającego.

100


3. Wykonawca w terminie do 5 dni roboczych jest zobowiązany przekazać Zamawiającemu poprawiony dokument w wersji 2.

4. Zamawiający weryfikuje ustosunkowanie się do uwag przez Wykonawcę i ewentualnie przedstawia ponownie swoje uwagi z zastrzeżeniem, że będą się one odnosić do wcześniej zgłoszonych zastrzeżeń lub nowo przedstawionych fragmentów dokumentacji.

5. Jeżeli dokument w wersji 2 nie uwzględnia w wystarczającym stopniu uwag Zamawiającego organizowana jest narada jakości, na której Zamawiający wraz z Wykonawcą szczegółowo omawiają możliwość i sposób realizacji uwag oraz określają termin dostarczenia kompletnego dokumentu.

6. Po dostarczeniu dokumentu w wersji 3 Zamawiający podejmuje decyzje o jego odbiorze lub odrzuceniu.

7. Odbiór produktu typu dokument potwierdza się protokołem odbioru podpisanym przez obie strony.

8. Zamawiający zastrzega sobie prawo odbioru warunkowego dokumentu, w którym stwierdzono wady ale nie są one na tyle istotne by wstrzymywać przebieg prac wdrożeniowych. W takim przypadku w protokole odbioru produktu zawierane są klauzule wskazujące listę wad do usunięcia wraz ze wskazaniem terminu dostarczenia produktu bez wad.

9. Zamawiający zastrzega sobie prawo nie wnoszenia uwag do dokumentu i jego odrzucenia w przedstawionej formie jeżeli jakość dokumentu będzie rażąco niska. Poprzez rażąco niską jakość Zamawiający rozumie brak wszystkich elementów wymaganych w SIWZ lub wymaganych na podstawie uzgodnień projektowych lub bardzo niskiej jakości opis tych elementów np. jedno lub kilku zdaniowy bardzo ogólny opis.

Odbiór produktu typu migracja systemu Proces odbioru produktu migracja systemu musi przebiegać następująco:

1. Wykonawca po przeprowadzaniu procesu migracji testowej systemu na wydajną bazę danych przedstawia raport z migracji wg szablonu uzgodnionego na etapie analizy przedwdrożeniowej oraz zgłasza gotowość systemu do testów funkcjonalnych. Raport z migracji musi dokumentować poprawność przeprowadzenia procesu migracji testowej w szczególności kompletność przeniesionych danych.

2. Testy funkcjonalne wykonywane są na podstawie dokumentacji testowej zatwierdzonej na etapie analizy przedwdrożeniowej z zastrzeżeniem, że dokumentacja ta będzie uwzględniała pełny przebieg kluczowych dla Zamawiającego procesów biznesowych. Jako pełny przebieg rozumie się testowanie zarówno ścieżek pozytywnych jak i negatywnych dla procesów.

3. Testy funkcjonalne wykonywane są na dokumentacji testowej opracowanej w ramach etapu I

4. Za realizację testów odpowiada Wykonawca przy współudziale Zamawiającego. Zamawiający zastrzega sobie prawo samodzielnej realizacji testów przy lub bez obecności Wykonawcy. W przypadku realizacji testów bez obecności wykonawcy, Zamawiający zobowiązuje się do opisu wykrytych błędów w sposób umożliwiający odtworzenie błędu Wykonawcy (opis powtarzalnej ścieżki dojścia do błędu wraz z zestawem danych testowych). Informacje takie muszą być przekazane w dokumencie będącym protokołem z sesji odbytych testów systemu przez Zamawiającego.

5. Jeżeli w procesie testowania uwidocznione zostaną błędy uniemożliwiające odbiór systemu w ramach raportu z testów są one uwidaczniane w tym raporcie wraz z ustaleniem terminu przeprowadzanie II tury testów. Kryteria odbiorowe dla poszczególnych rodzajów testów określone są w rozdziale „Testy”

6. Wykonawca w uzgodnionym terminie przedstawia system do II tury testów. W ramach II tury testów weryfikowane są scenariusze dla których stwierdzono występowanie błędów w ramach I tury. Zamawiający zastrzega sobie prawo wykonania testów regresji dla scenariuszy testowych, które przebiegły poprawnie w II turze.

7. Każda tura testów kończy się raportem z testów przedstawionym Zamawiającemu.

8. W przypadku spełniania warunków odbioru testów funkcjonalnych migracji systemu Zamawiający i Wykonawca podpisują protokół odbioru testów funkcjonalnych migracji.

9. W przypadku pozytywnej weryfikacji raportu z migracji i testów funkcjonalnych migracji Zamawiający podejmuje decyzję o realizacji migracji produkcyjnej.

101


10. Po przeprowadzaniu uruchomienia produkcyjnego systemu po migracji w terminie nie wcześniej niż po 5 dniach, Wykonawca przedstawi raport z migracji produkcyjnej systemu wg szablonu uzgodnionego na etapie analizy przedwdrożeniowej. Raport musi zawierać raporty z wydajności systemu sprzed i po migracji systemu. Raporty te muszą umożliwiać porównanie:

- Czasu zapisu do bazy danych systemu dla tych samych lub porównywalnych danych,

- Czasu odpowiedzi bazy danych na zapytania systemu dla tych samych lub porównywalnych zapytań.

11. Na podstawie raportu z migracji produkcyjnej systemu Zamawiający dokonuje odbioru migracji systemu poprzez podpisanie protokołu odbioru.

12. Odbiór migracji systemu musi zostać potwierdzony protokołem odbioru podpisanym przez obie strony.

13. Zamawiający zastrzega sobie prawo odbioru warunkowego migracji systemu, w którym stwierdzono wady ale nie są one na tyle istotne by wstrzymywać przebieg prac wdrożeniowych. W takim przypadku w protokole odbioru migracji muszą zostać zawarte klauzule wskazujące listę wad do usunięcia wraz ze wskazaniem terminu dostarczenia produktu bez wad.

Odbiór produktu typu szkolenia Produkt szkolenia musi być odbierany każdorazowo i przekazany do akceptacji Zamawiającego wraz z

listą obecności uczestników szkolenia. Pracownicy Zamawiającego mają obowiązek podpisania listy obecności na szkoleniu. Wykonawca odpowiada za zorganizowanie sprzętu niezbędnego do przeprowadzenia szkolenia. Zamawiający udostępni Wykonawcy salę szkoleniową z dostępem do sieci internet. Wykonawca zobowiązany jest zapewnić każdemu uczestnikowi komplet materiałów szkoleniowych minimum w formie plików na nośniku elektronicznym lub wskazania lokalizacji z której można takie pliki pobrać samodzielnie. Na podstawie materiałów szkoleniowych i listy obecności podpisywany jest przez strony protokół odbioru szkolenia.

Odbiór produktów typu licencje Odbiór produktów typu licencje musi nastąpić na podstawie protokołu przekazania licencji po wcześniejszym sprawdzeniu kompletności dostawy.

Odbiór etapu / umowy Dla każdego z etapów Wdrożenia określona jest lista produktów dostarczanych w ramach etapów. Odbiór etapu może nastąpić jedynie jeżeli odebrane są wszystkie produktu dla danego etapu minimum na poziomie odbioru warunkowego z zastrzeżeniem, że w momencie odbioru Etapu II wszystkie produkty poprzedniego etapu powinny uzyskać status odbioru bezwarunkowego.

Testy

Odbiór produktu typu Systemu będzie się odbywał poprzez przeprowadzenie testów oprogramowania. Również proces migracji systemu będzie odbierany w ramach poniżej opisanego procesu testowego.

W ramach realizacji przedmiotu umowy Wykonawca zobowiązany jest przeprowadzić zestaw testów potwierdzających poprawność działania dostarczanych modułów. W skład testów wchodzą minimum następujące testy:

1. Testy funkcjonalne – zestaw testów potwierdzających możliwość realizacji kluczowych procesów dla dostarczanych modułów zidentyfikowanych i opisanych w ramach analizy przedwdrożeniowej.

2. Testy wydajnościowe – testy mające na celu potwierdzenie, że założone wskaźniki wydajności systemu zostały osiągnięte.

3. Testy integracji – testy potwierdzające zdolność modułów do współpracy z innymi systemami dla których konieczność integracji została opisana w OPZ.

Dokumentacja testowa 1. Dokumentacja testowa musi zostać opracowana przez Wykonawcę na etapie analiz przedwdrożeniowej.

Dokumentacja testowe musi obejmować następujące rodzaje dokumentów:

1) plan testów,

102


2) scenariusz testowe,

3) przypadki testowe,

4) dane do testów.

2. Plan i scenariusze muszą być zgodne z powszechnie stosowanymi zasadami i praktykami. Plan testów musi określać w szczególności:

1) ogólne zasady przeprowadzania testów,

2) opis środowiska testowego,

3) kolejność wykonywania scenariuszy testowych,

4) klasyfikację wykrytych problemów testowych,

5) kryteria sukcesu dla poszczególnych kategorii testów.

3. Scenariusze muszą zapewniać pokrycie wszystkich procesów kluczowych dla działalności Zamawiającego w zakresie dostarczanych modułów. Każdy scenariusz musi określać:

1) dane, które muszą być wprowadzone do systemu przed uruchomieniem scenariusza,

2) kolejność czynności, wykonywanych w czasie testu oraz dane, wprowadzane do systemu w czasie testu,

3) oczekiwaną reakcję systemu na wykonane czynności i wprowadzone dane.

4. Przypadki testowe i dane testowe w tym wszelkie materiały eksploatacyjne dostarczone muszą być przez Wykonawcę. Zamawiający zobowiązany jest do współpracy z Wykonawcą przy przygotowywaniu scenariuszy testowych i danych testowych, przeprowadzaniu testów oraz przygotowaniu wyników testów.

5. Zamawiający dopuszcza przeprowadzenie testów automatycznych, o ile w planie testów zostanie wyspecyfikowany zakres tych testów i uzyska on akceptację Zamawiającego.

6. Testy muszą zostać przeprowadzone w terminie przewidzianym w harmonogramie, zgodnie z zaakceptowanym planem testów.

7. Testy muszą zostać wykonane z użyciem środowiska testowego chyba, że plan testów będzie przewidywał inaczej, na bazie reprezentatywnej próbki danych eksploatacyjnych. Zakres testów nie może wykraczać poza merytoryczny zakres projektu. Test może zostać przerwany, jeżeli z jakiejkolwiek przyczyny nie może być kontynuowany (np. poważny błąd w oprogramowaniu lub awaria systemu). Test taki powinien zostać powtórzony lub kontynuowany w innym terminie po obustronnym uzgodnieniu.

8. W ramach procesu testowania mogą wystąpić następujące kategorię błędów

Poziom istotności OpisA/Krytyczny Zatrzymanie działania Produktu lub błąd uniemożliwiający realizację kluczowego procesu

w tym także obniżenie wydajności, które w praktyce uniemożliwia jego realizację i nie jest możliwe wskazanie obejścia błędu.

B /Wysoki Zatrzymanie działania Produktu lub realizację kluczowego procesu w tym także obniżenie wydajności, które w praktyce uniemożliwia jego realizację ale jest możliwe wskazanie obejścia błędu. Obejście umożliwia weryfikację funkcjonalności występujących „za” błędem.

C /Średni Zakłócenie pracy Produktu wpływające na weryfikację poprawności przebiegu kluczowego procesu.

D/Niski Zakłócenie pracy Produktu niewpływające na weryfikację poprawności przebiegu kluczowego procesu12, w tym błędy kosmetyczne interfejsu.

Kryteria akceptacji dla scenariuszy i przypadków testowych1. Wynik testu dla Scenariusza Testowego będzie uznany za pozytywny, gdy wyniki testów dla wszystkich

Przypadków Testowych zawartych w Scenariuszu Testowym są pozytywne. Wynik testu dla Scenariusza Testowego uzna się za negatywny, gdy wynik testu dla któregokolwiek Przypadku Testowego zawartego w Scenariuszu testowym jest negatywny.

103


2. Wynik testu dla Przypadku Testowego uzna się za pozytywny, gdy opis oczekiwanego rezultatu zamieszczony w polu „Oczekiwany wynik" jest ‘zgodny’ z faktycznie uzyskanym wynikiem po zakończeniu Przypadku Testowego.

3. Wynik testu dla Przypadku Testowego uzna się za negatywny, gdy opis oczekiwanego rezultatu zamieszczony w polu „Oczekiwany wynik" jest ‘nie zgodny’ z faktycznie uzyskanym wynikiem po zakończeniu Przypadku Testowego. W przypadku, gdy występująca niezgodność jest wynikiem błędnie opisanego Przypadku Testowego, wówczas wynik testu może być uznany za prawidłowy, a błędny opis Przypadku Testowego musi zostać poprawiony przez Wykonawcę. Sytuacja taka musi znaleźć odzwierciedlenie w raporcie z Testów Akceptacyjnych.

Kryteria zakończenia testów sukcesem1. Testy muszą być wykonane na podstawie Scenariuszy Testowych zaakceptowanych przez Zamawiającego.

2. Testy Zamawiający uzna za zakończone z sukcesem, gdy:

1) zostaną przeprowadzone testy z wykorzystaniem zaplanowanych Scenariuszy Testowych,

2) brak będzie niezakończonych Scenariuszy Testowych z powodu wystąpienia Incydentu/ów z klasą istotności B/Wysoki, C/Średni i D/Niski, których liczba wykracza poza dopuszczalny limit,

3) na moment zakończenia Testów Akceptacyjnych musi być brak Incydentów z klasą istotności A/Krytyczny,

3. W przypadku wystąpienia Incydentu, który uniemożliwia wykonanie wszystkich zaplanowanych przypadków Testowych i/lub Scenariuszy Testowych, a który nie wynika z winy Wykonawcy, wówczas Zamawiający dopuszcza aby zakres testów został zmieniony (wyłączenie przypadków i/lub scenariuszy) na podstawie decyzji podjętej przez Zamawiającego.

4. W przypadku Scenariuszy Testowych zakończonych negatywnie, w których wystąpiły Incydenty o klasie istotności B/Wysoki, C/Średni lub D/Niski, wynik ich zakończenia może zostać uznany za pozytywny na podstawie decyzji podjętej przez Kierownika Projektu ze strony Zamawiającego.

5. Testy uznaje się za zakończone z wynikiem negatywnym, gdy po ich zrealizowaniu otrzymano następujące wyniki:

1) istnieje przynajmniej jeden niezakończony Scenariusz Testowy z powodu wystąpienia Incydentu/ów z klasą istotności A/Krytyczny,

2) istnieją niezakończone Scenariusze Testowe z powodu wystąpienia Incydentu/ów z klasą istotności B/Wysoki i C/Średni, których liczba wykracza poza dopuszczalny limit, w takim przypadku Scenariusze te nie mogą zostać uznane za zakończone pozytywnie.

6. W przypadku zakończenia Testów z wynikiem negatywnym, musi zostać ustalony plan powtórzenia testów. Wybór scenariuszy do II tury testów musi zostać przeprowadzony według następujących zasad:

1) Scenariusze Testowe, które otrzymały wynik negatywny z powodu wystąpienie Incydentu/ów.

2) Scenariusze Testowe dla funkcjonalności powiązanych z funkcjonalnością Scenariusza Testowego, w którym wystąpiły Incydenty.

7. Zamawiający zastrzega sobie prawo przeprowadzenia testów regresji dla scenariuszy z wynikiem pozytywnym.

Kryteria akceptacji testów funkcjonalnych Dopuszczalna liczba otwartych Incydentów na zakończenie Testów Funkcjonalnych

Kategoria błędu Dopuszczalna liczba przypadków testowych z błędemA/Krytyczny 0B/Wysoki 0C/Średni 2D/Niski 10

104


Kryteria akceptacji testów wydajnościowych Minimalny średni czas reakcji Systemu wynosi 1 sekunda.

Kryteria akceptacji testów integracji Raport testów musi wykazywać, że dostarczone oprogramowanie współpracuje z systemem HIS użytkowanym przez Zamawiającego w zakresie wymaganym przez OPZ. W szczególności generowane pliki wymiany (pliki XML, dokumenty HL7, widoki na bazie danych) posiadają prawidłową (zgodną z wymaganiami) strukturę i zawartość W zakresie testów procesu migracji Raport testów musi wykazywać, że generowane z nowej wersji systemu pliki wymiany (pliki XML, dokumenty HL7, widoki na bazie danych) posiadają identyczną strukturę i zawartość dla takiego samego zakresu danych jak w dotychczas używanym systemie HIS

Wymagania dla sprzętu komputerowego Dla każdego z niżej wymienionych rodzajów sprzętu Zamawiający określił minimalne wymagania, które dostarczany sprzęt powinien spełniać. Zamawiający dopuszcza również dostarczenie rozwiązań równoważnych dla wyspecyfikowanego sprzętu.

Macierz dyskowa Liczba szt. – 1

Kategoria Opis wymagania Ogólne System musi być dostarczony ze wszystkimi komponentami do instalacji w

standardowej szafie rack 19” (42U pojemności użytecznej do instalacji urządzeń w pozycji poziomej, wyposażonej w przednie drzwi perforowane, zamykane na zamek z kluczem, jednoskrzydłowe, z możliwością montażu lewa/prawa strona,) z zajętością maks. 6U w tej szafie. Każdy skonfigurowany moduł/obudowa musi posiadać układ nadmiarowy zasilania i chłodzenia, zapewniający bezprzerwową pracę macierzy bez ograniczeń czasowych w przypadku utraty redundancji w danym układzie (zasilania lub chłodzenia). Każdy moduł/obudowa powinien posiadać widoczne elementy sygnalizacyjne do informowania o stanie poprawnej pracy lub awarii. Rozbudowa o dodatkowe moduły dla obsługiwanych dysków powinna odbywać się wyłącznie poprzez zakup takich modułów, bez konieczności zakupu dodatkowych licencji lub specjalnego oprogramowania aktywującego proces rozbudowy lub musi być dostarczona licencja na dwukrotność dostarczanej pojemności. Dostarczana macierz musi umożliwiać takie podłączenie półek aby awaria lub/i usunięcie jednej z półek nie powodowało utraty dostępu do danych znajdujących się na pozostałych modułach. Oferowana macierz musi obsługiwać min. 260 dysków wykonanych w technologii hot-plug. Wszystkie zainstalowane dyski hot-plug, z wyłączeniem dysków SSD stosowanych jako rozszerzenie pamięci Cache kontrolerów, muszą być dostępne dla

105


zapisu danych Użytkownika. Macierz musi umożliwiać rozbudowę i jednoczesne podłączenie i używanie modułów (tzw. „półek dyskowych”) pozwalająca umieścić do 24 dysków 2,5” typu hotplug dla dysków NL-SAS SAS i SSD oraz dla 12 dysków 3,5” typu hotplug SAS, NL-SAS,SSD oraz dla 60 dysków typu hotplug SAS, NL-SAS,SSD; Wymaga się aby macierz umożliwiała jednoczesne podłączenie i użycie dowolnego rodzaju i kombinacji wyżej wymienionych półek dyskowych

Pojemność Pojemność dostarczonej macierzy:5,3 TB powierzchni użytecznej na dyskach SAS 10 000 obr./min. (RAID5 + HotSpare)10,6 TB powierzchni użytecznej na dyskach NL-SAS (RAID5 + HotSpare)40 TB powierzchni użytecznej na dyskach NL-SAS

Kontrolery Kontrolery macierzy muszą obsługiwać tryb pracy w układzie active-active lub mesh-active, macierz musi być dostarczona z zainstalowanymi minimum 2 kontrolerami;

Każdy z kontrolerów macierzy musi posiadać po minimum 16 GB pamięci podręcznej Cache – kontrolery muszą obsługiwać między sobą mechanizm lustrzanej kopii danych (cache mirror) przeznaczonych do zapisu; możliwość rozbudowy do 32GB na kontroler

Macierz musi obsługiwać rozbudowę pamięci podręcznej cache dla operacji odczytu o minimum 800GB poprzez instalację dodatkowych modułów pamięci w kontrolerach lub wykorzystanie pojemności zainstalowanych dysków SSD,

W przypadku awarii zasilania dane nie zapisane na dyski, przechowywane w pamięci podręcznej Cache dla zapisów muszą być zabezpieczone metodą trwałego zapisu na dysk.

Kontrolery muszą posiadać możliwość ich wymiany bez konieczności wyłączania zasilania całego urządzenia;

Kontrolery macierzy obsługują funkcjonalność deduplikacji w trybie in-line oraz kompresji danych. – nie jest wymagane dostarczenie tej funkcjonalności – opcja rozbudowy

Macierz musi obsługiwać wymianę kontrolera RAID bez utraty danych zapisanych na dyskach.

Każdy z kontrolerów RAID powinien posiadać dedykowany minimum 1 interfejs RJ-45 Ethernet obsługujący połączenia z prędkością minimum 1Gb/s dla zdalnej komunikacji z oprogramowaniem zarządzającym i konfiguracyjnym macierzy.

Kontrolery macierzy muszą być oparte o procesor wykonany w technologii wielordzeniowej z minimum 4 rdzeniami,

Kontrolery macierzy muszą obsługiwać do 130 grup dyskowych w całym rozwiązaniu, bez konieczności wymiany dostarczonych kontrolerów

Oferowana macierz musi mieć wyprowadzone 4 porty FC 16Gb/s do dołączenia serwerów bezpośrednio lub do dołączenia do sieci SAN, na każdy kontroler RAID.

Macierz musi umożliwiać wymianę portów do transmisji danych obsługujących protokoły: iSCSI 10Gb/s, SAS 12GB/s

Wymiana portów jw. nie może powodować wymiany samych kontrolerów RAID w oferowanym rozwiązaniu a w przypadku konieczność licencjonowania tej funkcjonalności macierz ma być dostarczona z aktywną licencja na instalację i obsługę każdego z wymienionych protokołów transmisji danych

Macierz posiada obsługę operacji plikowych I/O w sieci NAS w obrębie zainstalowanych kontrolerów. Protokoły dostępu: CIFS, NFS. W przypadku obsługi protokołów CIFS i NFS wymagana jest funkcjonalność agregacji przepustowości dla interfejsów dedykowanych do obsługi tych protokołów. Obsługa protokołów CIFS i NFS musi odbywać się jednocześnie . – nie jest wymagane dostarczenie tej funkcjonalności – opcja rozbudowy

Poziomy RAID Macierz musi zapewniać poziom zabezpieczenia danych na dyskach definiowany poziomami RAID:

o Raid-0o Raid-1o Raid-10o Raid-5

106


o Raid-50o Raid-6

Dyski Oferowana macierz musi wspierać dyski hot-plug:o dyski elektroniczne SSD i mechaniczne HDD z interfejsami

SAS12Gb/so dyski mechaniczne HDD o prędkości obrotowej 7,2 krpm, 10 krpm

oraz 15k rpm, Macierz musi obsługiwać mieszaną konfigurację dysków hot-plug SSD i HDD

w rozmiarach 2,5” i 3,5” zainstalowanych w dowolnym module rozwiązania; Wszystkie dyski wspierane przez oferowany model macierzy muszą być

wykonane w technologii hot-plug i posiadać podwójne porty SAS obsługujące tryb pracy full-duplex

Macierz musi obsługiwać min. 60 dysków SAS SSD w całym rozwiązaniu, Macierz musi umożliwiać skonfigurowanie każdego zainstalowanego dysku

hot-plug jako dysk hot-spare (dysk zapasowy)o Macierz posiada możliwość konfiguracji dysku hot-spare dla

zabezpieczenia dowolnej grupy dyskowej RAIDo Macierz posiada możliwość konfiguracji dysku hot-spare

dedykowanego dla zabezpieczenia tylko wybranej grupy dyskowej RAID

W przypadku awarii dysku fizycznego i wykorzystania wcześniej skonfigurowanego dysku zapasowego wymiana uszkodzonego dysku na sprawny nie może powodować powrotnego kopiowania danych z dysku hot-spare na wymieniony dysk (tzw. CopyBackLess).

Macierz musi pozwalać na zaszyfrowanie danych zapisanych na dostarczonych dyskach SSD SAS i HDD SAS/NL-SAS minimum kluczem AES256-bit – jeżeli w tym celu niezbędne jest zakupienie dodatkowych licencji bądź komponentów sprzętowych to należy je dostarczyć wraz z macierzą

Opcje programowe Macierz musi być wyposażona w system kopii migawkowych umożliwiających wykonanie minimum 2048 kopii migawkowych

Macierz musi umożliwiać zdefiniowanie min. 6000 woluminów (LUN) Macierz powinna umożliwiać podłączenie logiczne z serwerami i stacjami

poprzez min. 1024 ścieżek logicznych FC Macierz musi umożliwiać aktualizację oprogramowania wewnętrznego

kontrolerów RAID i dysków bez konieczności wyłączania macierzy oraz bez konieczności wyłączania ścieżek logicznych FC/iSCSI dla podłączonych stacji/serwerów

Macierz musi umożliwiać dokonywanie w trybie on-line (tj. bez wyłączania zasilania i bez przerywania przetwarzania danych w macierzy) operacje: powiększanie grup dyskowych, zwiększanie rozmiaru woluminu, migrowanie woluminu na inną grupę dyskową

Macierz musi posiadać wsparcie dla systemów operacyjnych : Microsoft Windows Server 2012R2, 2016, SuSE Linux Enterprise Server, Red Hat Linux Enterprise Server, HP-UNIX, IBM AIX, Oracle Solaris, Vmware Vsphere;

Macierz musi być dostarczona z licencją na oprogramowanie wspierające technologię typu multipath (obsługa nadmiarowości dla ścieżek transmisji danych pomiędzy macierzą i serwerem) dla połączeń FC i iSCSI.

Macierz musi posiadać możliwość uruchamiania mechanizmów zdalnej replikacji danych, w trybie synchronicznym i asynchronicznym, po protokołach FC oraz iSCSI, bez konieczności stosowania zewnętrznych urządzeń konwersji wymienionych protokołów transmisji. Funkcjonalność replikacji danych musi być zapewniona z poziomu oprogramowania wewnętrznego macierzy, jako tzw. storage-based data replication. Replikacja danych musi być obsługiwana w połączeniu z każdą macierzą z tej samej rodziny urządzeń wspierającą obsługę zdalnej replikacji danych. – nie jest wymagane dostarczenie tej funkcjonalności – opcja rozbudowy

Macierz musi posiadać możliwość tworzenia lokalnych tj. w obrębie zasobów macierzy, pełnych kopii danych (tzw. klony danych), kopii przyrostowych oraz kopii lustrzanych (mirror) – nie jest wymagane dostarczenie tej funkcjonalności – opcja rozbudowy

Macierz musi obsługiwać mechanizm ochrony priorytetów obsługi wybranych zasobów – za taki mechanizm uznaje się funkcję typu ‘cache

107


partitioning’ lub ‘storage partitioning’. Macierz musi obsługiwać adresację IP v.4 i IP v.6 Wraz z macierzą należy dostarczyć oprogramowanie lub moduły

programowe typu plug-in pozwalające na integracje macierzy w środowiskach Vmware w zakresie obsługi mechanizmów: Vmware VAAI, Vmware VVOL, Vmware MultiPath IO – z subskrypcją do bezpłatnej aktualizacji w całym okresie obowiązywania gwarancji

Macierz musi obsługiwać mechanizmy Thin Provisioning, czyli przydziału dla obsługiwanych środowisk woluminów logicznych o sumarycznej pojemności większej od sumy pojemności dysków fizycznych zainstalowanych w macierzy.

Macierz musi obsługiwać mechanizmy typu AST (Automated Storage Tiering) tj. automatycznego migrowania i realokacji bloków danych pomiędzy różnymi technologiami dyskowymi na podstawie analizy częstotliwości operacji I/O dla tych bloków oraz wg potrzeb wydajnościowych serwerów, środowisk i aplikacji korzystających z zasobów macierzy. Mechanizm AST musi być obsługiwany przy korzystaniu zarówno z trzech jak z dwóch dostarczonych technologii dyskowych: SSD, SSAS, NLSAS. Macierz musi pozwalać na definiowanie różnych polityk i zasad migrowania danych w obrębie tej samej macierzy. Mechanizm AST musi być wyposażony w funkcję Quality-of-Services pozwalająca na zagwarantowaniu wydajności dla wybranych zasobów macierzy (woluminów) mierzonej jako maksymalny czas opóźnień operacji I/O wykonywanych przez serwer/środowisko/aplikację. Mechanizm AST musi pozwalać na definiowanie okna czasowego dla zbierania pomiarów wydajności operacji I/O oraz okna czasowego dla migrowania danych wg ustalonych zasad i polityk – minimalny definiowany czas trwania w/w operacji (długość okna czasowego) nie może być dłuższy niż 4 godziny. Mechanizm AST musi pozwalać na wykluczanie wybranych godzin i dni z pomiarów wydajności operacji I/O. – nie jest wymagane dostarczenie tej funkcjonalności – opcja rozbudowy

Macierz musi wspierać usługi VSS (Volume ShadowCopy Services) w systemach klasy Microsoft Windows Sever – wymagane jest dostarczenie niezbędnego oprogramowania / sterowników VSS pozwalających na obsługę VSS przy maksymalnej pojemności i liczbie dysków obsługiwanych przez oferowaną. W czasie trwania gwarancji wymaga się bezpłatnego dostępu do nowych wersji oprogramowania i sterowników

Macierz musi obsługiwać mechanizmy migracji danych w trybie online z innej macierzy tej klasy, z zachowaniem obsługi operacji I/O dla serwerów podłączonych do migrowanej macierzy tj. do migrowanych zasobów LUN

Macierz wspiera rozwiązania klasy ‘klastra macierzowego’ tj. zapewnienia wysokiej dostępności zasobów dyskowych macierzy dla podłączonych platform software’owych i sprzętowych z wykorzystaniem synchronicznej replikacji danych pomiędzy minimum 2 macierzami protokołami FC oraz iSCSI. Mechanizm klastra macierzowego musi być obsługiwany dla protokołów FC oraz iSCSI, zarówno w zakresie replikacji danych jak i w zakresie sposobu podłączenia serwerów do zasobów macierzy. Pod użytym pojęciem ‘wysoka dostępność zasobów dyskowych’ należy rozumieć zapewnienie bezprzerwowego działania środowiska (aplikacja/ system operacyjny/ serwer) podłączonego do macierzy (macierz podstawowa) w przypadku wystąpienia awarii logicznego połączenia z tą macierzy bądź awarii samej macierzą, powodujących dla danego środowiska brak dostępu do zasobów macierzy podstawowej. Funkcjonalność ‘klastra macierzowego’ musi pozwalać na automatyczne i ręczne przełączanie obsługi środowisk produkcyjnych z macierzy podstawowej na zapasową w przypadku awarii macierzy podstawowej (tzw. Automated/manual failover). – nie jest wymagane dostarczenie tej funkcjonalności – opcja rozbudowy

Zarządzanie Oprogramowanie do zarządzania musi być zintegrowane z systemem operacyjnym systemu pamięci masowej

Komunikacja z wbudowanym oprogramowaniem zarządzającym macierzą musi być możliwa w trybie graficznym np. poprzez przeglądarkę WWW oraz w trybie tekstowym.

108


Musi być możliwe zdalne zarządzanie macierzą z wykorzystaniem standardowej przeglądarki internetowej (np. Internet Explorer, Google Chrome, Mozilla Firefox) bez konieczności instalacji żadnych dodatkowych aplikacji na stacji administratora

Wbudowane oprogramowanie macierzy musi obsługiwać połączenia z modułem zarządzania macierzy poprzez szyfrowanie komunikacji protokołami: SSL dla komunikacji poprzez przeglądarkę WWW i protokołem SSH dla komunikacji poprzez CLI

Gwarancja i serwis Całe rozwiązanie musi być objęte 36 miesięcznym okresem gwarancji z naprawą miejscu instalacji urządzenia i z gwarantowanym czasem skutecznego zakończenia naprawy najpóźniej w ciągu następnego dnia roboczego od dnia zgłoszenia awarii do organizacji serwisowej producenta macierzy.

Dyski twarde nie podlegają zwrotowi organizacji serwisowej; Serwis gwarancyjny musi obejmować dostęp do poprawek i nowych wersji

oprogramowania wbudowanego, które są elementem zamówienia. Po zakończeniu okresu gwarancji musi być zapewniony przez producenta

rozwiązania bezpłatny dostęp do aktualizacji oprogramowania wewnętrznego oferowanej macierzy oraz do kolejnych wersji oprogramowania zarządzającego w okresie minimum 2 lat.

System musi zapewniać możliwość samodzielnego i automatycznego powiadamiania producenta i administratorów Zamawiającego o usterkach za pomocą wiadomości wysyłanych poprzez szyfrowany protokół.

Macierz musi pochodzić z oficjalnego kanału sprzedaży producenta w UE. Nie dopuszcza się użycia macierzy odnawianych, demonstracyjnych lub powystawowych

Urządzenie musi być wykonane zgodnie z europejskimi dyrektywami RoHS i WEEE stanowiącymi o unikaniu i ograniczaniu stosowania substancji szkodliwych dla zdrowia

Możliwość odpłatnego wydłużenia gwarancji producenta do 7 lat w trybie onsite z gwarantowanym skutecznym zakończeniem naprawy serwera najpóźniej w następnym dniu roboczym od zgłoszenia usterki (podać koszt na dzień składania oferty);

Serwer Typu 1 Liczba – 4 szt,.

Kategoria Opis wymagania

Obudowa Typu RACK, wysokość nie więcej niż 2U; Szyny umożliwiające wysunięcie serwera z szafy stelażowej; Ramię porządkujące ułożenie przewodów z tyłu serwera;

Płyta główna Dwuprocesorowa; Wyprodukowana i zaprojektowana przez producenta serwera Możliwość instalacji procesorów 28-rdzeniowych; Możliwość zainstalowania moduł TPM 2.0 6 złącz PCI Express generacji 3w tym:

o 3 fizyczne złącza o prędkości x16;o 3 fizyczne złącza o prędkości x8;o Możliwość rozbudowy do 8 aktywnych złącz PCIe

24 gniazda pamięci RAM; Obsługa minimum 3TB pamięci RAM; Wsparcie dla technologii:

o Memory Scrubbing lub równoważnej: data scrubbing, data cleansingo SDDCo Advanced ECCo Rank Sparing lub równoważnej;

Obsługa pamięci nieulotnej instalowanej w gniazdach pamięci RAM o pojemności

109


sumarycznej minimum 1TB (przez pamięć nieulotną rozumie się moduły pamięci zachowujące swój stan np. w przypadku nagłej awarii zasilania, nie dopuszcza się podtrzymania bateryjnego stanu pamięci)

Minimum 2 sloty dla dysków M.2 na płycie głównej (lub dedykowanej karcie PCI Express) nie zajmujące klatek dla dysków hot-plug;

Procesory Jeden procesor 10-rdzeniowy architektura x86 Taktowanie bazowe 2,2GHz 13MB pamięci cache

lub równoważny osiągający wynik Average CPU Mark 11500 pkt (dla pojedynczego procesora). Wynik musi być dostępny na stronie https://www.cpubenchmark.net

Pamięć RAM 128 GB pamięci RAM DDR4 Registered 2933Mhz

Dyski twarde i napędy Minimum 4 wnęki dla dysków twardych Hotplug 3,5”;

Kontrolery LAN Trwale zintegrowana karta LAN, nie zajmująca żadnego z dostępnych slotów PCI Express, wyposażona minimum w interfejsy: 2x 1Gbit Base-T ze wsparciem iSCSI oraz PXE boot;

Karta LAN 4x 1Gbit Base-T; możliwość wymiany zainstalowanych interfejsów LAN na interfejsy 4x 10Gbit SFP

Kontrolery I/O Możliwość zainstalowania kontrolera RAID obsługującego dyski NVMe Zainstalowane dwa nośniki flash o pojemności 64GB w konfiguracji RAID-1

rozwiązanie dedykowane dla hypervisora oraz niezajmujące zatok dla dysków hot-plug

Zainstalowana karta FC 16Gb/s dwuportowaPorty Zintegrowana karta graficzna ze złączami VGA z tyłu oraz z przodu serwera;

1 port USB 3.0 na panelu przednim; 1 port USB wewnętrzny; 2 porty USB 3.0 dostępne z tyłu serwera; Możliwość instalacji jednego portu serial, możliwość wykorzystania portu do

zarządzania serwerem; Ilość dostępnych złącz USB nie może być osiągnięta poprzez stosowanie

zewnętrznych przejściówek, rozgałęziaczy czy dodatkowych kart rozszerzeń zajmujących jakikolwiek slot PCI Express i/lub USB serwera;

Zasilanie, chłodzenie Redundantne zasilacze hotplug o sprawności 94% (tzw. klasa Platinum) o mocy minimalnej 800W;

Redundantne wentylatory hotplug; Zarządzanie Niezależny od systemu operacyjnego, sprzętowy kontroler umożliwiający pełne

zarządzanie, zdalny restart serwera;o Dedykowana karta LAN 1 Gb/s, dedykowane złącze RJ-45 do komunikacji

wyłącznie z kontrolerem zdalnego zarządzania z możliwością przeniesienia tej komunikacji na inną kartę sieciową współdzieloną z systemem operacyjnym;

o Dostęp poprzez przeglądarkę Web, SSH;o Zarządzanie mocą i jej zużyciem oraz monitoring zużycia energii;o Zarządzanie alarmami (zdarzenia poprzez SNMP)o Możliwość przejęcia konsoli tekstowejo Możliwość zarządzania przez 6 administratorów jednocześnieo Przekierowanie konsoli graficznej na poziomie sprzętowym oraz możliwość

montowania zdalnych napędów i ich obrazów na poziomie sprzętowym (cyfrowy KVM)

o Obsługa serwerów proxy (autentykacja)o Obsługa VLANo Możliwość konfiguracji parametru Max. Transmission Unit (MTU)o Wsparcie dla protokołu SSDPo Obsługa protokołów TLS 1.0, TLS 1.1, TLS 1.2, SSL v3o Obsługa protokołu LDAPo Integracja z HP SIMo Synchronizacja czasu poprzez protokół NTPo Możliwość backupu i odtworzenia ustawień bios serwera oraz ustawień

karty zarządzającej

110


Oprogramowanie zarządzające i diagnostyczne umożliwiające konfigurację kontrolera RAID, instalację systemów operacyjnych, zdalne zarządzanie, diagnostykę i przewidywanie awarii w oparciu o informacje dostarczane w ramach zintegrowanego w serwerze systemu umożliwiającego monitoring systemu i środowiska (m.in. temperatura, dyski, zasilacze, płyta główna, procesory, pamięć operacyjna);

Dedykowana, wbudowana w kartę zarządzającą (lub zainstalowana) pamięć flash o pojemności minimum 16 GB;

Możliwość zdalnej reinstalacji systemu lub aplikacji z obrazów zainstalowanych w obrębie dedykowanej pamięci flash bez użytkowania zewnętrznych nośników lub kopiowania danych poprzez sieć LAN;

Serwer posiada możliwość konfiguracji i wykonania aktualizacji BIOS, Firmware, sterowników serwera bezpośrednio z GUI (graficzny interfejs) karty zarządzającej serwera bez pośrednictwa innych nośników zewnętrznych i wewnętrznych poza obrębem karty zarządzającej.

Wspierane OS Microsoft Windows Server 2019, 2016 VMWare vSphere 6.7, 6.5 Suse Linux Enterprise Server 12 Red Hat Enterprise Linux 7

Gwarancja i serwis Zgłaszanie usterek i awarii sprzętowych poprzez automatyczne założenie zgłoszenia w systemie helpdesk/servicedesk producenta sprzętu;

Firma serwisująca musi posiadać ISO 9001:2000 na świadczenie usług serwisowych; Bezpłatna dostępność poprawek i aktualizacji BIOS/Firmware/sterowników

dożywotnio dla oferowanego serwera – jeżeli funkcjonalność ta wymaga dodatkowego serwisu lub licencji producenta serwera, takowy element musi być uwzględniona w ofercie;

Możliwość odpłatnego wydłużenia gwarancji producenta do min. 7 lat w trybie onsite z gwarantowanym skutecznym zakończeniem naprawy serwera najpóźniej w następnym dniu roboczym od zgłoszenia usterki (podać koszt na dzień składania oferty);

w przypadku awarii dysków twardych dysk pozostaje u Zamawiającego, czas przystąpienia do naprawy gwarancyjnej - do końca następnego dnia

roboczego, Wykonawca naprawę gwarancyjną musi świadczyć w miejscu instalacji

urządzenia, Zamawiający wymaga aby Wykonawca zapewnił opiekę kierownika

technicznego ds. Eskalacji, dostępność wsparcia technicznego przez 24 godziny 7 dni w tygodniu przez

cały rok, dostęp do portalu technicznego producenta, który umożliwi zamawianie

części zamiennych i/lub wizyt technika serwisowego, mający na celu przyśpieszenie i procesu diagnostyki i skrócenia czasu usunięcia usterki,

szybkie wsparcie telefoniczne świadczone przez wyszkolonych inżynierów, a nie przez call center bazujące na skryptach rozmów telefonicznych,

w przypadku wystąpienia usterki wsparcie techniczne ma rozwiązywać problemy z fabrycznie zainstalowanym oprogramowaniem,

w przypadku wystąpienia usterki wymagana jest natychmiastowa reakcja wsparcia technicznego (diagnostyka zaraz po wystąpieniu awarii).

Dokumentacja, inne Elementy, z których zbudowane są serwery muszą być produktami producenta tych serwerów lub być przez niego certyfikowane oraz całe muszą być objęte gwarancją producenta, o wymaganym w specyfikacji poziomie SLA – wymaganie oświadczenie wykonawcy lub producenta;

Serwer musi być fabrycznie nowy i pochodzić z oficjalnego kanału dystrybucyjnego w UE – wymagane oświadczenie wykonawcy lub producenta;

Ogólnopolska, telefoniczna infolinia/linia techniczna producenta serwera, w ofercie należy podać link do strony producenta na której znajduje się nr telefonu oraz maila na który można zgłaszać usterki;

W czasie obowiązywania gwarancji na sprzęt, możliwość po podaniu na infolinii numeru seryjnego urządzenia weryfikacji pierwotnej konfiguracji sprzętowej serwera, w tym model i typ dysków twardych, procesora, ilość fabrycznie zainstalowanej pamięci operacyjnej, czasu obowiązywania i typ udzielonej gwarancji;

111


Możliwość aktualizacji i pobrania sterowników do oferowanego modelu serwera w najnowszych certyfikowanych wersjach bezpośrednio z sieci Internet za pośrednictwem strony www producenta serwera;

Oprogramowanie systemowe Liczba szt. – 4

Kategoria Opis wymagania Przeznaczenie System operacyjny dla dostarczanych serwerów Wymagania - Możliwość zainstalowania w trybach 32 bit i 64 bit.

- Możliwość zainstalowania na serwerach o architekturze X86- Współpraca z dostarczanym oprogramowaniem do wirtualizacji- System z kanału dystrybucji producenta- możliwość pobierania aktualizacji dla systemu

Serwer typu 2 Liczba szt. – 2


Obudowa Typu Rack, wysokość max. 2U; Możliwość zamontowania 8 dysków 2 wentylatory Redundantne zasilacze

Parametry procesor 2 GHz min 4 rdzenie 4GB pamięci RAM 4x karta sieciowa 1Gb/s 2x USB ver. 3 2x USB ver. 2

Dyski Wspierane dyski SATA oraz SSD Dyski HOT SWAP Zainstalowane 8 dysków o pojemności 4TB, certyfikowanych przez producenta

serwera NAS oraz posiadające gwarancję producenta serwera NAS wpierane poziomy RAID: 0/1/5/5+HS/6/10/JBOD wspierane systemy plików: EXT4, EXT3, NTFS, FAT32, HFS+ dyski przeznaczone do pracy 24/7/365

Oprogramowanie VPN Server: OpenVPN 256bit SSL/TLS, PPTP 128bit encryption Radius Server: 802.1x (PAP , EAP-TLS/PAP, EAP-TTLS/PAP) FTP Server: FTP, FTP z SSL/ TLS, FXP, TFTP (PXE boot), SFTP Dostęp do plików za pomocą protokołów CIFS/SMB, NFS, AFP, Serwer monitoringu: możliwość podłączenia do 40 kamer, dostarczona licencja na 4

kamery Wsparcie dla IPv4 oraz IPv6 Port trunking /NIC teaming: Balance-rr (Round-Robin), Active Backup, Balance XOR,

Broadcast, IEEE 802.3ad, Balance-tlb (Adaptive, Transmit Load Balancing), Balance-alb (Adaptive Load Balancing)

Wsparcie dla Microsoft Windows Active Directory Wsparcie dla Open LDAP

iSCSI iSCSI target iSCSI LUN online expansion LUN mapping / LUN masking Online LUN capacity expansion MC/S MPIO (multipath input output) for load balancing and failover iSCSI LUN Backup iSCSI initiator for virtual disks

Gwarancja i serwis Zgłaszanie usterek i awarii sprzętowych poprzez automatyczne założenie zgłoszenia w systemie helpdesk/servicedesk producenta sprzętu;

Firma serwisująca musi posiadać ISO 9001:2000 na świadczenie usług serwisowych;

112


Bezpłatna dostępność poprawek i aktualizacji BIOS/Firmware/sterowników dożywotnio dla oferowanego serwera – jeżeli funkcjonalność ta wymaga dodatkowego serwisu lub licencji producenta serwera, takowy element musi być uwzględniona w ofercie;

Możliwość odpłatnego wydłużenia gwarancji producenta do min. 7 lat w trybie onsite z gwarantowanym skutecznym zakończeniem naprawy serwera najpóźniej w następnym dniu roboczym od zgłoszenia usterki (podać koszt na dzień składania oferty);

w przypadku awarii dysków twardych dysk pozostaje u Zamawiającego, czas przystąpienia do naprawy gwarancyjnej - do końca następnego dnia

roboczego, Wykonawca naprawę gwarancyjną musi świadczyć w miejscu instalacji

urządzenia, Zamawiający wymaga aby Wykonawca zapewnił opiekę kierownika

technicznego ds. Eskalacji, dostępność wsparcia technicznego przez 24 godziny 7 dni w tygodniu przez

cały rok, dostęp do portalu technicznego producenta, który umożliwi zamawianie

części zamiennych i/lub wizyt technika serwisowego, mający na celu przyśpieszenie i procesu diagnostyki i skrócenia czasu usunięcia usterki,

szybkie wsparcie telefoniczne świadczone przez wyszkolonych inżynierów, a nie przez call center bazujące na skryptach rozmów telefonicznych,

w przypadku wystąpienia usterki wsparcie techniczne ma rozwiązywać problemy z fabrycznie zainstalowanym oprogramowaniem,

w przypadku wystąpienia usterki wymagana jest natychmiastowa reakcja wsparcia technicznego (diagnostyka zaraz po wystąpieniu awarii).

UPS Liczba szt. – 3 Kategoria Opis wymagania Ogólne elementy umożliwiające montaż w szafie RACK

zajętość w szafie RACK nie więcej niż 2U ups typu on-line moc pozorna 3kVA moc rzeczywista 2,7 kW podtrzymanie 3,8 minuty przy 100% obciążeniu podtrzymanie 11,5 minuty przy 50% obciążeniu wyjścia: 8x IEC 320 C13 (10A) 1x RJ45 aplikacja do automatycznego zamykania wspieranych systemów operacyjnych w

przypadku braku zasilania wspierane i certyfikowane systemy operacyjne: Microsoft® Windows Server®

2012 R2, SUSE Linux Enterprise Server, Red Hat Enterprise Linux, VMware Infrastructure

zarządzanie przez SNMP automatyczny wewnętrzny bypass bezprzerwowa wymiana baterii wyświetlacz LCD na froncie urządzenia, umożliwiający zarządzanie i monitoring

urządzenia certyfikaty: CE, CB

Gwarancja i serwis door-to-door

Switch dostępowy Liczba szt. – 3 Kategoria Opis wymagania Klasa produktu SWITCH - przełącznik sieciowy zarządzalny

Porty przełącznika: minimum 48x 10/100/1000Base-T RJ45 oraz minimum 4x 1/10GBase-X SFP+

113


Port konsolowy: RJ45 (RS-232)

Port zarządzania: RJ45 (10/100Base-T RJ45)

Port USB: minimum 1 port co najmniej w standardzie 2.0

Szybkość przełączania: minimum 176Gb/s

Przepustowość: minimum 131Mp/s (dla pakietów 64Kb)

Bufor pakietów:minimum 3MB. Dopuszcza się urządzenia oferujące bufor pamięci podzielony na minimum 1,5MB per 24 porty.

Ramki Jumbo: minimum 10k

Tablica adresów MAC minimum 16k

Adresy MAC Multicast minimum 4k

Tablica ACL: minimum 1k

Tablica VLAN: minimum 4094

Tablica routingu:minimum 1k dla IPv4 z możliwością wykorzystania IPv6. Dopuszcza się rozwiązania współdzielące tablicę routingu dla IPv4 oraz IPv6 w maksymalnej proporcji 1:4.

Taktowanie procesora: minimum 800MHz

Pamięć Flash:minimum 160MB. Dopuszcza się urządzenia oferujące maksymalnie 2 kości pamięci z sumaryczną pojemnością spełniającą wymóg

Pamięć RAM: minimum 512MB

Temperatura pracy: zakres minimum 0°C - 50°C

Wilgotność względna: zakres minimum 10% - 95% (bez kondensacji)

Zasilanie: zabudowany zasilacz 230V AC

Pobór mocy: maksymalnie 50WZabezpieczenie przeciwprzepięciowe: minimum 6kV

Wymiary: maksymalna: maksymalna: szerokość 440 mm, wysokość 44mm , głębokość 240mm

Certyfikaty bezpieczeństwa: CE, RoHS

Algorytm pracy: Store and Forward

Obsługa VLAN:

Voice VLAN, Port based VLAN, MAC based VLAN, Protocol based VLAN, Private VLAN, VLAN Translation, N:1 VLAN Translation, GVRP, IEEE 802.1Q, Normal QinQ, Selective QinQ, Flexible QinQ

DHCP:IPv4/IPv6 DHCP Client,IPv4/IPv6 DHCP Relay, Option 82, IPv4/IPv6 DHCP Snooping,IPv4/IPv6 DHCP Server

Drzewo rozpinające: IEEE802.1D (STP), IEEE802.1W (RSTP), IEEE802.1S (MSTP), Multi-Process MSTP, Root Guard, BPDU guard, BPDU forwarding

Protekcja ringowa MRPP, ITU-T G.8032 – recovery time < 50ms, Loopback Detection, Fast Link

Protokoły routingu:

Static Routing, RIPv1/v2, RIPng, OSPFv2/v3, BGP4, BGP4+, OSPF multiple process, LPM Routing, Policy-based Routing (PBR) IPv4/IPv6, VRRP, IPv6 VRRPv3, URPF IPv4/IPv6, ECMP, BFD, Static Multicast Route, Multicast Receive Control, Illegal Multicast Source Detect, GRE Tunnel

Agregacja linków: IEEE 802.3ad (LACP), 128 groups per device / 8 ports per group, load balance

Bezpieczeństwo

Storm Control based on packets, Port Security, MAC Limit based on VLAN and Port, Anti-ARP-Spoofing , Anti-ARP-Scan, ARP Binding, Gratuitous ARP, ARP Limit, Anti ARP/NDP Cheat, Anti ARP Scan, ND Snooping, DAI, IEEE 802.1x, Authentication, Authorization, Accounting, Radius IPv4/IPv6, TACACS+, MAB, Port and MAC based authentication, Accounting based on time length and traffic, Guest VLAN and auto VLAN,

Multicast: IGMP v1/v2/v3 snooping and L2 Query, IGMP Fast leave, MVR, MLD v1/v2 Snooping, IPv4/IPv6 DCSCM, PIM-SM, PIM-DM, PIM-SSM, IGMP authentication

QoS:

8 queques per port, Bandwidth Control, Flow Control: HOL, IEEE802.3x, Flow Redirect, Classification based on ACL, COS, TOS, DiffServ, DSCP, port number; Traffic Policing, PRI Mark/Remark, IEEE 802.1p, Queuing Method: SP, DWRR, SDWRR; DNS Client, DNS Relay

Lista Kontroli Dostępu:

IP Src/Dst ACL, MAC Src/Dst ACL, MAC-IP ACL, User-Defined ACL, Time Range ACL, port number TCP/UDP ACL, VLAN ACL, REDIRECT and Statistics based on ACL, Precedence, Vlan Tag/Untag, Rules can be configured to port and VLAN

Diagnostyka: sFlow, Traffic Analysis, RSPAN, ERSPAN, VCT, Ping, Trace Route, Dying GASP

Zarządzanie TFTP/FTP, CLI, Telnet, Console, Web/SSL (IPv4/IPv6), SSH (IPv4/IPv6), SNMP v1/v2c/v3,

114


SNMP Trap, Public & Private MIB interface, RMON 1,2,3,9, Syslog (IPv4/IPv6), SNTP/NTP (IPv4/IPv6), Dual IMG, Multiple Configuration Files, Port Mirror, CPU Mirror, IEEE 802.3ah/802.1ag OAM, ULDP (like UDLD), LLDP/LLDP MED., VSF (4 devices in one stack) – hardware stacking

Oszczędność energii: IEEE 802.3az (Energy Efficient Ethernet), LED Shut-off,

Oprogramowanie oraz wsparcie techniczne

oprogramowanie przełącznika (firmware) dostępne bez ograniczeń czasowych, przez cały okres cyklu życia urządzenia, poprzez Internet, wsparcie techniczne dystrybutora bez konieczności wykupu dodatkowych usług

Gwarancja:

gwarancja czasu życia (Limited Lifetime warranty) obejmująca:1. przełącznik,2. zasilacze i wiatraki,3. moduły SFP, SFP+ i QSFP+,4. bezterminowy dostęp do nowych wersji oprogramowania,

czas przystąpienia do naprawy gwarancyjnej do następnego dnia roboczego od przyjęcia zgłoszenia,

możliwość zgłaszania awarii w trybie 24x7x365 poprzez ogólnopolską linię telefoniczną producenta.

Okablowanie Niezbedne okablowanie umożliwiające podłączenie switchy za pomocą portów 1/10GBase-X SFP+ (8 paczkordów światłowodowych wraz z modułami SFP+)

FireWall (UTM) Liczba szt. – 1


Wymagania Ogólne

Dostarczony system bezpieczeństwa musi zapewniać wszystkie wymienione poniżej funkcje sieciowe i bezpieczeństwa niezależnie od dostawcy łącza. Dopuszcza się aby poszczególne elementy wchodzące w skład systemu bezpieczeństwa były zrealizowane w postaci osobnych, komercyjnych platform sprzętowych lub komercyjnych aplikacji instalowanych na platformach ogólnego przeznaczenia. W przypadku implementacji programowej dostawca musi zapewnić niezbędne platformy sprzętowe wraz z odpowiednio zabezpieczonym systemem operacyjnym.System realizujący funkcję Firewall musi dawać możliwość pracy w jednym z trzech trybów: Routera z funkcją NAT, transparentnym oraz monitorowania na porcie SPAN.W ramach dostarczonego systemu bezpieczeństwa musi być zapewniona możliwość budowy minimum 2 oddzielnych (fizycznych lub logicznych) instancji systemów w zakresie: Routingu, Firewall’a, IPSec VPN, Antywirus, IPS, Kontroli Aplikacji. Powinna istnieć możliwość dedykowania co najmniej 10 administratorów do poszczególnych instancji systemu.System musi wspierać IPv4 oraz IPv6 w zakresie:· Firewall.· Ochrony w warstwie aplikacji.· Protokołów routingu dynamicznego.

Redundancja,

monitoring i

wykrywanie awarii

1. W przypadku systemu pełniącego funkcje: Firewall, IPSec, Kontrola Aplikacji oraz IPS – musi istnieć możliwość łączenia w klaster Active-Active lub Active-Passive. W obu trybach powinna istnieć funkcja synchronizacji sesji firewall.2. Monitoring i wykrywanie uszkodzenia elementów sprzętowych i programowych systemów zabezpieczeń oraz łączy sieciowych.3. Monitoring stanu realizowanych połączeń VPN.4. System musi umożliwiać agregację linków statyczną oraz w oparciu o protokół LACP. Powinna istnieć możliwość tworzenia interfejsów redundantnych.

Interfejsy, Dysk,

Zasilanie:

1. System realizujący funkcję Firewall musi dysponować minimum:· 18 portami Gigabit Ethernet RJ-45.· 4 gniazdami SFP 1 Gbps.2. System Firewall musi posiadać wbudowany port konsoli szeregowej oraz gniazdo USB umożliwiające podłączenie modemu 3G/4G oraz instalacji oprogramowania z klucza USB.

115


3. W ramach systemu Firewall powinna być możliwość zdefiniowania co najmniej 200 interfejsów wirtualnych - definiowanych jako VLAN’y w oparciu o standard 802.1Q.4. System musi być wyposażony w zasilanie AC.

Parametry wydajności

owe:

1. W zakresie Firewall’a obsługa nie mniej niż 2 mln jednoczesnych połączeń oraz 130.000 nowych połączeń na sekundę.2. Przepustowość Stateful Firewall: nie mniej niż 20 Gbps.3. Przepustowość Firewall z włączoną funkcją Kontroli Aplikacji: nie mniej niż 3.5 Gbps.4. Wydajność szyfrowania IPSec VPN: nie mniej niż 7 Gbps.5. Wydajność skanowania ruchu w celu ochrony przed atakami (zarówno client side jak i server side w ramach modułu IPS) dla ruchu Enterprise Traffic Mix - minimum 2.2 Gbps.6. Wydajność skanowania ruchu typu Enterprise Mix z włączonymi funkcjami: IPS, Application Control, Antywirus - minimum 1.2 Gbps.7. Wydajność systemu w zakresie inspekcji komunikacji szyfrowanej SSL dla ruchu http – minimum 800 Mbps.

Funkcje Systemu

Bezpieczeństwa:

W ramach dostarczonego systemu ochrony muszą być realizowane wszystkie poniższe funkcje. Mogą one być zrealizowane w postaci osobnych, komercyjnych platform sprzętowych lub programowych:1. Kontrola dostępu - zapora ogniowa klasy Stateful Inspection.2. Kontrola Aplikacji.3. Poufność transmisji danych - połączenia szyfrowane IPSec VPN oraz SSL VPN.4. Ochrona przed malware – co najmniej dla protokołów SMTP, POP3, IMAP, HTTP, FTP, HTTPS.5. Ochrona przed atakami - Intrusion Prevention System.6. Kontrola stron WWW.7. Kontrola zawartości poczty – Antyspam dla protokołów SMTP, POP3.8. Zarządzanie pasmem (QoS, Traffic shaping).9. Mechanizmy ochrony przed wyciekiem poufnej informacji (DLP).10. Dwu-składnikowe uwierzytelnianie z wykorzystaniem tokenów sprzętowych lub programowych. W ramach postępowania powinny zostać dostarczone co najmniej 2 tokeny sprzętowe lub programowe, które będą zastosowane do dwu-składnikowego uwierzytelnienia administratorów lub w ramach połączeń VPN typu client-to-site.11. Analiza ruchu szyfrowanego protokołem SSL.12. Analiza ruchu szyfrowanego protokołem SSH.

Polityki, Firewall

1. Polityka Firewall musi uwzględniać adresy IP, użytkowników, protokoły, usługi sieciowe, aplikacje lub zbiory aplikacji, reakcje zabezpieczeń, rejestrowanie zdarzeń.2. System musi zapewniać translację adresów NAT: źródłowego i docelowego, translację PAT oraz:· Translację jeden do jeden oraz jeden do wielu.· Dedykowany ALG (Application Level Gateway) dla protokołu SIP. 3. W ramach systemu musi istnieć możliwość tworzenia wydzielonych stref bezpieczeństwa np. DMZ, LAN, WAN.

Połączenia VPN

1. System musi umożliwiać konfigurację połączeń typu IPSec VPN. W zakresie tej funkcji musi zapewniać:· Wsparcie dla IKE v1 oraz v2.· Obsługa szyfrowania protokołem AES z kluczem 128 i 256 bitów w trybie pracy Galois/Counter Mode(GCM).· Obsługa protokołu Diffie-Hellman grup 19 i 20.· Wsparcie dla Pracy w topologii Hub and Spoke oraz Mesh, w tym wsparcie dla dynamicznego zestawiania tuneli pomiędzy SPOKE w topologii HUB and SPOKE.· Tworzenie połączeń typu Site-to-Site oraz Client-to-Site.· Monitorowanie stanu tuneli VPN i stałego utrzymywania ich aktywności.· Możliwość wyboru tunelu przez protokoły: dynamicznego routingu (np. OSPF) oraz routingu statycznego.· Obsługa mechanizmów: IPSec NAT Traversal, DPD, Xauth.· Mechanizm „Split tunneling” dla połączeń Client-to-Site.2. System musi umożliwiać konfigurację połączeń typu SSL VPN. W zakresie tej funkcji musi zapewniać:· Pracę w trybie Portal - gdzie dostęp do chronionych zasobów realizowany jest za pośrednictwem przeglądarki. W tym zakresie system musi zapewniać stronę komunikacyjną działającą w oparciu o HTML 5.0.· Pracę w trybie Tunnel z możliwością włączenia funkcji „Split tunneling” przy zastosowaniu dedykowanego klienta.

Routing i obsługa

łączy WAN

1. W zakresie routingu rozwiązanie powinno zapewniać obsługę:· Routingu statycznego.· Policy Based Routingu.· Protokołów dynamicznego routingu w oparciu o protokoły: RIPv2, OSPF, BGP oraz PIM.2. System musi umożliwiać obsługę kilku (co najmniej dwóch) łączy WAN z mechanizmami statycznego lub dynamicznego podziału obciążenia oraz monitorowaniem stanu połączeń WAN.

116


Zarządzanie pasmem

1. System Firewall musi umożliwiać zarządzanie pasmem poprzez określenie: maksymalnej, gwarantowanej ilości pasma, oznaczanie DSCP oraz wskazanie priorytetu ruchu.2. Musi istnieć możliwość określania pasma dla poszczególnych aplikacji.3. System musi zapewniać możliwość zarządzania pasmem dla wybranych kategorii URL.

Kontrola Antywiruso

wa

1 Silnik antywirusowy musi umożliwiać skanowanie ruchu w obu kierunkach komunikacji dla protokołów działających na niestandardowych portach (np. FTP na porcie 2021).2. System musi umożliwiać skanowanie archiwów, w tym co najmniej: zip, RAR.3. System musi dysponować sygnaturami do ochrony urządzeń mobilnych (co najmniej dla systemu operacyjnego Android).4. System musi współpracować z dedykowaną platformą typu Sandbox lub usługą typu Sandbox realizowaną w chmurze. W ramach postępowania musi zostać dostarczona platforma typu Sandbox wraz z niezbędnymi serwisami lub licencja upoważniająca do korzystania z usługi typu Sandbox w chmurze.

Ochrona przed

atakami

1. Ochrona IPS powinna opierać się co najmniej na analizie sygnaturowej oraz na analizie anomalii w protokołach sieciowych.2. System powinien chronić przed atakami na aplikacje pracujące na niestandardowych portach.3. Baza sygnatur ataków powinna zawierać minimum 6500 wpisów i być aktualizowana automatycznie, zgodnie z harmonogramem definiowanym przez administratora.4. Administrator systemu musi mieć możliwość definiowania własnych wyjątków oraz własnych sygnatur.5. System musi zapewniać wykrywanie anomalii protokołów i ruchu sieciowego, realizując tym samym podstawową ochronę przed atakami typu DoS oraz DDoS.6. Mechanizmy ochrony dla aplikacji Web’owych na poziomie sygnaturowym (co najmniej ochrona przed: CSS, SQL Injecton, Trojany, Exploity, Roboty) oraz możliwość kontrolowania długości nagłówka, ilości parametrów URL, Cookies.7. Wykrywanie i blokowanie komunikacji C&C do sieci botnet.

Kontrola aplikacji

1. Funkcja Kontroli Aplikacji powinna umożliwiać kontrolę ruchu na podstawie głębokiej analizy pakietów, nie bazując jedynie na wartościach portów TCP/UDP.2. Baza Kontroli Aplikacji powinna zawierać minimum 2500 sygnatur i być aktualizowana automatycznie, zgodnie z harmonogramem definiowanym przez administratora.3. Aplikacje chmurowe (co najmniej: Facebook, Google Docs, Dropbox) powinny być kontrolowane pod względem wykonywanych czynności, np.: pobieranie, wysyłanie plików.4. Baza powinna zawierać kategorie aplikacji szczególnie istotne z punktu widzenia bezpieczeństwa: proxy, P2P.5. Administrator systemu musi mieć możliwość definiowania wyjątków oraz własnych sygnatur.

Kontrola WWW

1. Moduł kontroli WWW musi korzystać z bazy zawierającej co najmniej 40 milionów adresów URL pogrupowanych w kategorie tematyczne.2. W ramach filtra www powinny być dostępne kategorie istotne z punktu widzenia bezpieczeństwa, jak: malware (lub inne będące źródłem złośliwego oprogramowania), phishing, spam, Dynamic DNS, proxy.3. Filtr WWW musi dostarczać kategorii stron zabronionych prawem: Hazard.4. Administrator musi mieć możliwość nadpisywania kategorii oraz tworzenia wyjątków – białe/czarne listy dla adresów URL.5. Administrator musi mieć możliwość definiowania komunikatów zwracanych użytkownikowi dla różnych akcji podejmowanych przez moduł filtrowania..

Uwierzytelnianie

użytkowników w

ramach sesji

1. System Firewall musi umożliwiać weryfikację tożsamości użytkowników za pomocą:· Haseł statycznych i definicji użytkowników przechowywanych w lokalnej bazie systemu.· Haseł statycznych i definicji użytkowników przechowywanych w bazach zgodnych z LDAP.· Haseł dynamicznych (RADIUS, RSA SecurID) w oparciu o zewnętrzne bazy danych.2. Musi istnieć możliwość zastosowania w tym procesie uwierzytelniania dwu-składnikowego.3. Rozwiązanie powinno umożliwiać budowę architektury uwierzytelniania typu Single Sign On przy integracji ze środowiskiem Active Directory oraz zastosowanie innych mechanizmów: RADIUS lub API.

Zarządzanie

11. Elementy systemu bezpieczeństwa muszą mieć możliwość zarządzania lokalnego z wykorzystaniem protokołów: HTTPS oraz SSH, jak i powinny mieć możliwość współpracy z dedykowanymi platformami centralnego zarządzania i monitorowania.2. Komunikacja systemów zabezpieczeń z platformami centralnego zarządzania musi być realizowana z wykorzystaniem szyfrowanych protokołów.3. Powinna istnieć możliwość włączenia mechanizmów uwierzytelniania dwu-składnikowego dla dostępu administracyjnego.4. System musi współpracować z rozwiązaniami monitorowania poprzez protokoły SNMP w wersjach 2c, 3 oraz umożliwiać przekazywanie statystyk ruchu za pomocą protokołów netflow lub sflow.5. System musi mieć możliwość zarządzania przez systemy firm trzecich poprzez API, do którego producent udostępnia dokumentację.6. Element systemu pełniący funkcję Firewal musi posiadać wbudowane narzędzia diagnostyczne, przynajmniej: ping, traceroute, podglądu pakietów, monitorowanie procesowania sesji oraz stanu sesji

117


firewall.

Logowanie

1. Elementy systemu bezpieczeństwa muszą realizować logowanie do aplikacji (logowania i raportowania) udostępnianej w chmurze, lub w ramach postępowania musi zostać dostarczony komercyjny system logowania i raportowania w postaci odpowiednio zabezpieczonej, komercyjnej platformy sprzętowej lub programowej.2. W ramach logowania system pełniący funkcję Firewall musi zapewniać przekazywanie danych o zaakceptowanym ruchu, ruchu blokowanym, aktywności administratorów, zużyciu zasobów oraz stanie pracy systemu. Musi być zapewniona możliwość jednoczesnego wysyłania logów do wielu serwerów logowania.3. Logowanie musi obejmować zdarzenia dotyczące wszystkich modułów sieciowych i bezpieczeństwa oferowanego systemu.4. Musi istnieć możliwość logowania do serwera SYSLOG.

Certyfikaty

Poszczególne elementy oferowanego systemu bezpieczeństwa powinny posiadać następujące certyfikacje:· ICSA lub EAL4 dla funkcji Firewall.· ICSA dla funkcji IPS lub NSS Labs w kategorii NGFW.· ICSA dla funkcji SSL VPN.

Serwisy i licencje

W ramach postępowania powinny zostać dostarczone licencje upoważniające do korzystania z aktualnych baz funkcji ochronnych producenta i serwisów. Powinny one obejmować:a) Kontrola Aplikacji, IPS, Antywirus (z uwzględnieniem sygnatur do ochrony urządzeń mobilnych - co najmniej dla systemu operacyjnego Android), Analiza typu Sandbox, Antyspam, Web Filtering, bazy reputacyjne adresów IP/domen na okres 36 miesięcy.

Gwarancja oraz wsparcie

1. Gwarancja: System musi być objęty serwisem gwarancyjnym producenta przez okres 36 miesięcy, polegającym na naprawie lub wymianie urządzenia w przypadku jego wadliwości. W ramach tego serwisu producent musi zapewniać również dostęp do aktualizacji oprogramowania oraz wsparcie techniczne w trybie 8x5.

Rozszerzone wsparcie serwisowe AHB/SOS

1. System musi być objęty rozszerzonym wsparciem technicznym gwarantującym udostępnienie oraz dostarczenie sprzętu zastępczego na czas naprawy sprzętu w ciągu 8 godzin od momentu potwierdzenia zasadności zgłoszenia, realizowanym przez producenta rozwiązania lub autoryzowanego dystrybutora przez okres 36 miesięcy.2. Dla zapewnienia wysokiego poziomu usług podmiot serwisujący musi posiadać certyfikat ISO 9001 w zakresie świadczenia usług serwisowych. Zgłoszenia serwisowe będą przyjmowane w języku polskim w trybie 24x7 przez dedykowany serwisowy moduł internetowy oraz infolinię w języku polskim 24x7 . Oferent winien przedłożyć dokumenty:· Oświadczanie Producenta lub Autoryzowanego Dystrybutora świadczącego wsparcie techniczne o gotowości świadczenia na rzecz Zamawiającego wymaganego serwisu (zawierające: adres strony internetowej serwisu i numer infolinii telefonicznej).· Certyfikat ISO 9001 podmiotu serwisującego..

Opisy do wymagań ogólnych

1. Opis przedmiotu zamówienia (nie techniczny, tylko ogólny): W przypadku istnienia takiego wymogu w stosunku do technologii objętej przedmiotem niniejszego postępowania (tzw. produkty podwójnego zastosowania), Dostawca winien przedłożyć dokument pochodzący od importera tej technologii stwierdzający, iż przy jej wprowadzeniu na terytorium Polski, zostały dochowane wymogi właściwych przepisów prawa, w tym ustawy z dnia 29 listopada 2000 r. o obrocie z zagranicą towarami, technologiami i usługami o znaczeniu strategicznym dla bezpieczeństwa państwa, a także dla utrzymania międzynarodowego pokoju i bezpieczeństwa (Dz.U. z 2004, Nr 229, poz. 2315 z późn zm.) oraz dokument potwierdzający, że importer posiada certyfikowany przez właściwą jednostkę system zarządzania jakością tzw. wewnętrzny system kontroli wymagany dla wspólnotowego systemu kontroli wywozu, transferu, pośrednictwa i tranzytu w odniesieniu do produktów podwójnego zastosowania.2. Opis przedmiotu zamówienia (nie techniczny, tylko ogólny): Oferent winien przedłożyć oświadczenie producenta lub autoryzowanego dystrybutora producenta na terenie Polski, iż oferent posiada autoryzację producenta w zakresie sprzedaży oferowanych rozwiązań

Gwarancja i serwis Zamawiający wymaga wsparcia technicznego dla zaoferowanej gwarancji w trybie 24 godziny 7 dni w

tygodniu przez cały rok

118


Oprogramowanie do wirtualizacji Liczba szt. – 3

Licencja dla 3 serwerów fizycznych posiadających 2 procesory z gwarancją utrzymania aktualnej wersji przez okres min. 3 lat,

Kod wymagania Opis WYM.WIR.001 Warstwa wirtualizacji musi być zainstalowana bezpośrednio na sprzęcie fizycznym bez

dodatkowych pośredniczących systemów operacyjnychWYM.WIR.002 Rozwiązanie musi zapewnić możliwość obsługi wielu instancji systemów operacyjnych na

jednym serwerze fizycznym i powinno się charakteryzować maksymalnym możliwym stopniem konsolidacji sprzętowej.

WYM.WIR.003 Pojedynczy klaster może się skalować do 64 fizycznych hostów (serwerów) z zainstalowaną warstwą wirtualizacji.

WYM.WIR.004 Oprogramowanie do wirtualizacji zainstalowane na serwerze fizycznym potrafi obsłużyć WYM.WIR.005 i wykorzystać procesory fizyczne wyposażone w 480 logicznych wątków oraz do 6TB

pamięci fizycznej RAM.WYM.WIR.006 Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn

wirtualnych 1-128 procesorowych.WYM.WIR.007 Oprogramowanie do wirtualizacji musi zapewniać możliwość stworzenia dysku maszyny

wirtualnej o wielkości do 62 TB.WYM.WIR.008 Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn

wirtualnych WYM.WIR.009 z możliwością przydzielenia do 4 TB pamięci operacyjnej RAM.WYM.WIR.010 Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn

wirtualnych, z których każda może mieć 1-10 wirtualnych kart sieciowych.WYM.WIR.011 Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn

wirtualnych, z których każda może mieć 32 porty szeregowe.WYM.WIR.012 Rozwiązanie musi umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe usługi bez

spadku wydajności i dostępności pozostałych wybranych usług.WYM.WIR.013 Rozwiązanie powinno w możliwie największym stopniu być niezależne od producenta

platformy sprzętowej.WYM.WIR.014 Polityka licencjonowania musi umożliwiać przenoszenie licencji na oprogramowanie do

wirtualizacji pomiędzy serwerami.WYM.WIR.015 Rozwiązanie musi wspierać następujące systemy operacyjne: MS-DOS 6.22, Windows

3.1, Windows 95, Windows 98, Windows XP, Windows Vista , Windows NT 4.0, Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows 7, Windows 8, SLES 11, SLES 10, SLES 9, SLES 8, RHEL 6, RHEL 5, RHEL 4, RHEL 3, Solaris 11 ,Solaris 10, Solaris 9, Solaris 8, OS/2 Warp 4.0, NetWare 6.5, NetWare 6, NetWare 5, OEL 4, OEL 5, Debian, CentOS, FreeBSD, Asianux, Mandriva, Ubuntu 14, Ubuntu 12, SCO OpenServer, SCO Unixware, Mac OS X.

WYM.WIR.016 Rozwiązanie musi umożliwiać przydzielenie większej ilości pamięci RAM dla maszyn wirtualnych niż fizyczne zasoby RAM serwera w celu osiągnięcia maksymalnego współczynnika konsolidacji.

WYM.WIR.017 Rozwiązanie musi umożliwiać udostępnienie maszynie wirtualnej większej ilości zasobów dyskowych niż jest fizycznie zarezerwowane na dyskach lokalnych serwera lub na macierzy.

WYM.WIR.018 Rozwiązanie powinno posiadać centralną konsolę graficzną do zarządzania maszynami wirtualnymi i do konfigurowania innych funkcjonalności. Centralna konsola graficzna powinna mieć możliwość działania zarówno, jako aplikacja na maszynie fizycznej lub wirtualnej, jak i jako gotowa, wstępnie skonfigurowana maszyna wirtualna tzw. virtual appliance.

WYM.WIR.019 Rozwiązanie musi zapewnić możliwość bieżącego monitorowania wykorzystania zasobów fizycznych infrastruktury wirtualnej (np. wykorzystanie procesorów, pamięci RAM, wykorzystanie przestrzeni na dyskach/wolumenach) oraz przechowywać i wyświetlać

119


dane maksymalnie sprzed roku. WYM.WIR.020 Oprogramowanie do wirtualizacji powinno zapewnić możliwość wykonywania kopii

migawkowych instancji systemów operacyjnych (tzw. snapshot) na potrzeby tworzenia kopii zapasowych bez przerywania ich pracy.

WYM.WIR.021 Oprogramowanie do wirtualizacji musi zapewnić możliwość klonowania systemów operacyjnych wraz z ich pełną konfiguracją i danymi.

WYM.WIR.022 Oprogramowanie do wirtualizacji oraz oprogramowanie zarządzające musi posiadać możliwość integracji z usługami katalogowymi Microsoft Active Directory.

WYM.WIR.023 Rozwiązanie musi zapewniać mechanizm bezpiecznego uaktualniania warstwy wirtualizacyjnej (hosta, maszyny wirtualnej) bez potrzeby wyłączania wirtualnych maszyn.

WYM.WIR.024 System musi posiadać funkcjonalność wirtualnego przełącznika (virtual switch) umożliwiającego tworzenie sieci wirtualnej w obszarze hosta i pozwalającego połączyć maszyny wirtualne w obszarze jednego hosta, a także na zewnątrz sieci fizycznej. Pojedynczy przełącznik wirtualny powinien mieć możliwość konfiguracji do 4000 portów.

WYM.WIR.025 Pojedynczy wirtualny przełącznik musi posiadać możliwość przyłączania do niego dwóch i więcej fizycznych kart sieciowych, aby zapewnić bezpieczeństwo połączenia ethernetowego w razie awarii karty sieciowej.

WYM.WIR.026 Wirtualne przełączniki musza obsługiwać wirtualne sieci lokalne (VLAN).WYM.WIR.027 Rozwiązanie musi zapewnić wbudowany, bezpieczny mechanizm do automatycznego

tworzenia kopii zapasowych, odtwarzania wskazanych maszyn wirtualnych. Mechanizm ten musi umożliwiać również odtwarzanie pojedynczych plików z kopii zapasowej oraz zapewnia stosowanie deduplikacji dla kopii zapasowych. Mechanizm zapewnia możliwość wykonywania spójnych kopii zapasowych serwerów aplikacyjnych (Microsoft SQL Server, Microsoft Exchange Server, Microsoft SharePoint Server) oraz replikację kopii zapasowych.

WYM.WIR.028 Rozwiązanie musi zapewniać mechanizm replikacji wskazanych maszyn wirtualnych w obrębie klastra serwerów fizycznych.

WYM.WIR.029 Rozwiązanie musi mieć możliwość przenoszenia maszyn wirtualnych w czasie ich pracy pomiędzy serwerami fizycznymi. Mechanizm powinien umożliwiać 4 lub więcej takich procesów przenoszenia jednocześnie.

WYM.WIR.030 Musi zostać zapewniona odpowiednia redundancja i taki mechanizm (wysokiej dostępności HA) , aby w przypadku awarii lub niedostępności serwera fizycznego wybrane przez administratora i uruchomione nim wirtualne maszyny zostały uruchomione na innych serwerach z zainstalowanym oprogramowaniem wirtualizacyjnym.

120

szpital-ostroda.plszpital-ostroda.pl/userfiles/attachments/tenders/232/2... · Web viewMorfologia...

Documents

Transcript of szpital-ostroda.plszpital-ostroda.pl/userfiles/attachments/tenders/232/2... · Web viewMorfologia...