OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

1 ZAŁĄCZNIK NR 9 DO SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA W PROJEKCIE E-ZDROWIE DLA MAZOWSZA NA DOSTAWY I WDROŻENIE EDM, SSI Niniejszy załącznik składa się z 233 ponumerowanych stron Warszawa, dnia r. Strona 1 z 233

2 Strona 2 z 233

3 Spis treści Spis treści Ogólny opis projektu Opis projektu Cele szczegółowe Wykaz podmiotów biorących udział w realizacji Projektu Charakterystyka rozwiązania Główne zadania projektu Akty Prawne Przedmiot zamówienia Architektura Systemu Główne założenia Transmisja danych w sieci rozległej, węzły sieci Organizacja wdrożenia Założenia podstawowe Przygotowanie Dokumentacji Przygotowanie Struktury Systemu i Projektu Dostawa i instalacja Infrastruktury sprzętowej Dostawa i instalacja Oprogramowania standardowego Dostawa, instalacja, konfiguracja i wdrożenie Oprogramowania aplikacyjnego Testy Odbiór koocowy Dodatkowe zobowiązania Wykonawcy Zobowiązania PP Oprogramowanie aplikacyjne - Wymagania ogólne Niezawodnośd Systemu Dostępnośd Systemu LREDM RREDM SSI Strona 3 z 233

4 5.2.4 CASE Wydajnośd Systemu SEDM SSI CASE Elektroniczna Dokumentacja Medyczna Wymagania Ogólne REDM wymagania ogólne REDM Przechowywanie i przetwarzanie EDM REDM Prezentacja i przetwarzanie danych REDM Integracja infrastruktura IHE REDM Bezpieczeostwo i audyt Serwer Centrum Autoryzacji (CA) REDM Poprawnośd danych EHR Viewer Funkcjonalności ogólne EHR Viewer Funkcjonalności uwierzytelnienia użytkownika EHR Viewer Funkcjonalności wyszukiwania pacjenta EHR Viewer Funkcjonalności przeglądania danych medycznych pacjenta EHR Viewer Funkcjonalności wyszukiwania dokumentacji medycznej Architektura SEDM Warstwa regionalna Regionalna szyna danych Bazy danych ATNA RREDM Repozytorium regionalne EHR Viewer regionalny Pojedyncze źródło identyfikacji pacjentów Warstwa lokalna Systemu MEZ SSI LREDM EHR Viewer lokalny Strona 4 z 233

5 Mechanizmy integracji Backup Szpitalny System Informatyczny SSI (HIS) Wymagania ogólne Wymogi dotyczące interoperacyjności lub migracji dla oferowanego SSI Centrum Analiz Statystyczno Ekonomicznych (CASE) Architektura ogólna Tryb współpracy CASE z Oprogramowaniem Partnerów Projektu (PP) Sposób dostosowania systemów dziedzinowych do potrzeb związanych z raportowaniem Wymagania dotyczące hurtowni danych (HD) Wymagania dotyczące systemu Business Intelligence (BI) Źródła i zakres danych gromadzonych w CASE Zakres danych gromadzonych w CASE Raporty Sprzęt komputerowy (Infrastruktura sprzętowa) - Wymagania Urządzenia wielofunkcyjne Urządzenie skanująco drukujące Typ Urządzenie skanująco drukujące Typ Urządzenie skanująco drukujące Typ 3 (2) Urządzenie skanująco drukujące Typ Urządzenie skanująco-drukujące typ 5 A Skaner wielofunkcyjny kolorowy Stacje robocze i komputery przenośne Tablet Zestaw terminalowy z monitorem Stacja Mobilna Laptop Notebook Zestaw Komputerowy Typ 1 (kliencki) Zestaw Komputerowy Typ 2 (kliencki) Zestaw komputerowy Typ 3 (kliencki) Strona 5 z 233

6 6.2.9 Zestaw Komputerowy Typ 4 (kliencki) Monitor Wyposażenie stanowisk pracy Kolektor danych Skaner Dowodów osobistych Drukarka kodów kreskowych Czytnik kodów kreskowych Czytnik kodów kreskowych bezprzewodowy Czytnik kodów kreskowych 2D bezprzewodowy Drukarka opasek dla pacjentów Sprzęt do obsługi SSK Sprzęt do EOD Drukarka etykiet EOD - 2 sztuki Czytnik kodów kreskowych EOD 2 sztuki Skaner dokumentów EOD - 1 sztuka Monitor LED do monitorowania parametrów infrastruktury Sprzęt serwerowy (Infrastruktura serwerowa) - Wymagania Macierze Macierz dyskowa SSD Macierz Typ Macierz Typ Macierz Typ Macierz Typ Macierz Typ Macierz Typ Macierz Typ Serwery Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Strona 6 z 233

7 7.2.6 Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Serwer Typ Obudowa Blade Typ Obudowa Blade Typ Sprzęt serwerowy pozostały Przełącznik SAN Typ Przełącznik SAN Typ Switch ISCSI Typ Switch ISCSI Typ Switch ISCSI Typ Biblioteka Taśmowa Typ Biblioteka Taśmowa Typ Biblioteka Taśmowa Typ KVM + Panel Urządzenie NAS Rozwiązanie backupowe (PP nr 6, 8) Rozwiązania backupowe (PP nr 20) Szafa serwerowa 42 U Szafa Rack 27U Szafa Rack 24U UPS UPS Strona 7 z 233

8 UPS UPS UPS Rozbudowa istniejącego rozwiązania serwerowego (PP nr 16) Rozbudowa istniejącego rozwiązania serwerowego (PP nr 20) Listwa Zasilająca do szafy Moduł SFP FC long distance Oprogramowanie standardowe - Wymagania Wymagania ogólne Oprogramowanie do obsługi kopii zapasowych (System Backupu) Oprogramowanie antywirusowe Oprogramowanie wirtualizacyjne Oprogramowanie do monitoringu sieci Oprogramowanie systemowe dla Sprzętu serwerowego Oprogramowanie systemowe dla Sprzętu komputerowego Licencje dostępowe dla oprogramowania serwerowego Specyfikacja dostaw i usług (SDU) Szpital Mazowiecki w Garwolinie Sp. z o.o Specjalistyczny Szpital Wojewódzki w Ciechanowie Mazowiecki Szpital Specjalistyczny im. dr Józefa Psarskiego w Ostrołęce Dostarczane środowisko typu blade musi zostad skonfigurowane w następujący sposób: Wojewódzkiego Szpitala Zespolonego w Płocku Szpital Dziecięcy im. Med. Dr. Med. Jana Bogdanowicza Samodzielny Publiczny Zakład Opieki Zdrowotnej w Warszawie Mazowieckie Specjalistyczne Centrum Zdrowia im. Prof. Jana Mazurkiewicza w Pruszkowie Samodzielny Wojewódzki Publiczny Zespół Zakładów Psychiatrycznej Opieki Zdrowotnej im. Dr Barbary Borzym w Radomiu Samodzielny Specjalistyczny Zespół Zakładów Opieki Zdrowotnej im. Dr Teodora Dunina w Rudce Mazowieckie Centrum Leczenia Chorób Płuc i Gruźlicy Wojewódzka Stacja Pogotowia Ratunkowego i Transportu Sanitarnego Meditrans Samodzielny Publiczny Zakład Opieki Zdrowotnej w Warszawie Strona 8 z 233

9 9.11 Samodzielny Publiczny Zakład Opieki Zdrowotnej Wojewódzka Stacja Pogotowia Ratunkowego i Transportu Sanitarnego w Płocku Samodzielny Publiczny Zakład Opieki Zdrowotnej MEDITRANS OSTROŁĘKA Stacja Pogotowia Ratunkowego i Transportu Sanitarnego w Ostrołęce Samodzielny Publiczny Zakład Opieki Zdrowotnej RM-MEDITRANS Stacja Pogotowia Ratunkowego i Transportu Sanitarnego w Siedlcach Wojewódzki Samodzielny Zespół Publicznych Zakładów Opieki Zdrowotnej im. Prof. Eugeniusza Wilczkowskiego w Gostyninie Mazowiecki Szpital Bródnowski Sp. z o.o Samodzielny Zespół Publicznych Zakładów Opieki Zdrowotnej im. Dzieci Warszawy w Dziekanowie Leśnym Samodzielny Publiczny Zakład Opieki Zdrowotnej Wojewódzki Szpital Zakaźny w Warszawie Samodzielny Wojewódzki Zespół Publicznych Zakładów Psychiatrycznej Opieki Zdrowotnej w Warszawie Mazowieckie Centrum Psychiatrii DREWNICA Sp. z o.o Mazowiecki Szpital Wojewódzki w Siedlcach Sp. z o.o Mazowieckie Centrum Rehabilitacji STOCER Sp. z o.o Mazowiecki Szpital Specjalistyczny w Sp. z o.o Centrum Leczniczo Rehabilitacyjne i Medycyna Pracy ATTIS Sp. z o.o Województwo Mazowieckie Spis załączników Spis rysunków Spis tabel Strona 9 z 233

10 1. Ogólny opis projektu 1.1 Opis projektu Podstawowym celem projektu E-zdrowie dla Mazowsza jest dostosowanie podmiotów leczniczych dla których Samorząd Województwa Mazowieckiego jest podmiotem tworzącym bądź właścicielem do wymogów ustawy z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz. U. Nr 113, poz. 657 i Nr 174, poz. 1039). Rozbudowa ma na celu bezpieczne i zgodne z prawem wytwarzanie, przechowywanie, przekazywanie dokumentów medycznych pomiędzy jednostkami oraz integrację z tworzoną na szczeblu krajowym Elektroniczną Platformą Gromadzenia Informacji o Zdarzeniach Medycznych (P1). Istotnym celem projektu jest również stworzenie Centrum Analiz Statystyczno-Ekonomicznych, co wiąże się z zakupem i wdrożeniem odpowiedniego programu zarządczego, umożliwiającego tworzenie opracowao statystycznych na potrzeby nadzoru merytorycznego sprawowanego przez Samorząd WM nad jednostkami, dla których WM jest organem tworzącym lub właścicielem. Na chwilę obecną nadzór ten sprawowany jest poprzez analizę danych przekazywanych przez jednostki w formie papierowej i obejmuje większy zakres danych niż raporty dla Ministerstwa Zdrowia, GUS i NFZ. Pakiet zarządczy umożliwi WM sprawniejszy nadzór na jednostkami zależnymi, co w konsekwencji przełoży się na korzyści w sferze planowania strategicznego rozwoju służby zdrowia na terenie WM, wpłynie pozytywnie na gospodarkę finansową, ostatecznie przyczyni się do poprawy jakości usług medycznych. Mazowiecki Szpital Bródnowski Sp. z o.o. w Warszawie pełni funkcję lidera projektu E-zdrowie dla Mazowsza realizowanego w ramach Priorytetu II Przyśpieszenie e-rozwoju Mazowsza dla działania 2.1 Przeciwdziałanie wykluczeniu informacyjnemu Regionalnego Programu Operacyjnego Województwa Mazowieckiego Cele szczegółowe 1) Dostosowanie systemów informatycznych w szpitalach do obsługi elektronicznej dokumentacji medycznej zgodnie z wymogami ustawy z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz. U. z 2011 Nr 113, poz. 657 i Nr 174, poz. 1039). 2) Wzrost liczby mieszkaoców wykorzystujących Internet do komunikacji z lekarzem oraz uzyskanie informacji na temat opieki zdrowotnej w WM. 3) Poprawa bezpieczeostwa danych znajdujących się w obszarze opieki zdrowotnej. 4) Wdrożenie nowoczesnych technologii ICT dla personelu medycznego wykorzystującego technologie informatyczne w codziennej pracy. Strona 10 z 233

11 5) Monitorowanie przez WM dostępności do świadczeo medycznych u podległych PP oraz innych danych istotnych dla utrzymania istniejącej infrastruktury medycznej i poziomu świadczonych usług medycznych. 6) Wzrost liczby osób korzystających z usług on line w zakresie informacji na temat opieki zdrowotnej. Cele projektu zostaną osiągnięte poprzez: 1) zakup sprzętu komputerowego, który uzupełni lub zastąpi przestarzały sprzęt u PP, 2) uzupełnienie i wyposażenie PP w niezbędne systemy informatyczne umożliwiające dokumentowanie zdarzeo medycznych zgodnie z Ustawą z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia, 3) prowadzenie elektronicznej dokumentacji medycznej zgodnie ze standardem HL 7 CDA, oraz jej wymianę zgodnie z Rozporządzeniem Ministra Zdrowia z dnia 28 marca 2013 r. w sprawie wymagao dla Systemu Informacji Medycznej (Dz.U. z 2013 r. poz. 463), 4) stworzenie regionalnego archiwum elektronicznej dokumentacji medycznej, która zapewni efektywne wykorzystanie powyższych zadao, 5) zakup i wdrożenie odpowiedniego programu zarządczego umożliwiającego tworzenie opracowao statystycznych na potrzeby nadzoru merytorycznego sprawowanego przez WM nad PP. 6) wyposażenie PP w łącza internetowe zapewniające pełną wymianę danych medycznych między PP, 1.3 Wykaz podmiotów biorących udział w realizacji Projektu W celu zapewnienia kompleksowego systemu e-zdrowie działającego na terenie WM w projekcie udział wezmą 23 mazowieckie jednostki ochrony zdrowia nadzorowane przez Samorząd WM, działające w formie samodzielnych publicznych zakładów opieki zdrowotnej, jak też działające w formie spółek prawa handlowego, dla których podmiotem tworzącym/właścicielem jest WM: 1) Specjalistyczny Szpital Wojewódzki w Ciechanowie, 2) Mazowiecki Szpital Specjalistyczny im. dr J. Psarskiego w Ostrołęce, 3) Wojewódzki Szpital Zespolony w Płocku, 4) Mazowiecki Szpital Specjalistyczny Spółka z ograniczoną odpowiedzialnością z siedzibą w Radomiu, 5) Mazowiecki Szpital Wojewódzki w Siedlcach Sp. z o.o., 6) Mazowiecki Szpital Bródnowski w Warszawie Sp. z o.o., 7) Samodzielny Zespół Publicznych Zakładów Opieki Zdrowotnej im. Dzieci Warszawy w Dziekanowie Leśnym, 8) Szpital Dziecięcy im. prof. dr med. Jana Bogdanowicza Samodzielny Publiczny Zakład Opieki Zdrowotnej w Warszawie, 9) SPZOZ Wojewódzki Szpital Zakaźny w Warszawie, Strona 11 z 233

12 10) Wojewódzki Samodzielny Zespół Publicznych Zakładów Opieki Zdrowotnej im. prof. dr E. Wilczkowskiego w Gostyninie, 11) Mazowieckie Specjalistyczne Centrum Zdrowia im. prof. dr Jana Mazurkiewicza w Pruszkowie, 12) Samodzielny Wojewódzki Publiczny Zespół Zakładów Psychiatrycznej Opieki Zdrowotnej im. dr Barbary Borzym w Radomiu, 13) Samodzielny Wojewódzki Zespół Publicznych Zakładów Psychiatrycznej Opieki Zdrowotnej w Warszawie, 14) Mazowieckie Centrum Psychiatrii Drewnica Spółka z ograniczoną odpowiedzialnością, 15) Szpital Mazowiecki w Garwolinie Sp. z o.o., 16) Samodzielny Specjalistyczny Zespół Zakładów Opieki Zdrowotnej w Rudce, 17) Mazowieckie Centrum Leczenia Chorób Płuc i Gruźlicy w Otwocku, 18) Centrum Leczniczo-Rehabilitacyjne i Medycyny Pracy ATTIS Sp. z ograniczoną odpowiedzialnością, 19) Wojewódzka Stacja Pogotowia Ratunkowego i Transportu Sanitarnego "Meditrans" SPZOZ w Warszawie, 20) Samodzielny Publiczny Zakład Opieki Zdrowotnej Wojewódzka Stacja Pogotowia Ratunkowego i Transportu Sanitarnego w Płocku, 21) Samodzielny Publiczny Zakład Opieki Zdrowotnej "Meditrans Ostrołęka" Stacja Pogotowia Ratunkowego I Transportu Sanitarnego w Ostrołęce, 22) Samodzielny Publiczny Zakład Opieki Zdrowotnej "RM-Meditrans" Stacja Pogotowia Ratunkowego i Transportu Sanitarnego w Siedlcach, 23) Mazowieckie Centrum Rehabilitacji STOCER Sp. z o.o. 24) Województwo Mazowieckie Lokalizacja projektu: Projekt realizowany będzie w 12 miastach województwa mazowieckiego: 1) Warszawie, 2) Siedlcach 3) Radomiu 4) Ciechanowie 5) Płocku 6) Ostrołęce, 7) Otwocku, 8) Garwolinie 9) Gostyninie 10) Konstancinie Jeziornie 11) Pruszkowie 12) Ząbkach. 13) Ponadto projekt realizowany będzie także na terenie gminy Łomianki w Dziekanowie Leśnym oraz w gminie Mrozy w miejscowości Rudka. Rys. 1 Mapa sytuująca projekt na terenie Województwa Mazowieckiego Strona 12 z 233

13 1.4 Charakterystyka rozwiązania Głównym efektem realizacji niniejszego zamówienia będzie stworzenie Regionalnego Archiwum Dokumentów. Repozytorium elektronicznej dokumentacji medycznej powinno zostad wdrożone zarówno w warstwie lokalnej, jak i w warstwie regionalnej. Oznacza to, że każdy Partner Projektu będzie mógł zarządzad procesem tworzenia i gromadzenia elektronicznej dokumentacji medycznej, a jednocześnie wdrożone zostaną mechanizmy synchronizacji zawartości repozytorium EDM z warstwą regionalną. Repozytorium w warstwie regionalnej zawierad będzie łączną całkowitą elektroniczną dokumentację medyczną w skali całego rozwiązania, tj. wszystkich Podmiotów. 1.5 Główne zadania projektu W ramach realizacji niniejszego zamówienia przewidziany jest zakup sprzętu i oprogramowania, które pozwolą na osiągnięcie celów projektu E-Zdrowie dla Mazowsza. Strona 13 z 233

14 Zakup i wdrożenie oprogramowania obejmuje: SSI do elektronicznego ewidencjonowania zdarzeo medycznych dla wszystkich PP w formie rozbudowy (zakup nowych modułów oprogramowania) bądź nowego zakupu, Oprogramowanie do wytwarzania, archiwizowania i przetwarzania Elektronicznej Dokumentacji Medycznej (EDM) oraz utworzenie REDM u PP (z wyłączeniem Zamawiającego) oraz RREDM u Zamawiającego. Oprogramowanie Centrum Analiz Statystyczno Ekonomicznych (CASE), które umożliwia tworzenie opracowao statystycznych na potrzeby nadzoru merytorycznego UMWM, Dodatkowo zostanie zakupiony sprzęt, na który składają się: sprzęt komputerowy (stacje robocze, laptopy, tablety, urządzenia skanująco drukujące, drukarki, niszczarki) który uzupełni lub zastąpi przestarzały sprzęt w jednostkach, sprzęt serwerowy (bazy danych, macierze dyskowe, serwery, backup, szafy rack, system archiwizacji, switche FC, UPSy). Szacowany termin realizacji zamówienia: Akty Prawne 1. Ustawa z dnia 15 kwietnia 2011r. o działalności leczniczej (Dz. U. z 2013 pozycja 217 z późn. zm.), 2. Ustawa z dnia 29 września 1994r. o rachunkowości (tekst jednolity z 2013 pozycja 330 z późn. zm.), 3. Ustawa z dnia 11 marca 2004r. o podatku od towarów i usług (tekst jednolity z 2011r. Dz. U. nr 177 poz z późn. zm.), 4. Ustawa z dnia 26 lipca 1991r. o podatku dochodowym od osób fizycznych (tekst jednolity z 2012r. pozycja 361 z późn. zm.), 5. Rozporządzenie Ministra Zdrowia i Opieki Społecznej z dnia 22 grudnia 1998 r. w sprawie szczególnych zasad rachunku kosztów w publicznych zakładach opieki zdrowotnej (Dz.U. z 1998r. nr 164 poz z późn. zm.).w związku z tym, iż to rozporządzenie zostało uchylone, a nie wydano w tym zakresie nowych przepisów Wykonawca jest zobowiązany dostarczyd Oprogramowanie uwzględniające zasady określone w treści tego aktu lub w wydanych w toku realizacji zamówienia odpowiednich przepisów prawa. 6. Ustawa z dnia 5 grudnia 2008r. o zapobieganiu oraz zwalczaniu zakażeo i chorób zakaźnych u ludzi (tekst jednolity Dz.U z r poz 947 z późn. zm dotyczy Systemu medycznego HIS - Monitorowanie zakażeo zakładowych. a. Ustawa z dnia 29 sierpnia 1997r. o ochronie danych osobowych (tekst jednolity z 2014, pozycja 1182 z późn. zm.),. 7. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadad urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004r. nr 100 poz.1024), Strona 14 z 233

15 8. Rozporządzenie Ministra Zdrowia z dnia 20 września 2012r w sprawie warunków, sposobu i trybu zaopatrywania pacjentów szpitala w znaki identyfikacyjne oraz sposobu postępowania w razie stwierdzenia ich braku (Dz. U. z 2012r. poz. 1098) dotyczy Systemu medycznego HIS), 9. Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (tekst jednolity Dz.U r. poz 177 z zm.), 10. Ustawa z dnia 26 czerwca 1974r. Kodeks pracy (Dz.U. z 2014 roku, pozycja 1502 z późn. zm.), 11. Ustawa o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych ( Dz. U 2004 nr 210 poz z późn. zm., 12. Ustawa z dnia 25 czerwca 1999r. o świadczeniach pieniężnych z ubezpieczenia społecznego w razie choroby i macierzyostwa (tekst jednolity z 2014 roku, pozycja 159 z późn. zm.), 13. Ustawa z dnia 13 października 1998r. o systemie ubezpieczeo społecznych (tekst jednolity z 2014 roku, pozycja 1442 z późn. zm..), 14. Ustawa z dnia 17 lutego 2005r o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U z 2014 roku, pozycja 1114 z późn. zm.), 15. Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagao dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagao dla systemów teleinformatycznych (Dz. U. z 2012r. pozycja 526). 16. Rozporządzenie Ministra Zdrowia z dnia 18 lutego 2011 r. w sprawie warunków bezpiecznego stosowania promieniowania jonizującego dla wszystkich rodzajów ekspozycji medycznej (Dz.U nr 51 poz. 265) Strona 15 z 233

16 2. Przedmiot zamówienia MEZ.1 Wykonawca zrealizuje poniższe zadania, dla których szczegółowe wymagania opisano w rozdziałach 3 9: 1.1. Opracowanie Dokumentacji Struktury Systemu i Projektu 1.2. Dostarczenie i wdrożenie SSI dla PP Szpitalny System Informatyczny dla zinformatyzowania procesów związanych z obsługą pacjenta i procesów szpitalnych, 1.3. Dostarczenie i wdrożenie Lokalnego Repozytorium Elektronicznej Dokumentacji Medycznej dla każdego PP (z wyłączeniem Zamawiającego) oraz Regionalnego Repozytorium Elektronicznej Dokumentacji Medycznej dla Zamawiającego zbioru dokumentacji medycznej generowanej i rejestrowanej w postaci elektronicznej (cyfrowej), 1.4. Dostarczenie i wdrożenie CASE narzędzia dla UMWM do nadzoru merytorycznego nad PP, 1.5. Dostarczenie i wdrożenie CA Centrum Autoryzacji narzędzie informatyczne do wydawania i przechowywania podpisów elektronicznych niekwalifikowanych 1.6. Dostarczenie, uruchomienie i wdrożenie Infrastruktury sprzętowej niezbędnej do funkcjonowania oraz korzystania z SSI, REDM, RREDM i CASE 1.7. Zapewnienie na okres realizacji Projektu - Systemu Zgłoszeo narzędzia informatycznego umożliwiającego zgłaszanie oraz obsługę uwag i Wad przez PP 1.8. Zapewnienie Instruktaży stanowiskowych w celu pomoc użytkownikom w miejscu instalacji, pomocy w administracji i konfiguracji systemu, wykonywaniu dodatkowych prac konfiguracyjnych, konsultacji. MEZ.2 Oprogramowanie i Infrastruktura sprzętowa zamawiane w niniejszym zamówieniu musi byd dostarczane w całości do siedzib PP. MEZ.3 Wszystkie dostarczane Produkty i Komponenty podlegają usłudze projektowania, instalacji, konfiguracji i wdrożenia. MEZ.4 Usługi projektowania, 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. MEZ.5 Wszystkie nazwy własne oprogramowania i sprzętu użyte w opisie przedmiotu zamówienia należy traktowad jako określenie standardów parametrów technicznych, użytkowych, funkcjonalnych i jakościowych oczekiwanych przez Zamawiającego i należy odczytywad wraz z wyrazami lub równoważne. MEZ.6 Zamawiający dopuszcza zastosowanie przez Wykonawcę rozwiązao równoważnych rozwiązaniom wskazanym w opisie przedmiotu zamówienia. MEZ.7 Wykonawca oferując rozwiązanie równoważne do opisanego w specyfikacji jest zobowiązany wykazad równoważnośd w zakresie parametrów technicznych, użytkowych, funkcjonalnych i jakościowych, które muszą byd spełnione na poziomie nie niższym niż parametry wskazane przez Zamawiającego. MEZ.8 Wykonawca jest zobowiązany do realizacji Projektu zgodnie z zasadami i wytycznymi Zamawiającego, ujętymi w niniejszym opisie oraz dokumentach: umowie, studium wykonalności, decyzji ws. dofinansowania, harmonogramie rzeczowo-finansowym i budżecie Projektu oraz innych dokumentach wskazanych przez Zamawiającego, a także Strona 16 z 233

17 wytycznych Unii Europejskiej, wytycznych IZ RPOWM oraz ogólnych zasadach finansowania projektów i obowiązujących przepisów prawa, w tym prawa wspólnotowego. Strona 17 z 233

18 3. Architektura Systemu 3.1 Główne założenia MEZ.9 W ramach Projektu Wykonawca przeprowadzi dostawy i wdrożenie Systemu (Oprogramowanie aplikacyjne) zgodnie z ogólną architekturą, którą prezentuje Rysunek 1: 9.1. REDM - lokalne Repozytorium Elektronicznej Dokumentacji Medycznej RREDM Regionalne Repozytorium Elektronicznej Dokumentacji Medycznej zawierającego kopię REDM tylko do odczytu Szyna usług (ESB) wspiera działania mechanizmów wyszukiwania, zapewnia spójnośd repozytoriów, odpowiedzialna za routing usług i transfer dokumentów Rejestr nagłówków (metadanych) EDM (RREDM) usprawnia mechanizm wyszukiwania dokumentacji Mechanizm eksportu do LREDM odpowiedzialny za integracją HIS z LREDM 9.6. SSI - Szpitalny System Informatyczny PP (rozbudowa bądź wdrożenie nowego systemu) 9.7. CASE - Centrum Analiz Statystyczno Ekonomicznych dla UMWM MEZ.10 W ramach zamówienia Wykonawca zobowiązany jest dostarczyd kompletny zaimplementowany i działający System. Strona 18 z 233

19 Rysunek 1 Architektura Systemu MEZ 3.2 Transmisja danych w sieci rozległej, węzły sieci MEZ.11 Funkcjonowanie RREDM opiera się na komunikacji pomiędzy RREDM, a LREDM połączonymi za pomocą łączy telekomunikacyjnych WAN MEZ. MEZ.12 W celu zapewnienia poufności danych w komunikacji LREDM RREDM Wykonawca skonfiguruje i uruchomi WAN MEZ składający się z kanałów wirtualnych VPN z szyfrowaniem IPSec (Rysunek 2) o sile szyfrowania przynajmniej AES 128 pomiędzy RREDM, a LREDM bazujący na internetowych łączach telekomunikacyjnych zapewnionych przez PP. Strona 19 z 233

20 Jednostka 1 Serwery lokalny Router vpn Połączenia VPN INTERNET Jednostka 2 Serwery lokalny Router vpn Serwery regionalny Warstwa Regionalna Router vpn Rysunek 2 Poglądowy schemat połączenia LREDM i RREDM Strona 20 z 233

21 4. Organizacja wdrożenia 4.1 Założenia podstawowe MEZ.13 Organizacja Projektu opiera się o powszechnie stosowane standardy realizacji projektów informatycznych. MEZ.14 W szczególności organizacja Projektu zakłada, że: Projekt będzie realizowany w oparciu o zdefiniowany uprzednio przez Wykonawcę Harmonogram wdrożenia, który powinien byd uzgodniony i zaakceptowany przez Partnerów oraz odpowiednio utrzymywany w toku realizacji prac, Wykonawca umożliwi Partnerom udział we wszystkich pracach realizowanych przez Wykonawcę w ramach realizacji przedmiotu zamówienia (m.in. w czasie projektowania, instalacji, konfiguracji i wdrożenia), Wykonawca zobowiązany jest przeprowadzid dostawy przedmiotu zamówienia w dokładnych terminach i godzinach uzgodnionych z Partnerami, Wszystkie oferowane urządzenia (Infrastruktura sprzętowa) muszą byd wyprodukowane zgodnie z normą jakości ISO 9001:2000 lub normą równoważną, nośniki Oprogramowania, Infrastruktura sprzętowa muszą byd oznakowane w taki sposób, aby możliwa była identyfikacja zarówno produktu jak i producenta, nośniki z Oprogramowaniem oraz Infrastruktura sprzętowa muszą byd dostarczone Partnerom w oryginalnych opakowaniach fabrycznych, oferowane Oprogramowanie i Infrastruktura sprzętowa muszą pochodzid z oficjalnego kanału dystrybucji producenta, a gwarancja musi pochodzid od producenta i byd świadczona przez sied serwisową producenta. MEZ.15 Prace Wykonawcy będą realizowane na podstawie Harmonogramu wdrożenia. MEZ.16 Szczegółowy Harmonogram wdrożenia zostanie opracowany przez Wykonawcę i uzgodniony z Partnerami nie później niż w ciągu 30 dni od podpisania Umowy. MEZ.17 Wykonawca w Harmonogramie wdrożenia musi uwzględnid w szczególności podział na zadania takie jak projektowanie, dostawy, usługi instalacji/konfiguracji, testowanie, wdrożenie i odbiory. MEZ.18 Realizacja wszystkich zadao dla całości Oprogramowania i Infrastruktury sprzętowej muszą zostad przeprowadzone do roku. MEZ.19 Prace w Projekcie podzielone są na podstawowe etapy zarządcze ze wskazaniem głównych prac do wykonania wg Tabela 1. MEZ.20 Tabela 1 jest podstawą do opracowania przez Wykonawcę szczegółowego Harmonogramu wdrożenia. Strona 21 z 233

22 Tabela 1 Podstawowe etapy i terminy realizacji Projektu MEZ - Harmonogram ETAP I II III IV Analiza przedwdrożeniowa OPIS Wykonawca jest zobowiązany do opracowania i uzgodnienia Harmonogramu wdrożenia Systemu oraz wykonania Dokumentacji Analizy przedwdrożeniowej. Produktem koocowym tego etapu jest szczegółowy Harmonogram wdrożenia dla każdego PP oraz kompletna i odebrana Dokumentacja Analizy przedwdrożeniowej dla każdego PP umożliwiające rozpoczęcie i realizację prac Wykonawcy w celu realizacji wymagao niniejszego Opisu przedmiotu zamówienia. Projektowanie Systemu Wykonanie projektu Systemu w postaci Dokumentacji projektowej niezbędnej do wybudowania całego Systemu MEZ w zakresie obejmującym każdego PP Dostawy Infrastruktury sprzętowej i licencji na Oprogramowanie dla każdego PP W ramach realizacji przedmiotu zamówienia Wykonawca jest zobowiązany do dostaw licencji na Oprogramowanie i Infrastruktury sprzętowej do każdego z PP Produktem tego etapu są kompletnie wykonane dostawy wraz z Dokumentacją. Instalacja, konfiguracja i wdrożenie Oprogramowania oraz Infrastruktury sprzętowej dla każdego PP W ramach realizacji przedmiotu zamówienia Wykonawca jest zobowiązany do wykonania prac instalacyjnych, konfiguracji i wdrożenia Infrastruktury sprzętowej i Oprogramowania u każdego PP oraz zrealizowania Asyst stanowiskowych. Produktem tego etapu są kompletnie wykonane wszystkie dostawy i niezbędne Usługi instalacyjno-wdrożeniowe będące przedmiotem zamówienia wraz z Dokumentacją oraz Asysty stanowiskowe. TERIMN WYKONANIA (NIE PÓŹNIEJ NIŻ DO ) Do 30 dni od daty podpisania Umowy Do 90 dni od daty podpisania Umowy Do 140 dni od daty podpisania Umowy Do 240 dni od daty podpisania Umowy Strona 22 z 233

23 ETAP V Odbiory OPIS Wykonawca zobowiązany jest do przedstawienia poszczególnych składników przedmiotu zamówienia do odbioru: Oprogramowanie, Infrastruktura sprzętowa, Usługi, Dokumentacja, etc. Całośd przedmiotu zamówienia podlega Odbiorowi koocowemu. TERIMN WYKONANIA (NIE PÓŹNIEJ NIŻ DO ) Do dnia MEZ.21 Wdrożenie należy rozumied jako szereg uporządkowanych i zorganizowanych działao mających na celu wybudowanie opisanego w OPZ Systemu. Wdrożenie będzie realizowane w ramach powołanych do tego celu struktur organizacyjnych po stronie Zamawiającego, Partnerów oraz Wykonawcy. MEZ.22 Wdrożenie będzie realizowane na podstawie szczegółowego Harmonogramu wdrożenia opracowanego przez Wykonawcę i zaakceptowanego przez Zamawiającego oraz Partnerów. MEZ.23 W ramach wdrożenia Wykonawca przygotuje informacje na temat struktury organizacyjnej zarządzania Projektem, w ramach której muszą zostad powołane minimum następujące role w projekcie: Kierownik Projektu ze strony Zamawiającego oraz koordynatorzy u PP Kierownik Projektu ze strony Wykonawcy, Koordynator ds. wdrożeo ze strony Wykonawcy. MEZ.24 W ramach struktury organizacyjnej procesu wdrożenia musi zostad również powołany Komitet Sterujący minimum w składzie: Przewodniczący przedstawiciel Zamawiającego, Główny Dostawca przedstawiciel Wykonawcy, Główny Odbiorca przedstawiciel Zamawiającego, Każda z tych ról ma prawo powoład swoich specjalistów dziedzinowych odpowiadających za operacyjną realizację Projektu. Szczegółowe zadania i kompetencje Komitetu Sterującego zostaną szczegółowo opisane w Dokumentacji. MEZ.25 Wdrożenie, z zastrzeżeniami wskazanymi poniżej, w punktach 25.4, 25.5, 25.6, muszą realizowad osoby wymienione w ofercie Wykonawcy w wykazie osób zamieszczonym w ofercie, przy czym: prace instalacyjne i wdrożeniowe systemu muszą byd przeprowadzane przez osoby posiadające doświadczenie w zakresie produktów, których dotyczyd będzie instalacja oraz wdrożenie, osoby wykonujące prace instalacyjne i wdrożeniowe muszą byd dyspozycyjne w trakcie trwania prac instalacyjnych i wdrożeniowych. Wymagany jest stały kontakt roboczy z Zamawiającym i Partnerami, Wykonawca przekaże Zamawiającemu i Partnerom wykaz numerów telefonów kontaktowych do osób wykonujących prace instalacyjne, wdrożeniowe i Asysty stanowiskowe, Zamawiający wymaga, by wszelkie zastępstwa lub trwała zmiana w zespole osób instalujących i wdrażających zgłaszana była niezwłocznie przez Wykonawcę, z Strona 23 z 233

24 zastrzeżeniem, że osoba zastępująca musi posiadad nie mniejsze kwalifikacje niż osoba zastępowana, zastępstwo lub trwała zmiana danej osoby wymaga akceptacji ze strony Zamawiającego, Zamawiający może zażądad zmiany osoby wdrażającej. MEZ.26 Po dokonaniu wdrożenia docelowo System powinien spełniad wymagania określone w Opisie przedmiotu zamówienia oraz uwzględniad charakter prowadzonej przez PP działalności, jak również spełniad wymagania obowiązujących przepisów prawa, w szczególności ustaw i rozporządzeo dotyczących: rachunkowości i sposobu liczenia kosztów, podatków, prawa pracy, ochrony danych osobowych, informatyzacji podmiotów realizujących zadania publiczne, Systemu informacji w ochronie zdrowia. MEZ.27 W trakcie realizacji Wykonawca zaplanuje w uzgodnieniu z Partnerami i zrealizuje Asysty stanowiskowe dla PP w wymiarze min roboczogodzin łącznie dla całego Projektu. MEZ.28 Wymiar Asyst stanowiskowych dla każdego z PP będzie dostosowany do ilości stanowisk korzystających z Oprogramowania i Infrastruktury sprzętowej, rodzajów/typów Oprogramowania i Infrastruktury sprzętowej oraz skali wdrożenia u każdego PP MEZ.29 Ilośd Asyst stanowiskowych w zakresie wymagania MEZ.31, 31.1 dla każdego z Partnerów Projektu będzie stanowid nie mniej niż 85% sumarycznej ilości Asyst stanowiskowych dla Partnera Projektu MEZ.30 PP każdorazowo przy wykorzystaniu puli godzin Asyst stanowiskowych zwróci się do Wykonawcy celem zlecenia odpowiednich prac łącznie z wymiarem godzinowym przeznaczonym na zadanie. MEZ.31 Asysty stanowiskowe będą prowadzone natywnie w języku polskim i obejmą w szczególności: pomoc użytkownikom w korzystaniu z Oprogramowania w miejscu instalacji, pomoc w administracji i konfiguracji Systemu, wykonywanie dodatkowych prac konfiguracyjnych, konsultacje. 4.2 Przygotowanie Dokumentacji MEZ.32 W ramach procesu wdrożenia Wykonawca opracuje w porozumieniu z Zamawiającym i Partnerami Dokumentację, która składa się z czterech zakresów: Dokumentacja Analizy przedwdrożeniowej wraz ze szczegółowym Harmonogramem wdrożenia, Dokumentacja Projektowa, Dokumentacja powykonawcza, Dokumentacja użytkowa. MEZ.33 Dokumentacja powyższa stanowi bazowe zapisy opisujące budowany/zbudowany System oraz sposób organizacji prac i wdrożenia. Na podstawie zapisów w tych dokumentach będą prowadzone i odbierane poszczególne zadania realizowane przy budowie Systemu. Dokumenty te wraz z SIWZ będę stanowiły podstawę do weryfikacji funkcjonalnej i jakościowej Systemu w trakcie odbiorów. Strona 24 z 233

25 MEZ.34 Dokumentacja projektowa wraz z późniejszymi zmianami, obejmuje w szczególności szczegółowe projekty obejmujące warstwę biznesową, logiczną i technologiczną, na podstawie których będzie budowany System, w szczególności w zakresie Oprogramowania aplikacyjnego, Oprogramowania standardowego, Infrastruktury sprzętowej. Dokumentacja podlega akceptacji Zamawiającego i PP. MEZ.35 Dokumentacja projektowa zostanie opracowana przez Wykonawcę z uwzględnieniem Opisu procesów biznesowych funkcjonujących u każdego PP i w uzgodnieniu z PP. MEZ.36 Opis procesów biznesowych dla każdego PP zostanie dostarczony przez Zamawiającego po podpisaniu Umowy. MEZ.37 Dokumentacja użytkowa zawiera w szczególności dokumenty będące instrukcjami obsługi, które w przystępny sposób pokazują jak Użytkownik wewnętrzny ma się posłużyd Oprogramowaniem aplikacyjnym, Infrastrukturą Sprzętową aby obsłużyd procesy i funkcje jakie System może realizowad. Dokumentacja użytkowa powinna zawierad podręczniki użytkownika, umożliwiające samodzielne korzystanie z dostarczonego Sprzętu i Oprogramowania, w szczególności: opis procesów biznesowych realizowanych przez System, dokładny opis funkcjonalny Modułów, opis Formatek w poszczególnych Modułach wraz z opisem ich przeznaczenia, opis wszystkich funkcji dostępnych na pojedynczej Formatce Modułu Oprogramowania aplikacyjnego, opis poruszania się pomiędzy Formatkami poszczególnych Modułów, procedury rozpoznawania przyczyn wystąpienia Wady, sposób korzystania z systemu pomocy, instrukcje instalacji, konfiguracji i administracji, instrukcje postępowania w przypadkach szczególnych oraz awarii, odtworzenie po awarii, instrukcje archiwizacji oraz backup owania. MEZ.38 Dokumentacja powykonawcza powinna zawierad w szczególności: schematy architektury Infrastruktury sprzętowej wraz z połączeniami poszczególnych ich elementów, wykaz elementów Infrastruktury sprzętowej, Infrastruktury sieciowej, Oprogramowania niezbędnego do działania Systemu, w tym również serwerów baz danych, serwerów aplikacyjnych, instrukcje instalacji wszystkich elementów Infrastruktury sprzętowej, Infrastruktury sieciowej, Oprogramowania niezbędnego do działania Systemu, wykaz zalecanych parametrów Oprogramowania niezbędnych do działania Systemu, wykaz konfiguracji Systemu adresowany do Administratora, pozwalającej na samodzielne administrowanie Systemem przez PP po dokonaniu jego Odbioru koocowego, inne dokumenty wytworzone w trakcie realizacji Projektu dotyczące rozwiązao technicznych i projektowych. MEZ.39 Dokumentacja będzie dostarczona w formie elektronicznej na odpowiednio oznakowanych nośnikach elektronicznych CD/DVD umożliwiających jej powielanie oraz w formie papierowej w 4 egzemplarzach w języku polskim. Strona 25 z 233

26 MEZ.40 W związku z tym, że zamówienie realizowane jest w ramach Projektu współfinansowanego przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego oraz budżetu Paostwa w ramach Regionalnego Programu Operacyjnego Województwa Mazowieckiego na lata , Wykonawca zobowiązuje się do umieszczania odpowiednich oznaczeo i logotypów zgodnych z Wytycznymi Instytucji Zarządzającej tym programem w zakresie informacji i promocji na Dokumentacji, Komponentach i Produktach wytwarzanych/dostarczanych w wyniku realizacji przedmiotu zamówienia. Dla Sprzętu oraz nośników Oprogramowania oznacza to naklejenie odpowiednich nalepek. 4.3 Przygotowanie Struktury Systemu i Projektu Pierwszym zadaniem do wykonania w ramach procesu wdrożenia jest opracowanie przez Wykonawcę w uzgodnieniu z PP Struktury Systemu i Projektu, który zgodnie z umową składa się z dwóch części: Dokumentacji Analizy przedwdrożeniowej Dokumentacji Projektowej Oba dokumenty stanowią bazowy zapis opisujący sposób realizacji Projektu i budowany System. Na podstawie zapisów w tych dokumentach będą prowadzone i odbierane poszczególne zadania realizowane przy budowie Systemu. Dokumenty te wraz z SIWZ będę stanowiły podstawę do weryfikacji funkcjonalnej i jakościowej Systemu w trakcie odbiorów. 4.4 Dostawa i instalacja Infrastruktury sprzętowej MEZ.41 Dostawa i instalacja Infrastruktury sprzętowej jest zadaniem mającym na celu dostarczenie zamawianego Sprzętu do wskazanych lokalizacji PP w porozumieniu z PP według Harmonogramu wdrożenia. Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to z bieżącą pracą PP. MEZ.42 Wykonawca zapewni wniesienie dostarczonego Sprzętu do wskazanych pomieszczeo. MEZ.43 Wykonawca dostarczy Sprzęt sukcesywnie w terminie bezpośrednio poprzedzającym jego instalację i w sposób dopasowany do możliwości logistycznych Zamawiającego. Zakres i wielkości dostaw należy każdorazowo uzgodnid z PP. MEZ.44 Wykonawca zobowiązany jest przeprowadzid dostawy przedmiotu zamówienia w godzinach uzgodnionych z PP. MEZ.45 Wszystkie oferowane urządzenia muszą byd nowe, wyprodukowane po 01 stycznia 2015 roku, zgodnie z normą jakości ISO 9001:2000 lub normą równoważną. MEZ.46 Sprzęt i komponenty muszą byd oznakowane przez producenta w taki sposób, aby możliwa była identyfikacja zarówno produktu jak i producenta. MEZ.47 Sprzęt musi byd dostarczony w oryginalnych opakowaniach fabrycznych. MEZ.48 Oferowany sprzęt musi pochodzid z oficjalnego kanału dystrybucji producenta, a gwarancja musi pochodzid od producenta i byd świadczona przez sied serwisową producenta. MEZ.49 Dla całej Infrastruktury sprzętowej, we wszystkich lokalizacjach Wykonawca dostarczy, zamontuje, skonfiguruje i dostroi Sprzęt, Oprogramowanie standardowe (w tym oprogramowanie służące do zarządzania Sprzętem) i Oprogramowanie aplikacyjne. Strona 26 z 233

27 MEZ.50 Jeżeli przy Sprzęcie nie są wymienione lub wymieniona jest niewystarczająca ilośd akcesoriów połączeniowych takich jak przewody zasilające, kable sygnałowe, kable światłowodowe i wszelkie inne przewody a także wkładki sfp, sfp+, itp, a są niezbędne do współdziałania urządzeo - Wykonawca dostarczy potrzebne akcesoria do zbudowania i wdrożenia całości Systemu. 4.5 Dostawa i instalacja Oprogramowania standardowego MEZ.51 W ramach zadania dostawy i instalacji Oprogramowania systemowego i Oprogramowania narzędziowego (Oprogramowanie standardowe) Wykonawca ma dokonad dostawy, instalacji i konfiguracji Oprogramowania standardowego na dostarczonym Sprzęcie oraz w Istniejących systemach informatycznych zgodnie z wymaganiami niniejszego opisu przedmiotu zamówienia w taki sposób aby zapewnid prawidłowe funkcjonowanie Oprogramowania aplikacyjnego, Sprzętu oraz Istniejących systemów informatycznych na wszystkich stanowiskach pracy (stanowiska komputerowe) u Zamawiającego i PP. MEZ.52 Dostawa i instalacja zostanie wykonana w lokalizacjach zgodnych z instalacją Sprzętu zgodnie z Harmonogramem. MEZ.53 Po zakooczeniu instalacji, zainstalowane Oprogramowanie standardowe musi zostad skonfigurowane tak, aby działało poprawnie zgodnie z jego przeznaczeniem i wymaganą architekturą Systemu oraz zapewniało prawidłową pracę Oprogramowania aplikacyjnego. Oprogramowanie standardowe musi zostad zainstalowane i skonfigurowane do pracy na stanowiskach komputerowych podłączonych do sieci LAN, w taki sposób aby zapewnid stabilną pracę Istniejących systemów informatycznych u PP. 4.6 Dostawa, instalacja, konfiguracja i wdrożenie Oprogramowania aplikacyjnego MEZ.54 Zadanie dostawy, instalacji, konfiguracji i wdrożenia Oprogramowania aplikacyjnego obejmuje: SSI (w tym EOD, SSK, pozostałe), LREDM i RREDM, CASE, CA MEZ.55 Dostawa i instalacja ma byd wykonana w wyznaczonych lokalizacjach PP zgodnie z Dokumentacją. MEZ.56 Po zakooczeniu prac instalacyjnych Oprogramowanie musi zostad skonfigurowane i wdrożone w sposób tzw. pod klucz oraz tak, aby oferowało funkcjonalności opisane w SIWZ oraz zgodnie z Dokumentacją. MEZ.57 Oprogramowanie aplikacyjne musi zostad zainstalowane przez Wykonawcę w szczególności z wykorzystaniem Sprzętu i w środowiskach informatycznych Partnerów Projektu. Oprogramowanie aplikacyjne musi zostad zainstalowane i skonfigurowane w sposób tzw. pod klucz na wszystkich stanowiskach komputerowych u PP MEZ.58 Oprogramowanie aplikacyjne musi zostad zainstalowane w taki sposób aby zachowad w całości dotychczasowe integracje z oprogramowaniem posiadanym przez PP w Strona 27 z 233

28 szczególności obejmujące zakres integracji, interfejsy integracji oraz model wymiany danych. 4.7 Testy MEZ.59 W ramach tego zadania zostaną przeprowadzone wszystkie testy opisane w SIWZ. Celem przeprowadzenia testów jest weryfikacja przez PP, czy wszystkie prace wykonane w trakcie budowania Systemu zostały wykonane prawidłowo i zgodnie z założeniami funkcjonalnymi i jakościowymi. Testy będą przeprowadzane przez Wykonawcę przy współudziale pracowników PP jak i wskazanych przez Zamawiającego osób i podmiotów zewnętrznych. MEZ.60 Pozytywne zakooczenie testów wraz z usunięciem wskazanych Wad jest niezbędne aby dla poszczególnych komponentów oraz Systemu dokonad odbiorów w ramach poszczególnych Etapów oraz Odbioru koocowego. 4.8 Odbiór koocowy MEZ.61 Zadanie to ma na celu potwierdzenie wykonania wszystkich zadao wynikających z Projektu, w tym odebrania wszystkich Komponentów i etapów Projektu oraz dostarczenia wszystkich wymaganych w zamówieniu dokumentów. Dokonanie Odbioru koocowego zakooczy prace przy budowie Systemu i będzie podstawą do przekazania Systemu do użytkowania produkcyjnego. 4.9 Dodatkowe zobowiązania Wykonawcy MEZ.62 Wykonanie przedmiotu zamówienia z najwyższą starannością, efektywnością oraz zgodnie z najlepszą praktyką i wiedzą zawodową. MEZ.63 Wykonanie w całości przedmiotu zamówienia w zakresie określonym w opisie przedmiotu zamówienia. MEZ.64 Dokonanie z PP wszelkich koniecznych ustaleo mogących wpływad na przedmiot zamówienia i sposób jego realizacji oraz ciągła współpraca z PP na każdym etapie wykonywania przedmiotu zamówienia. MEZ.65 Stosowanie się do wytycznych wdrożonej u Zamawiającego/PP polityki bezpieczeostwa informacji zgodnej z rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadad urządzenia i systemy informatyczne służące do przetwarzania danych osobowych. MEZ.66 Udzielanie PP każdorazowo pełnej informacji na temat stanu realizacji przedmiotu zamówienia. MEZ.67 Współdziałanie z osobami wskazanymi przez PP. MEZ.68 Przeprowadzenie w trakcie wdrożenia Asysty stanowiskowych w dwóch kategoriach: a) dla użytkowników Oprogramowania aplikacyjnego, b) dla administratorów technicznych - wyznaczonych spośród pracowników PP, obejmujących zakres konfiguracji i użytkowania: SSI, LREDM, RREDM, CASE, CA Strona 28 z 233

29 68.4. Infrastruktury sprzętowej, Oprogramowania standardowego nadzoru nad użytkownikami oraz wydawania uprawnieo (poświadczeo/certyfikatów), pozostałego Oprogramowania oraz Infrastruktury sprzętowej. MEZ.69 Wykonawca uzgodni z PP plan instruktaży w etapie Projektowania Systemu. MEZ.70 Po ukooczeniu Asyst stanowiskowych uczestnicy mają w szczególności umied posługiwad się Oprogramowaniem i jego modułami odpowiednio do swojej roli, a także znad i rozumied ich funkcjonowanie w Systemie. MEZ.71 Administratorzy techniczni po zakooczeniu instruktaży muszą w szczególności umied wykonywad czynności administracji, a także instalacji Oprogramowania aplikacyjnego i Oprogramowania standardowego, znad i umied realizowad procedury backupu, znad wytyczne w zakresie polityki bezpieczeostwa i umied je stosowad. Ponadto powinni znad typowe zagrożenia i problemy związane z funkcjonowaniem Systemu, a także sposoby ich wykrywania oraz przeciwdziałania. Powinni umied instalowad, konfigurowad, rekonfigurowad, monitorowad i prawidłowo eksploatowad dostarczony Sprzęt i Oprogramowanie, jak również znad jego wdrożoną konfigurację. MEZ.72 W przypadku potrzeby Partnerzy zapewniają we własnym zakresie pomieszczenia dla przeprowadzenia Asyst stanowiskowych. Wykonawca może realizowad Asysty stanowiskowe również na stanowiskach pracy pracowników PP Zobowiązania PP Do zobowiązao PP należą: 1) Udzielanie Wykonawcy na bieżąco wyjaśnieo niezbędnych do realizacji przedmiotu zamówienia oraz przekazywania niezbędnych informacji. 2) Informowanie Wykonawcy o wszelkich czynnościach podejmowanych w związku z realizacją Projektu, jeśli będą one miały związek z realizacją przedmiotu zamówienia przez Wykonawcę. 3) Udostępnienie dokumentów, materiałów, danych, dokumentacji i informacji będących w posiadaniu PP, niezbędnych do realizacji przedmiotu zamówienia. 4) Umożliwienie Wykonawcy dostępu do posiadanych przez PP obiektów, sprzętu, sieci internetowej, gniazd zasilających do urządzeo 230V AC, oprogramowania oraz dokumentacji, niezbędnych do realizacji przedmiotu zamówienia, zgodnie z wewnętrznymi regulacjami Zamawiającego w zakresie bezpieczeostwa. 5) Udzielanie asysty technicznej na uzasadniony wniosek Wykonawcy w realizacji przedmiotu zamówienia w zakresie tego wymagającym Strona 29 z 233

30 5. Oprogramowanie aplikacyjne - Wymagania ogólne 5.1 Niezawodnośd Systemu MEZ.73 Wszystkie składniki Systemu mają umożliwiad: Odtworzenie danych na podstawie kopii zapasowej Wykonywanie kopii zapasowych danych w trakcie pracy Systemu Szybkie odtworzenie danych W przypadku wystąpienia większego ponad standardowe obciążenia System powinien zachowad przewidzianą wymaganiami funkcjonalnośd. 5.2 Dostępnośd Systemu MEZ.74 Dostępnośd Systemu jest podzielona na obszary: SEDM, SSI, CASE LREDM MEZ.75 Działanie w trybie 24 godzinnym przez 365 dni w roku z dostępnością co najmniej na poziomie 99% w skali miesiąca. LREDM nie jest dostępne, gdy występuje sytuacja uniemożliwiająca wykorzystanie którejś z jego kluczowych funkcji z przyczyn leżących wewnątrz Systemu (np. awarii, spadku przepustowości Systemu i wynikającego stąd przeciążenia). Przez kluczowe funkcje Systemu należy rozumied te, które są niezbędne dla korzystania z funkcjonalności LREDM. Planowane prace serwisowe (down time) odbywają się w godzinach od 2:00 do 5:00. W ciągu jednego miesiąca mogą odbyd się maksymalnie cztery takie przerwy. Czas planowych prac serwisowych (down time) nie jest liczony jako niedostępnośd RREDM MEZ.76 Działanie w trybie 24 godzinnym przez 365 dni w roku z dostępnością co najmniej na poziomie 97% w skali miesiąca (maksymalnie 6h niedostępności). RREDM nie jest dostępne, gdy występuje sytuacja uniemożliwiająca wykorzystanie którejś z jego kluczowych funkcji z przyczyn leżących wewnątrz Systemu (np. awarii, spadku przepustowości Systemu i wynikającego stąd przeciążenia Systemu). Przez kluczowe funkcje Systemu należy rozumied te, które są niezbędne dla korzystania z funkcjonalnościami RREDM. Planowane prace serwisowe (down time) odbywają się w godzinach od 2:00 do 5:00. W ciągu jednego miesiąca mogą odbyd się maksymalnie dwie takie przerwy. Czas planowych prac serwisowych (down time) nie jest liczony jako niedostępnośd SSI MEZ.77 SSI działa w trybie 24 godzinnym przez wszystkie dni w roku z dostępnością co najmniej na poziomie 99% w skali miesiąca. System nie jest dostępny, gdy występuje sytuacja uniemożliwiająca wykorzystanie którejś z jego kluczowych funkcji z przyczyn leżących wewnątrz Systemu (np. awarii, spadku przepustowości Systemu i wynikającego stąd Strona 30 z 233

31 przeciążenia Systemu). Przez kluczowe funkcje Systemu należy rozumied te, które są niezbędne dla korzystania z funkcjonalności SSI. Planowane prace serwisowe (down time) odbywają się w godzinach od 2:00 do 5:00. W ciągu jednego miesiąca mogą odbyd się maksymalnie cztery takie przerwy. Czas planowych prac serwisowych (down time) nie jest liczony jako niedostępnośd CASE MEZ.78 CASE zapewnia dostępnośd co najmniej na poziomie 97% w skali miesiąca (maksymalnie 6h niedostępności) w godzinach 7-17, natomiast w godzinach 17-7 oraz w pozostałe dni dostępnośd na poziomie 96% w skali miesiąca (maksymalnie 20,8h niedostępności). Planowane prace serwisowe (down time) odbywają się poza godzinami korzystania z CASE. W ciągu jednego miesiąca mogą odbyd się maksymalnie cztery przerwy. Czas planowych prac serwisowych (down time) nie jest liczony jako niedostępnośd. 5.3 Wydajnośd Systemu MEZ.79 Wydajnośd Systemu obejmuje SEDM, SSI i CASE: SEDM MEZ.80 Czas dostępu do danych w RREDM nie może byd dłuższy niż 10 sekund (liczony jako czas od wysłania zapytania do dostarczenia odpowiedzi z rejestru RREDM). MEZ.81 Czas dostępu do danych w REDM nie może byd dłuższy niż 3 sekund (liczony jako czas od wysłania zapytania do otrzymania odpowiedzi z REDM). MEZ.82 Architektura RREDM musi pozwalad na tworzenie klastrów wydajnościowych oraz niezawodnościowych SSI MEZ.83 Architektura SSI ma zapewnid możliwośd skalowania wydajności bez konieczności modyfikacji oprogramowania a jedynie poprzez rozbudowę środowiska sprzętowego i licencji Oprogramowania standardowego MEZ.84 SSI ma zapewnid czas oczekiwania na wynik operacji w dowolnym module nie dłuższy niż 5 s przy średnim obciążeniu 50 użytkowników pracujących jednocześnie CASE MEZ.85 Czas dostępu do dowolnego raportu zgromadzonego w CASE nie może byd dłuższy niż 10 sekund (liczony jako czas od wysłania zapytania do dostarczenia raportu). MEZ.86 Czas dostępu do dowolnego raportu zgromadzonego w CASE nie może byd dłuższy niż 20 sekund (liczony jako czas od wysłania zapytania do dostarczenia raport) przy średnim obciążeniu 25 użytkowników pracujących jednocześnie. Strona 31 z 233

32 5.4 Elektroniczna Dokumentacja Medyczna Wymagania Ogólne MEZ.EDM.1 MEZ.EDM.2 MEZ.EDM.3 System MEZ ma zapewniad rozdzielnośd LREDM i RREDM. Planowane rozwiązanie nie pozwala na bezpośredni dostęp do LREDM z poziomu RREDM. Wymiana Elektronicznej Dokumentacji Medycznej jest realizowana jednostronnie na osi LREDM RREDM. Zasilanie LREDM Elektroniczną Dokumentacją Medyczną jest realizowane jednostronnie na osi systemy dziedzinowe u PP typu SSI (HIS), LIS, RIS, PACS LREDM. Pod względem architektury SEDM będzie podzielony na częśd regionalną RREDM, w której funkcjonowad będą elementy systemu odpowiadające za interoperacyjnośd rozwiązania, częśd lokalną LREDM, działającą u poszczególnych PP wchodzącą w skład domeny. Oba elementy SEDM (RREDM, LREDM) mogą byd posadowione w lokalizacji jednego z uczestników projektu, bądź też hostowane i udostępniane w modelu Cloud zgodnie z obowiązującymi wymaganiami prawnymi. Ostateczna architektura rozwiązania będzie uzgodniona z PP Wykonawca musi wdrożyd LREDM u każdego PP oraz RREDM w lokalizacji Zamawiającego REDM wymagania ogólne MEZ.EDM.4 REDM odpowiada za przyjmowanie i przechowywanie dokumentów medycznych w postaci elektronicznej. MEZ.EDM.5 REDM odpowiada za gromadzenie i przetwarzanie dowolnej EDM, zgodnej ze standardem HL7 CDA. MEZ.EDM.6 REDM wykorzystuje standard identyfikatorów OID. MEZ.EDM.7 REDM powinno natywnie wspierad mechanizm wielo-jednostkowości (multitenancy). W ramach jednej instancji można utworzyd nielimitowaną ilośd logicznie odseparowanych od siebie repozytoriów, przynależących do osobnych jednostek leczniczych i posiadających unikalne identyfikatory. MEZ.EDM.8 REDM jest neutralne pod względem zawartości. MEZ.EDM.9 REDM wyposażone jest w interfejs web services pozwalający na pobranie dowolnego dokumentu o znanym identyfikatorze. MEZ.EDM.10 REDM obsługuje standard WS-Trust, umożliwiający delegację uprawnieo użytkowników zewnętrznych poprzez zaufanego brokera bezpieczeostwa oraz współpracę z systemem STS (Security Token Service). MEZ.EDM.11 REDM pozwala na przesyłanie oraz udostępnianie dokumentów oraz innych obiektów za pomocą web service. Interface web service pozwala na dodawanie dowolnych metadanych. MEZ.EDM.12 REDM obsługuje profil integracyjny XDS.b. MEZ.EDM.13 W ramach integracji web services REDM obsługuje standard WS-Security. Strona 32 z 233

33 MEZ.EDM.14 SRDM może byd zintegrowane z systemami wykonującymi transformację dokumentów (transkrypcję tekstu, wykonywanie skrótów i rekompresji dokumentów). MEZ.EDM.15 Silnik REDM zbudowany jest w architekturze dwuwarstwowej warstwy persystencji (opartej o bazę danych) oraz warstwy logiki biznesowej. MEZ.EDM.16 Repozytorium obsługuje teczki dokumentów. MEZ.EDM.17 Dokumenty umieszczone w repozytorium nie mogą byd modyfikowane oraz usuwane przed upływem okresu retencji. REDM umożliwia natomiast wykonywanie adnotacji do dokumentów oraz zamianę dokumentów. REDM przechowuje zarówno dokument oryginalny, adnotację oraz ewentualny dokument zamieniający (replacement document). REDM przechowuje relacje pomiędzy dokumentami oryginalnym, zamieniającym oraz adnotacjami. MEZ.EDM.18 REDM posiada wbudowane mechanizmy pozwalające na zbieranie danych z obszaru wydajności działania oprogramowania (performance monitoring). MEZ.EDM.19 REDM posiada natywne wsparcie do wdrożeo w środowiskach klastrowych REDM Przechowywanie i przetwarzanie EDM MEZ.EDM.20 Repozytorium przechowuje informację o zgodach pacjenta na udostępnianie dokumentów w ramach PL, oraz na udostępnianie dokumentu poza PL. MEZ.EDM.21 Repozytorium wykorzystuje zewnętrzne systemy znakowania czasem oraz Centra Autoryzacji, co pozwala na automatyczne znakowanie czasem i automatyczne elektroniczne podpisywanie dokumentów. MEZ.EDM.22 Repozytorium posiada mechanizm wersjonowania dokumentów. MEZ.EDM.23 Repozytorium umożliwia definiowanie typów przechowywanych dokumentów. MEZ.EDM.24 Repozytorium obsługuje umieszczanie identyfikatorów dokumentów przechowywanych w innych systemach repozytoryjnych (zgodnie z XDS.b). MEZ.EDM.25 Repozytorium oblicza identyfikator hash jednoznacznie związany z zawartością dokumentu. MEZ.EDM.26 Repozytorium umożliwia przechowywanie dokumentów, których typy oraz sekcje zdefiniowane są na podstawie słownika LOINC. MEZ.EDM.27 Repozytorium odrzuca próbę rejestracji dokumentu o tym samym identyfikatorze oraz innej zawartości (liczonej jako różna zawartośd binarna). MEZ.EDM.28 W ramach procesu rejestracji dokumentu, repozytorium modyfikuje metadane dodając co najmniej: identyfikator repozytorium, skrót dokumentu (hash), wielkośd dokumentu. MEZ.EDM.29 Repozytorium obsługuje dokumenty w formacie HL7 CDA Lv1, HL7 CDA Lv2 oraz HL7 CDA Lv3 i pobiera osadzone w nich archetypy openehr. MEZ.EDM.30 Repozytorium przechowuje informacje o tym na jakim medium przechowywany jest dokument. MEZ.EDM.31 Repozytorium definiuje relacje transformacji dokumentów pomiędzy formatami lub formami (np. forma audio transkrypcja). Przechowywany jest zarówno dokument Strona 33 z 233

34 oryginalny jak i transformowany. Zachowywana jest relacja pomiędzy obydwoma dokumentami. MEZ.EDM.32 Repozytorium przechowuje informacje o miejscu składowania dokumentu fizycznego jeśli dokument ma postad fizyczną papierową. MEZ.EDM.33 Repozytorium integruje się z systemami usług semantycznych (terminologicznych) na poziomie web services. MEZ.EDM.34 Repozytorium umożliwia przesyłanie wielu dokumentów bądź wybranych teczek dokumentów w ramach jednego procesu rejestracji. MEZ.EDM.35 Każdy z obiektów, w zależności od typu, może byd opisywany za pomocą zbioru metadanych. Każda z metadanych może byd definiowana jako wymagana, lub opcjonalna. Definicje wymaganych/opcjonalnych metadanych definiowane są dla danego typu obiektu/dokumentu. MEZ.EDM.36 Dla każdego obiektu repozytorium obsługuje co najmniej następujący zestaw metadanych: identyfikator pacjenta, płed pacjenta, początek i koniec zdarzenia medycznego, data utworzenia dokumentu, nazwa i rodzaj dokumentu, rodzaj i nazwa jednostki medycznej, status dokumentu (aktywny, nie aktywny), unikalny identyfikator dokumentu. MEZ.EDM.37 Repozytorium udostępnia narzędzia do przeglądania szablonów i archetypów zgodnych ze standardem openehr. MEZ.EDM.38 Repozytorium udostępnia narzędzia pozwalające na budowanie i testowanie kwerend zgodnych ze specyfikacją AQL. MEZ.EDM.39 Repozytorium natywnie wspiera integrację z platformą SMART (Substitutable Medical Apps & Reusable Technology). MEZ.EDM.40 Repozytorium przechowuje formularze wykorzystywane do bezpośredniego wprowadzania danych do repozytorium. Repozytorium posiada mechanizmy wersjonowania przechowywanych formularzy REDM Prezentacja i przetwarzanie danych MEZ.EDM.41 Repozytorium integruje się z mechanizmami nadawania w sposób atomowy uprawnieo do obiektów przetrzymywanych w repozytorium. Dla każdego obiektu możliwe jest zdefiniowanie przynajmniej następujących uprawnieo: wyświetlenie metadanych i udostępnienie dokumentu. MEZ.EDM.42 Repozytorium umożliwia podpisywanie dokumentów podpisem elektronicznym. Podpis również składowany jest w repozytorium. MEZ.EDM.43 Repozytorium pozwala na zniszczenie dokumentów po upływie okresu retencji. MEZ.EDM.44 Repozytorium wyposażone jest w interfejs web services pozwalający na przeszukiwanie dokumentów, zgodnie z posiadanymi przez użytkownika uprawnieniami. MEZ.EDM.45 Repozytorium posiada interfejsy umożliwiające eksport pojedynczych dokumentów bądź całych zbiorów dokumentów. Eksportowane obiekty mogą byd dodatkowo opatrzone podpisem elektronicznym zapewniającym integralnośd eksportowanych danych. Strona 34 z 233

35 MEZ.EDM.46 Repozytorium zintegrowane jest z zewnętrznymi systemami zarządzania użytkownikami (LDAP). MEZ.EDM.47 Repozytorium posiada wbudowane mechanizmy pozwalające na pełno-tekstowe przeszukiwanie zarówno meta-danych, jak i merytorycznej zawartości przechowywanego dokumentu REDM Integracja infrastruktura IHE MEZ.EDM.48 MEZ.EDM.49 Repozytorium integruje się z domeną identyfikacji pacjenta (pojedynczym źródłem tożsamości pacjenta). Repozytorium integruje się z rejestrem dokumentów na podstawie interfejsu ITI-41 profilu integracyjnego XDS.b REDM Bezpieczeostwo i audyt MEZ.EDM.50 Repozytorium przechowuje tokeny SAML związane z udostępnieniem dokumentu użytkownikowi poprzez okres retencji dokumentu. MEZ.EDM.51 Repozytorium przechowuje wszystkie informacje o żądaniu udostępnienia dokumentu, wraz z informacją czy żądanie pojawiło się od użytkownika wewnętrznego, zewnętrznego i czy skooczyło się udostępnieniem dokumentu czy też odmową udostępnienia Serwer Centrum Autoryzacji (CA). MEZ.EDM.52 MEZ.EDM.53 Do autoryzacji EDM powinny byd stosowane dwa rodzaje podpisów elektronicznych: Kwalifikowany W przypadku EDM udostępnianego na zewnątrz PP np. dla Pacjentów, uprawnionych organów np. sądy, prokuratura, etc Niekwalifikowany W przypadku EDM używanego wyłącznie na potrzeby PP zaangażowanych w MEZ. Wykonawca powinien wybudowad Centrum Autoryzacji (CA) wydające podpisy elektroniczne niekwalifikowane u każdego z PP oraz dostarczyd procedury związane z wydawaniem, przechowywaniem i odnawianiem podpisów REDM Poprawnośd danych MEZ.EDM.54 Repozytorium definiuje reguły walidacji metadanych na etapie inicjalnego wprowadzenia dokumentu. MEZ.EDM.55 Co najmniej obsługiwane są: wyrażenia regularne, występowanie pojęcia w słowniku EHR Viewer Funkcjonalności ogólne MEZ.EDM.56 MEZ.EDM.57 MEZ.EDM.58 Aplikacja umożliwia przeglądanie elektronicznego rekordu pacjenta budowanego na podstawie danych pochodzących z systemów medycznych (SSI). Aplikacja dostępna jest za pośrednictwem przeglądarki internetowej. Wspierane przeglądarki internetowe w wersji minimalnej: Firefox wersja 20.X, Internet Explorer wersja 8.X, Strona 35 z 233

36 58.3. Chrome wersja od 22.X. MEZ.EDM.59 Aplikacja nie gromadzi żadnych danych osobowych pacjentów ani nie przechowuje dokumentacji medycznej. MEZ.EDM.60 Aplikacja nie wymaga instalowania bazy danych. MEZ.EDM.61 Aplikacja może byd zintegrowana z dowolnym innym systemem zgodnym z profilem integracyjnym XDS.b. MEZ.EDM.62 System udostępnia mechanizm nadawania uprawnieo do wykonywania poszczególnych operacji atomowych na dokumentach składowanych w repozytorium EHR Viewer Funkcjonalności uwierzytelnienia użytkownika MEZ.EDM.63 MEZ.EDM.64 Dostęp do aplikacji zabezpieczony jest loginem i hasłem Użytkownicy mogą byd uwierzytelniani za pomocą: lokalnej bazy danych użytkowników, systemów LDAP (zarówno lokalnych, jak i zdalnych) EHR Viewer Funkcjonalności wyszukiwania pacjenta MEZ.EDM.65 MEZ.EDM.66 Aplikacja umożliwia przeszukiwanie rozproszonej bazy danych pacjentów Wyszukiwanie pacjenta możliwe jest przynajmniej na podstawie kryteriów: imię, nazwisko, PESEL, numer dowodu osobistego, numer paszportu EHR Viewer Funkcjonalności przeglądania danych medycznych pacjenta MEZ.EDM.67 Aplikacja umożliwia pobranie pełnej dokumentacji medycznej wybranego pacjenta. MEZ.EDM.68 Podczas pobierania dokumentacji aplikacja prezentuje postęp procesu pobierania dokumentacji. MEZ.EDM.69 Raz pobrana dokumentacja pacjenta jest buforowana na czas trwania sesji użytkownika dzięki czemu nie ma konieczności jej wielokrotnego pobierania. MEZ.EDM.70 Dokumentacja prezentowana jest w widoku chronologicznym lub zagregowanym. MEZ.EDM.71 W widoku chronologicznym prezentowana jest lista epizodów pacjenta z możliwością przeglądania szczegółów każdego z epizodów. MEZ.EDM.72 Widok zagregowany prezentuje na jednym ekranie całą historię leczenia pacjenta. MEZ.EDM.73 Aplikacja posiada widoki tematyczne prezentujące wyłącznie dane medyczne istotne z punktu widzenia danej dziedziny medycyny. MEZ.EDM.74 Aplikacja prezentuje wyniki badao laboratoryjnych w postaci graficznej (wykres czasowy). MEZ.EDM.75 Aplikacja umożliwia personalizację prezentacji danych medycznych przez użytkownika. MEZ.EDM.76 Aplikacja udostępnia systemem pomocy kontekstowej. Strona 36 z 233

37 MEZ.EDM.77 Aplikacja umożliwia wykonywanie kwerend AQL EHR Viewer Funkcjonalności wyszukiwania dokumentacji medycznej MEZ.EDM.78 System umożliwia wyszukiwanie elektronicznych dokumentów medycznych wg następujących kryteriów dziedzinowych: MEZ.EDM.79 Dane dokumentów, między innymi: typ dokumentu, data utworzenia dokumentu, tytuł dokumentu. MEZ.EDM.80 Dane pacjenta: nazwisko, nr PESEL (dla indywidualnych dokumentów medycznych). MEZ.EDM.81 Jednostka organizacyjna: nazwa, specjalnośd jednostki organizacyjnej MEZ.EDM.82 Dane autorów: nazwisko, numer prawa wykonywania zawodu. MEZ.EDM.83 System umożliwia wyszukiwanie elektronicznych dokumentów medycznych wg technicznych identyfikatorów pojęd zdefiniowanych w systemie dziedzinowym w którym utworzono dokument (system źródłowy): MEZ.EDM.84 Rodzaj dokumentu zdefiniowany w systemie źródłowym, MEZ.EDM.85 Identyfikator jednostki organizacyjnej w której utworzono dokument, MEZ.EDM.86 Identyfikator pacjenta (dla indywidualnych dokumentów medycznych), MEZ.EDM.87 Identyfikator autora dokumentu, MEZ.EDM.88 System umożliwia wyszukiwanie wszystkich wersji podanego dokumentu medycznego, które zostały zarejestrowane w repozytorium EDM. MEZ.EDM.89 System umożliwia wyszukiwanie wszystkich załączników do podanego dokumentu medycznego, które zostały zarejestrowane w EDM Architektura SEDM Rysunek 3 przedstawia ogólną koncepcję SEDM. Strona 37 z 233

38 Moduł Ekportu do EDM Regionalna Szyna Danych ATNA Systemy źródłowe MPI EHR Viewer Lokalny EDM BUFOR Regionalny EHR Viewer Master Rejestr nagłówków EDM (XDS Registry) Regionalny EDM Slave Warstwa lokalna Warstwa regionalna Warstwa regionalna MEZ.EDM.90 Rysunek 3 Ogólna Architektura SEDM Na warstwę regionalną system MEZ składają się następujące elementy: Pojedyncze źródło identyfikacji pacjenta (MPI) Rejestr regionalny (XDS.Registry) Identity provider Regionalna instancja systemu EHR Viewer Repozytorium regionalne (XDS.Repository) Regionalna szyna danych Moduł ATNA Regionalna szyna danych MEZ.EDM.91 MEZ.EDM.92 MEZ.EDM.93 Szyna usług musi byd zgodna ze standardami: SOAP 1.1, SOAP 1.2, SOAP WITH ATTACHMENTS i obsługiwad wiele warstw transportowych np.: JMS, HTTP,FTP, TCP. Oraz obsługę komunikatów typu np.: SOAP, XML, SMTP. Szyna usług będzie oparta o serwer aplikacji zgodny ze standardem JEE (Java Enterprise Edition). Szyna musi mied wbudowaną obsługę co najmniej następujących mechanizmów: kolejkowych autoryzacji i mapowania ról Strona 38 z 233

39 MEZ.EDM.94 MEZ.EDM klastrowania Szyna usług musi umożliwid: Implementację komunikacji bezpośredniej pomiędzy lokalną EDM a regionalnym EDM na podstawie posiadanych adapterów, oraz transformację danych i komunikatów np. xpath/xslt/xquery i ma umożliwiad wzbogacanie transformacji danych o warunki logiczne lub ograniczenia Monitorowanie poprawnej pracy usług Eksportu ustawieo konfiguracyjnych i importu na innej instancji Szyny Usług Realizacji poziomów bezpieczeostwa w zakresie uwierzytelniania, Kontroli dostępu, Zarządzania użytkownikami, grupami i rolami, przechowywania i walidacji certyfikatów, haseł, klucza oraz audytowania zdarzeo bezpieczeostwa Ograniczenia czasu wywołao dla usług oraz Szyna usług ma zawierad zestawienie adapterów do systemów i standardów zewnętrznych np: -, nfs, pliki lokalne, http, smtp, ftp, jms, -, jdbc, edi, oracle, db Automatycznego i ręcznego restartu (migracji) instancji serwerów aplikacyjnych na innych fizycznych maszynach w razie awarii, wraz z przeniesieniem istotnych dla przetwarzania danych. Automatyczna rekonfiguracja serwerów aplikacyjnych po restarcie (zmiana adresu IP, itp.) Konfiguracji ochrony serwerów aplikacyjnych (i aplikacji) przed przeciążeniem. Wykonawca ma wybudowad interfejs integracji służący do wymiany danych pomiędzy Systemem MeZ, a Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych ( P1 ) Bazy danych MEZ.EDM.96 MEZ.EDM.97 MEZ.EDM.98 Wymagane jest zastosowanie relacyjnej baz danych min. ANSI SQL:1999 System bazy danych posiada funkcjonalnośd identyczną na 64-bitowe platformy Unix (Solaris dla procesorów SPARC/x86-64, IBM AIX), Intel Linux 32-bit i 64-bit, MS Windows 32-bit i 64bit. System bazy danych musi mied możliwości: Migrację struktur bazy danych i danych pomiędzy ww. platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego Wsparcie dla wielu ustawieo narodowych i wielu zestawów znaków (włącznie z Unicode) Przeniesienie migracji 8-bitowego zestawu znaków bazy danych (np MS Windows CP 1252, ISO ) do Unicode Brak formalnych ograniczeo na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy) Wsparcie dla procedur i funkcji składowanych w bazie danych Wsparcie dla języków proceduralnych, blokowych (umożliwiającym deklarowanie zmiennych wewnątrz bloku), oraz wspierających obsługę wyjątków Kompilację procedur składowanych w bazie danych do postaci kodu binarnego. Strona 39 z 233

40 98.8. Deklarowanie triggerów na poziomie instrukcji DML (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeo 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 triggerów powinien umożliwiad oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views) 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 logowao Określanie przywilejów użytkowników bazy danych 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) Nadawanie przywilejów za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W danej chwili użytkownik może mied aktywny dowolny podzbiór nadanych ról bazodanowych Wykonywanie i katalogowanie kopii bezpieczeostwa bezpośrednio przez serwer bazy danych. Zautomatyzowanego usuwania zbędnych kopii bezpieczeostwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki nadmiarowości backup'ów. Integracji z powszechnie stosowanymi systemami backupu (Legato, Veritas, Tivoli, Data Protector itd) Wykonywanie kopii bezpieczeostwa w trybie offline oraz w trybie online Zaimplementowanie polityki bezpieczeostwa regulującej dostęp do danych na poziomie pojedynczych wierszy w tabelach. Mechanizm ten powinien byd realizowany za pomocą mechanizmów silnika bazy danych i powinien byd przezroczysty dla aplikacji Rejestrowanie zdarzeo silnika bazy danych w czasie rzeczywistym. MEZ.EDM.99 Dodatkowo dla REDM regionalny system bazy danych powinien mied mechanizmy: Ochrona poufności i integralności informacji Kontrolny - wspomagającym bezpieczeostwo bazy danych Szyfrowanie informacji w bazie danych w obszarach wewnętrznym oraz sieciowym niezależny od aplikacji. MEZ.EDM.100 Silnik bazy danych powinien udostępniad możliwośd: Zrównoleglenia operacji SQL (zapytania, instrukcje DML, ładowanie danych, tworzenie indeksów, przenoszenie tabel/indeksów pomiędzy przestrzeniami danych) oraz procesów wykonywania kopii bezpieczeostwa bądź odtwarzania Wykonywanie niektórych operacji związanych z utrzymaniem bazy danych bez konieczności pozbawienia dostępu użytkowników do danych. W szczególności Strona 40 z 233

41 ATNA dotyczy to tworzenia / przebudowywania indeksów oraz reorganizacji bądź redefinicji tabel Zakładania/przebudowywania indeksów online bez konieczności odłączenia użytkowników operujących (zapytania, operacje insert, update, delete) na tabelach podlegających indeksowaniu Zarządzania przydziałem zasobów obliczeniowych dla użytkowników bazy danych (Resource Manager). MEZ.EDM.101 Moduł ATNA (Audit Trail and Node Authentication), służący do przechowywania pełnej informacji audytowej o procesach i zdarzeniach zachodzących w trakcie realizacji żądao do wszystkich systemów stanowiących SEDM (zarówno lokalną, jak i regionalną), należy traktowad jako uzupełnienie mechanizmów bezpieczeostwa i audytu zaimplementowanych we wszystkich systemach. MEZ.EDM.102 Obecnośd modułu ATNA jest zalecana, jednakże zasadnośd implementacji podlegad będzie weryfikacji w trakcie realizacji Projektu RREDM MEZ.EDM.103 RREDM przechowywad będzie scentralizowane informacje o miejscu składowania wszystkich EDM u PP. MEZ.EDM.104 RREDM jest systemem wspólnym dla wszystkich LREDM i udostępnia informacje o miejscu przechowywania EDM będących przedmiotem zapytao generowanych przez systemy EHR Viewer (lokalne oraz regionalny) oraz inne systemy, którym przyznane zostaną uprawnienia do korzystania z RREDM. MEZ.EDM.105 RREDM implementuje profil integracyjny XDS.b, w szczególności interfejs rejestracji dokumentu ITI-42 oraz interfejs zapytao ITI Repozytorium regionalne MEZ.EDM.106 RREDM pełni dwie istotne funkcje w Systemie: MEZ.EDM.107 Służy jako kopia bezpieczeostwa LREDM przechowywanej EDM. Pozwoli to na ograniczenie kosztów, związanych z utrzymaniem infrastruktury backup u w poszczególnych jednostkach leczniczych. MEZ.EDM.108 Magazynu danych wymienianych pomiędzy PP podłączonymi do RREDM. Wszystkie żądania o udostępnienie EDM realizowane będą w warstwie regionalnej przy wykorzystaniu kopii EDM przechowywanych w RREDM. Efektem takiej konfiguracji jest ograniczenie wymagao odnośnie infrastruktury sprzętowej oraz łącz internetowych w poszczególnych jednostkach leczniczych. Dodatkowo, takie rozwiązanie eliminuje ryzyko związane z przerwami w dostępności warstwy lokalnej systemu nawet jeśli w jednej (bądź więcej) jednostce leczniczej nastąpi przerwa w zasilaniu bądź w dostępie do sieci Internet, żądania udostępnienia EDM realizowane Strona 41 z 233

42 będą z poziomu repozytorium regionalnego, posadowionego w serwerowni warstwy regionalnej o wyższym poziomie dostępności EHR Viewer regionalny MEZ.EDM.109 Za pomocą regionalnej instancji systemu EHR Viewer, umożliwione jest przeglądanie, pobieranie i udostępnianie dokumentacji medycznej gromadzonej przez wszystkie podmioty lecznicze uczestniczące w Projekcie. Dostęp do RREDM zapewniony jest personelowi wszystkich jednostek leczniczych włączonych do warstwy regionalnej w Systemu MEZ Pojedyncze źródło identyfikacji pacjentów MEZ.EDM.110 Pojedyncze źródło identyfikacji pacjentów system klasy MPI, implementujący funkcjonalności PIX/PDQ profilu integracyjnego XDS.b stanowi centralny zbiór informacji o wszystkich pacjentach, na rzecz których świadczone będą usługi lecznicze we wszystkich podmiotach biorących udział w Projekcie i podłączonych do Systemu MEZ. MEZ.EDM.111 Wykorzystanie systemu MPI pozwoli na odseparowanie danych osobowych pacjenta (dane chronione) od danych medycznych (dane ściśle chronione), co z kolei wyeliminuje koniecznośd tworzenia dodatkowych magazynów danych osobowych u poszczególnych PP. Ponadto, takie rozwiązanie ma stanowid dodatkowe zabezpieczenie przed przechwyceniem danych chronionych w RREDM i LREDM. MEZ.EDM.112 EDM identyfikowana będzie jedynie za pomocą identyfikatora pacjenta, przechowywanego w odseparowanym logicznie systemie. Uzyskanie przez osoby niepowołane dostępu do jednego z tych systemów nie pozwoli na jednoznaczne określenie przynależności EDM do pacjenta Warstwa lokalna Systemu MEZ MEZ.EDM.113 Na warstwę lokalną systemu MEZ składają się następujące elementy: MEZ.EDM.114 System źródłowy (HIS, system pogotowia),, MEZ.EDM.115 SSI, MEZ.EDM.116 RIS, MEZ.EDM.117 LIS, MEZ.EDM.118 PACS, MEZ.EDM.119 Lokalna instancja systemu EHR Viewer, MEZ.EDM.120 LREDM (XDS.Repository), MEZ.EDM.121 Lokalna szyna danych, MEZ.EDM.122 Serwer buforujący. MEZ.EDM.123 W powyższym schemacie przyjęto założenie, że RIS, LIS i PACS stanowią osobne źródła EDM i podlegają dostosowaniu do przesyłania dokumentów do LREDM. W przypadku, gdy wspomniane systemy są zintegrowane z SSI, traktuje je się jako systemy transparentne, a jedynym źródłem EDM jest system SSI. Strona 42 z 233

43 MEZ.EDM.124 Lokalna szyna danych wymagana jest do wdrożenia w sytuacji, gdy RIS, LIS i PACS stanowią osobne źródła EDM. W przypadku integracji RIS, LIS i PACS z SSI, dopuszczalny jest model integracji w postaci point-to-point pomiędzy SSI a LREDM. MEZ.EDM.125 W celu zapewnienia ciągłości i spójności danych przesyłanych do warstwy regionalnej Sytemu MEZ, wskazane jest zastosowanie serwera buforowania SSI MEZ.EDM.126 SSI traktowany jest jako źródło powstawania EDM. Wymaga się, aby SSI przekazywał do LREDM dokumenty zgodne z szablonami, określonymi na etapie wdrożenia Projektu LREDM MEZ.EDM.127 LREDM służyd będzie gromadzeniu, przechowywaniu i przetwarzaniu EDM wytworzonej u PP. MEZ.EDM.128 Dodatkowo LREDM pełnid będzie rolę dodatkowego magazynu EDM przygotowanego do współpracy z regionalnymi i krajowymi systemami udostępniania i przesyłania EDM. Zgodnie z wymaganiami CSIOZ, repozytorium lokalne implementuje profil integracyjny XDS.b, w szczególności interfejs przekazywania i rejestracji ITI-41 oraz interfejs pobierania ITI-43. MEZ.EDM.129 W uzasadnionych i wyjątkowych przypadkach po zatwierdzeniu przez Partnera - dopuszcza się implementację LREDM w ramach infrastruktury serwerowej warstwy regionalnej Systemu, pod warunkiem zapewnienia minimum fizycznej i logicznej separacji od innych danych medycznych przechowywanych w systemach warstwy regionalnej oraz przy zapewnieniu nieograniczonego dostępu personelu administracyjnego właściciela danych Partnera, którego LREDM ma zostad posadowione w warstwie regionalnej Systemu EHR Viewer lokalny MEZ.EDM.130 Lokalna instancja systemu EHR Viewer pozwala uwierzytelnionym użytkownikom na wyszukiwanie i przeglądanie EDM, wytworzonej w ramach PP i przechowywanej w LREDM. Dostęp do lokalnej instancji systemu EHR Viewer ograniczony będzie wyłącznie do personelu PP. MEZ.EDM.131 Udostępnianie dokumentacji medycznej będzie ograniczone wyłącznie do personelu PP Mechanizmy integracji MEZ.EDM.132 SEDM wykorzystuje protokoły komunikacyjne, wyspecyfikowane przez międzynarodową organizację IHE (Integrating the Healthcare Enterprise). REDM w szczególności stworzony został do współpracy z innymi systemami przy wykorzystaniu profilu integracyjnego XDS.b (XDS.b Integration Profile). Strona 43 z 233

44 MEZ.EDM.133 Komunikacja z systemami źródłowymi odbywad się będzie za pośrednictwem lokalnej szyny danych (lub bezpośrednio, w przypadku zastosowania modelu integracji pointto-point) przy wykorzystaniu następujących interfejsów integracyjnych: ITI-41 Provide and Register Document Set podstawowy interfejs służący do przesyłania dokumentów medycznych do repozytorium (modułu XDS.Repository), ITI-42 Register Document Set interfejs wykorzystywany do aktualizacji rejestru dokumentów medycznych (modułu XDS.Registry), ITI-21 Patient Demographics Query interfejs wykorzystywany do wyszukiwania pacjentów w module MPI (Master Patient Index, pojedynczego źródła identyfikacji pacjentów). W ramach danych, zwracanych przez moduł MPI, znajdują się identyfikatory wykorzystywane przez oprogramowanie repozytorium EDM do poprawnego i jednoznacznego powiązania składowanego dokumentu medycznego z pacjentem, ITI-43 Retrieve Document interfejs służący do pobierania dokumentacji medycznej, składowanej w ramach modułu repozytorium EDM, ITI-8 Patient Identity Feed interfejs służący do aktualizacji systemu MPI w przypadku, gdy pacjent pojawia się po raz pierwszy w jednostce leczniczej wyposażonej w System Elektronicznej Dokumentacji Medycznej, ITI-18 Registry Stored Query interfejs służący do odpytania modułu XDS.Registry o zbiór dokumentów spełniający zadane kryteria wyszukiwania, MEZ.EDM.134 W procesie przesyłania dokumentu do REDM, wykorzystywane są interfejsy ITI-21, ITI-8 i ITI-41, MEZ.EDM.135 Interfejs ITI-42 wywoływany jest przez oprogramowanie pośredniczące szynę danych warstwy lokalnej. MEZ.EDM.136 W procesie przeszukiwania i pobierania EDM wykorzystywane są interfejsy ITI-21, ITI- 18 i ITI-43. MEZ.EDM.137 Wymaga się, by LREDM będące w posiadaniu poszczególnych jednostek biorących udział w Projekcie zostały dostosowane do wymogu stawianego powyżej. MEZ.EDM.138 Systemy źródłowy HIS, pogotowia, stanowiący źródło Elektronicznej Dokumentacji Medycznej musi zaimplementowad co najmniej mechanizmy eksportu do, eksportu do standardu hl7 cda L1,L2 lub L3( automatycznego lub na żądania) MEZ.EDM.139 Systemy jest traktowany jako źródło powstawania Elektronicznej Dokumentacji Medycznej (EDM) i musi przekazywad do EDM dokumenty zgodne z szablonami, określonymi na etapie wdrożenia niniejszego Projektu Backup MEZ.EDM.140 Rozwiązanie musi udostępniad możliwośd wykonania kopii bezpieczeostwa dla całej warstwy regionalnej RREDM. MEZ.EDM.141 Backup musi byd w innej lokalizacji (np. DATACENTER) niż RREDM. MEZ.EDM.142 Wymagania do DATACENTER: Strona 44 z 233

45 Brak dostępu do danych przez administratorów/użytkowników organizacji obsługującej Datacenter Co najmniej dwa niezależnie łącza sieciowe pomiędzy RREDM i DataCenter Awaryjne zasilanie Bezpieczeostwo (kontrola wejścia/wyjścia ) SLA 99% w skali miesiąca Usługi szyfrowania danych Mechanizmy wersjonowania i archiwizacji plików. 5.5 Szpitalny System Informatyczny SSI (HIS) Wymagania ogólne MEZ.SSI.1 Szpitalny System Informatyczny SSI dla poszczególnych PP został opisany w Załącznikach do SIWZ. MEZ.SSI.2 Oferowany SSI (HIS) ma byd zgodny z aktualnymi aktami prawnymi regulującymi organizację i działalnośd sektora usług medycznych i opieki zdrowotnej w kraju, w tym: 2.1. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadad urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 nr 100, poz.1024), 2.2. Ustawa z dnia 17 lutego 2005 o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U z 2014 pozycja 1114 z późniejszymi zmianami 2.3. Ustawa z dnia 26 czerwca 1974 r. Kodeks pracy (Dz. U. 2014, pozycja 1502 z późniejszymi zmianami) 2.4. Rozporządzenie Ministra Zdrowia z dnia 20 czerwca 2008 r. w sprawie zakresu niezbędnych informacji gromadzonych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeo ze środków publicznych (Dz.U pozycja 1447 z późniejszymi zmianami) 2.5. Rozporządzenie Ministra Zdrowia w sprawie rodzajów i zakresu dokumentacji medycznej w zakładach opieki zdrowotnej oraz sposobu jej przetwarzania z dnia 21 grudnia 2010, Dz.U. 2014, pozycja 177 z późniejszymi zmianami, 2.6. System musi spełniad wymogi wynikające z ustawy o Ochronie Danych Osobowych z 29 sierpnia 1997 roku oraz z Rozporządzenia MSWiA z 29 kwietnia 2004 roku, w szczególności system musi przechowywad informacje o: a. dacie wprowadzenia danych osobowych, b. użytkowniku wprowadzającego dane osobowe (identyfikator użytkownika), c. źródle danych (o ile dane nie pochodzą od osoby, której te dane dotyczą), d. odbiorcach danych którym dane osobowe zostały udostępnione, Strona 45 z 233

46 e. dacie i zakresie tego udostępnienia, f. dacie modyfikacji danych osobowych, g. użytkowniku modyfikującym dane (identyfikator użytkownika), 2.7. Zarządzenie nr 80/2013/DSOZ Prezesa NFZ z dn. 16 grudnia w sprawie określania warunków zawierania i realizacji umów w rodzaju rehabilitacja lecznicza, 2.8. Zarządzenie Prezesa NFZ nr 20/2006 z 18 maja 2006 zmieniające zarządzenie Nr 90/2005* Prezesa Narodowego Funduszu Zdrowia z dnia 17 października 2005 r. w sprawie przyjęcia Szczegółowych materiałów informacyjnych o przedmiocie postępowania w sprawie zawarcia umów o udzielanie świadczeo opieki zdrowotnej oraz o realizacji i finansowaniu umów o udzielanie świadczeo opieki zdrowotnej w rodzaju: rehabilitacja lecznicza, 2.9. Ustawa z dnia 29 września 1994 r. o rachunkowości (Dz. U. z 2013 roku, pozycja 330 z późniejszymi zmianami.), Zgodnośd z normą ISO 17025:2001 Ogólne wymagania dotyczące laboratoriów badawczych i wzorcujących, Zarządzenie Nr 103/2012/DSOZ Prezesa Narodowego Funduszu Zdrowia w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących świadczeo ambulatoryjnych i szpitalnych oraz Zarządzenie nr 14/2013/DSOZ Prezesa Narodowego Funduszu Zdrowia zmieniające zarządzenie w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących świadczeo ambulatoryjnych i szpitalnych Zarządzenie nr 6/2012/DSOZ Prezesa Narodowego Funduszu Zdrowia zarządzenie w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących deklaracji POZ/ KAOS, zwrotnych wyników weryfikacji deklaracji POZ/ KAOS, zwrotnego rozliczenia deklaracji POZ/ KAOS Zarządzenie nr 93/2012/DSOZ Prezesa Narodowego Funduszu Zdrowia w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących danych zbiorczych o świadczeniach udzielonych w ramach POZ Zarządzenie nr 3/2015/DSOZ Prezesa Narodowego Funduszu Zdrowia zmieniające zarządzenie zmieniające zarządzenie w sprawie określenia warunków zawierania i realizacji umów o udzielanie świadczeo w rodzaju: podstawowa opieka zdrowotna Zarządzenie nr 80/2014/DGL Prezesa Narodowego Funduszu Zdrowia w sprawie określenia warunków zawierania i realizacji umów w rodzaju leczenie szpitalne w zakresie chemioterapia Zarządzenie nr 59/2011/DGL Prezesa Narodowego Funduszu Zdrowia w sprawie określenia warunków zawierania i realizacji umów w rodzaju leczenie szpitalne w zakresie terapeutyczne programy zdrowotne Strona 46 z 233

47 2.17. Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010r w sprawie rodzajów i zakresu dokumentacji medycznej, oraz sposobu jej przetwarzania (tekst jednolity Dz.U r. poz 177 z zm.) Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz.U.z 2011 roku, numer 113, pozycja 657 z późniejszym zmianami), Rozporządzenie Ministra Zdrowia z dnia 28 marca 2013 r. w sprawie wymagao dla Systemu Informacji Medycznej Rozporządzenie Ministra Zdrowia z dnia 13 lipca 2012 r. w sprawie szczegółowego sposobu postępowania w sprawach przyjęcia oraz wypisania ze szpitala psychiatrycznego (Dz.U. z 2012 roku, pozycja 854), Rozporządzenie ministra zdrowia z 25 marca 2013 r. w sprawie klasyfikacji danych i systemu kodów w Systemie Informacji Medycznej (Dz. U. z 2013 roku, pozycja 473), Zarządzenie nr 79/2013/DSOZ Prezesa Narodowego Funduszu Zdrowia w sprawie określenia warunków zawierania i realizacji umów w rodzaju opieka psychiatryczna i leczenie uzależnieo ze wszystkimi późniejszymi zmianami ( m.in. Zarządzenie Nr 94/2013/DSOZ Prezesa Narodowego Funduszu Zdrowia zmieniające zarządzenie w sprawie określenia warunków zawierania i realizacji umów w rodzaju opieka psychiatryczna i leczenie uzależnieo, Zarządzenie Nr 78/2014/DSOZ Prezesa Narodowego Funduszu Zdrowia zmieniające zarządzenie w sprawie określenia warunków zawierania i realizacji umów w rodzaju opieka psychiatryczna i leczenie uzależnieo Zarządzenie Nr 89/2013/DSOZ Prezesa Narodowego Funduszu Zdrowia w sprawie określenia warunków zawierania i realizacji umów w rodzaju: leczenie szpitalne ze wszystkimi późniejszymi zmianami ( m.in. Zarządzenie Nr 1/2014/DSOZ, Zarządzenie Nr 4/2014/DSOZ, Zarządzenie Nr 23/2014/DSOZ, Zarządzenie Nr 81/2014/DSOZ, Zarządzenie Nr 88/2014/DSOZ) Zarządzenie Nr 27/2012/DGL Prezesa Narodowego Funduszu Zdrowia z dnia 10 maja 2012 r. w sprawie określenia warunków zawierania i realizacji umów w rodzaju leczenie szpitalne w zakresie programy zdrowotne (lekowe) ze wszystkimi późniejszymi zmianami (m.in. zarządzenie Nr 42/2012/DGL, zarządzenie Nr 66/2012/DG, zarządzenie Nr 95/2012/DGL, zarządzenie Nr 3/2013/DGL, zarządzenie Nr 8/2013/DGL, zarządzenie Nr 19/2013/DGL, zarządzenie Nr 29/2013, zarządzenie Nr 42/2013, zarządzenie Nr 48/2013, zarządzenie Nr 59/2013, zarządzenie 78/2013 oraz Zarządzenie Nr 5/2014/DGL Prezesa Narodowego Funduszu Zdrowia) Rozporządzenie Ministra Zdrowia z dnia 11 grudnia 2012 r. w sprawie wzorów oświadczeo o przysługującym świadczeniobiorcy prawie do świadczeo opieki zdrowotnej (Dz.U.2012, pozycja 1421), Strona 47 z 233

48 2.28. Ustawa o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych ( Dz. U 2004 nr 210 poz z późn. zm) Ustawa z dnia 19 sierpnia 1994 r. o ochronie zdrowia psychicznego (Dz. U. z 2001 roku, numer 231, pozycja 1375 z późniejszymi zmianami), ROZPORZĄDZENIE MINISTRA ZDROWIA z dnia 28 czerwca 2012 r. w sprawie sposobu stosowania i dokumentowania zastosowania przymusu bezpośredniego oraz dokonywania oceny zasadności jego zastosowania (Dz.U. z 2012 roku, pozycja 740), ROZPORZĄDZENIE MINISTRA ZDROWIA z dnia 18 kwietnia 2013 r. w sprawie zakresu niezbędnych informacji gromadzonych przez świadczeniodawców posiadających umowę z Narodowym Funduszem Zdrowia o udzielanie całodobowych lub całodziennych świadczeo zdrowotnych związanych z nabywaniem leków, środków spożywczych specjalnego przeznaczenia żywieniowego oraz wyrobów medycznych (Dz.U. z 2013 roku, pozycja 489), ROZPORZĄDZENIE MINISTRA ZDROWIA z dnia 20 października 2005 r. w sprawie zakresu zadao lekarza, pielęgniarki i położnej podstawowej opieki zdrowotnej (Dz.U. z 2005 roku, numer 214, pozycja 1816), ROZPORZĄDZENIE MINISTRA ZDROWIA z dnia 20 września 2012 r. w sprawie warunków, sposobu i trybu zaopatrywania pacjentów szpitala w znaki identyfikacyjne oraz sposobu postępowania w razie stwierdzenia ich braku (Dz.U. z 2012 roku, pozycja 1098), ROZPORZĄDZENIE MINISTRA ZDROWIA z dnia 19 kwietnia 2013 r. w sprawie minimalnej funkcjonalności dla systemów teleinformatycznych umożliwiających realizację usług związanych z prowadzeniem przez świadczeniodawców list oczekujących na udzielenie świadczenia zdrowotnego (Dz.U. z 2013 roku, pozycja 516), Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta z późniejszymi zmianami (Dz.U. numer 2012, pozycja 159 z późniejszymi zmianami), ROZPORZĄDZENIE MINISTRA ZDROWIA z dnia 30 lipca 2009 r. w sprawie prowadzenia depozytu w stacjonarnym zakładzie opieki zdrowotnej (Dz.U z 2009 roku, numer 129, pozycja 1068), Ustawa z dnia 29 czerwca 1995 r. o statystyce publicznej (Dz. U roku, pozycja 591 z późniejszymi zmianami) Możliwośd raportowania danych zgodnych z wymogami Systemu Statystyki Resortowej Ministra Zdrowia (SSRMZ) w szczególności sprawozdania: MZ-06, MZ-11, MZ-12, MZ-15, MZ-19, MZ-24, MZ-29, MZ-29A, MZ-30, MZ-88, MZ Ustawa z dnia 29 lipca 2005 r. o przeciwdziałaniu narkomanii (Dz. U. z 2012 roku, poz 124 z późniejszymi zmianami) Rozporządzenie Ministra Zdrowia z dnia 8 kwietnia 2014 r. w sprawie zajęd rehabilitacyjnych organizowanych w szpitalach psychiatrycznych (Dz.U poz. 522) Strona 48 z 233

49 2.40. Ustawa z dnia 26 lipca 1991 r. o podatku dochodowym od osób fizycznych (Dz. U. z 2012 roku, numer 361 z późniejszymi zmianami) Wymogi dotyczące interoperacyjności lub migracji dla oferowanego SSI. MEZ.SSI.3 Wykonawca zobowiązuje się dostarczyd PP określone funkcjonalności SSI, poprzez dostawę nowego rozwiązania lub zmodernizowanie i rozbudowanie istniejącego w taki sposób, aby w jak najszerszym zakresie zostały zaspokojone obecne i przyszłe potrzeby PP. Koniecznym jest równoczesne zachowanie pełnej wzajemnej interoperacyjności nowo wdrażanych modułów/grup funkcjonalności, a także w przypadku rozbudowy, pełnej interoperacyjności z modułami/grupami funkcjonalności już funkcjonującymi u PP. MEZ.SSI.4 Dane jakie powinny byd przeniesione do nowego systemu informatycznego powinny obejmowad minimum: 4.1. dane o pacjentach i ich opiekunach, 4.2. słownik lekarzy (pracujących i kierujących), 4.3. słownik instytucji kierujących, 4.4. dane o płatnikach i umowach, 4.5. dane statystyczne rozliczonych pacjentów do NFZ, 4.6. kolejki oczekujących. MEZ.SSI.5 Przeniesione dane muszą umożliwid wygenerowanie prawidłowych (zgodnych z opublikowanymi przez NFZ plikami walidującymi) komunikatów wymiany danych z NFZ dotyczących wszystkich umów na świadczenia w bieżącym roku rozliczeniowym i roku następnym. MEZ.SSI.6 Dane zaimportowane do SSI z aktualnie użytkowanego oprogramowania muszą byd spójne z nowo wprowadzanymi, edytowalne, podlegające analizie i spełniające warunki walidacji dla określonych typów pól. MEZ.SSI.7 Pełną odpowiedzialnośd za przeniesienie danych ponosi Wykonawca. MEZ.SSI.8 Zamawiający wymaga także, aby wszystkie posiadane lub dostarczane systemy zewnętrzne integrowały się z modernizowanym lub oferowanym systemem informatycznym. Pełną odpowiedzialnośd za integracje z systemami zewnętrznymi ponosi Wykonawca. MEZ.SSI.9 Wymogi dotyczące środowiska bazodanowego dla oferowanego SSI Wraz z SSI Wykonawca dostarczy relacyjną bazę danych (RDBMS), która będzie pełnid rolę środowiska bazodanowego dla SSI. Oferowany RDBMS powinien zapewnid mechanizmy wysokiej dostępności (HA) co najmniej pracę w trybie klastra lub w trybie replikacji bazy danych Wykonawca dostarczy licencje na relacyjną bazę danych (RDBMS) bezterminowe, typu per processor Nie dopuszcza się licencji czasowych Licencje powyższe muszą zawierad min. 1 rok wsparcia technicznego producenta Dostarczone licencje na RDBMS muszą umożliwiad Zamawiającemu wykorzystanie jego pełnej funkcjonalności w innych aplikacjach będących aktualnie bądź w przyszłości w posiadaniu Zamawiającego. Strona 49 z 233

50 9.6. Dostarczany RDBMS musi byd zgodny z platformami serwerowymi będącymi przedmiotem tego zamówienia Liczba licencji na RDBMS powinna zapewnid optymalną (przewidzianą przez producenta) wydajnośd dostarczanego oprogramowania w poszczególnych lokalizacjach w okresie 5-ciu lat od daty odbioru koocowego prac Wykonawcy. MEZ.SSI.10 Wykonawca zobowiązuje się dostarczyd PP określone funkcjonalności Szpitalnego Systemu Informatycznego, przy założeniu, że wszystkie moduły dostarczane w ramach realizacji przedmiotu zamówienia, posiadad będą licencję otwartą - bez limitu użytkowników korzystających z modułu. MEZ.SSI.11 Wykonawca w przypadku rozbudowy lub wymiany Szpitalnego Sytemu Informatycznego obecnie użytkowanego przez Partnerów Projektu, zobowiązany jest zachowad pełną, istniejącą obecnie integrację SSI z urządzeniami zewnętrznymi, a także oprogramowaniem, które jest użytkowane przez PP a nie podlega rozbudowie lub wymianie w ramach niniejszego projektu. MEZ.SSI.12 Wykonawca w przypadku rozbudowy lub wymiany Szpitalnego Sytemu Informatycznego obecnie użytkowanego przez Partnerów Projektu, zobowiązany jest zapewnid wzajemną integrację wszystkich dostarczanych modułów SSI, oraz systemów, w zakresie funkcjonalnie nie mniejszym niż obecnie istniejący. 5.6 Centrum Analiz Statystyczno Ekonomicznych (CASE) Architektura ogólna MEZ.CASE.1 Jednym z celów Projektu MeZ jest sprawowanie pełnego i rzetelnego nadzoru właścicielskiego poprzez zbieranie jednolitych danych z systemów informatycznych Partnerów Projektu, które muszą spełniad zasadę interoperacyjności i komplementarności. Cel ten zostanie osiągnięty poprzez zakup i wdrożenie odpowiedniego programu zarządczego klasy Business Intelligence CASE umożliwiającego tworzenie opracowao statystycznych na potrzeby nadzoru merytorycznego sprawowanego przez WM nad Podmiotami leczniczymi, dla których WM jest organem tworzącym lub właścicielem. MEZ.CASE.2 CASE powinien uwzględnid i wykorzystywad rozwiązania integrujące, w szczególności szyny do zbierania jednolitych danych z systemów informatycznych Partnerów Projektu lub w ramach regionalnego repozytorium. MEZ.CASE.3 Ponieważ zakres pozyskiwanych i gromadzonych danych wybiega ponad wymagania NFZ, MZ i GUS, warunkiem sprawnego i bezbłędnego sumowania informacji dla celów statystycznych jest znormalizowanie formularzy dla wszystkich żądanych danych oraz harmonogramu ich aktualizacji. MEZ.CASE.4 CASE jest systemem zarządczym umożliwiającym tworzenie opracowao statystycznych na potrzeby nadzoru merytorycznego WM nad PP. MEZ.CASE.5 CASE powinien uwzględnid i wykorzystywad rozwiązania integrujące, w szczególności szyny integracyjnej i WAN MEZ do zbierania jednolitych danych z SSI/SEDM u PP. Strona 50 z 233

51 Rysunek 4 Ogólna architektura CASE MEZ.CASE.6 CASE składa się z następujących komponentów: 6.1. Oprogramowanie typu Business Intelligence (BI) do tworzenia raportów, analiz, wskaźników, symulacji i formularzy, 6.2. Hurtownia danych, 6.3. Moduł importu danych źródłowych, 6.4. Moduł do generowania szablonów formularzy elektronicznych Tryb współpracy CASE z Oprogramowaniem Partnerów Projektu (PP) MEZ.CASE.7 MEZ.CASE.8 MEZ.CASE.9 MEZ.CASE.10 MEZ.CASE.11 MEZ.CASE.12 CASE (warstwa regionalna) wraz ze sprzętem zostanie zainstalowane w UM. Zamawiający wymaga na system BI licencji wieczystej, zapewniającej dostęp dla nieograniczonej liczby użytkowników, z dostępem dla wielu użytkowników jednocześnie. Zbiorcza statystyka medyczna będzie domeną Urzędu Marszałkowskiego. Co do zasady, każdy PP będzie miał w CASE dostęp tylko do swoich danych i będzie w tym zakresie mógł korzystad z narzędzi udostępnionych przez system BI. Dostęp do danych i raportów zbiorczych będzie możliwy dla PP wyłącznie za zgodą UM. System BI umożliwi autoryzowany dostęp do raportów i zestawieo przez przeglądarkę internetową. Dane przekazywane do CASE mogą byd opatrywane podpisem elektronicznym oraz znacznikiem czasu. Strona 51 z 233