Małopolski System Informacji Medycznej projekt pilotażowy

Załącznik nr 9 Dotyczy przetargu nieograniczonego na zamówienie pn.:stworzenie oraz kompletne wdrożenie Małopolskiego Systemu Informacji Medycznej - projekt pilotażowy, w ramach Małopolskiego Regionalnego Programu Operacyjnego na lata 2007 2013 (399/ZP/2014). Opis przedmiotu zamówienia (OPZ) Małopolski System Informacji Medycznej projekt pilotażowy

1. Wstęp... 4 2. Wymagania podstawowe do realizacji Systemu MSIM... 5 2.1. Założenia projektowe... 5 2.2. Ogólne wymagania jakie powinien spełniad system MSIM... 11 2.3. Koncepcja wykonania i dostawy, instalacji, konfiguracji, wdrożenia, uruchomienia oraz integracji systemu MSIM... 15 2.4. Dyslokacja elementów systemu... 18 2.5. Zasady budowy reguł interoperacyjności w systemie... 19 2.6. Koncepcja synchronizacji czasu normalizacji czasu... 19 2.7. Koncepcja autentykacji i identyfikacji użytkowników... 20 2.8. Koncepcja współpracy z Internetowym Kontem Pacjenta (IKP)... 21 2.9. Koncepcja przesyłania dokumentacji o dużej pojemności... 22 2.10. Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych jednostek... 23 2.11. Schemat połączeo pomiędzy elementami systemu... 23 2.12. Interfejsy komunikacyjne z innymi systemami informatycznymi... 27 2.13. Koncepcja komunikacji pomiędzy jednostkami... 28 2.14. Koncepcja przesyłu danych pomiędzy jednostkami... 30 2.15. Integracja systemów oraz danych z innych systemów do wdrażanego systemu MSIM... 31 2.16. Koncepcja wirtualizacji zasobów informatycznych... 31 3. Analiza stanu aktualnego... 31 3.1. Infrastruktura informatyczna... 31 3.2. Infrastruktura sieciowa... 39 3.3. Łącza internetowe... 41 3.4. Procedury bezpieczeostwa... 42 3.5. Oprogramowanie dziedzinowe... 43 3.6. Rodzaje przetwarzanych danych... 45 3.7. Gwarancja i serwis... 47 3.8. Lokalne słowniki dokumentów... 48 4. Model statyczny... 49 4.1. Komponent lokalny... 49 4.2. Komponent regionalny... 50 4.3. Interfejsy... 54 5. Model dynamiczny... 55 5.1. Wprowadzenie... 55 5.2. Metoda opisu... 55 5.3. Mapa główna procesów biznesowych... 57 5.4. Przekazywanie EDM... 58 5.5. e-rejestracja... 65 6. Wymagania Systemu MSIM... 71 6.1. Wymagania ogólne... 71 6.2. Wymagania ogólne interfejsu użytkownika... 72 6.3. Wymagania prawne, organizacyjne i funkcjonalne... 72 6.4. Wymagania wydajnościowe systemu... 78 6.5. Wymagania skalowalności... 78 6.6. Wymagania wolumenu przetwarzanych danych... 78 6.7. Wymagania niezawodności... 78 6.8. Wymagania bezpieczeostwa... 79 6.9. Ochrona danych osobowych... 80 6.10. Wymagania systemu zarządzania tożsamością... 81 6.11. Procedury nadawania/zmiany/odbierania uprawnieo... 82 6.12. Repozytorium EDM... 83 6.13. Usługa e-rejestracja... 84 6.14. Wymagania warstwy integracji... 90 7. Infrastruktura... 91 Strona 2 z 161

7.1. Infrastruktura serwerowa... 99 7.2. Komunikacja... 112 7.3. Bezpieczeostwo... 120 7.4. Pozostałe elementy... 129 7.5. Oprogramowanie systemowe... 132 8. Platforma danych... 139 8.1. Metadane dla źródeł danych... 139 8.2. Model biznesowy platformy danych... 140 9. Metodyka wdrożenia Systemu... 141 9.1. Dokumentacja... 141 9.2. Szkolenia... 145 9.3. Odbiór... 151 9.4. Eksploatacja... 153 10. Gwarancja oraz wsparcie... 155 10.1. Gwarancja... Błąd! Nie zdefiniowano zakładki. 10.2. Wsparcie... Błąd! Nie zdefiniowano zakładki. 11. Licencjonowanie... 161 Strona 3 z 161

1. Wstęp Przedmiotem zamówienia jest stworzenie oraz kompletne wdrożenie jednolitej zintegrowanej platformy wymiany danych Medycznych i udostępnienie elektronicznych usług medycznych w skali regionu. Założeniem projektu MSIM (Małopolski System Informacji Medycznej) projekt pilotażowy jest stworzenie regionalnego systemu informacji medycznej narzędzia informatycznego pozwalającego na wymianę dokumentacji medycznej pomiędzy podmiotami leczniczymi w województwie małopolskim. Projekt planowany jest do realizacji jako indywidualny projekt kluczowy Małopolskiego Regionalnego Programu Operacyjnego na lata 2007-2013 i umieszczony jest w Indykatywnym Wykazie Indywidualnych Projektów Kluczowych Małopolskiego Regionalnego Programu Operacyjnego na lata 2007-2013. W projekcie bierze udział Urząd Marszałkowski oraz jako partnerzy 3podmioty lecznicze z terenu województwa małopolskiego: Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu, Szpital Specjalistyczny im. J. Dietla w Krakowie, Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Przedmiotem niniejszego zamówienia jest: 1. Dostawa dokumentacji, 2. Przygotowanie koncepcji wdrożenia, 3. Dostawa licencji, 4. Dostawa oprogramowania wytwarzanego na potrzeby Zamówienia, 5. Dostawa oprogramowania standardowego oraz systemowego, 6. Dostawa, instalacja, integracja i konfiguracja infrastruktury sprzętowej oraz programowej, 7. Szkolenia oraz instruktarze stanowiskowe, 8. Gwarancja. Szczegółowe wymagania dla powyższych produktów zdefiniowane zostały w kolejnych rozdziałach. Strona 4 z 161

2. Wymagania podstawowe do realizacji Systemu MSIM 2.1. Założenia projektowe 2.1.1. Warstwy MSIM System MSIM ma zapewniać rozdzielność warstwy regionalnej i warstwy lokalnej. Planowane rozwiązanie nie pozwala na bezpośredni dostęp do systemów dziedzinowych Szpitali z poziomu warstwy regionalnej. Warstwa regionalna Warstwa lokalna HIS LIS RIS PACS. Rysunek 1. Separacja dostępu do systemów dziedzinowych (źródłowych). Wymiana Elektronicznej Dokumentacji Medycznej jest realizowana dwustronnie na osi Warstwa lokalna Warstwa regionalna oraz HIS Warstwa lokalna. Z kolei e-rejestracja jest zasilana za pośrednictwem WebService ów i może się komunikować z HIS w zakresie wymiany grafików, terminów, informacji o kolejkach oczekujących. Pozostałe systemy dziedzinowe takie jak LIS, RIS, PACS nie są integrowane z warstwą lokalną (ew. pośrednio poprzez HIS). Integracja systemami LIS, RIS i PACS jest poza zakresem zamówienia. W zakres zamówienia wchodzi integracja z interfejsami do systemów HIS opracowanymi przez wykonawców tych systemów (wyciąg z umów jest załączony do SIWZ. Pod względem architektury rozwiązania cały system wymiany dokumentów i danych medycznych jest podzielony na część regionalną, w której funkcjonować będą elementy systemu odpowiadające za interoperacyjność rozwiązania oraz część lokalną, działającą w poszczególnych jednostkach medycznych wchodzących w skład domeny. Dokumentacja medyczna jest gromadzona w EDM, które są elementem dostawy w warstwie lokalnej, natomiast warstwa regionalna zawiera jedynie jej indeks. W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji pacjentów, pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą metadane wszystkich dokumentów). Ustalany jest też schemat i zasady identyfikacji obiektów powstających w systemie oraz ich wersjonowaniem. Strona 5 z 161

W poszczególnych szpitalach zostaną utworzone Lokalne Repozytoria EDM, które pozwalać będą na gromadzenie, przechowywanie i przesyłanie zgodnie z przepisami (Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia oraz Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania) dokumentacji medycznej. Integracja warstwy regionalnej i lokalnej powinna odbywać się za pomocą usług sieciowych w oparciu o regionalną szynę danych. W szpitalach będzie konieczne wykonanie integracji z WebSerwisami dostawców HIS wykonanymi w ramach odrębnego zlecenia. Warstwa regionalna MSIM Regionalna Szyna Usług Warstwa lokalna MSIM Integracja z WebSerwisami dostawców HIS HIS Rysunek 2. Metody integracji w MSIM. Zamawiający jednocześnie nie określa sposobu wewnętrznej wymiany danych w ramach dostarczanych w ramach zamówienia modułów (tj. w przypadku, gdy oprogramowanie Wykonawcy będzie miało jakąś wewnętrzną strukturę to nie określa sposobu wymiany danych w ramach oferowanego oprogramowania). Strona 6 z 161

2.1.2. Wymiana EDM W zakresie wymiany EDM rozwiązanie przewiduje podział funkcjonalny na warstwę lokalną i warstwę regionalną według poniższych wytycznych. Rejestr dokumentów EDM (warstwa regionalna MSIM) EDM (warstwa lokalna MSIM) Adapter komunikacyjny (warstwa lokalna MSIM) Interfejs z HIS HIS Rysunek 3. Wymiana danych w zakresie EDM. Warstwa lokalna gdzie będzie wdrożony moduł odpowiedzialny za wytwarzanie, gromadzenie i przesyłanie EDM oraz usługi towarzyszące pozwalające na integrację z węzłem regionalnym. W warstwie lokalnej będzie gromadzona EDM zgodna z Załącznikiem9A Standard wymiany danych pomiędzy HIS i MSIM, zgodnie zobowiązującymi przepisami. Za pomocą odpowiednich usług i serwisów informacja o wytworzeniu dokumentacji medycznej będzie przesyłana do warstwy regionalnej, gdzie zostanie utworzony indeks z podstawowymi informacjami dotyczącymi tego dokumentu. Pozwoli to na poziomie regionalnym przechowywać scentralizowane informacje o miejscu składowania i fakcie wytworzenia wraz z informacją o wersjonowaniu wszystkich dokumentów medycznych w podmiotach biorących udział w Projekcie. Wiarygodność EDM będzie wymagała poświadczenia przy użyciu mechanizmów zaimplementowanych w systemie. Za pomocą odpowiednich interfejsów uwierzytelniony Użytkownik będzie mógł odpytać warstwę regionalną o dokumenty w innych jednostkach oraz pobrać je w całości lub częściowo. Dostęp do dokumentacji będzie autoryzowany, co oznacza, że użytkownik będzie mógł otrzymać dokumenty, do których ma prawo. W poszczególnych szpitalach uczestniczących zostaną wdrożone i wykorzystane repozytoria lokalne, których głównym zadaniem będzie przyjmowanie i przechowywanie zgodnie z przepisami wskazanymi w dalszej części dokumentów medycznych z systemów dziedzinowych (HIS, LIS, RIS lub innych) funkcjonujących w szpitalach. Warstwa regionalna gdzie wdrożony będzie rejestr EDM, który zawiera rejestr dokumentów czyli tzw. indeks EDM znajdującej się we wszystkich lokalnych repozytoriach EDM. W przypadku konieczności pobrania przez lekarza pełnej dokumentacji medycznej pacjenta z konkretnego pobytu/wizyty wymaga się możliwość jej zamówienia/pobrania jedynie w trzech wariantach możliwych do wybrania przez Użytkownika: Strona 7 z 161

Podstawowa dokumentacja medyczna (m. in. dokumentacja zewnętrzna: karta informacyjna, karta porady specjalistycznej, karta informacyjna SOR). Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza objętość). Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość) Wymagane rozwiązanie zapewni w przypadku konieczności zapoznania się z bardziej szczegółową dokumentacją pobranie jej w komplecie dla danego pobytu, przez co gwarantuje się analizę danych diagnostycznych i z procesu leczenia w kontekście całego pobytu. Eliminuje to zagrożenie opierania się podczas decyzji leczniczych na pobranym dokumencie (np. z danymi diagnostyki laboratoryjnej) bez kontekstu procesu leczenia wdrożonego podczas danego pobytu. W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji pacjentów, pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą metadane wszystkich dokumentów). W warstwie regionalnej będzie realizowana większość usług (np. wyszukiwanie, przeglądanie, pobieranie, przekazywanie do innych podmiotów). Rozwiązanie takie minimalizuje warunki techniczne potrzebne w warstwie lokalnej do sprawnego funkcjonowania systemu wszelkie zapytania od strony klientów obsługiwane są wyłącznie z wykorzystaniem warstwy regionalnej. Przedmiotem zamówienia w ramach MSIM jest: warstwa regionalna (rejestr EDM), EDM w warstwie lokalnej, adapter komunikacyjny. Pozostałe elementy wymiany EDM są realizowane w toku umów z dostawcami HIS. Strona 8 z 161

2.1.3. E-Rejestracja Szczególną usługą realizowaną w ramach komponentu regionalnego jest usługa e-rejestracji. Usługa e-rejestracji udostępnia funkcjonalność rezerwacji usług medycznych w jednostkach ochrony zdrowia zintegrowanych z MSIM. e-rejestracja MSIM (warstwa regionalna MSIM) e-rejestracja partnera (poza MSIM) HIS Rysunek 4. Wymiana danych w ramach e-rejestracji. Użytkownik ma możliwość rejestracji na wskazany termin i anulowania wizyty. Z e-rejestracji mogą korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi (pacjenci). W ramach usługi powinien funkcjonować system komunikatów (powiadomień dla użytkowników końcowych w formie np. wiadomości e-mail i SMS) dotyczących: potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno przez użytkownika jak i w lokalnym systemie medycznym HIS). W szczególności usługa obejmuje następujące funkcjonalności: Przegląd listy usług możliwych do realizacji w placówce Zamawiającego dla pacjenta. Przegląd listy usług możliwych do rezerwacji przez Internet. Możliwość rezerwacji terminu usługi do wybranej poradni lub wybranego lekarza. Określenie celu wizyty u lekarza, z podziałem na: przypadek nagły incydentalny, stan nagły przy chorobie przewlekłej, wizytę kontrolną, wizytę po kolejną receptę, wizytę po skierowanie na badanie specjalistyczne. Udostępnienie danych o zaplanowanych wizytach i usługach. Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana). Możliwość wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko pacjenta, numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla pacjenta. Dostęp do informacji o lokalizacji miejsca wykonania usługi. Możliwość odwołania rezerwacji. Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail). Zamówieniem objęta jest: Strona 9 z 161

e-rejestracja na poziomie regionalnym integrująca jednostki w ramach MSIM, dostarczenie, zainstalowanie i skonfigurowanie serwera e-mail na potrzeby powiadomień MSM. Współpraca z dostawcami HIS i dostarczenie interfejsów jest poza zamówieniem (realizowana w toku odrębnych umów). Poza zamówieniem jest również dostarczenie bramki SMS. Poza tą rejestracją mogą występować inne moduły e-rejestracji na poziomie poszczególnych partnerów, jednak o ile zostanie utrzymana decyzja o ich eksploatacji. Zamawiający nie wymaga przeprowadzania integracji pomiędzy e-rejestracją na poziomie regionalnym, a ewentualnymi rejestracjami lokalnymi. 2.1.4. Podstawowe standardy wykonania MSIM Głównym celem proponowanego rozwiązania jest usprawnienie zarządzania i podniesienie jakości procesów leczniczych w podmiotach leczniczych objętych systemem, poprzez rozbudowę i rozszerzenie stanu istniejącego przedstawionego w analizie stanu obecnego. Rozbudowa ma na celu bezpieczne i zgodne z prawem wytwarzanie, przechowywanie, oraz przekazywanie dokumentów medycznych pomiędzy jednostkami oraz integrację z tworzoną na szczeblu krajowym Elektroniczną Platformą Gromadzenia Informacji O Zdarzeniach Medycznych (projekt P1). W celu zapewnienia dalszej łatwej rozbudowy oraz integracji z nowymi systemami wymaga się, aby system w jak największym stopniu oparty był o obowiązujące w tej dziedzinie na świecie standardy i dobre praktyki. Najszerzej przyjętym w chwili obecnej standardem dotyczącym przekazywania dokumentacji pomiędzy szpitalami jest profil XDS.b proponowany przez międzynarodową organizację IHE Wykonawca powinien dostarczać WebSerwis y umożliwiające zewnętrzną wymianę danych zgodnie z profilem XDS.b, jakkolwiek nie jest wymagane, aby Wykonawca korzystał z tego standardu w komunikacji w ramach komunikacji pomiędzy dostarczanymi komponentami MSIM. Profil ten opisuje procesy i komunikaty jakie muszą zostać wymienione pomiędzy dwoma jednostkami, aby nastąpiło poprawne przekazanie dokumentu medycznego. Standard wspierany jest obecnie przez większość głównych dostawców oprogramowania medycznego na świecie. Sam układ dokumentu medycznego powinien być zdefiniowany w języku XML, w oparciu o najszerzej przyjęty na świecie format dokumentu opracowany przez organizację HL7 CDAR2 na 3- cim poziomie interoperacyjności (w zakresie, gdy to jest możliwe w pozostałych wypadkach należy stosować poziom 2-gi i 1-szy w szczególności dla zeskanowanych dokumentów dopuszcza się 1-szy poziom interoperacyjności). HL7 CDAR2 na trzecim poziomie interoperacyjności zostało także zaproponowane jako podstawowy format dokumentów medycznych na poziomie krajowym przez Centrum Systemów Informatycznych w Ochronie Zdrowia. Na etapie Analizy Przedwdrożeniowej uwzględniona zostanie kwestia dostosowania/ujednolicenia istniejących słowników, formatów danych i standardów danych słownikowych w celu wykonania poprawnej integracji/wymiany danych pomiędzy systemami dziedzinowymi zlokalizowanymi w warstwach lokalnych, a warstwą regionalną. Pod względem architektury rozwiązania cały system wymiany dokumentów i danych medycznych podzielony powinien być na część regionalną, w której funkcjonować będą elementy systemu odpowiadające za interoperacyjność rozwiązania oraz część lokalną, działającą w poszczególnych jednostkach medycznych. Warstwa regionalna może być posadowiona w lokalizacji jednego z uczestników projektu. W przyszłości planuje się rozwój systemu co najmniej w następujących aspektach: Podłączanie nowych jednostek do systemu. Rozszerzanie zakresu wymienianych danych zarówno w aspekcie dodatkowych danych do obecnie wymienianych dokumentów, jak i podłączania nowych systemów dziedzinowych. Strona 10 z 161

Rozszerzanie funkcjonalności poprzez podłączanie dodatkowych modułów. 2.2. Ogólne wymagania jakie powinien spełniać system MSIM 2.2.1. Główne założeniasystemu MSIM Integracja systemów informatycznych (HIS, RIS, LIS, PACS, innych) jednostek medycznych. Wymagane jest udostępnienie interfejsów pozwalających w przyszłości na integrację z systemami partnerów (tj. sama integracja jest poza zakresem zamówienia). Wyjątkiem są systemy HIS, gdzie integracja jest zapewniona przez umowy będące załącznikiem do SIWZ. Integracja ta musi pozwalać systemom dziedzinowym na zasilenie lokalnych EDM dokumentami medycznymi wytworzonymi przez te systemy funkcjonujące w jednostkach medycznych z Repozytorium Elektronicznej Dokumentacji Medycznej. W warstwie lokalnej (jednostkach medycznych) zaimplementowany zostanie moduł gromadzenia danych odbierający dokumentację medyczną wytwarzaną w systemach dziedzinowych funkcjonujących w jednostce. W warstwie regionalnej wdrożona zostanie platforma integrująca odpowiedzialna za komunikację pomiędzy jednostkami medycznymi oraz udostępnianie, przesłanie do zamawiającego (pacjenta, jednostki medycznej) dokumentacji medycznej gromadzonej w ramach systemów dziedzinowych tych jednostek. Ponadto niezbędna będzie integracja warstwy regionalnej z Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (P1)) w szczególności w zakresie IKPw zakresie zgodnym z aktualną dokumentacją projektu P1. System udostępniania dokumentacji medycznej Wymagane jest dostarczenie infrastruktury sprzętowej i programowej oraz wdrożenie usługi pozwalającej na udostępnianie w jednostkach medycznych (warstwa lokalna systemu MSIM) w jednym miejscu (moduł wymiany danych) dokumentacji medycznej z różnych systemów dziedzinowychfunkcjonujących w tych jednostkach(ewentualna wymiana danych z systemami RIS. LIS, PACS i innych będzie się odbywać za pośrednictwem HIS).. Rozwiązanie będzie zbudowane w architekturze rozproszonej moduł wymiany zostanie zaimplementowany w każdej jednostce medycznej uczestniczącej w projekcie (w szczególności może być zrealizowany przez lokalny EDM dostarczony w ramach projektu). Szczególowa koncepcja mumodułu w zostanie określona na etapie Analizy przedwdrożeniowej. Komunikacja pomiędzy modułami,a także dostęp do dokumentacji medycznej będzie realizowany za pomocą usług uruchomionych na platformie integującej w warstwie regionalnej systemu MSIM. Wdrożenie platformy integrującej wymianę elektronicznej dokumentacji medycznej na poziomie regionalnym Wymaga się stworzenia platformy integrującej (warstwa regionalna systemu MSIM) z wykorzystaniem technologii szyny danych oraz interfejsów integracyjnych, która zapewni komunikację i wymianę dokumentacji medycznej pomiędzy jednostkami medycznymi w regionie a także umożliwi dostęp do dokumentacji dla pacjenta. W ramach tego elementu ma zostać zrealizowane dostarczenie infrastruktury sprzętowej i programowej oraz wdrożenie usług umożliwiających wyszukiwanie, prezentację oraz wymianę/udostępnianie dokumentacji medycznej. Platforma ta zostanie zintegrowana z projektem P1 w zakresie indeksowania Strona 11 z 161

i udostępniania dokumentacji medycznej zamawianej przez pacjenta za pomocą IKP. Wymiana dokumentacji medycznej w ramach platformy integracyjnej będzie realizowana zgodne z przyjętymi standardowymi protokołami w ochronie zdrowia (HL7 CDA R2 na poziomie 3-cim interoperacyjności, DICOM, XML i PDF zgodne z Rozporządzeniem Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania) w zakresie przekazywanym do lokalnych EDM przez systemy HIS. Wdrożenie elektronicznych usług medycznych Zakłada się uruchomienie elektronicznych usług dostępnych w warstwie regionalnej systemu MSIM: 1. Wyszukiwanie dokumentacji medycznej pacjenta: Usługa dostępna dla personelu medycznego będzie umożliwiać wyszukanie dokumentacji pacjenta wg określonych kryteriów takich jak dane pacjenta, rodzaju usługi medycznej, data czy jednostka medyczna. Wynik wyszukiwania będzie miał postać listy z możliwością jej pogrupowanej wg określonych kryteriów takich jak jednostka medyczna, rodzaj usługi medycznej czy data wykonania usługi. 2. Wymiana oraz udostępnianie dokumentacji medycznej pomiędzy jednostkami medycznymi: Usługa dostępna dla personelu medycznego będzie umożliwiać pobranie dokumentacji medycznej pacjenta zgromadzonej w jednostkach medycznych uczestniczących w projekcie. Zakres wymienianych danych pomiędzy jednostkami może być różny i zależy od specjalizacji danej jednostki, a także od zasobu dokumentacji gromadzonej w jej systemach dziedzinowych. Dokumentacja będzie pobierana z listy uzyskanej w procesie wyszukiwania. W przypadku konieczności pobrania pełnej dokumentacji medycznej pacjenta z konkretnego pobytu/wizyty wymaga się możliwość jej zamówienia/pobrania jedynie w trzech wariantach możliwych do wybrania przez Użytkownika: Podstawowa dokumentacja medyczna (m. in. dokumentacja zewnętrzna: karta informacyjna, karta porady specjalistycznej, karta informacyjna SOR). Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza objętość). Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość) 3. Udostępnianie dokumentacji medycznej pacjentowi (w tym wyników badań): Usługa będzie umożliwiać pobranie przez pacjenta dokumentacji medycznej zgromadzonej w jednostkach medycznych uczestniczących w projekcie. W ramach wdrożenia usługi zostanie wykonana integracja z Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (projekt P1) w zakresie Internetowego Konta Pacjenta (IKP), funkcjonującego w ramach platformy P1, dzięki któremu pacjent będzie miał możliwość zamawiania dokumentacji medycznej. Wskazana przez pacjenta dokumentacja będzie udostępniana z poziomu systemu MSIM. Integracja z IKP będzie obejmować zestawienie szyfrowanego połączenia pozwalającego na udostępnianie/przesyłanie EDM, którą zamówił pacjent (w IKP pacjent powinien otrzymać informację o sposobie udostępnienia dokumentacji, np. link do udostępnionej dokumentacji znajdującej się w EDM w warstwie lokalnej MSIM). Strona 12 z 161

W ramach usługi realizowany będzie scenariusz: o o o o pacjent przy użyciu IKP wyszukuje w wykazie interesującą go dokumentację medyczną, za pomocą usługi dostępnej w IKP pacjent zamawia interesująca go dokumentację medyczną, System MSIM obsługuje żądanie we właściwy sposób, umożliwiając przesył dokumentacji medycznej, pacjent pobiera zamówioną dokumentację medyczną. 4. Elektroniczna rejestracja pacjentów (e-rejestracja) Szczególną usługą realizowaną w ramach komponentu regionalnego jest usługa e-rejestracji. Usługa e-rejestracji udostępnia funkcjonalność rezerwacji usług medycznych w jednostkach ochrony zdrowia zintegrowanych z MSIM. Użytkownik ma możliwość rejestracji na wskazany termin i anulowania wizyty. Z e-rejestracji mogą korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi (pacjenci). W ramach usługi powinien funkcjonować system komunikatów (powiadomień dla użytkowników końcowych w formie np. wiadomości e-mail i SMS) dotyczących: potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno przez użytkownika jak i w lokalnym systemie medycznym HIS). W szczególności usługa obejmuje następujące funkcjonalności: Rejestrację terminu wizyty Anulowanie terminu wizyty Przeglądanie terminów (przyszłych aktywnych, przyszłych zarejestrowanych, przyszłych anulowanych i historycznych) Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail) 5. Portal Informacyjny e-zdrowie. Portal będzie miał postać aplikacji webowej prezentującej informację o projekcie, świadczonych usługach, uczestniczących partnerach. Na portalu będą udostępniane: Informacje o jednostkach ochrony zdrowia, które są zintegrowane z MSIM w ramach projektu (w tym lista usług świadczony przez te podmioty), Wyszukiwarka usług medycznych (wg typu usługi oraz wg jednostki ochrony zdrowia), Dane kontaktowe do jednostek ochrony zdrowia (tel. do placówki, poszczególnych specjalistów, informacji, rejestracji Informacje nt. możliwości skorzystania z e-rejestracji (wraz z krótkim instruktażem jak z korzystać z rozwiązania na portalu oraz charakterystyka e-usługi FAQ), Funkcjonalność umożliwiająca rejestrację oraz założenie konta, Informacje o projekcie MSIM. Ponadto w ramach wdrożenia systemu MSIM dostępne będą: Mobilna wersja portalu informacyjnego e-zdrowie. Strona 13 z 161

Usługa podpisu elektronicznego dla EDM. UsługapodpisuelektronicznegodlaEDMbędzieobsługiwaćfunkcjepodpisywania i weryfikacji podpisu elektronicznego z wykorzystaniem Centrum Autoryzacji (CAPE w Małopolsce). Centrum CAPE będzie wykorzystywane w zakresie: a.) wydawania certyfikatów elektronicznych do podpisywania (przyjmowanie wniosku o certyfikat w postaci pliku PKCS#10 i udostępnianie wygenerowanego certyfikatu) b.) znakowania czasem (usługa znakowania czasem zgodna ze standardem RFC 3161. Usługa Single Sign-On (SSO) spełniająca następujące wymagania: a.) System powinien zapewnić funkcjonalność pojedynczego uwierzytelniania użytkowników w obrębie dostarczanej platformy oraz dostarczanych aplikacji dziedzinowych b.) System powinien zapewnić interfejs API umożliwiający podłączenie do systemu SSO zewnętrznych aplikacji dziedzinowych. Prace integracyjne po stronie zewnętrznych aplikacji dziedzinowych nie są objęte niniejszym postępowaniem c.) Uwierzytelnianie użytkowników musi być realizowane na podstawie jednoznacznie przydzielonego loginu oraz hasła użytkownika. Serwer mailowy na potrzeby powiadomień MSIM Wszystkie realizowane przez System MSIM usługi elektroniczne będą dostępne przy pomocy dedykowanych interfejsów dostępu jako API dla systemów informatycznych jak iw trybie graficznym dla użytkowników portalu. Zapewnienie interoperacyjności Rozwiązanie ma opierać się założenie przekazywania pomiędzy podmiotami elektronicznej dokumentacji medycznej w ustandaryzowanym formacie możliwym do odczytania w dowolnej lokalizacji. Elementem odpowiedzialnym za przekazywanie dokumentacji medycznej wraz z zapewnieniem prawidłowego uwierzytelnienia użytkowników będzie warstwa regionalna, co uniezależnia rozwiązanie od poszczególnych podmiotów. Rozwiązanie takie pozwala na wzajemny dostęp uprawnionych użytkowników z wszystkich podmiotów dołączonych do MSIM do wszystkich wytwarzanych w formie elektronicznej dokumentów medycznych dostępnych w ramach MSIM. W celu zapewnienia bezpieczeństwa przesyłu danych zakłada się zestawienie bezpiecznego, bezpośredniego i szyfrowanego połączenia pomiędzy jednostkami medycznymi. Połączenie VPN będzie charakteryzować się dużą efektywnością oraz zapewni wysoki poziom bezpieczeństwa. 2.2.2. Wymagania ogólne dla systemu MSIM 1. System MSIM ma umożliwić wymianę EDM pomiędzy jednostkami ochrony zdrowia zintegrowanymi z MSIM. 2. System MSIM ma umożliwić wymianę dokumentacji medycznej w ramach e-usług pomiędzy jednostkami ochrony zdrowia zintegrowanymi z MSIM. 3. Wymiana dokumentacji medycznej ma być realizowana z wykorzystaniem technologii szyny danych oraz interfejsów integracyjnych. Strona 14 z 161

4. System MSIM musi być przygotowany na integrację z lokalnymi systemami dziedzinowymi w ramach interfejsów zgodnych ze standardem opisanym w Załączniku 9A.: 5. Zakres wymienianych danych pomiędzy jednostkami może być różny i zależy od możliwości systemów dziedzinowych danej jednostki ochrony zdrowia. 6. Podłączenie nowej jednostki ochrony zdrowa do MSIM nie może wymagać od dostawcy systemu dziedzinowego dla danej jednostki ochrony zdrowia żadnej specyficznej wiedzy (np. z zakresu kryptografii) poza umiejętnością implementacji webservices zgodnie z dokumentacją protokołu wymiany danych. 7. Wymiana informacji w ramach sieci pomiędzy jednostkami ochrony zdrowa z wykorzystaniem MSIM, realizującej e-usługi ma wykorzystywać interfejsy wymiany danych zgodne z przyjętymi standardowymi protokołami w ochronie zdrowia (m. in. HL7 CDA R2 na poziomie interoperacyjności 3-cim, DICOM, XML i PDF zgodne z Rozporządzeniem Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania). W przypadku konieczności standardowe protokoły mogą zostać rozbudowane o dodatkowe elementy, nie występujące w w/w protokołach. 2.3. Koncepcja wykonania i dostawy, instalacji, konfiguracji, wdrożenia, uruchomienia oraz integracji systemu MSIM Wdrożenie należy rozumieć jako szereg uporządkowanych i zorganizowanych działań mających na celu wykonanie opisanego w OPZ Systemu MSIM. Wdrożenie będzie realizowane w ramach powołanych do tego celu struktur organizacyjnych po stronie Zamawiającego oraz Wykonawcy. Wykonawca ponosi odpowiedzialność za swoich pracowników i szkody przez nich poczynione w lokalizacjach instalacji infrastruktury sprzętowej. W ramach dokumentu Plan Wdrożenia Projektu zostaną przez Wykonawcę przygotowane informacje na temat struktury organizacyjnej zarządzania projektem, w tym muszą zostać powołane minimum następujące role w projekcie: 1. Kierownik Projektu ze strony Zamawiającego, 2. Kierownik Projektu ze strony Wykonawcy, 3. Zespół realizacyjny po stronie Wykonawcy. W ramach struktury organizacyjnej procesu wdrożenia musi zostać również powołany Komitet Sterujący minimum w składzie: 1. Przewodniczący przedstawiciel Zamawiającego, 2. Główny Dostawca przedstawiciel Wykonawcy, 3. Główny Odbiorca przedstawiciel Zamawiającego. Każda z tych ról ma prawo powołać swoich specjalistów dziedzinowych odpowiadających za operacyjną realizację projektu. Szczegółowe zadania i kompetencje Komitetu Sterującego zostaną szczegółowo opisane w Planie Wdrożenia Projektu. W ramach procesu Wdrożenia zaplanowano, iż nastąpią po sobie chronologicznie następujące działania: 1 Przygotowanie Analizy przedwdrożeniowej Systemu MSIM Pierwszym zadaniem do wykonania w ramach procesu wdrożenia jest opracowanie przez Wykonawcę w porozumieniu z Zamawiającym Analizy przedwdrożeniowej MSIM. Dokument ten stanowić będzie bazowy zapis opisujący budowany System MSIM. Na podstawie zapisów w tym dokumencie będą prowadzone i odbierane poszczególne zadania realizowane przy budowie Systemu MSIM. Strona 15 z 161

Dokument ten wraz z SIWZ będą stanowiły podstawę do weryfikacji funkcjonalnej i jakościowej Systemu MSIM w trakcie odbiorów. 2 Dostawa instalacja i konfiguracja infrastruktury Sieciowej Dostawa instalacja i konfiguracja infrastruktury sieciowej jest zadaniem mającym na celu budowę lub modernizację pasywnego sprzętu sieciowego oraz dostawę, instalację i konfigurację aktywnego sprzętu sieciowego do wskazanych lokalizacji według przygotowanego przez Wykonawcę wspólnie z Zamawiającym harmonogramu w porozumieniu z Partnerami Projektu. Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to z bieżącą pracą Partnerów Projektu. Harmonogram musi być przedstawiony jako diagram Gantta, który obejmuje zadania wraz z ich następnikami, datę rozpoczęcia, datę zakończenia zadania, czas trwania (liczony w dniach roboczych), podmiot odpowiedzialny za realizację zadania, % postęp w realizacji zadania. Wymagania w zakresie organizacji prac instalacyjnych: a) Wykonawca będzie dostarczał pasywny sprzęt sieciowy sukcesywnie w ilości niezbędnej do prowadzenia prac instalacyjnych zgodnie z harmonogramem. b) Wykonawca będzie dostarczał aktywny sprzętu sieciowego sukcesywnie w terminie bezpośrednio poprzedzającym jego instalację i w sposób dopasowany do możliwości logistycznych zamawiającego i Partnerów Projektu. Zakres i wielkości dostaw należy każdorazowo uzgodnić z Zamawiającym. c) Za przechowywanie narzędzi i materiałów (w tym pasywnego i aktywnego sprzętu sieciowego) w miejscu instalacji odpowiada Wykonawca. Wykonawca zobowiązany jest zagwarantować przechowywanie materiałów zgodnie z wymaganiami producenta. d) Za sprzęt sieciowy zapewniany w ramach realizacji przedmiotu zamówienia do czasu podpisania protokołu odbioru odpowiada Wykonawca. 3 Dostawa instalacja i konfiguracja infrastruktury sprzętowej Dostawa instalacja i konfiguracja infrastruktury sprzętowej jest zadaniem mającym na celu dostarczenie zamawianego sprzętu do wskazanych lokalizacji według przygotowanego przez Wykonawcę wspólnie z Zamawiającym harmonogramu w porozumieniu z Partnerami Projektu. Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to z bieżącą pracą Partnerów Projektu. Wymagania w zakresie logistyki dostaw: a) Wykonawca ma zapewnić wniesienie dostarczonego sprzętu do miejsca (pomieszczenia) u Partnera Projektu oraz w lokalizacji warstwy regionalnej MSIM. b) Wykonawca będzie dostarczał sprzęt sukcesywnie w terminie bezpośrednio poprzedzającym jego instalację i w sposób dopasowany do możliwości logistycznych zamawiającego i Partnerów Projektu. Zakres i wielkości dostaw należy każdorazowo uzgodnić z Zamawiającym. c) Za przechowywanie narzędzi i materiałów (w tym infrastruktury sprzętowej) w miejscu instalacji odpowiada Wykonawca. Wykonawca zobowiązany jest zagwarantować przechowywanie materiałów zgodnie z wymaganiami producenta. Strona 16 z 161

d) Za infrastrukturę sprzętową zapewnianą w ramach realizacji przedmiotu zamówienia do czasu podpisania protokołu odbioru odpowiada Wykonawca. 4 Dostawa, instalacja i konfiguracja Oprogramowania systemowego i narzędziowego W ramach zadania dostawy, instalacji oraz konfiguracji Oprogramowania systemowego i narzędziowego Wykonawca ma dokonać instalacji i konfiguracji wymaganego oprogramowania systemowego i narzędziowego na dostarczonym uprzednio sprzęcie. Dostawa i instalacja ma być wykonana we wskazanych lokalizacjach zgodnie z Planem Wdrożenia Projektu. Po zakończeniu instalacji, zainstalowane oprogramowanie musi zostać skonfigurowane tak aby działało poprawnie zgodnie z jego przeznaczeniem i wymaganą architekturą rozwiązania Systemu MSIM oraz oferowało funkcjonalność opisaną w SIWZ, a także zapewniać prawidłową pracę Oprogramowania aplikacyjnego. 5 Dostawa, instalacja i konfiguracja Oprogramowania aplikacyjnego W ramach zadania dostawy instalacji i konfiguracji oprogramowania aplikacyjnego Wykonawca ma dokonać instalacji i konfigurację zamawianego oprogramowania aplikacyjnego. Dostawa instalacja i konfiguracja ma być wykonana we wskazanych lokalizacjach oraz zgodnie z Planem Wdrożenia Projektu. Po zakończeniu prac instalacyjnych oprogramowanie musi zostać skonfigurowane tak aby oferowało funkcjonalność opisaną w SIWZ oraz zgodnie z wymaganą architekturą rozwiązania Systemu MSIM. 6 Integracja MSIM z Partnerami Projektu i Podmiotami leczniczymi Zadania te polegają na integracji wskazanych jednostek ochrony zdrowia w ramach Systemu MSIM, zgodnie z wymaganą architekturą rozwiązania systemu MSIM oraz określonymi elementami warstwy integracji Systemu MSIM. Głównym celem integracji jest uruchomienie e- Usług w zakresie synchronizacji i wymiany danych pomiędzy warstwą regionalną MSIM, a warstwami lokalnymi Partnerów Projektu. 7 Testy Celem przeprowadzenia testów jest weryfikacja przez Zamawiającego, czy wszystkie prace wykonane w trakcie budowania Systemu MSIM zostały wykonane prawidłowo i zgodnie z założeniami funkcjonalnymi i jakościowymi. Testy będą przeprowadzane zarówno przez pracowników Partnerów Projektów jak i wskazanych przez Zamawiającego osób i podmiotów zewnętrznych. W celu przeprowadzenia testów Wykonawca przygotuje kompletne środowisko testowe oraz scenariusze testowe. Pozytywne zakończenie testów wraz z usunięciem wskazanych wad jest niezbędne aby dla poszczególnych komponentów oraz Systemu MSIM dokonać odbiorów w ramach poszczególnych etapów oraz odbioru końcowego. 8 Odbiór końcowy Zadanie to ma na celu potwierdzenie wykonanie wszystkich zadań wynikających z Projektu, w tym odebrania wszystkich Komponentów i etapów Projektu oraz dostarczenia wszystkich wymaganych w zamówieniu dokumentów. Dokonanie odbioru końcowego zakończy prace przy budowie Systemu MSIM i będzie podstawą do przekazania Systemu MSIM do użytkowania produkcyjnego. Strona 17 z 161

Wykonawca ma przekazać protokoły odbioru końcowego z rozpisaniem na składowe będące elementami całego systemu MSIM w uzgodnieniu z Zamawiającym. 2.4. Dyslokacja elementów systemu Lista lokalizacji, w których należy zainstalować elementy systemu 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w Krakowie 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o.(gdzie zlokalizowane są dwie serwerownie do których dostarczona zostanie infrastruktura zamawiana w ramach MSIM) Ponadto Projekt musi umożliwiać przyłączenie do niego w dalszym okresie kolejnych jednostek ochrony zdrowia. Zgodnie z podziałem funkcjonalnym System składa się z komponentu regionalnego oraz komponentu lokalnego. Komponent lokalny umieszony zostanie w następujących lokalizacjach: 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w Krakowie 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Komponent regionalny umieszony zostanie w lokalizacji: 1. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Lista lokalizacji jest aktualna na dzień 6.10.2014. Strona 18 z 161

Cała komunikacja mająca na celu przekazanie dokumentacji ze Szpitala występującego o dokumentację do szpitala udostępniającego dokumentację jest realizowana za pośrednictwem warstwy regionalnej MSIM. Rysunek 5. Koncepcja komunikacji w MSIM. 2.5. Zasady budowy reguł interoperacyjności w systemie Zakres i znaczenie metadanych EDM oraz schematów atomowych dla repozytorium EDM i rejestru EDM powinien być zgodny z wytycznymi profilu integracyjnego XDS.b, a w szczególności z tabelą 4.3.1.1-3 dokumentu IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross- Transaction and Content Specifications (dostępny na stronie: http://www.ihe.net/uploadedfiles/documents/iti/ihe_iti_tf_vol3.pdf). Nie ma potrzeby tworzenia formularzy elektronicznych w zakresie przekazywania EDM, ponieważ odbywa się ona w całości z wykorzystaniem usług sieciowych i interakcji pomiędzy systemami. 2.6. Koncepcja synchronizacji czasu normalizacji czasu Synchronizacja i znakowanie czasem elektronicznej dokumentacji medycznej następuje w oparciu o usługę znakowania czasem (TSS Time Stamping Service). Usługa znakowania czasem powinna być świadczona centralnie, co w przypadku systemu MSIM oznacza, że usługa będzie świadczona przez komponent regionalny rozwiązania, jako jedna ze wspólnych usług infrastrukturalnych. Strona 19 z 161

Algorytm znakowania czasem powinien być oparty o przesyłanie skrótów dokumentów do usługi (serwera znakowania czasem) i znakowaniu wyłącznie skrótów dokumentów. Architektura takiego rozwiązania implikuje w warstwie regionalnej istnienie 2 usług infrastrukturalnych: Usługa znakowania czasem Usługa weryfikacji znaku czasu System powinien wykorzystywać usługę znacznika czasu realizowaną przez Centrum Autoryzacji (CAPE w Małopolsce)), przez zastosowanie funkcjonującej obecnie w Centrum aplikacji PentaSCAPE- TSA Service. Aktualna wydajność usługi powinna być wystarczająca do planowej skali systemu. Certyfikaty, listy CRL oraz inne dane przechowywane przez Centrum Certyfikacji znakowane są wiarygodnym czasem pochodzącym z wzorcowego zaufanego serwera czasu. Usługa znakowania czasem musi posiadać wydajność na poziomie oferowanym przez CAPE w Małopolsce. 2.7. Koncepcja autentykacji i identyfikacji użytkowników Identyfikacja, uwierzytelnianie i autoryzacja użytkowników (osób oraz systemów) powinna być oparta o mechanizm scentralizowany, który logicznie wydziela 2 warstwy: Identity provider (dostawca tożsamości) pełniący funkcję weryfikującą funkcja powinna być dostępna z poziomu komponentu regionalnego jak wspólna usługa infrastrukturalna. Klientów usługi, którzy potrzebuję rzetelnej i aktualnej informacji o tożsamości uczestników komunikacji funkcja ta będzie wykorzystywana głównie przez komponent lokalny. Rozwiązanie powinno być oparte o jeden wspólny serwer certyfikacyjny, każdy użytkownik będzie miał klucz/token weryfikowany przez serwer certyfikacji. Zakłada się wykorzystanie działającego Centrum Autoryzacji podpisu elektronicznego w ramach Urzędu Marszałkowskiego(CAPE w Małopolsce). Usługa uwierzytelniania powinna być oparta o mechanizm jednokrotnego logowania (ang. Single Sign On SSO) w obrębie aplikacji wytworzonych w ramach projektu. W ramach MSIM powstanie usługa pozwalająca poszczególnym HIS-om wykorzystanie tego mechanizmu w ramach poszczególnych instalacji. Kwestia zaimplementowania SSO w ramach poszczególnych HIS jest elementem odrębnego zamówienia udzielonego wykonawcom HIS. Na potrzeby usługi e-rejestracja wymagane będzie utworzenie niezależnego repozytorium tożsamości dla Pacjentów, którzy będą chcieli korzystać z funkcjonalności rezerwowania wizyt w placówce medycznej. Konta tych pacjentów a w konsekwencji ich dane osobowe muszą być zabezpieczone mechanizmami odpowiadającymi poziomowi wysokiemu zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych W celu zapewnienia bezpieczeństwa danych osobowych dla potwierdzenia rejestracji wymagana będzie wizyta w placówce z wydrukowanym formularzem rejestracji celem potwierdzenia danych osobowych i otrzymania hasła pierwszego logowania. Strona 20 z 161

2.8. Koncepcja współpracy z Internetowym Kontem Pacjenta (IKP) W celu zapewnienia wymiany informacji pomiędzy usługodawcami, a platformą P1 zostały wybrane standardy komunikacji, które sprawią, że proces ten będzie mógł przebiegać w sposób zunifikowany. Z uwagi na interoperacyjność oraz wytyczne CSIOZ 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.b - 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. Platforma P1 wykorzystuje również standard: HL7 CDA R2 na 3-cim poziomie interoperacyjności- w zakresie transferu nie obrazowych danych medycznych, DICOM w zakresie gromadzenia i przekazywania informacji o miejscu przechowywania danych obrazowych. 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 (webservices) zostanie wykorzystany standard WSDL (wersja co najmniej 1.1). Każdy dokument wysyłany do platformy P1 będzie podlegał regułom walidacyjnym przypisanym do konkretnego dokumentu. Reguły walidacyjne przypisane do dokumentu nadrzędnego mają zastosowanie do obiektów powiązanych podrzędnych. System zapewni możliwość zabezpieczania wysyłanych komunikatów zgodnie ze specyfikacją WS Security (OASIS Standard 1.1) oraz wykorzystania modelu X.509 Token Profile 1.1. System zapewni możliwość wysyłania komunikatów obsługiwanych przez system centralny zgodnie ze wskazaną w niniejszej SIWZ dokumentacją projektu P1. Zgodnie z założeniami Internetowe Konto Pacjenta umożliwiać będzie gromadzenie w jednym miejscu wszystkich informacji dotyczących stanu zdrowia pacjenta. Szybki dostęp do systemu będzie wspierać lekarza przy podejmowaniu optymalnych decyzji i wzmacnia skuteczność leczenia. Pacjentowi natomiast, zapewnia możliwość zarządzania własną dokumentacją medyczną, w szczególności umożliwi łatwy i szybki dostęp do skierowań, recept czy zaświadczeń. Stan prac nad wdrożeniem IKP wygląda następująco: Prototyp Internetowego Konta Pacjenta został wdrożony w 2011 roku i objął pacjentów chorych na cukrzycę w wieku od 18 lat leczących się w Krakowie. W lutym 2014 zakończono realizację Projektu Zintegrowanych prototypów Internetowego Konta Pacjenta oraz e-recepty. System przetestowano w trzech miastach Gdańsku, Olsztynie i Warszawie. Wykonawca systemu MSIM musi przewidzieć w ramach usługi wykonanie wymiany komunikatów, które pomiędzy MSIM, a Systemem P1 zgodnie z regułami tworzenia ww. elektronicznych dokumentów medycznych, które zostały opublikowane na stronach CSIOZ odnośniki do tych dokumentów znajdują się w niniejszej SIWZ. Wdrożony system MSIM musi być otwarty na system P1 w zakresie IKP ze względu na poniższe warunki: Istnienie jednego, centralnego rejestru EDM w warstwie regionalnej obejmującego całą EDM w Podmiotach objętych Projektem, a w konsekwencji posiadaniu zintegrowanej informacji o całej EDM. Strona 21 z 161

Rejestr EDM zgodnie z wytycznymi będzie realizowany na podstawie standardów komunikacji, również w zakresie e-zdrowia, które nie są cechą szczególną koncepcji, lecz powszechnie uznanym standardem komunikacji w podobnych rozwiązaniach. Wykorzystanie standardowego interfejsu komunikacji przez rejestr EDM oznacza, że integracja z każdym klientem rejestru powinna być maksymalnie uproszczona. Współpraca z CSIOZ w ramach systemu P1 w zakresie IKP odbywać się powinna na poziomie aplikacji pozwalającej na dostęp do konta pacjenta, w której będzie on miał możliwość zamawiania dokumentacji medycznej, która będzie następnie udostępniana/przesyłana za pomocą usługi dostępnej w warstwie regionalnej systemu MSIM. Integracja z P1 w zakresie IKP będzie obejmować zestawienie szyfrowanego połączenia pozwalającego na udostępnianie/przesyłanie danych medycznych, które zamówił pacjent. W ramach usługi realizowany będzie scenariusz: pacjent w IKP wyszukuje w wykazie interesującą go dokumentację medyczną (na podstawie indeksu zlokalizowanego w warstwie regionalnej), za pomocą usługi dostępnej w P1 pacjent zamawia interesująca go dokumentację medyczną, zlecenie zostaje przekazane do placówki, która udostępnia wskazaną dokumentację, placówka udostępnia zamówioną dokumentację medyczną, pacjent pobiera zamówioną dokumentację medyczną. W ramach integracji z CSIOZ należy zapewnić możliwość: przekazania tożsamości pacjenta do systemu MSIM, tak aby pacjent mógł wykorzystać usługę wyszukiwania i pobierania EDM, przekazywania zgód pacjentów na udostępnianie dokumentacji medycznej. Przekazywanie tożsamości pomiędzy Systemem MSIM, a Platformą P1 musi spełniać wszystkie wymagania prawne związane z anonimizacją danych Pacjentów. W zakresie zamówienia jest dostosowywanie MSIM do aktualnych wytycznych CSIOZ w zakresie platformy P1 przez okres wskazany w ofercie lecz nie mniej niż 5 lat od daty odbioru końcowego systemu, w tym uzyskiwanie wszystkich wymaganych certyfikacji. 2.9. Koncepcja przesyłania dokumentacji o dużej pojemności W przypadku dokumentacji medycznej głównym elementem wytwarzającym dane o dużej pojemności są dane obrazowe. W związku z czym System musi mieć możliwość 3-poziomowego wyboru zakresu pobieranej dokumentacji medycznej. Takie rozwiązanie pozwala na ograniczenie ruchu i nie obciążanie łączy bez uzasadnienia. Uwierzytelniony użytkownik będzie mógł skorzystać z następujących wariantów zamówienia/pobrania dokumentacji: Podstawowa dokumentacja medyczna (dokumentacja zewnętrzna: karta informacyjna, karta porady specjalistycznej, karta informacyjna SOR), Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza objętość), Pełna dokumentacja medyczna z konkretnej hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość). Przesył pełnej dokumentacji medycznej z danymi obrazowymi w jakości diagnostycznej o dużej objętości będzie wspomagany poprze mechanizm dynamicznego przydzielana przepustowości łącza, dający wyższy priorytet dla bieżącej obsługi jednostki szpitalnej, a niższy dla wymiany dokumentacji. Stworzenie mechanizmu przesyłu danych o dużej objętości (dane obrazowe) ma być funkcjonalnością zaimplementowaną w MSIM. Dostęp do danych obrazowych będzie zrealizowany: Strona 22 z 161

za pomocą interfejsu opracowanego przez Wykonawcę MSIM, do którego będą dołączane poszczególne PACS-y. Zadaniem Wykonawcy MSIM jest w tym przypadku stworzenie WebServisów, za pomocą, których będzie możliwa wymiana danych obrazowych (w formacie DICOM). Integracja MSIM z poszczególnymi systemami PACS nie jest elementem niniejszego zamówienia. Przez interfejs z systemem HIS (opisanym w załączniku 9A do SIWZ). Zadaniem Wykonawcy MSIM jest zapewnienie dostępu do danych obrazowych w przypadku gdy PACS jest bezpośrednio zintegrowany z HIS (sytuacja taka ma miejsce w Szpitalu im. Ludwika Rydygiera). 2.10. Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych jednostek W ramach koncepcji rozwoju systemu przewiduje się: 1. Zdefiniowanie i udostępnienie standardów warstwy integracji, w którego skład wchodzi m. in. interfejs integracji regionalnej odpowiedzialny za wymianę danych, umożliwiający komunikację elektroniczną pomiędzy regionem a lokalnymi systemami informatycznymi (standardy zapytań, struktur baz danych) Wykonawca przygotuje taki dokument na etapie realizacji projektu. 2. Rozwój na poziomie warstwy regionalnej e-usług dostarczanych wszystkim obywatelom, usługi integrujące działania jednostek służby zdrowia i usługi dedykowane organom działającym na poziomie regionalnym i ponadregionalnym do realizacji w ramach kolejnych projektów. 3. System zarządczy dla Województwa Małopolskiego w zakresie przewidzianym OPZ, 4. Integracja z pozostałymi systemami regionalnymi w dziedzinie e-zdrowia, w tym systemami i usługami wytwarzanymi w ramach projektów CSIOZ oraz innych platform regionalnych, np. PSIM (Podkarpacki System Informacji Medycznej) w tym zakresie wymagane jest zagwarantowanie integracji z w ramach zaleceń CSIOZ w okresie gwarancji. Architektura warstwy regionalnej ma zapewniać łatwą modyfikowalność systemu w przyszłości. Modyfikowalność systemu jest rozumiana jako co najmniej: Podłączanie nowych jednostek do systemu poprzez konfiguracje Rozszerzanie zakresu wymienianych danych poprzez konfiguracje Rozszerzanie funkcjonalności poprzez podłączanie dodatkowych modułów W tym zakresie Wykonawca przygotuje standardy integracji. 2.11. Schemat połączeń pomiędzy elementami systemu Sekcja przedstawia schemat połączeń pomiędzy elementami systemu, w tym połączeń sieciowych. Sieć Sieć połączeń pomiędzy poszczególnym uczestnikami projektu musi zostać zbudowana z wykorzystaniem posiadanego przez uczestników projektu łącza internetowego. W ramach publicznej sieci Internet zostanie zbudowana dedykowana sieć VPN, która połączy wszystkich uczestników projektu. W związku z tym, dane nie mogą być przesyłane w postaci jawnej lecz należy je szyfrować. Zakłada się w tym celu wykorzystanie mechanizmu IPsec (Internet Protocol Security), dzięki któremu urządzenia tworzą tzw. tunele IPsec. Dane przed wyjściem do Internetu są szyfrowane przez brzegowe urządzenie UTM znajdujące się w Szpitalu. Natomiast na końcu tunelu dane są odszyfrowywane przez brzegowe urządzenie UTM znajdujące się w lokalizacji regionalnej. W sytuacji przesyłania danych z Regionu do Szpitali kolejność szyfrowania będzie odwrotna. Strona 23 z 161

Takie tunele będę na stałe zestawione pomiędzy poszczególnymi Szpitalami, a Regionem. Układ ten przedstawia poniższy rysunek. Rysunek 6:Schemat połączeń VPN (źródło: opracowanie własne) Dzięki temu, wszystkie dane przechodzące przez Internet są bezpieczne. Również pracownicy zdalni mogą łączyć się do sieci firmowej poprzez tunel IPsec, umożliwia to bezpiecznie korzystanie z zasobów sieci firmowej np. z domu. W tym przypadku sieć VPN ma strukturę gwiazdy. Na poniższym rysunku został przedstawiony schemat połączeń infrastruktury sprzętowej dla projektu MSIM. W warstwie technicznej schemat połączeń pomiędzy elementami systemu oparty jest o następujące typy połączeń: Tunele VPN szyfrowane protokołem SSL pomiędzy warstwą regionalną a poszczególnymi komponentami lokalnymi, Łącze Ethernet 1Gb w zakresie sieci LAN, Połączenia z wykorzystaniem protokołu FC dla sieci SAN pomiędzy macierzami a serwerami. Strona 24 z 161

Szpital lokalny 3 Rysunek 7. Schemat połączeń pomiędzy elementami systemu

Rysunek 8.Schemat połączeń infrastruktury sprzętowej w lokalizacji Regionalnej. Strona 26 z 161

Rysunek 9.Schemat połączeń infrastruktury sprzętowej w lokalizacji Lokalnej. 2.12. Interfejsy komunikacyjne z innymi systemami informatycznymi System MSIM wykorzystuje następujące zewnętrzne interfejsy: System HIS, gdzie zakres i tryb wymiany danych określony jest interfejsem ITI-41

Lokalny systemu lub moduł e-rejestracji, gdzie zakres i tryb integracja określony jest definicją procesów biznesowych z grupy e-rejestracji (rozdział 2) P1 (IKP), gdzie zakres i tryb wymiany danych określony jest interfejsem właściwym dla klientów rejestru i repozytorium EDM Centrum Autoryzacji podpisu elektronicznego w Małopolsce(CAPE w Małopolsce), gdzie zakres i tryb integracji musi odpowiadać wymaganej funkcjonalności usługi podpisu elektronicznego dla EDM Wytyczne dla komunikacji z platformą P1: Komunikacja z platformą P1 następuje w oparciu o reguły tworzenia Elektronicznej Dokumentacji Medycznej i model transportowy danych o Zdarzeniach Medycznych oraz Indeksie EDM, gdzie platforma P1 jest rejestrem EDM Komunikat przekazania informacji o zdarzeniu medycznym jest inicjowany przez komponent regionalny, który przekazuje komunikat do platformy P1 analogicznie do zdarzenia rejestracji EDM przekazywanego przez komponent lokalny do komponentu regionalnego System dziedzinowy musi wytworzyć a komponent regionalny musi przygotować komunikat do platformy P1 zgodnie z ostatnią aktualną wersją wytycznych dostępnych na stronach CSIOZ Wykonawca jest zobowiązany do przygotowania opisu interfejsów, ich wykonania i przetestowania na zasadach odrębności w stosunku do pozostałych funkcji systemu MSIM (interfejsy można testować w oderwaniu od samego systemu). 2.13. Koncepcja komunikacji pomiędzy jednostkami Cała komunikacja mająca na celu przekazanie dokumentacji ze Szpitala występującego o dokumentację do szpitala udostępniającego dokumentację jest realizowana za pośrednictwem warstwy regionalnej MSIM. Strona 28 z 161

Rysunek 10.Schemat koncepcji komunikacji Takie rozwiązanie pozwala na zachowanie wysokiego poziomu bezpieczeństwa przez ustanowienie tylko jednego kanału komunikacji pomiędzy szpitalem, a warstwą regionalna, przez który przeprowadzony jest cały proces komunikacji. Strona 29 z 161

2.14. Koncepcja przesyłu danych pomiędzy jednostkami Proces udostępnienia dokumentu zilustrowany został na poniższym rysunku: Rysunek 11. Schemat procesu udostępniania dokumentu W ramach systemu MSIM przesył danych pomiędzy jednostkami powinien być realizowany w przypadku udostępniania dokumentacji medycznej. Scenariusz udostępniania dokumentacji medycznej jest następujący: 1. Użytkownik za pomocą aplikacji typu klient wyszukuje dokument pacjenta w rejestrze na podstawie metadanych. 2. System regionalny sprawdza uprawnienia użytkownika. 3. Repozytorium Regionalne kontaktuje się z repozytorium jednostki w którym przechowywana jest dokumentacja. 4. Dokumentacja wysyłana jest z repozytorium, w którym weryfikowana jest jej poprawność. 5. Dokumentacja wysyłana jest z warstwy regionalnej MSIM do użytkownika. 6. Po potwierdzeniu przesłania dokumentacji do Użytkownika, w warstwie regionalnej zostaje odnotowany fakt udostępnienia Elektronicznej Dokumentacji Medycznej zawierający co najmniej dane o: użytkowniku, dacie, czasie udostępnienia, wersji przekazanych dokumentów). Strona 30 z 161

2.15. Integracja systemów oraz danych z innych systemów do wdrażanego systemu MSIM System MSIM wykorzystuje następujące zewnętrzne interfejsy i w takim zakresie musi być zintegrowany z systemami zewnętrznymi udostępniającymi lub wykorzystującymi interfejsy: System HIS, gdzie zakres i tryb wymiany danych określony jest interfejsem ITI-41 Lokalny systemu lub moduł e-rejestracji, gdzie zakres i tryb integracja określony jest definicją procesów biznesowych z grupy e-rejestracji (rozdział 2) P1, gdzie zakres i tryb wymiany danych określony jest interfejsem właściwym dla klientów rejestru i repozytorium EDM, tj. ITI-18 i ITI-43 Centrum Autoryzacji podpisu elektronicznego w Małopolsce, gdzie zakres i tryb integracji musi odpowiadać wymaganej funkcjonalności usługi podpisu elektronicznego dla EDM. 2.16. Koncepcja wirtualizacji zasobów informatycznych Wymagana jest dostawa oprogramowania do wirtualizacji z licencjami wystarczającymi dla uruchomienia na dostarczonym sprzęcie 40 serwerów wirtualnych. Wykonawca musi opracować i uzgodnić z Zamawiającym plan wirtualizacji zasobów obejmujących zakres, tryb i konfigurację zasobów wirtualizowanych biorąc pod uwagę charakterystykę Systemu MSIM, zasady wirtualizacji poszczególnych Partnerów oraz przesłanki wydajnościowe i bezpieczeństwa. Wymagania na oprogramowanie do wirtualizacji przedstawiono w sekcji z oprogramowaniem standardowym (infrastruktura). 3. Analiza stanu aktualnego 3.1. Infrastruktura informatyczna 3.1.1. Serwerownia 3.1.1.1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu L.P. Parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 1. Adres 33-300 Nowy 33-300 Nowy 33-300 Nowy Sącz, Młyńska Sącz, Młyńska Sącz, Młyńska 10 10 10 2. Lokalizacja w budynku 33-300 Nowy 33-300 Nowy 33-300 Nowy Sącz, Młyńska Sącz, Młyńska Sącz, Młyńska 5, Budynek 5, Budynek 5,Budynek główny główny - RTG onkologiczny 3. Powierzchnia użytkowa [m 2 ] /wysokość [m] 10/2,98 8/2,54 6/2,96 4. Czy jest wolne miejsce na dodatkową szafę Tak Tak Tak 5. Ilość szaf RACK/Ilość wolnego miejsca [U] 1/5 1/0 3/5 ZABEZPIECZENIA FIZYCZNE 6. System alarmowy Nie Nie Tak 7. Monitoring video Nie Nie Nie 8. Kontrola dostępu Nie Nie Nie 9. Ochrona fizyczna Nie Nie Nie 10. Drzwi antywłamaniowe Nie Nie Nie 11. Zabezpieczenie okien Tak Tak Nie 12. Sygnalizacja pożaru Nie Nie Tak 13. System gaszenia pożaru gazem obojętnym Nie Nie Nie 14. Gaśnica CO2 Nie Nie Nie 15. Kontrola temperatury Nie Nie Nie Strona 31 z 161

16. Kontrola wilgoci Nie Nie Nie 17. Podłoga techniczna Nie Nie Nie ZAGROŻENIA 18. Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski) 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) INNE Tak (niski) Tak (niski) Nie Tak (niski) Tak (niski) Nie 20. Ilość klimatyzatorów 1 1 1 21. Łączna wydajność klimatyzatorów [kw] 5,2 8,8 7,1 PRZYŁĄCZA TELETECHNICZNE 22. Wolne przyłącza sieci logicznej [szt.] 12 24 24 23. Zapas dla przyłączenia urządzeń do sieci Tak Tak Tak elektrycznej [A] 24. Zapas mocy dla przyłączenia urządzeń do Tak/ 25 Tak/ 25 Tak/ 25 sieci elektrycznej [TAK/NIE]/[A] 25. Wydzielony obwód zasilania [TAK/NIE] Nie Nie Nie 26. System zasilania awaryjnego [TAK/NIE] Tak Tak Tak 27. Centralny UPS [TAK/NIE]/Moc [kva] Nie Nie Nie 28. Agregat prądotwórczy [TAK/NIE]/Moc [kva] Nie Nie Nie ZIDENTYFIKOWANE RYZYKA 29. Konieczność rozbudowy sieci logicznej Tak Tak Tak 30. Konieczność rozbudowy sieci elektrycznej Tak Tak Tak 3.1.1.2. Szpital Specjalistyczny im. J. Dietla w Krakowie L.P. Parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 1. Adres 31-121 Kraków, ul. Skarbowa 1 31-121 Kraków, ul Focha 33 2. Lokalizacja w budynku 31-121 Kraków, 31-121 Kraków, ul. Skarbowa 4 ul Focha 33, Główna lokalizacja 2km od Głównej Lokalizacji 3. Powierzchnia użytkowa [m 2 ] /wysokość [m] 18/2,90 12/2,70 4. Czy jest wolne miejsce na dodatkową szafę Tak Tak 5. Ilość szaf RACK/Ilość wolnego miejsca [U] 4/70 3/26 ZABEZPIECZENIA FIZYCZNE 6. System alarmowy Nie Tak 7. Monitoring video Nie Tak 8. Kontrola dostępu Nie Tak 9. Ochrona fizyczna Tak Tak 10. Drzwi antywłamaniowe Nie Nie 11. Zabezpieczenie okien Nie Nie dotyczy (brak okien) 12. Sygnalizacja pożaru Tak Tak 13. System gaszenia pożaru gazem obojętnym Nie Nie 14. Gaśnica CO2 Tak Tak 15. Kontrola temperatury Nie Nie 16. Kontrola wilgoci Nie Nie 17. Podłoga techniczna Nie Nie ZAGROŻENIA 18. Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski) 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) INNE 20. Ilość klimatyzatorów 2 2 21. Łączna wydajność klimatyzatorów [kw] 6 4 PRZYŁĄCZA TELETECHNICZNE Nie Nie Nie Nie Strona 32 z 161

22. Wolne przyłącza sieci logicznej [szt.] 90 120 23. Zapas dla przyłączenia urządzeń do sieci 8 20 elektrycznej [A] 24. Zapas mocy dla przyłączenia urządzeń do Tak/8 Tak/20 sieci elektrycznej [TAK/NIE]/[A] 25. Wydzielony obwód zasilania [TAK/NIE] Tak Tak 26. System zasilania awaryjnego [TAK/NIE] Nie Tak 27. Centralny UPS [TAK/NIE]/Moc [kva] Nie Tak/2KVA 28. Agregat prądotwórczy [TAK/NIE]/Moc [kva] Nie Tak/650kVA ZIDENTYFIKOWANE RYZYKA 29. Konieczność rozbudowy sieci logicznej Nie Nie 30. Konieczność rozbudowy sieci elektrycznej Nie Nie 3.1.1.3. Szpital Specjalistyczny im. Ludwika Rydygieraw Krakowie sp. z o.o. L.P. Parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 1. Adres Kraków, os. Kraków, os. Złotej Jesieni 1, 31-826 Kraków Złotej Jesieni 1, 31-826 Kraków 2. Lokalizacja w budynku Kraków, os. Kraków, os. Złotej Jesieni 1, 31-826 Kraków Złotej Jesieni 1, 31-826 Kraków 3. Powierzchnia użytkowa [m 2 ] /wysokość [m] 13/3 30/3 4. Czy jest wolne miejsce na dodatkową szafę Tak Tak 5. Ilość szaf RACK/Ilość wolnego miejsca [U] 5/42 Brak ZABEZPIECZENIA FIZYCZNE 6. System alarmowy Nie Tak 7. Monitoring video Tak Tak 8. Kontrola dostępu Nie Nie 9. Ochrona fizyczna Nie Nie 10. Drzwi antywłamaniowe Nie Nie 11. Zabezpieczenie okien Brak okien Tak 12. Sygnalizacja pożaru Tak Tak 13. System gaszenia pożaru gazem obojętnym Nie Nie 14. Gaśnica CO2 Tak Tak 15. Kontrola temperatury Tak Nie 16. Kontrola wilgoci NIe Nie 17. Podłoga techniczna NIe Nie ZAGROŻENIA 18. Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski) 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) INNE Nie (niski) Tak (niski) 20. Ilość klimatyzatorów 2 0 21. Łączna wydajność klimatyzatorów [kw] 7 kw 0 PRZYŁĄCZA TELETECHNICZNE Nie (niski) Tak (niski) 22. Wolne przyłącza sieci logicznej [szt.] 70 22 23. Zapas dla przyłączenia urządzeń do sieci 6kW Brak - do elektrycznej [A] uruchomienia w zależności od potrzeb 24. Zapas mocy dla przyłączenia urządzeń do sieci Tak /200kW Tak/200kW elektrycznej [TAK/NIE]/[A] 25. Wydzielony obwód zasilania [TAK/NIE] Tak Nie 26. System zasilania awaryjnego [TAK/NIE] Tak Nie 27. Centralny UPS [TAK/NIE]/Moc [kva] Tak /20kVA Nie 28. Agregat prądotwórczy [TAK/NIE]/Moc [kva] Tak /2x 540kVA (dla całego szpitala) ZIDENTYFIKOWANE RYZYKA 29. Konieczność rozbudowy sieci logicznej Tak Tak Strona 33 z 161

30. Konieczność rozbudowy sieci elektrycznej Tak Tak 3.1.2. Serwery L.P Producent - model Rok produkcji RAM Obudowa [Tower / RACK-xU] Rola (zadanie) Szpital Specjalistycznyim. J. Śniadeckiego w Nowym Sączu 1. Optimus Nserwer 2005 2GB Tower Auto ID 2. Optimus Nserwer 2005 3GB Tower Simple KP 3. IBM x3650 2009 6GB Rack 2U Simple ERP 4. SUN x4170 2011 24GB Rack 1U Eskulap terminale 5. SUN x4170 2012 24GB Rack 1U Eskulap terminale 6. SUN x4170 2012 20GB Rack 1U Eskulap terminale 7. HP ML350 2011 4GB Rack 4U Impax 8. HP ML350 2011 2GB Rack 4U Impax Szpital Specjalistyczny im. J. Dietla w Krakowie 1. HP RP5470 UX PA- 2001 2GB RACK 6U HIS/LIS/RIS RISC 2. NTT TYTAN 4205 2008 4GB RACK 3U Administracja+ serwer plików WINSER 3. NTT TYTAN WINSER 2009 8GB RACK 2U PACS 2003 4. DELL (PACS) LX 2011 8GB Rack 2U PACS 5. HP BLADE 620c 2012 16GB Rack Dystrybucja obrazów DiCOM 6. HP BLADE 620c 2012 16GB Rack Serwer Terminali Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. 1. HP ML 110 G4 2007 4GB Rack Obsługa ZDL 2. SuntarNET 2007 4GB Rack Serwer plików 3. HP DL 380 G5 2008 16GB Rack Infomedica 4. HP DL 380 G5 2008 16GB Rack HIS - zapasowy 5. HP DL 380 G5 2008 4GB Rack Dostęp do WAN (serwer typu UTM) 6. HP DL 160 G6 2009 4GB Rack Serwer plików 7. HP BL460c G6 2010 16GB Blade PACS 8. HP BL460c G6 2010 16GB Blade PACS 9. HP BL460c G6 2010 32GB Blade HIS, RIS 10. HP BL460c G6 2010 16GB Blade Hyper-V, WSUS, dreryk 11. HP BL460c G6 2010 16GB Blade Hyper-V, Serwer Kaspersky, ewuś 12. HP DL 120 G6 2010 4GB Rack Kontroler domeny 13. HP DL 120 G6 2010 4GB Rack Kontroler domeny 14. HP DL 160 G6 2010 4GB Rack Płatnik, Intranet 15. HP DL 360 G6 2010 4GB Rack Serwer plików 16. HP DL 120 G6 2011 4GB Rack PCM, 17. HP DL 360 G7 2012 4GB Rack Poczta, witryna WWW 18. HP BL460c G8 2013 64GB Blade EDM 19. HP BL460c G8 2013 64GB Blade EDM 3.1.3. Macierze L.P Producent - model Rok produkcji Pojemność Jakie dane są przechowywane Szpital Specjalistycznyim. J. Śniadeckiego w Nowym Sączu 1. IBM DS3512 2009 2x 1TB; PACS 5x300MB Rodzaj dysków [SATA / FATA] SAS (SATA) Szpital Specjalistyczny im. J. Dietla w Krakowie 1. HP MSA P2000 2012 12TB Dane SAS administracyjne 2. NTT 2008 18TB Dane medyczne SATA Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Strona 34 z 161

L.P Producent - model Rok Pojemność Jakie dane są Rodzaj dysków produkcji przechowywane [SATA / FATA] 1. HP MSA P2000 2009 5TB PACS SAS 2. HP 2312fc 2010 12TB PACS SAS 3. HP MSA P2000 G3 2012 32TB HIS,Archiwa SAS 4. HP MSA2000 2012 24TB Dane administracyjne SAS 3.1.4. Biblioteka taśmowa L.P Producent - model Rok produkcji Pojemność Jakie dane są przechowywane Oprogramowanie do backupu Szpital Specjalistycznyim. J. Śniadeckiego w Nowym Sączu 1. HP StorageWorks MSL 2010 20x1,6 TB PACS Firmeware HP 2024 2. SUN Oracle Storagetek 2011 20x1,6 TB Simple Firmeware Oracle SL24 Szpital Specjalistyczny im. J. Dietla w Krakowie 1. Brak Nie dotyczy Nie dotyczy Nie dotyczy Nie dotyczy 1 HP StorageWorks MSL 4048 Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. 2010 48x800GB PACS Firmeware HP, Synektik Strona 35 z 161

3.1.5. Połączenia sieciowe oraz sieć NAS 3.1.5.1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Główny Punkt Dystrybucyjny (GPD) znajduje się w pomieszczeniu serwerowni na parterze w budynku Pulmonologii. Oprócz tego w budynkach znajdują lokalne punkty dystrybucyjne, są to: Punkty 4P0, 4P1, 4P3, 4P4 (zlokalizowane na piętrach 0, 1, 3 i 4 Budynku 4) Punkty 3P-1, 3P0, 3P1, 3P2, 3P3 zlokalizowane na piętrach -1, 0, 1, 2 i 3 Budynku 3 Punkt PU zlokalizowany w budynku Pulmonologii Punkt PS zlokalizowany w budynku Kliniki Psychiatrycznej Punkt TE zlokalizowany w dziale technicznym Strona 36 z 161

Punkt DR (istniejący) zlokalizowany w budynku Dyrekcji Punkt RTG (istniejący) na parterze budynku 4 Punkty zostały połączone okablowaniem światłowodowym wielodomowym OM3 o różnej liczbie włókien. Załączony rysunek ilustruje schemat sieci logicznej. Podstawą do opracowania zagadnień związanych z okablowaniem strukturalnym są normy okablowania strukturalnego: ISO/IEC11801 wyd. II EN50173-1 wyd. II TIA/EIA 569A PN-EN50173-1 + AC TIA/EIA 568B 3.1.5.2. Szpital Specjalistyczny im. J. Dietla w Krakowie cat. 5e światłowód 10Gb (Wszystkie połączenia posiadają backup podwójny ring) Strona 37 z 161

cat 6 światłowód 1 Gb łącze LINK 4Mb/1Mb od 1.02.2013 światłowód 100M iscasi, FC, SCASI 3.1.5.3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Sieć informatyczna w Szpitalu zbudowana jest w topologii rozszerzonej gwiazdy. Szkielet sieci zbudowany na 6-cio światłowodach MM 50/125 które łączą centralny punkt dystrybucyjny (MDF serwerownia) z lokalnymi punktami dystrybucyjnymi (IDF)usytuowanymi na poszczególnych piętrach. Stacje robocze użytkowników komunikują się z przełącznikiem brzegowymi HP ProCurve 2610 po skrętce miedzianej cat.5e/6 z prędkością 100/1000 Mbps (w zależności od parametrów switch). Komunikacja w obrębie sieci szkieletowej odbywa się z prędkością 1/10Gbps.Szkielet sieci spina modularny przełącznik szkieletowy HP ProCurve 5412zl. W obrębie serwerowni funkcjonuje sieć pamięci masowej SAN zbudowana w technologii Fibre Channel w skład której wchodzi: 5 macierzy dyskowych HP MSA, system serwerowy HP Blade, 3 serwery Rackowe, biblioteka taśmowa MSL4048.Komunikację pomiędzy urządzeniami serwerowymi i zasobami pamięci zapewniają 3 switche FC(HP StorageWorks 8/20q oraz Brocade 8/12C). Komunikacja w strukturze FC odbywa się z prędkością 8Gbps. Na rysunku poniżej przedstawiony jest schemat infrastruktury FC. Strona 38 z 161

L.P. 3.1.6. Sprzęt komputerowy Rok produkcji Typ [terminal/pc] System operacyjny Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 1. 2011 Terminale Windows serwer 2008 200 2. 2005-2012 PC Windows XP 65 3. 2011 PC Windows VISTA 5 4. 2012-2013 PC Windows 7 20 5. 2013 PC Windows 8 1 1. 2008, 2012, 2013 Ilość [szt.] Szpital Specjalistyczny im. J. Dietla w Krakowie Terminal Linux 140 2. 2005-2013 PC Windows (XP; VISTA; 7) 110 Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. Z o.o. 1 2004-2013 PC Windows XP PRO, 7 PRO 574 3.2. Infrastruktura sieciowa 3.2.1. Sieć szkieletowa L.P Podmiot Technologia Przepustowość Redundancja [TAK/NIE] 1. Szpital Specjalistyczny im. J. Światłowód 1Gb/10Gb Nie Śniadeckiego w Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w Światłowód 10Gb Tak Krakowie 3. Szpital Specjalistyczny im. Ludwika Światłowód 1Gb/10Gb Nie Rydygiera w Krakowie sp. z o.o. 3.2.2. Sieć pozioma L.P Podmiot Technologia Przepustowość Kategoria 1. Szpital Specjalistyczny im. J. Śniadeckiego UTP 100Mb/1Gb 5/6e w Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w Krakowie UTP 1Gb 5e/6 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. UTP/FTP 100Mb/1Gb 5e/6 3.2.3. Węzły pośrednie L.P Podmiot Ilość Odrębne zasilania [TAK / NIE / CZĘŚCIO WO] 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w Krakowie 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. UPS [TAK / NIE / CZĘŚCIOW O] Dostęp chroniony [TAK / NIE / CZĘŚCIOWO] 23 Nie Nie Częściowo 7 Częściowo (2 z zasilaniem) Częściowo (2) Częściowo 18 Częściowo Częściowo Częściowo Strona 39 z 161

3.2.4. Urządzenia UTM L.P Podmiot [TAK / NIE] (model) 1. Szpital Specjalistyczny im. J. Śniadeckiego Tak (MikroTik w Nowym Sączu Board 1000) 2. Szpital Specjalistyczny im. J. Dietla w Tak (Juniper Krakowie SSG140) 3. Szpital Specjalistyczny im. Ludwika TAK (Linuks - Rydygiera w Krakowie sp. z o.o. Slackware) ilość Redundancja Rok produkcji 1 Nie 2009 1 Nie 2009 1 Nie 2010 3.2.5. Urządzenia aktywne lista 3.2.5.1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu L.P. Producent Model Rok produkcji Ilość 1. Allied Telesis AT-8000S/24 2009 4 2. Allied Telesis AT-8000GS/24 2010 20 3. Allied Telesis AT-8100S/48 2009 1 4. Allied Telesis AT-9000/24 2009 2 5. Allied Telesis AT-x900/24 2010 1 6. Allied Telesis AT-9000/52 2012 2 7. Allied Telesis AT-x600/24 2010,2012 2 8. Allied Telesis AT-MC101xL 2009 2 9. Allied Telesis AT-G6f Rapier 2007 1 10. Allied Telesis AT-8 PoE 2009 2 11. Allied Telesis AT-8000S/48 2009 1 3.2.5.2. Szpital Specjalistyczny im. J. Dietla w Krakowie L.P. Producent Model Rok Ilość produkcji 1. Netgear M5300-52G +2 x SFP10Gb + 2 2013 9 moduły stack 2. Netgear GS752TXS +2xSFP 10Gb 2012 4 3. 3com serii 4200 2010 3 4. 3com 24 port 2011 2 3.2.5.3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp z o.o. L.P. Producent Model Rok produkcji Ilość 1. HP ProCurve 2610 2010 24 2. HP ProCurve 2610 2008 6 3. HP ProCurve 2610 2009 5 4. HP ProCurve 2810 2007 2 5. HP ProCurve 2910al-48G 2010 3 6. HP ProCurve5412zl 2008 1 7. HP ProCurve5406zl 2010 1 8. HP Storage Works 8/20q Fibre Channel 2010 1 Switch 9. HP Brocade 8/12C SAN 2010 1 10. HP Brocade 8/12C SAN 2013 1 Strona 40 z 161

3.3. Łącza internetowe LP. Operator Serwerownia Technologia przyłącza Ilość stałych adresów IP Przepustowość download [Mbps] Przepustowość upload [Mbps] Szczytowe obciążenie Pozostały czas trwania umowy [mies.] Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 1. TP SA Serwerownia RTG Neostrada 5 40 4 90% 2 Tak Szpital Specjalistyczny im. J. Dietla w Krakowie 1. Fibertech Skarbowa 1 Światłowód 8 10 10 50% 12 Tak 2. TP SA Skarbowa 1 ADSL 6 4 1 100% 22 Tak 1. Netia SA Kraków, os. Złotej Jesieni 1, 31-826 Kraków 2. Exatel SA Kraków, os. Złotej Jesieni 1, 31-826 Kraków Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Światłowód 4 50 50 80% 9 Tak Radiowe 16 40 40 80% Brak danych Tak Czy są warunki do zwiększenia przepustowości Szacując, że do obsługi MSIM będzie konieczne łącze o min. przepustowości 20 Mbps (zarówno upload, jak i download) łącza w Szpitalu Specjalistycznym im. J. Śniadeckiego w Nowym Sączu (tylko upload), oraz Szpitalu Specjalistycznym im. J. Dietla w Krakowie są niewystarczające do obsługi MSIM. Dostarczenie niezbędnych łącz, których mowa wyżej nie jest elementem zamówienia.

3.4. Procedury bezpieczeństwa Nazwa jednostki Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Wdrożona Polityka Bezpiecze ństwa Nie (zamierza wdrożyć w 2014r) System zarządzania Bezpieczeń stwem Informacji Nie Procedury dotyczące bezpieczeństwa Informacji Istniejące procedury: - Instrukcja zarządzania systemami informatycznymi służącymi do przetwarzania danych osobowych - procedury archiwizacji danych - procedury nadawania i odbierania uprawnień w szpitalu Szpital Specjalistyczny im. J. Dietla w Krakowie Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. wdrożone są procedury ISO w zakresie nadawania uprawnień użytkownikom systemu; rozwiązania w zakresie bezpieczeństwa to: karty chipowe (klucze), konta domenowe, konta do systemu informatycznego HIS, RIS, LIS oraz do systemów administracyjnych Tak Tak Istniejące procedury: - 1. Instrukcja zarządzania systemem informatycznym (IZSI) 2 Polityka Bezpieczeństwa Informacji (PI) 3 Procedura bezpieczeństwa danych w ISO 9001:2010 Tak Tak Istniejące procedury: - - instrukcja zarządzania systemem informatycznym - polityka bezpieczeństwa informacji - procedura bezpieczeństwa danych w ISO 9001:2008 - Procedura zarządzania uprawnieniami w systemach informatycznych - w szpitalu uruchomiono działania zmierzające do uzyskania normy PN-ISO/IEC 27001 Poza Szpitalem Specjalistycznym im. J. Śniadeckiego w Nowym Sączu, wszystkie pozostałe Szpitale posiadają opracowane Polityki Bezpieczeństwa. Oznacza to, że w Szpitalach tych są opracowane zasady i dostępne narzędzia formalne opisujące co najmniej przydzielanie i odbieranie uprawnień dostępu do systemów medycznych oraz polityki haseł. Są to minimalne konieczne narzędzia formalne do wdrożenia na ich podstawie systemu MSIM oraz określenia zasad dostępu do niego. W ramach prac projektowych należy wypracować ujednoliconą politykę bezpieczeństwa dla systemu MSIM. Wykonawca systemu MSIM w ramach realizacji projektu opracuje dokumentację ochrony danych osobowych na którą składać się będą następujące dokumenty: Polityka bezpieczeństwa danych osobowych, Instrukcja zarządzania systemem służącym do przetwarzania danych osobowych.

3.5. Oprogramowanie dziedzinowe 3.5.1. System HIS L.P. Podmiot Producent Nazwa Wersja Wsparcie [TAK/NIE] 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Politechnika Poznańska ESKULAP 4.4.1 bw Tak 2. Szpital Specjalistyczny im. J. Dietla w Krakowie GEM Systemy Informatyczne SIS Brak wersjonowania Tak 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Comarch (Esaprojekt) Optimed 6.00.360 Tak L.P. 3.5.2. System LIS - analityka Podmiot Producent Nazwa Wersja Wsparcie [TAK/NIE] HIS 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Politechnika Poznańska ESKULAP 2.3.0 s Tak Tak 2. Szpital Specjalistyczny im. J. Dietla w Krakowie GEM Systemy SIS Brak wersjonowania Tak Tak Informatyczne 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Marcel Centrum 2.440.10.1285 Tak Tak Integra -cja z 3.5.3. System LIS - bakteriologia L.P Podmiot Producent Nazwa Wersja Wspar Integra cie -cja z HIS 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Politechnika Poznańska ESKULAP 1.2.1 h Tak Tak 2. Szpital Specjalistyczny im. J. Dietla w Krakowie GEM Systemy SIS Brak TAK Tak Informatyczne wersjonowania 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Marcel Centrum 2.440.10.1285 Tak Tak

3.5.4. System RIS L.P. Podmiot Producent Nazwa Wersja Wspa rcie 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Agfa IMPAX 2.3.0 r Tak Tak 2. Szpital Specjalistyczny im. J. Dietla w Krakowie GEM Systemy SIS Brak Tak Tak Informatyczne wersjonowania 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Comarch (Esaprojekt) CRID 3.1.14.4 Tak Tak Integra -cja z HIS (wyniki opisowe) 3.5.5. System PACS L.P Podmiot Producent Nazwa Wersja Wspa -rcie 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Agfa IMPAX 6.4.0.4 513 Tak Nie 2. Szpital Specjalistyczny im. J. Dietla w Krakowie PIXEL ExPACS Ostatnia do Tak Nie wygaśnięcia wsparcia, tj. 01.12.2016 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Synektik ARPACS 2.143.145. Tak Tak Integracja z HIS 3.5.6. E-Rejestracja L.P. Podmiot Czy jest świadczona? Producent Nazwa/Uwagi Wersja Wspa rcie Integra cja z HIS 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nie Brak Brak Brak Nie Nie Nie Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w Krakowie Nie (w trakcie Brak Brak Brak Nie Nie Nie projektowania) 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Tak 1.0 Tak. Nie. Nie. Szpital Specjalistyczny im. L. Rydygiera Sp. z o.o. Dział Informatyki Oprogramowanie autorskie wykonane we własnym zakresie Możliwość podłączenie pozostałych Strona 44 z 161

3.5.7. Wnioski Integracja wymienionych systemów z HIS realizowana jest w zakresie wysyłania zlecenia i odbierania wyniku. Wynik nie zawiera danych obrazowych PACS. Z powyższego zestawienia danych wynika że większość systemów (za wyjątkiem PACS) jest już zintegrowana z HIS. Analiza poziomu dojrzałości usługi e-rejestracja wykazuje, że jest to usługa, która na poziomie lokalnym obecna jest w jednostkach na bardzo zróżnicowanym poziomie. Niektórzy Partnerzy Projektu nie posiadają takiej usługi, u niektórych jest ona na bardzo niskim poziomie dojrzałości lub jej wdrożenie jest dopiero planowane. Niektórzy Partnerzy posiadają taką usługę wdrożoną i zintegrowaną z oprogramowaniem HIS. Uruchomienie usługi e-rejestracja w skali całego regionu wymaga jednak dodatkowych działań związanych z dostarczeniem części regionalnej rozwiązania. 3.6. Rodzaje przetwarzanych danych Legenda: 01- Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 02- Szpital Specjalistyczny i. J. Dietla w Krakowie 03- Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. W poniższej tabeli wskazano system, z którego jest możliwość importu danych (HIS / LIS / RIS) Podmiot 01 02 03 dokumenty podstawowe - priorytet 1 1 Formularz historii choroby HIS HIS HIS 2 Wywiad lekarski HIS HIS HIS 3 Epikryza HIS HIS HIS 4 Karta informacyjna z leczenia szpitalnego HIS HIS HIS 5 Opis przebiegu leczenia HIS HIS - 6 Wyniki badań laboratoryjnych analityka HIS HIS HIS/LIS 7 Wyniki badan laboratoryjnych bakteriologia HIS HIS HIS/LIS 8 Wyniki badań diagnostyki obrazowej opis HIS HIS HIS/RIS 9 Wyniki konsultacji HIS HIS - 10 Protokół operacyjny HIS HIS HIS 11 Karta zleceń lekarskich HIS HIS - dokumenty rzadko spotykane w HIS - priorytet 2 12 Wywiad epidemiologiczny HIS HIS - 13 14 Karta Oceny Ryzyka Zakażenia przy Przyjęciu do Szpitala Ocena ryzyka związanego ze stanem odżywienia dokumenty pielęgniarskie - priorytet 3 HIS HIS - HIS HIS HIS 15 Plan opieki HIS HIS - 16 Karta gorączkowa HIS HIS HIS 17 Karta indywidualnej opieki pielęgniarskiej - HIS - 18 Karta obserwacyjna HIS HIS - 19 Karta wywiadu pielęgniarskiego HIS HIS - 20 Raport pielęgniarski - HIS - dokumenty nie wychodzące ze szpitala - brak konieczności wymiany pomiędzy jednostkami 21 Karta procesu sterylizacji - - -

Opis przedmiotu zamówienia 22 Karta kwalifikacyjna do zabiegu HIS HIS - 23 Karta przebiegu znieczulenia HIS HIS - 24 Okołooperacyjna Karta Kontrolna - - - 25 Karta zabiegów fizjoterapeutycznych - HIS - 26 Karty TISS - - - 27 Inne np. zgoda pacjenta na wykonanie badania lub zabiegu - - HIS Powyższe dokumenty w postaci elektronicznej mają charakter sformatowanych plików tekstowych o niewielkim rozmiarze. Rozmiar każdego z nich nie jest ściśle określony ze względu na zmienność tekstów, które te dokumenty zawierają. Można szacować że ich rozmiar będzie ograniczony do kilkuset kilobajtów. Wszyscy partnerzy projektu zadeklarowali gotowość udostępniania oraz chęć korzystania z dokumentacji medycznej poprzez MSIM pod warunkiem że będzie to zgodne z obowiązującymi przepisami prawa. W poniższej tabeli wskazano szacowany roczny przyrost tekstowych danych medycznych w [MB] przyjmując średnią wielkość pojedynczego dokumentu medycznego skonwertowanego do formatu pdf: 300kb uwzględniając liczbę pobytów oraz szacowaną częstość występowania danej dokumentacji. Przyjęto na potrzeby szacowania że zabiegi operacyjne dotyczą 6 % hospitalizacji (wyliczenia dokonano na podstawie danych statystycznych z 2007 roku). Podmiot 01 02 03 Ilość hospitalizacji w roku 28000 15000 28000 Roczny przyrost danych [MB]- priorytet 1 1 Formularz historii choroby 8400 4500 8400 2 Wywiad lekarski 8400 4500 8400 3 Epikryza 8400 4500 8400 4 Karta informacyjna z leczenia szpitalnego 8400 4500 8400 5 Opis przebiegu leczenia 8400 4500 8400 6 Wyniki badań laboratoryjnych analityka 8400 4500 8400 7 Wyniki badan laboratoryjnych bakteriologia 8400 4500 8700 8 Wyniki badań diagnostyki obrazowej opis 8400 4500 45000 9 Wyniki konsultacji 8400 4500 8400 10 Protokół operacyjny 504 270 504 11 Karta zleceń lekarskich 8400 4500 8400 dokumenty rzadko spotykane w HIS - priorytet 2 12 Wywiad epidemiologiczny 8400 4500 8400 13 Karta Oceny Ryzyka Zakażenia przy Przyjęciu do Szpitala 8400 4500 8400 14 Ocena ryzyka związanego ze stanem odżywienia 8400 4500 8400 dokumenty pielęgniarskie - priorytet 3 15 Plan opieki 8400 4500 8400 16 Karta gorączkowa 8400 4500 8400 17 Karta indywidualnej opieki pielęgniarskiej 8400 4500 8400 18 Karta obserwacyjna 8400 4500 8400 19 Karta wywiadu pielęgniarskiego 8400 4500 8400 20 Raport pielęgniarski 8400 4500 8400 Strona 46 z 161

Opis przedmiotu zamówienia W poniższej tabeli wskazano roczny przyrost danych medycznych obrazowych w [GB] L.P. Podmiot Roczny przyrost danych w [GB] 1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 1900 2. Szpital Specjalistyczny im. J. Dietla w Krakowie 8000 3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. 3000 Analiza systemów dziedzinowych u Partnerów Projektu oraz rodzajów przetwarzanej dokumentacji pokazuje, że podstawowym i często jedynym systemem dziedzinowym, który daje możliwość integracji w zakresie EDM, jest oprogramowanie klasy HIS. Dodatkowo analiza wskazała, że większość podstawowej dokumentacji medycznej jest możliwa do wyeksportowania z używanego oprogramowania klasy HIS. 3.7. Gwarancja i serwis Zapisy gwarancyjne oraz serwisowe umów podpisanych między szpitalami i dostawcami aplikacji/systemów dziedzinowych, nie gwarantują bez kosztowego przeprowadzenia integracji MSIM z systemami dziedzinowymi. Integracja zawsze skutkuje poniesieniem jej kosztów, można co najwyżej wpływać na rozmiar tych kosztów. W celu ich ograniczenia najważniejsze wydaje się doprowadzenie do stanu, w którym integracja z MSIM dotyczyłaby jak najmniejszej ilości systemów. W obszarze wymiany EDM optymalnym rozwiązaniem wydaje się integracja podstawowego systemu dziedzinowego, czyli oprogramowania klasy HIS, z Repozytorium Elektronicznej Dokumentacji Medycznej. 3.7.1. Opieka serwisowa (ilość miesięcy do wygaśnięcia umowy) L.P Podmiot HIS LIS RIS PACS 1. Szpital Specjalistyczny im. J. Śniadeckiego 1 1 1 1 w Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w 26 26 26 36 Krakowie 3. Szpital Specjalistyczny im. Ludwika 13 17 13 24 Rydygiera w Krakowie Sp. z o.o. 3.7.2. Opieka serwisowa (SLA czas reakcji na błąd krytyczny w godzinach) L.P Podmiot HIS LIS RIS PACS 1. Szpital Specjalistyczny im. J. Śniadeckiego 48 48 48 48 w Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w 8 8 8 12 Krakowie 3. Szpital Specjalistyczny im. Ludwika 24 24 24 24 Rydygiera w Krakowie Sp. z o.o. 3.7.3. Integracja z systemem HIS L.P Podmiot LIS RIS PACS 1. Szpital Specjalistyczny im. J. Śniadeckiego Tak Tak Nie w Nowym Sączu 2. Szpital Specjalistyczny im. J. Dietla w Tak Tak Nie Krakowie 3. Szpital Specjalistyczny im. Ludwika Tak Tak Tak Rydygiera w Krakowie Sp. z o.o. Strona 47 z 161

Opis przedmiotu zamówienia 3.7.4. Wnioski Na potrzeby MSIM informacje należy podzielić na dwie główne grupy: Informacje znakowe oraz informacje graficzne. Dla informacji graficznych głównym miejscem przechowywania jest system PACS. Informacje tekstowe ewidencjonowane są w wielu systemach medycznych, przy czym systemy HIS pełnią rolę pośredniczącą. Wykorzystanie w systemie MSIM repozytorium EDM powoduje więc ograniczenie kosztów integracji. W przypadku usługi e-rejestracja sposób jej wykonania jest pochodną oczekiwań użytkowników i specyficznej sytuacji produktowej w tym zakresie. 3.8. Funkcjonalność Centrum Autoryzacji Podpisu Elektronicznego (CAPE) Obecnie funkcjonująca w Centrum aplikacja PentaSCAPE RA-Service umożliwia uzyskanie certyfikatu na podstawie żądania w formacie PKCS#10. Nie ma określonych wymagań dot. zawartości żądania PKCS#10 (do certyfikatu pobierany jest jedynie klucz publiczny). CAPE obsługuje klucze i rozmiary zgodne z profilem certyfikatu użytego w PentaSCAPE Ra-Service do wystawienia certyfikatu. Usługa umożliwiająca uzyskanie certyfikatu udostępniana jest poprzez interfejs WWW, w którym uwierzytelnianie odbywa się poprzez podanie loginu i hasła. Usługa znakowania czasem realizowana jest za pomocą dostępnej przez protokół http aplikacji PentaSCAPE-TSAService i zgodna ze standardem RFC 3161. Nie przeprowadzano testów wydajnościowych usługi. Aktualna wydajność usługi powinna być wystarczająca do planowanej skali systemu. Ścieżka certyfikacyjna certyfikatu TSA obejmuje certyfikaty CA o nazwach wyróżniających: 'CN=RootCA, O=Województwo Małopolskie, C=PL' i 'CN=Centrum Autoryzacji w Małopolsce, O=Województwo Małopolskie, C=PL'. Odpowiedzi OCSP podpisywane są kluczem dedykowanym. Nie przeprowadzano testów wydajnościowych usługi OCSP. Usługa wydawania certyfikatów w centrum CAPE będzie dostępna bez ograniczeń licencyjnych. Zamawiający zapewnia dostęp do interfejsu API umożliwiającego wykorzystanie CAPE w procesach autoryzacji dokumentów. W załączniku 9B do SIWZ znajdują się wyciągi ze spisów treści dokumentacji CAPE, która zostanie udostępniona wybranemu Wykonawcy. 3.9. Lokalne słowniki dokumentów Lokalne słowniki dokumentów w większości jednostek pokrywają się, ponieważ wynikają z obowiązującego prawodawstwa. Wszystkie rodzaje dokumentów są zdefiniowane w ramach systemu HIS, choć dotyczą również danych pochodzących z innych systemów dziedzinowych (LIS, RIS). Różnice między dokumentami wynikają ze specjalizacji jednostek oraz nieprecyzyjnego dookreślenia formatu dokumentacji przez ustawodawcę. Ponadto w jednostkach używa się dokumentów medycznych opracowanych na potrzeby własne szpitala (np. w Szpitalu Specjalistycznym im. J. Dietla w Krakowie Karta Przymusu). Kluczowym elementem systemu będzie wymiana dokumentacji medycznej w zw. z czym jeżeli niezbędne będzie w celu wykonania poprawnej integracji dostosowanie/ujednolicenie istniejących słowników, formatów danych i standardów danych słownikowych składowanych i udostępnianych należy to uwzględnić i wykonać we wdrożeniu. Strona 48 z 161

Opis przedmiotu zamówienia 4. Model statyczny System MSIM składa się z komponentu regionalnego i komponentu lokalnego. Wykonawca musi wdrożyć komponent regionalny w Szpitalu Specjalistycznym im. Ludwika Rydygiera w Krakowie sp. z o.o. Wykonawca musi wdrożyć komponenty lokalne w każdym Szpitalu uczestniczącym w projekcie. 4.1. Komponent lokalny Komponent lokalny składa się z następujących jednostek funkcjonalnych: 4.1.1. Repozytorium EDM Repozytorium EDM to moduł odpowiedzialny za przyjmowanie i przechowywanie dokumentów medycznych z systemów źródłowych funkcjonujących w Szpitalach. Moduł ten odpowiada za gromadzenie, przetwarzanie EDM zgodnej ze standardem HL7 CDA R2 na 3-cim poziomie interoperacyjności,. Repozytorium EDM musi wystawiać i obsługiwać interfejs przekazywania i rejestracji EDM zgodnie z wytycznymi ITI-41 profilu integracyjnego XDS.b (nie dotyczy architektury wewnętrznej systemu). Repozytorium EDM musi obsługiwać interfejs pozwalający na pobranie EDM uwierzytelnionemu użytkownikowi zgodnie z wytycznymi ITI-43 (nie dotyczy architektury wewnętrznej systemu). Repozytorium EDM musi wspierać opcję (rozszerzenie) profilu integracyjnego XDS.b związaną z obsługą asynchronicznej wymiany wiadomości (ang. Asynchronous Web Services Exchange Option ). 4.1.2. Systemy dziedzinowe (źródłowe): HIS, LIS, RIS a MSIM Systemy dziedzinowe to systemy informatyczne wspierające działalność leczniczą szpitala w tzw. części białej, które w kontekście niniejszego projektu stanowią źródło EDM. Systemy źródłowe (za wyjątkiem systemu HIS w zakresie integracji pomiędzy lokalnym EDM, a HIS oraz e-rejestracją z wykorzystaniem interfejsu opracowanego przez dostawcę HIS) nie są objęte w jakikolwiek sposób przedmiotem zamówienia. Ich dostosowanie do funkcjonowania zgodnie z zaproponowanymi interfejsami stanowi przedmiot odrębnych działań realizacyjnych. Systemami dziedzinowymi w kontekście niniejszego projektu są systemy HIS, LIS, RIS i inne, w których generowana jest EDM. 4.1.3. Usługa podpisu elektronicznego dla EDM Usługa podpisu elektronicznego dla EDM musi obsługiwać funkcję podpisywania i weryfikacji podpisu elektronicznego związanego z wdrożonym systemem tożsamości z wykorzystaniem Centrum Autoryzacji (CAPE w Małopolsce). Usługa podpisu elektronicznego musi być zgodna z funkcjonującą Polityką Certyfikacji CAPE w Małopolsce. Usługa musi integrować się z funkcjami CAPE w zakresie znakowania czasem oraz wykorzystania podpisu elektronicznego oraz pozostałych usług CAPE oraz wystawiać te usługi dla pozostałych komponentów Systemu MSIM, w tym repozytorium EDM, rejestru EDM oraz systemów dziedzinowych (w szczególności HIS). Strona 49 z 161

Opis przedmiotu zamówienia 4.1.4. Usługa buforowania dla klienta pobierania EDM Usługa istnieje w celu pośredniczenia w asynchronicznym trybie pobierania EDM. Klient korzystający z usługi pobierania EDM w trybie asynchronicznym zamawia zgromadzenie EDM (np. z kilku różnych źródeł o znacznym wolumenie), a następnie usługa buforowania przejmuje w jego imieniu proces zgromadzenia EDM. Usługa musi obsługiwać 2 interfejsy komunikacji: Push - w momencie wystąpienia zdarzenia zakończenia pobrania EDM wysyłany jest komunikat o gotowości do jej pobrania do zarejestrowanego klienta Pull w momencie odebrania komunikatu od klienta wysyłana jest gotowa EDM lub w przypadku jej braku (np. trwa proces buforowania) zwracany jest komunikat o stanie procesu (np. procent i wolumen pobranych już danych w odniesieniu do całości) Wymaga się aby nana etapie Analizy Przedwdrożeniowej, Wykonawca przedstawił możliwe warianty zapewnienia odporności do wyboru przez Zamawiającego na awarię w warstwie sieciowej (np. na zagrożenia typu przerwy w połączeniu). 4.2. Komponent regionalny Komponent regionalny składa się z następujących jednostek funkcjonalnych: 4.2.1. Rejestr EDM Rejestr EDM musi przechowywać scentralizowane informacje o miejscu składowania i fakcie wytworzenia wraz z informacją o wersjonowaniu wszystkich dokumentów medycznych w podmiotach biorących udział w Projekcie. Za pomocą odpowiednich interfejsów uwierzytelniony Użytkownik Systemu MSIM będzie mógł odpytać warstwę regionalną o dokumenty w innych jednostkach oraz pobrać je w całości lub częściowo. Rejestr EDM musi obsługiwać interfejs ITI-42 w zakresie rejestracji EDM. Rejestr EDM musi obsługiwać interfejs ITI-18 w zakresie obsługi zapytań od użytkowników Systemu MSIM. 4.2.2. Źródło identyfikacji pacjentów Źródło identyfikacji pacjentów musi jednoznacznie określać tożsamość pacjenta na podstawie jego właściwości. Źródło identyfikacji musi obsługiwać interfejs ITI-42 w zakresie rejestracji EDM. Źródło identyfikacji musi obsługiwać interfejs ITI-18 w zakresie obsługi zapytań od użytkowników Systemu MSIM. 4.2.3. Usługa uwierzytelniania i autoryzacji użytkowników System musi przechowywać tożsamości użytkowników Systemu MSIM, w tym personelu medycznego i obsługi technicznej. Musi przechowywać prawa dostępu użytkowników Systemu MSIM. Musi umożliwiać dodawanie, modyfikowanie i usuwanie użytkowników. Musi umożliwiać tworzenie grup użytkowników. Grupy użytkowników związane ze struktura organizacyjną projektu (w tym Podmiotu) powinny być wprowadzone i skonfigurowane przed uruchomieniem Systemu MSIM oraz możliwe do edycji w każdym momencie. Strona 50 z 161

Opis przedmiotu zamówienia Określanie praw dostępu musi być możliwe na poziomie grup użytkowników. Do nawiązywania zdalnych połączeń administracyjnych muszą być stosowane protokoły komunikacyjne zapewniające bezpieczne uwierzytelnianie oraz poufność i integralność przesyłanych danych. Uwierzytelnianie w MSIM musi być oparte na PKI z CAPE w Małopolsce (Certificate Authority). W szczególności uwierzytelnianie połączeń IPSec VPN ma być realizowane poprzez certyfikaty klientów VPN, wystawiane dla każdego z użytkowników indywidualnie przez CAPE (Centrum Autoryzacji podpisu elektronicznego). W zależności od uprawnień mogą być wystawiane osobne certyfikaty. Uwierzytelniania w MSIM może być realizowane przy pomocy innych metod uwierzytelnienia tylko w uzgodnieniu z Zamawiającym. W szczególności zakłada się, że uwierzytelnianie Pacjentów (klientów) usługi e-rejestracja powinno odbywać się przy pomocy metody opartej na loginie/haśle. Ważność certyfikatu musi być weryfikowana w CAPE on-line przy pomocy protokołu OCSP lub podobnego. Bezpieczeństwo kluczy powinno być realizowane z wykorzystaniem Polityki Certyfikacji CA MSIM. Polityka certyfikacji powinna być oparta na RFC3647 Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Framework. Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi. 4.2.4. Usługa wyszukiwania EDM Musi umożliwiać klientom (np. systemowi P1 w zakresie IKP lub aplikacjom webowym) przesłanie zapytania do rejestru EDM zgodnie z wytycznymi ITI-18 profilu integracyjnego XDS.b. Usługa wyszukiwania EDM musi umożliwiać: Przeszukiwanie rejestru EDM, Odpowiedź na zapytania o pozycję rejestru, Zwracanie wyników zapytania, Z uwzględnieniem praw dostępu użytkownika. Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi. 4.2.5. Usługa pobierania EDM Musi umożliwiać klientom(systemom klienckim) przesłanie zapytania do rejestru EDM zgodnie z wytycznymi ITI-18 profilu integracyjnego XDS.b. Usługa musi umożliwiać: Dostęp do repozytorium EDM, Odpowiadać na zapytania o pozycję repozytorium, Zwracać wyników zapytania, Zamówienie EDM (pobranie w trybie asynchronicznym), Odebranie EDM po wcześniejszym zamówieniu, Z uwzględnieniem praw dostępu. Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi. Strona 51 z 161

Opis przedmiotu zamówienia 4.2.6. Usługa e-rejestracja (regionalna) Usługa e-rejestracji udostępnia funkcjonalność rezerwacji usług medycznych w jednostkach ochrony zdrowia zintegrowanych z MSIM. Użytkownik ma możliwość rejestracji usługi medycznej na wskazany termin i anulowania tej wizyty. Z usługi e-rejestracji mogą korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi (pacjenci). W ramach e-usługi powinien funkcjonować system komunikatów (powiadomień dla użytkowników końcowych w formie wiadomości e-mail oraz System MSIM musi być przygotowano do wysyłania wiadomości SMS ) dotyczących: potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno przez użytkownika jak i w lokalnym systemie medycznym HIS). W szczególności usługa obejmuje następujące funkcjonalności: Przegląd listy usług możliwych do realizacji w placówce Zamawiającego dla pacjenta, Przegląd listy usług możliwych do rezerwacji przez Internet, Możliwość zdalnego zgłoszenia wniosku o rezerwację terminu usługi z preferowanymi terminami (zakres dat, dni tygodnia, przed południem, po południu): do Pracowni Diagnostycznej lub Gabinetu Lekarskiego, Umożliwia określenia celu wizyty u lekarza, z podziałem na: przypadek nagły incydentalny, stan nagły przy chorobie przewlekłej, wizytę kontrolną, wizytę po kolejną receptę, wizytę po skierowanie na badanie specjalistyczne, Udostępnienie danych o zaplanowanych wizytach i usługach, Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana), Możliwość wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko pacjenta, numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla pacjenta, Dostęp do informacji o lokalizacji miejsca wykonania usługi, Możliwość odwołania rezerwacji. Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail) Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi. 4.2.7. Usługa komunikacji z P1 (IKP) Usługa odpowiedzialna za komunikację z P1 zgodnie z wytycznymi i interfejsem platformy P1. Usługa musi umożliwiać przetworzenie zapytania o EDM przez Pacjenta i wywołać odpowiednie usługi w systemie MSIM. Usługa musi umożliwiać wyszukanie EDM uwierzytelnionemu w P1 Pacjentowi. Usługa musi umożliwiać pobranie EDM uwierzytelnionemu przez P1 Pacjentowi. Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi. 4.2.8. Usługa słownikowa Celem funkcjonowania usługi słownikowej jest posiadanie jednolitej terminologii w EDM będącej przedmiotem wymiany w projekcie MSIM. Usługa słownikowa pośredniczy w dostępie do słowników oferowanych przez platformę P1, tj.: ICD-10, ICD-9, ICF, ICNP Usługa umożliwia klientom, w szczególności systemom dziedzinowym, na: Wyszukanie pełno tekstowe terminu, Strona 52 z 161

Opis przedmiotu zamówienia Wyszukanie nadrzędnego terminu (w drzewie taksonomicznym), Wyszukanie listy podrzędnych terminów (w drzewie taksonomicznym), Pobranie dowolnego poddrzewa słownika (np. wszystkich terminów podrzędnych dla danego terminu). Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi. 4.2.9. Usługa synchronizacji rejestrów EDM Usługa musi umożliwiać synchronizację regionalnego i lokalnych EDM. Usługa musi umożliwiać synchronizację ręczną (na żądanie). Usługa musi umożliwiać konfigurowania interwału synchronizacji przez administratora ze względu na czas i rodzaj zdarzenia (np. otrzymanie nowego zapisu od rejestru, przesłanie dokumentacji do repozytorium lub dowolnego interfejsu wystawianego na szynie usług regionalnie lub lokalnie). Wymagane jest opracowanie programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi. 4.2.10. Portal informacyjny Portal informacyjny musi być aplikacją webową prezentującą informacje o projekcie, świadczonych usługach, uczestniczących partnerach. Portal musi być narzędziem klasy CMS umożliwiającym dostosowywanie oraz dodawanie treści przez użytkowników po stronie Zamawiającego. Portal musi posiadać możliwość dowolnej edycji i wprowadzania tekstu, w m. in. tym tworzenia podstron, linkowania, podłączanie zdjęć. Portal musi posiadać szatę graficzną uzgodnioną i zaakceptowaną przez Zamawiającego. Portal musi zawierać odnośniki do wszystkich usług systemu, stanowiąc centralny punkt dostępu do systemu MSIM. Portal musi być zintegrowany ze stroną województwa małopolskiego, oznaczony logiem projektu oraz banerami wymaganymi przepisami UE. Z portalu musi być możliwe przejście do wszystkich usługi w tym e-rejestracji. Na portalu udostępnione będą: Informacje o jednostkach ochrony zdrowia, które są zintegrowane z MSIM w ramach projektu (w tym lista usług świadczony przez te podmioty) Wyszukiwarka usług medycznych (wg typu usługi oraz wg jednostki ochrony zdrowia) Dane kontaktowe do jednostek ochrony zdrowia (tel. do placówki, poszczególnych specjalistów, informacji, rejestracji) Informacje nt. możliwości skorzystania z e-rejestracji (wraz z krótkim instruktażem jak z korzystać z rozwiązania na portalu oraz charakterystyka e-usługi - FAQ) Funkcjonalność umożliwiająca rejestrację oraz założenie konta Informacje o projekcie MSIM Wszystkie powyższe dane, opisy, grafiki, funkcjonalności do portalu wprowadzi Wykonawca. 4.2.11. Panel administratora Panel zawiera wszystkie funkcje potrzebne do administracji Systemem MSIM dla uprawnionych użytkowników (administratorów). Panel musi posiadać interfejs webowy. Strona 53 z 161

Opis przedmiotu zamówienia Panel dostępny jest z poziomu komponentu regionalnego w strefie umożliwiającą bezpieczną pracę administracyjną. Moduł w szczególności musi spełniać następujące funkcje: dodawanie użytkowników, nadawanie i modyfikacja uprawnień, parametryzacja ustawień synchronizacji z innymi systemami, dodawanie podmiotów, konfiguracja modułów wymiany danych, konfiguracja modułu e-rejestracji, konfiguracja usług. 4.3. Interfejsy Każdy moduł funkcjonalny (usługa, źródło, repozytorium) musi udostępniać interfejsy dostępu w postaci usług publikowanych na regionalnej szynie usług. Zakłada się model integracji oparty o jawne, otwarte, wyspecyfikowane w postaci języka WSDL interfejsy przyporządkowane do komponentów systemu. Każda interakcja pomiędzy komponentami systemu musi następować przy użyciu tych interfejsów. Interakcja nie może następować w postaci wywołań niejawnych. W tym celu wykorzystuje się interfejsy profilu integracyjnego XDS.b organizacji IHE, w szczególności: ITI-41 w zakresie dostarczania i rejestrowania dokumentów w repozytorium, ITI-42 w zakresie rejestrowania dokumentów w rejestrze ITI-43 w zakresie pozyskiwania dokumentów z repozytorium ITI-18 w zakresie zapytań do rejestru ITI-8 oraz ITI-44 w zakresie identyfikacji pacjenta przez rejestr wraz z rozszerzeniami przewidzianymi wytycznymi w sprawie reguł tworzenia i modelu transportowego EDM publikowanymi przez CSIOZ. Warstwa regionalna komunikuje się z lokalną szyną usług lub bezpośrednio lokalnym EDM. Dopuszcza się również możliwość istnienia serwerów buforowania po obu stronach (wstępne przetwarzanie, redukcja pasma transferowego). Konstrukcja warstwy integracyjnej w warstwie regionalnej z wykorzystaniem powyższych standardów w zakresie usług wyszukiwania EDM w rejestrze (ITI-18) oraz pobierania EDM w repozytoriach (ITI- 43) musi umożliwiać integrację z innymi systemami regionalnymi i lokalnymi w obszarze e-zdrowia. Strona 54 z 161

Opis przedmiotu zamówienia 5. Model dynamiczny 5.1. Wprowadzenie Analiza zakładów opieki zdrowotnej uczestniczących w projekcie, w tym analiza ich umocowania prawnego, rodzaju wykonywanej działalności, a także stan informatyzacji wykazany w audycie IT wskazuje, że najistotniejszymi z punktu widzenia projektowanego systemu procesami biznesowymi dla badanych Podmiotów są procesy związane z dwoma obszarami: obszarem przekazywania elektronicznej dokumentacji medycznej (EDM) oraz z obszaru elektronicznej usługi rejestracji. Z tego tytułu zdecydowano się na wskazanie następujących procesów biznesowych jako najistotniejszych dla badanych zakładów opieki zdrowotnej: 1. Wyszukiwanie elektronicznej dokumentacji medycznej, 2. Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym, 3. Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym, 4. Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z wykorzystaniem IKP, 5. Rezerwacja terminu wizyty, 6. Anulowanie rezerwacji terminu wizyty. Niniejszy dokument przedstawia raport z analizy powyżej zidentyfikowanej listy procesów biznesowych. 5.2. Metoda opisu Każdy z procesów biznesowych został przedstawiony w formie opisowej i graficznej. 5.2.1. Opis procesu Pierwszą częścią opisu jest forma tabelaryczna. Opis procesu w tej części zawiera następujące informacje: Nazwa procesu zawiera identyfikator procesu oraz nazwę właściwą procesu. Identyfikator proces został dodany do nazw procesu w celu umożliwienia i ułatwienia identyfikacji procesów na diagramach zbiorczych przedstawiający grupy procesów. Identyfikator procesu unikalny identyfikator procesu umożliwiający identyfikację procesu w całości dokumentacji. Wersja procesu numer kolejny wersji procesu. Cel procesu przedstawia podstawowy cel procesu biznesowego. Uczestnicy procesu przedstawia listę uczestników danego procesu, w tym systemy zewnętrzne (np. system P1 w zakresie IKP). Warunki wejściowe do procesu zawiera listę warunków wejściowych do procesu biznesowego, w tym również dane wejściowe. Warunki wyjściowe z procesu zawiera listę warunków wyjściowych, w tym dane wyjściowe z procesu biznesowego. Opis procesu - właściwy opis procesu przedstawiony w postaci kolejnych kroków procesu. Poszczególne kroki procesu opisane są w sposób narratywny; jednocześnie mają one swoje odpowiedniki w reprezentacji graficznej procesu, przy czym na diagramie ich nazwy są już skrócone. Jest to spowodowane z 2 względów. Po pierwsze w celu zachowania przejrzystości diagramu. Po drugie nazwy na diagramie oznaczające czynności stanową równocześnie nazwy kluczowych przypadków użycia warunkujących funkcjonalności systemu informatycznego wspierającego realizację opracowanych procesów biznesowych. Strona 55 z 161

Opis przedmiotu zamówienia 5.2.2. Graficzna prezentacja procesu Proces biznesowy opisany w postaci tabelarycznej został również przedstawiony w postaci graficznej. Zawiera ona poszczególne kroki procesu oraz przepływy informacji. Diagram procesu został przygotowany z wykorzystaniem notacji BPMN. W poszczególnych diagramach zastosowano elementy graficzne przedstawione w poniższej tabeli. Symbol Opis symbolu Element symbolizujący proces biznesowy Element symbolizujący zdarzenie inicjujące proces biznesowy. Element symbolizujący koniec procesu biznesowego. Element symbolizujący zdarzenie pośrednie polegające na odbiorze komunikatu Element symbolizujący zdarzenie pośrednie polegające na wysłaniu komunikatu Element symbolizujący krok procesu biznesowego (wykonaną czynność, zwaną również aktywnością) Element symbolizujący przepływ informacji,, tzw. MessageFlow (zaznaczony w niektórych przypadkach jako nazwa relacji) Element symbolizujący bramkę decyzyjną (albo) Element symbolizujący bramkę równoległą (i) Element symbolizujący bramkę LUB Element symbolizujący zbiór (rejestr) danych Strona 56 z 161