Załącznik 4 do Studium Wykonalności

Transkrypt

1 Załącznik 4 do Studium Wykonalności Koncepcja rozwiązania Pomorskie e-zdrowie Wersja 4.02 Data: 28 grudnia 2016 r. disi@pomorskie.eu, Strona 1 z 212

2 Spis treści 1 Definicje, akronimy, skróty Założenia projektowe Architektura rozwiązania PeZ i organizacja utrzymania Warstwy architektury PeZ Założenia architektury PeZ Opis architektury biznesowej PeZ Opis architektury informacji PeZ Opis architektury aplikacji PeZ Architektura GCPD/DR Architektura rozwiązania PeZ dla podmiotów klasy E Architektura rozwiązania PeZ dla podmiotów klasy C i D Architektura rozwiązania PeZ dla podmiotów klasy A i B Sieci teleinformatyczne, sieci zasilania gwarantowanego, dostęp do Internetu PL i SWP Obszar okablowania strukturalnego Obszar sieci zasilania gwarantowanego Obszar sieci WLAN Obszar sieci LAN Założenia i analiza istniejących rozwiązań w PL Koncepcja sieci teleinformatycznych dla PL klasy E Koncepcja sieci teleinformatycznych dla PL typu D Koncepcja sieci teleinformatycznych dla PL typu C Koncepcja sieci teleinformatycznych dla PL B Koncepcja sieci teleinformatycznych dla GCPD i DR Obszar sieci WAN PeZ disi@pomorskie.eu, Strona 2 z 212

3 4.6 Obszar sieci SAN Obszar sieci Internet Analiza w zakresie sprzętu informatycznego - SWP Koncepcja architektury infrastruktury serwerowej i przestrzeni dyskowej w GCPD Architektura infrastruktury dla PL bez infrastruktury serwerowej (klasa E) Architektura infrastruktury dla PL posiadającego pojedynczą małą serwerownię (klasa D - pogotowia) Architektura infrastruktury dla PL posiadającego pojedynczą małą serwerownię (klasa C) Architektura infrastruktury dla PL mających własną infrastrukturę dla jednej dużej serwerowni (typ B ) Architektura infrastruktury dla PL mających własną infrastrukturę minimum dwóch serwerowni (typ A) Architektura bezpieczeństwa infrastruktury i systemy zarządzania dla GCPD i PL Oprogramowanie dziedzinowe i specjalistyczne Proponowane podejście do realizacji HIS HIS w podmiotach leczniczych klasy E HIS w podmiotach leczniczych klasy D HIS w podmiotach leczniczych klasy C HIS w podmiotach leczniczych klasy A i B ERP ERP w podmiotach leczniczych klasy E ERP w podmiotach leczniczych klasy D ERP w podmiotach leczniczych klasy A, B i C RCP PACS PACS w podmiotach leczniczych klasy E disi@pomorskie.eu, Strona 3 z 212

4 6.4.2 PACS w podmiotach leczniczych klasy D PACS w podmiotach leczniczych klasy A, B i C RIS RIS w podmiotach leczniczych klasy E RIS w podmiotach leczniczych klasy D RIS w podmiotach leczniczych klasy A, B i C LIS LIS w podmiotach leczniczych klasy E LIS w podmiotach leczniczych klasy D LIS w podmiotach leczniczych klasy A, B i C EOD Lokalny EDM Koncepcja rozwiązania portalowego Ogólna koncepcja Obszary funkcjonalne portalu Wymagania dotyczące bezpieczeństwa i zarządzania użytkownikami Propozycja elementów składowych portalu Mapa portalu Wykaz elementów stałych (statycznych) portalu Architektura systemu Technologia regionalnego portalu informacyjnego Rozwiązania regionalne z zakresu e-zdrowia Warstwa biznesowa Warstwa aplikacji Warstwa danych Baza danych lokalnego EDM Baza danych regionalnego EDM disi@pomorskie.eu, Strona 4 z 212

5 7.3.3 Baza danych RDM Koncepcja w zakresie regionalnego systemu informatycznego klasy BI Regionalny system BI Propozycja architektury rozwiązania klasy BI Koncepcja Systemu Oceny Jakości Proponowana architektura systemu Sposoby gromadzenia i analizy danych wraz z raportowaniem Integracja z portalem e-zdrowie Wymagania techniczne systemu oraz rozwiązania IT Koncepcja Systemu Zdarzeń Niepożądanych Proponowana architektura systemu Sposoby gromadzenia i analizy danych wraz z raportowaniem Integracja z portalem e-zdrowie Wymagania techniczne systemu oraz rozwiązania IT Koncepcja Systemu Obsługi Ratownictwa Drogowego Założenia dla koncepcji Systemu Obsługi Ratownictwa Drogowego Sposoby komunikacji ze środowiskiem PeZ Architektura systemu i współpraca z portalem Koncepcja platformy e-usług Założenia i koncepcja dla systemu e-informacja Założenia i koncepcja dla systemu e-koordynacja Opieki medycznej Założenia i koncepcja dla e-opieka nad osobami chorymi na cukrzycę Założenia i koncepcja dla e-opieka nad osobami chorymi na POChP Założenia i koncepcja dla systemu e-koordynacja Opieki Nad Osobami Starszymi Założenia i koncepcja dla systemu e-rejestracja Założenia i koncepcja dla systemu Platformy e-radiologii disi@pomorskie.eu, Strona 5 z 212

6 7.8.8 Założenia i koncepcja dla systemu Obsługi elektronicznych zleceń pomiędzy świadczeniobiorcami Założenia i koncepcja dla systemu Obsługi Nadzoru Właścicielskiego Założenia i koncepcja dla systemu Regionalnego e-rejestru Danych Ratunkowych - RRDR Założenia i koncepcja dla systemu Wsparcia Polityki Zdrowotnej Założenia i koncepcja dla Wymiany Dokumentacji Medycznej Długoterminowe Archiwa Danych Wymiana dokumentacji medycznej dla podmiotów leczniczych z województwa pomorskiego nie będących uczestnikami projektu Koncepcja systemu gromadzenia i archiwizacji danych z poszczególnych systemów informatycznych znajdujących się w PL Założenia dla koncepcji systemu gromadzenia i archiwizacji danych Ilość danych wraz z prognozami pięcioletniego przyrostu Funkcjonalności systemu gromadzenia i archiwizacji danych dla PL Funkcjonalności systemu kopii zapasowych (backupu) Dla PL które zostały zakwalifikowane jako Mały Podmiot Leczniczy Dla PL które zostały zakwalifikowane do klasy średnich i dużych - A, B, C i D Rola GCPD Przykładowa procedura dla kopii zapasowych danych i przywracania Koncepcja realizacji szkoleń w ramach projektu PeZ disi@pomorskie.eu, Strona 6 z 212

7 Wykaz tabel i rysunków Tabela 1: Wykaz definicji i skrótów użytych w projekcie Tabela 2: Wykaz skrótów nazw podmiotów leczniczych i ich przyporządkowanie Tabela 3 Minimalne grupy funkcjonalności HIS dla podmiotów leczniczych klasy E Tabela 4: Minimalne grupy funkcjonalności HIS dla podmiotów leczniczych klasy D Tabela 5 Minimalne grupy funkcjonalności ERP dla podmiotów leczniczych klasy E Tabela 6: Minimalne grupy funkcjonalności ERP dla podmiotów leczniczych klasy D Tabela 7: PL klasy E, które powinny posiadać system PACS Tabela 8: PL klasy A, B i C, które powinny posiadać system PACS Tabela 9: PL klasy E, które powinny posiadać system RIS Tabela 10: PL klasy A, B i C które powinny posiadać system RIS Tabela 11: PL klasy A, B i C, które powinny posiadać system LIS Tabela 12: Kategorie użytkowników Portalu wraz z ich skróconymi uprawnieniami Tabela 13: Charakterystyka elementów portalu Tabela 14: Główni interesariusze i kluczowe interakcje w obszarze PRIM Tabela 15: Funkcjonalności i najważniejsze aspekty działania Systemu Oceny Jakości Tabela 16: Funkcjonalności i najważniejsze aspekty działania Systemu Zdarzeń Niepożądanych Tabela 17 Definicja kopii bezpieczeństwa i archiwizacji danych Tabela 18 Wolumen danych w podmiotach leczniczych z podziałem na backup i archiwizację disi@pomorskie.eu, Strona 7 z 212

8 Rysunek 2-1: Model logiczny rozwiązania PeZ Rysunek 2-2: Schemat ideowy komunikacji szyny danych Rysunek 3-1: Schemat architektury w modelu TOGAF Rysunek 3-2: Architektura biznesowa PeZ Rysunek 3-3: Ogólny opis architektury rozwiązania PeZ Rysunek 3-4: Architektura GCPD Rysunek 4-1: Schemat systemu zasilania gwarantowanego obiektu szpitalnego Rysunek 4-2: Koncepcja konfiguracji WLAN w PL Rysunek 4-3: Koncepcja sieci LAN w PL Rysunek 4-4: Koncepcja sieci teleinformatycznych dla podmiotów medycznych typu E Rysunek 4-5: Koncepcja sieci teleinformatycznych dla podmiotów medycznych typu D Rysunek 5-1: Wysokopoziomowa architektura aplikacji w PeZ Rysunek 5-2 Schemat ideowy architektury placówki GCPD w projekcie PeZ Rysunek 5-3: Koncepcja architektury infrastruktury dla podmiotu klasy E Rysunek 6-1: Struktura zintegrowanego systemu informatycznego wraz z powiązaniami Rysunek 6-2: Diagram typowych aplikacji szpitalnych Rysunek 6-3: Obieg informacji pomiędzy HIS/PACS/RIS Rysunek 7-1: Główni interesariusze i kluczowe interakcje w obszarze PRIM Rysunek 7-2: PRIM, warstwa aplikacji Rysunek 7-3 Komponenty logiczne warstwy integracyjnej Rysunek 7-4: PRIM, architektura danych Rysunek 7-5: PRIM, schemat integracji i wymiany danych Rysunek 7-6: Schemat architektury Systemu Oceny Jakości Rysunek 7-7: Architektura Systemu Zdarzeń Niepożądanych Rysunek 7-8: Schemat archiwizacji w Lokalizacji 1 (Małe PL) Rysunek 7-9. Schemat systemu archiwizacji i backupu w podmiotach klasy A, B,C i D disi@pomorskie.eu, Strona 8 z 212

9 1 Definicje, akronimy, skróty Wykaz użytych w dokumencie definicji i skrótów wyszczególniony został w tabeli poniżej. Skrót/definicja Wyjaśnienie Kategoria okablowania strukturalnego miedzianego zgodnego z normami TIA ANSI/ 5e 6A AP AV BI CA TIA//EIA-568-B.2 Commercial Building Telecommunications Standard Part 2: Balanced Twisted pair Cabling Components, 2001, zapewniająca prawidłowe połączenia w sieciach do 1GE (zgodnie z ISO kat. D) Kategoria okablowania strukturalnego miedzianego zgodnego z normami TIA ANSI/TIA//EIA-568-B.2.10 Commercial Building Telecommunications Standard Part 2: Addendum 10: Transmission Performance Specification for 4 Pair 100 Ohm Augmented Category 6 cabling draft, zapewniająca prawidłowe połączenia w sieciach 10GE (zgodnie z ISO kat EA) Access Point punkt dostępu do bezprzewodowej sieci komputerowej Oprogramowanie narzędziowe, przeznaczone do zabezpieczania stacji roboczych przed szkodliwym oprogramowaniem Business Intelligence oprogramowanie aplikacyjne umożliwiającym umożliwiające tworzenie opracowań statystycznych z działalności podmiotu Certificate Authority centrum certyfikacji jako zespół środków organizacyjnotechnicznych, wystawiające certyfikaty cyfrowe dla potrzeb autoryzacji uprawnień dostępu do systemów informatycznych CIFS Common Internet File System protokół komputerowych służący udostępnianiu zasobów CLOUD CSIOZ DCS Chmura odmiejscowiona struktura obliczeniowa lub niezawodnościowa umieszczona w różnych ośrodkach przetwarzania danych Centrum Systemów Informatycznych Ochrony Zdrowia państwowa jednostka budżetowa, powołana przez Ministra Zdrowia, odpowiadająca za monitorowanie planowanych, budowanych i prowadzonych systemów teleinformatycznych za poziomie centralnym i regionalnym Database Connection Services - usługi powiązań bazodanowych disi@pomorskie.eu, Strona 9 z 212

10 Skrót/definicja DHCP DICOM DMZ DNS DR DWH EDM eidas EOD epuap ERP ESD FC GCPD HIS HL7 Wyjaśnienie Dynamic Host Configuration Protocol - protokół dynamicznego konfigurowania hostów Digital Imaging and Communications in Medicine obrazowanie cyfrowe i wymiana obrazów w medycynie zgodnie z strategiami od WG-01 do WG-30 Demilitarized zone, strefa zdemilitaryzowana bądź ograniczonego zaufania jest to wydzielany na zaporze sieciowej (ang. Firewall/UTM) obszar sieci komputerowej nienależący ani do sieci wewnętrznej (tj. tej chronionej przez zaporę), ani do sieci zewnętrznej (tej przed zaporą; na ogół jest to Internet). Domain Name System - system nazw domenowych Disaster Recovery zapasowe centrum danych Data warehouse hurtownia danych Elektroniczna Dokumentacja Medyczna rozporządzenie Parlamentu Europejskiego i Rady (UE) w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym Elektroniczny Obieg Dokumentów Elektroniczna Platforma Usług Administracji Publicznej Enterprise Resource Planning tzw. szara część systemu HIS lub system rachunkowo księgowy Elektroniczny System Dostępu Fibre Channel - standard magistrali szeregowej definiujący wielowarstwową architekturę, która służy do przesyłania danych przez sieć. Główne Centrum Przetwarzania Danych Hospital Information System część tzw. biała informatycznego systemu medycznego Health Level Seven - standard elektronicznej wymiany informacji w środowiskach medycznych disi@pomorskie.eu, Strona 10 z 212

11 Skrót/definicja IPS iscsi LAN LDAP LIS MAN MDF MOF MSWiA MVPN/MPLS VPN NAS NFS NFZ P1 Wyjaśnienie Intrusion Prevention System systemy wykrywania i zapobiegania włamaniom Internet Small Computer Systems Interface - protokół iscsi umożliwia budowę systemów pamięci masowych SAN (ang. Storage Area Network) przy zastosowaniu macierzy dyskowych SCSI i sieci Ethernet (protokół TCP/IP) Local Area Network lokalna sieć komputerowa Lightweight Directory Access Protocol - protokół przeznaczony do korzystania z usług katalogowych Laboratory Information System medyczny system laboratoryjny Metropolitan Area Network miejska sieć komputerowa Main Distribution Frame - Punkt Dystrybucyjny sieci LAN (Main Distribution Frame) Miejski Ośrodek Finansowania Ministerstwo Spraw Wewnętrznych i Administracji Wirtualna Sieć Prywatna w sieci MPLS Network Attached Storage - technologia umożliwiająca podłączenie zasobów pamięci dyskowych bezpośrednio do sieci komputerowej Network File System oparty na UDP lub TCP protokół zdalnego udostępniania systemu plików Narodowy Fundusz Zdrowia Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych PACS PeZ Picture Archiving and Communication System - komunikacji Skrót do nazwy Projektu Pomorskie e-zdrowie System archiwizacji obrazu i PKI (CA) PL PL01 Public Key Infrastructure (Certification Authority) - Infrastruktura klucza publicznego Podmiot Leczniczy jednostka medyczna biorąca udział w projekcie PEZPeZ Wojewódzki Szpital Psychiatryczny im. prof. Tadeusza Bilikiewicza w Gdańsku disi@pomorskie.eu, Strona 11 z 212

12 Skrót/definicja PL02 PL05 PL06 PL07 PL08 PL10 PL11 PL12.1 PL14 PL16 PL17 PL18 PL19.2 PL PL PL PoE POZ PRIM RDBMS RDM RIS Wyjaśnienie Stacja Pogotowia Ratunkowego w Gdańsku Wojewódzki Zespół Reumatologiczny im. dr Jadwigi Titz-Kosko Centrum Zdrowia Psychicznego w Słupsku Wojewódzki Szpital Specjalistyczny im. Janusza Korczaka w Słupsku Sp. z o.o. Szpital dla Nerwowo i Psychicznie Chorych im. St. Kryzana w Starogardzie Gdańskim Wojewódzki Ośrodek Terapii Uzależnień w Gdańsku Stacja Pogotowia Ratunkowego w Słupsku COPERNICUS PL Sp. z o.o. Szpital Dziecięcy Polanki im. Macieja Płażyńskiego w Gdańsku Sp. z o.o. Szpital Specjalistyczny w Prabutach Sp. z o.o. Przemysłowy Zespół Opieki Zdrowotnej Sp. z o.o. Szpital Specjalistyczny w Kościerzynie Sp. z o.o. Szpitale Wojewódzkie w Gdyni Sp. z o.o. połączone z PL oraz PL Szpitale Wojewódzkie w Gdyni Sp. z o.o. Szpital Specjalistyczny im. F. Ceynowy Sp. z o.o. Pomorskie Centrum Chorób Zakaźnych i Gruźlicy Sp. z o.o. Power over Ethernet - technologia przesyłu energii elektrycznej za pomocą skrętki do urządzeń peryferyjnych będących elementami sieci Ethernet Podstawowa Opieka Zdrowotna Pomorski Repozytorium Informacji Medycznej Relational Database Management System - System zarządzania relacyjną bazą danych Rejestr Dokumentacji Medycznej Radiology Information System - Radiologiczny System Informacyjny disi@pomorskie.eu, Strona 12 z 212

13 Skrót/definicja SaaS SAD SAN SAS SDP Serwer AC SKD SOA SOJ SOR SR lub SOR SSID SSO SWP SWD PRM System, System PeZ Systemy dziedzinowe Systemy regionalne Systemy specjalistyczne Systemy wspierające SZN Wyjaśnienie Software as a Service oprogramowanie udostępniane jako usługa System Archiwizacji Danych Storage Area Network - sieć pamięci masowej Serial Attached SCSI - interfejs komunikacyjny, będący następcą SCSI System dostępu do pomieszczeń Serwer certyfikacyjny System Kontroli Dostępu ang. Service Oriented Architecture architektura zorientowana na usługi System Oceny Jakości Szpitalny Oddział Ratunkowy System Ratownictwa lub System Obsługi Ratownictwa service set identifier - identyfikator sieci WLAN Single sign-on system pojedynczego logowania Samorząd Województwa Pomorskiego System Wsparcia Dowodzenia Państwowego Ratownictwa Medycznego System teleinformatyczny powstały w wyniku realizacji Projektu PeZ Medyczne systemy informatyczne funkcjonujące w obszarze ochrony zdrowia Systemy informatyczne funkcjonujące na poziomie regionalnym i umożliwiające świadczenie usług elektronicznych dla pacjentów (informacyjne oraz interakcyjne), a także umożliwiające świadczenie usług na rzecz uczestników projektu PeZ Systemy informatyczne wspierające działalność podmiotu medycznego w części szarej Systemy informatyczne z zakresu zarządzania infrastrukturą IT oraz wspierające działanie podmiotu na poziomie infrastruktury teleinformatycznej System Zdarzeń Niepożądanych disi@pomorskie.eu, Strona 13 z 212

14 Skrót/definicja UK UMWP UTM VLAN VPN WAN WAN PeZ WLAN Wyjaśnienie Usługa Katalogowa Urząd Marszałkowski Województwa Pomorskiego Unified Threat Management - wielofunkcyjne zapory sieciowe zintegrowane w postaci jednego urządzenia i/lub oprogramowania Virtual Local Area Network - sieć komputerowa wydzielona logicznie w ramach innej, większej sieci fizycznej Virtual Private Network - Wirtualna Sieć Prywatna Wide Area Network Sieć rozległa Wide Area Network -. Ddedykowana sieć rozległa stworzona na potrzeby projektu Pomorskie ezdrowie Wireless Local Area Network bezprzewododowa lokalna sieć komputerowa Tabela 1: Wykaz definicji i skrótów użytych w projekcie disi@pomorskie.eu, Strona 14 z 212

15 2 Założenia projektowe Klauzula generalna: W zależności od uzasadnionych i uzgodnionych potrzeb uczestników Projektu PeZ wymagania Koncepcji Techniczno-Technologicznej mogą w przyszłości ulec zmianie/modyfikacji/doprecyzowaniu w specyfikacji opisu przedmiotu zamówienia dla poszczególnej kategorii zamówienia. Rekomendowany model logiczny rozwiązania Pomorskie e-zdrowie został przedstawiony na poniższym schemacie (Rysunek 2-1): disi@pomorskie.eu, Strona 15 z 212

16 Rysunek 2-1: Model logiczny rozwiązania PeZ Model ten opiera się na założeniu, że przyszłe rozwiązanie będzie bazowało na dwóch podstawowych komponentach technologicznych tj. warstwie regionalnej oraz warstwie lokalnej. Kluczowym komponentem warstwy regionalnej w zakresie komunikacji pomiędzy warstwą lokalną a otoczeniem zewnętrznym jest szyna danych zgodnie z paradygmatem SOA (ang. Service Oriented disi@pomorskie.eu, Strona 16 z 212

17 Architecture architektura zorientowana na usługi), która pozwalać będzie na integrację wdrażanych w ramach projektu aplikacji/systemów poprzez usługi (zdefiniowane interfejsy) udostępniane przez nie a także wymianę informacji oraz integrację z systemami zewnętrznymi. Zakładany jest model centralny szyny danych, który stanowić będzie model połączeń pomiędzy serwisami z systemów lokalnych oraz systemów zewnętrznych (w tym np. Platform centralnych np. P1, epuap a także docelowo również systemów w placówkach ZOZ, które będą mogły być podłączone do systemu PeZ). Szczegółowe wymagania funkcjonalne, pozafunkcjonalne oraz integracyjne dla komponentu zostaną zdefiniowane na etapie przygotowywania OPZ. Schemat ideowy został przedstawiony poniżej. Rysunek 2-2: Schemat ideowy komunikacji szyny danych disi@pomorskie.eu, Strona 17 z 212

18 Warstwa regionalna rozwiązania będzie odpowiedzialna z jednej strony za świadczenie usług IT dla PL uczestniczących w projekcie, z drugiej zaś strony za udostępnienie usług medycznych drogą elektroniczną pacjentom PL. Warstwa lokalna rozwiązania będzie odpowiedzialna za świadczenie usług IT dla PL, w którym została zainstalowana lub na rzecz, którego została skonfigurowana w zewnętrznym ośrodku przetwarzania danych. Założenia projektowe: Poniżej przedstawiono podstawowe założenia dotyczące projektu Pomorskie e-zdrowie. 1. Realizacja celów strategicznych poprzez udostępnienie e-usług Celem głównym projektu Pomorskie e-zdrowie (PeZ) jest poprawa jakości i dostępności usług medycznych świadczonych na obszarze województwa pomorskiego oraz poprawa efektywności pomorskich podmiotów leczniczych, dla których Samorząd Województwa Pomorskiego jest organem tworzącym. Cel ten zostanie osiągnięty poprzez wdrożenie i udostępnienie na obszarze Województwa Pomorskiego regionalnych elektronicznych usług e-usług dedykowanych dla obywateli województwa, podmiotów leczniczych zlokalizowanych w województwie oraz Samorządu Województwa Pomorskiego. 2. Doposażenie w infrastrukturę sprzętowo-sieciową oraz oprogramowanie Aby mogły zostać wdrożone i uruchomione e-usługi, infrastruktura oraz systemy informatyczne podmiotów leczniczych muszą spełniać określone wymagania techniczne, technologiczne i funkcjonalne narzucane przez projektowane rozwiązanie. W związku z tym wymagana jest rozbudowa i modernizacja systemów informatycznych (wraz z niezbędną infrastrukturą) w pomorskich podmiotach leczniczych biorących udział w projekcie. Dodatkowo, wdrożenie e-usług wymusza konieczność utworzenia na szczeblu regionalnym dedykowanego centrum przetwarzania danych, którego zadaniem jest między innymi dostarczanie funkcjonalności tych usług. Do sprawnego działania centrum wymagane jest posiadanie na poziomie regionalnym odpowiednio wydajnej infrastruktury sieci teleinformatycznej. disi@pomorskie.eu, Strona 18 z 212

19 3. Dostosowanie zakresu funkcjonalnego projektu do potrzeb poszczególnych odbiorców W ramach projektu PeZ można wyróżnić trzy grupy interesariuszy: pacjenci, pracownicy podmiotów medycznych i pracownicy Samorządu Województwa Pomorskiego. Wymienione grupy odbiorców są zaangażowane w różne procesy biznesowe, a co za tym idzie posiadają różne potrzeby. Również w przypadku uczestniczących w projekcie PL można wskazać znaczne różnice w zakresie powierzonych i realizowanych zadań, liczbę leczonych pacjentów i wielkości placówki. Zróżnicowane możliwości finansowe i personalne oraz różnice w aktualnie posiadanym wyposażeniu w sprzęt medyczny, informatyczny oraz infrastrukturę sieciową wymuszają kategoryzację podmiotów i indywidualne podejście do każdej z grup. Rozwiązanie jest dopasowane w zakresie funkcjonalności zarówno do potrzeb odrębnych grup interesariuszy, jak i do różnych kategorii podmiotów leczniczych. 4. Podział rozwiązania na warstwy W ramach projektu rozwiązanie zostanie podzielone na dwie współpracujące ze sobą warstwy: warstwę lokalną na poziomie podmiotów leczniczych i wspólną warstwę regionalną. Warstwę lokalną będą stanowiły ustandaryzowane nowoczesne i interoperacyjne systemy dziedzinowe, nowe lub zmodernizowane obecnie posiadane. W szczególności będą to systemy typu HIS, EDM, LIS, RIS, PACS, ERP, EOD, system rejestracji czasu pracy personelu, system kontroli dostępu do pomieszczeń, system gromadzenia i archiwizacji danych oraz system zarządzania bezpieczeństwem informacji i dostępu do danych. Warstwa regionalna będzie scentralizowanym zestawem elektronicznych usług dedykowanych dla pacjentów, personelu podmiotów leczniczych biorących udział w projekcie i pracowników Samorządu Województwa Pomorskiego, zgodnie z ich potrzebami. 5. Interoperacyjność Rozwiązanie zapewnia interoperacyjność systemów i usług w następujących obszarach: o o Interoperacyjność techniczna zapewnienie zgodności na poziomie interfejsów i protokołów komunikacyjnych. Interoperacyjność semantyczna - ujednolicenie słowników oraz struktur danych. W tym celu warstwa regionalna będzie udostępniała słowniki i rejestry używane przy wymianie danych. Ponadto cała elektroniczna dokumentacja medyczna disi@pomorskie.eu, Strona 19 z 212

20 o przechowywana w repozytoriach dokumentacji będzie zapisywana w standardzie HL7 CDA. Interoperacyjność procesowa określenie spójnych procesów w ramach całości rozwiązania. W projekcie PeZ przyjęto m.in., że gromadzenie i wymiana elektronicznej dokumentacji medycznej będą się odbywały zgodnie ze standardem IHE XDS.b. Standard ten został również przyjęty jako obowiązujący w projekcie P1. 6. Bezpieczeństwo danych osobowych Z uwagi na przetwarzanie w systemie danych osobowych, a w szczególności danych wrażliwych, rozwiązanie będzie spełniało najwyższe standardy w zakresie bezpieczeństwa danych. Gromadzone będą dane audytowe związane z dostępem do informacji oraz z jej przetwarzaniem. Rozwiązanie będzie spełniało wymogi nałożone przez Ustawę o ochronie danych osobowych (Dz. U r. poz. 922) oraz dotyczące systemów informatycznych Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych. 7. Skalowalność, otwartość i elastyczność rozwiązania Zostanie zapewniona otwartość i skalowalność rozwiązania umożliwiająca dołączanie w przyszłości do projektu Pomorskie e-zdrowie kolejnych zainteresowanych podmiotów leczniczych z obszaru województwa pomorskiego, pod warunkiem spełnienia wymagań technicznych, niezależnie od formy organizacyjnej bądź statusu właścicielskiego (jednostki publiczne i niepubliczne). Architektura rozwiązania umożliwia także elastyczne dopasowanie do zmieniających się potrzeb biznesowych poprzez możliwość rozbudowy PeZ o nowe komponenty i usługi realizujące kolejne funkcjonalności. 8. Integracja z innymi platformami Zakłada się, że w przyszłości rozwiązanie zapewni integrację z systemami centralnymi, między innymi: disi@pomorskie.eu, Strona 20 z 212

21 o o "Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych" (P1) Platforma udostępniania on-line przedsiębiorcom usług i zasobów cyfrowych rejestrów medycznych (P2) przy wykorzystaniu udostępnionych publicznie interfejsów komunikacyjnych. 9. Nowoczesny kanał komunikacji w obszarze ochrony zdrowia. Podniesienie dostępności usług medycznych zostanie osiągnięte poprzez udostępnienie elektronicznego kanału komunikacji. Udostępnienie obywatelom województwa, personelowi medycznemu i pracownikom samorządu e-usług otwiera nowoczesny kanał komunikacji w obszarze ochrony zdrowia. Dostęp do e-usług powinien obejmować jak największą grupę odbiorców i z tego względu interesariusze mogą korzystać z e-usług poprzez różnego rodzaju urządzenia typu smartfony, tablety, laptopy, komputery stacjonarne. 10. Świadczenie usług infrastrukturalnych przez regionalne centrum przetwarzania danych Świadczenie e-usług dla całego województwa wymaga na poziome regionalnym określonych zasobów infrastrukturalnych w postaci centrum przetwarzania danych. Regionalne centrum przetwarzania danych musi zapewniać bezpieczne, wydajne i niezawodne przetwarzanie danych na potrzeby e-usług. Dodatkowo regionalne centrum przetwarzania danych może wspierać podmioty lecznicze w zakresie świadczenia usług infrastrukturalnych - np. regionalne centrum przetwarzania danych może udostępniać dedykowane zasoby do uruchomienia systemów podmiotów leczniczych lub udostępniać przestrzeń do przechowywania kopii zapasowych. 11. Zastosowanie sprawdzonych technologii Zapewnienie odpowiedniego poziomu dostępności, wydajności i bezpieczeństwa e-usług wymaga zastosowania sprawdzonych i dojrzałych technologii. Zastosowane technologie muszą być ciągle wspierane i rozwijane. Ze względu na interoperacyjność zastosowane technologie powinny być wspierane przez wielu producentów i dostawców rozwiązań informatycznych. 12. Architektura rozwiązania o dużym potencjale rozwoju. Świadczenie e-usług w Polsce jest w początkowym stadium rozwoju i należy przewidywać dalszy rozwój e-usług w obszarze ochrony zdrowia. Z tego względu architektura rozwiązania disi@pomorskie.eu, Strona 21 z 212

22 musi być otwarta na wprowadzanie zmian i rozbudowę rozwiązania. Architektura rozwiązania powinna także zakładać łatwość wdrażania i utrzymywania rozwiązania. 13. Konieczność spełnienia wymagań formalno-prawnych wynikających m.in. z następujących regulacji: a. Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz.U poz z późn. zm.) wraz z delegowanymi aktami wykonawczymi. b. Ustawa z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych (Dz.U poz z późn. zm.) wraz z delegowanymi aktami wykonawczymi. c. Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U poz. 186 z późn. zm. ) wraz z delegowanymi aktami wykonawczymi. d. Ustawa z dnia 5 grudnia 1996 r. o zawodach lekarza i lekarza dentysty (Dz.U poz. 464 z późn. zm.) wraz z delegowanymi aktami wykonawczymi. e. Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U poz. 922) wraz z delegowanymi aktami wykonawczymi. f. Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U poz z późn. zm. ) wraz z delegowanymi aktami wykonawczymi. g. Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz.U poz z późn. zm. ) wraz z delegowanymi aktami wykonawczymi. h. Ustawa z dnia 29 stycznia 2004 r. - Prawo zamówień publicznych (Dz.U poz z późn. zm. ) wraz z delegowanymi aktami wykonawczymi. i. Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U poz z późn. zm.) wraz z delegowanymi aktami wykonawczymi. j. Ustawa z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz.U poz. 1579) wraz z delegowanymi aktami wykonawczymi k. Ustawa z dnia 15 kwietnia 2011 r. o działalności leczniczej (Dz.U poz z późn. zm.) wraz z delegowanymi aktami wykonawczymi l. Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz.U nr 128 poz z późn. zm.) m. Dyrektywa Parlamentu Europejskiego i Rady 2011/24/UE z dnia 9 marca 2011 r. w sprawie stosowania praw pacjentów w transgranicznej opiece zdrowotnej (Dz.Urz.UE L 88 z s.45) wraz z dyrektywami wykonawczymi. n. Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany disi@pomorskie.eu, Strona 22 z 212

23 informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U poz. 113 z późn. zm. ) o. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U nr 100 poz. 1024) p. Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz. U nr 205, poz z późn. zm.). q. Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U poz. 177 z późn. zm.). r. Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 5 czerwca 2014 r. w sprawie przeprowadzania konkursu oraz przeznaczania i rozliczania środków finansowych na informatyzację (Dz. U poz. 780) s. Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz. U nr 217 poz. 1836) t. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 20 czerwca 2007 w sprawie wykazu wyrobów służących zapewnieniu bezpieczeństwa publicznego lub ochronie zdrowia i życia oraz mienia, a także zasad wydawania dopuszczenia tych wyrobów do użytkowania (Dz.U r., nr 143, poz z późn. zm.). u. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych)) 2. Wdrożone rozwiązanie PeZ obejmować będzie uruchomienie usług świadczonych zarówno dla użytkowników systemu PeZ niebędących pracownikami SWP oraz PL jak i dla użytkowników systemu PeZ będących pracownikami SWP oraz PL. 3. Rozwiązania informatyczne będą ustandaryzowane, a ich dostępność będzie następująca: a. rozwiązania klasy regionalnej będą dostępne jako rozwiązania scentralizowane dla wszystkich PL oraz SWP, b. rozwiązania specjalistyczne należące do obszaru systemów infrastruktury (np. DR, bezpieczeństwo, itp.) będą scentralizowane dla wszystkich PL, c. rozwiązania dziedzinowe i specjalistyczne dla podmiotów leczniczych będą rozmieszczone w PL i ustandaryzowane. 4. Wszystkie PL będą działały w oparciu o sieć MVPN połączoną z GCDP/DR. disi@pomorskie.eu, Strona 23 z 212

24 5. W PL powinny być wykonane i działać sieci strukturalne kategorii minimum 6A. disi@pomorskie.eu, Strona 24 z 212

25 3 Architektura rozwiązania PeZ i organizacja utrzymania Klauzula generalna: W zależności od uzasadnionych i uzgodnionych potrzeb uczestników Projektu PeZ wymagania Koncepcji Techniczno-Technologicznej mogą w przyszłości ulec zmianie/modyfikacji/doprecyzowaniu w specyfikacji opisu przedmiotu zamówienia dla poszczególnej kategorii zamówienia. Ogólny opis architektury rozwiązania PeZ obejmuje swoim zakresem wszystkich uczestników projektu PeZ. Ze względu na konieczność optymalizacji rozwiązania, architektura PeZ została dostosowana do potrzeb poszczególnych PL. Aby ułatwić proces standaryzacji poszczególnych obszarów merytorycznych, PL zostały podzielone na kilka klas. Klasy podmiotów wynikają w pierwszej kolejności z inwentaryzacji przeprowadzonej wcześniej oraz z potrzeb IT podmiotu leczniczego. W dalszej części dokumentu główny nacisk będzie kładziony na klasyfikację wg. potrzeb IT, poza kilkoma wyjątkami. Lista podmiotów wraz z przypisaniem ich do poszczególnych jest zawarta w tabeli poniżej: Skrót podmiotu Klasa podmiotu zgodnie z inwentaryza cją Klasa podmiotu w zakresie potrzeb IT Pełna nazwa Podmiotu Leczniczego PL01 B C Wojewódzki Szpital Psychiatryczny im. prof. Tadeusza Bilikiewicza w Gdańsku PL02 A1 D Stacja Pogotowia Ratunkowego w Gdańsku PL05 B C Wojewódzki Zespół Reumatologiczny im. dr Jadwigi Titz-Kosko PL06 A1 E 1 Centrum Zdrowia Psychicznego w Słupsku PL07 C2 A Wojewódzki Szpital Specjalistyczny im. Janusza Korczaka w Słupsku Sp. z o.o. PL08 B B Szpital dla Nerwowo i Psychicznie Chorych im. St. Kryzana w Starogardzie Gdańskim PL10 A2 E Wojewódzki Ośrodek Terapii Uzależnień w Gdańsku PL11 A1 D Stacja Pogotowia Ratunkowego w Słupsku PL12.1 C1 A COPERNICUS PL Sp. z o.o. PL14 B B Szpital Dziecięcy Polanki im. Macieja Płażyńskiego w Gdańsku Sp. z o.o. PL16 B B Szpital Specjalistyczny w Prabutach Sp. z o.o. PL17 A1 E Przemysłowy Zespół Opieki Zdrowotnej Sp. z o.o. PL18 C2 B Szpital Specjalistyczny w Kościerzynie Sp. z o.o PL19.2 C1 A Szpitale Wojewódzkie w Gdyni Sp. z o.o Tabela 2: Wykaz skrótów nazw podmiotów leczniczych i ich przyporządkowanie 1 Posadowienie infrastruktury serwerowej w PL07 disi@pomorskie.eu, Strona 25 z 212

26 Klasa PL zgodnie z inwentaryzacją: A1 małe PL (3 szt.) charakteryzujące się : o zatrudnieniem do 300 pracowników, o pracą w trybie ciągłym, tzn. 7/24h, o niewielką bazą sprzętową, tzn. poniżej 75 komputerów osobistych, o brakiem dedykowanych pomieszczeń serwerowni, o brakiem w PL personelu informatycznego lub części etatów, A2 małe PL (2 szt.) charakteryzujące się : o zatrudnieniem do 300 pracowników, o pracą w trybie jedno zmianowym, o niewielką bazą sprzętową, tzn. poniżej 75 komputerów osobistych, o brakiem dedykowanych pomieszczeń serwerowni, o brakiem w PL personelu informatycznego lub części etatów, B średnie PL (6 szt.) charakteryzujące się : o zatrudnieniem powyżej 300 pracowników, o pracą w trybie ciągłym, o średnią bazą sprzętową, tzn. powyżej 75 komputerów osobistych, o brakiem dedykowanych pomieszczeń serwerowni, o brakiem w PL personelu informatycznego lub posiadaniem kilku etatów w obszarze obsługi IT, C1 duże PL (2 szt.) charakteryzujące się : o zatrudnieniem powyżej 1000 pracowników, o dużą bazą sprzętową, tzn. powyżej 300 komputerów osobistych, o dwiema serwerowniami, o posiadaniem przez podmiot własnej obsługi IT, o do kategorii tej należą podmioty powstałe w wyniku połączenia dwóch PL, C2 duże PL (3 szt.) charakteryzujące się : o zatrudnieniem powyżej 1000 pracowników, o dużą bazą sprzętową, tzn. powyżej 300 komputerów osobistych, o jedną serwerownią, o posiadaniem własnej obsługi IT, o do kategorii tej należą podmioty powstałe w wyniku połączenia dwóch PL. Klasa PL w zakresie potrzeb IT: A (3 szt.) Duże podmioty w tym podmioty odległe, charakteryzujące się: disi@pomorskie.eu, Strona 26 z 212

27 o minimum dwoma pomieszczeniami serwerowymi lub serwerownią główną i pomieszczeniem pod serwerownie zapasowe, o możliwością połączenia swoich serwerowni za pomocą ciemnego światłowodu wielomodowego lub jednomodowego lub w przypadku, kiedy serwerownie są rozdzielone w dwóch różnych oddalonych od siebie budynkach, możliwość wybudowania takiego światłowodu. o potrzebą instalacji lokalnej infrastruktury wirtualizacji zasobów na dużych serwerach, o siecią serwerową opartą o protokoły 16Gbit FC i 10/1Gbit Ethernet. B (4 szt.) Duże podmioty, charakteryzujące się o Jednym dużym pomieszczeniem serwerowym, o trudnym lub ze względu na odległość niemożliwym lub nieopłacalnym dostępem do infrastruktury światłowodowej (ciemny światłowód), dającym możliwość wpięcia w sieć światłowodową aglomeracji trójmiejskiej, o potrzebą instalacji lokalnej infrastruktury wirtualizacji zasobów na dużych serwerach umieszczonych w jednej serwerowni, o siecią serwerową opartą o protokoły 10/1Gbit Ethernet, o macierzami danych wpiętych do serwerów za pomocą polaczeń SAS, iscsi lub FC C (2 szt.) Średnie i małe podmioty, charakteryzujące się: o jedną małą serwerownią lub jednym pomieszczeniem dedykowanym pod serwerownię, o łatwym dostępem do infrastruktury światłowodowej (ciemny światłowód), dającym możliwość wpięcia w sieć światłowodową aglomeracji trójmiejskiej, o potrzebą instalacji lokalnej infrastruktury wirtualizacji zasobów na średnich serwerach, w jednej serwerowni, o siecią serwerową opartą o protokoły 10/1Gbit Ethernet, o macierzą danych wpiętą do serwerów za pomocą polaczeń SAS, iscsi lub FC D (2 szt.) Pogotowia, charakteryzujące się: o jednym małym pomieszczeniem serwerowym, o potrzebą instalacji lokalnej infrastruktury wirtualizacji zasobów na małych serwerach, w jednej serwerowni, wraz z zwirtualizowaną bazą danych, o dostępem do zasobów sprzętowo-programowych zlokalizowanych w ośrodku GCPD gwarantujących realizację reżimu wysokiej niezawodności, o siecią serwerową opartą o protokoły 10/1Gbit Ethernet, o macierzą danych wpiętą do serwerów za pomocą połączeń SAS, iscsi lub FC. E (3 szt.) Bardzo małe podmioty, charakteryzujące się: o brakiem pomieszczeń serwerowych, disi@pomorskie.eu, Strona 27 z 212

28 o o o łatwym dostępem do infrastruktury światłowodowej (ciemny światłowód), dającym możliwość wpięcia w sieć światłowodową aglomeracji trójmiejskiej, wykorzystaniem zasobów sprzętowo-programowych zlokalizowanych w ośrodku GCPD, instalacją LAN w postaci okablowania strukturalnego i/lub z siecią WLAN w zależności od budżetu PL. Klasa SWP i CPD w zakresie potrzeb: SWP Samorząd Województwa Pomorskiego, charakteryzujący się: o łatwym dostępem do infrastruktury światłowodowej (ciemny światłowód), dającym możliwość wpięcia w sieć światłowodową aglomeracji trójmiejskiej i dostępu do GCPD/DR, w celu nadzoru. GCPD Główne Centrum Przetwarzania Danych charakteryzujące się: o jednym pomieszczeniem serwerowym, o łatwym dostępem do infrastruktury światłowodowej (ciemny światłowód), dającym możliwość wpięcia w sieć światłowodową aglomeracji trójmiejskiej, o potrzebą instalacji lokalnej infrastruktury wirtualizacji zasobów na bardzo dużych serwerach, w jednej serwerowni, o infrastrukturą bazodanową baz danych szyny regionalnej i regionalnego EDM, o siecią serwerową opartą o protokół FC, o macierzą danych działająca w trybie synchronizacji z macierzą w DR o macierzą danych NAS, działająca w trybie asynchronicznym dla banku archiwum danych z możliwością rozszerzania pamięci w chmurze danych, o łączem do publicznej sieci internet o prędkości minimum 10Gbit DR Disater Recovery Site Zapasowe Centrum Przetwarzania Danych charakteryzujące się: o jednym pomieszczeniem serwerowym, o łatwym dostępem do infrastruktury światłowodowej (ciemny światłowód), dającym możliwość wpięcia w sieć światłowodową aglomeracji trójmiejskiej, o infrastrukturą bazodanową działającą w trybie wysokiej niezawodności, do klastra baz danych dla systemów GCPD, o siecią serwerową opartą o protokół FC, o szybką macierzą danych działająca w trybie synchronizacji z macierzą w GCPD, o dużą macierzą danych NAS, działająca w trybie asynchronicznym dla banku archiwum danych, o łączem internetowym o prędkości minimum 1Gbit. disi@pomorskie.eu, Strona 28 z 212

29 W odniesieniu do tak zróżnicowanych użytkowników, architektura systemu PeZ została podzielona na dwie części: na obszar systemów lokalnych, których modele świadczenia zostały określone szczegółowo w rozdziałach opisujących systemy dziedzinowe i specjalistyczne dla PL oraz na obszar systemów (usług) regionalnych, które są wspólne dla wszystkich uczestników projektu. W dalszej części dokumentu jest opisana ogólna architektura rozwiązania PeZ wraz z jej uszczegółowieniem dla specyficznych odbiorców (użytkowników rozumianych jako PL) oraz uszczegółowieniem architektury dla usługodawców będących istotnym elementem architektury całości rozwiązania PeZ (GCPD). 3.1 Warstwy architektury PeZ Rekomendujemy opisanie architektury PeZ w oparciu o model TOGAF przedstawiony na poniższym rysunku (Rysunek 3-1). Architektura biznesu Architektura aplikacji Architektura informacji Architektura infrastruktury Rysunek 3-1: Schemat architektury w modelu TOGAF Zgodnie z wymaganiami z OPZ i korzystając z opisu przedstawionego na rysunku (Rysunek 3-1) modelu, w niniejszym dokumencie opisane są warstwy architektoniczne systemu Pomorskie e-zdrowie. Szczególny nacisk położono na obszar infrastruktury technicznej i aplikacji. 3.2 Założenia architektury PeZ Założenia dla architektury Pomorskiego e-zdrowia uwzględniające dobre praktyki w obszarze projektowania systemów informatycznych są następujące: disi@pomorskie.eu, Strona 29 z 212

30 wszystkie PL będą mieć dostęp do systemów dziedzinowych i specjalistycznych wspierających ich procesy, systemy dziedzinowe i specjalistyczne obsługujące te same procesy zostaną ustandaryzowane - standaryzacja systemów dziedzinowych i specjalistycznych powinna powodować standaryzację komunikacji pomiędzy nimi oraz komunikacji z warstwą regionalną (standaryzacja architektury integracyjnej), wszystkie PL będą korzystać z ustandaryzowanych systemów wspierających, wszystkie PL będą korzystać z systemów regionalnych, celem zoptymalizowania i umożliwienia wysokiej dostępności systemów regionalnych oraz usług, które będą świadczone dla poszczególnych PL, usługi informatyczne będą świadczone przez Główne Centrum Przetwarzania Danych (założenia dotyczące GCPD zamieszczone zostały w dalszej części dokumentu), wszystkie PL będą działały w jednej rozległej sieci, w PL powinny być wykonane i działać sieci komputerowe LAN kategorii min. 6A i WLAN, wszystkie PL w architekturze PeZ będą korzystać z usług IT na zdefiniowanym poziomie SLA (odpowiednio zdefiniowane parametry itp.), architektura aplikacji będzie ustandaryzowana, zaś zależnie od wielkości podmiotu, zakres funkcjonalny oraz model dostępu do infrastruktury będzie zróżnicowany, integracja aplikacji będzie odbywać się z wykorzystaniem standardów branżowych, jednostki nieposiadające infrastruktury serwerowni lub posiadające ją na poziomie nie wystarczającym dla potrzeb danego PL, będą korzystać z usług świadczonych przez GCPD, architektura rozwiązania PeZ będzie zapewniać ochronę informacji wrażliwych, w taki sposób, aby na efektywnie ją chronić w dowolnym obszarze przetwarzania, począwszy od repozytoriów informacji, aż poprzez przesyłanie informacji między podmiotami, od 1 stycznia 2018 roku wszystkie PL powinny mieć wdrożoną elektroniczną dokumentację medyczną (EDM), w zależności od uzasadnionych i uzgodnionych potrzeb uczestników Projektu PeZ treść Koncepcji Techniczno-Technologicznej może w przyszłości ulec modyfikacji i doprecyzowaniu zarówno w niniejszym dokumencie i/lub specyfikacji opisu przedmiotu zamówienia w poszczególnej kategorii zamówienia. 3.3 Opis architektury biznesowej PeZ Dla poprawnego zdefiniowania istotnych elementów technicznych wspierających świadczenie usług droga elektroniczną w obszarze zdrowia, konieczne jest przede wszystkim określenie celów disi@pomorskie.eu, Strona 30 z 212

31 biznesowych projektu oraz określenie architektury biznesowej rozwiązania PeZ. Wysokopoziomowa architektura biznesowa PeZ opisana została na rysunku (Rysunek 3-2). ŚWIADCZENIE USŁUG MEDYCZNYCH DOSTĘPNOŚĆ USŁUG PORÓWNYWANIE OFERT ANALIZA RYZYKA DOSTĘPNOŚĆ USŁUG ZAPOBIEGANIE DZIAŁ. NIEPOŻĄDAYM ANALIZA DANYCH KOORDYNOWANIE BADAŃ OCENA JAKOŚCI WEWNĘTRZNA KOMUNIKACJA ZEWNĘTRZNA KOMUNIKACJA JAKOŚĆ ŚWIADCZONYCH USŁUG EFEKTYWNOŚĆ OBSZARU ZDROWIA PROFILAKTYKA FILARY E-ZDROWIA W POMORSKIEM Rysunek 3-2: Architektura biznesowa PeZ Główne trzy elementy biznesowe to jakość, efektywność oraz profilaktyka. Na tych elementach będzie koncentrować się charakter biznesowy PeZ obejmując poniższe elementy w obszarze świadczenia usług medycznych: dostępność usług i e-usług wymiar opisujący katalog usług i sposób ich prezentowania oraz prezentowanie informacji w zakresie poziomu osiągalności usług lub ich wykorzystania na poziomie całości regionu. Dostępność usług będzie obszarem, który disi@pomorskie.eu, Strona 31 z 212

32 będzie kreował popyt na usługi (w obszarze profilaktyki), ale też będzie regulowany w obszarze jakości, analiza ryzyka związana zarówno ze zdefiniowanymi obszarami możliwych działań niepożądanych, jak i kalkulacji działań zapobiegawczych i ich efektywności finansowej, ocena jakości jako parametr oceny zarówno ze strony właścicielskiej jak i ze strony usługobiorców, wewnętrzna komunikacja jako parametr efektywności wymiany informacji między podmiotami oraz wewnątrz podmiotów; parametr ten ma bezpośredni wpływ na realizację usług medycznych w podmiotach, zapobieganie działaniom niepożądanym jako obszar działań zmniejszających obszar wpływu ryzyka, ze szczególnym uwzględnieniem przetwarzanych danych wrażliwych (parametr ściśle powiązany z analizą ryzyka i analizą danych w podmiotach), analiza danych jako obszar analizy efektywności ekonomicznej działania podmiotów, porównywanie ofert jako obszar przekazywania oferty dla pacjenta i sterowanie ofertą, aby spełniała wymagania i zapotrzebowania pacjenta, a jednocześnie nie była przewymiarowana w stosunku do aktualnych lub przewidywanych potrzeb, koordynowanie badań jako obszar optymalizujący obciążenie poszczególnych podmiotów leczniczych oraz brak dublowania działań w obszarze diagnostyki, zewnętrzna komunikacja jako obszar przekazywania istotnych informacji do odbiorców zewnętrznych (pacjenci) oraz instytucji / podmiotów celem sprawnej wymiany informacji (w ramach tego obszaru znajduje się także obszar informowania pacjenta przekazywania istotnych danych w zakresie ochrony zdrowia). 3.4 Opis architektury informacji PeZ W ramach projektu powstanie pakiet usług, w podziale na grupy interesariuszy: Pakiet usług dla pacjentów (mieszkańców województwa pomorskiego): o e-informacja, o e-rejestracja, o e-koordynacja Opieki Medycznej, o e-koordynacja Opieki nad Osobami Starszymi, o Rejestr danych ratunkowych, o Wymiana dokumentacji medycznej - Długoterminowe Archiwa Danych, o Wymiana dokumentacji medycznej dla podmiotów leczniczych z województwa pomorskiego nie będących uczestnikami projektu, o Wsparcie polityki zdrowotnej, disi@pomorskie.eu, Strona 32 z 212

33 Pakiet usług dla Podmiotów Leczniczych o e-informacja, o e-rejestracja, o e-koordynacja Opieki Medycznej, o e-opieka nad osobami chorymi na cukrzycę, o e-opieka nad osobami chorymi na POChP, o e-koordynacja Opieki nad Osobami Starszymi, o Teleradiologia, o Rejestr danych ratunkowych, o Wymiana dokumentacji medycznej - Długoterminowe Archiwa Danych, o Wymiana dokumentacji medycznej Repozytoria bieżące i długoterminowe dla małych ZOZ, o Obsługa Elektronicznych Zleceń pomiędzy świadczeniodawcami, o Wsparcie polityki zdrowotnej, o Obsługa nadzoru właścicielskiego, Pakiet usług dla SWP: o e-informacja, o Wsparcie polityki zdrowotnej, o Obsługa nadzoru właścicielskiego, pakiet usług integracyjnych dla podmiotów zewnętrznych (CSIOZ, NFZ, MSWiA): o integracja z systemem P1, o integracja z epuap (profil zaufany), o integracja z systemem ewuś, o integracja z systemem Kolejek Oczekujących, o integracja z SWD PRM 2.0 (o ile zostanie udostępniona taka możliwość w ramach SWD PRM). W poszczególnych obszarach dziedzinowych i specjalistycznych, wymienione są szczegółowe opisy dotyczące grup usług w obszarze architektury informacji. Wyżej wymienione usługi można także pogrupować na grupy poziomu regionalnego, dziedzinowego i specjalistycznego. 3.5 Opis architektury aplikacji PeZ Ogólny opis architektury rozwiązania PeZ znajduje się na poniższym rysunku (Rysunek 3-3). disi@pomorskie.eu, Strona 33 z 212

34 Rysunek 3-3: Ogólny opis architektury rozwiązania PeZ Założenia rozwiązania PeZ są następujące: Istnieje Główne Centrum Przetwarzania Danych (GCPD), którego przeznaczeniem jest świadczenie następujących usług: o usługa dostępu do systemów IT dla podmiotów klasy E, która składa się z: dostępu do systemów dziedzinowych i specjalistycznych (np. HIS, ERP, RIS, itp.), dostępu do systemów specjalistycznych (AV, EOD, CA itp.), disi@pomorskie.eu, Strona 34 z 212

35 dostępu do usług infrastrukturalnych (backup, bezpieczeństwo, hosting, poczta, DNS itp.), dostępu do systemów na poziomie regionalnym (portal, BI). o usługa dostępu do systemów IT dla podmiotów klasy C i D, która składa się z: dostępu do części systemów specjalistycznych (AV, EOD, CA, itp.), dostępu do części usług infrastrukturalnych (archiwum EDM, bezpieczeństwo, hosting, poczta, DNS itp.), dostępu do systemów na poziomie regionalnym (portal, BI). o usługa dostępu do systemów IT dla podmiotów klasy A i B, która składa się z: dostępu do części systemów specjalistycznych (AV, EOD, CA, itp.), dostępu do części usług infrastrukturalnych (archiwum EDM, bezpieczeństwo, hosting, poczta, DNS itp.), dostępu do systemów na poziomie regionalnym (portal, BI). Istnieje Zapasowe Centrum Przetwarzania danych (DR), którego celem jest: o świadczenie usług DR dla systemów Regionalnych i e-usług znajdujących się w GCPD, o replika asynchroniczna archiwum EDM. Dla PL zostanie utworzona sieć MVPN tworząc WAN PeZ dla tych placówek, Dostęp do sieci Internet PL korzystających z sieci WAN aglomeracji trójmiejskiej może być realizowany przez łącze w GCPD, Bazy danych zostaną umieszczone, w podmiotach klasy D w wersjach zwirtualizowanych w obszarze przestrzeni serwerów aplikacyjnych. Podmioty klasy E nie będą posiadały własnej infrastruktury serwerowej w swojej lokalizacji, lecz będą korzystać z infrastruktury oferowanej przez GCPD. Podmioty klasy E będą korzystać z ustandaryzowanej infrastruktury systemowej w całym obszarze biznesowym (dziedzinowy, specjalistyczny, regionalny), gdzie zakres funkcjonalny wykorzystywanych systemów będzie zależny od charakterystyki poszczególnych podmiotów leczniczych. Podmioty klasy C i D będą korzystać z ustandaryzowanej infrastruktury systemowej w części zakresu specjalistycznego oraz w całym zakresie systemów regionalnych, gdzie zakres funkcjonalny wykorzystywanych systemów będzie zależny od charakterystyki poszczególnych podmiotów leczniczych. Podmioty klasy C i D będą posiadać własną infrastrukturę sprzętową (serwery, pamięci masowe, itp.), na której będą posadowione systemy w obszarze dziedzinowym i specjalistycznym. W podmiotach tych systemy wirtualizacji, macierzy i chmury baz danych będą działały heterogenicznie wzajemnie się zabezpieczając. Usługi ze strony GCPD podmiotów klasy C i D będą skoncentrowane na poziomie usług regionalnych. W ten sposób, podmiot leczniczy klasy C i D będzie miał disi@pomorskie.eu, Strona 35 z 212

36 dostęp do systemów regionalnych PeZ w zakresie rozwiązania portalowego, systemu zarządzania jakością, systemu zapobiegania nadużyciom, BI, archiwum długoterminowego, hostingu i dostępu do e-usług. Dodatkowo, zgodnie z podejściem i wizją kompleksową EDM podmiotu leczniczego klasy C i D będzie replikować się do EDM regionalnego. Podmioty klasy A i B będą korzystać z ustandaryzowanej infrastruktury systemowej jedynie w zakresie systemów regionalnych. Podmioty klasy A będą posiadać własną infrastrukturę sprzętową, na której będą posadowione systemy w obszarze dziedzinowym i specjalistycznym i własne minimum dwie serwerownie. Podmioty B będą gromadziły infrastrukturę w zakresie jednej serwerowni. Podmioty klasy A i B znajdujące się poza aglomeracją trójmiejską sieci WAN zostaną połączone z GCPD poprzez MVPN. W podmiotach tych ze względu na odległość od sieci światłowodowej systemy wirtualizacji, macierzy i chmury baz danych będą działały heterogenicznie wzajemnie się zabezpieczając bez konieczności wykorzystania infrastruktury GCPD. Szyna danych architektury PeZ jest otwarta i przygotowana na dołączenie kolejnych podmiotów leczniczych w przypadku deklaracji z ich strony korzystania z systemu, w szczególności podmiotów leczniczych realizujących zadania MOF oraz POZ. Do systemów regionalnych zostanie dołączona otwarta infrastruktura API, z przekazaniem możliwości integracji w postaci opisu oprogramowania wejścia wyjścia dla przyszłych systemów, rozbudowy i integracji z P1, P2 oraz przyszłymi centrami służącymi do podpisu EDM. Na potrzeby projektu powstanie wspólne repozytorium użytkowników zawierające uprawnienia z poszczególnych systemów, pozwalające na aktywne sprawdzenie wszelkich nieprawidłowości w dostępie do informacji wrażliwych oraz umożliwiające weryfikację posiadanych dostępów do informacji, z możliwością ich wycofania. W obszarze systemów regionalnych zostanie umieszczony system hostingu stron www z CMS i BIP oraz serwery poczty elektronicznej dla wszystkich PL. Serwery poczty będą zintegrowane z systemem kalendarzy oraz obsługą faxów poprzez efax. Kalendarze zostaną zintegrowane z systemami ERP w zakresie obsługi kadrowej w obszarze rozliczania czasu pracy. Dla każdej z grup opracowane zostały odrębne założenia dotyczące dostępu do aplikacji i funkcjonalności. W dalszych podrozdziałach, opisano architekturę rozwiązań dla poszczególnych grup oraz dla Głównego Centrum Przetwarzania Danych, którego zadaniem będzie udostępnienie infrastruktury dla systemów regionalnych dostępnych dla wszystkich PL, a także infrastruktury niezbędnej dla wsparcia świadczenia usług dla poszczególnych klas PL. disi@pomorskie.eu, Strona 36 z 212

37 3.6 Architektura GCPD/DR Zgodnie z ogólnym opisem architektury PeZ zakładane jest zapewnienie GCPD nie będącego częścią obecnej infrastruktury technicznej żadnego z podmiotów leczniczych ani SWP. GCPD zostanie zabezpieczone drugim Centrum Przetwarzania Danych DR. GCPD będzie zapewniać wszystkim podmiotom dostępność następujących usług (w podziale na klasę podmiotu): dla PL typu E świadczenie usługi dostępu do systemów (zgodnie ze szczegółową architekturą opisaną dla danych PL): o HIS, LIS, o EDM, o EOD, o ERP, o back office (poczta, usługi katalogowe, AV, CA), o scentralizowany dostęp do sieci Internet, o Archiwum EDM, o Dostęp do e-usług, o Obsługa hostingu domen, usług pocztowych, efaxu, stron www/bip, dla PL typu C i D świadczenie ustandaryzowanych usług dla systemów wspierających (zgodnie ze szczegółową architekturą opisaną dla danych PL): o PKI, o back office (poczta, usługi katalogowe, AV, CA), o scentralizowany dostęp do sieci Internet, o archiwum EDM, o dostęp do System Obsługi Ratownictwa dla SOR, o dostęp do e-usług, o obsługa hostingu domen, usług pocztowych, efaxu, stron www/bip, dla PL typu A i B świadczenie usług o PKI, o dostęp do Systemu Obsługi Ratownictwa dla SOR, o scentralizowany dostęp do sieci Internet, o back office (poczta, usługi katalogowe, AV, CA), o archiwum EDM, o dostęp do e-usług, o obsługa hostingu domen, usług pocztowych, efaxu i stron www/bip. disi@pomorskie.eu, Strona 37 z 212

38 Zadaniem GCPD będzie także zapewnianie dla wszystkich PL oraz SWP świadczenia ustandaryzowanych usług dla systemów na poziomie regionalnym: elektroniczny obieg dokumentów, BI, SOJ, SZN, rozwiązanie portalowe obejmujące świadczenie usług regionalnych oraz dla poszczególnych PL, rozwiązanie wspólnego portalu hostingowego dla platform internetowych wszystkich PL i BIP oraz centralna obsługa poczty, umiejscowienie oprogramowania platformy e-usług i systemu obsługi ratownictwa, warstwa integracyjna realizowana przez szynę danych, EDM i Archiwum długoterminowe EDM, backup i archiwizacja dla PeZ (centralny węzeł systemu), warstwa kontroli i weryfikacji uprawnień w świadczonych usługach dostępowych, pozostałych usług infrastrukturalnych. Schemat infrastruktury technicznej GCPD oraz relacje z poszczególnymi podmiotami leczniczymi przedstawia rysunek poniżej (Rysunek 3-4): disi@pomorskie.eu, Strona 38 z 212

39 Rysunek 3-4: Architektura GCPD Opis architektury GCPD/DR przedstawiony jest na poniższym rysunku. Strona 39 z 212

40 Rysunek 3-5: Architektura rozwiązania PeZ dla GCPD/DR Główne Centrum Przetwarzania Danych i wszystkie działające w nim systemy, zostaną zduplikowane w drugim zapasowym Centrum Przetwarzania Danych. Każdy pojedynczy system lub serwer działający w GCPD będzie miał swoje aktywne i/lub pasywne odzwierciedlenie w infrastrukturze DR, za wyjątkiem systemów specjalistycznych i dziedzinowych PL klasy E działających w GCPD. Połączenie pomiędzy GCPD i DR w oparciu o ciemne włókna światłowodowe powinno obejmować 8j, w tym: disi@pomorskie.eu, Strona 40 z 212

41 2j dla połączenia dla danych 16 G FC macierzy danych, 2j dla połączenia metro-cluster 16G FC macierzy danych, 2j dla połączenia 40/10GE dla serwerów i danych. Poza tym w GCPD oraz DR zostaną umieszczone systemy e-usług platformy PeZ oraz systemy archiwum danych długoterminowych i regionalnego EDM. Do obydwu serwerowni zostanie dołączona sieć Internet, w GCPD 10Gbit a w DR 5Gbit, sieć ta zostanie wpięta w obszar sieci ze wspólną adresacją lub własną adresacją jako strefa DMZ (jest to wydzielany na zaporze sieciowej (ang. Firewall/UTM) obszar sieci komputerowej nienależący ani do sieci wewnętrznej (tj. tej chronionej przez zaporę), ani do sieci zewnętrznej (tej przed zaporą; na ogół jest to Internet)). W DMZ zostanie uruchomiony system failover łącza internetowego oraz zostaną zamontowane wszystkie systemy generowania MVPN i systemów bezpieczeństwa styku z siecią Internet. 3.7 Architektura rozwiązania PeZ dla podmiotów klasy E Opis architektury dla podmiotów klasy E przedstawiony jest na rysunku poniżej. disi@pomorskie.eu, Strona 41 z 212

42 Rysunek 3-6: Architektura rozwiązania PeZ dla PL klasy E Zgodnie z zaprezentowanym powyżej podejściem, podmioty klasy E nie będą posiadać własnej infrastruktury serwerowej i przechowywania danych ani nie będą posiadać własnych systemów informatycznych części białej i szarej. Całość usług IT będzie świadczona przez GCPD. W ramach świadczenia usług, GCPD będzie udostępniać system specjalistyczny HIS wraz z EDM, a także dostęp do systemu klasy ERP, pocztę elektroniczną, kontrolę dostępu, PKI itd. Dodatkowo, podmioty klasy E będą miały dostęp do systemów regionalnych PeZ w zakresie rozwiązania portalowego, systemu zarządzania jakością, systemu zapobiegania nadużyciom, BI. Dodatkowo, zgodnie z podejściem i wizją kompleksową, EDM podmiotów klasy E będą replikować się do EDM regionalnego. disi@pomorskie.eu, Strona 42 z 212

43 W zakresie systemów specjalistycznych, podmioty klasy E będą korzystać z systemu klasy ERP, który będzie zintegrowany z systemem HIS. System klasy ERP będzie w obszarze funkcjonalności ograniczony do potrzeb podmiotów klasy E. Dodatkowo, podmioty te będą mogły korzystać z systemu elektronicznego obiegu dokumentacji (EOD), także ograniczonego do jego potrzeb. W obszarze rozwiązań infrastruktury, podmioty klasy E będą wykorzystywać rozwiązanie antywirusowe, SSO, usługi katalogowe. Systemy zarządzania i monitorowania bezpieczeństwa IT oraz system backupu, wdrożone w GCPD będą obsługiwać infrastrukturę sprzętowo-systemową rozwiązań wykorzystywanych przez podmioty klasy E. Podmioty będą też korzystały ze wspólnego dostępu do sieci Internet udostępnianej przez WAN PeZ z GCPD. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło łącze Internetowe. Do podpisu pod dokumentacją elektroniczną w EDM będzie służył do wyboru: eidas, e-puap i własne CA dla podpisów niekwalifikowanych. System będzie też otwarty na ewentualną możliwość podpięcia innego typu podpisu pod dokumentacją w razie zmiany przepisów. PKI (CA) będzie wykorzystywane jako opcja dla e-puap i eidas jednak w infrastrukturze PeZ będzie CA główne, mające swoje odnogi we wszystkich PL za wyjątkiem PL klasy E. Regionalne CA będzie działało jak Root CA. Założenie oddzielnego Root CA wdrażanego w ramach projektu PeZ zapewni w pierwszej fazie zarówno certyfikaty do szyfrowania danych/transmisji oraz podpisywanie użytkowników podpisem niekwalifikowanym. Urządzenia, które będą funkcjonowały w podmiotach klasy E to komputery osobiste użytkowników, urządzenia drukujące oraz szafka MDF jako punkt dostępu do systemów zewnętrznych (GCPD, Internet, NFZ, itp.), a także niezbędna infrastruktura sieciowa w tym urządzeń bezpieczeństwa w zakresie sieci komputerowych oraz instalacja zasilania gwarantowanego. 3.8 Architektura rozwiązania PeZ dla podmiotów klasy C i D Opis architektury podmiotów klasy C i D przedstawiony jest na poniższym rysunku. disi@pomorskie.eu, Strona 43 z 212

44 Rysunek 3-7: Architektura rozwiązania PeZ dla podmiotów klasy C i D Zgodnie z zaprezentowanym ogólnym podejściem, podmioty klasy C i D będą posiadać własną infrastrukturę sprzętową, w jednej serwerowni, która będzie bazą dla działania systemów informatycznych wspierających procesy w części białej i szarej podmiotu leczniczego oraz systemów PACS/RIS/LIS o ile podmiot takie posiada. Na serwerach podmiotu zostanie również zainstalowana usługa lokalnego kontenera usług katalogowych, lokalnego CA, systemu backupu na NAS, EDM, systemu dostępu do pomieszczeń lub systemu zarządzania czasem pracy o ile został zaplanowany. Cześć usług będzie świadczona przez GCPD i będzie składać się usług backoffice owych (EOD, AV, poczta elektroniczna, CA), a także globalnych usług infrastrukturalnych związanych z SSO oraz disi@pomorskie.eu, Strona 44 z 212

45 replikacją backupu (szczegóły konfiguracji backupu podane są w rozdziale 7.11 niniejszego dokumentu). Minimalna przepustowość sieci będzie dostosowana dla poszczególnych PL i w zależności od potrzeb będzie do 10GE dla połączeń sieciowych. Podmioty będą też korzystały ze wspólnego dostępu do sieci Internet udostępnianej przez WAN PeZ z GCPD. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło łącze Internetowe. Druga część usług będzie także świadczona przez GCPD i będzie zestawem usług świadczonych obligatoryjnie na rzecz PL. W ten sposób, podmiot leczniczy klasy C i D będzie miał dostęp do systemów regionalnych PeZ w zakresie rozwiązania portalowego, e-usług, systemu zarządzania jakością, systemu zapobiegania nadużyciom, BI. Dodatkowo, zgodnie z podejściem i wizją kompleksową, EDM podmiotu leczniczego klasy C i D będzie replikować się do EDM regionalnego. W zakresie systemów dziedzinowych, docelowo jest planowane rozbudowanie obszaru rozwiązań o moduły RIS, LIS oraz PACS w zakresie potrzeb poszczególnych podmiotów. W zakresie systemów specjalistycznych PL klasy C i D będą korzystać z systemu klasy ERP wdrożonego lokalnie w podmiocie. System ERP obejmować będzie rozszerzony zakres funkcjonalności (oferowany jako standard dla PL klasy C i D oraz uwzględniający specyfikę danego podmiotu leczniczego). System elektronicznego obiegu dokumentacji (EOD) będzie dostępny dla podmiotu klasy C i D w podobnym zakresie jak dla pozostałych podmiotów, z możliwością wykorzystania rozszerzenia niektórych funkcjonalności zwiększających efektywność obiegu dokumentów w danej jednostce. W obszarze rozwiązań infrastruktury, podmiot leczniczy klasy C i D będzie wykorzystywać wewnętrzne rozwiązania w obszarze kontenera usług katalogowych, SDP (system dostępu do pomieszczeń serwerowni) oraz backupu. Inne rozwiązania infrastrukturalne takie jak rozwiązanie antywirusowe, SSO, CA, poczta elektroniczna, będą dostępne z poziomu regionalnego. Systemy zarządzania i monitorowania bezpieczeństwa IT oraz scentralizowany system backupu będą obsługiwać infrastrukturę sprzętowo-systemową rozwiązań biznesowych wykorzystywanych przez podmiot leczniczy klasy C i D. Podmiot będzie korzystał z obsługi poczty i usług hostingowych dla stron Internetowych z poziomu regionu, usług efaxu, i poczty elektronicznej. Placówki będą posiadały u siebie lokalne CA służące w połączeniu z eidas i epuap do podpisywania elektronicznej dokumentacji medycznej. Podpis będzie dostępny na karcie, która wraz z certyfikatem do SSO będzie podstawowym elementem dla logowania do domeny. System będzie też otwarty na ewentualną możliwość podpięcia innego typu podpisu pod dokumentacją w razie zmiany przepisów. PKI (CA) będzie wykorzystywane jako opcja dla e-puap i eidas jednak w infrastrukturze PeZ będzie CA główne, mające swoje odnogi we wszystkich PL za wyjątkiem PL klasy E. Regionalne CA będzie działało jak Root CA. Założenie oddzielnego Root CA wdrażanego w ramach projektu PeZ zapewni w pierwszej fazie zarówno certyfikaty do szyfrowania danych/transmisji oraz podpisywanie użytkowników podpisem niekwalifikowanym. disi@pomorskie.eu, Strona 45 z 212

46 W ramach działań projektowych w podmiotach klasy C i D planowane jest rozbudowanie i modernizacja infrastruktury do standardów technicznych określonych w poszczególnych rozdziałach niniejszego opracowania. Dodatkowo, w ramach modernizacji infrastruktury planowane jest dokonanie wymiany sprzętu i oprogramowania w poszczególnych jednostkach. 3.9 Architektura rozwiązania PeZ dla podmiotów klasy A i B Opis architektury podmiotów klasy A i B przedstawiony jest na poniższym rysunku. Rysunek 3-8: Architektura rozwiązania PeZ dla podmiotów klasy A i B disi@pomorskie.eu, Strona 46 z 212

47 Zgodnie z zaprezentowanym ogólnym podejściem, podmioty klasy A i B będą posiadać własną infrastrukturę sprzętową, w tym podmioty klasy A w minimum dwóch serwerowniach, a podmioty B w jednej dużej serwerowni, która będzie bazą dla działania systemów informatycznych wspierających procesy w części białej oraz dla części szarej podmiotu leczniczego. Usługi ze strony GCPD podmiotów klasy A i B będą skoncentrowane na poziomie usług regionalnych. W ten sposób, podmiot leczniczy klasy A i B będzie miał dostęp do systemów regionalnych PeZ w zakresie rozwiązania portalowego, systemu zarządzania jakością, systemu zapobiegania nadużyciom, BI, archiwum długoterminowego, hostingu i dostępu do e-usług. Dodatkowo, zgodnie z podejściem i wizją kompleksową, EDM podmiotu leczniczego klasy A i B będzie replikować się do EDM regionalnego. Podmioty będą też korzystały ze wspólnego dostępu do sieci Internet udostępnianej przez WAN PeZ z GCPD. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło łącze Internetowe. Placówki będą posiadały u siebie lokalne CA służące w połączeniu z eidas i epuap do podpisywania elektronicznej dokumentacji medycznej. Podpis będzie dostępny na karcie, która wraz z certyfikatem do SSO będzie podstawowym elementem dla logowania do domeny. System będzie też otwarty na ewentualną możliwość podpięcia innego typu podpisu pod dokumentacją w razie zmiany przepisów. PKI (CA) będzie wykorzystywane jako opcja dla e-puap i eidas, jednak w infrastrukturze PeZ będzie CA główne, mające swoje odnogi we wszystkich PL za wyjątkiem PL klasy E. Regionalne CA będzie działało jak Root CA. Założenie oddzielnego Root CA wdrażanego w ramach projektu PeZ zapewni w pierwszej fazie zarówno certyfikaty do szyfrowania danych/transmisji oraz podpisywanie użytkowników podpisem niekwalifikowanym. Kolejny rodzaj usług świadczonych przez GCPD na rzecz podmiotów A i B to archiwum długoterminowe EDM. W ramach działań projektowych w podmiotach klasy A i B planowane jest rozbudowanie i modernizacja infrastruktury do standardów technicznych określonych w poszczególnych rozdziałach niniejszego opracowania. Dodatkowo, w ramach modernizacji infrastruktury planowane jest dokonanie wymiany sprzętu i oprogramowania w poszczególnych jednostkach. disi@pomorskie.eu, Strona 47 z 212

48 4 Sieci teleinformatyczne, sieci zasilania gwarantowanego, dostęp do Internetu PL i SWP Klauzula generalna: W zależności od uzasadnionych i uzgodnionych potrzeb uczestników Projektu PeZ wymagania Koncepcji Techniczno-Technologicznej mogą w przyszłości ulec zmianie/modyfikacji/doprecyzowaniu w specyfikacji opisu przedmiotu zamówienia dla poszczególnej kategorii zamówienia. Zgodnie z ogólną koncepcją architektury, gdzie występuje GCPD, jako centralny węzeł dla rozwiązań informatycznych w obszarze projektu PeZ, a także poszczególne PL ze zróżnicowanym poziomem infrastruktury sieciowej, w dalszej części podrozdziału opisane zostały koncepcje organizacji infrastruktury poziomu sieciowego dla każdego z typów podmiotów leczniczych. Ogólne założenia w obszarze sieciowym to: standaryzacja sieci LAN (kategoria, urządzenia pasywne i aktywne) wraz z budową sieci zasilania gwarantowanego, standaryzacja sieci SAN, budowa sieci WAN PeZ na potrzeby projektu Pomorskie e-zdrowie, ujednolicenie dostępu do Internetu. 4.1 Obszar okablowania strukturalnego Podczas procesu inwentaryzacji w większości podmiotów stwierdzono brak zgodności okablowania strukturalnego w części lub w całości z kategorią 5e, dla okablowania budynkowego. W związku z powyższym w ramach projektu PeZ przewidziano modernizację/budowę okablowania światłowodowego i miedzianego, a następnie jego certyfikację. W niektórych jednostkach konieczna jest również budowa kanalizacji teletechnicznej. Przyjęto standard budowy okablowania w oparciu o kable światłowodowe jednomodowe i wielomodowe (okablowanie pionowe oraz szkieletowe) oraz kable miedziane ekranowane spełniające normę kat. min. 6A (okablowanie poziome). 4.2 Obszar sieci zasilania gwarantowanego Zgodnie z Rozporządzenia Ministra Infrastruktury z dnia 12 kwietnia 2002 roku w sprawie warunków technicznych jakim powinny odpowiadać budynki i ich usytuowanie (Dz.U. nr 75/2002, disi@pomorskie.eu, Strona 48 z 212

49 poz. 690 z późniejszymi zmianami) budynek, w którym zanik napięcia w elektrycznej sieci zasilającej może spowodować zagrożenie życia lub zdrowia ludzi, poważne zagrożenie, a także znaczne straty materialne, należy zasilić co najmniej z dwóch niezależnych źródeł energii elektrycznej. Szpitale i inne obiekty opieki zdrowotnej prowadzące działania medyczne wymagają dużej gwarancji zasilania i zapewnienia bezpieczeństwa pacjentów, personelu, urządzeń i procedur. Oznacza to na ogół konieczność zastosowania kilku źródeł zasilania (podstawowego, rezerwowego i awaryjnego). Źródłami podstawowymi i rezerwowymi są z reguły osobne stacje transformatorowe, przyłącza do linii elektroenergetycznych średniego napięcia geograficznie rozdzielonych i zasilanych w miarę możliwości z różnych GPZ (Głównych Punktów Zasilania). Źródłem zasilania awaryjnego najczęściej jest zespół spalinowo-elektryczny. Źródła zasilania i układ zasilania w obiektach medycznych powinny być dostosowane do wymaganego stopnia niezawodności. Ze względu na konieczność optymalizacji rozwiązania, architektura PeZ została dostosowana do potrzeb poszczególnych podmiotów leczniczych. W większości podmiotów leczniczych objętych projektem PeZ brakuje wydzielonych instalacji zasilania gwarantowanego dla systemów IT. W związku z powyższym należy przewidzieć budowę układu zasilania gwarantowanego dla każdej nich. Instalacja zasilania gwarantowanego rezerwowana urządzeniami UPS i agregatem prądotwórczym, będzie zasilała urządzenia znajdujące się w serwerowni, urządzenia łączności bezprzewodowej oraz komputery. Urządzenia sieci LAN w tym urządzenia łączności bezprzewodowej oraz komputery systemów informatycznych zaliczają się do odbiorów wymagających bezprzerwowego zasilania gwarantowanego (I kategorii). Odbiory kategorii I powinny być zasilane poprzez dedykowane instalacje i systemy elektryczne. Kompletny, nowoczesny system zasilania podmiotu leczniczego typu A i B powinien zawierać rezerwowe źródło zasilania agregat prądotwórczy oraz UPS. Agregat prądotwórczy powinien posiadać zdolność wytwarzania napięcia o odpowiednich parametrach przez wyznaczony okres podczas zaniku zasilania podstawowego. Do czasu dostarczenia napięcia o odpowiednich parametrach (od kilku do kilkunastu minut) źródłem zasilania są baterie UPS. UPS ma również za zadanie dostarczyć zasilanie w przypadku obniżenia parametrów napięcia z podstawowego źródła. System zasilania gwarantowanego poza podstawowym zadaniem dostarczania zasilania ma również za zadnie chronić odbiory przed chwilowymi wahaniami amplitudy, udarami napięciowymi, szumami, zakłóceniami impulsowymi, wahaniami częstotliwości, przepięciami łączeniowymi, odkształceniami harmonicznymi napięcia i prądu. Poniższy rysunek przedstawia schemat systemu zasilania gwarantowanego obiektu szpitalnego. disi@pomorskie.eu, Strona 49 z 212

50 Rysunek 4-1: Schemat systemu zasilania gwarantowanego obiektu szpitalnego Opis rozwiązań dla poszczególnych typów PL opisano poniżej. Podmioty klasy E ze względu, iż nie mają przewidzianej serwerowni, zostaną wyposażone jedynie w UPS podtrzymujące zasilanie dla urządzeń stanowiskowych i drobnych urządzeń sieci LAN. Podmioty klasy C i D będą posiadać zabezpieczenia UPS oraz agregat prądotwórczy (jako opcjonalne rozwiązanie) w przypadku, gdy ciągłość świadczenia usług medycznych jest wymagana (np. pogotowie ratunkowe). Sieci komputerowe oraz wyznaczone systemy wspomagania i kontroli procesów w podmiocie leczniczym typu C i D będą zasilane przez dedykowane instalacje i systemy elektryczne. Kompletny, nowoczesny system zasilania podmiotu leczniczego klasy C i D będzie zawierać rezerwowe źródło - zasilacz UPS. Zasilacz UPS będzie miał za zadanie dostarczyć zasilanie w przypadku obniżenia parametrów napięcia z podstawowego źródła również za zadnie chronić odbiory przed chwilowymi disi@pomorskie.eu, Strona 50 z 212

51 wahaniami amplitudy, udarami napięciowymi, szumami, zakłóceniami impulsowymi, wahaniami częstotliwości, przepięciami łączeniowymi, odkształceniami harmonicznymi napięcia i prądu. Podmioty typu A i B będą wyposażone w instalację zasilania gwarantowanego przyłączoną do obwodów zasilania podstawowego, zapasowego i awaryjnego. Urządzenia przyłączone do instalacji będą pracować bezprzerwowo w przypadku zaniku napięcia w obwodzie zasilania podstawowego i zapasowego. W przypadku dłuższej przerwy w dostawie energii elektrycznej, służby techniczne podmiotu poinformują o braku możliwości pracy komputerów poszczególnych użytkowników z uwagi na ograniczenie poboru mocy. Układ zasilania gwarantowanego będzie złożony z dedykowanej instalacji elektrycznej zasilającej gniazda wtyczkowe typu DATA dla bezpieczeństwa oznaczone kolorem czerwonym, zasilacza UPS który będzie zapewniał zasilanie w czasie przełączania automatyki SZR (Samoczynne Załączanie Rezerwy) oraz agregatu prądotwórczego stanowiącego źródło zasilania awaryjnego. Instalacja zasilania gwarantowanego będzie wybudowana dedykowanymi obwodami przyłączonymi do wydzielonej rozdzielnicy elektrycznej w pomieszczeniach z zamontowanymi UPS ami. Rozdzielnice instalacji zasilania gwarantowanego zostaną przyłączone WLZ ami (Wewnętrzna Linia Zasilająca) do rozdzielnicy głównej z zamontowanym w niej SZR. W przypadku braku agregatu prądotwórczego lub jego niewystarczającej mocy, należy zakupić agregat i wyposażyć go w systemy automatyki i monitorowania pracy agregatu. Przy zakupie należy pamiętać, że poza automatyką i systemami monitorowania należy agregat wyposażyć w zbiorniki oleju napędowego o pojemności zapewniającą nieprzerwaną pracę zespołu pod pełnym obciążeniem w czasie minimum 24h. 4.3 Obszar sieci WLAN Sieci WLAN zapewniają wszystkie funkcje realizowane przez tradycyjne sieci LAN, nie wymagając instalowania okablowania. Posiadają niezaprzeczalne zalety związane z możliwością dowolnego przemieszczania użytkowników w obrębie swojego działania. Zintegrowane rozwiązania WLAN umożliwiają pracownikowi, poruszającemu się po całym terenie podmiotu, dostęp do różnego rodzaju informacji specyficznych dla danego podmiotu czy też komunikowanie się ze światem poprzez sieć Internet. Z drugiej zaś strony niosą one ze sobą szereg mniej lub bardziej znanych zagrożeń specyficznych dla rozwiązań bezprzewodowych, tym większych im technologie te stają się powszechniejsze. Stworzenie rozwiązania wykorzystującego pełne możliwości sieci bezprzewodowych WLAN w wersji AC oraz oferującego wysoki poziom bezpieczeństwa informacji wymaga rozważenia wszystkich kluczowych elementów już na etapie projektowania sieci. Do elementów tych należy z jednej strony infrastruktura, konfiguracja, niezawodność oraz możliwość przyszłego rozwoju projektowanego systemu z drugiej zaś strony zagadnienia takie jak bezpieczeństwo transmisji czy disi@pomorskie.eu, Strona 51 z 212

52 uwierzytelnianie i autoryzacja zarówno użytkowników jak i sprzętu. Nie mniej ważnym elementem jest zaprojektowanie, wdrożenie oraz monitorowanie polityki bezpieczeństwa. Koncepcja budowy sieci WLAN w PL zakłada na etapie przetargu wykonanie przez Wykonawcę: przeprowadzenie pomiarów sieci WLAN oraz przegląd dokumentacji budynkowej i na ich podstawie wykonanie projektu technicznego rozmieszczenia urządzeń Access Point (AP) w PL, doprowadzenie okablowania strukturalnego do każdego z AP, zasilanie punktów dostępu poprzez PoE z urządzeń aktywnych sieci, uruchomienie sieci w standardach AC, wdrożenie scentralizowanego modelu zarządzania wszystkimi punktami dostępowymi sieci WLAN z możliwością zastosowania 2 kontrolerów, uruchomienie na urządzeniach dedykowanych sieci (multi ssid) np. sieć biurowa, sieć dla gości, sieć dedykowana dla tabletów medycznych itd., zapewnienie roaming u pomiędzy punktami dostępowymi, wsparcie dla mechanizmów szyfrowania WPA2 w wersji Infrastucture, opartych o serwer RADIUS lub usług katalogowych z własną bazą danych dla rejestracji adresów MAC, autoryzację użytkowników w oparciu o protokół 802.1x, w przypadku części sieci dedykowanych uwierzytelnianie pracowników w oparciu o konto i hasło z usług katalogowych, wdrożenie funkcjonalności captive portalu dla gości, z potwierdzeniem regulaminu i limitowaniem czasu i prędkości połączenia, rozłożenie obciążenia ruchu z sieci WLAN pomiędzy kontrolery, możliwość przydziału odpowiedniego pasma użytkownikowi poprzez wbudowany trafficshaper, pracę w warstwie 3 modelu OSI, monitorowanie wydajności sieci WLAN. Kontrolery wraz z opcjonalnymi serwerami usługowymi będą odpowiadać za przechowywanie i udostępnianie konfiguracji wszystkich urządzeń radiowych, segmentację logiczną sieci, realizację polityk bezpieczeństwa i profili usługowych dla różnych grup użytkowników, badanie aktywności użytkowników, wykrywanie intruzów oraz optymalizację wykorzystania pasma radiowego poprzez dynamiczną adaptację do zmian w czasie rzeczywistym. Zaletą takiego scentralizowanego modelu zarządzania jest łatwość wprowadzania globalnych zmian konfiguracyjnych dla całej sieci bezprzewodowej oraz automatyzacja wybranych czynności, za które w systemach rozproszonych odpowiedzialny jest administrator. Infrastruktura zarządzana centralnie pozwala na szybkie i efektywne diagnozowanie problemów zaś jej rozbudowa sprowadza się jedynie do fizycznego disi@pomorskie.eu, Strona 52 z 212

53 podłączenia nowych punktów dostępowych do kablowej sieci transportowej zapewniającej komunikację z kontrolerem oraz wyjście do Internetu. W podmiotach klasy E planuje się sieć tradycyjną LAN oraz zostanie uruchomiona sieć WLAN. Poniżej na rysunku przedstawiono koncepcję architektury sieci WLAN w PL. Rysunek 4-2: Koncepcja konfiguracji WLAN w PL W ramach projektu PeZ infrastruktura WLAN może być wykorzystywana do realizacji dedykowanych sieci: dla pacjentów, tabletów medycznych, komputerów pracowników PL itd. PL klasy E będą wykorzystywały sieć WLAN jako główną sieć połączenia ze sobą komputerów w sieci LAN. PL 06 (Centrum Zdrowia Psychicznego w Słupsku) jako podmiot klasy E również wpisuje się w powyższą koncepcję jednak jego pośrednikiem do GCPD, będzie PL 07 (Wojewódzki Szpital Specjalistyczny im. Janusza Korczaka w Słupsku Sp. z o.o.) jako minigcpd. 4.4 Obszar sieci LAN Struktura (część pasywna) oraz architektura (elementy aktywne) sieci LAN w PL powinny zostać zmodernizowane w celu uzyskania parametrów niezbędnych do wdrożenia aplikacji i usług projektu PeZ oraz pozbycia się potencjalnych zagrożeń/ wąskich gardeł istniejących w PL. disi@pomorskie.eu, Strona 53 z 212

54 4.4.1 Założenia i analiza istniejących rozwiązań w PL Przyjęte założenia: urządzenia aktywne, które są wsteczne dwie generacje w tył podlegają wymianie, okablowanie w PL zostanie wykonane zgodnie z zaleceniami opisanymi w ppkt Poniżej opisane są główne koncepcje zmian w obrębie obszaru sieci obejmujące: migrację do sieci LAN w pełni przełączanej i zarządzanej, stosowanie architektury dwuwarstwowej sieci - przełączników core/agregujących i przełączników dostępowych, zarówno w serwerowni jak i do podłączenia komputerów w sieci, wyeliminowanie użytkowania urządzeń niewspieranych przez producentów lub/i serwis zewnętrzny), podłączanie przełączników w pośrednich punktach dystrybucyjnych poprzez dwie drogi światłowodowe z węzłem nadrzędnym z wykorzystaniem redundantnych urządzeń pracujących w trybie failover, wprowadzenie redundantnych przełączników warstwy trzeciej w części centralnej core (rdzeniu sieci), agregujących i rozsyłający ruch w sieci, pozwalających na stworzenie sieci zdolnej do szybkiej rekonfiguracji w przypadku awarii, przypisanie użytkowników do sieci VLAN, podział grup roboczych, oraz konfigurację reguł wymiany informacji pomiędzy nimi, wprowadzenie dodatkowych mechanizmów pozwalających na skuteczne zapobieganie niepożądanym sytuacjom w krytycznych segmentach sieci, wdrożenie mechanizmów zapewnienia jakości usług dla krytycznych aplikacji sieciowych oraz dla ochrony przed atakami hackerów, odpowiednią konfigurację urządzeń sieciowych w celu ograniczenia dostępu do interfejsu administracyjnego dla ściśle określonej grupy administratorów, wprowadzenie narzędzi zarządzania siecią pozwalających na monitorowanie parametrów sieci w czasie rzeczywistym, usprawnienie polityki monitorowania urządzeń sieciowych celem unikania sytuacji niepożądanych, stosowanie filtracji pomiędzy VLANami poprzez dedykowane urządzenia firewall/utm, stosowanie filtracji pomiędzy siecią WAN PeZ oraz rezerwowym łączem Internet, a siecią w podmiocie, sieć PeZ WAN i publiczna sieć Internet będą wpięta w ten sam router, disi@pomorskie.eu, Strona 54 z 212

55 stosowanie na brzegu sieci urządzeń routujących do WAN PeZ oraz publicznego łącza Internet (łącze zapasowe). Rysunek 4-3: Koncepcja sieci LAN w PL disi@pomorskie.eu, Strona 55 z 212

56 Dla uzyskania pożądanego poziomu wydajności i ciągłości działania sieci LAN oraz gwarancji niezawodności krytycznych aplikacji działających w tej sieci zalecane jest zastosowanie powyższej architektury sieci LAN Koncepcja sieci teleinformatycznych dla PL klasy E Koncepcja sieci teleinformatycznych dla podmiotów leczniczych nieposiadających pomieszczeń serwerowni przedstawiona jest na rysunku poniżej (Rysunek 4-4). Rysunek 4-4: Koncepcja sieci teleinformatycznych dla podmiotów medycznych typu E Założeniem tej koncepcji jest posiadanie przez podmiot leczniczy wewnętrznej sieci LAN w charakterze sieci WLAN jako sieci dostępowej w drugiej warstwie, która jest połączona z siecią wewnętrzną w GCPD bezpośrednio poprzez łącze LAN w WAN PeZ. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło łącze Internetowe opcjonalne. Sieć WLAN będzie przyłączona do switcha core, który będzie przyłączony do GCPD poprzez wkładki SFP+, kontrolery znajdą się w GCPD (lub PL) i będą obsługiwać wszystkie PL klasy E Koncepcja sieci teleinformatycznych dla PL typu D Koncepcja sieci teleinformatycznych dla podmiotów leczniczych z jedną serwerownia przedstawiona jest na rysunku poniżej (Rysunek 4-5). disi@pomorskie.eu, Strona 56 z 212

57 Rysunek 4-5: Koncepcja sieci teleinformatycznych dla podmiotów medycznych typu D Założeniem koncepcji jest posiadanie jednorodnej, wewnętrznej i nowoczesnej wewnętrznej sieci LAN, kategorii min. 6A przez PL. Sieć ta służy do wewnętrznej komunikacji z systemami umieszczonymi w podmiocie leczniczym. W PL ze względu na umieszczenie duplikatów serwerów w jednej serwerowni obok sieci, systemy nie będą komunikowały się poprzez sieć SAN. Do podłączenia macierzy danych i NAS zostaną użyte połączenia bezpośrednie SAS i iscsi. Połączenia z komputerami, drukarkami i innymi urządzeniami będą wykonywane linkami 1GE w technologii miedzianej. Przełączniki dystrybucyjne będą wyposażone w PoE+ do zasilania urządzeń WLAN. Cała jednostka będzie połączona z siecią w GCPD poprzez sieć WAN PeZ. Komunikacja poprzez WAN PeZ jest ustanowiona poprzez technologię MVPN/MPLS/VPLS z infrastrukturą danego podmiotu leczniczego, która jest współdzielona z pozostałymi systemami umieszczonymi w GCPD lub z usługami, oferowanymi przez GCPD. Sieć zostanie podzielona na VLANy, pomiędzy którymi ruch będzie filtrowany i routowany poprzez firewall/utm sprzętowy. VLANy będą odseparowywały sieć serwerową, bazodanową, sieć urządzeń medycznych PACS/RIS, sieć WLAN, sieć Internetową, sieć publiczną dla połączeń SSID, sieć tabletów, sieć stacji PC itp. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło opcjonalne łącze Internetowe Koncepcja sieci teleinformatycznych dla PL typu C Koncepcja sieci teleinformatycznych dla podmiotów leczniczych z jedną serwerownią przedstawiona jest na rysunku poniżej. disi@pomorskie.eu, Strona 57 z 212

58 Rysunek 4-6: Koncepcja sieci teleinformatycznych dla podmiotów medycznych typu C Założeniem koncepcji jest posiadanie jednorodnej, wewnętrznej i nowoczesnej wewnętrznej sieci LAN, kategorii min. 6A przez PL. Sieć ta służy do wewnętrznej komunikacji z systemami umieszczonymi w podmiocie leczniczym. W PL ze względu na umieszczenie duplikatów serwerów w jednej serwerowni obok sieci, systemy nie będą komunikowały się poprzez sieć SAN. Do podłączenia macierzy danych i NAS zostaną użyte połączenia bezpośrednie SAS i iscsi. Przełączniki dystrybucyjne będą połączone z przełącznikiem agregującym każdy dwoma linkami 10GE, po jednym do każdego z przełączników agregujących w technologii światłowodowej mieszanej. Dla połączeń wyższych niż 300m połączenia będą wykonywane w technologii jednomodowej. Połączenia z komputerami, drukarkami i innymi urządzeniami będą wykonywane linkami 1GE w technologii miedzianej. Przełączniki dystrybucyjne będą wyposażone w PoE+ do zasilania urządzeń WLAN. Cała jednostka będzie połączona z siecią w GCPD poprzez sieć WAN PeZ. Komunikacja poprzez WAN PeZ jest ustanowiona poprzez technologię MVPN/MPLS/VPLS z infrastrukturą danego podmiotu leczniczego. Sieć zostanie podzielona na VLANy, pomiędzy którymi ruch będzie filtrowany i routowany poprzez router. VLANy będą odseparowywały sieć serwerową, bazodanową, sieć części białej i szarej, sieć WLAN, sieć Internetową, sieć publiczną dla połączeń SSID, sieć tabletów, sieć stacji PC itp. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło opcjonalne łącze Internetowe Koncepcja sieci teleinformatycznych dla PL B Koncepcja sieci teleinformatycznych dla podmiotów leczniczych z jedną serwerownia przedstawiona jest na rysunku poniżej. disi@pomorskie.eu, Strona 58 z 212

59 Rysunek 4-7: Koncepcja sieci teleinformatycznych dla podmiotów medycznych typu B Założeniem koncepcji jest posiadanie jednorodnej, wewnętrznej i nowoczesnej wewnętrznej sieci LAN, kategorii min. 6A przez PL. Sieć ta służy do wewnętrznej komunikacji z systemami umieszczonymi w podmiocie leczniczym. W PL ze względu na umieszczenie duplikatów serwerów w jednej serwerowni obok sieci, systemy nie będą komunikowały się poprzez sieć SAN. Do podłączenia macierzy danych i NAS zostaną użyte połączenia bezpośrednie SAS i iscsi. Dla PL klasy B sieć LAN będzie oparta o przełączniki 10GE, gdzie przełączniki pomiędzy sobą będą używały dwóch połączeń SFP/SFP+/QSFP. Do połączenia z przełącznikami dostępowymi w serwerowni zostaną użyte połączenia SFP/SFP+/QSFP po jednym z każdego przełącznika dostępowego do każdego z przełączników rdzenia sieci. Połączenia z serwerami będą odbywały się za pomocą portów 10GE. Przełączniki dystrybucyjne będą połączone z przełącznikiem agregującym każdy dwoma linkami 10GE, po jednym do każdego z przełączników agregujących w technologii światłowodowej. Dla połączeń wyższych niż 300m połączenia będą wykonywane w technologii jednomodowej. Połączenia z komputerami, drukarkami i innymi urządzeniami będą wykonywane linkami 1GE w technologii miedzianej. Przełączniki dystrybucyjne będą wyposażone w PoE+ do zasilania urządzeń WLAN. Cała jednostka będzie połączona z siecią w GCPD poprzez sieć WAN PeZ. Komunikacja poprzez WAN PeZ będzie ustanowiona poprzez technologię MVPN/MPLS/VPLS z infrastrukturą danego podmiotu leczniczego Sieć zostanie podzielona na VLANy, pomiędzy którymi ruch będzie filtrowany i routowany poprzez firewall/utm sprzętowy. Brzeg sieci będzie wyposażony w szyfratory VPN. VLANy będą odseparowywały sieć serwerową, bazodanową, sieć urządzeń medycznych PACS/RIS, sieć WLAN, sieć Internetową, sieć publiczną dla połączeń SSID, sieć tabletów, sieć stacji PC itp. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło opcjonalne łącze Internetowe Koncepcja sieci teleinformatycznych dla PL typu A disi@pomorskie.eu, Strona 59 z 212

60 Koncepcja sieci teleinformatycznych dla podmiotów leczniczych posiadających redundantne pomieszczenia serwerowni przedstawiona jest na rysunku poniżej (Rysunek 4-8). Rysunek 4-8: Koncepcja sieci teleinformatycznych dla podmiotów leczniczych typu A W tej koncepcji, całość infrastruktury sieciowej oparta jest na wewnętrznej sieci LAN, która może składać się z kilku podsieci, a także celem zapewnienia odpowiedniego poziomu dostępności systemów umieszczonych będzie składać się z osobno skonfigurowanej sieci SAN. Sieć LAN będzie się składać z segmentów kategorii min 6A, ale w przypadku, jeżeli jest to akceptowalne z punktu widzenia bezpieczeństwa oraz wydajności pracy, z odpowiednio zabezpieczonych segmentów sieci WLAN. Większość usług systemów informatycznych będzie świadczona w obrębie podmiotu leczniczego. Usługi IT z GCPD będą jedynie w obszarze rozwiązań poziomu regionalnego. Poprzez łącze WAN będzie możliwy także dostęp do usług Disaster Recovery dla krytycznych systemów danego podmiotu leczniczego. Dla sieci SAN i LAN ze względu, iż urządzenia sieci SAN i LAN będą znajdowały się w dwóch serwerowniach, pomiędzy serwerowniami zostanie wykonane połączenie kablem światłowodowym jednomodowym o wielkości przewidzianej w projekcie technicznym. W przypadku kiedy serwerownie znajdują się w innych budynkach oddalonych od siebie np. PL 12.1, do połączenia pomiędzy serwerowniami zostanie wynajęte łącze o gęstości 8j ciemnego światłowodu. W tym 4j dla połączenia FC i 4j do połączenia 40/10GE dla przełączników rdzeniowych. Sieci SAN zostaną oparte na przełącznikach SAN o prędkościach portów 16Gbit. Sieć LAN zostanie zbudowana z minimum dwóch przełączników agregujących rdzenia sieci o prędkości rdzenia 40/10GE i minimum 6 portów 40/10GE. Porty zostaną użyte w następujący sposób: Dla PL 12.1 i 19.2: 2 porty 40/10GE do połączenia przełączników między sobą w każdej z trzech serwerowni podmiotu, disi@pomorskie.eu, Strona 60 z 212

61 1 port z każdego przełącznika do połączenia z innym przełącznikiem rdzeniowym w sąsiedniej serwerowni do połączenia trzech serwerowni w ringu, 2 porty 40/10GE do połączenia każdego z przełączników dostępowych serwerowych, po 1 porcie 10GE do połączenia z przełącznikami dystrybucyjnymi w każdej z lokalizacji. Dla PL07 : 2 porty 40/10GE do połączenia przełączników między sobą w każdej z serwerowni podmiotu, 2 porty z każdego przełącznika do połączenia z innym przełącznikiem rdzeniowym w sąsiedniej serwerowni, 2 porty 40/10GE do połączenia każdego z przełączników dostępowych serwerowych, po 1 porcie 10GE do połączenia z przełącznikami dystrybucyjnymi w każdej z lokalizacji. Połączenia w serwerowni do urządzeń LAN będą odbywały się portami 10GE o liczbie portów 2x40/10GE, 48x10/1GE). Połączenia przełączników dystrybucyjnych z urządzeniami komputerowymi będą odbywały się połączeniami 1GE w technologii miedzianej z PoE+. Przełączniki te będą uniwersalne i będą posiadać 48 portów GE PoE+ i dwa porty SFP+ 10GE SR lub LR. Rdzeń sieci i połączenia w serwerowni będą odbywały się po światłowodzie wielomodowym. Połączenia pomiędzy rdzeniem sieci a przełącznikami dystrybucyjnymi będą odbywały się po jednym linku 10GE z każdego z przełączników agregujących w technologii światłowodowej. Sieć zostanie podzielona na VLANy, pomiędzy którymi ruch będzie filtrowany i routowany poprzez firewall/utm sprzętowy. VLANy będą odseparowywały sieć serwerową, bazodanową, sieć urządzeń medycznych PACS/RIS, sieć WLAN, sieć Internetową, sieć publiczną dla połączeń SSID, sieć tabletów, sieć stacji PC itp. Cała jednostka będzie połączona z siecią w GCPD poprzez sieć WAN PeZ. Sieć zostanie podzielona na VLANy, pomiędzy którymi ruch będzie filtrowany i routowany poprzez firewall/utm sprzętowy. Brzeg sieci będzie wyposażony w szyfratory VPN. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło opcjonalne łącze Internetowe Koncepcja sieci teleinformatycznych dla GCPD i DR Ze względu na planowane zlokalizowanie części infrastruktury teleinformatycznej w GCPD i DR wraz ze świadczonymi na niej usługami na poziomie lokalnym i regionalnym na rzecz PL oraz podmiotów zewnętrznych, sieć serwerowa powinna charakteryzować się wysokim poziomem niezawodności i wydajności. Sieć ta powinna cechować się maksymalną odpornością na niespodziewane przerwy w pracy zarówno na poziomie urządzeń jak i łączy danych (Internet, WAN PeZ). Aby zapewnić dodatkowy poziom dostępności świadczonych usług i ciągłość działania systemów produkcyjnych, zalecane jest uruchomienie dodatkowej redundantnej serwerowni DR w innej lub tej samej co GCPD lokalizacji. disi@pomorskie.eu, Strona 61 z 212

62 Oprócz redundancji obu serwerowni niezbędne jest zwielokrotnienie sprzętu w każdej z nich, tak aby w razie awarii jednego z urządzeń, nastąpiło automatyczne przekazanie jego roli do urządzenia sprawnego. Dzięki takiemu podejściu możemy uniknąć pojedynczego punktu awarii (Single Point of Failure) w sieci komputerowej. Istnieje kilka trybów DR (Zapasowe Centrum Przetwarzania Danych). W zależności od potrzeb może to być: rola w większości pasywna, ograniczająca się do reaktywnego uruchomienia zasobów z podstawowego CPD w przypadku jego awarii w tym przypadku wszystkie urządzenia umieszczone w tej lokalizacji pracują w trybie oczekiwania na incydent, rola mieszana, w której oprócz funkcji zapasowej istniejąca infrastruktura mogłaby również być wykorzystywana do uruchamiania maszyn w nieawaryjnych sytuacjach w grę mogłoby wchodzić np. zastosowanie dla celów środowiska testowego i deweloperskiego, pełna konfiguracja active-active, w której dodatkowo podstawowe CPD pełniłoby rolę zapasową dla maszyn produkcyjnych pracujących w dotychczasowym CPD. Rekomendowane jest aby DR pracowało w roli pasywnej. W GCPD i DR zostaną zainstalowane po 2 przełączniki rdzeniowe o liczbie portów 6x40/10GE i 48x10GE. 2 porty 40/10GE będą służyły do połączenia przełączników między sobą, 2 porty 40/10GE po jednym z każdego z przełączników będzie służył do połączenia z przełącznikami rdzeniowymi w DR. Porty 10GE SFP+ SR będą służyły do podłączenia urządzeń i serwerów. Dodatkowe porty 40/10GE będą służyły do podłączenia dodatkowych przełączników 40/10GE. Przełączniki FC będą ze sobą połączone linkami 16 G FC poprzez WAN PeZ oraz z urządzeniami serwerowymi i macierzami połączeniami z każdego z przełączników FC do każdego z serwerów i macierzy tak aby do każdego z serwerów istniały minimum dwa linki z każdego z przełączników. Routery, firewalle/utmy, szyfratory VPN DLP zostaną połączone portami SFP+. Systemy baz danych mogą pracować w oparciu o własny VLAN infrastruktury całego projektu PeZ. Wszystkie systemy pracujące wirtualnie, łącznie z serwerami usługi katalogowej, LDAP i systemem PKI powinny pracować jako maszyny wirtualne. disi@pomorskie.eu, Strona 62 z 212

63 Rysunek 4-9. Zalecana architektura sieci w GCPD i DR disi@pomorskie.eu, Strona 63 z 212

64 Szafy RACK zarówno w jednym jak i drugim centrum powinny zostać wyposażone w przełączniki LAN i SAN. Ze względu na małą liczbę połączeń LAN i SAN do serwerów, przełączniki dostępowe powinny zostać instalowane bezpośrednio w tych szafach. Połączenia z serwerami, macierzami danych z przełącznikami powinny być wykonywane duplikowanymi linkami 10GE i 16 FC w technologii światłowodowej. Serwery powinny być wyposażone w wiele portów na różnych kartach tak, aby można było duplikować połączenia sieciowe. 4.5 Obszar sieci WAN PeZ W ramach projektu PeZ powstanie sieć (WAN PeZ) dostępowa pozwalająca na komunikację pomiędzy wszystkimi podmiotami uczestniczącymi w projekcie. Powstająca sieć będzie miała co najmniej 18 punktów dostępowych. Charakteryzować się ona będzie dużą elastycznością konfiguracji i możliwością dalszej rozbudowy. Ze względu na możliwości technologiczne i biznesowe oraz dostępność w obszarze województwa pomorskiego sieci o różnych technologiach, ze względu na potrzeby projektu sieć WAN została podzielona na poszczególne kategorie: sieć światłowodowa w przypadku połączenia GCPD z DR, sieć MVPN poprzez Internet i/lub dedykowane zasoby sieci operatorskich, sieć Internet dla GCPD/DR o prędkości 10/5Gbit. Kluczowym elementem infrastruktury sieci WAN PeZ i jej głównym zadaniem jest połączenie: GCPD z DR, każdego z PL klasy A, B, C, D, E szyfrowaną siecią MVPN z GCPD i DR, Placówek PL07, PL12.1, PL19.2 między sobą. Podmioty będą posiadały łącza, które za pomocą sprzętowych systemów UTM będą łączyły się poprzez MVPN do GCPD lub DR na zasadzie load balancingu. Łącza takie powinny wtedy zostać wpięte w router brzegowy podmiotu lub UTM. Podmioty kategorii A i B ze względu na swoją specyfikę, mają niskie zapotrzebowanie na dostęp do usług świadczonych przez GCPD. Głównym zadaniem jest dostęp do e-usług, wymiany danych w zakresie EDM oraz przechowywanie kopii archiwów. Do tego celu wystarczy łącze Internetowe o prędkości minimum 200Mbit (1Gbit dla PL klasy A) i utworzone silnie szyfrowane połączenie wirtualnej sieci prywatnej w sieci MPLS. Do łączności VPN zostaną przeznaczone karty akceleratorów VPN/WAN PeZ jako część składowa routerów brzegowych podmiotów i GCPD/DR. Połączenia będą mogły odbywać się naprzemiennie do GCPD i DR w przypadku awarii GCPD. Umiejscowienie geograficzne podmiotów znajduje się na disi@pomorskie.eu, Strona 64 z 212

65 poniższej mapce w postaci czarnych punktów. Rolę łącza zapasowego (publicznego) do GPCD będzie pełniło opcjonalne łącze Internetowe. Rysunek Umiejscowienie geograficzne podmiotów o dostępie Internetowym do GCPD w sieci WAN. 4.6 Obszar sieci SAN W ramach projektu PeZ powstaną sieci SAN w następujących lokalizacjach: GCPD, DR (1 sieć obejmująca obydwa ośrodki przetwarzania) oraz dedykowane sieci w PL klasy A. Koncepcja sieci SAN zakłada, że będzie ona zapewniała komunikację pomiędzy infrastrukturą serwerową, a przestrzenią dyskową udostępnianą przez macierze. Szafy RACK zarówno w jednym jak i drugim centrum powinny zostać wyposażone w przełączniki LAN i SAN. Ze względu na stosowanie dużych serwerów i małą liczbę połączeń LAN i SAN do tych serwerów, przełączniki dostępowe powinny zostać instalowane bezpośrednio w tych szafach. Przełączniki na każdą szafę powinny zostać disi@pomorskie.eu, Strona 65 z 212

66 duplikowane i łączone minimum z dwoma innymi przełącznikami agregującymi linkami minimum 2x40/10GE w technologii światłowodowej. Połączenia z serwerami, macierzami danych z przełącznikami powinny być wykonywane duplikowanymi linkami 10GE i 16 FC w technologii światłowodowej. Serwery powinny być wyposażone w wiele portów na różnych kartach tak, aby można było duplikować połączenia sieciowe. Połączenie sieci SAN pomiędzy GCPD a DR będzie odbywało się minimum dwoma linkami po 16G FC każdy z każdym z podmiotów klasy A.PL klasy A będą posiadały własną sieć SAN o przepustowości 16G FC. Poniżej na rysunku (Rysunek 4-). przedstawiono na poziomie warstwy fizycznej architekturę sieci SAN (rozciągniętą pomiędzy GCPD, a serwerownią w DR). disi@pomorskie.eu, Strona 66 z 212

67 Rysunek 4-11: Graficzne przedstawienie koncepcji sieci SAN w GCPD i DR Warstwa logiczna sieci SAN będzie rozciągała się pomiędzy dwoma ośrodkami obliczeniowymi (GCPD i DR) poprzez przełączniki, które będą połączone parami między lokalizacjami i zorganizowanymi w dwie odrębne logiczne sieci SAN (FABRIC A oraz FABRIC B). Rozdzielenie sieci SAN na dwa niezależne segmenty jest optymalne z punktu widzenia niezawodności oraz codziennej administracji. Uniezależni to przede wszystkim sam rdzeń sieci SAN od błędów ludzkich i ewentualnych uszkodzeń sprzętu. W razie awarii jednego segmentu, wszystkie dane będą dalej spójne i dostępne. 4.7 Obszar sieci Internet Dostęp do sieci Internet w PL i GCPD/DR będzie realizowany w następujący sposób: dostęp dla PL przez WAN PEZ: o 1Gbit symetrycznie dla PL klasy A, o 200Mbit symetrycznie dla PL klasy B, C, D i E, dostęp dla GCPD/DR o prędkości 10/5Gbit. Dostęp do sieci Internet dla PL klasy E będzie realizowany głównie w oparciu o łącze w GCPD/DR. Lokalne istniejące łącza Internetowe będą podlegały do włączenia pod router brzegowy i będą służyły tylko i wyłącznie jako dostęp alternatywny i zapasowy do EDM i e-usług realizowanych przez Platformę Regionalną. Cały ruch Internetowy będzie odpowiednio zabezpieczony oraz przefiltrowany w GCPD. Pomiędzy GCPD i DR powinien zostać skonfigurowany VLAN DMZ. W DMZ powinien zostać zainstalowany router, który dzieliłby pasmo na część portalową oraz część dostępową Internetu dla potrzeb PL. Rolę łącza zapasowego z poszczególnych PL do GPCD będzie pełniło łącze Internetowe publiczne obecnie posiadane lub wykupione przez dany PL. Rekomenduje się aby łącze miało prędkość min 60Mbit. disi@pomorskie.eu, Strona 67 z 212

68 5 Analiza w zakresie sprzętu informatycznego - SWP Klauzula generalna: W zależności od uzasadnionych i uzgodnionych potrzeb uczestników Projektu PeZ wymagania Koncepcji Techniczno-Technologicznej mogą w przyszłości ulec zmianie/modyfikacji/doprecyzowaniu w specyfikacji opisu przedmiotu zamówienia dla poszczególnej kategorii zamówienia. Zgodnie z założeniami architektury PeZ oraz zgodnie z opisami dla poszczególnych poziomów, zostały ustalone założenia dla kluczowych obszarów sprzętowych projektu PeZ. Założenia te są następujące: obszar stacji roboczych: o stacje robocze będą ustandaryzowane, o będą istnieć przynajmniej dwa modele stacji roboczych (standardowy i rozszerzony) celem umożliwienia uruchamiania bardziej wymagających aplikacji dla części użytkowników w projekcie PeZ, obszar urządzeń mobilnych w tym laptopów, tabletów i tabletów medycznych: o urządzenia mobilne w PeZ będą ustandaryzowane, o będą istnieć przynajmniej dwa modele urządzeń mobilnych (standardowy i rozszerzony) celem umożliwienia uruchamiania bardziej wymagających aplikacji dla części użytkowników w projekcie PeZ, o będą istnieć przynajmniej trzy modele tabletów: tablet medyczny lekarski, tablet medyczny pielęgniarski, tablet niemedyczny zmywalny, obszar urządzeń skanujących i drukujących: o preferowane są urządzenia wielofunkcyjne, o odchodzi się od lokalnych urządzeń skanujących i drukujących, obszar środowiska serwerowego: o środowisko serwerowe i przechowywania danych powinno być ustandaryzowane na poziomie całości PeZ, o środowisko serwerowe w GCPD/DR powinno składać się z dużych serwerów, o środowisko bazodanowe powinno być odseparowane od środowiska aplikacyjnego i mieć własną infrastrukturę wysokodostępową, o środowisko aplikacyjne powinno zostać zwirtualizowane i zklastrowane Dodatkowo, od powyższych założeń zostały dopuszczone wyjątki, które są uzasadnione w związku z następującymi przypadkami: disi@pomorskie.eu, Strona 68 z 212

69 realizacją wcześniejszych projektów finansowanych z funduszy europejskich, specyfiką danego podmiotu leczniczego, specyfiką urządzeń medycznych lub procedur medycznych. Aby zrealizować potrzeby projektu PeZ w najbardziej optymalny sposób, architektura infrastruktury składa się z Głównego Centrum Przetwarzania Danych pełniącego rolę głównego węzła infrastruktury dla usług informatycznych na poziomie regionalnym oraz współdzielonych usług nie będących usługami regionalnymi (np. usługi infrastrukturalne) oraz z infrastruktury serwerowni lokalnych, które świadczą usługi informatyczne dla podmiotów leczniczych klasy A, B, C i D. Wysokopoziomowa architektura aplikacji jest opisana na poniższym rysunku (Rysunek 5-1): Rysunek 5-1: Wysokopoziomowa architektura aplikacji w PeZ Powyższa mapa obejmuje wszystkie warianty mapowania aplikacji na poszczególne PL, niezależnie od ich wielkości i zakresu działania. disi@pomorskie.eu, Strona 69 z 212

70 5.1 Koncepcja architektury infrastruktury serwerowej i przestrzeni dyskowej w GCPD Główny założeniem koncepcji architektury infrastruktury serwerowej jest zapewnienie przez PeZ funkcjonowania Głównego Centrum Przetwarzania Danych. GCPD będzie działało łącznie w klastrze z DR. W odniesieniu do rysunku (Rysunek 5-1), zakładana jest wirtualizacja środowiska serwerowego i możliwość logicznego oddzielenia zasobów serwerowych dla poszczególnych podmiotów leczniczych i systemów dedykowanych dla tych PL. W GCPD i DR będą przetwarzane wszystkie usługi regionalne, BI, usługi archiwum EDM. Samo GCPD będzie również świadczyło usługi CPD dla podmiotów klasy E. disi@pomorskie.eu, Strona 70 z 212

71 Rysunek 5-2 Schemat ideowy architektury placówki GCPD w projekcie PeZ disi@pomorskie.eu, Strona 71 z 212

72 GCPD jest centralnym elementem projektu PeZ zapewniającym mniejszym podmiotom klasy E całkowitą infrastrukturę serwerowo-macierzową. Ponieważ prawdopodobieństwo równoczesnej awarii serwerowni lokalnych we wszystkich podmiotach klasy A, B, C i D jest bardzo niskie, w GCPD nie będą przetwarzane systemy z tych podmiotów. GCPD będzie świadczyło szereg usług regionalnych (np. portal, centralny system CA, globalne usługi katalogowe, PKI (CA), DNS, hosting, poczta itd.) i wspólnych, co oznacza konieczność zapewnienia odpowiedniej puli zasobów do tego celu. Rekomendowane jest aby DR pracowało w roli pasywnej, wykorzystując produkcyjnie zasoby serwerowe, sieciowe i łącza danych do bieżącego świadczenia usług. Cała infrastruktura serwerowa powinna zostać zwirtualizowana. Na serwerach zwirtualizowanych powinny zostać umieszczone po dwa serwery wirtualne pracujące w klastrze active-active lub active-pasive. Aby nie duplikować i nie mnożyć w nieskończoność infrastruktury sieciowej powinny zostać zastosowane duże przepływności danych w sieciach VLAN. Z tego też powodu w GCPD i DR powinny zostać zainstalowane duże serwery, o dużej mocy obliczeniowej o wielu rdzeniach dostępnych do przetwarzania danych. Przestrzeń baz danych powinna zostać umieszczona jako wirtualne bazy danych na odrębnej infrastrukturze serwerowej lub w architekturze klastrów baz danych w chmurze obliczeniowej Architektura infrastruktury dla PL bez infrastruktury serwerowej (klasa E) W tego typu podmiotach całość elementów serwerowych i przestrzeni dyskowych zostanie umieszczona w GCPD/DR. Model może polegać na formie kolokacji dedykowanego sprzętu albo w formie dedykowanych maszyn wirtualnych i bazodanowych z zapewnioną przestrzenią dyskową. Backup będzie zatem realizowany w GCPD/DR za pomocą centralnej instancji backupowej. Podobnie archiwizacja elektronicznej dokumentacji medycznej (jeżeli taka będzie wytwarzana w danym podmiocie) będzie realizowana w GCPD. Zgodnie z założeniami w wyodrębnionej przestrzeni będą znajdować się systemy: HIS, EDM, ERP, Systemy infrastruktury IT (usługi katalogowe, poczta, szyna integracji danych, AV). Zgodnie z założeniami, PL klasy E mają dostęp do ogólnych, regionalnych systemów: elektroniczny obieg dokumentów, SOJ, SZN, disi@pomorskie.eu, Strona 72 z 212

73 BI, portal, EDM regionalny. Poniżej (Rysunek 5 3) opisano schemat ideowy architektury podmiotu: Rysunek 5-3: Koncepcja architektury infrastruktury dla podmiotu klasy E disi@pomorskie.eu, Strona 73 z 212

74 5.1.2 Architektura infrastruktury dla PL posiadającego pojedynczą małą serwerownię (klasa D - pogotowia) Ze względu na specyfikę Stacji Pogotowia Ratunkowego, placówki tej klasy muszą zostać potraktowane w sposób indywidualny. W związku z rozbudową Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM), wiele funkcjonalności systemów części białej przejmie właśnie system SWD PRM 2.0. System Obsługi Ratownictwa opierać się będzie na rozwiązaniu uzupełniającym funkcje Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM) o rozwiązania pozwalające na automatyczne przekazywania danych ratunkowych do zespołu wyjazdowego z bazy danych Regionalnego Repozytorium Danych Ratunkowych, oraz rozwiązanie pozwalające na wysłanie w sposób elektroniczny Karty Medycznych Czynności ratunkowych bezpośrednio do SOR podmiotu leczniczego do którego karetka zawiezie poszkodowanego o ile w ramach systemu SWD PRM zostaną udostępnione konieczne interfejsy. Na obecnym etapie prac projektowych należy również uwzględnić sytuację, w której SWD PRM w wersji 2.0 zapewni poniższe wymagania i funkcjonalności. Bez ostatecznych decyzji od gestora systemu SWD PRM (obecnie gestorem systemu jest MSWiA, docelowo system SWD PRM zostanie przejęty przez MZ) w projekcie na etapie aktualizacji KTT opisano proponowane założenia dedykowanego w ramach PeZ rozwiązania, nie mniej jednak przyjęto również potencjalną integrację z SWD 2 PRM. W obecnej chwili system SWD PRM jest zainstalowany na stanowiskach dyspozytora, który po podjęciu zgłoszenia, wypełnia Kartę Wyjazdu, tym samym zlecając najbliżej zlokalizowanej wolnej karetce pogotowia wyjazd do poszkodowanego. Dane wyjazdowe trafiają na tablet systemu SWD PRM w karetce pogotowia, który jest zainstalowany w niemedycznej części karetki, tak aby miał do niego dostęp Ratownik Medyczny lub Lekarz. Lekarz wypełnia następnie Kartę Medycznych Czynności Ratunkowych (KMCR), która wydrukowana na drukarce atramentowej w karetce trafia w jednej kopii do SORu szpitala a w drugiej do Stacji Pogotowia. Przy zamknięciu zlecenia wyjazdowego, dane zostają przekazane do bazy danych systemu SWD, jednak szpital musi sam przepisać te dane do swojego systemu (Izba Przyjęć) a Stacja Pogotowia sama musi ręcznie przepisać dane z Karty Wyjazdu i Karty Medycznych Czynności Ratunkowych do swojego systemu analitycznego. Dane będą mogły być importowane automatycznie do systemu HIS Szpitala oraz systemu analitycznego Pogotowia Ratunkowego pod warunkiem że w ramach systemu SWD PRM zostaną udostępnione niezbędne interfejsy. W tego typu podmiotach elementy systemów dziedzinowych i specjalistycznych zostaną umieszczone w lokalnej serwerowni. Część elementów serwerowych i przestrzeni dyskowych związanych disi@pomorskie.eu, Strona 74 z 212

75 z realizacją projektu zostanie umieszczonych w GCPD, niezależnie czy to w formie kolokacji dedykowanego sprzętu czy dedykowanych maszyn wirtualnych z zapewnioną przestrzenią dyskową. Natomiast w serwerowni podmiotu zostaną elementy nie objęte projektem. Z tego też powodu backup będzie realizowany dwutorowo. Z jednej strony w GCPD za pomocą centralnej instancji backupowej dla systemów podmiotu tam zlokalizowanych, a z drugiej dla pozostałych systemów w oparciu o lokalny system backupowy. Archiwizacja elektronicznej dokumentacji medycznej (jeżeli taka będzie wytwarzana w danym podmiocie) będzie realizowana w GCPD. Zalecane jest wykorzystanie jako systemu backupowego lokalnego rozwiązania jak w całym projekcie PeZ., ponieważ uprości to administrację tym rozwiązaniem, a również umożliwi albo realizację backupów w oparciu o centralną infrastrukturę backupową lub dodatkowe zabezpieczenie danych poprzez replikację backupów do GCPD. Z racji, iż w Stacjach Pogotowia w części białej przewidziana jest jedynie apteka i integracja z SWD 2.0, sprzęt niezbędny do wyposażenia serwerowni również musi być zoptymalizowany pod specyfikę tych jednostek. Poniżej opisano schemat ideowy architektury podmiotu: disi@pomorskie.eu, Strona 75 z 212

76 Rysunek 5-4: Koncepcja architektury infrastruktury dla podmiotu klasy D disi@pomorskie.eu, Strona 76 z 212

77 W podmiotach klasy D serwerowa: powinna zostać zainstalowana następująca minimalna infrastruktura minimum dwa serwery zwirtualizowane pracujące w klastrze niezawodnościowowydajnościowym z 2 rdzeniami po 16 core każdy, min 256GB RAM, 2x10GE Eth Serwery powinny zostać zwirtualizowane, a w przestrzeni wirtualnej powinny zostać umieszczone serwery Windows, Linux i serwery baz danych. Baza danych będzie przetwarzana na serwerach jako maszyna wirtualna z przypisanym procesorem. macierz dla bazy danych i systemów wirtualnych tzw. macierz szybka o pojemności minimum. 4TB dla dysków SAS w RAID6, minimum jeden kontroler po dwa porty 10G iscsi Replikacja danych macierzy na przestrzeń w GCPD/DR będzie następowała poprzez mechanizmy synchronicznej replikacji a zapis danych będzie podlegał deduplikacji. macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 18TB dla dysków SATA/NLSAS w RAID6, minimum dwa porty 10GE dla połączeń iscsi Macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM lub szyfrowanie danych będzie dostępne poprzez odrębny serwer. Dane EDM będą replikowane poprzez serwer replikacyjny do archiwum EDM na platformie regionalnej Architektura infrastruktury dla PL posiadającego pojedynczą małą serwerownię (klasa C) W tego typu podmiotach elementy systemów dziedzinowych i specjalistycznych zostaną umieszczone w lokalnej serwerowni. Część elementów serwerowych i przestrzeni dyskowych związanych z realizacją projektu zostanie umieszczonych w lokalnej serwerowni danego podmiotu. Archiwizacja elektronicznej dokumentacji medycznej (jeżeli taka będzie wytwarzana w danym podmiocie) będzie realizowana w GCPD. Zalecane jest wykorzystanie jako systemu backupowego lokalnego rozwiązania jak w całym projekcie PeZ, ponieważ uprości to administrację tym rozwiązaniem, a również umożliwi albo realizację backupów w oparciu o centralną infrastrukturę backupową lub dodatkowe zabezpieczenie danych poprzez replikację backupów do GCPD. Poniżej opisano schemat ideowy architektury podmiotu: disi@pomorskie.eu, Strona 77 z 212

78 Rysunek 5-5: Koncepcja architektury infrastruktury dla podmiotu klasy C disi@pomorskie.eu, Strona 78 z 212

79 Zgodnie z założeniami architektury, całość systemów dziedzinowych i wspierających znajduje się w serwerowniach danego PL typu C: W lokalnej serwerowni, zostają następujące systemy: HIS, ERP, EDM, RIS, LIS, ESD, kontener usługi katalogowych/ldap, systemy infrastruktury IT (usługi katalogowe, szyna integracji danych, AV). Zgodnie z założeniami PL typu C mają dostęp do ogólnych, regionalnych systemów: elektroniczny obieg dokumentów, SOJ, SZN, BI, portal, EDM regionalny, CA, hosting www/bip. W podmiotach klasy C serwerowa: powinna zostać zainstalowana następująca minimalna infrastruktura minimum dwa serwery zwirtualizowane pracujące w klastrze niezawodnościowowydajnościowym z 2 rdzeniami po 16 core każdy, min 256GB RAM, 2x10GEEth, kontroler SAS Serwery powinny zostać zwirtualizowane a w przestrzeni wirtualnej powinny zostać umieszczone serwery Windows, Linux i serwery baz danych. Baza danych będzie przetwarzana na 2 serwerach fizycznych. macierz dla bazy danych i systemów wirtualnych tzw. macierz szybka o pojemności minimum. 20TB dla dysków SAS w RAID6, minimum dwa kontrolery po dwa porty SAS podłączone bezpośrednio do serwerów, disi@pomorskie.eu, Strona 79 z 212

80 macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 100TB dla dysków SATA/NLSAS w RAID6, minimum dwa porty 10GE dla połączeń iscsi. Macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM lub szyfrowanie danych będzie dostępne poprzez odrębny serwer. Dane EDM będą replikowane poprzez serwer replikacyjny do archiwum EDM na platformie regionalnej. urządzenie do backupu danych Architektura infrastruktury dla PL mających własną infrastrukturę dla jednej dużej serwerowni (typ B ) W tego typu podmiotach całość elementów serwerowych i przestrzeni dyskowych zostanie umieszczona w pojedynczych serwerowniach podmiotów. Będą tam się znajdowały zarówno systemy związane z projektem PeZ jak i pozostałe systemy podmiotu nie objęte tym projektem. Backup będzie zatem realizowany w ramach podmiotu za pomocą dedykowanej instancji backupowej. Mimo autonomiczności systemu backupowego podmiotu zalecane jest jego ujednolicenie z centralnym systemem backupowym umieszczonym w GCPD. Umożliwi to ułatwienie administracji całością rozwiązania i obniży koszty systemu backupowego jako całości z punktu widzenia projektu. Archiwizacja elektronicznej dokumentacji medycznej będzie natomiast realizowana w GCPD. Poniżej jest schemat ideowy architektury PL tego typu. disi@pomorskie.eu, Strona 80 z 212

81 Rysunek 5-6: Koncepcja architektury infrastruktury dla podmiotu klasy B disi@pomorskie.eu, Strona 81 z 212

82 Zgodnie z założeniami architektury, całość systemów dziedzinowych i wspierających znajduje się w serwerowniach danego PL typu B: HIS, EDM, RIS, LIS, ESD, ERP, systemy infrastruktury IT (usługi katalogowe, szyna integracji danych, AV). Jednocześnie, ciągłość danych jest zapewniona poprzez posiadanie ZCPD w ramach PL typu B. Zgodnie z założeniami PL typu B mają dostęp do ogólnych, regionalnych systemów: elektroniczny obieg dokumentów, SOJ, SZN, BI, portal, EDM regionalny, CA, hosting www/bip. W podmiotach klasy B powinna zostać zainstalowana następująca minimalna infrastruktura serwerowa: minimum dwa serwery zwirtualizowane pracujące w klastrze niezawodnościowowydajnościowym z min 2 rdzeniami po 16 core lub każdy, min 256GB RAM (PL core i 768 GB RAM), 2x10GE, kontroler SAS Serwery powinny zostać zwirtualizowane a w przestrzeni wirtualnej powinny zostać umieszczone serwery Windows, Linux. Baza danych będzie przetwarzana na 2 serwerach fizycznych. dwie macierze w klastrze synchronicznym dla bazy danych i systemów wirtualnych tzw. macierz szybka o pojemności minimum 43TB dla dysków SAS w RAID6, minimum dwa kontrolery po dwa porty SAS podłączone bezpośrednio do serwerów. macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 200TB dla dysków SATA/NLSAS w RAID6, minimum dwa kontrolery po dwa porty SAS i/lub porty 10GE dla połączeń iscsi disi@pomorskie.eu, Strona 82 z 212

83 Macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM lub szyfrowanie danych będzie dostępne poprzez odrębny serwer. Dane EDM będą replikowane poprzez serwer replikacyjny do archiwum EDM na platformie regionalnej. urządzenie do backupu danych Architektura infrastruktury dla PL mających własną infrastrukturę minimum dwóch serwerowni (typ A) W tego typu podmiotach całość elementów serwerowych i przestrzeni dyskowych zostanie umieszczona w serwerowniach podmiotów. Będą tam się znajdowały zarówno systemy związane z projektem PeZ jak i pozostałe systemy podmiotu nie objęte tym projektem. Backup będzie zatem realizowany w ramach podmiotu za pomocą dedykowanej instancji backupowej. Ponieważ podmiot dysponuje przynajmniej dwoma serwerowniami może również zapewnić w ramach własnych zasobów rozdzielenie systemu backupowego na dwie lokalizacje geograficzne. Mimo autonomiczności systemu backupowego podmiotu zalecane jest jego ujednolicenie z centralnym systemem backupowym umieszczonym w GCPD. Poniżej schemat ideowy architektury PL kategorii A. disi@pomorskie.eu, Strona 83 z 212

84 Rysunek 5-7: Koncepcja architektury infrastruktury podmiotu klasy A disi@pomorskie.eu, Strona 84 z 212

85 Zgodnie z założeniami architektury, całość systemów dziedzinowych i wspierających znajduje się w serwerowniach danego PL typu A: HIS, EDM, RIS, LIS, ESD, ERP, systemy infrastruktury IT (usługi katalogowe, szyna integracji danych, AV). Jednocześnie, ciągłość danych jest zapewniona poprzez posiadanie ZCPD w ramach PL typu A. Zgodnie z założeniami PL typu A mają dostęp do ogólnych, regionalnych systemów: elektroniczny obieg dokumentów, SOJ, SZN, BI, portal, EDM regionalny, CA, hosting www/bip. W podmiotach klasy A powinna zostać zainstalowana następująca minimalna infrastruktura serwerowa: minimum cztery serwery zwirtualizowane pracujące w klastrze niezawodnościowowydajnościowym z min 2 rdzeniami po 16/22 core lub każdy, min 384/768GB RAM, min 2/4x10GE NIC, 2x8/16G FC Serwery powinny zostać zwirtualizowane, a w przestrzeni wirtualnej powinny zostać umieszczone serwery Windows, Linux. Baza danych będzie przetwarzana na 2/4 serwerach fizycznych. minimum dwie macierze dla bazy danych i systemów wirtualnych tzw. macierz szybka (po jednej na serwerownię) o pojemności minimum. 47TB (w tym 4TB na SSD) dla dysków SAS w RAID6, minimum dwa kontrolery FC/iSCSI minimum 1/2 macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 200TB dla dysków SATA/NLSAS w RAID6, minimum dwa porty 10GE dla połączeń iscsi disi@pomorskie.eu, Strona 85 z 212

86 Macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM lub szyfrowanie danych będzie dostępne poprzez odrębny serwer. Dane EDM będą replikowane poprzez serwer replikacyjny do archiwum EDM na platformie regionalnej. urządzenie do backupu danych. We wszystkich podmiotach powinien zostać zakupiony system operacyjny w wersji nielimitowanej, pozwalającej na używanie dowolnej ilości instancji wirtualnych serwerów w obszarze wirtualizacji aplikacji Architektura bezpieczeństwa infrastruktury i systemy zarządzania dla GCPD i PL. Infrastruktura bezpieczeństwa w GCPD/DR i PL musi zostać podzielona na dwa elementy: infrastruktura sprzętowa (routery, firewall/utm, IPS), infrastruktura systemowa (AV, zarządzanie uprawnieniami). Systemy bezpieczeństwa w całej sieci WAN PeZ czyli w GCPD/DR oraz w każdej z PL powinny być jednakowe i zarządzane centralnie, z możliwością udostepnienia monitoringu zdarzeń dla konsoli administratorów lokalnych. Na brzegu sieci w każdym PL podłączonym do sieci Internet powinien zostać zainstalowany router, sprzętowy firewall/utm, akcelerator silnego szyfrowania kanałów VPN. W mniejszych PL klasy C i D mogą to być dwa routery wyposażone w moduły realizujące funkcjonalności jw. lub odrębne urządzenia realizujące przedmiotowe funkcjonalności. W PL typu A powinny być to odrębne klastry urządzeń działające w trybie failover. W GCPD powinien zostać zainstalowany dedykowany centralny system bezpieczeństwa aplikacji web w tym e-usług, udostępnianych przez portal regionalny, usług hostingu stron PL i BIP, baz danych, plików i aplikacji chmurowych. System taki musi obsługiwać DMZ i strefę WAN PeZ. Musi mieć możliwość klasyfikacji adresów IP użytkowników korzystających z web (e-usług), rozpoznawać szkodliwe pule adresów IP oraz przeciwdziałać zautomatyzowanym atakom (np. phishing IP, DoS, MM, podejrzane IP). Ruch sieciowy z podejrzanych IP musi zostać szybko i skutecznie sklasyfikowany jako podejrzany i przewidziany do możliwej inicjacji ataku. W GCPD powinien ponadto zostać zainstalowany zaawansowany system ochrony przed atakami web, oraz file malware protection a także SQL Injection. System zapewni oprócz rozwiązań antywirusowych, zaawansowaną ochronę przez ukierunkowanymi atakami, które omijają tradycyjne zabezpieczenia bazujące na sygnaturach i stanowią realne zagrożenie dla wszystkich serwerów i stacji roboczych w GCPD i PL. Rozwiązanie tego typu powinno zostać wdrożone jako appliance lub jako maszyna wirtualna, jako środowisko do wykrywania i blokowania zaawansowanych ataków typu malware. Sygnatury ataków muszą być pobierane online z bazy udostępnianej przez producenta. System musi skanować podejrzany kod, analizując pliki, załączniki, obiekty WWW na styku z siecią disi@pomorskie.eu, Strona 86 z 212

87 Internet oraz wewnątrz struktury serwerowej PeZ. Obok systemu ochrony malware, jako główny system zabezpieczeń powinien zostać zainstalowany centralny skaner AV, zintegrowany z lokalnymi programowymi systemami ochrony przed atakami zewnętrznymi. Końcówki systemu zostaną zainstalowane na każdej z maszyn serwerów, baz danych oraz na sprzęcie komputerowym w całej sieci PeZ. Centralnie zostanie zainstalowany serwer szczepionek, który będzie uaktualniany sygnaturami zwykłych ataków i listą szczepionek antywirusowych dostarczanych od producenta oprogramowania. Systemy, które maja dostęp do sieci Internet e-usługi oraz portale zewnętrzne i hosting powinny mieć własną odseparowaną bazę danych użytkowników (pacjentów), tak aby baza ta była odseparowana i nie korzystała ani z usług aktywnej usługi katalogowej/ldap kontenerów PeZ ani z baz danych wewnętrznych. Baza tego typu powinna być odrębnym serwerem np. Linux, umieszczonym w kontrolowanej strefie za DMZ oraz silnie monitorowana przez systemy bezpieczeństwa i odporna na ataki typu SQL Injection. Ważnym elementem takiego systemu będzie możliwość uporządkowania zarządzania uprawnieniami na etapie wnioskowania o uprawnienia i procesu ich nadawania. Istotnym elementem systemu będzie analiza efektywności przydzielonych uprawnień. W kontekście ustawy o ochronie danych osobowych oraz rozporządzenia parlamentu europejskiego w sprawie ochronny osób fizycznych w związku z przetwarzaniem danych osobowych, ważnym elementem systemu będzie możliwość cyklicznej weryfikacji uprawnień w oparciu o kryteria opisowe, oraz stosowaną w PeZ analizę ryzyka oraz proaktywną minimalizację działań niepożądanych. disi@pomorskie.eu, Strona 87 z 212

88 6 Oprogramowanie dziedzinowe i specjalistyczne Klauzula generalna: W zależności od uzasadnionych i uzgodnionych potrzeb uczestników Projektu PeZ wymagania Koncepcji Techniczno-Technologicznej mogą w przyszłości ulec zmianie/modyfikacji/doprecyzowaniu w specyfikacji opisu przedmiotu zamówienia dla poszczególnej kategorii zamówienia. Oprogramowanie wykorzystywane w podmiotach leczniczych można generalnie podzielić na dwie kategorie: dziedzinowe oprogramowanie wspierające działalność leczniczą podmiotu (część biała - HIS), specjalistyczne oprogramowanie wspierające obsługę własną podmiotu leczniczego (część szara - ERP). Systemy te występują zazwyczaj jako głęboko zintegrowane oprogramowanie. Uzupełnieniem części białej są inne systemy specjalistyczne tj. PACS/RIS/LIS. Systemy te wspierają podstawową działalność PL i decydują w głównej mierze o poziomie świadczonych usług oraz sprawności zarządzania PL. Szczegółowe informacje na temat wyżej wymienionych systemów zostały omówione w dalszej części tego rozdziału. 6.1 Proponowane podejście do realizacji W niniejszym rozdziale przedstawione zostały ogólne założenia proponowanego podejścia do realizacji. Proponowana koncepcja opiera się o następujące kluczowe założenia. 1. Dla każdego typu systemów, wchodzących w zakres PeZ w obszarze systemów dziedzinowych i specjalistycznych zostały wyszczególnione minimalne wymagania w zakresie grup funkcjonalności, jakie systemy te powinny zapewniać. W zależności od rodzaju podmiotu (A, B, C, D, E) i jego specyfiki (tj. szpitale, poradnie, pogotowia) wytypowano docelowe funkcjonalności dedykowane do wdrożenia w poszczególnych podmiotach. 2. Po przeprowadzeniu analizy istniejących w PL systemów, dla każdego z nich został zaproponowany jeden z poniższych wariantów podejścia do realizacji. disi@pomorskie.eu, Strona 88 z 212

89 I. Dostarczenie nowego, standardowego i zintegrowanego systemu, który zostanie zakupiony w ramach projektu PeZ. Wariant dotyczy podmiotów, które nie posiadają aktualnie własnych rozwiązań. II. Zastąpienie systemu już eksploatowanego w PL rozwiązaniem opisanym w wariancie I. Wariant ten dotyczy podmiotów posiadających własne rozwiązanie, którego rozbudowa, dalsze utrzymanie oraz możliwości integracji nie są uzasadnione. III. Rozbudowa systemu eksploatowanego w PL o brakujące funkcjonalności z listy minimalnych wymagań dedykowanym danemu podmiotowi i integracja tego systemu z resztą architektury dostarczanej w ramach PeZ. Wariant ten dotyczy podmiotów posiadających własne rozwiązanie, którego wycofanie z eksploatacji nie znajduje uzasadnienia. Wariant ten dotyczy przede wszystkim systemów stosunkowo nowych i oferowanych przez liczących się dostawców. Wariant ten uwzględnia również systemy wdrażane z wykorzystaniem środków europejskich, dla których obowiązuje okres trwałości. 3. W zależności od rodzaju podmiotu (A, B, C i D), zgodnie z opisaną we wcześniejszej części tego dokumentu koncepcją, systemy będą funkcjonować w poszczególnych PL w różnych modelach architektury i świadczenia usług oraz w GCPD (klasa E). Modele te zostały opisane w dalszej części tego rozdziału. 4. Szczegółowe zakresy funkcjonalności, w tym specyfikacja wymagań funkcjonalnych oraz pozafunkcjonalnych dla poszczególnych PL zostanie uzgodniona z placówkami biorącymi udział w realizacji Projektu PeZ na etapie tworzenia dokumentacji przetargowej ze szczególnym uwzględnieniem opisów przedmiotu zamówienia. 5. Na etapie przygotowywania dokumentacji przetargowej uzgodniony zostanie okres oraz zakres szczegółowy asysty technicznej dla systemów dziedzinowych w okresie trwałości projektu w zakresie możliwości budżetowych każdej z placówek biorących udział w projekcie. Sukces projektu wymaga uruchomienia systemu regionalnego i systemów lokalnych w zakresie umożliwiającym ich pełną integrację. Dlatego przyjmuje się że w ramach realizacji projektu w poszczególnych PL, dostawca rozwiązania dostarczy niezbędne licencje, zainstaluje je na infrastrukturze klienta, skonfiguruje wg wymagań zapisanych w OPZ, zintegruje system wg zapisów OPZ, przeszkoli użytkowników oprogramowania w zakresie wdrażanych licencji oraz zrealizuje wdrożenie istniejących w PL systemów w zakresie umożliwiającym wymaganą integrację z systemem regionalnym PeZ. Na poniższym rysunku przedstawiona została zaproponowana struktura systemów i modułów zapewniających zakładane w założeniach projektu PeZ funkcjonalności, wraz z powiązaniami disi@pomorskie.eu, Strona 89 z 212

90 obrazującymi obieg informacji w podmiocie leczniczym. Schemat ten należy traktować jako podejście na niskim poziomie szczegółowości, obrazujące ogólną ideę proponowanego rozwiązania. Propozycje dla poszczególnych podmiotów zostały dostosowane do typu i specyfiki każdego z nich. W dalszej części tego punktu opisane zostały najważniejsze cechy poszczególnych systemów. disi@pomorskie.eu, Strona 90 z 212

91 Rysunek 6-1: Struktura zintegrowanego systemu informatycznego wraz z powiązaniami disi@pomorskie.eu, Strona 91 z 212

92 System HIS to szpitalny system informatyczny, czyli tzw. część biała. Jest to podstawowy system wspierający obsługę pacjentów. Zintegrowany z pozostałymi systemami informatycznymi w jednostkach medycznych. W HIS powstaje m.in. dokumentacja medyczna (zgodnie z obowiązującymi aktualnie przepisami prawa), którą system przesyła do lokalnego systemu EDM. Komunikacja jest obustronna, tj. system HIS za pomocą API prezentuje dokumentację medyczną i rekord pacjenta z EDM. HIS odpowiada również za tworzenie kont pacjentów w regionalnej bazie LDAP (komponent odpowiedzialny za przechowywanie kont użytkowników). Rysunek 6-2: Diagram typowych aplikacji szpitalnych disi@pomorskie.eu, Strona 92 z 212

93 System LIS (Laboratoryjny System Informacyjny) dedykowany jest do wsparcia podstawowych zadań w zakresie zarządzania danymi, takich jak obsługa zleceń (rejestracja zleceń, rejestracja materiałów, walidacja wyników, archiwizacja i dystrybucja danych), połączenie aparatury analitycznej z systemem informatycznym i obsługa pracy laboratorium. W ramach zarządzania laboratorium system umożliwia prowadzenie gospodarki odczynnikami, statystyki i rozliczanie procedur. Integracja systemu LIS z HIS zapewnia transfer zlecenia z systemu szpitalnego do systemu laboratoryjnego. Po wykonaniu testów i walidacji wyników dane są przesłane do systemu HIS. Dane są gromadzone w HIS i przesyłane do systemu EDM jako element dokumentacji medycznej. System RIS (Radiologiczny System Informacyjny) zapewni obsługę informatyczną procedur wykonywanych w ramach Zakładów Radiologii w podmiotach leczniczych. Do podstawowych zadań systemu należy rejestracja danych pacjenta oraz danych zlecenia, wyznaczanie terminu badań. Po realizacji zlecenia system umożliwia zapis wykonania badania oraz użytego materiału. Integracja systemów HIS-RIS (z wykorzystaniem standardu HL7) zapewnia wsparcie dwustronnej komunikacji pomiędzy oddziałem radiologii z innymi oddziałami. System PACS (system archiwizacji i transmisji obrazów) wspierać będzie proces diagnozowania i odpowiadać będzie za gromadzenie danych obrazowych i szybki do nich dostęp. W PACS realizowane będą usługi związane z akwizycją, archiwizacją i przetwarzaniem obrazów. Integracja systemu PACS (z wykorzystaniem standardu DICOM) z pozostałymi systemami informatycznymi w podmiotach leczniczych umożliwi między innymi transfer list roboczych pomiędzy systemami HIS, RIS i PACS. Integracja tych systemów zapewni również uruchomienie usługi polegającej na pobraniu archiwalnych danych obrazowych, które mogą być wykorzystane w związku z przyjęciem pacjenta do szpitala lub wyznaczeniem wizyty w poradni. Pozwoli tym samym skrócić czas oczekiwania na wynik badania. Zakładany obieg informacji pomiędzy systemami HIS, PACS i RIS został przedstawiony na poniższym rysunku. disi@pomorskie.eu, Strona 93 z 212

94 Rysunek 6-3: Obieg informacji pomiędzy HIS/PACS/RIS System ERP (Enterprise Resource Planning) służyć będzie do zarządzania zasobami podmiotu leczniczego (tzw. część szara ). ERP zapewni wsparcie realizacji procesów finansowo-księgowych, kadrowo-płacowych, zarządczych i analitycznych w podmiotach leczniczych. Oferowany jako zintegrowany, wielomodułowy system współpracować będzie z następującymi systemami: system obiegu spraw i dokumentów (EOD), portal pacjenta, BI i dedykowane hurtownie danych, systemy HIS. System EOD (Elektroniczny Obieg Dokumentów) zapewni wsparcie dla procesu obiegu pism i spraw oraz przepływu pracy. W ogólnej definicji sprawy prowadzone w EOD mogą być odzwierciedleniem realizowanych projektów lub innych działań pogrupowanych tematycznie. Dokument przychodzący może mieć postać przesyłki wpływającej w formie materialnej (pismo, nośnik elektroniczny itp.) jak i elektronicznej ( , dokument z epuap). System EOD zapewni funkcjonalności umożliwiające disi@pomorskie.eu, Strona 94 z 212

95 tworzenie nowych spraw, pism, obsługę standardowego obiegu pism oraz wysyłanie wiadomości e- mail. System BI umożliwi wykonywanie analitycznych zapytań ad-hoc i budowanie raportów i przeprowadzanie analiz w oparciu o zgromadzone dane z systemów typu ERP i HIS. System w minimalnym zakresie zapewni gromadzenie zagregowanych i odpersonalizowanych danych z obszarów: 6.2 HIS liczby zarejestrowanych zdarzeń medycznych informacje o wszystkich zdarzeniach medycznych rejestrowanych w podmiotach leczniczych, statystyczne dane medyczne szczegółowe informacje dotyczące różnych chorób, ich przebiegu i wynikach leczenia. Dane te będą odpersonalizowane, recepty, zwolnienia, skierowania informacje na temat wystawionych recept, wypisanych zwolnień i skierowań, bez składowania tychże dokumentów w formie elektronicznej (dane te będą odpersonalizowane), rozliczenia z NFZ informacje na temat rozliczeń z NFZ, realizacji kontraktów, dane administracyjne między innymi informacje o kosztach prowadzenia działalności medycznej, posiadanych zasobach, dane finansowo zarządcze. Przykładowy zakres grup funkcjonalności dla HIS może być następujący (szczegółowe zakresy funkcjonalne dla każdej z placówek zostaną opracowane w uzgodnieniu z PL na etapie prac analitycznych w trakcie opracowywania dokumentacji przetargowej): rejestracja (z możliwością obsługi e-rejestracji), poradnia (możliwość wystawiania recept), w zależności od potrzeb ze wsparciem dla medycyny pracy, medycyny sportowej, pielęgniarki społecznej itp., gabinet, apteka, apteczka oddziałowa, powiązana z apteką centralną, zlecenia medyczne, w zakresie wykonywania i obsługi zleceń medycznych, w tym zleceń elektronicznych, punkt pobrań, w zależności od potrzeb dodatkowo ze wsparciem dla laboratorium, banku krwi i serologii; w zależności od decyzji dla poszczególnych PL powiązany z LIS, disi@pomorskie.eu, Strona 95 z 212

96 ruch chorych (dedykowany dla obsługi oddziałów szpitalnych i izby przyjęć) dostosowany do obsługi przez personel zarówno na komputerach stacjonarnych jak i w ograniczonym zakresie - na tabletach, blok operacyjny, rehabilitacja, moduły specjalistyczne (telerehabilitacja, endoskopia, logopedia, patomorfologia w zakresie wsparcia procesów diagnostyki z wykorzystaniem urządzeń cyfrowych, np. mikroskopów cyfrowych, itp) pracownia, w zależności od potrzeb, np. EKG, EEG, sterylizatornia, zakażenia, stacja dializ, żywienie, SOR, Archiwum Dokumentacji Papierowej rozliczenia z NFZ i innymi Płatnikami, w zakresie rozliczenia z płatnikiem, grup JGP, Wymagania dotyczące integracji HIS z istniejącymi systemami: poszczególne grupy funkcjonalności HIS są ze sobą zintegrowane i umożliwiają dwukierunkową wymianę danych w czasie rzeczywistym, system jest zintegrowany z ERP i umożliwia dwukierunkową wymianę danych między tymi systemami w czasie rzeczywistym, system jest zintegrowany z lokalnym systemem Elektronicznej Dokumentacji Medycznej i umożliwia dwukierunkową wymianę danych między tymi systemami w czasie rzeczywistym, system zintegrowany jest z regionalnym portalem informacyjnym i umożliwia dwukierunkową wymianę danych w czasie rzeczywistym między tymi dwoma systemami umożliwiając realizację wymagań funkcjonalnych dotyczących portalu oraz tworzenie nowych kont dla pacjentów, system jest zintegrowany z systemami PACS/RIS/LIS, jeśli systemy te istnieją w danym podmiocie leczniczym, bądź są dla danego podmiotu planowane do wdrożenia w ramach projektu PeZ, disi@pomorskie.eu, Strona 96 z 212

97 system jest zintegrowany z Rejestrem Dokumentacji Medycznej (dostępnym na platformie regionalnej) i umożliwia dwukierunkową wymianę danych w czasie rzeczywistym. Obie stacje pogotowia ratunkowego (PL02 i PL11) zgłosiły potrzebę wdrożenia modułu informacyjnego wspomagającego ratownictwo medyczne. Moduł ten będzie umożliwiał wyszukanie informacji z rejestru danych ratunkowych przez dyspozytora. Dyspozytor przekaże wyszukane dane bezpośrednio na tablet umieszczony w karetce. Szczegóły systemu znajdują się w opisie Systemu Obsługi Ratownictwa w dalszej części dokumentu koncepcji. W ten sposób członkowie zespołów ratunkowych będą mieli dostęp na swoich tabletach medycznych, do wybranej dokumentacji medycznej pacjentów, do których jadą. Bezawaryjny, bezpieczny, zapewniający ochronę danych osobowych sposób komunikacji zostanie zapewniony poprzez szyfrowaną komunikację z siecią wewnętrzną PeZ. Dodatkowo system musi uwzględniać specyficzne potrzeby każdego PL np. specyficzne wymagania dla Psychiatrii, Onkologii, itd HIS w podmiotach leczniczych klasy E PL klasy E to podmioty najmniejsze, najczęściej przychodnie. Podmioty te charakteryzują się dużą specjalizacją i specyficznymi potrzebami w zakresie oprogramowania. Rekomendowane jest przyjęcie dla tego typu jednostek minimalnego zestawu grup funkcjonalności, tak aby spełniał on oczekiwania wszystkich podmiotów tej klasy i jednocześnie pozwalał na elastyczną rozbudowę w przyszłości. Minimalne grupy funkcjonalności proponowane do implementacji w ramach projektu PeZ w poszczególnych zostały wyszczególnione w tabeli poniżej. Są to wymagania standardowe, uwzględniające specyfikę poszczególnych PL. Uzasadnione, zgłoszone w trakcie przeprowadzonej inwentaryzacji indywidualnej potrzeby zgłoszone przez podmiot leczniczy zostały opisane w dokumencie dedykowanym danemu podmiotowi. Lista podmiotów klasy E: 1. PL06 - Centrum Zdrowia Psychicznego w Słupsku 2. PL10 - Wojewódzki Ośrodek Terapii Uzależnień w Gdańsku 3. PL17 - Przemysłowy Zespół Opieki Zdrowotnej Sp. z o.o. Grupa E PL06 PL10 PL17 Rejestracja X x x Poradnia X x x disi@pomorskie.eu, Strona 97 z 212

98 Grupa E PL06 PL10 PL17 Gabinet X x x Apteka X x x Apteczka oddziałowa X x x Zlecenia medyczne X x x Punkt pobrań X x Ruch chorych X x Rehabilitacja x x Zakażenia X x x Rozliczenia NFZ X x x Raporty i statystyka X x x Tabela 3 Minimalne grupy funkcjonalności HIS dla podmiotów leczniczych klasy E PL kategorii E charakteryzują się małymi zespołami ludzkimi i niewielką skalą działania. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych klasy E przyjąć dla systemów HIS rozwiązanie architektoniczne oparte o chmurę prywatną i model usługowy SaaS. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne. Rozwiązanie zostanie umieszczone wraz z ERP w GCPD i udostępniane przez WAN projektu PeZ. Zgodnie z aktualnymi trendami na rynku oprogramowania dla jednostek ochrony zdrowia, jednostki monospecjalistyczne, w szczególności jednostki o specjalizacji psychiatrycznej obsługiwane są z wykorzystaniem standardowego oprogramowania, odpowiednio skonfigurowanego do potrzeb tych jednostek HIS w podmiotach leczniczych klasy D PL klasy D to podmioty średnie i małe - Stacje Pogotowia Ratunkowego. Podmioty te świadczą specjalistyczne usługi medyczne wynikające z zakresu zadań im powierzonych. Rekomendowane jest przyjęcie dla tego typu jednostek minimalnego zestawu grup funkcjonalności standardowych, tak aby spełniał on oczekiwania wszystkich podmiotów tej klasy, zestaw funkcjonalności specjalistycznych danych dla specyfiki działania podmiotu. Lista podmiotów leczniczych klasy D jest następująca: disi@pomorskie.eu, Strona 98 z 212

99 1. PL02 Stacja Pogotowia Ratunkowego w Gdańsku, 2. PL11 Stacja Pogotowia Ratunkowego w Słupsku, Minimalne grupy funkcjonalności proponowane do implementacji w ramach projektu PeZ w poszczególnych zostały wyszczególnione w tabeli poniżej. Są to wymagania standardowe, uwzględniające specyfikę poszczególnych PL. Uzasadnione, zgłoszone w trakcie przeprowadzonej inwentaryzacji indywidualnej potrzeby zgłoszone przez podmiot leczniczy zostały opisane w dokumencie dedykowanym danemu podmiotowi. Grupa D PL02 PL11 Dyspozytor x X Zespół wyjazdowy x x Tabela 4: Minimalne grupy funkcjonalności HIS dla podmiotów leczniczych klasy D PL kategorii D, ze względu na swoją specyfikę, nie będą korzystać z typowych funkcjonalności wykorzystywanych w placówkach lecznictwa zamkniętego i otwartego. Dla tej kategorii zostaną przygotowane dedykowane moduły umożliwiające wgląd zespołu wyjazdowego w dane ratunkowe gromadzone w Regionalnym Rejestrze Danych Ratunkowych. Grupa funkcjonalności Dyspozytor zapewni dyspozytorowi możliwość wyszukania w rejestrze danych ratunkowych danych dotyczących pacjenta do którego realizowane jest zlecenie wyjazdu. Dane te po wstępnym zweryfikowaniu przekazywane będą przez Dyspozytora na tablet zespołu wyjazdowego. Moduł Zespół wyjazdowy, to aplikacja mobilna, która wyświetli na ekranie urządzenia mobilnego (tableta) dane wysłane przez Dyspozytora. PL kategorii D posiadają rozbudowaną infrastrukturę, wraz z własną serwerownią będą posiadały w pełni bezawaryjną infrastrukturę. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych klasy D przyjąć dla systemów HIS lokalne rozwiązanie architektoniczne. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne HIS w podmiotach leczniczych klasy C PL klasy C to podmioty niewielkie, zatrudniające poniżej 1000 osób. Podmioty te świadczą zawężony, specjalistyczny zakres usług medycznych. Rekomendowane jest przyjęcie dla tego typu jednostek minimalnego zestawu grup funkcjonalności, tak aby spełniał on oczekiwania wszystkich podmiotów tej klasy i jednocześnie pozwalał na elastyczną rozbudowę w przyszłości. Lista podmiotów leczniczych klasy C jest następująca: disi@pomorskie.eu, Strona 99 z 212

100 1. PL01 Wojewódzki Szpital Psychiatryczny im. prof. Tadeusza Bilikiewicza w Gdańsku, 2. PL05 Wojewódzki Zespół Reumatologiczny im. dr Jadwigi Titz-Kosko Minimalne grupy funkcjonalności proponowane do implementacji w ramach projektu PeZ w poszczególnych PL zostały wyszczególnione w tabeli poniżej. Są to wymagania standardowe, uwzględniające specyfikę poszczególnych PL. Uzasadnione, zgłoszone w trakcie przeprowadzonej inwentaryzacji indywidualnej potrzeby zgłoszone przez podmiot leczniczy zostały opisane w dokumencie dedykowanym danemu podmiotowi. Grupa C PL01 PL05 Rejestracja x x Poradnia x x Gabinet x x Apteka x x Apteczka oddziałowa x x Zlecenia medyczne x x Punkt pobrań x x Ruch chorych x x Moduły specjalistyczne x x Rehabilitacja x Pracownia x x Sterylizatornia x Zakażenia x x Rozliczenia NFZ x x Raporty i statystyka x x PL kategorii C posiadają rozbudowaną infrastrukturę, wraz z własną serwerownią główną. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych klasy C przyjąć dla systemów HIS lokalne rozwiązanie architektoniczne. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne. disi@pomorskie.eu, Strona 100 z 212

101 Zgodnie z aktualnymi trendami na rynku oprogramowania dla jednostek ochrony zdrowia, jednostki monospecjalistyczne, w szczególności jednostki o specjalizacji psychiatrycznej obsługiwane są z wykorzystaniem standardowego oprogramowania, odpowiednio skonfigurowanego do potrzeb tych jednostek HIS w podmiotach leczniczych klasy A i B PL klasy A i B to podmioty duże lub średnie, zatrudniające powyżej 1000 osób. Podmioty te świadczą szeroki zakres usług medycznych lub są podmiotami specjalistycznymi. Rekomendowane jest przyjęcie dla tego typu jednostek minimalnego zestawu grup funkcjonalności, tak aby spełniał on oczekiwania wszystkich podmiotów tej klasy i jednocześnie pozwalał na elastyczną rozbudowę w przyszłości. Lista podmiotów leczniczych klasy A, B jest następująca: 1. PL07 Wojewódzki Szpital Specjalistyczny im. Janusza Korczaka w Słupsku Sp. z o.o. 2. PL08 Szpital dla Nerwowo i Psychicznie Chorych im. St. Kryzana w Starogardzie Gdańskim 3. PL12.1 COPERNICUS PL Sp. z o.o. 4. PL14 Szpital Dziecięcy Polanki im. Macieja Płażyńskiego w Gdańsku sp. z o.o. 5. PL16 Szpital Specjalistyczny w Prabutach Sp. z o.o. 6. PL18 Szpital Specjalistyczny w Kościerzynie Sp. z o.o. 7. PL19.2 Szpitale Wojewódzkie w Gdyni sp. z o.o. Minimalne grupy funkcjonalności proponowane do implementacji w ramach projektu PeZ w poszczególnych zostały wyszczególnione w tabeli poniżej. Są to wymagania standardowe, uwzględniające specyfikę poszczególnych PL. Uzasadnione, zgłoszone w trakcie przeprowadzonej inwentaryzacji indywidualnej potrzeby zgłoszone przez podmiot leczniczy zostały opisane w dokumencie dedykowanym danemu podmiotowi. Grupa A i B PL07 PL08 PL12.1 PL14 PL16 PL18 PL19.2 Rejestracja x x x x x x x Poradnia x x x x x x x Gabinet x x x x x x x Apteka x x x x x x x Apteczka oddziałowa x x x x x x x Zlecenia medyczne x x x x x x x disi@pomorskie.eu, Strona 101 z 212

102 Grupa A i B PL07 PL08 PL12.1 PL14 PL16 PL18 PL19.2 Punkt pobrań x 2 x x 3 x x 4 x 5 x 6 Ruch chorych x x x x x x x Moduły specjalistyczne x x x x x Blok operacyjny x x x x Rehabilitacja x x x x x x Pracownia x x x x x x x Sterylizatornia x x x x x Zakażenia x x x x x x x Patomorfologia x x x Stacja dializ x x Żywienie x x x x SOR x x x x Rozliczenia NFZ x x x x x x x Raporty i statystyka x x x x x x x PL kategorii A posiadają rozbudowaną infrastrukturę, wraz z własną serwerownią główną i zapasową a PL kategorii B z jedną serwerownią. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych klasy A i B przyjąć dla systemów HIS lokalne rozwiązanie architektoniczne. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne. 2 Ze wsparciem dla banku krwi i serologii 3 Ze wsparciem dla banku krwi i serologii 4 ze wsparciem dla banku krwi 5 Ze wsparciem dla banku krwi i serologii 6 Ze wsparciem dla banku krwi i serologii disi@pomorskie.eu, Strona 102 z 212

103 Zgodnie z aktualnymi trendami na rynku oprogramowania dla jednostek ochrony zdrowia, jednostki monospecjalistyczne, w szczególności jednostki o specjalizacji psychiatrycznej obsługiwane są z wykorzystaniem standardowego oprogramowania, odpowiednio skonfigurowanego do potrzeb tych jednostek. Specyfika wybranych obszarów działania poszczególnych PL wymaga zastosowania specjalistycznego oprogramowania dziedzinowego, które dostarczane jest przez wąskie grono wyspecjalizowanych firm, zazwyczaj producentów sprzętu z którym to oprogramowanie współpracuje. 6.3 ERP Przykładowy zakres grup funkcjonalności został wskazany poniżej (szczegółowe zakresy funkcjonalne dla każdej z placówek zostaną opracowane w uzgodnieniu z PL na etapie prac analitycznych w trakcie opracowywania dokumentacji przetargowej): obsługa księgowa, obsługa finansowa, ewidencja majątku trwałego, ewidencja kadrowa, obsługa płac, gospodarka magazynowa, zakupy, sprzedaż, zarządzanie inwestycjami, gospodarka remontowa, budżetowanie i controlling, system informowania kierownictwa, raportowanie, kalkulacja kosztów leczenia, transport sanitarny. Wymagania dotyczące integracji z istniejącymi systemami są następujące: poszczególne grupy funkcjonalności systemu ERP są ze sobą zintegrowane i umożliwiają dwukierunkową wymianę danych w czasie rzeczywistym, system jest zintegrowany z HIS i umożliwia dwukierunkową wymianę danych między tymi systemami w czasie rzeczywistym, disi@pomorskie.eu, Strona 103 z 212

104 system jest zintegrowany z systemem BI i hurtownią danych; umożliwia wymianę danych w okresach minimum raz dziennie, system jest zintegrowany z systemem Elektronicznego Obiegu Dokumentów i umożliwia wymianę danych między tymi systemami w czasie rzeczywistym; dodatkowo zapewniona jest możliwość korzystania z funkcjonalności EOD z poziomu ERP. Wymieniony wyżej wykaz jest wynikiem analizy przeprowadzonej w trakcie tworzenia koncepcji. Oznacza to, że nie każdy podmiot otrzyma wszystkie wymienione wyżej grupy funkcjonalności. Zgodnie z założeniami, docelowa lista ta będzie dostosowana dla każdego PL, co zostało omówione w dalszej części tego punktu ERP w podmiotach leczniczych klasy E PL klasy E to podmioty najmniejsze, najczęściej przychodnie. Podmioty te charakteryzują się dużą specjalizacją i specyficznymi potrzebami w zakresie oprogramowania. Rekomendowane jest przyjęcie dla tego typu jednostek minimalnego zestawu grup funkcjonalności, tak aby spełniał on oczekiwania wszystkich podmiotów tej klasy i jednocześnie pozwalał na elastyczną rozbudowę w przyszłości. Minimalne grupy funkcjonalności proponowane do implementacji w ramach projektu PeZ w poszczególnych zostały wyszczególnione w tabeli poniżej. Są to wymagania standardowe, uwzględniające specyfikę poszczególnych PL. Uzasadnione, zgłoszone w trakcie przeprowadzonej inwentaryzacji indywidualnej potrzeby zgłoszone przez podmiot leczniczy zostały opisane w dokumencie dedykowanym danemu podmiotowi. Grupa E PL06 PL10 PL17 obsługa księgowa x x x obsługa finansowa x x x ewidencja majątku trwałego x x x ewidencja kadrowa x x x obsługa płac x x x gospodarka magazynowa x x x zakupy x x x sprzedaż x x x zarządzanie inwestycjami x x disi@pomorskie.eu, Strona 104 z 212

105 Grupa E PL06 PL10 PL17 gospodarka remontowa x x budżetowanie i controlling x x system informowania kierownictwa x x raportowanie x x x kalkulacja kosztów leczenia x x x transport sanitarny x x Tabela 5 Minimalne grupy funkcjonalności ERP dla podmiotów leczniczych klasy E PL kategorii E charakteryzują się małymi zespołami ludzkimi i niewielką skalą działania. Analizując w jakim modelu powinny w nich funkcjonować systemy informatyczne należy zwrócić w pierwszej kolejności uwagę na aspekty formalno-prawne. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych klasy E przyjąć dla systemów ERP rozwiązanie architektoniczne oparte o chmurę prywatną i model usługowy SaaS ERP w podmiotach leczniczych klasy D PL klasy D to Pogotowia Ratunkowe. Podmioty te świadczą specjalistyczny zakres usług medycznych. Rekomendowane jest przyjęcie dla tego typu jednostek minimalnego zestawu grup funkcjonalności, tak aby spełniał on oczekiwania wszystkich podmiotów tej klasy i jednocześnie pozwalał na elastyczną rozbudowę w przyszłości. Minimalne grupy funkcjonalności proponowane do implementacji w ramach projektu PeZ w poszczególnych PL zostały wyszczególnione w tabeli poniżej. Są to wymagania standardowe, uwzględniające specyfikę poszczególnych PL. Uzasadnione, zgłoszone w trakcie przeprowadzonej inwentaryzacji indywidualnej potrzeby zgłoszone przez podmiot leczniczy zostały opisane w dokumencie dedykowanym danemu podmiotowi. Grupa D PL02 PL11 obsługa księgowa x x obsługa finansowa x x ewidencja majątku trwałego x x disi@pomorskie.eu, Strona 105 z 212

106 Grupa D PL02 PL11 ewidencja kadrowa x x obsługa płac x x gospodarka magazynowa x x zakupy x x sprzedaż x x raportowanie x x kalkulacja kosztów leczenia x x transport sanitarny x x Tabela 6: Minimalne grupy funkcjonalności ERP dla podmiotów leczniczych klasy D PL tej kategorii posiadają rozbudowaną infrastrukturę, wraz z własną serwerownią. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych tej klasy, przyjąć dla systemów ERP lokalne rozwiązanie architektoniczne. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne ERP w podmiotach leczniczych klasy A, B i C PL klasy A, B i C to podmioty duże i średnie, zatrudniające powyżej 1000 osób. Podmioty te świadczoną szeroki zakres usług medycznych. Rekomendowane jest przyjęcie dla tego typu jednostek minimalnego zestawu grup funkcjonalności, tak aby spełniał on oczekiwania wszystkich podmiotów tej klasy i jednocześnie pozwalał na elastyczną rozbudowę w przyszłości. Minimalne grupy funkcjonalności proponowane do implementacji w ramach projektu PeZ w poszczególnych zostały wyszczególnione w tabeli poniżej. Uzasadnione, zgłoszone w trakcie przeprowadzonej inwentaryzacji indywidualnej potrzeby zgłoszone przez podmiot leczniczy zostały opisane w dokumencie dedykowanym danemu podmiotowi. Grupa A PL07 PL12.1 PL19.2 obsługa księgowa x x x obsługa finansowa x x x ewidencja majątku trwałego x x x disi@pomorskie.eu, Strona 106 z 212

107 Grupa A PL07 PL12.1 PL19.2 ewidencja kadrowa x x x obsługa płac x x x gospodarka magazynowa x x x zakupy x x x sprzedaż x x x zarządzanie inwestycjami x x x gospodarka remontowa x x x budżetowanie i controlling x x x system informowania kierownictwa x x x raportowanie x x x kalkulacja kosztów leczenia x x x transport sanitarny x x x Grupa B PL08 PL14 PL16 PL18 obsługa księgowa x x x x obsługa finansowa x x x x ewidencja majątku trwałego x x x x ewidencja kadrowa x x x x obsługa płac x x x x gospodarka magazynowa x x x x zakupy x x x x sprzedaż x x x x zarządzanie inwestycjami x disi@pomorskie.eu, Strona 107 z 212

108 Grupa B PL08 PL14 PL16 PL18 gospodarka remontowa x budżetowanie i controlling x x x x system informowania kierownictwa x x x x raportowanie x x x x kalkulacja kosztów leczenia x x x x transport sanitarny x x x x Grupa C PL01 PL05 obsługa księgowa x x obsługa finansowa x x ewidencja majątku trwałego x x ewidencja kadrowa x x obsługa płac x x gospodarka magazynowa x x zakupy x x sprzedaż x x budżetowanie i controlling x x system informowania kierownictwa x x raportowanie x x kalkulacja kosztów leczenia x x transport sanitarny x x PL kategorii A, B i C charakteryzują się dużymi zespołami ludzkimi i dużą skalą działania. PL tej kategorii posiadają rozbudowaną infrastrukturę, wraz z własną serwerownią. Na bazie disi@pomorskie.eu, Strona 108 z 212

109 przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych tej klasy, przyjąć dla systemów ERP lokalne rozwiązanie architektoniczne. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne RCP Przykładowy zakres funkcjonalności dla systemu rejestracji czasu pracy został wskazany poniżej (szczegółowe zakresy funkcjonalne dla każdej z placówek zostanie opracowany w uzgodnieniu z PL na etapie prac analitycznych w trakcie opracowywania dokumentacji przetargowej): automatyczna rejestracja zdarzeń związanych z przyjściem oraz wyjściem pracownika do i z podmiotu leczniczego poprzez karty zbliżeniowe, edycja zdarzeń typu wejście wyjście, kontrola użytkowników i grup, sterowanie kalendarzem, harmonogramowanie pracy (planowanie pracy, planowanie zmian, itp.), integracja modułem kadry i płace systemu ERP, raporty. Ważne jest, by system RCP, który będzie docelowo wdrażany w poszczególnych podmiotach, zgodny był z przepisami prawa pracy oraz wewnętrznymi regulacjami w tym zakresie, obowiązującymi w tych podmiotach. Powinien również umożliwiać np. integrację z systemami bramek wejściowych i systemach kontroli do pomieszczeń chronionych (w podmiotach, których takie rozwiązanie posiadają). 6.4 PACS System PACS (Picture Archiving and Communication System) to platforma obrazowa, umożliwiająca długoterminową, cyfrową archiwizację oraz dostęp do badań różnego rodzaju (radiologia, kardiologia, onkologia itd.) oraz różnych modalności (USG, CT, MR, RTG, Angio itd.) z poziomu tej samej przeglądarki. Przeglądarka obrazów wyświetla je zgodnie ze standardem DICOM, w jakości diagnostycznej. Rozwiązanie to znacznie upraszcza przebieg pracy i spójną organizację danych, a dzięki przydatnemu zestawowi narzędzi klinicznych zapewnia obsługę wielu specjalizacji medycznych i różnych technik obrazowania. System PACS powinien być łatwy w obsłudze i dostosowywany do infrastruktury informatycznej podmiotów leczniczych. Systemy PACS wdrażane w ramach projektu PeZ powinny zapewniać bezpieczny zdalny dostęp do obrazów, opisów badań (w przypadku integracji z systemem RIS) oraz innych załączników disi@pomorskie.eu, Strona 109 z 212

110 (zeskanowane dokumenty, notatki itp.) z każdego miejsca w szpitalu. System musi zapewniać zgodność międzynarodowymi standardami DICOM, HL7 oraz profilami IHE. Ucyfrowienie w obszarze diagnostyki obrazowej będzie możliwe tylko dla urządzeń posiadających aktywny interfejs cyfrowy. Minimalny zakres grup funkcjonalności, jakie powinny być zapewnione dla podmiotów leczniczych jest następujący: PACS zapewnia zdalny dostęp do obrazów, opisów badań oraz innych załączników (zeskanowane dokumenty, notatki itp.) z każdego miejsca w szpitalu, z zewnętrznych podmiotów i z domu. Zdalny dostęp można uzyskać z każdego miejsca na świecie. Przykładowy zakres grup funkcjonalności został wskazany poniżej (szczegółowe zakresy funkcjonalne dla każdej z placówek zostaną opracowane w uzgodnieniu z PL na etapie prac analitycznych w trakcie opracowywania dokumentacji przetargowej): w zakresie dystrybucji wyników: zdalny dostęp do obrazów i opisów badań, możliwość wysłania opisu badania pocztą elektroniczną, możliwością nagrania i kopiowania płyty CD/DVD z dowolnej stacji roboczej z dostępem do systemu, w zakresie zgodności ze standardami komunikacji danych zgodność z DICOM, w zakresie funkcjonalności klinicznych: Maximum Intensity Projection MIP, Average Intensity Projection AIP, Multi Planar Reconstruction MPR, Weighted MIP i AIP, Volume Rendering, Digital Subtraction Angiography DSA, pomiary USG - np. Doppler, wygładzanie obrazu, reverse panning for mammography, w zakresie funkcjonalności przeglądarki: takie samo oprogramowanie dla każdego rodzaju użytkownika (różnice polegają tylko na uprawnieniach), wykorzystanie technologii WEB, protokoły wyświetlania badań definiowane dla grup użytkowników lub indywidualnie, disi@pomorskie.eu, Strona 110 z 212

111 3 sposoby ręcznego rozmieszczania serii badań (poza automatycznymi protokołami), wyświetlanie CT/MR Enhanced objects, wyświetlanie obrazów SPECT i medycyny nuklearnej, obsługa Visual Light Objects (VLO), automatyczna i manualna synchronizacja serii i badań, automatyczne linie referencyjne, powiększenie z możliwością dobrania wielkości kształtu i skali powiększenia, pomiary i adnotacja, rotacja i lustrzane odbicie, wybór zdefiniowanych ustawień kontrastu, uproszczona nawigacja za pomocą myszki i klawiatury, obsługa obrazów kluczowych, kalibracja obrazu, eksport obrazów w formatach BMP, JPEG, i AVI, możliwość elastycznego i zaawansowanego definiowania protokołów wyświetlania badań, obsługa wielu monitorów oraz monitorów monochromatycznych, obsługa cine (dla multi-frame) (do 60 fps), nagrywanie i kopiowanie CD/DVD na lokalnym PC, w zakresie optymalizacji przepływu pracy: integracja z RIS (wywoływanie przeglądarki PACS z poziomu Systemu RIS lub HIS), listy robocze dostosowane do potrzeb użytkownika, zaawansowane filtrowanie, zarządzanie statusem badania, archiwizacja i wyświetlanie załączonych plików, dodatkowo, system powinien dostarczać panel administratora, dostępny przez przeglądarkę WWW, z każdego komputera z dostępem do sieci szpitalnej PACS w podmiotach leczniczych klasy E Podmioty klasy E w większości nie posiadają oddziałów diagnostycznych. Analiza potrzeb wykazała, że w systemy PACS powinny być wyposażone PL wymienione w tabeli poniżej. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych klasy A przyjąć dla systemów PACS rozwiązanie architektoniczne oparte o chmurę prywatną i model usługowy SaaS. disi@pomorskie.eu, Strona 111 z 212

112 Nazwa jednostki PL17 Przemysłowy Zespół Opieki Zdrowotnej Sp. z o.o. Pracownie diagnostyczne Badanie rtg - szeroki zakres Tabela 7: PL klasy E, które powinny posiadać system PACS PACS w podmiotach leczniczych klasy D Podmioty klasy D nie mają potrzeb w zakresie systemów PACS PACS w podmiotach leczniczych klasy A, B i C Wszystkie podmioty klasy A, B i C posiadają oddziały diagnostyczne, zatem każdy z nich powinien być wyposażony w systemy PACS (zgodnie z tabelą poniżej). Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych tej klasy przyjąć dla systemów PACS lokalne rozwiązanie architektoniczne. Nazwa jednostki PL05 Wojewódzki Zespół Reumatologiczny im. dr Jadwigi Titz-Kosko Pracownie diagnostyczne Pracownie diagnostyczne Pracownia RTG Zakład Diagnostyki Obrazowej: PL07 Wojewódzki Szpital Specjalistyczny im. Janusza Korczaka w Słupsku Sp. z o.o. PL12.1 COPERNICUS PL Sp. z o.o. (obejmująca także były Szpital Specjalistyczny im. Św. Wojciecha w Gdańsku Gdańsk, Al. Jana Pawła II 50) PL18 Szpital Specjalistyczny w Kościerzynie Sp. z o.o. Pracownia Tomografii Komputerowej Pracownia Radiologii Zabiegowej Pracownia Rentgenodiagnostyki Ogólnej Pracownia Mammografii Pracownia Rezonansu Magnetycznego Pracownia Angiografii Pracownie diagnostyki obrazowej Zakład diagnostyki obrazowej Dział diagnostyki obrazowej Zakład Diagnostyki Obrazowej PL19.2 Szpitale Wojewódzkie w Gdyni Sp. z o.o. Pracownia tomografii komputerowej Pracownia radiologii zabiegowej Pracownia rentgenodiagnostyki ogólnej Pracownia opisowa Zakład Medycyny Nuklearnej disi@pomorskie.eu, Strona 112 z 212

113 Nazwa jednostki PL08 Szpital dla Nerwowo i Psychicznie Chorych im. St. Kryzana w Starogardzie Gdańskim PL16 Szpital Specjalistyczny w Prabutach Sp. z o.o. Pracownie diagnostyczne Pracownia rentgenodiagnostyki ogólnej Pracownie Diagnostyki Obrazowej: TK, RTG, USG Tabela 8: PL klasy A, B i C, które powinny posiadać system PACS 6.5 RIS Zadaniem systemu RIS (Radiology Information System) jest kompleksowe wsparcie procesu realizacji badania radiologicznego. Proces ten obejmuje etapy: planowania wizyt i rejestracji pacjenta, wykonanie badania, sporządzenie i wydanie opisu. W proponowanej koncepcji dopuszcza się dostarczenie systemu RIS jako jednego z modułów HIS, bądź jako osobne rozwiązanie, zapewniające z HIS dwustronną komunikację w standardzie HL7. Kluczowe jest, aby zapewniał pełną integrację z PACS (w standardzie DICOM). Integracja z HIS pozwoli na spełnienie założeń projektu PeZ związanego z udostępnianiem dokumentacji medycznej (w koncepcji założono, że HIS będzie systemem, do którego będzie podłączona regionalna warstwa integracyjna). Przykładowy zakres grup funkcjonalności dla RIS może być następujący (szczegółowe zakresy funkcjonalne dla każdej z placówek zostaną opracowane w uzgodnieniu z PL na etapie prac analitycznych w trakcie opracowywania dokumentacji przetargowej): w zakresie rejestracji: możliwość rezerwacji badania, możliwość uproszczonej (wprowadzenie jedynie niektórych, wcześniej zdefiniowanych danych obligatoryjnych) rejestracji pacjenta dla badań pilnych, możliwość automatycznego wybrania badania jako pilnego podczas rejestracji przez technika w trybie dyżurowym, możliwość widoku badań planowych i nieplanowych w terminarzu, możliwość szybkiego wyboru daty w terminarzu (miniaturowy kalendarz), wyświetlanie ilości pacjentów aktualnie oczekujących na wykonanie badania, generowanie harmonogramu pracy pracowni na każdy dzień, disi@pomorskie.eu, Strona 113 z 212

114 możliwość wygenerowania i udostępnienia użytkownikowi obrazu ISO (dane DICOM WG-02, 03, 07, 12, 15, 16, 17, 21, 21, opis) i nadruku na płytę (możliwość ręcznego nagrywania badania), możliwość wygenerowania i udostępnienia użytkownikowi obrazu do nadruku na CD (możliwość ręcznego nagrywania badania), w zakresie zarządzania wizytami: skalowalny, graficzny przegląd wizyt zapisanych w terminarzu; możliwość dostosowania przedziałów czasowych (5 min, 10 min, 15 min, 20 min itd.) w zależności od potrzeb poszczególnych pracowni, możliwość zmiany widoku listy wizyt w zależności od wybranego czasu i daty, wyświetlanie wizyt w widoku dziennym lub tygodniowym dla poszczególnych pracowni, możliwość zdefiniowania różnych czasów badań dla różnych typów urządzeń (np. inne czasy badań dla rezonansu magnetycznego 1,5T i 3T), możliwość tworzenia i zarządzania pasmami rezerwacji (czasy pracy pracowni, święta, czasy przerw w pracy urządzenia np. serwis, dodatkowe informacje, możliwość wydruku listy wizyt w wybranym dniu, możliwość zarezerwowania terminu wizyty bez podania przez pacjenta pełnych danych dotyczących badania czy ubezpieczenia (np. gdy rezerwacja odbywa się telefonicznie), możliwość wyszukania i wyświetlenia szczegółów wizyty: ID pacjenta, nazwisko, imię, rodzaj badania, możliwość szybkiego wyszukiwania wizyt na podstawie częściowo wpisanych danych, takich jak: nr badania, PESEL, nazwisko, imię pacjenta, filtrowanie i sortowanie wyświetlanych wizyt, dostęp do informacji archiwalnych z poprzednich wizyt danego pacjenta, możliwość tworzenia wizyt nachodzących czasowo na siebie, możliwość dokonywania szybkich zmian daty i godziny wizyty pomiędzy dniami tygodnia i godzinami (drag&drop), szybkie rezerwowanie i zgłaszanie wizyt na CITO w terminarzu badań nieplanowych, możliwość zdefiniowania praw dostępu do poszczególnych pracowni diagnostycznych dla użytkowników systemu, wyświetlanie wizyt przypisanych do: poszczególnych użytkowników lub grup użytkowników (radiolodzy, technicy, rejestracja, administracja), disi@pomorskie.eu, Strona 114 z 212

115 system cenników z podziałem na płatników, procedury medyczne, czas obowiązywania, dodatkowe parametry jednostek zlecających (min. REGON i NIP jednostki zlecającej), w zakresie realizacji badań diagnostycznych: system śledzenia, czy pacjent oczekuje na badanie, lista pacjentów oczekujących na badanie z informacjami dotyczącymi priorytetu badania lub informacjami o przypadkach pilnych, automatyczne dokumentowanie informacji o czasie rozpoczęcia/zakończenia badania i użytkowniku systemu, który badanie przeprowadzał, automatyczne dokumentowanie czasu trwania badania, możliwość dodawania kolejnego badania bezpośrednio w pracowni diagnostycznej, możliwość zmiany wykonywanej procedury bezpośrednio w pracowni diagnostycznej, możliwość usuwania badania bezpośrednio w pracowni diagnostycznej, możliwość doprecyzowania typu wykonywanej procedury (np. procedura z kontrastem), dowolnie definiowalna lista zużywanych materiałów dla każdego badania, w zakresie raportowania i statystyki dostępny katalog typowych raportów dostępnych bezpośrednio z systemu RIS, możliwość eksportu raportów do formatu czytelnego dla Microsoft Excel, OpenOffice, LibreOffice, system powinien wspierać standard DICOM, w szczególności funkcjonalność DICOM Modality Worklist, w tym generowanie DICOM Modality Worklist zależnie od statusu badania, generowanie listy roboczej DICOM zależnie od poszczególnych typów badań, pracowni diagnostycznych, urządzeń diagnostycznych, system powinien dostarczać możliwość integracji z innymi systemami (HIS/PACS) w podmiotach leczniczych, a także zapewniać wsparcie dla teleradiologii poprzez możliwość zdefiniowania i podłączenia dowolnej liczby stacji diagnostycznych i archiwów PACS, system powinien pobierać/dostarczać informacje z/do systemu HIS podmiotu leczniczego w zakresie rozliczeń z NFZ, disi@pomorskie.eu, Strona 115 z 212

116 dodatkowo system powinien zapewniać pracę z wykorzystaniem wiodących przeglądarek internetowych, na komputerach wykorzystywanych w podmiotach leczniczych (Windows Vista/7/8/10, Linux, Mac OSX), interfejs użytkownika i pomoc kontekstowa powinny być napisane w języku polskim. Wszelkie działania, w szczególności historia zmian powinny być automatycznie logowane. Powyższa lista zawiera wymagania zalecane. Proponowana koncepcja zakłada dostarczenie do podmiotów leczniczych zintegrowanych rozwiązań PACS/RIS. Oznacza to, co do zasady, że podmioty, które zgodnie z przeprowadzoną analizą zostaną wyposażone w systemy PACS, otrzymają również system RIS RIS w podmiotach leczniczych klasy E Analiza potrzeb wykazała, że w systemy RIS powinny być wyposażone PL wymienione w tabeli poniżej. Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych klasy A przyjąć dla systemów RIS rozwiązanie architektoniczne oparte o chmurę prywatną i model usługowy SaaS. Nazwa jednostki PL17 Przemysłowy Zespół Opieki Zdrowotnej Sp. z o.o. Pracownie diagnostyczne Badanie rtg - szeroki zakres Tabela 9: PL klasy E, które powinny posiadać system RIS RIS w podmiotach leczniczych klasy D Analiza potrzeb wykazała, że podmioty lecznicze klasy D nie mają zapotrzebowania na system RIS RIS w podmiotach leczniczych klasy A, B i C Każdy z podmiotów leczniczych klasy A, B i C powinien być wyposażony w systemy RIS (zgodnie z tabelą poniżej). Wdrażany bądź modernizowany system musi spełniać aktualne wymogi prawne. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych tej klasy przyjąć dla systemów RIS lokalne rozwiązanie architektoniczne. Nazwa jednostki Wojewódzki Zespół Reumatologiczny im. dr Jadwigi Titz- Kosko Pracownie diagnostyczne Pracownie dianostyczne Pracownia RTG disi@pomorskie.eu, Strona 116 z 212

117 Nazwa jednostki COPERNICUS PL Sp. z o.o. (obejmująca także były Szpital Specjalistyczny im. Św. Wojciecha w Gdańsku Gdańsk, Al. Jana Pawła II 50) Szpitale Wojewódzkie w Gdyni Sp. z o.o. Pracownie diagnostyczne Pracownie diagnostyki obrazowej Zakład diagnostyki obrazowej Pracownia Diagnostyki Obrazowej ->Pracownia tomografii komputerowej ->Pracownia radiologii zabiegowej ->Pracownia rentgenodiagnostyki ogólnej Zakład Medycyny Nuklearnej Szpital Specjalistyczny w Kościerzynie Sp. z o.o. Wojewódzki Szpital Specjalistyczny im. Janusza Korczaka w Słupsku Sp. z o.o. Szpital Specjalistyczny w Prabutach Sp. z o.o. Dział diagnostyki obrazowej Zakład Diagnostyki Obrazowej: - Pracownia Tomografii Komputerowej - Pracownia Radiologii Zabiegowej - Pracownia Rentgenodiagnostyki Ogólnej - Pracownia Mammografii - Pracownia Rezonansu Magnetycznego - Pracownia Angiografii Pracownie Diagnostyki Obrazowej: TK,RTG, USG Tabela 10: PL klasy A, B i C które powinny posiadać system RIS 6.6 LIS Przykładowy zakres grup funkcjonalności dla LIS został wskazany poniżej (szczegółowe zakresy funkcjonalne dla każdej z placówek zostaną opracowane w uzgodnieniu z PL na etapie prac analitycznych w trakcie opracowywania dokumentacji przetargowej): w zakresie rejestracji pacjentów i zleceń diagnostycznych: prowadzenie kartoteki pacjentów i ich rejestracja, łącznie z datą przyjęcia do szpitala, grupy krwi i Rh, oraz identyfikacja pacjenta na podstawie różnych danych: demograficznych, nr księgi głównej, identyfikatora zewnętrznego, rejestracja serologicznej historii pacjenta (daty, zmiany: grupy krwi, wykryte alloprzeciwciała, powikłania poprzetoczeniowe, konsultacje, kwalifikacje do podania immunoglobuliny), sygnalizacja (wyróżnianie) takich pacjentów przy wyświetlaniu 7, 7 dotyczy LIS dla serologii disi@pomorskie.eu, Strona 117 z 212

118 rejestracja zleceń (wszystkie badania), od zleceniodawców szpitalnych i zewnętrznych, całkowicie automatyczny dobór cen dla wykonywanych badań, automatyczne rozliczanie zleceń, z uwzględnieniem specjalnych ich rodzajów (cito, dyżury...), możliwość automatycznej rejestracji zleceń za pomocą czytnika (skanera) OMR, prowadzenie głównej książki zleceń i możliwość jej wydruku, zapewnienie możliwości współpracy z innymi laboratoriami w zakresie automatycznego tworzenia wysyłkowych list zleceń z niektórych badań i zwrotnego odbioru (rejestracji) wyników oraz rozliczeń; możliwość uwzględnienia takich wyników na zbiorczym formularzu wyniku dla pacjenta, obsługa pracowni 8 : Hematologii, Koagulologii, Analityki ogólnej, Biochemii, Immunologii, Analiz dyżurowych, Serologii 9, Mikrobiologii 10, Wirusologii i Toksykologii; zapewnienie możliwości działania laboratoriów analityki, mikrobiologii 11 i serologii transfuzjologicznej 12 w oparciu o jedną, wspólną bazę danych, z możliwością tworzenia wspólnych raportów statystycznych i rozliczeniowych, wsparcie dla procesu analitycznego: prowadzenie książek zleceń i wyników w pracowniach, automatycznie sprzężonych z książką główną, definiowanie w dowolnym czasie i automatyczne prowadzenie ksiąg (ewidencji/list) wg określonych wymagań, automatyczne kierowanie badań do stanowisk, na których mają być wykonane, z uwzględnieniem alternatywnych metod wykonywania, w tym możliwość przekierowywania badań do innej pracowni, pełna automatyka sterowania analizatorami diagnostycznymi (programowanie, wysyłanie zleceń, odbiór wyników, przesłanie informacji technicznych), automatyczna współpraca z analizatorami w zakresie kontroli przeciwciał anty-d grupy VI u dawców 13, manualne wprowadzanie wyników serologicznych, zapewniające 14 : 8 w zależności od indywidualnych potrzeb PL 9 dotyczy LIS dla serologii 10 dotyczy LIS dla mikrobiologii 11 dotyczy LIS dla mikrobiologii 12 dotyczy LIS dla serologii 13 dotyczy LIS dla serologii 14 dotyczy LIS dla serologii disi@pomorskie.eu, Strona 118 z 212

119 wprowadzenie pełnego protokołu wraz ze stopniami aglutynacji, automatyczną weryfikację zgodności protokołu z wydawanym wynikiem i znaną z historii pacjenta jego dotychczasową grupą krwi i Rh, możliwość wprowadzania rzadkich grup krwi, opisywanie wyników, również uzyskanych automatycznie, przyspieszona, automatyczna obsługa zleceń pilnych, automatyczny dobór wartości referencyjnych i automatyczne flagowanie wyników, w tym flagowanie wyników będących tekstowymi opisami, z możliwością dowolnej liczby zakresów referencyjnych, osobno dla każdej metody wykonania badania, elastyczny system rejestracji wyników mikrobiologicznych, uwzględniający 15 : kolejno izolowane organizmy, predefiniowane testy antybiogramowe z definicjami stref wrażliwości, z możliwością modyfikacji (dodawania pojedynczych testów) w trakcie wykonania, przeprowadzone testy identyfikacyjne, ograniczenie dostępnych dla organizmu antybiotyków i mechanizmów oporności, wykonane antybiogramy wraz z parametrami (strefa, MIC), rejestracja błędów wykonania, określanie, analiza i sygnalizacja przekroczenia krytycznych wartości wyników badań, grupa funkcjonalności dla obsługi Szpitalnego Banku Krwi, umożliwiająca 16 : rejestrację dokumentów (dostawa, zamówienie, wydanie, zwrot, zniszczenie) z automatycznym generowaniem odpowiednich protokołów i zleceń na badania serologiczne, automatyczne przyjmowanie wyników badań serologicznych, automatyczne generowanie dokumentów wydania, rejestracja przychodu składnika krwi, z rozróżnieniem przychodu z zewnątrz, przychodu po wykonaniu dodatkowego procesu technologicznego, i bilansu otwarcia, dane zakodowane na etykiecie kodem ISBT mają być wprowadzane skanerem, zapewniony jest wydruk protokołu transportu (po zarejestrowaniu dokumentu), 15 dotyczy LIS dla mikrobiologii 16 dotyczy LIS dla banku krwi disi@pomorskie.eu, Strona 119 z 212

120 rejestracja zamówienia składników krwi, rejestracja wydania składników krwi zgodnie z zamówieniem, automatycznie wykorzystująca dane z zamówienia, automatyczny (po zarejestrowaniu wydania) wydruk protokołu wydania/transportu, rejestracja zwrotu składnika krwi, rejestracja likwidacji składnika krwi, rejestracja reklamacji składnika krwi, zapewnienie możliwości automatycznej identyfikacja materiału: system znakowania kodami paskowymi ( oklejanie w miejscu pobrania, nie w laboratorium) niewymagający drukarek tych kodów, automatyczna identyfikacja materiału biorców i krzyżowanych składników zgodna z oryginalnymi oznaczeniami kodem kreskowym materiału pobranego od pacjenta oraz z banku krwi 17. jednoznaczna identyfikacja pacjenta, zlecenia i każdej próbki materiału w oparciu o kod paskowy, również rozróżnianie materiałów w ramach jednego zlecenia, nieograniczone czasowo wykrycie i możliwość blokady użycia w systemie dwóch probówek z identycznym kodem kreskowym, wykorzystanie kodów kreskowych we współpracy z analizatorami, funkcja przyjęcia materiału, umożliwiająca rejestrację materiału z równoczesną weryfikacją zlecenia (wykrycie zleceń, do których brak materiału, oraz materiału, do którego brak zlecenia), uwzględnienie tego faktu w procesie analitycznym, kontrola jakości i wiarygodności wyników, zabezpieczenie dostępu do danych zgodnie z obowiązującymi przepisami (w tym ustawy o ochronie danych osobowych), rejestracja, śledzenie i odtwarzanie czynności ważnych dla procesu analitycznego (godzina pobrania, rejestracji zlecenia, planowana godzina wykonania badania, przyjęcia materiału, wykonania, zatwierdzenia, wydruku/ wydania), z podaniem kto i kiedy wykonał, z uwidocznieniem tej informacji na wydruku wyniku, katalogowanie miejsca przechowywania próbek po wykorzystaniu (niekłopotliwe dla użytkownika, np. pojedynczy odczyt kodu kreskowego) z możliwością późniejszego odszukania i wskazania. 17 dotyczy LIS dla banku krwi disi@pomorskie.eu, Strona 120 z 212

121 Powyższa lista zawiera wymagania zalecane. Docelowa lista funkcjonalności zależy od decyzji SWP i podmiotów leczniczych. Uzasadnione, zgłoszone w trakcie przeprowadzonej inwentaryzacji indywidualnej potrzeby zgłoszone przez PL zostały opisane w dokumencie dedykowanym danemu podmiotowi. Należy przyjąć, że większość PL zleca badania innym firmom tzw. outsourcing. System musi przewidywać również taką funkcjonalność LIS w podmiotach leczniczych klasy E Podmioty klasy E w większości nie posiadają oddziałów laboratoryjnych. Z tego powodu w proponowanej koncepcji przyjęto założenie, aby w tych podmiotach nie wdrażać osobnych systemów LIS LIS w podmiotach leczniczych klasy D Analiza potrzeb wykazała, że PL klasy D nie mają potrzeb w zakresie informatyzacji LIS LIS w podmiotach leczniczych klasy A, B i C Analiza potrzeb wykazała, że w systemy LIS powinny być zintegrowane z systemem HIS (wymagana jest pełna integracja). Wdrażany bądź modernizowany system LIS musi spełniać aktualne wymogi prawne. Na bazie przeprowadzonej analizy oraz dostępnych na rynku rozwiązań rekomendujemy dla podmiotów leczniczych tej klasy przyjąć dla systemów LIS lokalne rozwiązanie architektoniczne. Nazwa jednostki COPERNICUS PL Sp. z o.o. (obejmująca także były Szpital Specjalistyczny im. Św. Wojciecha w Gdańsku Gdańsk, Al. Jana Pawła II 50) Zakres Standardowy, wraz z bankiem krwi i serologią Szpital Specjalistyczny w Kościerzynie Sp. z o.o. Standardowy, wraz z bankiem krwi i serologią Szpitale Wojewódzkie w Gdyni Sp. z o.o. Wojewódzki Szpital Specjalistyczny im. Janusza Korczaka w Słupsku Sp. z o.o. Wojewódzki Szpital Psychiatryczny im. prof. Tadeusza Bilikiewicza w Gdańsku Standardowy, wraz z bankiem krwi i serologią Standardowy, wraz z bankiem krwi i serologią Standardowy disi@pomorskie.eu, Strona 121 z 212

122 Nazwa jednostki Szpital dla Nerwowo i Psychicznie Chorych im. St. Kryzana w Starogardzie Gdańskim Zakres Standardowy Tabela 11: PL klasy A, B i C, które powinny posiadać system LIS 6.7 EOD Przykładowy zakres grup funkcjonalności został wskazany poniżej (szczegółowe zakresy funkcjonalne dla każdej z placówek zostaną opracowane w uzgodnieniu z PL na etapie prac analitycznych w trakcie opracowywania dokumentacji przetargowej): system obiegu dokumentów (EOD), musi spełniać wszystkie warunki związane z elektronicznym zarządzaniem dokumentacją, zgodnie z rozporządzeniem prezesa Rady Ministrów z dnia 18 stycznia 2011 roku w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U r., nr 14, poz. 67 z poz. zm.), EOD musi być zgodny z przepisami prawa: Ustawa z dnia 14 czerwca 1960 r. kodeks postępowania administracyjnego (Dz.U r., nr 98, poz z późn. zm.); Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U r., nr 101, poz. 926 z późn. zm.); Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i komponenty informatyczne służące do przetwarzania danych osobowych (Dz.U r., nr 100, poz. 1024); Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (Dz. U r., nr 123, poz. 698 z późn. zm.); Rozporządzenie Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U r., nr 14, poz. 67 z późn. zm.); Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz.U r., nr 206, poz. 1519); disi@pomorskie.eu, Strona 122 z 212

123 Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U r., nr 206, poz. 1518); Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz.U r., nr 206, poz. 1517); Rozporządzenie Ministra Kultury z dnia 16 września 2002 r. w sprawie postępowania z dokumentacją, zasad jej klasyfikowania i kwalifikowania oraz zasad i trybu przekazywania materiałów archiwalnych do archiwów państwowych (Dz.U r., nr 167, poz. 1375); Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U r., nr 130, poz z późn. zm.); Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (tekst jednolity Dz. U r., poz z późn. zm.); Rozporządzenie Ministra Środowiska z dnia r. w sprawie wzoru oraz zawartości i układu publicznie dostępnego wykazu danych o dokumentach zawierających informacje o środowisku i jego ochronie (Dz.U r. nr 186 poz z późn.zm.); EOD musi posiadać architekturę trójwarstwową: warstwa prezentacji, obejmująca interfejsy użytkownika klienta WWW, umożliwiający prezentację danych na komputerach stacjonarnych oraz urządzeniach przenośnych wyposażonych w przeglądarkę internetową, warstwa aplikacji, obejmującą serwer aplikacji Systemu, warstwa danych, zawierającą serwer bazy danych. EOD musi posiadać polskojęzyczny interfejs WWW i polskojęzyczną instrukcję obsługi. EOD musi przechowywać wszystkie dane w bazie danych zgodnej ze standardem SQL oraz zapewniającej transakcyjność operacji. Dopuszcza się przechowywanie poza bazą danych plików, w postaci w repozytorium dyskowego - ich integralność z systemem musi być zapewniona przez metadane opisujące poszczególne pliki. Metadane muszą być przechowywane w bazie danych. EOD musi posiadać mechanizmy pozwalające na ochronę poufności informacji przechowywanych w bazie danych, np. z wykorzystaniem technik szyfrowania. Ochrona powinna zapewniać spójny model bezpieczeństwa dla informacji przechowywanych w pliku bazodanowym, kopii zapasowej, czy plików exportu. EOD musi umożliwiać śledzenie ruchu w architekturze trójwarstwowej. Konieczne jest, aby istniała możliwość kontroli ruchu pomiędzy aplikacją, a bazą danych w taki sposób, disi@pomorskie.eu, Strona 123 z 212

124 aby na etapie tej komunikacji można było eliminować wszelkiego rodzaju ryzyka związane z atakami bazodanowymi. EOD musi umożliwiać dostęp do systemu przez użytkownika końcowego z poziomu przeglądarki internetowej, co najmniej Internet Explorer, Firefox, Google Chrome, Opera w najnowszych wersjach. EOD musi cechować się interfejsem użytkownika opartym na nowoczesnych rozwiązaniach: wykorzystywać menu, listy, formularze, przyciski, referencje (linki), itp. EOD powinien stosować oznaczanie pól wymaganych na formularzu ekranowym w sposób wyróżniający te pola a w przypadku ich błędnego wypełnienia jednoznacznie wskazywał na pola błędnie wypełnione. EOD musi cechować duża elastyczność, rozumiana jako możliwość dostosowania systemu do zmieniających się wymagań funkcjonalnych wynikających ze zmieniającego się stanu prawnego i zmieniających się warunków praktycznych i przepisów prawnych. EOD musi zabezpieczać dane przed przypadkowym nadpisaniem w przypadku równoczesnego korzystania z tych danych przez wielu użytkowników. EOD musi posiadać widok indywidualny, prezentujący tylko te składniki systemu, do których uprawniony jest dany użytkownik. EOD musi obsługiwać rejestrację przesyłek przychodzących, w formie papierowej i elektronicznej (przekazywanych za pośrednictwem Elektronicznej Skrzynki Podawczej na epuap lub poczty elektronicznej). Podczas procesu rejestracji przesyłek przychodzących w formie papierowej EOD musi umożliwiać skanowanie z wykorzystaniem skanera zgodnego z TWAIN (z poziomu interfejsu aplikacji) poszczególnych dokumentów, wchodzących w skład przesyłki. Interfejs do skanowania musi posiadać, co najmniej narzędzia do edycji obrazu ze skanera poprzez: zapis do JPG, PNG i PDF, zmiany kontrastu. EOD musi umożliwiać odebranie poczty elektronicznej za pomocą wbudowanego klienta pocztowego IMAP SSL oraz SMTP TLS/SSL i umożliwić rejestrację w rejestrze przesyłek wpływających lub bezpośrednie dołączenie wiadomości z załącznikami do akt sprawy. EOD musi umożliwiać opatrywanie przesyłek przychodzących metadanymi zgodnie z instrukcją kancelaryjną oraz dowolne rozszerzenie zbioru metadanych w oparciu o rodzaj rejestrowanego dokumentu. System musi umożliwiać generowanie potwierdzenia przyjęcia przesyłki wpływającej przez punkt kancelaryjny, opatrzonego kodem kreskowym odpowiadającym kodowi kreskowemu przesyłki. Potwierdzenie przyjęcia wygenerowane przez EOD musi być konfigurowalne i umożliwiać zamieszczenie, co najmniej daty wpływu, oznaczenia graficznego jednostki, nazwy jednostki. disi@pomorskie.eu, Strona 124 z 212

125 EOD musi umożliwiać rejestrację zwrotów przesyłek oraz pocztowych potwierdzeń odbioru (zwrotek). EOD musi umożliwiać zarządzanie zakresem zawartości słowników systemowych. Minimalna lista słowników to: RWA, Gońcy, Kody pocztowe, Rodzaje dokumentów, Sposoby dostarczania korespondencji, Sposoby wysyłania korespondencji, Statusy spraw, Sposoby płatności. EOD musi umożliwiać prowadzenie wielu punktów kancelaryjnych w zakresie rejestracji przesyłek. EOD musi umożliwiać użytkownikom dekretującym wskazanie jednej lub kilku komórek lub osób merytorycznych - odpowiedzialnych za prowadzenie i zakończenie sprawy. W przypadku wyboru kilku osób, możliwe jest wskazanie osoby odpowiedzialnej za ostateczne załatwienie sprawy. EOD musi umożliwić odróżnienie oraz jednoznaczną identyfikację i odrębne przetwarzanie poszczególnych dokumentów, przechowywanych w postaci odwzorowań cyfrowych wchodzących w skład przesyłki, przy zachowaniu ich powiązania z przesyłką. EOD musi umożliwić dodawanie przez użytkownika informacji opisujących poszczególne dokumenty, przesyłki lub sprawy w postaci notatek, zgodnie z instrukcją kancelaryjną. Dla dokumentów papierowych niepodlegających skanowaniu oraz dokumentów na nośnikach elektronicznych nie podlegających kopiowaniu do systemu EOD, system musi umożliwić sporządzenie metryki, zawierającej podstawowe informacje o dokumencie (co najmniej tytuł, identyfikator, notatka). EOD musi umożliwiać dwustronną komunikację z systemem epuap (odbieranie - wysyłanie dokumentów). EOD musi posiadać wbudowany edytor tekstu WYSYWIG służący do tworzenia dokumentów wewnątrz systemu, bez konieczności używania zewnętrznych aplikacji. Edytor powinien posiadać podstawowe funkcjonalności edytora tekstu służące redagowaniu dokumentów. EOD musi umożliwiać tworzenie szablonów dokumentów na bazie wbudowanego edytora tekstu WYSWIG, EOD musi umożliwić generowanie i drukowanie naklejek z kodami kreskowymi na dokumenty papierowe oraz nośniki i odnajdywanie na podstawie zeskanowanej naklejki odwzorowania cyfrowego bądź metryki danego dokumentu. EOD musi umożliwić rejestrację obiegu (lokalizacja, czas przemieszczenia, użytkownik) dokumentów papierowych (dla których istnieje odwzorowanie cyfrowe oraz dla których nie zostało ono wykonane) oraz nośników. disi@pomorskie.eu, Strona 125 z 212

126 EOD musi umożliwić sporządzanie odwzorowań cyfrowych dokumentów poprzez skanowanie dostępne z poziomu systemu, zgodnie z wymaganiami określonymi w instrukcji kancelaryjnej. EOD musi umożliwić wszczynanie, prowadzenie i załatwianie spraw, przechowywanie akt sprawy i prowadzenie spisów spraw zgodnie z obowiązującymi przepisami. System automatycznie musi nadawać znak sprawy i zapewnia jego zgodność z wymogami instrukcji kancelaryjnej. EOD musi umożliwić prowadzenie rejestrów kancelaryjnych, w tym rejestru przesyłek wpływających, wychodzących oraz pism wewnętrznych. EOD musi umożliwić numerację i klasyfikację spraw w oparciu o JRWA zgodnie z instrukcją kancelaryjną. EOD musi umożliwiać oddzielną rejestrację dokumentów nietworzących akt sprawy, EOD musi umożliwiać wielostopniowy proces akceptacji dokumentów (zgodnie z instrukcją kancelaryjną podmiotu), z możliwością parametryzacji wymagalności akceptacji dla dokumentu przed jego wysłaniem do interesanta lub założeniem z niego sprawy. Użytkownik powinien mieć możliwość swobodnego definiowania ścieżek akceptacji (wskazania konkretnych osób oraz liczby pozytywnych zatwierdzeń dla każdego etapu akceptacji). EOD musi umożliwić zapis projektów pism przekazywanych pomiędzy użytkownikami lub komórkami w trakcie załatwiania sprawy, a także zamieszczanie komentarzy odnoszących się do projektów pism. EOD musi zapewnić prowadzenie, podgląd oraz wydruk metryki sprawy zgodnie z obowiązującymi przepisami. EOD musi umożliwić opisywanie spraw i akt sprawy metadanymi zgodnie z obowiązującymi przepisami. EOD musi umożliwić odnotowanie wysyłki przesyłek wychodzących w rejestrze i opatrzenie ich metadanymi zgodnie z przepisami. EOD musi zapewnić przydzielanie spraw i korespondencji, przekazanych na dane stanowisko, konkretnym użytkownikom, pracującym na tym stanowisku. EOD musi umożliwić podgląd historii sprawy, ścieżki obiegu sprawy. EOD musi posiadać funkcjonalność obsługi kalendarzy. Każdy z użytkowników powinien posiadać dostęp do własnego kalendarza z możliwością dodawania do niego dowolnych zdarzeń. Użytkownik powinien mieć możliwość określenia typu zdarzenia oraz jego opisu. Użytkownik powinien mieć również możliwość definiowania zdarzeń całodniowych i dłuższych oraz cyklicznych. System ma umożliwiać przeglądanie kalendarzy podwładnych. Kalendarz musi umożliwiać dodawanie i edycję wpisów za pomocą mechanizmu przeciągnij i upuść. disi@pomorskie.eu, Strona 126 z 212

127 EOD musi umożliwiać zarządzanie zasobami poprzez ustalanie rezerwacji zasobów. System musi umożliwić definiowanie dowolnych zasobów. Każdy zasób musi być powiązany ze swoim terminarzem, w którym to uprawnieni użytkownicy mają wgląd. Ponadto tylko uprawnieni użytkownicy mogą rezerwować zasoby a jej fakt jest odnotowywany w terminarzu zasobu. Musi również istnieć możliwość grupowania zasobów (np. grupa pojazdy zwierająca pojazdy, którymi dysponuje Zamawiający)." EOD musi posiadać funkcjonalność pozwalającą na zbiorcze podejrzenie dostępności rezerwowanych zasobów i innych użytkowników. System musi umożliwiać rezerwację czasu innych użytkowników (jako współuczestników zdarzenia). EOD musi pozwalać każdemu użytkownikowi swobodnie decydować o tym kto i w jakim zakresie ma dostęp do jego terminarza. Każdy terminarz musi być możliwy do przeglądania w trybie dziennym, tygodniowym, miesięcznym. EOD musi być wyposażony w funkcjonalność komunikatora tekstowego. Komunikator musi być wewnętrznym oprogramowaniem dla urzędu i nie może umożliwiać komunikacji z zewnętrznymi komunikatorami dostępnymi publicznie, EOD musi umożliwić użytkownikowi podgląd przypisanych do niego spraw i korespondencji, z możliwością sortowania, filtrowania i przeszukiwania. EOD musi umożliwiać podpisywanie dokumentów przy pomocy kwalifikowanego podpisu elektronicznego. EOD musi umożliwić informowanie o statusie sprawy w BIP poprzez opracowany w tym celu interfejs udostępniony poprzez Web Services. EOD musi umożliwić wprowadzanie zmian kadrowych, urlopów i zastępstw. Umożliwia przekazanie osobie zastępującej części lub całości uprawnień osoby zastępowanej. Uprawnienia muszą być przekazane na określony czas dat lub bezterminowo. EOD musi posiadać moduł urlopów, EOD musi umożliwiać definiowanie zastępstw na czas nieobecności, polegających na udzieleniu pełnomocnictwa innemu użytkownikowi do wykonywania czynności w imieniu użytkownika nieobecnego. Pełnomocnictwo powinno być definiowane w określonym przedziale czasu. Dostęp do danych nieobecnego użytkownika powinien być kontrolowany przez System i odbierany wraz z upłynięciem daty końcowej. W trakcie trwania zastępstwa w systemie jest prezentowana informacja o zastępowaniu jednej osoby przez drugą. Wszystkie operacje wykonywane w zastępstwie powinny być zapisane w sposób umożliwiający jednoznaczne określenie, kto wykonał daną operację. EOD musi posiadać wbudowany moduł workflow umożliwiający co najmniej: wersjonowanie ścieżek przepływu pracy, disi@pomorskie.eu, Strona 127 z 212

128 definiowanie ścieżek przepływu pracy w oparciu o strukturę organizacyjną jednostki w sposób graficzny poprzez przeciąganie predefiniowanych składników i linii przepływu między nimi, procedowanie i dekretację spraw oraz pism z wykorzystaniem mechanizmu procedowania według definiowalnych ścieżek (mechanizm przepływu pracy - workflow) w pełni zgodnie z instrukcją kancelaryjną, wpinanie w istniejące ścieżki przepływu pracy zewnętrznych interfejsów integracyjnych (usług sieciowych), definiowanie tzw. mapper ów umożliwiających modyfikowanie danych pomiędzy kolejnymi zadaniami przepływu pracy. EOD musi umożliwić modelowanie wielopoziomowej struktury organizacyjnej instytucji, która umożliwi przypisanie pracowników do odpowiednich stanowisk. EOD musi umożliwić definiowanie uprawnień do poszczególnych funkcji systemu oraz grupowanie uprawnień w role w celu ułatwienia administracji systemem. EOD musi umożliwiać delegowanie części lub całości posiadanych uprawnień. System musi posiadać wyodrębniony moduł administracyjny. Dostęp do tego modułu mogą uzyskać jedynie użytkownicy z odpowiednimi uprawnieniami. EOD musi posiadać rozbudowany rejestr zdarzeń rejestrujący akcje użytkowników na obiektach systemowych, udane i nieudane próby logowania oraz typowe błędy aplikacji. Rejestr umożliwia również wskazywanie kont nieużywanych przez użytkowników. EOD umożliwi zarządzanie uprawnieniami w oparciu o grupy uprawnień i grupy zasobów, jakich dotyczą. System uprawnień musi być zdolny do odzwierciedlenia uprawnień i odpowiedzialności poszczególnych pracowników wynikający z Instrukcji Kancelaryjnych oraz struktury stanowisk. Zakres wartości w słownikach prowadzonych przez system powinien być konfigurowalny przez administratora lub pochodzić z rejestrów centralnych (np. TERYT). EOD musi umożliwić nadawanie i ograniczanie uprawnień do danych osobowych interesantów osób fizycznych, zapewniając ochronę tych danych zgodnie z ustawą o ochronie danych osobowych (tekst jednolity Dz.U r., poz z późn. zm.). EOD musi rejestrować wszystkie czynności dostępu do usług i zasobów w systemie, EOD musi posiadać mechanizm informujący użytkownika o wprowadzonych zmianach w aplikacji. EOD oferowany będzie wszystkim podmiotom leczniczym. Na bazie przeprowadzonej analizy rekomendujemy przyjąć dla systemów klasy EOD następujące rozwiązania architektoniczne: disi@pomorskie.eu, Strona 128 z 212

129 chmurę prywatną i model usługowy SaaS, dla podmiotów leczniczych klasy E rozwiązanie mieszane udostępnienie usługi z poziomu warstwy regionalnej zaś składowanie dokumentów wytworzonych i obsługiwanych w placówce lokalnie, dla podmiotów leczniczych klasy A, B, C i D. Podejście to jest optymalne ze względu na: o udostępnienie jednolitej i spójnej wersji oprogramowania EOD dla wszystkich placówek biorących udział w Projekcie PeZ (w przypadku zmiany zgłoszonej przez jeden podmiot modyfikacja oprogramowania zostanie udostępniona wszystkim tym samym koszty zmiany będą ponoszone raz) o konfigurację dedykowanych procesów (ich obsługi) w odniesieniu do potrzeb placówki o składowanie dokumentów na poziomie placówki o możliwość przekazywanie dokumentów/spraw pomiędzy placówkami biorącymi udział w projekcie poprzez warstwę regionalną (szynę danych). 6.8 Lokalny EDM Zgodnie z założeniami PeZ, proponowana koncepcja zakłada dostarczenie funkcjonalności związanych z dostępem i przechowywaniem elektronicznej dokumentacji medycznej w dwóch warstwach modelu architektury. Każdy z podmiotów leczniczych posiadać będzie własny, dedykowane repozytorium EDM autonomiczne w stosunku do systemu HIS. Dodatkowo zaimplementowane zostanie repozytorium EDM w warstwie regionalnej, przechowujące dokumenty przeznaczone do udostępnienia za zgodą pacjenta. Jednocześnie, zgodnie ze standardem IHE XDS.b w warstwie regionalnej zostanie zrealizowany rejestr dokumentów przechowywanych w poszczególnych repozytoriach lokalnych (PL). Przy takim podejściu spełnione zostanie jedno z kluczowych celów projektu PeZ, tj. dostęp do dokumentacji medycznej przez lekarza lokalnie, z danego podmiotu leczniczego oraz zdalnie, z innego podmiotu. Proponowane podejście do realizacji regionalnego EDM zostało omówione w Rozdziale 7 tego dokumentu, w którym przedstawiono koncepcję systemu PRIM. W niniejszym podpunkcie opisano zagadnienia dotyczące lokalnego systemu EDM. Lokalny EDM będzie zintegrowany z regionalnym EDM (PRIM) w celu wysyłania finalnie podpisanych dokumentów medycznych zgodnych z polityką przekazywania EDM, które przechowywane będą w systemie regionalnym. Lokalny EDM zostanie zintegrowany z systemami szpitalnymi HIS w celu zapisywania dokumentów wytworzonych w systemach szpitalnych. Lokalny EDM będzie udostępniał pełne API umożliwiające zaprezentowanie listy dokumentów pacjenta w interfejsie systemu HIS. Lokalny EDM będzie dawał możliwość wprowadzenia dokumentów bezpośrednio z systemów PL (za pomocą API), wprowadzania disi@pomorskie.eu, Strona 129 z 212

130 plików za pomocą interfejsu użytkownika, oraz bezpośrednio z urządzeń skanujących (wielofunkcyjnych). Jednocześnie lokalny EDM powinien być wyposażony w elastyczny moduł wprowadzania wydruków bezpośrednio do repozytorium. Lokalny EDM przechowuje pliki w postaci HL7 CDA, dokumenty wprowadzane są bezpośrednio w tym formacie. Pliki binarne są konwertowane do HL7 CDA. Połączenia pomiędzy systemami szpitalnymi a lokalnym EDM są szyfrowane (SSL). Lokalny EDM będzie zintegrowany z LDAP na poziomie użytkowników i grup. Zmiany w katalogu użytkowników powinny być natychmiastowo zapisywane w tym systemie. Uwierzytelnianie odbywać się powinno za pomocą loginu i hasła przechowywanego w bazie danych. Lokalny EDM powinien obsługiwać system autoryzacji pozwalający na autoryzację użytkownika API za pomocą tokenu (np. openid lub Oauth2). Zalecany zakres grup funkcjonalności, jakie powinny być zapewnione dla podmiotów leczniczych przez lokalny EDM jest następujący: możliwość przechowywania dokumentów w standardzie HL7 CDA Release 2 na dowolnym poziomie (Lv 1-3), lokalny EDM umożliwia przeglądanie zarówno dokumentacji lokalnej, oraz dokumentacji udostępnionej z innych jednostek, lekarz może przenieść dokumenty z innych jednostek i dołączyć do dokumentacji lokalnej PL, możliwość przechowywania dowolnych typów plików binarnych skonwertowanych do formatu HL7 CDA, zapewnienie eksportu dokumentacji medycznej z zachowaniem integralności, możliwość wydruku dokumentacji medycznej, możliwość tworzenia notatek (komentarzy) powiązanych z danym dokumentem, tworzenie rekordu pacjenta będącego wyciągiem z dokumentów medycznych, zawierających najważniejsze dane o pacjencie, rekord pacjenta powinien być zapisywany w otwartym formacie danych (HL7) prezentacja dokumentów w formie listy z możliwością podglądu każdego dokumentu, wraz z załącznikami (o ile takie istnieją), przechowywanie aktualnych dokumentów medycznych wytworzonych w lokalnym systemie typu HIS, przechowywanie wszystkich wersji dokumentów medycznych, przechowywanie indeksów do danych obrazowych z systemów PACS przechowywanych w tych systemach, o ile systemy te oferują taką funkcjonalność, disi@pomorskie.eu, Strona 130 z 212

131 mechanizmy umożliwiające wyszukiwanie według określonych parametrów (metadanych) dokumentu oraz pełno-tekstowe przeszukiwanie treści dokumentów (załączników), mechanizm opisywania dokumentów za pomocą metadanych, możliwość definiowania zestawów metadanych dla poszczególnych typów dokumentów, definiowanie i obsługa poziomów dostępności do wprowadzanej dokumentacji medycznej, minimum w trybach normal i restricted, przez różne grupy lekarzy 18 : krąg uprawnionych lekarzy psychiatrycznych i psychoterapeutów, krąg lekarzy specjalistów, pozostali lekarze, system zezwala na dostęp do dokumentacji medycznej zgodnie z informacjami dotyczącymi dostępności zawartymi w danym dokumencie medycznym, dziennik zdarzeń, tj. wszystkie operacje dotyczące dokumentu są zapisywane w systemie w sposób umożliwiający określenie kolejności działań i wykonawców czynności, przypisanie unikatowego identyfikatora dla każdego dokumentu, możliwość trwałego archiwizowania dokumentów bez opcji usunięcia lub modyfikacji, zabezpieczenie komunikacji z usługą dostępową przez SSL, dokumenty winny być przechowywane w relacyjnej bazie danych zapewniającej szyfrowanie danych przeźroczyste dla aplikacji, przechowywanie w systemie zgód na przetwarzanie danych osobowych i zgód na dostęp do dokumentacji medycznej, tworzenie teczek dokumentów, podpisywanie teczek dokumentów jako całości, numerowanie dokumentów w teczce, monitorowanie zmian dokumentów w teczce, obsługa kwalifikowanych podpisów elektronicznych przynajmniej dwóch różnych dostawców, oraz własne, niezależne centrum certyfikacyjne do podpisów niekwalifikowanych, przyjmowanie dokumentów podpisanych w systemach HIS. Powyższa lista zawiera wymagania zalecane. EDM oferowany będzie wszystkim podmiotom leczniczym. Na bazie przeprowadzonej analizy rekomendujemy przyjąć dla systemów klasy EDM następujące rozwiązania architektoniczne: 18 w zależności od specyfiki poszczególnych PL disi@pomorskie.eu, Strona 131 z 212

132 chmurę prywatną i model usługowy SaaS, dla podmiotów leczniczych klasy E, rozwiązania lokalne, dla podmiotów leczniczych klasy A, B, C i D. 6.9 Koncepcja rozwiązania portalowego Ogólna koncepcja Portal Pomorskie e-zdrowie będzie stanowił warstwę integracyjno-informacyjną pomiędzy systemami informatycznymi podmiotów leczniczych, a kluczowymi interesariuszami projektu PeZ. Działając zarówno na poziomie lokalnym, jak i regionalnym będzie służył w trzech podstawowych obszarach: wsparcia pacjenta, wymiany informacji wewnętrznej, informacji zarządczej. W części przeznaczonej dla pacjentów, spersonalizowany portal będzie umożliwiał przede wszystkim zdalną rejestrację. Będzie też umożliwiał, bez autoryzacji, dostęp do informacji o usługach świadczonych przez poszczególne podmioty oraz dostępności specjalistów. Informacja wewnętrzna przeznaczona jest głównie dla personelu medycznego w celu dostępu do repozytoriów dokumentacji medycznej i systemów HIS oraz dla administracji podmiotów leczniczych do systemów ERP i analitycznych. Portal udostępniając bieżącą informację o dostępności usług medycznych oraz specjalistów pozwoli na sprawniejsze zarządzanie placówkami i efektywniejsze wykorzystanie posiadanych zasobów. Obszar informacji zarządczej ma na celu otrzymanie wglądu do raportów i prezentacji na temat działań podmiotów leczniczych oraz obsługę i nadzór nad systemami obsługi jakości i zdarzeń niepożądanych. disi@pomorskie.eu, Strona 132 z 212

133 6.9.2 Obszary funkcjonalne portalu Projektując portal od strony użytkowej należy zdefiniować moduły funkcjonalne, które będą miały swoje specyficzne funkcjonalności. Opis wymaganych funkcjonalności dla poszczególnych modułów przedstawia się następująco: e-usługi dla pacjenta: o Po zalogowaniu się do systemu pacjent ma dostęp e-usług dostępnych dla Pacjenta. o System jest zintegrowany z regionalnym repozytorium dokumentacji medycznej w zakresie udostępniania dokumentacji medycznej danego pacjenta zalogowanemu pacjentowi lub lekarzowi, o ile w Regionalnym Systemie Rejestrów znajduje się zapis o dostępie lekarza do dokumentacji medycznej danego pacjenta. o System umożliwia dodawanie notatek (komentarzy) do własnych dokumentów medycznych. Komentarze wystawione przez pacjentów domyślnie mają tryb widoczności ustawiony na prywatny i nie są widoczne dla pozostałych użytkowników systemu. Autor komentarza może zmienić tryb widoczności, co skutkuje możliwością podglądu komentarza przez lekarzy uprawnionych do podglądu zadanego dokumentu medycznego. o Możliwość wprowadzania przez pacjenta danych medycznych dotyczących parametrów życiowych takich jak ciśnienie, waga, temperatura, wzrost. disi@pomorskie.eu, Strona 133 z 212

134 o System oferuje pacjentowi podstronę z listą lekarzy, którzy oglądali jego dokumentację medyczną, wraz z datą ostatniego wglądu. Każdy wpis na liście zawiera dodatkowo przycisk umożliwiający zablokowanie dostępu do dokumentacji dla tego lekarza. o Pacjent ma możliwość przeszukiwania listy lekarzy i lekarzy specjalistów, na podstawie imienia, nazwiska, bądź NPWZ (numer prawa wykonywania zawodu). Każdej znalezionej w ten sposób osobie może nadać uprawnienie wglądu w jego dokumentację. Pacjent może określić, nadając uprawnienie, czy jest to uprawnienie bezterminowe, czy obowiązuje w zadanym okresie czasu. o System daje API do podłączenia zewnętrznych systemów pozwalających na przechowywanie dokumentacji medycznej pacjenta o Pacjent jest powiadamiany o nadchodzących zdarzeniach medycznych (wizyty, badania etc), o Umożliwienie monitorowania statusu na liście oczekujących na udzielenie świadczenia. e-usługi dla lekarza: o Lekarz po zalogowaniu się ma dostęp do dokumentacji medycznej (przechowywanej w Regionalnym Repozytorium Dokumentacji Medycznej) pacjentów leczonych w PL, w którym pracuje. Niemniej jednak lekarz nie ma dostępu do pełnej listy pacjentów, do których dokumentacji medycznej ma dostęp. o Dostęp do dokumentacji medycznej konkretnego pacjenta możliwy jest po wpisaniu numeru PESEL, lub imienia, nazwiska i daty urodzenia pacjenta - wówczas wyświetlany jest pełny profil pacjenta zawierający dane krytyczne i dokumentację medyczną. Weryfikacja czy lekarz ma dostęp do dokumentacji medycznej pacjenta odbywa się w czasie rzeczywistym - na podstawie bazy danych zawierającej informacje na temat pacjentów i lekarzy jacy mają dostęp do dokumentacji medycznej danego pacjenta. o Lekarz ma możliwość dodawania notatek do konkretnych dokumentów medycznych z zaznaczeniem czy notatka ma być prywatna (widziana tylko przez wprowadzającego) czy publiczna (widziana przez pozostałych lekarzy) oraz czy jest widoczna dla pacjenta. o Lekarz ma możliwość przesłania wiadomości tekstowej na skrzynkę kontaktową pacjenta, którego dokumentację medyczną przegląda. o Lekarz ma dostęp do danych krytycznych- ratowniczych pacjenta bez zgody pacjenta. o W przypadkach krytycznych (np. nieprzytomny pacjent) lekarz może uruchomić tryb krytyczny i mieć dostęp do wszelkiej dokumentacji medycznej bez ograniczeń. Wówczas wszyscy pacjenci, których dokumentacja medyczna była obserwowana w disi@pomorskie.eu, Strona 134 z 212

135 trybie krytycznym dostają monit na skrzynkę kontaktową z danymi lekarza i datą dostępu do dokumentacji. o Lekarz ma możliwość wysłania na skrzynkę kontaktową innego lekarza wiadomości tekstowej (oznaczonej jako Zlecenie ), która zawiera opis zlecenia oraz identyfikator pacjenta, którego dotyczy. W przypadku braku uprawnień lekarza - zleceniobiorcy do dokumentacji wskazanego pacjenta, system automatycznie wysyła na skrzynkę kontaktową pacjenta wiadomość z prośbą o nadanie lekarzowi zleceniobiorcy odpowiednich uprawnień. System umożliwia pacjentowi nadanie uprawnień wskazanemu lekarzowi. o Lekarz zleceniobiorca, będący uprawnionym do dostępu do dokumentacji medycznej pacjenta może, korzystając z systemu, przeglądnąć dokumenty zgromadzone w RRDM i opisać wyniki konsultacji w wiadomości tekstowej, która w ramach odpowiedzi trafi do skrzynki kontaktowej lekarza-zleceniodawcy. o Lekarz ma dostęp do danych krytycznych każdego pacjenta. o Lekarz ma możliwość zlecenia dodatkowego lub konsultacji profesorskich w obrębie danego leczenia lub przekierowania zdjęć do platformy e-usług w celu opisu lub potwierdzenia opisu. Moduł dokumentacja medyczna: o Dokumentacja medyczna widoczna jest w kontekście PL w której pracuje lekarz. Lekarz w zależności od jednostki w której obecnie przebywa, może mieć dostęp do różnych dokumentów (pacjentów). o Dokumentacja medyczna prezentowana jest w formie rekordu pacjenta Regionalnego Repozytorium Dokumentacji Medycznej, lub w formie listy chronologicznej Dane rekordu pacjenta przechowywane są w otwartym modelu danych (HL7). Możliwe jest przechodzenie pomiędzy listą dokumentów, a Rekordem Pacjenta. o System obsługuje poziomy dostępności do wprowadzanej dokumentacji medycznej: krąg lekarzy psychiatrów i psychoterapeutów może oglądać wszystkie dokumenty, lekarze ze specjalizacją widzą jedynie dokumenty na poziomie normal i restricted, pozostali lekarze mogą przeglądać jedynie dokumenty na poziomie normal. o System wyświetla udostępnione dokumenty medyczne wraz z załączonymi notatkami (komentarzami) o ile takie istnieją i oglądający ma do nich dostęp. o System zapamiętuje całą historię logowań i dostępu do dokumentacji medycznej. disi@pomorskie.eu, Strona 135 z 212

136 o System umożliwia kontekstową nawigację pomiędzy rekordem pacjenta, a dokumentami z których pochodzą wpisy. o Administratorzy Regionalnego Repozytorium Dokumentacji Medycznej nie mają dostępu do dokumentacji medycznej. o System zapewnia całkowite szyfrowanie wszelkich wysyłanych danych. o System umożliwia pełnotekstowe przeszukiwanie dokumentacji medycznej, filtrowanie po typie dokumentów, autorze, jednostce, dacie. System umożliwia konfigurację: warunków, dotyczących parametrów życiowych (ciśnienia, wagi, temperatury oraz wzrostu), które są uznawane za negatywne, opisów z ostrzeżeniami dla pacjenta, linków do stron opisujących możliwe działania naprawcze. o Możliwość przechowywania dokumentów w standardzie HL7 CDA Release 2 na dowolnym poziomie (Lv 1-3). o Możliwość przechowywania dowolnych typów plików osadzonych w dokumencie HL7 o Wydruk dokumentacji medycznej. o Przechowywanie indeksów do danych obrazowych z systemów PACS przechowywanych w tych systemach, o ile systemy te oferują taką funkcjonalność. o Mechanizm opisywania dokumentów za pomocą metadanych. o Możliwość definiowania zestawów metadanych dla poszczególnych typów dokumentów. o Możliwość trwałego archiwizowania dokumentów bez opcji usunięcia lub modyfikacji. o Zabezpieczenie komunikacji z usługą dostępową przez SSL. o System przechowuje dokumenty zgody na przetwarzanie danych osobowych, zgody na dostęp do dokumentacji medycznej. o Tworzenie Rekordu pacjenta będącego wyciągiem z dokumentów medycznych, zawierających najważniejsze dane o pacjencie. Dane rekordu pacjenta przechowywane są w otwartym modelu danych (HL7) Moduł e-rejestracja o System webowy działający jako Single-Page Application (SPA), dostępny w każdym miejscu z dostępem do Internetu. Działa na popularnych przeglądarkach internetowych (aktualnych wersjach) i nie wymaga instalowania dodatkowego oprogramowania na komputerze użytkownika. Interfejs użytkownika w języku polskim. o System webowy wykorzystujący Responsive Web Design (RWD), funkcjonalny na urządzeniach o różnych rozdzielczościach ekranu. disi@pomorskie.eu, Strona 136 z 212

137 o o o o o o o o o o o o o o o o o System uniemożliwia osobom niepowołanym dostęp do konta pacjenta, poprzez zabezpieczenie odpowiednim hasłem i loginem. System umożliwia sprawdzenie czasu oczekiwania (kolejki) na usługę, z podziałem na: procedurę medyczną, komórkę organizacyjną oraz przypadek stabilny, przypadek pilny. System umożliwia wyszukiwanie wolnego terminu w wielu jednostkach medycznych jednocześnie. System umożliwia podgląd wolnych terminów w wybranej poradni bez konieczności logowania. System umożliwia podgląd wolnych terminów do wybranego lekarza bez konieczności logowania. System umożliwia podgląd wolnych terminów wybranej usługi medycznej bez konieczności logowania. System umożliwia wyszukiwanie grafików według kryterium płatnika, np. "NFZ". System umożliwia wyszukanie wolnych terminów wizyt lekarskich według kryterium specjalizacji lekarza, bez konieczności logowania. System pozwala użytkownikowi zapoznać się z informacjami dotyczącymi lekarza w tym: specjalizacją i opisem zawodowym. System umożliwia pacjentowi wyrażenie zgody na udostępnienie lekarzowi dokumentacji medycznej. System można zintegrować ze szpitalnymi systemami informatycznymi (HIS), tak aby zmiany w grafikach systemu HIS były automatycznie widoczne w systemie, oraz informacja na temat rezerwacji terminu była przesłana z systemu erejestracji do systemu HIS (lub odwrotnie). System umożliwia użytkownikowi zdalną rezerwację terminu do wybranej poradni, dopiero po uwierzytelnieniu danych pacjenta. System umożliwia użytkownikowi zdalną rezerwację terminu do wybranego lekarza, dopiero po uwierzytelnieniu danych pacjenta. System umożliwia użytkownikowi zdalną rezerwację terminu na wybraną usługę, dopiero po uwierzytelnieniu danych pacjenta. System wyszukuje grafiki poradni według kryterium specjalizacji poradni na podstawie części ósmej kodu resortowego. System blokuje rezerwację wizyty do tej samej poradni (o tym samym kodzie resortowym) w różnych terminach. System uniemożliwia rezerwację wizyt w tym samym czasie. Rejestracja odbywa się za pomocą graficznej prezentacji kalendarza, w którym pacjent wybiera dzień i godzinę wizyty spośród dostępnych terminów. System disi@pomorskie.eu, Strona 137 z 212

138 pozwala pacjentowi na wprowadzenie kilku przedziałów czasowych, na podstawie których zawężane są wyniki wyszukiwania. o System posiada moduł konta pacjenta, w którym widoczne są informacje na temat: daty i godziny wizyty, danych osobowych lekarza (w przypadku rejestracji do lekarza), nazwa jednostki medycznej oraz dane adresowe poradni, status rezerwacji wizyty (potwierdzone, niepotwierdzone, anulowane, odrzucone). Użytkownik ma możliwość wydrukowania swojej listy rezerwacji z poziomu modułu. o System umożliwia pacjentowi odwołanie zaplanowanej wizyty po podaniu powodu rezygnacji. o System umożliwia pacjentowi zmianę terminu zaplanowanej wizyty. W takiej sytuacji system musi najpierw uzyskać potwierdzenie z systemu HIS, po którym zostanie zmieniony status rezerwacji. o System automatycznie wysyła powiadomienia o rejestracji wizyty, zmianie terminu wizyty lub jej odwołania, oraz przypomnienie o zbliżającej się wizycie poprzez lub SMS 19. o System umożliwia administratorowi określenie domyślnych zakresów godzin kalendarza widocznych dla użytkownika. o System umożliwia administratorowi określenie: czasu utrzymywania pamięci podręcznej, czasu powiadomienia przed badaniem, czasu przechowywania grafików, czasu przechowywania terminów, filtra kodów resortowych wyświetlanych w interfejsie oraz włączenie/wyłączenie wysyłania powiadomień sms 20 / . o System umożliwia zapisywanie nieudanych prób logowania użytkowników. Hosting stron www PL i BIP PL: o Każdy PL w obrębie portalu Internetowego umieszczonego w GCPD/DR będzie miał do swojej dyspozycji obszar hostingowy dla własnych informacyjnych stron www i BIP z przekierowaniem do e-usług portalu nadrzędnego. o Udostępniana przestrzeń będzie posiadała cechy typowo hostingowe jak na innych portalach tego typu, o Każdy PL będzie miał dostępna przestrzeń na swoją stronę, o Każdy PL do dyspozycji będzie miła hosting w oparciu o CMS, o Portal nie będzie przechowywał danych użytkowników. Pozostałe wspólne wymagania dla portalu: o Administrator może edytować wielkość dodawanych załączników. 19 wymaganie opcjonalne, poza standardem 20 wymaganie opcjonalne, poza standardem disi@pomorskie.eu, Strona 138 z 212

139 o o o o o o o o o o o o o Interfejs użytkownika w zakresie dostępności dla osób niepełnosprawnych zgodny z wytycznymi organizacji W3C i Krajowymi Ramami Interoperacyjności, Zarządzaniem Systemem zajmują się użytkownicy dwóch rodzajów: Administratorzy, Redaktorzy Systemu. Każdy z podmiotów może mieć w systemie swój własny obszar, którego treści będą uzupełniane przez Redaktorów systemu tego podmiotu. Administrator może dodać nowy podmiot leczniczy, co skutkuje udostępnieniem dla niego nowego obszaru, w którym zamieszczane będą treści. W nowo utworzonym obszarze możliwe jest dodanie strony ze szczegółami podmiotu, które mogą być uzupełnione przez Administratora bądź Redaktora Systemu. Możliwość nadawania / odbierania uprawnień do dokumentacji pacjenta lekarzowi w sytuacjach wyjątkowych takich jak zwolnienie lekarza lub gdy nie może tego zrobić pacjent. Przypadki takie muszą zostać każdorazowo uzasadnione w systemie. Administrator może skorzystać z wyszukiwarki lekarzy, a następnie nadać lub odebrać lekarzowi uprawnienia do dokumentacji medycznej wybranego pacjenta. Administrator, by znaleźć pacjenta, do którego dokumentacji chce zmienić uprawnienie musi podać nr PESEL pacjenta, bądź trójkę: imię, nazwisko, data urodzenia. Nadanie uprawnień w takim trybie wiąże się z koniecznością podania obligatoryjnego komentarza, uzasadniającego tę operację. Informacja wraz z komentarzem trafia do skrzynki kontaktowej pacjenta. System umożliwi Redaktorom Systemu dodawanie treści dotyczących: wydarzeń, akcji promocyjnych, artykułów publikowanych na stronach systemu. Redaktorzy systemu mają poprzez narzędzia CMS: Możliwość dodawania oraz usuwania plików multimedialnych. System umożliwia dodawanie / edycję / usunięcie zawartości systemu bez znajomości HTML/CSS/JS. Redaktorzy systemu mają poprzez narzędzia CMS: Możliwość publikowania wprowadzonych treści. System umożliwia wstawianie komentarzy przez zalogowanych użytkowników pod treściami komunikatów, artykułów i promocji publikowanych przez PL. System umożliwia administratorom moderowanie komentarzy. System zapewnia możliwość tworzenia, edycji i usuwania formularzy. Przykładem formularza jest deklaracja POZ. Automatyczna aktualizacja mapy systemu. disi@pomorskie.eu, Strona 139 z 212

140 o System udostępnia możliwość odtwarzania plików audio i video z widocznym panelem sterującym. o System udostępnia kalkulator BMI i licznik kalorii. o Administratorzy Regionalnego Repozytorium Dokumentacji Medycznej nie mają dostępu do dokumentacji medycznej. o Baza danych obszaru portalowego będzie odrębną bazą danych. o Baza danych użytkowników logujących się do portalu będzie odrębna niezależna bazą danych nie znajdującą się w obszarze baz danych systemów HIS oraz niezintegrowaną z LDAP/ usługi katalogowe. Moduł informacji zarządczej: o Każdy użytkownik ma dostęp do informacji tylko tych podmiotów leczniczych i w takim zakresie czasowym w jakim ma nadane uprawnienia. o Przed zalogowaniem uprawnionego użytkownika Portal nie prezentuje żadnych treści wykraczających poza ogólnie dostępne informacje na temat Projektu. Informacje dotyczące Projektu obejmują informacje własne podmiotów leczniczych, informacje o akcjach profilaktycznych, akcjach prozdrowotnych itp. o Po zalogowaniu użytkownik dostaje dostęp do menu, które udostępnia zdefiniowane wcześniej raporty, wskaźniki, zestawienia itp. w logicznym podziale m.in. przedmiotowym, podmiotowym, czasowym lub innym. o Użytkownicy uprzywilejowani mają dostęp do tzw. generatora, który umożliwia tworzenie raportów, zestawień, wskaźników itp. analogicznych do tych tworzonych przez Regionalny System BI. o Portal wyświetla profil zalogowanego użytkownika, który pokazuje ostatnio wygenerowane / przeczytane raporty, zestawienia itp., zakres uprawnień danego użytkownika. o Portal ma wyraźnie zaznaczone na każdej stronie przyciski umożliwiające wydrukowanie obecnie przeglądanego raportu, zestawienia, wskaźnika itp., oraz wysłanie go innym użytkownikom. o Portal umożliwia generowanie wykresów do wszystkich wygenerowanych statystyk o Portal umożliwia zapamiętanie konfiguracji wygenerowanych przez użytkownika z możliwością odwołania się do nich po ponownym zalogowaniu o Portal umożliwia eksport wygenerowanych zestawień i wykresów do arkuszy kalkulacyjnych oraz do formatu PDF. o Portal umożliwia przeliczanie statystyk dla wszystkich zmiennych i kategorii występujących w raportach i analizach o Portal umożliwia agregację dowolnych zmiennych i kategorii występujących w raportach i analizach. disi@pomorskie.eu, Strona 140 z 212

141 o o o o o o o o o o o o o o o o o o o Portal umożliwia liczenie kowariancji między dowolnymi dwoma lub więcej zmiennymi i kategoriami występującymi w raportach i analizach. Wsparcie tworzenia tzw. sub-filtrów np. użytkownik może wykorzystać rezultaty jednego raportu jako filtr drugiego raportu. Możliwość wizualizacji graficznej tzw. wyjątków tzn. wartości przekraczających wartości oczekiwane, nie mieszczące się w pewnych zakresach itp. Możliwość wykonywania kalkulacji: matematycznych, statystycznych, znakowych, konwersji itp. Wsparcie tworzenia warunków wyliczanych, wykorzystywanych do filtrowania danych. Możliwość wizualizacji danych aktualnych, historycznych oraz trendu. Możliwość sortowania danych dowolnego wymiaru w porządku rosnącym lub malejącym. Możliwość ustawienia warunków potrzebnych do filtrowania danych. Możliwość wykonywania operacji drążenia danych do danych bardziej szczegółowych (drill down). Możliwość zmiany nazw kolumn na raporcie na dowolnie wybrane przez użytkownika nagłówki i etykiety. Możliwość zmiany wizualizacji danych na raporcie: pozioma i pionowa orientacja danych, ukrywanie etykiet wierszy i reguł agregacji danych. System ukrywa niewymagane lub nieistotne na raporcie tabele i/lub kolumny np. takie na podstawie których następuje agregacja/kalkulacja. Możliwość generowania raportów statystycznych do analizy zleconych badań diagnostyki w danym okresie według oddziału, osoby zlecającej, rodzaju badania. Możliwość generowania zestawienia wykonanych konsultacji w celu analizy obciążenia lekarzy. Możliwość generowania zestawień kosztów według zadanych kryteriów np. oddziałów, rodzaju diety. Możliwość agregowania danych o rodzajach i liczbie badań np. per oddział i per pacjent. Możliwość dynamicznej modyfikacji wszystkich elementów systemu na podstawie zmian w wymiarach rachunku kosztów (np. usunięcie OPK). Możliwość automatycznego systemowego przywrócenia raportów rachunkowości zarządczej oraz raportów generowanych ze względu na wymagania prawne. Możliwość definiowania tolerancji dla poszczególnych pozycji budżetu i planu oraz możliwość zmiany standardów budżetowych. disi@pomorskie.eu, Strona 141 z 212

142 o Możliwość dodawania nowych parametrów do standaryzowania (np. nowe procedury, nowe zasoby, czas opieki medycznej i pielęgniarskiej). o Możliwość dowolnego skonfigurowania parametrów dla odchyleń oraz ich prezentacji w raportach. o Możliwość dowolnej obróbki danych raportowych przy wykorzystaniu takich funkcji matematycznych jak np.: sumy, sumy częściowe, różnice, odchylenia, iloczyny czy ilorazy, trendy, średnie, mediany. o Możliwość generowania całościowego raportu na temat ruchu chorych. o Możliwość generowania raportów kosztowych konsultacji realizowanych per oddział. o Możliwość generowania raportów o kosztach / zużyciu leków i materiałów. o Możliwość generowania raportów przedstawiających kosztochłonność poszczególnych grup pacjentów oraz poszczególnych procedur. o Możliwość generowanie raportów kosztowych zrealizowanych usług. o Możliwość graficznego i procentowego przedstawiania danych odnośnie stanu wykorzystania limitów z NFZ. o Możliwość kalkulacji kosztów oddziałów, procedur medycznych oraz pacjenta. o Możliwość automatycznego wyliczenia kosztów zużycia głównych materiałów medycznych dla danego pacjenta na podstawie indeksów podanych materiałów oraz zużytych ilości (np. w przeliczeniu na pełne opakowania). o Możliwość tworzenia raportów opisujących stopień wykorzystania limitów programów lekowych. o Możliwość tworzenia raportu segregującego pacjentów wg różnych atrybutów. o Możliwość wizualizacji mierników operacyjnych oraz trendów (np. koszty poszczególnych grup pacjentów). o Możliwość wizualizacji raportów wykonania planów i budżetów w różnych horyzontach czasowych i w układzie dynamicznym. o Możliwość wpisania do systemu informacji o standardowych kosztach procedur medycznych i wartościach standardowych nośników dla poszczególnych procedur. o Możliwość wyznaczenia rentowności poszczególnych podmiotów leczniczych w oparciu o podział kosztów. o Możliwość wyznaczenia rentowności poszczególnych procedur w oparciu o podział kosztów. o Możliwość zachowywania i publikacji raportów ad-hoc, tak aby była możliwość ich automatycznego generowania w przyszłości. o Możliwość zestawienia kosztów leczenia pacjenta z wycenioną procedurą. o Możliwość generowania miesięcznych raportów dotyczących zleconych w danym miesiącu usług np. rehabilitacyjnych. disi@pomorskie.eu, Strona 142 z 212

143 Obszar intranetu: o Zapewnienie pełnej skalowalności w zakresie wyświetlanej szczegółowości wartościowych danych finansowych w złotych (możliwość wyboru np. tysięcy, milionów, ilości miejsc po przecinku). o Możliwość symulacji cen za usługi (np. zgodnie ze stawką NFZ) oraz kosztu normatywnego wykonania procedur medycznych wykonywanych w ośrodkach podstawowych i pomocniczych (np. EKG). o Możliwość automatycznej symulacji standardowych kosztów procedur medycznych w przypadku zmian cen materiałów, stawek amortyzacji, wynagrodzeń pracowników. o Raportowanie kosztów normatywnych dla poszczególnych procedur. o Możliwość wyliczania wskaźników finansowych tj. rentowności, płynności, analiza wartości średnich, korelacji i zależności. o Możliwość tworzenia raportów i zestawień porównawczych, sprawozdań finansowych (rachunek zysków i strat, bilans) miesiąc do miesiąca, narastająco, rok do roku, za poszczególne miesiące. część portalu dostępna dla pracowników po zalogowaniu, dostęp do informacji wewnętrznych na poziomie SWP, dostęp do informacji wewnętrznych na poziomie podmiotu leczniczego (np. książka telefoniczna wewnętrzna). Obszar aplikacji: część portalu dostępna dla pracowników po zalogowaniu, dostęp do aplikacji zintegrowanych z portalem w warstwie prezentacji, podstawowa aplikacja elektroniczny obieg dokumentów, inne aplikacje np.: o formularze, o zamówienia publiczne, o BIP, o repozytoria danych. Obszar informacyjny: strona początkowa portalu informacyjnego zawierająca odnośniki do innych składowych portalu, podstawowe informacje o podmiotach leczniczych uporządkowanych zgodnie z standardem opracowanym na potrzeby SWP, disi@pomorskie.eu, Strona 143 z 212

144 lista adresowa i telefoniczna poszczególnych podmiotów leczniczych, dane teleadresowe podmiotów leczniczych o zasięgu centralnym i instytucji centralnych, istotne informacje o świadczonych usługach (oraz sposobie przygotowywania się do nich) oraz przekierowanie na e-rejestrację, informacje o oddziałach, poradniach i innych jednostkach podmiotów leczniczych i ich godzinach przyjęć, zagregowane informacje o świadczonych usługach medycznych na terenie województwa, wraz z informacjami o ich dostępności w poszczególnych podmiotach leczniczych (umożliwiające sprawne znalezienie informacji o miejscu na terenie województwa, gdzie istnieje możliwość wykonania danej usługi) publikowanie artykułów i treści medycznych i paramedycznych, publikowanie komentarzy i informacji bieżących z zakresu medycznego (np. o ryzyku zarażenia wirusem Ebola), obszar informacji profilaktycznych, wraz z informacjami o akcjach promocji zdrowia i zdrowego trybu życia, oferowanych badaniach profilaktycznych, informacje z zakresu Prawa Pacjenta, informacje o dyżurach (kalendarze świadczenia usług) oraz czasie oczekiwania na usługi, odnośniki do pomocy dla Pacjenta (porady dla pacjenta w różnych sytuacjach), łącza do serwisów społecznościowych. Obszar usług dla pacjenta (nieuwzględniające dokładnej listy e-usług): dostęp do katalogu usług świadczonych przez PL, innych informacji na ich temat, możliwość rejestracji na usługi medyczne w wybranych podmiotach leczniczych oraz rezygnacji lub przełożenia wcześniej umówionej wizyty, dostęp do danych medycznych (z systemu elektronicznej dokumentacji medycznej), powiadamianie o akcjach profilaktycznych i prozdrowotnych, dostęp do danych na temat potrzeby odbycia niezbędnych badań, możliwość edycji podstawowych danych (np. kontaktowych), dostęp do informacji na temat czasu oczekiwania na daną usługę medyczną, dostęp do informacji na temat lekarzy i ich dostępności. Obszar nadzoru zarządczego: dostęp możliwy po zalogowaniu pracowników do części niejawnej, zwiększenie jakości nadzoru właścicielskiego poprzez wdrożenie narzędzi analitycznobenchmarkingowych na poziomie regionalnym, disi@pomorskie.eu, Strona 144 z 212

145 ułatwienie zarządzania PL poprzez uzupełnienie i rozbudowę wdrożonych w PL systemów klasy ERP oraz integrację z narzędziami analityczno-raportowymi oraz wdrożenie systemów obiegu dokumentów, obsługa systemu zapobiegania nadużyciom, obsługa systemu oceny jakości, dostęp do raportów opisujących działalność podmiotu leczniczego i narzędzi analitycznych Wymagania dotyczące bezpieczeństwa i zarządzania użytkownikami Portal powinien posiadać mechanizm zabezpieczający przed niepowołanym dostępem. W tym celu wykorzystywana będzie uwierzytelnianie użytkowników, a także zabezpieczenie systemu jako całości oraz gromadzonych w nim danych oraz automatycznie wykonywanie kopii bezpieczeństwa danych systemowych, oprogramowania, baz danych i dokumentów. W poniższej tabeli znajdują się proponowane kategorie użytkowników (rozumianych jako osoby zarejestrowane), wraz ze skróconymi uprawnieniami im przydzielonymi, dostępnymi po poprawnym uwierzytelnieniu (rzeczywisty zakres uprawnień jest szerszy i pozostaje w zgodzie z funkcjonalnościami wymienionymi w podrozdziale). Kategoria użytkownika Pacjent Lekarz Personel medyczny Pracownik administracyjny w PL Pracownik administracyjny w SWP Redaktor Skrócony opis i uprawnienia dostępu Po uwierzytelnieniu się, pacjent uzyskuje dostęp do swojej dokumentacji medycznej, podglądu swoich danych, możliwość rejestracji wizyt oraz wgląd w dyżury Lekarzy. Po zalogowaniu lekarz uzyskuje dostęp do dokumentacji medycznej pacjenta, zarówno z własnego podmiotu leczniczego, jak i z innych podmiotów poprzez regionalną bazę danych. Lekarz może także modyfikować te dane, jak i wprowadzać nowe. Pozostały personel medyczny podmiotu leczniczego, po zalogowaniu, uzyskuje dostęp do danych medycznych pacjenta w zakresie podglądu, edycji i wprowadzania, zależnie od przydzielonych uprawnień. Pracownicy, po zalogowaniu, mają dostęp do rejestracji pacjentów oraz zyskują dostęp do lokalnych systemów EOD, ERP i BI. Pracownicy organu tworzącego, po zalogowaniu, mają dostęp do czytania i tworzenia raportów z modułu informacji zarządczej. Pracownicy posiadający uprawnienia redaktorskie, po uwierzytelnieniu, disi@pomorskie.eu, Strona 145 z 212

146 posiadają uprawnienia do systemu CMS, umożliwiające tworzenie, publikowanie oraz edycję artykułów do portalu oraz zarządzanie danymi o danym podmiocie leczniczym. Administrator Administratorzy (lokalni i regionalni) dysponujący odpowiednimi uprawnieniami, po uprzednim zalogowaniu, mogą zarządzać kontami użytkowników (także grupami), ich uprawnieniami, dostępem. Zajmują się także monitorowaniem użytkowania portalu, jego konfiguracją i zarządzaniem (w tym bezpieczeństwem, wydajnością, kopiami zapasowymi). Tabela 12: Kategorie użytkowników Portalu wraz z ich skróconymi uprawnieniami Uprawnienia dostępu do poszczególnych elementów portalu mogą być przydzielane i odwoływane dla pojedynczych użytkowników, a nie jedynie dla grup użytkowników, co znacznie zwiększa elastyczność w nadawaniu uprawnień (umożliwia to np. udostępnienie części pracowników administracyjnych PL dostępu wyłącznie do rejestracji pacjentów, bez dostępu do innych lokalnych systemów części szarej). Portal powinien umożliwiać śledzenie konfliktów nadanych kategorii użytkownika, tak, aby informować osoby zainteresowane o jednoczesnym nadaniu sprzecznych (w kontekście separacji uprawnień) kategorii np. jednocześnie kategoria Administratora i Redaktora. Nadanie określonej kategorii użytkownika powinno odbywać się poprzez wypełnienie specjalnie przygotowanego wniosku, w ten sposób uruchamiając proces akceptacyjny, a co za tym idzie pełny proces raportowoaudytowy Propozycja elementów składowych portalu Mapa portalu Przykładowa mapa portalu może wyglądać w następujący sposób: Strona główna o Usługi medyczne Jak umówić się na wizytę Zdrowie psychiczne Pediatria e-usługi o PL (podstrony dla każdego podmiotu leczniczego) PL01 disi@pomorskie.eu, Strona 146 z 212

147 o o o o o o o o o PL02.. PL19.2 Informacje i zasoby zdrowotne Informacje tematycznie Alkohol i narkotyki Antykoncepcja Problemy żywieniowe Zdrowie emocjonalne Choroby zakaźne Ciąża Choroby przenoszone drogą płciową Informacje dla podróżnych Znajdź formularz Prawa pacjenta Aktualności ezdrowie Definicja ezdrowia i telemedycyny Wytyczne Europejskie Słownik ezdrowia Strategia ezdrowia Polski ezdrowie Centralne ezdrowie Regionalne Strategia ezdrowia Województwa Pomorskiego Standardy ezdrowia Rynek ezdrowia w Polsce Konferencje Projekty naukowo-badawcze FAQ Do pobrania Multimedia O nas Kim jesteśmy Powitanie Nasza misja disi@pomorskie.eu, Strona 147 z 212

148 o Wizja Nasze lokalizacje Informacje o prywatności i bezpieczeństwie Kontakt Wykaz elementów stałych (statycznych) portalu Strony statyczne mogą być wyświetlane w portalu na dwa sposoby: jako autonomiczne strony WWW, które mają kontrolę nad pełnym obszarem przeglądarki lub jako część obszaru strony portalu (w tym przypadku portal nadal kontroluje obszar banera i obszar nawigacyjny). Strony statyczne są tworzone i administrowane podobnie jak inne strony portalu. Występują jednak pewne różnice w niektórych krokach i opcjach. Szczegółowe informacje zawiera pomoc dotycząca interfejsu użytkownika i portletów dla portletu Zarządzanie stronami i jego portletów podrzędnych. Aby zaktualizować stronę statyczną, należy wprowadzić wymagane zmiany w pliku HTML, a następnie wymienić stronę portalu na zaktualizowaną stronę za pomocą narzędzi do administrowania portalem. Za pomocą narzędzia do dostosowywania stron portalu można aktualizować układ strony statycznej. W przypadku stron statycznych portalu, konieczne jest branie pod uwagę elementów, które będą wyświetlane w dla danych obszarów językowych. Obsługa języków narodowych jest udostępniana poprzez utworzenie pakunku plików języka znaczników obsługujących języki narodowe w postaci pliku ZIP, który zawiera także plik HTML definiujący treść statyczną. W trakcie wyświetlania algorytmy globalizacji portalu decydują na podstawie żądania, ustawień i dostępnych języków narodowych, która wersja narodowa ma być wyświetlana. Podczas tworzenia mapy portalu, konieczne jest określenie mapy portalu dla obsługiwanych języków oraz określenia, które elementy są tłumaczone i zawierane w wersjach wielojęzykowych. W odniesieniu do mapy portalu, w poniższej tabeli zawarta jest propozycja elementów portalu w podziale na elementy stałe oraz elementy dynamiczne (będzie ona uszczegółowiana na etapie tworzenia opisu przedmiotu zamówienia). Element portalu Strona główna Charakterystyka elementu dynamiczna disi@pomorskie.eu, Strona 148 z 212

149 Element portalu Usługi medyczne Jak umówić się na wizytę Zdrowie psychiczne Pediatria Charakterystyka elementu statyczna statyczna statyczna statyczna - PL (podstrony dla każdego podmiotu leczniczego) PL01 PL02 dynamiczna dynamiczna dynamiczna.. - PL19.2 Informacje i zasoby zdrowotne Informacje tematycznie Alkohol i narkotyki Antykoncepcja Problemy żywieniowe Zdrowie emocjonalne Choroby zakaźne Ciąża Choroby przenoszone drogą płciową dynamiczna statyczna statyczna statyczna statyczna statyczna statyczna statyczna statyczna statyczna - Informacje dla podróżnych Znajdź formularz Prawa pacjenta statyczna statyczna statyczna disi@pomorskie.eu, Strona 149 z 212

150 Element portalu Aktualności ezdrowie Definicja ezdrowia i telemedycyny Wytyczne Europejskie Słownik ezdrowia Strategia ezdrowia Polski ezdrowie Centralne ezdrowie Regionalne Strategia ezdrowia Województwa Pomorskiego Standardy ezdrowia Rynek ezdrowia w Polsce Konferencje Projekty naukowo-badawcze FAQ Do pobrania Multimedia O nas Kim jesteśmy Powitanie Nasza misja Wizja Nasze lokalizacje Informacje o prywatności i bezpieczeństwie Charakterystyka elementu dynamiczna statyczna statyczna statyczna statyczna statyczna dynamiczna dynamiczna statyczna statyczna statyczna dynamiczna statyczna statyczna statyczna dynamiczna statyczna statyczna statyczna statyczna statyczna statyczna statyczna disi@pomorskie.eu, Strona 150 z 212

151 Element portalu Kontakt Charakterystyka elementu statyczna Tabela 13: Charakterystyka elementów portalu 6.11 Architektura systemu Architekturę rozwiązania portalowego proponujemy oprzeć na standardowych komponentach przeznaczonych do budowy portali korporacyjnych. Wybór narzędzi informatycznych do realizacji poszczególnych elementów Portalu zależy od wyboru technologii przez wykonawcę portalu. Na tym etapie projektu nie jest wskazane wskazywanie konkretnych narzędzi i oprogramowania (rynek ten podlega bardzo szybkim zmianom). Większość portali korporacyjnych oparta jest właśnie o taki model funkcjonowania. Model ten gwarantuje Zamawiającemu pełną kontrolę nad udostępnianymi funkcjonalnościami, pozwala na dowolną skalowalność rozwiązania i elastyczne dostosowanie portalu do zmieniających się potrzeb biznesowych. Portal będzie udostępniał usługę rejestracji, zatem będzie zintegrowany w czasie rzeczywistym z każdym HISem podmiotów leczniczych, tak aby pacjenci mogli zapisywać się na wizyty do wybranych podmiotów leczniczych oraz weryfikować stan swojej kolejki. Możliwość dostępu do własnej dokumentacji medycznej przez pacjentów wymaga także połączenia w czasie rzeczywistym z Pomorskim Repozytorium Informacji Medycznej (PRIM). Komunikacja ta powinna odbywać się poprzez warstwę regionalnej szyny danych. W obszarze informacji zarządczej portal umożliwia dostęp dla pracowników administracyjnych z organu tworzącego PL (SWP) do danych analitycznych i możliwości przygotowywania raportów. By umożliwić tę funkcjonalność konieczna jest komunikacja z systemem BI w warstwie regionalnej realizowana w określonych odstępach czasu, jak np. raz na dzień, oferując w ten sposób możliwość codziennej aktualizacji raportów analitycznych. Rozwiązanie portalowe powinno wykorzystywać sprzęt zakupiony w ramach projektu PeZ dla GCPD i takie wymagania techniczne powinny znaleźć się na dalszych etapach projektu do spełnienia przez dostawców rozwiązania regionalnego portalowego informacyjnego. Rekomendowana docelowa architektura infrastruktury serwerowej i przestrzeni dyskowej w GCPD znajduje się w podrozdziale dotyczącym GCPD. disi@pomorskie.eu, Strona 151 z 212

152 Portal powinien mieć architekturę całkowicie odrębna od pozostałych części systemów PeZ, powinien być odseparowany działając w DMZ i powinien być zabezpieczony odrębnym sprzętowym firewallem/utmem, połączonym z centralnym systemem bezpieczeństwa. Kalendarze Lekarzy, udostępniane dla Pacjentów, powinny być zintegrowane z kalendarzami udostępnianymi z serwerów pocztowych np. Exchange, lekarzy w każdym z PL Technologia regionalnego portalu informacyjnego Kluczowymi technologiami wykorzystywanymi przy realizacji portali internetowych są: Linux, HTTP, XML/XHTML, Phyton/PHP Perl JavaScript, PLSQL, Postgres SQL Ze względu na bezpieczeństwo i kłopoty administracyjne należy unikać języka Java w portalu zewnętrznym za wyjątkiem aplikacji na Androida. Te też technologie w pierwszej kolejności proponujemy wybrać do budowy portalu e-zdrowie. Portal będzie wykorzystywał mechanizm CMS, który umożliwi edytowanie treści na nim dostępnych także osobom nie posiadającym wiedzy informatycznej. Ponadto portale wykorzystujące CMS są łatwiejsze do wykorzystywania i administrowania, są bezpieczniejsze od statycznych, posiadają wbudowane możliwości wyszukiwania i filtrowania oraz mają dobrą indeksowalność w wyszukiwarkach internetowych. System CMS, wykorzystany w ramach regionalnego portalu, składać się powinien minimum z następujących modułów: moduł zarządzania treścią, wraz z edytorem treści, moduł prezentacji treści, wraz z silnikiem motywów, zestaw widgetów, moduł cache ujący, moduł uprawnień. disi@pomorskie.eu, Strona 152 z 212

153 Dostępny będzie także moduł monitorowania statystyk portalu (zawierających liczbę otwarcia strony, liczbę odwiedzających, przeciętny czas spędzony na stronie itd.) oraz informacje o sposobie wykorzystania portalu przez poszczególnych użytkowników. disi@pomorskie.eu, Strona 153 z 212

154 7 Rozwiązania regionalne z zakresu e-zdrowia Klauzula generalna: W zależności od uzasadnionych i uzgodnionych potrzeb uczestników Projektu PeZ wymagania Koncepcji Techniczno-Technologicznej mogą w przyszłości ulec zmianie/modyfikacji/doprecyzowaniu w specyfikacji opisu przedmiotu zamówienia dla poszczególnej kategorii zamówienia. W celu realizacji założeń projektu, w ramach PeZ zostanie zbudowany zintegrowany system informatyczny oddziałujący na wszystkie podstawowe elementy opieki zdrowotnej tj. na proces zarządzania podmiotami leczniczymi, proces leczenia w tych podmiotach oraz proces obsługi pacjenta. W ramach poszczególnych procesów dostarczone zostanie wsparcie informatyczne dla personelu medycznego oraz pacjentów w zakresie dostępu do danych medycznych. Zostanie do zrealizowane poprzez implementację systemu Pomorskiego Repozytorium Informacji Medycznej (PRIM). Podstawowym zadaniem PRIM będzie przechowywanie i dostęp do dokumentacji medycznej. 7.1 Warstwa biznesowa Celem wdrożenia PRIM jest dostarczenie funkcjonalności związanej z umożliwieniem pacjentom oraz uprawnionym lekarzom wglądu danych medycznych. Dostęp będzie możliwy jedynie w przypadku, kiedy pacjent wyrazi na to zgodę. Kluczowe cechy systemu PRIM będą zatem następujące: przyjmowanie dokumentacji medycznej w postaci elektronicznej, przechowywanie w wymaganych okresach retencji danych, udostępnianie dokumentacji medycznej: innym podmiotom medycznym, P1 i P2 (indeksowanie bazy i przekazywanie informacji o danych) 21. Dodatkowo PRIM przechowywać będzie również dane słownikowe i rejestry, w celu przechowywania danych o lekarzach i pacjentach i wymiany z pozostałymi kluczowymi interesariuszami projektu. Na rysunku poniżej zobrazowano i opisano te interakcje. Tabela poniżej rysunku doprecyzowuje ich opis. 21 zgodnie z zaleceniami, wymaganiami, wytycznymi opracowanymi przy wszystkich projektach realizowanych przez Centrum Systemów Informacyjnych Ochrony Zdrowia (CSIOZ) np.: disi@pomorskie.eu, Strona 154 z 212

155 Rysunek 7-1: Główni interesariusze i kluczowe interakcje w obszarze PRIM disi@pomorskie.eu, Strona 155 z 212

156 Interesariusze Pacjenci PL MSWiA/NFZ Interakcje Interakcja systemu z pacjentami odbywa się po ich uprzedniej autoryzacji w sposób umożliwiający jednoznaczną i niezaprzeczalną identyfikację obywatela. Pacjenci otrzymają dostęp do: swojej dokumentacji medycznej zawierającej odbyte wizyty, wystawione recepty, opisy badań itp.; zamawiania kopii i odpisów dokumentacji medycznej, danych krytycznych obejmujących podstawowe dane medyczne takie jak grupa krwi, waga, uczulenia i inne; danych na temat potrzeby odbycia niezbędnych badań, w tym profilaktycznych; edycji swoich podstawowych danych, w tym danych kontaktowych; PL otrzymają możliwość: wytwarzania, przetwarzania i wymiany dokumentacji medycznej pomiędzy podmiotami; wsparcia procesów związanych z realizacją procesów leczenia; W koncepcji założono, że w ramach projektu PeZ zostanie zaimplementowane i wykorzystywane własne rozwiązanie, które będzie służyć będzie do uwierzytelniania użytkowników oraz potencjalnie zewnętrzne systemy do weryfikacji danych osobowych takie jak profil zaufany (epuap). Jednym z wariantów jest wykorzystanie certyfikatów, które będą wydawane przez wdrożone w tym celu Centrum Certyfikacji zlokalizowane w warstwie regionalnej. Ostateczna decyzja odnośnie wyboru wariantu sposobu uwierzytelniania zostanie podjęta na podstawie analizy przeprowadzonej przez wykonawcę wdrożenia projektu PeZ. Możliwe do realizacji są co najmniej mechanizmy: uwierzytelnianie użytkowników będzie bazować na bezpiecznym loginie i haśle, uwierzytelnienie z wykorzystaniem certyfikatów wydawanych przez wdrożone w tym celu dedykowane Centrum Certyfikacji, uwierzytelnienie obywateli z wykorzystaniem profilu zaufanego epuap, bądź Internetowego Konta Pacjenta. System wdrażany w ramach PeZ będzie współpracował z ewuś. disi@pomorskie.eu, Strona 156 z 212

157 Interesariusze RRPL / CSiOZ Interakcje Jednym z elementów PRIM będzie utworzony w ramach projektu PeZ regionalny rejestr podmiotów leczniczych (RRPL), będący częścią regionalnego rejestru dokumentacji medycznej (RDM), służący do weryfikacji struktury organizacyjnej świadczeniodawców. Po pozytywnym wdrożeniu planowanych centralnych rejestrów na poziomie krajowym wykorzystywane będą usługi dostarczane przez CSiOZ. Do tego czasu wykorzystywany będzie RDM. NIL / CSiOZ Jednym z elementów PRIM będzie utworzony w ramach projektu PeZ regionalny rejestr lekarzy (RRL), będący częścią regionalnego rejestru dokumentacji medycznej (RDM), służący do weryfikacji danych o lekarzach Po pozytywnym wdrożeniu planowanych centralnych rejestrów na poziomie krajowym wykorzystywane będą usługi dostarczane przez CSiOZ lub NIL. Do tego czasu wykorzystywany będzie RRL. P1, P2 / CSIOZ Wykorzystanie rejestrów opublikowanych/integrowanych w P1 i P2 np. słownik TERYT, ATC, MEDDRA, Standard Terms, Słowniki ICD-9, ICD-10 i System kodów resortowych, Centralny Wykaz Ubezpieczonych, Ewidencja Zasłużonych Honorowych Dawców Krwi, Ewidencja Zasłużonych Dawców Przeszczepu, Centralny Rejestr Sprzeciwów na Pobranie Komórek, Tkanek i Narządów ze Zwłok Ludzkich, Rejestr Podmiotów Wykonujących Działalność Leczniczą, Centralna Baza Umów, Rejestr zezwoleń na prowadzenie aptek, Centralny Rejestr Lekarzy, Centralny Rejestr Pielęgniarek i Położnych, Rejestr Diagnostów Laboratoryjnych, Rejestr Farmaceutów, Rejestr Produktów Leczniczych Dopuszczonych do Obrotu na Terytorium Rzeczpospolitej Polskiej, Wykaz Refundowanych Produktów Leczniczych, Środków Spożywczych Specjalnego Przeznaczenia Żywieniowego i Wyrobów Medycznych, Rejestr Systemów Kodowania i Klasyfikacji Statystyki Resortowej. P2 / CSIOZ Wykorzystanie rejestrów funkcjonujących w systemie ochrony zdrowia zgodnie z projektem P2 ( Tabela 14: Główni interesariusze i kluczowe interakcje w obszarze PRIM Koncepcja budowy PRIM zakłada, że ma on być systemem otwartym, co oznacza, że w każdym momencie będzie można dołączyć do niego inne PL, pod warunkiem spełnienia wymagań disi@pomorskie.eu, Strona 157 z 212

158 technicznych, niezależnie od formy organizacyjnej bądź statusu właścicielskiego (jednostki publiczne i niepubliczne). Dotyczy to w szczególności dołączenia do portalu dla pacjentów oraz dołączenia do systemu elektronicznej dokumentacji medycznej. Niniejsza koncepcja nie precyzuje formatów i protokołów wymiany danych określając jedynie założone mechanizmy użyte w integracji (SOA) i uruchomienie komunikacji z Systemem P1 i P2 przy wykorzystaniu interfejsów komunikacyjnych aplikacji API udostępnionych w zakresie Systemu P1 i P2. Określenie precyzyjnych formatów wymiany danych (protokołów, opisów konkretnych web services) będzie jednym z zadań wykonawcy realizującego poszczególne zakresy prac. 7.2 Warstwa aplikacji Koncepcja umiejscowienia Pomorskiego Repozytorium Informacji Medycznej została zobrazowana na rysunku poniżej. PRIM zostanie zaimplementowany w warstwie regionalnej PeZ i składać się będzie z następujących elementów: regionalne repozytorium elektronicznej dokumentacji medycznej (regionalny EDM) oraz regionalny rejestr dokumentacji medycznej (RDM). Rysunek 7-2: PRIM, warstwa aplikacji Regionalne repozytorium EDM przechowuje dokumenty przeznaczone do udostępnienia ze wszystkich podmiotów leczniczych w celu ich dalszej dystrybucji do podmiotów upoważnionych. disi@pomorskie.eu, Strona 158 z 212

159 Dostęp do tych danych realizowany będzie portal informacyjny, będący również częścią warstwy regionalnej oraz przez aplikacje do przeglądania dokumentacji medycznej zainstalowane w szpitalach w ramach lokalnego EDM. Dane medyczne będą dostępne wyłącznie dla osób uprawnionych (pracowników medycznych). Pozostali pracownicy (w szczególności odpowiedzialni za utrzymanie warstwy regionalnej) nie będą mieli dostępu do tych danych. Regionalny EDM będzie zatem repozytorium dostępnym na poziomie regionalnym, agregującym elektroniczną dokumentację medyczną przekazywaną przez podmioty lecznicze w celu udostępnienia jej pacjentom oraz osobom uprawnionym przez nich, w szczególności lekarzom. Regionalne repozytorium ułatwi dostęp jednostek do dokumentów i zabezpieczy system przed brakiem dostępności systemów lokalnych. Zostanie ono wdrożone w części regionalnej architektury PeZ w celu udostępnienia elektronicznej dokumentacji medycznej pacjentom i lekarzom poprzez portal, aplikacje lokalne oraz ew. inne systemy do udostępniania i przechowywania dokumentacji medycznej. Repozytorium będzie pełnić również rolę kopii zapasowej dla lokalnych repozytoriów elektronicznej dokumentacji medycznej. Rozwiązanie to pozwoli spełnić wymagania wynikające: z ustawy o prawach pacjenta i rzeczniku praw pacjenta, która zobowiązuje podmioty lecznicze do składowania danych medycznych przez okres 20 lat, z prawa pracy, które zobowiązują do składowania części dokumentacji medycznej przez okres 40 lat. Każdy z podmiotów leczniczych będzie posiadał własną, wyodrębnioną wirtualną lub fizyczną przestrzeń dyskową, na której zdalnie będzie składował swoje dane. Koncepcja związana z archiwizacją i gromadzeniem danych została opisana w rozdziale 14 tego dokumentu. Źródłem zasilania regionalnego EDM będą systemy EDM w lokalnych podmiotach leczniczych. Regionalny EDM będzie przetwarzać dane medyczne. System będzie zasilany danymi w czasie rzeczywistym, w momencie w którym do systemu lokalnego trafiają dokumenty z systemów HIS. Dane przechowywane w regionalnym EDM będą wysyłane i przekazywane w czasie rzeczywistym uprawnionym osobom z wykorzystaniem portalu oraz lokalnych aplikacji EDM. Regionalny rejestr dokumentacji medycznej (RDM) zawierać będzie indeks dokumentów przechowywanych w lokalnych EDM. Ponadto, w systemie regionalnym znajdą się: rejestry pracowników medycznych, rejestr pacjentów, rejestr zgód na przekazywanie dokumentacji medycznej. Rejestr pacjentów zrealizowany zostanie w strategii Master Patient Index tj. będzie wspierał identyfikację pacjentów z różnych systemów PL oraz umożliwiał łączenie rekordów. Rejestr Pacjentów będzie wspierał standardy IHE PDQ i IHE PIX. disi@pomorskie.eu, Strona 159 z 212

160 Lokalne EDM będą wyposażone w kompletny zestaw API wspierający podstawowe usługi IHE XDS.b pozwalający na integrację z innymi systemami w podmiocie leczniczym. Regionalna warstwa integracyjna to mechanizmy integracyjne umożliwiające na bezpieczne przesyłanie dokumentów z lokalnych EDM (przesłanie dokumentu medycznego do regionu, pobranie dokumentu medycznego z regionu, rejestracja dokumentu i zbioru dokumentów). Dodatkowo, rozwiązanie to będzie wykorzystywane do transferu danych pomiędzy systemami wdrażanymi w warstwie regionalnej, w szczególności PRIM i portalem. Ze względu na krytyczność komponentu szyny danych w przepływie informacji w ramach warstwy regionalnej konieczne jest zapewnienie wydajnej, stabilnej i skalowalnej platformy integracyjnej. Platforma powinna zapewniać budowanie integracji w postaci usług prostych (wirtualizacja i mediacja) oraz złożonych (orkiestracja), a także obsługiwać standardy IHE (co najmniej XDS.b, PIX, PDQ) stosowane w systemach medycznych. Rysunek 7-3 Komponenty logiczne warstwy integracyjnej Platforma regionalna budowana w ramach projektu PeZ powinna w szczególności być zgodna z wytycznymi, zasadami i rekomendacjami dla usługodawców dot. bezpiecznego przetwarzania EDM publikowanymi przez CSIOZ. W celu zapewnienia wymiany informacji pomiędzy usługodawcami, platforma P1 będzie gromadzić informacje o zdarzeniach medycznych mających miejsce u poszczególnych usługodawców. W celu realizacji tej wymiany zostały wybrane standardy disi@pomorskie.eu, Strona 160 z 212

161 komunikacji, które sprawią, że proces ten będzie mógł przebiegać w sposób zunifikowany. Z uwagi na interoperacyjność wybrany został standard IHE XDS.b, który gwarantuje obsługę wymaganych procesów w warunkach polskiej ochrony zdrowia jak również komunikację międzynarodową. Platforma P1 wykorzystuje dwa główne profile IHE w celu komunikacji między systemami: IHE XDS - wykorzystywany do wymiany informacji o dokumentach medycznych (rozszerzona o informacje o zdarzeniu medycznym, w ramach którego dokumentacja ta powstała), IHE XDM -wykorzystywany do importu do P1 dokumentów z placówek likwidowanych, HL7 CDA Release 2 - Jako standard zapisu dokumentów medycznych Współpraca z platformą P1 odbywać się będzie za pomocą wymiany komunikatów w postaci plików XML (standard XML Schema) - system zapewni wsparcie dla standardu przesyłania komunikatów, SOAP (w wersji co najmniej 1.1) z załącznikami - do opisu struktury i semantyki serwisu sieciowego (web service) zostanie wykorzystany standard WSDL (w wersji co najmniej 1.X). 7.3 Warstwa danych Architektura logiczna aplikacji implikuje architekturę danych, która została zaprezentowana na poniższym rysunku. Opisano na nim wyłącznie kluczowe bazy danych i rejestry oraz proponowane mechanizmy wymiany danych pomiędzy nimi, w ramach funkcjonalności z zakresu PRIM. Istotne jest natomiast, by użyte technologie bazy danych zapewniały wysoką dostępność, bezpieczeństwo (m.in. przeźroczyste dla aplikacji szyfrowanie), skalowalność klastra, mechanizmy zabezpieczenia i monitorowania działań użytkowników uprzywilejowanych (administratorów bazy danych). disi@pomorskie.eu, Strona 161 z 212

162 Rysunek 7-4: PRIM, architektura danych Na rysunku poniżej zamieszczono diagram prezentujący przepływ danych pomiędzy poszczególnymi systemami warstwy regionalnej i lokalnej. disi@pomorskie.eu, Strona 162 z 212

163 Rysunek 7-5: PRIM, schemat integracji i wymiany danych Regionalny portal informacyjny udostępniać będzie jeden z interfejsów użytkownika do elektronicznej dokumentacji medycznej i usługi elektronicznej rejestracji. W niniejszej koncepcji założono, że portal pobierać będzie na żądanie użytkownika rekord pacjenta i dokumentację medyczną z wykorzystaniem regionalnego EDM. W drugą stronę, dokumentacja medyczna i dodatkowe informacje wprowadzane przez pacjentów wysyłane są do regionalnego Rejestru Pacjenta. Pacjenci będą mieć możliwość za pośrednictwem portalu zarządzania uprawieniami lekarzy na dostęp do własnej dokumentacji medycznej. Dodatkowo portal umożliwi pacjentom elektroniczną rejestrację wizyt, dokonaną poprzez warstwy integracyjne w lokalnym, systemie HIS. Regionalny EDM udostępniać będzie interfejs API do pobierania dokumentacji medycznej i rekordu pacjenta i jego głównym zadaniem będzie gromadzenie dokumentacji medycznej spływającej z poszczególnych podmiotów leczniczych. Usługa udostępnienia dokumentacji medycznej poprzedzona będzie sprawdzeniem w RDM, czy lekarz posiada odpowiednie uprawnienia na dostęp do dokumentacji. Dokumentacja medyczna wytworzona w systemach obsługujących część białą w podmiotach leczniczych przechowywana będzie w lokalnych EDM podmiotów leczniczych. Lokalne EDM odpowiadać będą również za przekazanie tej dokumentacji medycznej na poziom regionalny, Jak opisano wyżej, na poziomie regionalnym będzie ona gromadzona w regionalnym EDM. Tym samym HIS przesyłać będzie dokumentację medyczną do lokalnego systemu EDM. W drugą stronę lokalny disi@pomorskie.eu, Strona 163 z 212

164 EDM pobierać będzie dokumentację medyczną i rekord pacjenta z EDM w celu prezentacji lekarzowi. Funkcjonalnością tego systemu będzie również tworzenie kont pacjentów w regionalnej bazie LDAP oraz aktualizacja danych pacjentów w RDM. Tym samym HIS korzystać będzie z aktualnych danych pacjentów zgromadzonych w RDM. Opisywana koncepcja zakłada utworzenie bazy LDAP na poziomie regionalnym. Komponent ten odpowiedzialny będzie za przechowywanie kont użytkowników i będzie wykorzystywany przez mechanizmy autentykacji działające w innych elementach systemu PeZ. Rejestr Danych Medycznych odpowiadać będzie za zarządzanie rejestrami i słownikami wykorzystywanymi przez pozostałe komponenty architektury Baza danych lokalnego EDM Lokalne bazy danych EDM będą składować wszystkie aktualne dokumenty medyczne wytworzone w lokalnym systemie HIS i systemach uzupełniających obsługę części białej, aktualizowane po każdym przesłaniu dokumentu do systemu lokalnego EDM oraz dane krytyczne, czyli: Numer PESEL lub inny numer identyfikacyjny, Imię, Nazwisko, Dane lekarza pierwszego kontaktu, Dane kontaktowe, Dane kontaktowe osoby do kontaktu w nagłych przypadkach, Zdolność komunikacji: jakość słuchu, wzroku, języki, Niepełnosprawności, Specyficzne warunki zdrowotne, takie jak: Alergie, uczulenia na leki, Aktywne implanty, Potencjalne źródła zniekształceń diagnostycznych jak metale w protezach lub inne ciała obce, Stałe schorzenia jak cukrzyca, hemofilia, astma, choroby serca, Specyficzny stan zdrowia: ciąża, rekonwalescencja, intensywny trening, Aktualnie pobierane leki, leki stałe, Aktualne choroby i leczenie Przebyte choroby i ich leczenie, Otrzymane szczepienia, disi@pomorskie.eu, Strona 164 z 212

165 Oznaczona grupa krwi, Dane o transfuzji krwi, Zastrzeżenia co do stosowanych procedur, np. na tle religijnym: transfuzje, Certyfikat dawcy organów, Honorowy krwiodawca, Aktualizacja danych krytycznych w systemach lokalnych EDM będzie odbywała się po przesłaniu dokumentów aktualizacyjnych zawierających odpowiednie struktury danych. Dane krytyczne powinny być zapisane w otwartym standardzie danych (HL7). Ponadto w lokalnej bazie EDM przechowywane będą indeksy do danych obrazowych z systemów RIS, PACS przechowywanych lokalnie w tych systemach, o ile systemy te zapewnią taką funkcjonalność Baza danych regionalnego EDM W bazie danych regionalnego EDM znajdą się między innymi następujące dane: Dane krytyczne zgodne z lokalnych baz danych EDM, zapisane w otwartym formacie danych (HL7), Podpisane elektronicznie na poziomie lokalnym dokumenty medyczne: Skierowania, Zlecenia, Recepty, Zwolnienia, Wyniki konsultacji medycznych, Karty wypisowe, Opis wyników badań obrazowych, Wyniki innych badań, np. laboratoryjnych, histopatologicznych, Linki do lokalnie przetrzymywanych danych obrazowych z systemów LIS, PACS, o ile systemy te zapewnią taką funkcjonalność Baza danych RDM W bazie danych Regionalnego Systemy Rejestrów znajdą się między innymi dane o: Pacjentach Lekarzach, Świadczeniodawcach disi@pomorskie.eu, Strona 165 z 212

166 7.4 Koncepcja w zakresie regionalnego systemu informatycznego klasy BI Regionalny system BI Modelem w jakim rekomendujemy aby funkcjonował system BI w Podmiotach Leczniczych będzie opierał się o centralną hurtownię danych. Rozwiązanie takie zakłada funkcjonowanie jednej centralnej hurtowni danych która jest zasilana danymi z systemów operacyjnych funkcjonujących w PL. Rozwiązanie tego typu jest aktualnie wdrożone w SWP i w 14 szpitalach. Istotnym zagadnieniem przy wdrażaniu tego rozwiązania będzie pobieranie danych z systemów operacyjnych funkcjonujących w PL. Hurtownia danych przygotowana pod system analiz musi integrować w sobie dane z różnych systemów oraz wskaźniki jakie na bazie przekazanych danych mają być wyliczane. Zakładamy, że w ramach projektu PeZ nastąpi standaryzacja oprogramowania ERP i HIS. Część PL będzie wdrażała rozwiązania od nowa, a część modernizowała aktualnie posiadane. Należy zadbać, aby wszystkie nowo wdrażane rozwiązania miały interfejs wymiany danych z hurtownią danych, a dla już funkcjonujących zadbać o taką ich modernizację, aby takie interfejsy powstały. Wdrożenie rozwiązania opartego o regionalną hurtownię danych przedstawia się następująco : BI (regionalne) Hurtownia Danych Zasilanie hurtowni danych BI1 BI2 BI3 BI4 BI19 BI Propozycja architektury rozwiązania klasy BI Planowane rozwiązanie BI powinno mieć następujące funkcjonalności : ocena zaspokojenia potrzeb medycznych mieszkańców województwa, ocena efektywności wykorzystania posiadanych zasobów medycznych, ocena jakości i zakresu dostarczanych usług, disi@pomorskie.eu, Strona 166 z 212

167 ocena i monitorowanie efektywności ekonomicznej i kondycji finansowej podległych placówek, ocena i monitorowanie kontraktów i rozliczeń z NFZ, porównanie wyników osiąganych przez poszczególne placówki, raporty ad hoc, monitoring niestandardowych wskaźników, tzn. problem z ustaleniem niestandardowych wartości składowych kosztów ze względu na niestandardowe przypadki leczenia (np. powikłania), realizacja analiz na bazie danych historycznych (kwestia wykorzystania danych historycznych, a nie bieżących z systemów dziedzinowych oraz ERP), rzetelność danych (aktualnie są problemy z nie pokrywającymi się danymi wewnątrz PL), a co za tym idzie wiarygodność raportów i benchmarków, właściwe liczenie kosztów od poziomu oddziału poprzez koszty lekarza na pojedynczego pacjenta (opracowanie dokładnego modelu analitycznego uruchomienie programu analitycznego, wskazywanie błędów w rozliczeniach z NFZ, analiza trendów, możliwość predykcji danych, zaawansowane narzędzia raportowania, brak modułu spinającego kilka innych modułów celem wyciągnięcia danych np. w formie wydruku na jednej stronie. Na bazie zebranych w czasie wywiadów i najlepszych praktyk, dla tego typu rozwiązań proponujemy aby powstała regionalna hurtownia danych. Hurtownia ta zostanie umieszczona w regionalnym GCPD. Bazując na dotychczasowych doświadczeniach z wykorzystywanego systemu BI oraz analizy danych jakimi będzie zasilana hurtownia można stwierdzić, że nie będzie konieczności budowania specjalnej infrastruktury technicznej dla tego rozwiązania. disi@pomorskie.eu, Strona 167 z 212

168 7.5 Koncepcja Systemu Oceny Jakości Proponowana architektura systemu Poniższa tabela przedstawia szczegółowy opis Systemu Oceny Jakości oraz pokazuje funkcjonalności i najważniejsze aspekty działania systemu. Opis Ujednolicony System Oceny Jakości opierać się będzie na rozwiązaniu ankietowym, dostępnym z poziomu portalu e-zdrowie i dostępnym dla każdego pacjenta. Wywołanie ankiet będzie możliwe w trzech przypadkach, otrzymanie linku do ankiety w wyniku zakończenia procesu rejestracji, otrzymanie linku do ankiety w wyniku przebytego procesu leczenia, samodzielne wejście na portal ezdrowie w celu wypełnienia ankiety. Proces otrzymania linku będzie opierać się na rozwiązaniach elektronicznych. Dane zebrane z ankiet zostaną zagregowane i zaprezentowane w portalu ezdrowie poprzez webowe narzędzie BI do generowania i prezentacji raportów. Warstwa wprowadzania, edycji i prezentacji działająca poprzez portal ezdrowie będzie korzystała z rozwiązania usług katalogowych, które pozwoli nadać kontekst pacjenta oraz zarządzać uprawnieniami poszczególnych użytkowników systemu. Warstwa komunikacji wykorzystywać będzie szynę usług do komunikacji z bazą danych i hurtownią danych (warstwą danych) oraz poprzez system rejestracji pozwoli nadać kontekst łączący pacjenta z wizytą. Źródło zasilania Zakres przetwarzanych informacji Częstotliwość zasilania Dane do systemu są wprowadzane przez pacjentów Podmiotów Leczniczych za pomocą funkcjonalności portalu ezdrowie. Wzory ankiet definiowane przez administratora Zamawiającego za pomocą narzędzia CMS. Dane ankietowe zbierane od pacjentów Podmiotów Leczniczych. W czasie rzeczywistym, zasilanie bazy danych gromadzących informacje ankietowe. Zasilanie regionalnej hurtowni danych odbywało się będzie w regularnych interwałach (np. zasilenie nocne). Pierwotne zasilenie używanych baz Nie zakłada się migracji danych do systemu z poprzednio funkcjonujących sposobów gromadzenia informacji dotyczących oceny jakości. disi@pomorskie.eu, Strona 168 z 212

169 danych Dalszy przepływ informacji Dane z systemu są prezentowane na portalu ezdrowie za pomocą narzędzia webowego do generowania i prezentacji raportów. Tabela 15: Funkcjonalności i najważniejsze aspekty działania Systemu Oceny Jakości Rysunek 7-6: Schemat architektury Systemu Oceny Jakości Powyżej zawarty został graficzny schemat architektury systemu z podziałem na warstwy wprowadzania i edycji, komunikacji i wymiany danych oraz prezentacji określający elementy składowe wraz ze sposobami przepływu danych pomiędzy poszczególnymi elementami a także innymi systemami z którymi komunikuje się SOJ Sposoby gromadzenia i analizy danych wraz z raportowaniem Zasilanie systemu w dane odbywać się będzie poprzez formularz ankietowy HTML dostępny z poziomu przeglądarki internetowej, jako element portalu e-zdrowie. Ankieta ta będzie wywoływana z bazy danych na podstawie kontekstu użytkownika, który wypełnia ankietę, a co za tym idzie sparametryzowana (np. osoba, która zakończyła proces leczenia dostanie inną ankietę od osoby, która tylko przeszła proces rejestracji. Wypełniona ankieta zostanie zapisana w bazie danych, a następnie przekazana do Hurtowni Danych w procesie cyklicznego zasilania. disi@pomorskie.eu, Strona 169 z 212

170 Ankiety do bazy danych definiowane będą przez administratora systemu po stronie zamawiającego, który poprzez interfejs do tworzenia ankiet korzystający z narzędzi CMS zdefiniuje pola oraz typy ankiet. Stworzona ankieta zostanie przekazana do Bazy danych. Wyniki ankiet zapisane w hurtowni danych połączone będą z regionalnym systemem BI, który odpowiedzialny będzie za analizę danych, na podstawie której generowane będą raporty dla Podmiotów Leczniczych oraz Zamawiającego. Wykorzystanie silnika BI umożliwi dokonywanie kompleksowych wielowymiarowych analiz, które znajdą swoje odzwierciedlenie w generowanych raportach. Kompletność i porównywalność danych zostanie zapewniona dzięki spójnemu i ujednoliconemu formularzowi oraz regionalnemu systemowi definiowania ankiet przez administratora Zamawiającego. Wśród rodzajów raportów można wymienić: raporty podsumowujące o Podmiotach Leczniczych, raporty w podziale na Oddziały, raporty w podziale na Lekarzy, raporty według grup pacjentów (wiek, płeć, wykształcenie, itp.) raporty zbiorcze/benchmarkowe, inne raporty wymagane przez Zamawiającego. Dane prezentowane będą dzięki webowym narzędziom BI korzystającym z silnika BI i Hurtowni Danych za pomocą portalu ezdrowie w formie predefiniowanych przez administratora Zamawiającego raportów podsumowujących generowanych na portalu ezdrowie oraz arkuszy xlsx eksportowanych z systemu na podstawie żądanych zmiennych. Każda uprawniona osoba z Podmiotu Leczniczego będzie mogła wygenerować kompleksowe raporty dla swojego PL oraz zbiorczy raport porównujący najważniejsze wskaźniki w odniesieniu do pozostałych podmiotów. Zamawiający będzie miał możliwość generowania kompleksowych raportów dla każdego Podmiotu Leczniczego oraz kompleksowych raportów porównawczych/benchmarkujących Integracja z portalem e-zdrowie Portal e-zdrowie musi umożliwiać dołączenie modułów zapewniających wprowadzanie danych i dostęp do raportów dla Systemu Oceny Jakości. Konstrukcja portalu musi być oparta o oprogramowanie pozwalające na zarządzanie treścią (CMS) oraz usługi katalogów, a także narzędzia webowe zintegrowane z systemem BI i hurtownią danych do generowania raportów i prezentacji treści na portalu. disi@pomorskie.eu, Strona 170 z 212

171 7.5.4 Wymagania techniczne systemu oraz rozwiązania IT Z uwagi na oparcie architektury Systemu Oceny Jakości o systemy wdrażane w ramach projektu Pomorskie e-zdrowie nie stwierdzono szczególnych wymagań innych niż dla systemów towarzyszących (system BI, Hurtownia i Baza Danych, portal e-zdrowie) w odniesieniu do wymagań technicznych, infrastruktury sprzętowej, oprogramowania, koniecznych do zastosowania technologii informatycznych, własności kodów źródłowych i praw autorskich. Wymagana jest integracja z systemami: BI - w zakresie przekazywania danych do tworzenia raportów. e-rejestracji w zakresie przekazania kontekstu ocenianej wizyty. usługi katalogowe w zakresie przekazania informacji o użytkowniku w szczególności z uprawnieniami. Portal e-zdrowie w zakresie osadzenia modułu Systemu Oceny Jakości na platformie portalu. 7.6 Koncepcja Systemu Zdarzeń Niepożądanych Proponowana architektura systemu Poniższa tabela przedstawia szczegółowy opis Systemu Zdarzeń Niepożądanych oraz pokazuje funkcjonalności i najważniejsze aspekty działania systemu. Opis Ujednolicony System Zdarzeń Niepożądanych opierać się będzie na rozwiązaniu webowym formularzu zgłoszenia zdarzenia niepożądanego dostępnym z poziomu portalu e-zdrowie i dostępnym dla każdej uprawnionej przez administratora portalu osoby w Podmiocie Leczniczym oraz rejestru Zdarzeń niepożądanych dostępnym na serwerach Zamawiającego, który będzie funkcjonował w trybie bazy danych. Dane dodane do systemu zostaną zagregowane i zaprezentowane w portalu ezdrowie poprzez webowe narzędzie BI do generowania i prezentacji raportów. Warstwa wprowadzania, edycji i prezentacji działająca poprzez część intranetową portalu ezdrowie będzie korzystała z rozwiązania usług katalogowych, które pozwoli nadać kontekst podmiotu oraz zarządzać uprawnieniami poszczególnych użytkowników systemu. W warstwie komunikacji dzięki szynie usług baza danych zostanie zasilana informacjami, dotyczącymi wprowadzonych zdarzeń oraz informacje będą mogły być edytowane na poziomie Podmiotów Leczniczych. Źródło zasilania Dane do systemu są wprowadzane przez każdego uprawnionego pracownika Podmiotu Leczniczego. disi@pomorskie.eu, Strona 171 z 212

172 Zakres przetwarzanych informacji Częstotliwość zasilania Dane dotyczące zdarzeń medycznych w tym dane pacjenta. W czasie rzeczywistym, zasilanie bazy danych gromadzących informacje o zdarzeniach niepożądanych. Zasilanie regionalnej hurtowni danych odbywało się będzie w regularnych interwałach (np. zasilenie nocne). Pierwotne zasilenie używanych danych baz Nie zakłada się migracji danych do systemu z poprzednio funkcjonujących sposobów gromadzenia informacji dotyczących zdarzeń niepożądanych. Dalszy przepływ informacji Dane z systemu są prezentowane na portalu ezdrowie za pomocą narzędzia webowego do generowania i prezentacji raportów. Tabela 16: Funkcjonalności i najważniejsze aspekty działania Systemu Zdarzeń Niepożądanych Rysunek 7-7: Architektura Systemu Zdarzeń Niepożądanych Powyżej zawarty został graficzny schemat architektury systemu z podziałem na warstwy wprowadzania i edycji, komunikacji i wymiany danych oraz prezentacji określający elementy disi@pomorskie.eu, Strona 172 z 212

173 składowe wraz ze sposobami przepływu danych pomiędzy poszczególnymi elementami a także innymi systemami z którymi komunikuje się SZN Sposoby gromadzenia i analizy danych wraz z raportowaniem Zasilanie w dane odbywać się będzie poprzez formularz HTML, dostępny z poziomu przeglądarki internetowej, jako element portalu e-zdrowie w części intranetowej. Formularz ten będzie dostępny jako jeden z modułów części intranetowej portalu dla każdego uprawnionego użytkownika systemu po zalogowaniu. Formularz będzie spójny dla wszystkich Podmiotów Leczniczych oraz niezmienny a jego konstrukcja oparta będzie o rozwiązania CMS. Wypełniony formularz zostanie zapisany w bazie danych, a następnie przekazany do Hurtowni Danych w procesie cyklicznego zasilania. Przykładowa konstrukcja pól wypełnianych dla formularza zgłoszenia zdarzenia niepożądanego Nazwa PL. Lokalizacja. Rodzaj ZN (list rozwijana np.): o Zdarzenia niepożądane związane z podaniem leku. o Zdarzenia niepożądane związane z anestezją/znieczuleniem. o Zdarzenia niepożądane związane z transfuzją. o Zdarzenia niepożądane związane ze sprzętem medycznym. o Operacja niewłaściwej strony. o Upadki pacjentów. o Samobójstwa. o Zakażenia MRSA. o Zgon matki/położnicy. o Pozostawienie ciała obcego. o Poparzenie pacjenta na sali operacyjnej. Opis ZN. Data wystąpienia ZN. Miejsce wystąpienia ZN. Analiza przyczyn (wykonano, nie wykonano, trwa). Przyczyna ZN (pole opisowe). Podjęte środki korygujące (pole opisowe). Zasądzono odszkodowanie (Tak/Nie). Wysokości zasądzonego odszkodowanie. Osoba rejestrująca. Zaraportowano do. disi@pomorskie.eu, Strona 173 z 212

174 Inne. Wypełnione formularze zapisane będą w regionalnych EDM w rekordzie pacjenta w otwartym formacie danych (HL7v3) oraz jako dokument HL7 CDA. I jednocześnie będą przesyłane do hurtowni danych połączonej z regionalnym systemem BI, który odpowiedzialny będzie za analizę danych, na podstawie której generowane będą raporty dla Podmiotów Leczniczych oraz Zamawiającego. Wykorzystanie silnika BI umożliwi dokonywanie kompleksowych wielowymiarowych analiz, które znajdą swoje odzwierciedlenie w generowanych raportach. Kompletność i porównywalność danych zostanie zapewniona dzięki spójnemu i ujednoliconemu formularzowi oraz regionalnemu systemowi definiowania ankiet przez administratora Zamawiającego. Wśród rodzajów raportów można wymienić: raporty indywidualne dla Podmiotów Leczniczych, raporty zbiorcze, raporty porównawcze (rodzaj ZN, miejsce wystąpienia), inne raporty wymagane przez Zamawiającego. Dane prezentowane będą dzięki webowym narzędziom BI korzystającym z silnika BI i Hurtowni Danych za pomocą części intranetowej portalu ezdrowie w formie predefiniowanych przez administratora Zamawiającego raportów podsumowujących generowanych na portalu ezdrowie w części intranetowej oraz arkuszy xlsx eksportowanych z systemu na podstawie żądanych zmiennych. Każda uprawniona osoba z Podmiotu Leczniczego będzie mogła wygenerować kompleksowe raporty dla swojego PL oraz zbiorcze raporty pokazujące rodzaje i miejsca występowania ZN wraz z przyczynami i środkami korygującymi dla wszystkich PL, które będą zanonimizowane bez podania nazwy innych Podmiotów.. Zamawiający będzie miał możliwość generowania kompleksowych raportów dla każdego Podmiotu Leczniczego oraz kompleksowych raportów porównawczych/ benchmarkujących Integracja z portalem e-zdrowie Portal e-zdrowie musi umożliwiać dołączenie modułów zapewniających wprowadzanie danych i dostęp do raportów dla Systemu Zdarzeń Niepożądanych. Konstrukcja portalu musi być oparta o oprogramowanie CMS, możliwość zarządzania treścią oraz usługę katalogową, a także narzędzia webowe zintegrowane z systemem BI i hurtownią danych do generowania raportów i prezentacji treści na portalu Wymagania techniczne systemu oraz rozwiązania IT Z uwagi o oparcie architektury Systemu Zdarzeń Niepożądanych o systemy wdrażane w ramach projektu Pomorskie ezdrowie nie stwierdzono szczególnych wymagań innych niż dla systemów disi@pomorskie.eu, Strona 174 z 212

175 towarzyszących (system BI, Hurtownia i Baza Danych, portal e-zdrowie) w odniesieniu do wymagań technicznych, infrastruktury sprzętowej, oprogramowania, koniecznych do zastosowania technologii informatycznych, własności kodów źródłowych i praw autorskich. Wymagana jest integracja z systemami: BI - w zakresie przekazywania danych do tworzenia raportów. usługi katalogowe w zakresie przekazania informacji o użytkowniku w szczególności z uprawnieniami. Portal e-zdrowie w zakresie osadzenia modułu Systemu Zdarzeń Niepożądanych na platformie portalu. 7.7 Koncepcja Systemu Obsługi Ratownictwa Drogowego Założenia dla koncepcji Systemu Obsługi Ratownictwa Drogowego System Obsługi Ratownictwa opierać się będzie na rozwiązaniu uzupełniającym funkcje Systemu Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego SWD PRM o rozwiązania pozwalające na automatyczne przekazywanie danych ratunkowych do zespołu wyjazdowego z bazy danych Regionalnego Repozytorium Danych Ratunkowych, oraz rozwiązanie pozwalające na wysłanie w sposób elektroniczny Karty Medycznych Czynności ratunkowych bezpośrednio do SOR podmiotu leczniczego do którego karetka zawiezie poszkodowanego o ile w ramach systemu SWD PRM zostaną udostępnione konieczne interfejsy. Na obecnym etapie prac projektowych należy również uwzględnić sytuację, w której SWD PRM w wersji 2.0 zapewni poniższe wymagania i funkcjonalności. Bez ostatecznych decyzji od gestora systemu SWD PRM (obecnie MSWiA, docelowo MZ) w projekcie na etapie aktualizacji KTT opisano proponowane założenia dedykowanego w ramach PeZ rozwiązania, nie mniej jednak przyjęto również potencjalną integrację z SWD 2 PRM. W obecnej chwili system SWD PRM jest zainstalowany na stanowiskach dyspozytora, który po podjęciu zgłoszenia, wypełnia Kartę Wyjazdu, tym samym zlecając najbliżej zlokalizowanej wolnej karetce pogotowia wyjazd do poszkodowanego. Dane wyjazdowe trafiają na tablet systemu SWD PRM w karetce pogotowia, który jest zainstalowany w niemedycznej części karetki, tak aby miał do niego dostęp Ratownik Medyczny lub Lekarz. Lekarz wypełnia następnie Kartę Medycznych Czynności Ratunkowych (KMCR), która wydrukowana na drukarce atramentowej w karetce trafia w jednej kopii do SORu szpitala a w drugiej do Stacji Pogotowia. Przy zamknięciu zlecenia wyjazdowego, dane zostają przekazane do bazy danych systemu SWD, jednak szpital musi sam przepisać te dane do swojego systemu (Izba Przyjęć) a Stacja Pogotowia sama musi ręcznie przepisać dane z Karty Wyjazdu i Karty Medycznych Czynności Ratunkowych do swojego systemu analitycznego. Dane będą mogły być importowane automatycznie do systemu HIS Szpitala oraz systemu analitycznego Pogotowia disi@pomorskie.eu, Strona 175 z 212

176 Ratunkowego pod warunkiem że w ramach systemu SWDPRM zostaną udostępnione niezbędne interfejsy. System SWD jest systemem komunikującym się z karetką pogotowia w sposób radiowy, a dostęp do sieci i systemów serwerowych SWD jest niemożliwy w chwili obecnej do uzyskania w celu integracji systemu Regionalnego e-zdrowia i tego systemu. Ze względu na to że większość zespołów ratownictwa medycznego składa się z 2 osób nie ma realnych możliwości wprowadzania danych do systemów ratownictwa w trakcie trwania akcji ratunkowej. Dostęp do niezbędnych danych w ramach rejestru danych ratunkowych należy zapewnić poprzez udostępnienie aplikacji internetowej responsywnej z której będą mogli skorzystać zarówno dyspozytorzy zespołów i jak i członkowie zespołów wyposażeni w mobilne urządzenia komunikacyjne. Rolą dyspozytora jest przekazywanie informacji niezbędnych do ratowania życia drogą radiową w szczególności informacji pozyskiwanych z regionalnego rejestru danych ratunkowych dotyczących pacjenta oraz dostępności zasobów w ramach aktywnych Szpitalnych Oddziałów Ratunkowych. Aby nie duplikować zadań realizowanych przez obydwa systemy, nowy system będzie obsługiwać tylko sferę białą czynności ratunkowych a zadania związane z wypełnieniem systemu SWD w zakresie Karty Medycznych Czynności Ratunkowych zostaną przesunięte do Dyspozytorni. W karetce pogotowia pojawi się drugi przenośny tablet medyczny, na którym zostanie zainstalowana aplikacja, która umożliwi: Odczyt danych ratunkowych z RCZM i RRDR w czasie wyjazdu do Pacjenta Wypełnienie KMCR i wysłanie jej do SOR bez drukowania Wybór SOR w trakcie transportu Pacjenta W Dyspozytorni Stacji Pogotowia pojawi się komputer z aplikacją systemu. W każdym z SOR pojawią się tablety wiszące przy wjeździe na SOR szpitala oraz duży monitor informujący o zbliżającym się Pacjencie. Dyspozytor w trakcie podjęcia zgłoszenia, wypełni w pierwszej kolejności Kartę Wyjazdu w systemie SWD, następnie informacje pozyskane w zgłoszeniu wpiszę w okno programu SORD, m.in. wstępne rozpoznanie, dane identyfikacyjne Pacjenta, np. PESEL. System sam odszuka Pacjenta po np. numerze PESEL, lub zidentyfikowanym numerze telefonu lub zakwalifikuje go jako nie w pełni rozpoznany lub NN. Ideą jest aby ta aplikacja działała automatycznie przy niewielkiej ilości danych w wyszukiwaniu rekordu Pacjenta. System będzie korzystał z różnych źródeł danych tak aby jednoznacznie dało się przypisać ratowanego Pacjenta do jego rekordu w RRDR. Następnie Dyspozytor wybierze Zespół, który po otrzymaniu zlecenia z systemu SWD podjął w tym czasie już wyjazd i przekaże wszystkie disi@pomorskie.eu, Strona 176 z 212

177 dane, te ze spisu dyspozytora z zakresu rozpoznania, oraz zidentyfikowane dane Pacjenta wraz z danymi z RRDR i RBZM na tablet, tak aby w czasie jazdy mógł się z nimi zapoznać Kierownik Zespołu Wyjazdowego. Po zaopatrzeniu Pacjenta, w trakcie jazdy do SOR, Kierownik ten zamiast wypełniać KMCR w tablecie SWD, wypełni te dane w przejrzystym, specjalnie skonstruowanym programie na te potrzeby tablecie systemu SORD. Następnie wybierze SOR z listy PL i zakończy pracę tabletową z Pacjentem. Dane z KMCR oraz dane z systemów RRDR i RBZM trafia do systemu HIS PL na SOR. Na monitorze w SOR PL pojawi się informacja o wiezionym Pacjencie, szacowany czas przyjazdu Zespołu Pogotowia oraz wstępne rozpoznanie. Na monitorze pojawi się tez informacja na którym tablecie znajduje się informacja szczegółowa o Pacjencie. W trakcie wjazdu Pacjenta na SOR osoba lekarz przejmujący pobiera tablet ze ściany, w prosty sposób poprzez kartę logowania loguje się na tym tablecie i od razu otrzymuje dane o Pacjencie. W tym samym czasie dane Pacjenta zostają zarejestrowane w Izbie Przyjęć PL jako KMCR. Aplikacja przy wysyłce danych do szpitala może mieć interakcje w postaci informacji o zajętości danego SOR i możliwości wyboru innego. Wykonując zlecenie, dane z procesu ratowania zapisują się automatycznie nie tylko w PL ale również trafiają do: RBZM jako kolejne zdarzenia w bazie, RRDR jako informacje o nowych elementach ratunkowych o ile się one nie powielają z istniejącymi, Izba Przyjęć PL, systemu HIS Stacji Pogotowia Ratunkowego, w celach statystycznych i w celach uzupełnienia zasobów karetki, lokalnego EDM stacji pogotowia jako dokumentacja podpisana przez Ratownika, regionalnego EDM. Kończąc pracę, Kierownik Zespołu wytwarza elektroniczną dokumentację medyczną, która zostanie wysłana do Repozytorium EDM i zapisana pod rekordem Pacjenta w otwartym formacie danych (HL7). Dyspozytor, po przekazaniu Pacjenta do SOR przez Zespół Wyjazdowy, przepisuje dane z KMCR systemu SORD do systemu SWD. W karetce pogotowia drukarka w tym momencie nie będzie potrzebna, a w celach identyfikacji dodatkowej Pacjenta zostanie wybudowany czytnik dokumentów Pacjentów. Tablet z aplikacją SORD będzie komunikował się przez Bluetooth lub WLAN z urządzeniami zainstalowanymi w karetce, tak aby do SOR przesyłać również dane z badań. Aplikacja zostanie przystosowana do zdarzeń medycznych możliwych w karetce, np. poród, zgon. Podpisanie dokumentacji medycznej wytwarzanej w systemie zostanie wykonany poprzez podpis zintegrowany na karcie do logowania. Aplikacja tabletu będzie uwzględniać buforowanie danych przy wysyłce danych przez kanały VPN sieci disi@pomorskie.eu, Strona 177 z 212

178 LTE/3G do systemu znajdującego się w GCPD. Aplikacja będzie uwzględniała warunki wypełniania danych w systemie, które w trakcie takiego wypełniania panują w trakcie jazdy do SOR. System będzie miał również małe aplikacje w postaci widgetów dla innych służb w celu powiadamiania o miejscu dotarcia ratowników. Monitor w SOR zostanie zintegrowany bezpośrednio z systemem poprzez aplikację na system android oraz monitor z zainstalowanym takim systemem Sposoby komunikacji ze środowiskiem PeZ System będzie komunikował się: regionalnym e-rejestrem Danych Ratunkowych, centralnym BI, HIS/ERP Stacji Pogotowia, aplikacjami obsługi dla załóg karetek pogotowia, aplikacjami dla innych służb ratownictwa w celu umożliwienia szybszego dotarcia na miejsce zdarzenia poprzez dane GPS, portalem ezdrowia w celu wyświetlenia mapy pobytu zespołów pogotowia i zespołów transportu medycznego dla zalogowanych pacjentów Architektura systemu i współpraca z portalem Portal e-zdrowie musi umożliwiać dołączenie modułów zapewniających automatyczną migrację pomiędzy systemami HIS poszczególnych PL i Regionalnym Rejestrem Danych Ratunkowych online. Dane te powinny mieć odrębny obszar systemu bazodanowego oraz powinny być zapisywane na dyskach szyfrowanych. Dostęp do danych mogą mieć tylko lekarze i ratownicy stacji pogotowia poprzez tablet ratunkowy i kartę logowania oraz uprawnieni lekarze SOR poprzez aplikację w SOR. 7.8 Koncepcja platformy e-usług Założenia i koncepcja dla systemu e-informacja e-informacja będzie ogólnodostępnym portalem www o tematyce związanej z opieką zdrowotną w regionie. Odbiorcami informacji publikowanych na portalu będą pacjenci. Portal składać się będzie z szeregu sekcji i podstron zawierających treści dotyczące tematyki zdrowia. W sekcji Aktualności publikowane będą artykuły przedstawiające bieżące informacje związane z medycyną oraz opieką zdrowotną w regionie. Publikacje te będą również dostępne dla użytkowników za pośrednictwem newsletterów. disi@pomorskie.eu, Strona 178 z 212

179 Kolejnym elementem portalu będzie sekcja, w której udostępniane są użytkownikom najważniejsze dokumenty zawierające treści dotyczące pacjentów, opieki zdrowotnej, itp. Mogą to być np. informacje o prawach pacjenta, ustawy związane ze świadczeniami zdrowotnymi, istotne dla pacjenta rozporządzenia wydawane przez Ministra Zdrowia. Na portalu e-informacja będą publikowane istotne dla pacjentów linki np. do serwisów Ministerstwa Zdrowia, Narodowego Funduszu Zdrowia, Rzecznika Praw Pacjenta. Na portalu prezentowane będą informacje dotyczące poszczególnych podmiotów leczniczych. Dotyczy to zarówno podmiotów, które od początku uczestniczą w projekcie, jak i tych, które mogą przystąpić do projektu w terminie późniejszym. Wszystkie dane publikowane w ramach tej sekcji będą dostarczane przez podmioty. W ramach informacji o podmiocie pokazywane będą jego dane adresowe i kontaktowe, podstawowe dane dotyczące rodzaju działalności i struktury organizacyjnej podmiotu, świadczonych usług medycznych oraz realizującego je personelu. Można będzie dowiedzieć się jakie przychodnie, gabinety, pracownie lub laboratoria są dostępne dla pacjentów. Dla każdej komórki prezentowane będą godziny przyjęć oraz możliwe sposoby kontaktu (numery telefonów, ewentualnie adresy e- mail). Udostępniana będzie lista usług medycznych realizowanych przez komórki organizacyjne podmiotu wraz z wykonującym je personelem. W przypadku usług medycznych lub badań, które wymagają szczególnego przygotowania do wizyty na portalu zamieszczana jest adekwatna informacja. Powyższe informacje prezentowane będą w analogiczny sposób dla wszystkich podmiotów uczestniczących w projekcie. Oddzielną część portalu będą stanowiły podstrony przeznaczone dla podmiotów leczniczych i samodzielnie przez podmioty redagowane. Zawartość tych stron i zakres prezentowanych informacji zależeć będzie od każdego z podmiotów. W szczególności mogą one zawierać wiadomości dotyczące bieżącej działalności, informacje dla pacjentów, banery reklamowe, linki do własnych stron www. Oprócz tego na portalu prowadzone będą tematyczne podstrony dedykowane wszystkim odbiorcom lub określonym grupom pacjentów. Podstrony te będą redagowane przez specjalistów zajmujących się określonymi dziedzinami ochrony zdrowia. W ramach stron tematycznych występować będą ogólne serwisy informacyjne, których zadaniem będzie promowanie zdrowego trybu życia, zapoznawanie z profilaktyką i prezentowanie dostępnych programów zdrowotnych. Innym rodzajem stron tematycznych będą serwisy adresowane do konkretnych odbiorców, takich jak np. młodzież szkolna, seniorzy, kobiety ciężarne, młode matki lub osoby niepełnosprawne. disi@pomorskie.eu, Strona 179 z 212

180 Kolejnym rodzajem tematycznych podstron portalu będą serwisy przeznaczone dla określonych grup pacjentów. Ich adresatami będą osoby dotknięte poszczególnymi schorzeniami. Serwisy te zawierać będą informacje tematycznie związane z profilaktyką, leczeniem i problemami występującymi w przypadku konkretnych chorób. Tego typu serwisy mogłyby być prowadzone dla chorych przewlekle, na przykład na cukrzycę, POChP, nadciśnienie lub inne powszechne choroby cywilizacyjne. Powyższe treści będą ogólnodostępne dla wszystkich użytkowników portalu e-informacja. Dodatkowo pacjenci będą mogli założyć konto, poprzez które uzyskają dostęp do dodatkowych funkcjonalności przeznaczonych dla uwierzytelnionych użytkowników. Na indywidualne konto pacjenta można będzie przesyłać dedykowane spersonalizowane wiadomości. Za pomocą tego konta użytkownik będzie mógł się kontaktować z redaktorami portalu. Zalogowanym użytkownikom mogą być także udostępniane ankiety lub formularze. Dodatkowo dla pacjentów posiadających swoje konto udostępniane będą inne e-usługi systemu regionalnego (np. elektroniczna rejestracja na wizyty). Podstawową funkcją e-informacji będzie dostarczanie różnego rodzaju informacji istotnych dla pacjenta, ale może także stanowić niezbędny element używany przez inne e-usługi. Portal będzie wyposażony w system pomocy ułatwiający jego użytkowanie. Wybrane fragmenty portalu e-informacja będą dostępne dla użytkowników również w wersji mobilnej. disi@pomorskie.eu, Strona 180 z 212

181 Portal zapewniać będzie dostęp do treści internetowych możliwie szerokiej grupie użytkowników, włączając w to osoby niepełnosprawne, poprzez realizację standardu WCAG 2.0 zgodnie z obowiązującym Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2016 r. poz. 113) Założenia i koncepcja dla systemu e-koordynacja Opieki medycznej e-koordynacja Opieki Medycznej będzie e-usługą umożliwiającą prowadzenie skoordynowanej opieki medycznej nad określonymi grupami pacjentów, w szczególności nad osobami dotkniętymi chorobami przewlekłymi. Usługa będzie zintegrowana z portalem e-informacja w zakresie publikowania na jego podstronach tematycznych serwisów w tym przypadku serwisu adresowanego do grupy pacjentów objętej koordynowaną opieką medyczną. e-usługa będzie wspomagać organizacyjnie proces leczenia pacjenta przez personel biorący udział w opiece koordynowanej oraz umożliwiać zbieranie danych (poprzez wprowadzanie lub importowanie z innych źródeł), udostępnianie ich na poszczególnych etapach opieki i przekazywanie do Koordynatora w celu rozliczenia. Jedną z funkcjonalności udostępnianych przez usługę e-koordynacja Opieki Medycznej będzie planowanie opieki medycznej. Możliwe będzie określenie jakie badania, wizyty lub inne świadczenia medyczne mają dotyczyć pacjenta i w jakich terminach powinny zostać wykonane. Opcjonalnie personel medyczny może w takim przypadku korzystać z elektronicznej rezerwacji wizyt. Powstały harmonogram opieki będzie dostępny zarówno dla personelu medycznego, jaki i dla samego pacjenta (konto pacjenta w systemie regionalnym). W ramach e-usługi będzie istniał współpracujący z harmonogramem system powiadomień, którego zadaniem jest przypominanie pacjentowi o zaplanowanych terminach. e-usługa będzie udostępniała również funkcjonalności umożliwiające śledzenie aktualnego statusu leczenia pacjenta np. jakie badania zostały wykonane i jakie są zaplanowane. Każde wykonane świadczenie i powiązana z nim dokumentacja medyczna będą gromadzone w ramach usługi. Zarejestrowane informacje będą dostępne dla pacjenta oraz dla personelu realizującego opiekę medyczną, zgodnie z posiadanymi uprawnieniami. Usługa e-koordynacja Opieki Medycznej będzie współpracować z e-usługami Wymiany dokumentacji medycznej. W repozytorium centralnym gromadzona będzie zarówno elektroniczna dokumentacja medyczna, jak i inne dokumenty zawierające istotne informacje związane z pacjentem. Dokumenty te mogą mieć różną formę, dopasowaną do technicznych możliwości ich wytwórcy (skan papierowego dokumentu, zdjęcie papierowego dokumentu wykonane telefonem komórkowym, itp.). Gromadzona dokumentacja będzie dostępna również dla pacjenta. disi@pomorskie.eu, Strona 181 z 212

182 Integralną częścią e-usługi będzie serwis internetowy publikowany na portalu e-informacja. Będzie on służyć do udostępniania treści istotnych w kontekście rodzaju koordynowanej opieki medycznej (np. konkretnej choroby przewlekłej cukrzycy itp.). Może także stanowić dodatkowe medium umożliwiające komunikację pomiędzy pacjentem a personelem zaangażowanym w opiekę koordynowaną poprzez newsletter, chat lub forum dyskusyjne. Opcjonalnym elementem e-usługi może być funkcjonalność telekonsultacji lub wideokonsultacji zapewniająca możliwość współpracy zaangażowanego personelu medycznego ze specjalistami bez konieczności bezpośredniego kontaktu. Usługa e-koordynacja Opieki Medycznej może być zintegrowana z e-usługą e-rejestracja. Umożliwi ona personelowi elektroniczną rezerwację wizyt/badań określonych w harmonogramie leczenia już na etapie jego planowania Założenia i koncepcja dla e-opieka nad osobami chorymi na cukrzycę e-opieka nad osobami chorymi na cukrzycę będzie e-usługą wspomagającą proces leczenia i opieki nad pacjentem chorym na cukrzycę oraz będzie służyć do wsparcia akcji informacyjnych i profilaktycznych kierowanych do osób zagrożonych zachorowaniem na cukrzycę. Użytkownikami e-usługi będą osoby potencjalnie zagrożone zachorowaniem na cukrzycę, bliscy chorych na cukrzycę, pacjenci chorzy na cukrzycę (lub ich opiekunowie prawni), lekarze sprawujący opiekę nad pacjentem. e-usługa będzie wykorzystywać szereg innych usług w celu utworzenia spójnego i kompletnego mechanizmu wspomagającego leczenie i opiekę nad pacjentem chorym na cukrzycę. W zakresie wsparcia profilaktyki usługa e-opieka nad osobami chorymi na cukrzycę będzie korzystać z mechanizmów dostarczanych przez usługę e-informacja w celu publikacji artykułów, ankiet, itp. przeznaczonych dla użytkowników e-usługi w dedykowanym serwisie informacyjnym. Istotnym elementem e-usługi będzie możliwość wyszukania podmiotów oraz lekarzy związanych z procesem leczenia lub opieki nad pacjentem chorym na cukrzycę oraz możliwość dokonania elektronicznej rejestracji. W tym celu e-usługa będzie zintegrowana z usługą e-rejestracja, umożliwiając pacjentowi, jego opiekunowi lub lekarzowi elektroniczną rezerwację wizyt/badań. Integralną częścią e-usługi będzie funkcjonalność monitoringu poziomu glukozy, przyjmowanych dawek insuliny, przyjmowanych węglowodanów oraz samopoczucia pacjenta. Funkcja będzie oferować możliwość ręcznego wprowadzania określonych danych w postaci tekstowej lub w postaci załączników (np. dostarczanych przez urządzenia takie jak pompy insulinowe), które wspierają samokontrolę pacjenta oraz mogą zostać udostępnione lekarzowi w celu oceny oraz ew. modyfikacji disi@pomorskie.eu, Strona 182 z 212

183 terapii. Ponieważ istotne jest aby dane były wprowadzane przez pacjenta na bieżąco i konsekwentnie, usługa powinna zapewnić łatwość obsługi i dostępność na wszelkiego rodzaju urządzeniach mobilnych. e-opieka nad osobami chorymi na cukrzycę będzie wykorzystywać również e-usługi związane z wymianą i przechowywaniem dokumentacji medycznej w celu udostępnienia dokumentacji medycznej związanej z leczeniem cukrzycy pomiędzy lekarzami oraz pacjentem i lekarzem. W e- Usłudze skierowanej do pacjentów chorych na cukrzycę będzie to wykorzystywane m.in. do współdzielenia dokumentacji pochodzącej z monitoringu pacjenta, dokumentów związanych z diagnostyką (np. wyniki badań) oraz leczeniem pacjenta (np. wyniki konsultacji, karty informacyjne leczenia szpitalnego, skierowania i zlecenia). Opcjonalnym elementem e-usługi może być funkcjonalność telekonsultacji lub wideokonsultacji zapewniająca możliwość współpracy personelu medycznego zaangażowanego w opiekę na pacjentami chorymi na cukrzycę Założenia i koncepcja dla e-opieka nad osobami chorymi na POChP e-opieka nad chorymi na POChP będzie e-usługą przeznaczoną dla pacjentów dotkniętych Przewlekłą Obturacyjną Chorobą Płuc (POChP). Jest to jedna z chorób cywilizacyjnych i jednocześnie jedna z najczęstszych chorób przewlekłych, a zachorowalność, jak i chorobowość w zakresie POChP stale wzrasta. Usługa będzie zintegrowana z portalem e-informacja w zakresie publikowania na jego podstronach tematycznych serwisów adresowanych do pacjentów chorujących na POChP oraz członków ich rodzin. Funkcjonalność e-usługi umożliwi pacjentom gromadzenie i przechowywanie informacji dotyczących ich stanu zdrowia np. wyników wykonywanych regularnie pomiarów, aktywności w ramach rehabilitacji itp. Mogą mieć postać ręcznie wykonywanych wpisów lub załączników w różnym formacie. Zgromadzone informacje są dostępne dla lekarza prowadzącego. Dzięki temu zapewniony będzie stały monitoring stanu pacjenta chorego na POChP zapewniający wzrost jakości leczenia. Posiadającym regionalne konto i zalogowanym pacjentom w ramach e-usługi będzie można udostępniać dedykowane ankiety lub formularze do wypełniania on-line. Na podstawie pozyskanych w ten sposób informacji możliwe będzie tworzenie analiz i statystyk związanych z zachorowaniami na POChP. e-usługa Opieka nad chorymi na POChP będzie współpracować z e-usługami Wymiany dokumentacji medycznej. W rejestrze centralnym gromadzone będą informacje zarówno o elektronicznej dokumentacji medycznej, jak i o innych dokumentach zawierających istotne dane związane z pacjentem. Dokumenty te mogą mieć różną formę, dopasowaną do technicznych możliwości ich disi@pomorskie.eu, Strona 183 z 212

184 wytwórcy (skan papierowego dokumentu, zdjęcie papierowego dokumentu wykonane telefonem komórkowym, itp.). Gromadzona w ten sposób dokumentacja będzie dostępna dla personelu medycznego, zgodnie z posiadanymi uprawnieniami oraz dla pacjenta. Integralną częścią e-usługi będzie serwis internetowy publikowany na portalu e-informacja. Będzie on służył do udostępniania treści istotnych w kontekście profilaktyki, diagnostyki, leczenia i rehabilitacji związanych z Przewlekłą Obturacyjną Chorobą Płuc. Będzie także stanowił wsparcie programów profilaktycznych i edukacyjnych dedykowanych zarówno osobom zagrożonym zachorowaniem, jak i już chorującym na POChP. Ma to szczególne znaczenie w związku z dużą częścią populacji dotkniętej tą przewlekłą chorobą. Może także stanowić dodatkowe medium umożliwiające komunikację pomiędzy pacjentami oraz personelem medycznym poprzez newsletter, chat lub forum dyskusyjne. Opcjonalnym elementem e-usługi może być funkcjonalność telekonsultacji lub wideokonsultacji zapewniająca możliwość współpracy personelu medycznego zaangażowanego w opiekę na pacjentami chorymi na POChP. Usługa Opieka nad chorymi na POChP może być zintegrowana z e-usługą e-rejestracja. Umożliwi ona pacjentom elektroniczną rezerwację wizyt lub badań kontrolnych w sposób wygodny, a jednocześnie nie angażujący personelu. Usługa Opieka nad chorymi na POChP jest dostępna dla użytkowników również w wersji mobilnej Założenia i koncepcja dla systemu e-koordynacja Opieki Nad Osobami Starszymi e-koordynacja Opieki nad Osobami Starszymi będzie e-usługą umożliwiającą prowadzenie skoordynowanej opieki zdrowotnej nad osobami starszymi oraz starszymi niesamodzielnymi. Usługa będzie zintegrowana z portalem e-informacja w zakresie publikowania na jego podstronach tematycznych serwisów adresowanych do seniorów, członków ich rodziny i opiekunów nieformalnych. Użytkownikami e-usługi będą pacjenci objęci opieką koordynowaną oraz członkowie zespołu prowadzącego opiekę skoordynowaną, w skład którego wchodzą np. lekarze rodzinni, pielęgniarki środowiskowe, pracownicy socjalni, psycholodzy. Usługa e-koordynacja Opieki nad Osobami Starszymi zapewni wymianę informacji pomiędzy wszystkimi jej użytkownikami pacjentem a personelem oraz personelem pomiędzy sobą. Komunikacja pacjenta z opiekującym się nim personelem będzie odbywać się za pomocą urządzeń mobilnych typu smartfon/tablet, obsługiwanych przez samego pacjenta albo przez jego opiekuna. Urządzenia te poprzez zainstalowane na nich aplikacje, służące do kontroli samopoczucia pacjenta disi@pomorskie.eu, Strona 184 z 212

185 i informowania o sytuacjach krytycznych dotyczących pacjenta, będzie przekazywać dane do repozytorium. Dostęp do tych informacji posiadać będzie personel realizujący usługi opieki, który po ich analizie zainicjuje odpowiednie działania. Wymiana informacji pomiędzy członkami zespołu prowadzącego opiekę koordynowaną będzie wspierana przez wspólne repozytorium danych gromadzące i udostepniające informacje dotyczące pacjenta, jego zdrowia oraz zdarzeń związanych z opieką nad tym pacjentem. Dane będą wprowadzane przez każdego z członków zespołu, w określonym dla niego zakresie, za pomocą dedykowanych aplikacji, dostępnych również na urządzeniach mobilnych. W ramach repozytorium będzie istniały algorytmy i mechanizmy automatycznego generowania powiadomień dla personelu prowadzącego opiekę koordynowaną, informujących o konieczności podjęcia określonych działań. Powiadomienia mogą być również automatycznie generowane dla pacjentów - np. przypomnienie o wizycie/zaplanowanym badaniu. Integralną częścią e-usługi będzie serwis internetowy publikowany na portalu e-informacja. Będzie on służył do udostępniania treści istotnych w kontekście opieki nad osobami starszymi oraz starszymi niesamodzielnymi i informacji ogólnych przydatnych dla seniorów. Może także dawać dodatkową możliwość komunikacji pomiędzy pacjentami, rodzinami lub opiekunami pacjentów i personelem realizującym usługi opieki koordynowanej poprzez newsletter, chat lub forum dyskusyjne Założenia i koncepcja dla systemu e-rejestracja e-rejestracja będzie e-usługą umożliwiającą pacjentom zarejestrowanie się drogą elektroniczną na wybrane usługi medyczne realizowane przez PL biorące udział w projekcie. Dotyczy to zarówno podmiotów, które od początku uczestniczą w projekcie, jak i tych, które mogą przystąpić do projektu w terminie późniejszym. e-rejestracja będzie dostępna poprzez przeglądarkę internetową z poziomu Portalu Pacjenta. Będzie zintegrowana z dostępną na tym samym portalu e-usługą e-informacja. Z usługi elektronicznej rejestracji będą mogli korzystać uwierzytelnieni użytkownicy posiadający indywidualne konto pacjenta założone na Portalu Pacjenta w ramach usługi e-informacja. Rezerwacja terminu wizyty będzie wymagać zalogowania się. e-rejestracja umożliwi pacjentom wyszukiwanie usług, dla których chcą zarezerwować termin wizyty. Wyszukiwanie odbywać się będzie z uwzględnieniem różnych kryteriów. Pacjent będzie miał możliwość dokonania wyboru usługi, realizującego ją personelu, miejsca realizacji oraz ustalenia daty i godziny wizyty, przy wykorzystaniu udostępnionej listy wolnych terminów. W przypadku usług medycznych wymagających podania przez pacjenta dodatkowych informacji (np. dotyczących disi@pomorskie.eu, Strona 185 z 212

186 skierowania lub związanych ze stanem zdrowia czy przebiegiem leczenia) wyświetlane będą odpowiednie formularze do wypełnienia on-line. Listy dostępnych do rezerwacji usług medycznych (zawierające m.in. opis i warunki wykonania usługi, informacje o miejscu realizacji usługi i personelu realizującym usługę) oraz grafiki zawierające wolne terminy wykonania tych usług będą udostępniane przez zaangażowane w projekt PL. Wykonanie rejestracji na usługę będzie potwierdzane odnotowaniem jej w ramach konta pacjenta. Użytkownik może również otrzymać dodatkowe potwierdzenie w formie wiadomości lub SMS. Usługa e-rejestracja będzie także powiadamiać w ten sam sposób pacjentów w innych przypadkach, takich jak zbliżający się termin wizyty, zmiana terminu wizyty i odwołanie terminu wizyty. Informacje dotyczące planowych i odbytych wizyt będą udostępniane użytkownikowi za pośrednictwem konta pacjenta. Z poziomu tego konta pacjent będzie mógł dokonać zmiany zaplanowanej wizyty lub ją odwołać. Interfejs usługi zapewni dostęp do niej możliwie szerokiej grupie użytkowników, włączając w to osoby niepełnosprawne, poprzez realizację standardu WCAG 2.0 zgodnie z obowiązującym Rozporządzeniem Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2016 r. poz. 113). Usługa e-rejestracja będzie dostępna dla użytkowników również w wersji mobilnej. Zakłada się, że możliwość udostępniania przez PL usług do e-rejestracji nie będzie ograniczona tylko do podmiotów zintegrowanych w ramach projektu za pomocą interfejsów. Przewiduje się, że inne PL będą również mogły korzystać z e-usługi. W ich przypadku dostarczanie danych o usługach medycznych i personelu realizującym te usługi, grafikach pracy będzie się odbywało za pośrednictwem dedykowanej aplikacji internetowej udostępnionej na poziomie regionalnym Założenia i koncepcja dla systemu Platformy e-radiologii Teleradiologia będzie usługą umożliwiającą organizację, zarządzanie oraz realizację zdalnej oceny badań obrazowych do celów diagnostycznych oraz konsultacji w ramach sieci urządzeń diagnostyki obrazowej oraz stanowisk opisowych. W ramach funkcjonalności związanych z organizacją usługa będzie oferować: rejestr urządzeń diagnostycznych, rejestr stanowisk opisowych wraz z informacjami na temat zakresu opisywanych badań oraz schorzeń, disi@pomorskie.eu, Strona 186 z 212

187 rejestr umów na świadczenie usług diagnostyki pomiędzy podmiotami. Funkcjonalność związana z zarządzaniem umożliwi kierowanie badań obrazowych do danego stanowiska opisowego z uwzględnieniem: grafików pracy stanowisk opisowych, zakresu realizowanych opisów badań, umów pomiędzy podmiotami, priorytetu realizacji opisu badania, dzięki czemu możliwe będzie zapewnienie wysokiej jakości oceny badań obrazowych w najkrótszym możliwym czasie. Dzięki centralnemu nadzorowi nad grafikami pracy stanowisk opisowych, usługa umożliwi zapewnienie ciągłości działania oceny badań w ramach sieci, również w przypadku wyłączenia poszczególnych stanowisk opisowych. Funkcjonalność będzie również wspierać rozliczenia pomiędzy podmiotami zlecającymi realizację opisów a podmiotami realizującymi opisy badań obrazowych. Funkcjonalność realizacji zdalnej oceny badań obrazowych umożliwi integrację usługi z systemami RIS oraz PACS podmiotów uczestniczących w usłudze przy użyciu formatu DICOM oraz HL7, bezpieczny przesył danych obrazowych oraz opisu badania. Usługa umożliwi również automatyczne składowanie dokumentów z opisem badania w regionalnym repozytorium EDM. Dodatkowo usługa będzie oferować dla niewielkich podmiotów możliwość korzystania z usługi bez konieczności posiadania systemów klasy PACS i RIS : archiwizację danych obrazowych (PACS w chmurze ), możliwość zlecenia opisów badań obrazowych, otrzymanie powiadomienia o zrealizowaniu opisu danego badania oraz możliwość podglądu opisu badania na dedykowanym portalu Założenia i koncepcja dla systemu Obsługi elektronicznych zleceń pomiędzy świadczeniobiorcami Obsługa Elektronicznych Zleceń będzie e-usługą, która umożliwi wymianę zleceń pomiędzy świadczeniodawcami. Zlecenia zazwyczaj dotyczą badań, których dana placówka medyczna nie wykonuje. Zlecenia realizowane są w ramach podpisanych wcześniej między placówkami umów i nie są tożsame ze skierowaniami. Zlecenie może dotyczyć zarówno np. badań laboratoryjnych lub histopatologicznych, gdzie do zewnętrznej pracowni wysyłany jest materiał, jak i badań wysokospecjalistycznych (np. rezonans, tomograf) związanych z przewiezieniem pacjenta do pracowni badań obrazowych. Do zlecenia może być dołączona dokumentacja elektroniczna lub informacje niezbędne do jej pobrania z repozytorium EDM. disi@pomorskie.eu, Strona 187 z 212

188 W ramach e-usługi prowadzony będzie rejestr umów zawartych pomiędzy podmiotami zlecającymi a realizującymi. Umowy te będą odpowiednikami umów papierowych. W ramach każdej umowy zdefiniowana będzie lista usług podlegających zlecaniu. Zlecenie wprowadzane będzie w systemie medycznym podmiotu zlecającego i przekazywane do systemu podmiotu realizującego. Jeśli zlecenie wymaga przekazania materiału do badań, informacja o materiale (rodzaj, numer próbki, opis) zapisywana będzie na zleceniu. Pracownik podmiotu, do którego trafiło zlecenie, zadecyduje o jego przyjęciu lub odrzuceniu. Może zaplanować realizację zlecenia na konkretny termin. W przypadku odrzucenia wprowadzi informację o jego przyczynach. Odpowiednia informacja o podjętej decyzji (zaplanowanym terminie lub przyczynach odrzucenia) wysyłana będzie do systemu podmiotu zlecającego. Jeśli zlecenie obejmuje wiele usług, każda z nich rozpatrywana będzie oddzielnie. Zlecenia przyjęte do realizacji przekazywane będą w systemie podmiotu realizującego do odpowiednich jednostek realizujących (np. zlecenie badania obrazowego przekazywane jest do odpowiedniej pracowni badań obrazowych itp.). Po zrealizowaniu zleconych usług, do podmiotu zlecającego wysyłane będą wyniki. Jednorazowo mogą być wysłane wyniki wielu, ale niekoniecznie wszystkich zleconych usług, ponieważ usługi mogą być realizowane w różnych terminach i przez różne jednostki wewnętrzne podmiotu realizującego. Wynik może być przesłany w postaci tekstowej lub w postaci dokumentu elektronicznego (przesyłany jest dokument z wynikiem lub informacje niezbędne do jego pobrania z repozytorium EDM). Zlecenie może zostać anulowane przez lekarza zlecającego, ale pod warunkiem, że nie rozpoczęła się jego realizacja. Zlecenie może zostać również anulowane przez stronę realizującą już po zaplanowaniu jego realizacji (np. w przypadku zajścia nowych okoliczności uniemożliwiających jego realizację). Proces obsługi zlecenia zakończy się, gdy zlecający odbierze wyniki wszystkich zleconych i nieanulowanych usług. e-usługa zapewni również formalną poprawność przesyłanych zleceń, w szczególności weryfikuje się czy lista zleconych usług jest zgodna z umową zawartą pomiędzy zlecającym a realizatorem Założenia i koncepcja dla systemu Obsługi Nadzoru Właścicielskiego Obsługa nadzoru właścicielskiego to rozwiązanie wspierające procesy związane z monitorowaniem sytuacji podległych podmiotów leczniczych (np. nadzór urzędu marszałkowskiego nad szpitalami wojewódzkimi i innymi podległymi podmiotami leczniczymi), w szczególności sprawozdawczością. disi@pomorskie.eu, Strona 188 z 212

189 e-usługa dostarczy funkcjonalności wspierające pracowników podległych podmiotów w zakresie przekazywania swoich danych do jednostki nadzorującej. Zakres przekazywanych danych wynikać będzie z wymagań sprawozdawczych danego podmiotu nadzorującego i obejmuje przekrojowe dane z takich obszarów jak ruch chorych, rozliczenia NFZ, kolejki oczekujących, finanse, kadry / płace. Wprowadzanie danych będzie odbywać się poprzez dedykowane predefiniowane formularze elektroniczne. Lista formularzy, częstotliwość przekazywania (układ miesięczny, kwartalny, półroczny, roczny), terminy uzupełniania formularzy będą zdefiniowane po stronie e Usługi. Użytkownik wybierze odpowiedni formularz, wprowadzi wartości liczbowe, zatwierdzi dane i przekaże uzupełniony formularz. Rozwiązanie będzie wspierać wprowadzanie danych do formularzy udostępniając funkcjonalność importu danych z plików. Zaimportowane dane będą mogły podlegać dalszej edycji przez użytkownika, aż do momentu ich zatwierdzenia. Uzupełniony przez pracownika jednostki podległej formularz z danymi, podlegać będzie dalszemu procesowaniu - jego dokładny przebieg może być elementem konfiguracji e Usługi wykonywanym jednorazowo, w momencie jego wdrożenia (w tym miejscu określa się, z jakich kroków się składa, w jakiej kolejności będą wykonywane i jakie są pomiędzy nimi zależności). Przykładowa ścieżka procesowania może wyglądać następująco: delegowany do uzupełnienia danych pracownik jednostki podległej uzupełnia formularz, następnie przekazuje go do osoby odpowiedzialnej w danym podmiocie za sprawozdawczość celem jego zatwierdzenia, po jej zatwierdzeniu formularz przekazywany jest do organu nadzorującego. Na każdym etapie będzie możliwość cofnięcia zadania (zwrócenia do korekty) wraz ze stosowanym komentarzem. Z punktu widzenia użytkownika ścieżka procesowania będzie miała postać zadań, które otrzymuje do realizacji (o tym fakcie będzie informowany np. mailowo). Każde zadanie będzie posiadało opis informujący o tym, czego dotyczy. Dostęp do e Usługi będzie możliwy po uwierzytelnieniu i autoryzacji użytkownika, co jest szczególnie ważne ze względu na odpowiedzialność związaną z przekazywanymi danymi - istotna będzie bowiem informacja kto uzupełnił dane w podległym podmiocie, kto je zatwierdził i (opcjonalnie) kto finalnie je zaakceptował po stronie podmiotu nadzorującego. Dane przekazywane przez podległe PL gromadzone będą w rozwiązaniu typu hurtownia danych, skąd udostępniane będą pracownikom organu nadzorującego w postaci predefiniowanych raportów (zestawień). Będzie istniała możliwość eksportu danych do plików w jednym z popularnych formatów (np. XLS). Zgromadzone dane będą również udostępniane do dalszej analizy (m.in. w narzędziu typu BI) w ramach e Usługi Wsparcia Polityki Zdrowotnej. disi@pomorskie.eu, Strona 189 z 212

190 Założenia i koncepcja dla systemu Regionalnego e-rejestru Danych Ratunkowych - RRDR Usługa Rejestr danych ratunkowych będzie służyć do pozyskania i udostępnienia informacji przydatnych dla ratownictwa medycznego. W ramach usługi wydzielono dwa obszary: karta danych ratunkowych, monitoring zasobów medycznych. Karta danych ratunkowych umożliwi akwizycję istotnych z punktu widzenia ratownictwa danych medycznych pacjenta (np. grupa krwi, alergie, choroby przewlekłe) z systemów dziedzinowych podmiotów leczniczych oraz udostępnienie ich w czytelnej i jednoznacznej postaci uprawnionemu personelowi medycznemu, w szczególności w zespołach ratownictwa medycznego oraz szpitalnych oddziałach ratunkowych. Karta danych ratunkowych będzie dostępna w systemie po udzieleniu zgody przez pacjenta na jej udostępnienie. Pacjent będzie posiadał również możliwość wprowadzenia do karty danych ratunkowych własnych adnotacji, np. dotyczących danych sprzed uruchomienia usługi czy np. numerów telefonów ICE (In Case of Emergency). Rejestr danych ratunkowych będzie zawierał również funkcjonalność monitoringu zasobów medycznych w poszczególnych podmiotach istotnych z punktu widzenia ratownictwa medycznego, w szczególności o dostępności: łóżek intensywnego nadzoru na oddziale SOR, sprzętu diagnostycznego (ze względu np. na awarie), sal operacyjnych (ze względu np. na wyłączenia czy odbywające się długotrwałe zabiegi), itd. Raportowanie powyższych danych przez podmioty i ich udostępnienie dyspozytorom medycznym oraz lekarzowi koordynatorowi ratownictwa medycznego będzie miało wpływ na skrócenie czasu decyzji o skierowaniu pacjenta do danego szpitala oraz optymalizacji wykorzystania zasobów medycznych. Rejestr danych ratunkowych dostępny będzie dla uprawnionych użytkowników w postaci dedykowanego portalu. Umożliwiona będzie również integracja z systemami HIS oraz oprogramowaniem wspomagającym pracę dyspozytora medycznego poprzez udostępnienie interfejsu wymiany danych. disi@pomorskie.eu, Strona 190 z 212

191 Założenia i koncepcja dla systemu Wsparcia Polityki Zdrowotnej Będzie to e-usługa udostępniająca zbiór funkcjonalności wspierających w prowadzeniu polityki zdrowotnej w danym regionie. W zależności od przyjętej strategii oraz wyznaczonych w jej ramach zadań rozwiązanie zapewniać będzie wsparcie poprzez dostarczenie analiz pozwalających pozyskać informacje, co do stanu opieki zdrowotnej na podległym obszarze. e Usługa będzie oferować zestaw analiz bazujących na danych z takich obszarów funkcjonowania podległych podmiotów leczniczych jak ruch chorych (informacja o leczonych pacjentach, długościach pobytów, wizytach, badaniach,...), rozliczenia NFZ (dane o wykonanych świadczeniach w ramach kontraktów z NFZ), kolejki oczekujących (na usługi medyczne np. porady specjalistów), finanse (klasyczne sprawozdania roczne takie jak np. bilans), kadry (liczba pracowników) / płace. W zależności od zdefiniowanych na etapie analizy potrzeb informacyjnych odbiorców, odpowiednie zakresy danych będą udostępniane użytkownikom końcowym. e-usługa umożliwi analizowanie danych dostępnych publicznie. Przykładem mogą być dane zawarte w raportach kwartalnych przekazywanych przez NFZ do Wojewody. W tym przypadku użytkownik będzie miał możliwość pozyskania informacji co do stanu opieki zdrowotnej na danym obszarze, w oderwaniu od placówek podległych. Informacje takie dotyczą zazwyczaj ogólnej sytuacji w regionie (np. województwie) i mogą obejmować np. dane o liczbie procedur medycznych wykonanych na oddziałach szpitalnych, liczbie hospitalizacji i osób hospitalizowanych, liczbie hospitalizacji wg trybów przyjęć i wypisów w poszczególnych powiatach, transporcie sanitarnym, ratownictwie medycznym (liczba wyjazdów). Zakłada się, że do wykonywania wszelkiego rodzaju analiz zostanie wykorzystane narzędzie typu BI. Rozwiązanie udostępni zbiór funkcjonalność pozwalających na zapoznanie się oraz śledzenie dynamiki zmian wskaźników obrazujących funkcjonowanie służby zdrowia w danym regionie. Wyliczone wskaźniki dla danego regionu mogą być następnie porównywane z wynikami np. ogólnopolskimi (wprowadzanymi do rozwiązania poprzez dedykowane formularze elektroniczne) lub danymi z innych regionów (o ile takie będą dostępne). Porównywane wskaźniki będą miały charakter ogólny ich zadaniem będzie zobrazowanie stanu zdrowia obywateli zamieszkujących dany obszar (nie będzie ich zadaniem obrazowanie sposobu funkcjonowania podmiotów leczniczych). Dostępne dla użytkownika wskaźniki to np. średnia długości życia (dla mężczyzn i kobiet), umieralność w przypadku chorób układu krążenia, umieralności niemowląt, zapadalności na określone choroby np. gruźlica. W ramach e Usługi e Informacja zakłada się możliwość publikowania materiałów dotyczących promocji zdrowia i profilaktyki zdrowotnej. disi@pomorskie.eu, Strona 191 z 212

192 Założenia i koncepcja dla Wymiany Dokumentacji Medycznej Długoterminowe Archiwa Danych Wymiana dokumentacji medycznej - Długoterminowe Archiwa Danych to e-usługa służąca do gromadzenia i udostępniania informacji o dokumentacji medycznej wytworzonej w podmiotach leczniczych uczestniczących w projekcie, do gromadzenia tej dokumentacji oraz jej udostępniania (bądź wymiany). Rozwiązanie dedykowane będzie przede wszystkim dla dużych podmiotów (głównie szpitali), które posiadają własne, lokalne repozytoria dokumentacji medycznej. Oprócz tego e Usługa umożliwi pacjentom dostęp do informacji o ich dokumentacji medycznej zgromadzonej w podmiotach leczniczych, dostęp do zawartości samych dokumentów oraz pobranie tych dokumentów. Zakłada się, że w przyszłości e-usługa zapewni integrację z systemami centralnymi (np. Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych - P1) w zakresie wymiany Elektronicznej Dokumentacji Medycznej odciążając tym samym zintegrowane z nią PL od konieczności zapewnienia tej integracji we własnym zakresie. Rozwiązanie umożliwi podmiotom leczniczym definiowanie polityki udostępnień dokumentacji medycznej (np. określanie typów dokumentów, które będą udostępniane). Dokumenty zgodne z polityką udostępnień będą automatycznie wysyłane do repozytorium centralnego, pozostając jednocześnie w repozytorium lokalnym danego podmiotu. Do udostępnienia dokumentacji medycznej niezbędna będzie zgoda pacjenta. Zgoda może dotyczyć konkretnego dokumentu, danego podmiotu lub personelu i może być składana przez pacjenta w ramach konta pacjenta dostępnego w systemie regionalnym. W ramach tego samego konta pacjent uzyska dostęp do własnych dokumentów. Będzie mógł przeglądać listę swoich dokumentów, przeglądać zawartość dokumentów elektronicznych oraz pobierać je. Repozytorium centralne umożliwi dostęp do dokumentacji medycznej za pomocą aplikacji internetowej lub za pomocą udostępnionego interfejsu komunikacyjnego, dzięki któremu możliwe będzie pobranie dokumentów do repozytorium lokalnego podmiotu leczniczego. Architektura rozwiązania zgodna będzie z profilem IHE XDS.b bazującym na standardach Web Services i ebxml. Oprócz istnienia repozytoriów lokalnych i repozytorium centralnego, zgodność z profilem zapewni centralny indeks pacjentów, przechowujący dane pacjentów, których dotyczą dokumenty. Same dokumenty będą odpersonalizowane i zawierać będą jedynie identyfikator pacjenta w centralnym indeksie. Takie rozwiązanie zapewni maksymalne bezpieczeństwo disi@pomorskie.eu, Strona 192 z 212

193 dokumentów przechowywanych w repozytorium centralnym. Oprócz samych dokumentów, istnieć będzie centralny indeks pozwalający na szybkie wyszukiwanie dokumentacji. Repozytorium centralne stanowić będzie nie tylko źródło dokumentacji medycznej pacjentów, ale również długoterminowe archiwum EDM. Gromadzona w nim dokumentacja pozostanie tam nawet w przypadku likwidacji podmiotu, który ją wytworzył. Zapewni również dostęp do dokumentacji w przypadku awarii systemu lokalnego czy braku jego dostępności on-line. e-usługa może być zintegrowana z e-usługą: Wymiana dokumentacji medycznej dla podmiotów leczniczych z województwa pomorskiego nie będących uczestnikami projektu. Pacjenci i lekarze uzyskają wówczas dostęp z jednego miejsca nie tylko do dokumentacji pochodzących ze szpitali, ale też z mniejszych podmiotów posiadających tak rozbudowanej infrastruktury sprzętowoprogramowej. Podstawowym standardem zapisu Elektronicznej Dokumentacji Medycznej jest HL7 CDA Wymiana dokumentacji medycznej dla podmiotów leczniczych z województwa pomorskiego nie będących uczestnikami projektu Wymiana dokumentacji medycznej dla podmiotów leczniczych z województwa pomorskiego nie będących uczestnikami projektu w tym repozytoria bieżące i długoterminowe stanowiące katalog EDM (zawierają informacje o miejscu gdzie znajduje się EDM, bez jego przechowywania w niniejszym repozytorium) dla podmiotów leczniczych z województwa pomorskiego nie będących uczestnikami, w szczególności POZ i AOS - będzie to elektroniczna usługa, która umożliwi udostępnianie i wymianę elektronicznej dokumentacji medycznej gromadzonej w lokalnych repozytoriach EDM podmiotów. Usługa będzie dedykowana dla tych podmiotów leczniczych, które nie są uczestnikami projektu PeZ (innymi słowy dla podmiotów, które nie integrują się z e-usługą: Wymiana Dokumentacji Medycznej Długoterminowe Archiwa Danych ). Usługa udostępni zintegrowanym podmiotom centralny rejestr EDM wykorzystywany także przez uczestników Projektu. Zakłada się, że zintegrowane z e-usługą podmioty lecznicze zdefiniują własną politykę udostępnień dokumentacji medycznej (np. określanie typów dokumentów, które będą udostępniane). Metadane dokumentów zgodnych z polityką udostępnień będą automatycznie przekazywane do rejestru centralnego, a same dokumenty pozostaną w repozytorium lokalnym danego podmiotu. Do udostępnienia dokumentacji medycznej niezbędna będzie zgoda pacjenta. Zgoda może dotyczyć konkretnego dokumentu, danego podmiotu lub personelu i może być składana przez pacjenta w ramach konta pacjenta dostępnego w systemie regionalnym. Zakłada się, że w przyszłości e-usługa zapewni integrację z systemami centralnymi (np. Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych - P1) disi@pomorskie.eu, Strona 193 z 212

194 w zakresie wymiany Elektronicznej Dokumentacji Medycznej odciążając tym samym zintegrowane z nią PL od konieczności zapewnienia tej integracji we własnym zakresie. Dokumenty medyczne składowane w lokalnych repozytoriach, których metadane zapisano w centralnym rejestrze, będą mogły podlegać udostępnieniu zarówno innym podmiotom jak i pacjentom. Zakłada się, że pacjent posiadający konto w systemie regionalnym będzie miał dostęp do listy dotyczących go dokumentów oraz będzie mógł pobrać poszczególne dokumenty. Oprócz tego będzie mógł zarządzać udostępnianiem tych dokumentów innym podmiotom zintegrowanym z systemem. Architektura rozwiązania zgodna będzie z profilem IHE XDS.b bazującym na standardach Web Services i ebxml. System lokalny powinien obsługiwać te interfejsy w zakresie udostępniania i pobierania EDM z uwzględnieniem wykorzystania centralnego rejestru pacjentów przy depersonalizacji informacji. e-usługa będzie również wspierać proces wymiany dokumentacji pomiędzy podmiotami leczniczymi a jednostkami usługowymi - np. laboratorium analityczne (o ile posiada odpowiednie repozytorium EDM) będzie mogło udostępniać w ten sposób wyniki badań zamówione przez inny podmiot uczestniczący w projekcie, co może przyśpieszyć proces wymiany informacji i oraz zwiększy jego bezpieczeństwo. 7.9 Koncepcja systemu gromadzenia i archiwizacji danych z poszczególnych systemów informatycznych znajdujących się w PL Założenia dla koncepcji systemu gromadzenia i archiwizacji danych Założeniem systemu gromadzenia i archiwizacji danych jest oznaczenie przez dany podmiot leczniczy zestawu danych wrażliwych dla danej jednostki. Dane wrażliwe obejmują także dane wykraczające poza dokumentację medyczną i są oznaczone jako przeznaczone do archiwizacji z określeniem czasu ich przechowywania w zależności od typu. W zakres danych wrażliwych mogą wchodzić np. dane księgowe, umowy z dostawcami, plany budynków, instrukcje, materiały (w tym wideo) szkoleniowe itp.. Te dane będą stanowiły od 5% do 20% całego wolumenu archiwizowanych dokumentów, którego większością będą dane medyczne. Zgodnie z rozporządzeniami - dokumentację medyczną należy przechowywać: 20 lat licząc od końca roku kalendarzowego w którym dokonano w niej ostatniego wpisu (dla dzieci które nie ukończyły 2 roku życia 22 lata), 30 lat licząc od końca roku kalendarzowego w którym dokonano w niej ostatniego wpisu w przypadku zgonu pacjenta na skutek uszkodzenia ciała lub zatrucia, disi@pomorskie.eu, Strona 194 z 212

195 10 lat dla zdjęć rentgenowskich przechowywanych poza dokumentacją medyczną pacjenta licząc od końca roku kalendarzowego w którym wykonano zdjęcie, 5 lat dla skierowań na badania lub zleceń licząc od końca roku kalendarzowego, w którym udzielono świadczenia będącego przedmiotem skierowania lub zlecenia. W kwestii przyrostu danych, w zależności od rodzaju systemu przewidywany roczny przyrost danych wahać się będzie od 3TB poprzez 10TB aż do 25TB dla każdego z wytypowanych rodzajów systemów. Duże znaczenie ma tu rozwój cyfrowej diagnostyki obrazowej oraz coraz większa jej dostępność, a także dyrektywa unijna o prowadzeniu dokumentacji medycznej w formie elektronicznej. Wskazana jest konieczność migracji danych z obecnych systemów archiwizujących gdyż urządzenia starszych technologii mogą nie spełnić oczekiwać w związku z rosnącymi trendami w medycynie oraz będą dodatkowym kosztem w utrzymaniu i zarządzaniu. Dodatkowo obecnie używane urządzenia nie są wstanie efektywnie adresować wymagań prawnych w obszarze archiwizacji danych medycznych. Dla celów analizy założono, że gromadzone dane przyrastają 400% w okresie pięciu lat. Zgodnie z najlepszymi praktykami należy oddzielić kwestię archiwizacji danych od tworzenia kopii bezpieczeństwa. Dane zarchiwizowane nie podlegają backupowi konstrukcja samego archiwum zabezpiecza dane. Backup natomiast obejmie systemy PL niezbędne dla poprawnego działania jednostki z retencją na poziomie 30 dni. W wypadku awarii zabezpieczanych systemów system kopii bezpieczeństwa będzie służył ich odtworzeniu i w konsekwencji przywróceniu prawidłowej pracy PL do stanu sprzed awarii. Wskazane jest posiadanie dwóch niezależnych systemów adresujących każdy z obszarów. Najważniejsze różnice między archiwizacją a tworzeniem kopii bezpieczeństwa przedstawione są w tabeli poniżej: Kopia bezpieczeństwa (backup) Zapasowa kopia informacji Wykorzystywana do odtwarzania Poprawia dostępność umożliwiając odtworzenie aplikacji do PIT (żądanego punktu w czasie) Krótkoterminowa (tygodnie lub miesiące) Dane są nadpisywane w pewnych cyklach (n.p. miesięcznych) Archiwizacja Podstawowa kopia informacji Służy do odzyskiwania informacji Poprawia wydajność poprzez przeniesienie danych (typu fixed) poza środowisko operacyjne Długoterminowa (lata lub dekady) Dane przechowywane dla potrzeb analiz, postprodukcji lub ze względu na wymogi prawne Nie służy do zapewnienia zgodności z Użyteczna do zapewnienia zgodności z uregulowaniami disi@pomorskie.eu, Strona 195 z 212

196 uregulowaniami ustawowymi ustawowymi i powinna uwzględniać politykę retencji Tabela 17 Definicja kopii bezpieczeństwa i archiwizacji danych Szczegółowe propozycje i koncepcje rozwiązań opisane są w dalszej części dokumentu Ilość danych wraz z prognozami pięcioletniego przyrostu Założono, że z całego wolumenu danych zgromadzonych w PL: 10% z tych danych będzie przechowywanych 5 lat, 70% z tych danych będzie przechowywanych 10 lat, 15% z tych danych będzie przechowywanych 20 lat, 5% z tych danych będzie przechowywanych 30 lat Poniższa tabela pokazuje zgromadzony wolumen danych z podziałem na dane do backupu oraz dane dla systemu archiwizacji. Podziału danych dokonano na podstawie założenia, że 95% zgromadzonych danych to dane systemów medycznych podlegające wymaganiom archiwizacyjnym, a 5% to dane systemów ERP, office itp. podlegające backupowi. Zakłada się, że dane archiwizowane składowane są na zasobach typu ostateczna pamięć masowa, która zawsze gwarantuje możliwość odzyskania danych i zapewnia nienaruszalności danych. Dane zakwalifikowane jako archiwum są wyłączone z procedur backupu. Dla zwymiarowania sprzętu oraz licencji przyjęto okres składowania 5 lat. Należy też przyjąć, że dane z tabeli są obliczane metodą przyrostową bez uwzględnienia logarytmu zwiększania danych. W związku z tym oraz w związku z coraz większym dostępem dysków twardych o pojemności 10TB, dane dla systemów archiwizacji zostaną obliczone za pomocą innych algorytmów. disi@pomorskie.eu, Strona 196 z 212

197 ID PL Nazwa Podmiotu Leczniczego Rodzaj Podmiotu Leczniczego Wolumen składowany obecnie [TB] Kopia bezpiecze ństwa Archiwi zacja 5 lat [TB] 10 lat [TB] 20 lat [TB] 30 lat [TB] Kopia bezpiecze ństwa Archiwi zacja Kopia bezpiecze ństwa Archiwi zacja Kopia bezpiecze ństwa Archiwi zacja Kopia bezpiecze ństwa Archiwi zacja PL 01 Wojewódzki Szpital Psychiatryczny im. prof. Tadeusza Bilikiewicza w Gdańsku Średni(*) 0,25 4, PL 02 Stacja Pogotowia Ratunkowego w Gdańsku Mały 0,25 4, PL 05 Wojewódzki Zespół Reumatologiczny im. dr Jadwigi Titz-Kosko Średni 0,25 4, PL 06 Centrum Zdrowia Psychicznego w Słupsku Mały 0,25 4, PL 07 PL 08 Wojewódzki Szpital Specjalistyczny im. Janusza Korczaka w Słupsku Sp. z o.o. Szpital dla Nerwowo i Psychicznie Chorych im. St. Kryzana w Starogardzie Gdańskim Duży 0,7 13,3 2,8 53,2 5,6 106,4 11,2 212,8 16,8 319,2 Średni 0,5 9, disi@pomorskie.eu, Strona 197 z 212

198 PL 10 PL 11 Wojewódzki Ośrodek Terapii Uzależnień w Gdańsku Mały 0,25 4, Stacja Pogotowia Ratunkowego w Słupsku Mały 0,25 4, PL COPERNICUS PL Sp. z o.o. były COPERNICUS Podmiot Leczniczy Sp. z o.o. byłe Wojewódzkie Centrum Onkologii w Gdańsku Sp. z o. o. Duży 2,65 50,35 10,6 201,4 21,2 402,8 42,4 805,6 63,6 1208,4 Duży 1,8 34,2 7,2 136,8 14,4 273,6 28,8 547,2 43,2 820,8 PL 14 Szpital Dziecięcy Polanki im. Macieja Płażyńskiego w Gdańsku Sp. z o.o. Średni 0,5 9, PL 16 PL 17 PL 18 Szpital Specjalistyczny w Prabutach Sp. z o.o. Średni 0,5 9, Przemysłowy Zespół Opieki Zdrowotnej sp. z o.o. Mały 0,25 4, Szpital Specjalistyczny w Kościerzynie Sp. z o.o. Duży 0,85 16,15 3,4 64,6 6,8 129,2 13,6 258,4 20,4 387,6 PL Szpitale Wojewódzkie w Szpitale Wojewódzkie w Duży 2,1 39,9 8,4 159,6 16,8 319,2 33,6 638,4 50,4 957,6 disi@pomorskie.eu, Strona 198 z 212

199 19. 2 Gdyni Sp. z o.o Gdyni Sp. z o.o Pomorskie Centrum Chorób Zakaźnych i Gruźlicy Sp. z o.o. Szpital Specjalistyczny im. F. Ceynowy sp. z o.o. Średni(*) 0,25 4, Duży 0,75 14, Główny System Archiwizacji znajdujący się w GCPD 13,45 255,55 53,8 1022,2 107,6 2044,4 215,2 4088,8 322,8 6133,2 (*) PL zakwalifikowano do wyższej kategorii ze względu na potencjał rozwojowy. Tabela 18 Wolumen danych w podmiotach leczniczych z podziałem na backup i archiwizację disi@pomorskie.eu, Strona 199 z 212

200 Ze względu na różny wolumen składowanych danych założono podział jednostek na 3 typy Podmiotów Leczniczych. Podział ten ma na celu unifikację sprzętu oraz metod archiwizacji i backupu dla każdego typu jednostki. Podziału dokonano w oparciu o następujące kryteria: małe PL podmioty, w których sumaryczny wolumen zgromadzonych danych jest mniejszy niż 5 TB, średnie PL podmioty, w których sumaryczny wolumen zgromadzonych danych jest większy niż 5 TB, ale mniejszy niż 100 TB, duże PL podmioty, w których sumaryczny wolumen zgromadzonych danych jest większy niż 100 TB, Główny System Archiwizacji znajdujący się w GCPD - punkt, w którym gromadzi się dane z wszystkich PL w celu ich dodatkowego zabezpieczenia na wypadek awarii. Proponowane wyposażenie podmiotów klasy A: dwie macierze dla bazy danych i systemów wirtualnych tzw. macierz szybka (po jednej na serwerownię) o pojemności minimum 47TB dla dysków SAS w RAID6 (w tym 4TB SSD), minimum dwa kontrolery FC/iSCSI, macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 200TB dla dysków SATA/NLSAS w RAID6, minimum dwa porty 10GE dla połączeń iscsi - macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM, urządzenie do backupu danych. Proponowane wyposażenie podmiotów klasy B: dwie macierze w klastrze synchronicznym dla bazy danych i systemów wirtualnych tzw. macierz szybka o pojemności minimum. 43TB (PL 16 21TB) dla dysków SAS w RAID6, minimum dwa kontrolery po dwa porty SAS podłączone bezpośrednio do serwerów, macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 200TB dla dysków SATA/NLSAS w RAID6, minimum dwa kontrolery po dwa porty SAS i/lub porty 10GE dla połączeń iscsi Macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM lub szyfrowanie danych będzie dostępne poprzez odrębny serwer. Dane EDM będą replikowane poprzez serwer replikacyjny do archiwum EDM na platformie regionalnej. urządzenie do backupu danych. disi@pomorskie.eu, Strona 200 z 212

201 Proponowane wyposażenie podmiotów klasy C: dwie macierze w klastrze synchronicznym dla bazy danych i systemów wirtualnych tzw. macierz szybka o pojemności minimum 21TB dla dysków SAS w RAID6, minimum dwa kontrolery FC/iSCSI macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 100TB dla dysków SATA/NLSAS w RAID6, minimum dwa kontrolery po dwa porty SAS i/lub porty 10GE dla połączeń iscsi. Macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM lub szyfrowanie danych będzie dostępne poprzez odrębny serwer. Dane EDM będą replikowane poprzez serwer replikacyjny do archiwum EDM na platformie regionalnej. urządzenie do backupu danych, Proponowane wyposażenie podmiotów klasy D: macierz dla bazy danych i systemów wirtualnych tzw. macierz szybka o pojemności minimum. 4TB dla dysków SAS w RAID6, minimum dwa kontrolery FC/iSCSI, macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 18TB dla dysków SATA/NLSAS w RAID6, minimum dwa porty 10GE dla połączeń iscsi Macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM lub szyfrowanie danych będzie dostępne poprzez odrębny serwer. Dane EDM będą replikowane poprzez serwer replikacyjny do archiwum EDM na platformie regionalnej. urządzenie do backupu danych. Proponowane wyposażenie podmiotów klasy E: obszar centralnego systemu danych w ilości po 20TB na każdy PL klasy E. Proponowane wyposażenie GCPD: GCPD i DR wyposażone w synchroniczną macierz dla bazy danych i systemów wirtualnych tzw. macierz szybka o pojemności minimum. 200TB dla dysków SAS w RAID6, minimum cztery kontrolery po dwa porty 16/32G FC - replikacja danych macierzy pomiędzy GCPD a DR będzie następowała poprzez mechanizmy metro-cluster a zapis danych będzie podlegał deduplikacji, GCPD i DR Macierz dla danych EDM, archiwum i danych backupu, tzw. macierz wolna o pojemności minimum 4PB dla dysków SATA/NLSAS w RAID6, minimum cztery porty 10GE dla połączeń iscsi disi@pomorskie.eu, Strona 201 z 212

202 Macierz będzie posiadała mechanizm szyfrowania dysków półek twardych dla EDM. Macierz będzie połączona w klastrze asynchronicznym pomiędzy GCPD/DR. Pojemność 4PB może zostać złożona np. z czterech macierzy NAS po 1PB. System dostępu do przestrzeni na macierzach powinien indeksować dane oraz mieć możliwość rozszerzenia macierzy o rozwiązania chmury danych. urządzenie do backupu danych Funkcjonalności systemu gromadzenia i archiwizacji danych dla PL Podział i rozróżnienie wolumenu na dane do backupu oraz archiwizacji danych jest kluczowy ponieważ inne technologie stosuje się do przetwarzania każdego rodzaju ww. danych, same zaś dane mają różne formaty oraz różną podatność na technologię kompresji i deduplikacji. Dane archiwizowane są wyłączone z backupu. Poniżej zostały przytoczone cechy systemu archiwizacji długookresowej danych, w dokumencie dalej określany jako System Archiwizujący. dostęp do danych online bez konieczności dodatkowego oczekiwania użytkownika na odtworzenie danych z nośników off-line (np. taśm magnetycznych), zapewnienie niezaprzeczalności wybranych danych w archiwum zgodnie z polityką przyjętą w standardzie np. Sec-17a4, możliwość zmiany poziomu zabezpieczenia wybranych danych przez administratora bez konieczności restartu macierzy lub ręcznej migracji danych, dynamiczne rozszerzanie pojemności systemu plików bez konieczności: modyfikacji już zainstalowanych kontrolerów, restartu systemu oraz ręcznej migracji/dystrybucji danych na nowe dyski systemu, urządzenie będzie wspierało rozbudowę systemu plików lub wymianę jego komponentów na nowsze (dyski, kontrolery) bez wpływu na dostępność danych - w przypadku rozszerzeń systemu o kolejne węzły lub półki system powinien automatycznie balansować dane w puli dostępnej pamięci, urządzenie będzie odporne na awarię jednego z wykorzystanych węzłów lub półek dyskowych, bez utraty spójności danych zapewniając do nich stały dostęp, urządzenie zapewni możliwość zmiany na żądanie bez konieczności restartu systemu sposobu zabezpieczenia przed awarią dysków lub kontrolera dla wybranych danych (plików, folderów, grup folderów) bez konieczności ich migracji oraz musi umożliwiać zapis na żądanie wybranych przez administratora danych w kilku kopiach (tzw. mirroring), system archiwizujący będzie całkowicie dostępny (on-line) w przypadku awarii pojedynczego punktu w systemie (dysk, półka, zasilacz, kontroler), disi@pomorskie.eu, Strona 202 z 212

203 system archiwizujący będzie dostępny (on-line) i wszystkie dane w pełni dostępne w przypadku awarii, która ma wpływ na minimalnie jeden kontroler lub co najmniej dwa dyski w systemie. system będzie miał możliwość skalowania pojemności zachowując pełny dostęp do danych i bez konieczności ich migracji. system archiwizujący będzie miał możliwość load balancing połączeń zgodnie z wybraną przez administratora polityką rozkładu obciążenia, bez stosowania dodatkowej aplikacji na stacji klienckiej lub zewnętrznych urządzeń równoważących obciążenie, system archiwizujący będzie łączyć się do wszystkich sieci klientów bez konieczności instalowania jakiegokolwiek oprogramowania na stacjach klienckich, urządzenie będzie pozwalać na tworzenie różnych udziałów logicznych dla wybranych użytkowników pozwalających na dostęp tylko do wybranych zasobów za pomocą protokołów SMB/CIFS lub NFS, urządzenie będzie obsługiwać jednoczesne uwierzytelnianie użytkowników do urządzenia i dedykowanych udziałów logicznych za pomocą systemów: NIS, LDAP, urządzenie umożliwi podział na logiczne części umożliwiający bezpieczną dystrybucje zasobów używających jednocześnie kilku rodzajów autentykacji takich jak: usługi katalogowe, LDAP, NIS, system pamięci masowej umożliwi eksport wybranych przez administratora danych na zewnętrzny system biblioteki taśmowej lub VTL (wirtualna biblioteka taśmowa) za pomocą standardu NDMP po portach min 10GE, system pamięci masowej umożliwi rozbudowę o moduł backupu na bibliotekę taśmową lub VTL (wirtualną bibliotekę taśmową) protokołem NDMP przy użyciu portów FC, rozwiązanie zapewni możliwość backup oraz odtwarzania plików przy pomocy protokołu NDMP bez używania serwera dedykowanego Funkcjonalności systemu kopii zapasowych (backupu) Poniżej zostały przedstawione cechy systemu kopii zapasowych dalej nazywane systemem backupu. pojedyncze rozwiązanie dla Data Center / baz danych / środowisk wirtualnych / zdalnych oddziałów / laptopów użytkowników z nielimitowaną liczbą agentów do plików/baz danych i maszyn wirtualnych, system zapewni automatyzację wszystkich zadań backupowych w oparciu o zdefiniowane na serwerze harmonogramy zadań, system zapewni przechowywanie wszystkich zdeduplikowanych kopii zapasowych na własnych dyskach, system będzie działał z globalną deduplikacją danych, deduplikacja realizowana będzie blokiem o zmiennej długości, disi@pomorskie.eu, Strona 203 z 212

204 system kopii zapasowych będzie miał możliwość asynchronicznej replikacji danych do innego urządzenia tego samego typu - replikacja będzie mogła odbywać się w każdym z kierunków. Najważniejsze założenia systemu kopii bezpieczeństwa: system kopii bezpieczeństwa będzie przechowywał 30 ostatnich pełnych backupów (okres retencji = 30 dni), będzie przechowywał jedynie unikalne bloki danych będzie oparty na technologii deduplikacji, będzie posiadał nieograniczoną liczbę agentów systemu backup, pozostawi pełną autonomie PL w zakresie systemów objętych kopiami bezpieczeństwa Dla PL które zostały zakwalifikowane jako Mały Podmiot Leczniczy Jak zostało powiedziane na wstępie inne technologie zostaną zastosowane do backupu i archiwizacji danych dla każdego typu jednostek. Dla jednostek zakwalifikowanych jako małe PL, ze względu na brak infrastruktury informatycznej oraz niewielki wolumen danych wszystkie komponenty środowiska archiwizująco-backupującego zostaną zainstalowane w lokalizacji oznaczonej jako GCPD, ewentualnie dla podniesienia dostępności do danych w tzw. 3 lokalizacji System Archiwizacji Zaproponowane rozwiązanie będzie działać na zasadzie współdzielonej pamięci masowej tzw. Storage archiwizującego typ 1 umieszczonej w GCPD/DR. Systemy medyczne będzie składowały dane na zasadzie zapisu do udostępnych im udziałów sieciowych iscsi. Poszczególni użytkownicy lub poszczególne PL będą zapisywały swoje dane na to samo urządzenie archiwizujące ale zasoby będą od siebie wzajemnie odseparowane logicznie. Ta sama pamięć masowa będzie współużytkowana przez wszystkie jednostki oznaczone jako Mały Podmiot Leczniczy ale dane każdej z jednostek będą wzajemnie od siebie odseparowane. System archiwizujący dla tych jednostek został zaprojektowany jako ostateczna pamięć masowa, która zawsze gwarantuje możliwość dostępu do danych i zapewnia ich nienaruszalność. Niezależnie od zabezpieczenia samych archiwizowanych danych na pamięci masowej wszystkie dane będą replikowane do centralnego urządzenia archiwizującego umieszczonego w GCPD ( typ 4 ). Replikacja będzie się odbywała poprzez sieć ethernet na podstawie oddzielnych harmonogramów zadań przystosowanych indywidualnie dla każdej z jednostki. W przypadku niedostępności danych z macierzy typ 1 możliwy będzie dostęp do tych danych z jej kopii w GCPD na macierzy typ 4 lub wdrożenie procedury odwrócenia replikacji i odzyskania utraconych danych z jej repliki. disi@pomorskie.eu, Strona 204 z 212

205 Systemy archiwizujące można łatwo integrować z istniejącymi infrastrukturami i można z nich bezproblemowo korzystać przy użyciu różnych aplikacji do obsługi tworzenia kopii zapasowych i archiwizacji. Integracja systemu archiwizującego nie wymaga wprowadzania żadnych zmian do procesu lub infrastruktury. Ponadto użytkownicy mogą wykorzystać system archiwizującego jako miejsce docelowe dla narzędzi ochrony aplikacji. Z uwagi na to, że system archiwizujący zapewnia jednoczesną obsługę wielu metod dostępu, w tym NFS, CIFS, NDMP, ze wszystkich aplikacji i narzędzi można będzie korzystać w jednym systemie w tym samym czasie. Dzięki temu zwiększy się konsolidacja zabezpieczającej pamięci masowej. System będzie widoczny dla użytkowników aplikacji jako serwer plików zapewniający dostęp z użyciem protokołów NFS i CIFS w sieci Ethernet, jako serwer taśm NDMP lub jako dyskowe miejsce docelowe przy użyciu interfejsów specyficznych. Wymagania: urządzenie składująco-archiwizujące Storage archiwizujący typ1 umieszczony w GCPD lub 3 lokalizacji zawierający: o licencję na replikację, o licencję iscsi, o mechanizmy odporności danych na awarię dysków, kontrolerów, węzła. Zalety rozwiązania: brak lokalnego urządzenia składującego dane (ewentualne rezygnacja jeżeli są zasoby na dyskach USB), obsługa wielu metod dostępu do urządzenia Storage archiwizujący przez iscsi, NDMP, możliwość długookresowego zabezpieczenia przechowywanych danych kopii zapasowych i zapewnienie zgodności z wewnętrznymi zasadami dotyczącymi nadzoru oraz z przepisami prawa w zakresie archiwizowania danych, replikacja danych do zdalnej lokalizacji zabezpiecza na wypadek awarii urządzenia, możliwość zdalnej administracji urządzeniem co ogranicza potrzebę posiadania wykfalifikowanego personelu w danej lokalizacji i redukuje koszty, brak wrażliwości na łącze przy dostępie do archiwum, dane dostępne online, w przypadku awarii repozytorium lokalnego możliwość odtworzenia danych z GCPD, możliwość kopiowania danych na taśmy przy pomocy modułów NDMP System kopii zapasowych - backupu Analogicznie jak w przypadku archiwizacji danych nie przewiduje się instalacji urządzeń backupowych w lokalizacjach określonych jako Mały Podmiot Leczniczy. Dane z systemów znajdujących się disi@pomorskie.eu, Strona 205 z 212

206 w Małych Podmiotach Leczniczych zakwalifikowane jako dane do backupu będą zapisywane za pomocą agenta backupu na współdzieloną platformę (appliance) znajdującą się w lokalizacji 3. Każdy z PL będzie mógł zapisać maksymalnie do 6TB danych źródłowych i zdefiniować dla nich 30 dniową retencję. Dla podniesienia bezpieczeństwa dane na platformie (appliance) znajdujące się w lokalizacji 3 będą replikowane do GCPD. W procesie backupu zabezpieczane będą wszystkie dane zawsze powstaje pełny backup. Jednak dzięki globalnej deduplikacji na źródle przesyłane będą tylko te informacje (fragmenty plików), które pojawią się od czasu wykonania ostatniej kopii zapasowej. W efekcie transferowi podlegać będzie jedynie ułamek promila zabezpieczanego wolumenu. Jednocześnie dzięki technice lokalnych cache y na kliencie proces nie będzie wrażliwy na złą jakość łącza. Sesje backupowe nie będą przerywane w sytuacji, kiedy zabraknie połączenia lub użytkownik wyłączy lub uśpi komputer, przerwana sesja backupu zostanie wznowiona po ponownym nawiązaniu połączenia z serwerem centralnym. Połączenie nawiązywane będzie automatycznie. Przed wysłaniem dane będą pakietowane, szyfrowane i wysyłane na serwer centralny. Dzięki deduplikacji System backupu prześle bardzo małe porcje danych i nie obciąży łącz. Dodatkowo, możliwe będzie ustawienie w konfiguracji poziom wysycenia łącza, którego System backupu nie będzie mógł przekroczyć. Te cechy oraz możliwość indywidualnego dostosowywania poszczególnych klientów do jakości łącza sprawią, że system backupu nadawać się będzie do realizacji zadań backupu poprzez WAN. Koncepcja systemu kopii zapasowych zakłada również aby instalacja agenta backup mogła być powiązana z zadaniami zdefiniowanymi w ramach usług katalogowych i mogła odbywać się automatycznie w czasie logowania użytkowników do np. usługi katalogowe. Dodatkowo nie powinno być konieczności tworzenia oddzielnych kont dla użytkowników. Poprzez integrację z usługi katalogowe użytkownicy powinni mieć możliwość logowania się do konsoli odtwarzania danych na swoich użytkowników systemowych. Dodatkowo administrator powinien mieć możliwość odtwarzanie wszystkich danych na rożne miejsca (nie koniecznie docelowe). Wymagania: software Systemu backupu klient umożliwiający backup z globalna deduplikacją na urządzenie (appliance), dedykowane Urządzenie backupowe zlokalizowane w lokalizacji 3, zapewniona przestrzeń (50TB) na urządzeniu backupowym w GCPD na potrzeby realizacji replikacji. Zalety rozwiązania: disi@pomorskie.eu, Strona 206 z 212

207 brak lokalnego systemu kopii zapasowych, darmowy klient System backupu (w cenie System backupu z GCPD), deduplikacja danych na kliencie ogranicza wykorzystanie sieci LAN/WAN, możliwość zdalnego backupu oraz odtwarzania danych w oryginalne lub alternatywne miejsce. Rysunek 7-8: Schemat archiwizacji w Lokalizacji 1 (Małe PL) Dla PL które zostały zakwalifikowane do klasy średnich i dużych - A, B, C i D System Archiwizacji Dane objęte archiwizacją z systemów znajdujących się w PL klasy A, B, C i D będą zapisywane na lokalnym zasobie dyskowym posiadającym cechy wysokiej skalowalności, możliwie najtańszym koszcie pojedynczego TB danych oraz łatwej migracji na nowszą platformę w wypadku konieczności odświeżenia technologii sprzętowej. Z racji wolumenu danych generowanych przez PL niezbędna będzie lokalna instancja archiwum. Dla zapewnienia bezpieczeństwa archiwum lokalne będzie replikowane do Głównego Systemu Archiwizacji znajdującego się w GCPD. Na potrzeby odseparowania danych o różnym stopniu wrażliwości będzie możliwy podział zasobu dyskowego na niezależne części logiczne z autonomiczną kontrolą dostępu w ramach użytkowników i systemów funkcjonujących w PL. disi@pomorskie.eu, Strona 207 z 212

208 Wymagania: urządzenie składująco-archiwizujące Storage archiwizujący zawierający: o licencję na replikację, o licencję iscsi, CIFS i NFS, o mechanizmy odporności danych na awarię dysków, kontrolerów, węzła. Zalety rozwiązania: lokalny dostęp do danych na urządzenia archiwizujących, obsługa wielu metod dostępu do urządzenia Storage archiwizujący przez iscsi, NFS, CIFS, NDMP, możliwość długookresowego zabezpieczenia przechowywanych danych kopii zapasowych i zapewnienie zgodności z wewnętrznymi zasadami dotyczącymi nadzoru oraz z przepisami prawa w zakresie archiwizowania danych, replikacja danych do zdalnej lokalizacji w GCPD zabezpiecza na wypadek awarii urządzenia, możliwość zdalnej administracji urządzeniem co ogranicza potrzebę posiadania wykfalifikowanego personelu w danej lokalizacji i redukuje koszty, brak wrażliwości na łącze przy dostępie do archiwum, w przypadku awarii repozytorium lokalnego możliwość odtworzenia danych z GCPD, możliwość kopiowania danych na taśmy przy pomocy modułów NDMP. Rysunek 7-9. Schemat systemu archiwizacji i backupu w podmiotach klasy A, B,C i D disi@pomorskie.eu, Strona 208 z 212