Małopolski System Informacji Medycznej projekt pilotażowy

ZAŁĄCZNIK NR 9 Opis przedmiotu zamówienia Małopolski System Informacji Medycznej projekt pilotażowy Opracowane przez Europejskie Centrum Technologii Informatycznych i Zarządzania ITmed Sp. z o. o. dla Województwa Małopolskiego Kraków, 2014

Opis Przedmiotu Zamówienia 1. Wstęp... 5 2. Wymagania podstawowe do realizacji Systemu MSIM... 5 2.1. Założenia projektowe... 6 2.2. Ogólne wymagania jakie powinien spełniad system MSIM... 9 2.3. Koncepcja wykonania i dostawy, instalacji, konfiguracji, wdrożenia, uruchomienia oraz integracji systemu MSIM... 13 2.4. Dyslokacja elementów systemu... 15 2.5. Zasady budowy reguł interoperacyjności w systemie... 16 2.6. Koncepcja synchronizacji czasu normalizacji czasu... 16 2.7. Koncepcja autentykacji i identyfikacji użytkowników... 17 2.8. Koncepcja współpracy z Internetowym Kontem Pacjenta (IKP)... 17 2.9. Koncepcja przesyłania dokumentacji o dużej pojemności... 19 2.10. Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych jednostek... 19 2.11. Schemat blokowy systemu... 20 2.12. Schemat połączeo pomiędzy elementami systemu... 21 2.13. Koncepcja obsługi systemu z urządzeo mobilnych... 25 2.14. Interfejsy komunikacyjne z innymi systemami informatycznymi... 26 2.15. Koncepcja komunikacji pomiędzy jednostkami... 26 2.16. Koncepcja przesyłu danych pomiędzy jednostkami... 28 2.17. Integracja systemów oraz danych z innych systemów do wdrażanego systemu MSIM... 29 2.18. Koncepcja wirtualizacji zasobów informatycznych... 29 3. Analiza stanu aktualnego... 29 3.1. Infrastruktura informatyczna... 29 3.2. Infrastruktura sieciowa... 46 3.3. Łącza internetowe... 50 3.4. Procedury bezpieczeostwa... 51 3.5. Oprogramowanie dziedzinowe... 53 3.6. Rodzaje przetwarzanych danych... 56 3.7. Gwarancja i serwis... 58 3.8. Lokalne słowniki dokumentów... 59 4. Model statyczny... 60 4.1. Komponent lokalny... 60 4.2. Komponent regionalny... 62 2 z 175

Opis Przedmiotu Zamówienia 4.3. Interfejsy... 66 5. Model dynamiczny... 67 5.1. Wprowadzenie... 67 5.2. Metoda opisu... 67 5.3. Mapa główna procesów biznesowych... 69 5.4. Przekazywanie EDM... 69 5.5. e-rejestracja... 77 6. Wymagania Systemu MSIM... 83 6.1. Wymagania ogólne... 83 6.2. Wymagania ogólne interfejsu użytkownika... 85 6.3. Wymagania prawne, organizacyjne i funkcjonalne... 85 6.4. Wymagania wydajnościowe systemu... 90 6.5. Wymagania skalowalności... 90 6.6. Wymagania wolumenu przetwarzanych danych... 90 6.7. Wymagania niezawodności... 91 6.8. Wymagania bezpieczeostwa... 91 6.9. Ochrona danych osobowych... 93 6.10. Wymagania systemu zarządzania tożsamością... 94 6.11. Procedury nadawania/zmiany/odbierania uprawnieo... 95 6.12. Repozytorium EDM... 95 6.13. Usługa e-rejestracja... 98 6.14. Wymagania warstwy integracji... 103 6.15. Wymagania dotyczące raportów... 104 7. Infrastruktura... 105 7.1. Infrastruktura serwerowa... 115 7.2. Komunikacja... 129 7.3. Bezpieczeostwo... 136 7.4. Pozostałe elementy... 144 7.5. Oprogramowanie systemowe... 147 8. Platforma danych... 154 8.1. Metadane dla źródeł danych... 154 8.2. Model biznesowy platformy danych... 154 8.3. Analiza źródeł danych... 155 3 z 175

Opis Przedmiotu Zamówienia 9. Metodyka wdrożenia Systemu... 159 9.1. Dokumentacja... 159 9.2. Szkolenia... 162 9.3. Odbiór... 168 9.4. Eksploatacja... 169 10. Gwarancja oraz wsparcie... 170 10.1. Gwarancja... 170 10.2. Wsparcie... 173 11. Licencjonowanie... 175 4 z 175

Opis Przedmiotu Zamówienia 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 7 podmiotów leczniczych z terenu województwa małopolskiego: Krakowskie Centrum Rehabilitacji i Ortopedii Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Szpital Wojewódzki im. św. Łukasza w Tarnowie Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 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 oraz asysta techniczna Szczegółowe wymagania dla powyższych produktów zdefiniowane zostały w kolejnych rozdziałach. 2. Wymagania podstawowe do realizacji Systemu 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. 5 z 175

Opis Przedmiotu Zamówienia 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. Zasilanie warstwy lokalnej Elektroniczną Dokumentacją Medyczną jest realizowane jednostronnie na osi: systemy dziedzinowe (HIS, LIS, RIS, PACS) warstwa lokalna. 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 wchodzących w skład domeny. Oba elementy systemu mogą być posadowione w lokalizacji jednego z uczestników projektu, bądź też hostowane i udostępniane w modelu Cloud zgodnie z obowiązującymi wymaganiami prawnymi. 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. W poszczególnych szpitalach zostaną utworzone Lokalne Repozytoria EDM, których głównym zadaniem będzie gromadzenie, przechowywanie i przesyłanie zgodnie z przepisami (Ustawa z dnia 28 kwietnia 2011 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 poszczególnych podsystemów powinna odbywać się za pomocą usług sieciowych w oparciu o szyny danych regionalną i lokalne umieszczone w szpitalach (w celu obniżenia kosztów instalacji możliwe jest też wykonanie w szpitalach integracji point-to-point, bez użycia lokalnej szyny danych, jest to szczególnie uzasadnione w sytuacji gdzie w jednostkach lokalnych funkcjonują pojedyncze systemy źródłowe). 2.1. Założenia projektowe Rozwiązanie przewiduje podział funkcjonalny na warstwę lokalną i warstwę regionalną. 6 z 175

Opis Przedmiotu Zamówienia Warstwa lokalna gdzie będzie wdrożony moduł odpowiedzialny za wytwarzanie, gromadzenie i przesyłanie EDM oraz usługi towarzyszące pozwalające na integracje z węzłem regionalnym. W warstwie lokalnej proponuje się gromadzenie dowolnej EDM, zgodnie zobowiązującymi przepisami oraz zgodnie ze specyfiką, potrzebami i oczekiwaniami poszczególnych Podmiotów. 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. Integracja poszczególnych podsystemów powinna odbywać się za pomocą webservices w oparciu o szyny danych regionalną i lokalne umieszczone w szpitalach (w celu obniżenia kosztów instalacji możliwe jest też wykonanie w szpitalach integracji point-to-point, bez użycia lokalnej szyny danych, jest to szczególnie uzasadnione w sytuacji gdzie w jednostkach lokalnych funkcjonują pojedyncze systemy źródłowe). 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 oznaczenia 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ść). 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. 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 7 z 175

Opis Przedmiotu Zamówienia 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ść 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. 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). 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) oraz innymi platformami regionalnymi. 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. 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 CDA w wersji 3. HL7 CDA w wersji 3 zostało także zaproponowane jako podstawowy format dokumentów medycznych na poziomie krajowym przez Centrum Systemów Informatycznych w Ochronie Zdrowia. Jeżeli niezbędne będzie w celu wykonania poprawnej integracji/wymiany danych pomiędzy systemami dziedzinowymi zlokalizowanymi w warstwach lokalnych a warstwą regionalną 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. 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, bądź też hostowana i udostępniana w modelu Cloud. 8 z 175

Opis Przedmiotu Zamówienia 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 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żenia systemu MSIM Integracja systemów informatycznych (HIS, RIS, LIS, PACS, innych) jednostek medycznych. Wymaga się stworzenie mechanizmu pozwalającego na integrację systemów dziedzinowych HIS funkcjonujących w jednostkach medycznych z Repozytorium Elektronicznej Dokumentacji Medycznej. W warstwie lokalnej (jednostkach medycznych) zaimplementowany zostanie moduł wymiany danych odpowiedzialny za wytworzenie, podpisanie i wersjonowanie powstającej dokumentacji medycznej wytwarzanej w różnych 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. W przypadku systemów dziedzinowych HIS niezbędna będzie ich integracja z wdrożonymi lub istniejącymi repozytoriami EDM oraz warstwą regionalną, w szczególności z systemem e-rejestracji (dostępnym z poziomu lokalnych systemów dziedzinowych HIS oraz aplikacji umieszczonej na portalu informacyjnym e-zdrowie). 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 IKP. 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. Rozwiązanie będzie zbudowane w architekturze rozproszonej moduł wymiany zostanie zaimplementowany w każdej jednostce medycznej uczestniczącej w projekcie. Moduł ten będzie realizował funkcje indeksowania (gromadzenia meta danych) dokumentacji medycznej oraz dostępu i konwersji tej dokumentacji do jednolitego standardu. 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 9 z 175

Opis Przedmiotu Zamówienia medycznej. Platforma ta zostanie zintegrowana z projektem P1 w zakresie indeksowania 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 v.3, 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). 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. Usługa będzie korzystać z modułów wymiany danych zlokalizowanych w jednostkach medycznych uczestniczących w projekcie. Dokumentacja medyczna będzie wyszukiwana w meta danych zgromadzonych w ww. modułach. Wynik wyszukiwania będzie miał postać czytelnej 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. Dostępne będą trzy tryby pozyskania dokumentacji zależne od pojemności danych - ad hoc dostępna będzie dokumentacja opisowa (w wariancie dokumentacji zewnętrznej, lub pełnej dokumentacji z pobytu) natomiast dane obrazowe z uwagi na dużą pojemność będą wymagały dłuższego czasu na ich pozyskanie. 3. Udostępnianie dokumentacji medycznej pacjentowi (w tym wyników badań): Usługa będzie umożliwiać pobranie przez pacjenta dokumentacji medycznej zgromadzonej 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 ramach usługi realizowany będzie scenariusz: 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 10 z 175

Opis Przedmiotu Zamówienia o 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, itp.) 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ą: 1. Aplikacje dedykowane dla urządzeń mobilnych: Zakres funkcjonalny: Obsługa procesu zamawiania EDM przez personel medyczny zgodnie z opracowanymi procesami biznesowymi Obsługa usługi e-rejestracji (umawianie, przeglądanie i anulowanie terminów) zgodnie z opracowanymi procesami biznesowymi Przeglądanie elektronicznej dokumentacji medycznej. 2. Usługa podpisu elektronicznego dla EDM. 11 z 175

Opis Przedmiotu Zamówienia Usługa podpisu elektronicznego dla EDM będzie 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). Będzie 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). Wszystkie realizowane przez System MSIM usługi elektroniczne będą dostępne przy pomocy dedykowanych interfejsów dostępu również w trybie graficznym. 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. 4. System MSIM musi być przygotowany na integrację z lokalnymi systemami dziedzinowymi: Różnych dostawców Używających różnych baz danych, Różnej strukturze Z serwerami baz danych działającymi na różnych systemach operacyjnych. 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 v.3, 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 12 z 175

Opis Przedmiotu Zamówienia 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 tych dokumentach będą prowadzone i odbierane poszczególne zadania realizowane przy budowie Systemu MSIM. Dokumenty te 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. 13 z 175

Opis Przedmiotu Zamówienia 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. a. 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. b. 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 SIWZa 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 14 z 175

Opis Przedmiotu Zamówienia 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 Zamawiający 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. 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. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie 2. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 3. Szpital Wojewódzki im. św. Łukasza w Tarnowie 4. Szpital Specjalistyczny im. J. Dietla w Krakowie 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 6. Krakowskie Centrum Rehabilitacji i Ortopedii 7. 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. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie 2. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 3. Szpital Wojewódzki im. św. Łukasza w Tarnowie 4. Szpital Specjalistyczny im. J. Dietla w Krakowie 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 6. Krakowskie Centrum Rehabilitacji i Ortopedii 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. 15 z 175

Opis Przedmiotu Zamówienia Komponent regionalny umieszony zostanie w lokalizacji: 1. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Lista lokalizacji jest aktualna na dzień 27.05.2014. Rozwiązanie musi gwarantować odseparowanie w warstwie sieciowej poszczególnych Szpitali od siebie. 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. 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. Nie ma potrzeby tworzenie 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. 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: 16 z 175

Opis Przedmiotu Zamówienia Usługa znakowania czasem Usługa weryfikacji znaku czasu System powinien wykorzystywać usługę znacznika czasu realizowaną przez Centrum Autoryzacji UMWM, przez zastosowanie funkcjonującej obecnie w Centrum aplikacji PentaSCAPE-TSAService. 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. Usługa weryfikacji znaku czasu 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. Każdy serwer lokalny będzie miał dostęp do kompletnej listy wszystkich użytkowników. Zakłada się wykorzystanie działającego Centrum Autoryzacji podpisu elektronicznego w ramach Urzędu Marszałkowskiego. Usługa uwierzytelniania powinna być oparta o mechanizm jednokrotnego logowania (ang. Single Sign On SSO) w obrębie aplikacji wytworzonych w ramach projektu oraz oprogramowania klasy HIS dla każdego szpitala. Użytkownik systemu HIS logując się do systemu będzie jednocześnie zalogowany do Systemu MSIM. 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. 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. 17 z 175

Opis Przedmiotu Zamówienia 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 - 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 (wersja 3) - w zakresie transferu nieobrazowych 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 z dokumentem Uproszczona instrukcja integracji - Integracja Prototypów Internetowego Konta Pacjenta (IKP) oraz e-recepty. 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 integracji z P1 w tym w zakresie IKP na pełnym poziomie dostępnym w okresie wykonywania usługi. Wymaga się dostosowania systemu MSIM do kolejnych wdrażanych w ramach Projektu P1 funkcji IKP realizowanych przez CSIOZ oraz przepisów prawa regulujących ten obszar w ramach usługi dostawy i nadzoru autorskiego. 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. 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 18 z 175

Opis Przedmiotu Zamówienia 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 Certyfikat CSIOZ będzie wystawiony dla całej platformy MSIM, w pozostałych przypadkach certyfikaty będą wystawione przez CSIOZ dla konkretnego podmiotu. Wykonawca musi zgromadzić pełen zakres danych przetwarzanych na potrzeby P1, zgodnie z wytycznymi CSIOZ. Przekazywanie tożsamości pomiędzy Systemem MSIM a Platformą P1 musi spełniać wszystkie wymagania prawne związane z anonimizacją danych Pacjentów. 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 powinien odbywać się w późnych godzinach wieczornych, gdzie znaczne obciążenie łącza nie będzie powodowało paraliżu funkcjonowania jednostki szpitalnej. Pozostała dokumentacja może być na bieżąco przesyłana przy założeniu, że zostanie zapewnione pełne bezpieczeństwo przesyłanych danych. 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 19 z 175

Opis Przedmiotu Zamówienia komunikację elektroniczną pomiędzy regionem a lokalnymi systemami informatycznymi (standardy zapytań, struktur baz danych, itp.). 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. 3. System zarządczy dla Województwa Małopolskiego, 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). 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 2.11. Schemat blokowy systemu W ramach planowanego rozwiązania należy zastosować rozdzielność warstwy regionalnej i warstwy lokalnej. Rozwiązanie nie pozwala na bezpośredni dostęp do systemów dziedzinowych Szpitali z poziomu warstwy regionalnej. Separacja dostępu do systemów dziedzinowych (źródłowych) Wymiana Elektronicznej Dokumentacji Medycznej jest realizowana dwustronnie na osi: warstwa lokalna warstwa regionalna. Zasilanie warstwy lokalnej Elektroniczną Dokumentacją Medyczną jest realizowane jednostronnie na osi: systemy dziedzinowe warstwa lokalna. Pod względem architektury rozwiązania cały system wymiany dokumentacji medycznej 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 20 z 175

POWER ALARM STATUS HA POWER POWER ALARM STATUS HA RESET CONFIG POWER TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX RESET CONFIG TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX USB 0 1 USB SLOT NUMBER 1 4 2 5 6 3 0 1 SLOT NUMBER 1 4 2 5 6 3 SSG550 SSG550 POWER ALARM STATUS HA POWER RESET CONFIG POWER ALARM STATUS TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX HA POWER RESET CONFIG USB 0 1 TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX SLOT NUMBER 1 4 2 5 6 3 POWER ALARM STATUS HA SSG550 POWER RESET CONFIG USB 0 1 SLOT NUMBER 1 4 2 5 6 3 SSG550 TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX USB 0 1 SLOT NUMBER 1 4 2 5 6 3 SSG550 IPsec POWER ALARM STATUS HA POWER ALARM POWER STATUS HA POWER RESET CONFIG RESET CONFIG TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX USB 0 1 USB 0 1 SLOT NUMBER 1 4 2 5 6 3 SLOT NUMBER 1 4 2 5 6 3 SSG550 SSG550 POWER ALARM STATUS HA POWER RESET CONFIG TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX USB 0 1 SLOT NUMBER 1 4 2 5 6 3 SSG550 Opis Przedmiotu Zamówienia medycznych. Oba elementy systemu mogą być posadowione w lokalizacji jednego z uczestników projektu, bądź też hostowane i udostępniane w modelu Cloud. 2.12. 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. Takie tunele będę na stałe zestawione pomiędzy poszczególnymi Szpitalami a Regionem. Układ ten przedstawia poniższy rysunek. Szpital 2 Szpital 1 Szpital 3 IPsec IPsec IPsec Region Szpital 4 IPsec IPsec Szpital 7 IPsec Szpital 5 Szpital 6 Rysunek 2:Schemat połączeo 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 21 z 175

Opis Przedmiotu Zamówienia Łącze Ethernet 1Gb w zakresie sieci LAN Połączenia z wykorzystaniem protokołu FC dla sieci SAN pomiędzy macierzami a serwerami 22 z 175

Rysunek 3 Schemat połączeń pomiędzy elementami systemu

POWER ALARM POWER ALARM STATUS HA STATUS HA POWER POWER RESET CONFIG RESET CONFIG TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX USB USB 0 1 0 1 SLOT NUMBER 1 4 2 5 3 6 SLOT NUMBER 1 4 2 5 3 6 SSG550 SSG550 Na poniższym rysunku został przedstawiony schemat połączeń infrastruktury sprzętowej w lokalizacji Regionalnej. SERWEROWNIA REGIONALNA Szpitale Konsola KVM Serwery aplikacyjny /integracji Serwer Bazy danych Serwery backupu/ zarządzania/wirtualizacji/ śr. testowego Przełączniki FC UTM/VPN Macierz dyskowa Biblioteka LTO Klaster Przełączników Ethernet Konsola KVM Serwery aplikacyjny/ integracji Serwer Bazy danych Serwery backupu/ zarządzania/wirtualizacji/ śr. testowego Legenda Macierz dyskowa Biblioteka LTO Sieć MGMT VPN IPSEC Łączę 1GE FC

POWER ALARM POWER ALARM STATUS HA STATUS HA POWER POWER RESET CONFIG RESET CONFIG TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX TX/RX 0/0 LINK TX/RX 0/1 LINK TX/RX 0/2 LINK TX/RX 0/3 LINK 10/100/1000 CONSOLE AUX USB USB 0 1 0 1 SLOT NUMBER 1 4 2 5 3 6 SLOT NUMBER 1 4 2 5 3 6 SSG550 SSG550 Opis Przedmiotu Zamówienia Na poniższym rysunku został przedstawiony schemat połączeń infrastruktury sprzętowej w lokalizacji Lokalnej. Infrastruktura EDM w Szpitalu Regionalna DC UTM/VPN Konsola KVM Klaster Przełączników Ethernet Serwer Pomocniczy Serwer Aplikacyjny Serwer Bazodanowy Macierz dyskowa Legenda Sieć MGMT VPN Łączę 1GE Biblioteka taśmowa SAS 2.13. Koncepcja obsługi systemu z urządzeń mobilnych W ramach systemu MSIM należy wytworzyć aplikacje dedykowane dla urządzeń mobilnych w zakresie: Obsługi procesu zamawiania EDM przez personel medyczny zgodnie z opracowanymi procesami biznesowymi Obsługi usługi e-rejestracji (umawianie, przeglądanie i anulowanie terminów) zgodnie z opracowanymi procesami biznesowymi 25 z 175

Opis Przedmiotu Zamówienia Przeglądanie elektronicznej dokumentacji medycznej. Aplikacje muszą być wytworzone na 3 mobilne systemy operacyjne: Android w wersji co najmniej 4, ios w wersji co najmniej 7 oraz Windows Phone w wersji co najmniej 8. Aplikacja mobilna podlega takim samym testom jak pozostałe komponenty Systemu. Wykonawca musi aplikacje mobilne wytworzyć oraz zarejestrować w sklepach właściwych dla danego systemu operacyjnego. Zakłada się 2 równoległe technologie wytworzenia aplikacji mobilnych: 1. Podstawowe usługi komponentu lokalnego i regionalnego będą udostępnione przy pomocy lekkich interfejsów bezstanowych zgodnie z modelem Rest. 2. Na poziomie lokalnym interfejs użytkownika oparty jest o przeglądarkę web. Rozwiązanie to pozwala na dostęp do danych systemu MSIM w zakresie możliwości technicznych i oprogramowania urządzenia mobilnego. W szczególności istotna jest tutaj wielkość ekranu oraz tryb pracy przeglądarki internetowej. 2.14. 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, 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.15. Koncepcja komunikacji pomiędzy jednostkami System musi gwarantować odseparowanie w warstwie sieciowej poszczególnych Szpitali od siebie. 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. 26 z 175

Opis Przedmiotu Zamówienia Rysunek: 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. 27 z 175

Opis Przedmiotu Zamówienia 2.16. Koncepcja przesyłu danych pomiędzy jednostkami Proces udostępnienia dokumentu zilustrowany został na poniższym rysunku: Rysunek: 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). 28 z 175

Opis Przedmiotu Zamówienia 2.17. 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.18. Koncepcja wirtualizacji zasobów informatycznych Serwery aplikacyjne i bazodanowe nie powinny być wirtualizowane. Zakłada się że jako serwery wirtualne będą działały serwery do backupu i zarządzania. Z założenia powinny pełnić rolę serwerów pomocniczych dla działania Systemu MSIM. Zakłada się zakup oprogramowania do wirtualizacji z licencją min. na dwa procesory dla każdego Szpitala oraz dla Regionu. Licencja ta pozwali na uruchomienie na serwerze dwuprocesorowym min. 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. Krakowskie Centrum Rehabilitacji i Ortopedii L.P. parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 30-224 Kraków 1. Adres Al. Modrzewiowa 22. 30-224 Kraków Al. 2. Lokalizacja w budynku Modrzewiowa 22, Budynek nr 1 3. Powierzchnia użytkowa [m 2 ]/wysokość [m] 12,5/2,6 4. Czy jest wolne miejsce na dodatkową szafę Tak 5. Ilość szaf RACK/Ilość wolnego miejsca [U] 0/0 ZABEZPIECZENIA FIZYCZNE 6. System alarmowy Nie 7. Monitoring video Nie 29 z 175

Opis Przedmiotu Zamówienia 8. Kontrola dostępu Tak 9. Ochrona fizyczna Tak 10. Drzwi antywłamaniowe Nie 11. Zabezpieczenie okien Nie dotyczy (brak okien) 12. Sygnalizacja pożaru Nie 13. System gaszenia pożaru gazem obojętnym Nie 14. Gaśnica CO2 Tak 15. Kontrola temperatury Tak 16. Kontrola wilgoci Tak 17. Podłoga techniczna Nie ZAGROŻENIA 18. Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski) Nie 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) Nie INNE 20. Ilość klimatyzatorów 1 21. Łączna wydajność klimatyzatorów [kw] 3,5 PRZYŁĄCZA TELETECHNICZNE 22. Wolne przyłącza sieci logicznej [szt.] 1 23. Zapas dla przyłączenia urządzeń do sieci elektrycznej [A] 8 24. Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A] Tak/7 25. Wydzielony obwód zasilania [TAK/NIE] Nie 26. System zasilania awaryjnego [TAK/NIE] Tak 27. Centralny UPS [TAK/NIE]/Moc [kva] Nie/0 28. Agregat prądotwórczy [TAK/NIE]/Moc [kva] Tak/200 ZIDENTYFIKOWANE RYZYKA 29. Konieczność rozbudowy sieci logicznej Tak 30. Konieczność rozbudowy sieci elektrycznej Tak 3.1.1.2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie L.P. Parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 1. Adres 31-202 Kraków, 31-202 Kraków, ul. Prądnicka 80 ul. Prądnicka 80 2. Lokalizacja 31-202 Kraków, ul. Prądnicka 80, Pawilon A-IV 31-202 Kraków, ul. Prądnicka 80, Pawilon A-IV 3. Powierzchnia użytkowa [m 2 ]/wysokość [m] 18/2,5 12/3 4. Czy jest wolne miejsce na dodatkową szafę Tak Tak 5. Ilość szaf RACK/Ilość wolnego miejsca [U] 4/24 3/40 ZABEZPIECZENIA FIZYCZNE 6. System alarmowy Tak Tak 7. Monitoring video Tak Tak 8. Kontrola dostępu Tak Tak 9. Ochrona fizyczna Tak Tak 10. Drzwi antywłamaniowe Nie Nie 11. Zabezpieczenie okien Tak 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 Tak 30 z 175

Opis Przedmiotu Zamówienia 16. Kontrola wilgoci Tak Tak 17. Podłoga techniczna Tak Tak ZAGROŻENIA 18. Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski) Nie Nie 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) Nie Nie INNE 20. Ilość klimatyzatorów 3 3 21. Łączna wydajność klimatyzatorów [kw] 30 30 PRZYŁĄCZA TELETECHNICZNE 22. Wolne przyłącza sieci logicznej [szt.] 48 48 23. Zapas dla przyłączenia urządzeń do sieci elektrycznej [A] 30 30 24. Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A] Tak/25 Tak/25 25. Wydzielony obwód zasilania [TAK/NIE] Tak Tak 26. System zasilania awaryjnego [TAK/NIE] Tak Tak 27. Centralny UPS [TAK/NIE]/Moc [kva] Tak/60 28. Agregat prądotwórczy [TAK/NIE]/Moc [kva] Tak/1000 ZIDENTYFIKOWANE RYZYKA 29. Konieczność rozbudowy sieci logicznej Nie Nie 30. Konieczność rozbudowy sieci elektrycznej Nie Nie 3.1.1.3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu L.P. parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 1. Adres 2. Lokalizacja w budynku 33-300 Nowy Sącz, Młyńska 10 33-300 Nowy Sącz, Młyńska 5, Budynek główny 33-300 Nowy Sącz, Młyńska 10 33-300 Nowy Sącz, Młyńska 5, Budynek główny - RTG 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 16. Kontrola wilgoci Nie Nie Nie 17. Podłoga techniczna Nie Nie Nie ZAGROŻENIA 18. 19. Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski) Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) Tak (niski) Tak (niski) Nie Tak (niski) Tak (niski) Nie 33-300 Nowy Sącz, Młyńska 10 33-300 Nowy Sącz, Młyńska 5,Budynek onkologiczny 31 z 175

Opis Przedmiotu Zamówienia INNE 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 elektrycznej [A] Tak Tak Tak 24. Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A] Tak/ 25 Tak/ 25 Tak/ 25 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.4. Szpital Specjalistyczny im. J. Dietla w Krakowie L.P. parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 1. Adres 31-121 Kraków, 31-121 Kraków, ul. Skarbowa 1 ul Focha 33 31-121 Kraków, 31-121 Kraków, 2. Lokalizacja w budynku ul. Skarbowa 4 ul Focha 33, Główna 2km od Głównej lokalizacja 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) Nie Nie 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) Nie Nie INNE 20. Ilość klimatyzatorów 2 2 21. Łączna wydajność klimatyzatorów [kw] 6 4 PRZYŁĄCZA TELETECHNICZNE 22. Wolne przyłącza sieci logicznej [szt.] 90 120 23. Zapas dla przyłączenia urządzeń do sieci elektrycznej [A] 8 20 24. Zapas mocy dla przyłączenia urządzeń Tak/8 Tak/20 32 z 175

Opis Przedmiotu Zamówienia do 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.5. Szpital Wojewódzki im. św. Łukasza w Tarnowie L.P. Parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 33-100 Tarnów, 1. Adres ul. Lwowska 178a 33-100 Tarnów, ul. Lwowska 2. Lokalizacja w budynku 178a Informatycy; D IIp. pok. 55 3. Powierzchnia użytkowa [m 2 ] /wysokość [m] 19,5/2,85 4. Czy jest wolne miejsce na dodatkową szafę Tak 5. Ilość szaf RACK/Ilość wolnego miejsca [U] 2/30 ZABEZPIECZENIA FIZYCZNE 6. System alarmowy Tak 7. Monitoring video Nie 8. Kontrola dostępu Nie 9. Ochrona fizyczna Tak 10. Drzwi antywłamaniowe Nie 11. Zabezpieczenie okien Nie 12. Sygnalizacja pożaru Tak 13. System gaszenia pożaru gazem obojętnym Nie 14. Gaśnica CO2 Nie 15. Kontrola temperatury Nie 16. Kontrola wilgoci Nie 17. Podłoga techniczna Nie ZAGROŻENIA 18. Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski) Tak (niski) 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) Tak (niski) INNE 20. Ilość klimatyzatorów 1 21. Łączna wydajność klimatyzatorów [kw] Brak danych PRZYŁĄCZA TELETECHNICZNE 22. Wolne przyłącza sieci logicznej [szt.] 24 23. Zapas dla przyłączenia urządzeń do sieci elektrycznej [A] 0 24. Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A] Nie/0 25. Wydzielony obwód zasilania [TAK/NIE] Tak 26. System zasilania awaryjnego [TAK/NIE] Tak 27. Centralny UPS [TAK/NIE]/Moc [kva] Nie 28. Agregat prądotwórczy [TAK/NIE]/Moc [kva] Nie ZIDENTYFIKOWANE RYZYKA 33 z 175

Opis Przedmiotu Zamówienia 29. Konieczność rozbudowy sieci logicznej Nie 30. Konieczność rozbudowy sieci elektrycznej Tak 3.1.1.6. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie L.P. Parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 1. Adres 31-503 Kraków, 31-503 Kraków, ul. Strzelecka ul. Strzelecka 2 2A 2. Lokalizacja w budynku 31-503 Kraków, 31-503 Kraków, ul. Strzelecka ul. Strzelecka 2 2A 3. Powierzchnia użytkowa [m 2 ] /wysokość [m] 6,46/4,30 12,65/2,60 4. Czy jest wolne miejsce na dodatkową szafę Tak Tak 5. Ilość szaf RACK/Ilość wolnego miejsca [U] 1/14U 2/20U ZABEZPIECZENIA FIZYCZNE 6. System alarmowy Nie Nie 7. Monitoring video Tak Tak 8. Kontrola dostępu Tak Nie 9. Ochrona fizyczna Tak Tak 10. Drzwi antywłamaniowe Nie Nie 11. Zabezpieczenie okien Nie Nie dotyczy 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) Tak(niski) Nie 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) Tak(niski) Tak(niski) INNE 20. Ilość klimatyzatorów 1 1 21. Łączna wydajność klimatyzatorów [kw] 1,85 1,09 PRZYŁĄCZA TELETECHNICZNE 22. Wolne przyłącza sieci logicznej [szt.] 10 10 23. Zapas dla przyłączenia urządzeń do sieci elektrycznej [A] 16 16 24. Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A] Tak/5 Tak/16 25. Wydzielony obwód zasilania [TAK/NIE] Nie Tak 26. System zasilania awaryjnego [TAK/NIE] Tak Tak 27. Centralny UPS [TAK/NIE]/Moc [kva] Nie Tak/40 28. Agregat prądotwórczy [TAK/NIE]/Moc [kva] Tak/150 ZIDENTYFIKOWANE RYZYKA 29. Konieczność rozbudowy sieci logicznej Nie Nie 30. Konieczność rozbudowy sieci elektrycznej Nie Nie 34 z 175

Opis Przedmiotu Zamówienia 3.1.1.7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. L.P. Parametr Serwerownia 1 Serwerownia 2 Serwerownia 3 Kraków, os. Kraków, os. 1. Adres Złotej Jesieni 1, 31-826 Kraków Złotej Jesieni 1, 31-826 Kraków Kraków, os. Kraków, os. 2. Lokalizacja w budynku 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) Nie (niski) Nie (niski) 19. Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) Tak (niski) Tak (niski) INNE 20. Ilość klimatyzatorów 2 0 21. Łączna wydajność klimatyzatorów [kw] 7 kw 0 PRZYŁĄCZA TELETECHNICZNE 22. Wolne przyłącza sieci logicznej [szt.] 70 22 23. Zapas dla przyłączenia urządzeń do sieci elektrycznej [A] 6kW 24. Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A] Tak /200kW 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] ZIDENTYFIKOWANE RYZYKA 29. Konieczność rozbudowy sieci logicznej Tak Tak 30. Konieczność rozbudowy sieci elektrycznej Tak Tak Brak - do uruchomienia w zależności od potrzeb Tak/200kW Tak /2x 540kVA (dla całego szpitala) 35 z 175

Opis Przedmiotu Zamówienia 3.1.2. Serwery L.P Producent - model Rok produk cji RAM Obudowa [Tower / RACKxU] Krakowskie Centrum Rehabilitacji i Ortopedii 1. Actina Solar 2011 4GB Tower Dostępowy 2. Fujitsu Siemens 2005 4GB Tower Serwer aplikacji 3. IBM X3550 2009 10GB Tower Baza danych 1. 6 x HP, Proliant BL460G6 Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie 2010 64GB Blade Platforma Vmware 2. HP, Proliant DL 380 G5 2009 4 GB Rack 2U Rola (zadanie) Active Direktory, DNS, DHCP, serwer licencji 3. HP, Proliant DL 380 G5 2009 32 GB Rack 2U Baza danych Oracle 4. HP, Proliant DL 380 G5 2009 32 GB Rack 2U Baza danych Oracle 5. HP, Proliant DL 380 G5 2012 4 GB Rack 2U Backup IBM Tivoli 6. HP, Proliant DL 380 G5 2012 4 GB Rack 2U Baza danych Oracle 7. IBM, xseries x3650-m2 2011 8GB Rack 2U Centrala telefoniczna Cisco CUCM 8. IBM, xseries x3650-m2 2011 8GB Rack 2U Centrala telefoniczna Cisco CUCM 9. IBM, xseries x3650-m2 2012 8GB Rack 2U Call Centre Cisco 10. IBM, xseries x3650-m2 2013 8GB Rack 2U Call Centre Cisco Szpital Specjalistyczny im. 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 Wojewódzki im. św. Łukasza w Tarnowie 1. Fujitsu 2005/6 3GB Tower Infomedia - ADM 2. Fujitsu; Primergy RX300 S5 2010 72GB Rack 2U Infomedica ADT APT 3. Fujitsu; Primergy RX300 2011/1 S6 2 12GB Rack 2U RIS 4. Fujitsu; Primergy RX300 2011/1 S6 2 12GB RACK 2U PACS 5. Fujitsu; Primergy RX300 2011/1 S7 2 24GB RACK 2U ProfLab 6. Fujitsu; Primergy RX300 2012/1 S7 3 16GB RACK 2U Hurtownia danych - OPTICO 7. Fujitsu; Primergy RX100 2011/1 S6 2 4GB RACK 1U Internetowy 8. SunTar 2005/6 4GB Tower EWUŚ Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 1. Fujitsu-Siemens Zapasowy dla aplikacji medycznych: 2006/7 16 GB Tower TX200S3/X5110 IM; AMMS i baza danych Serwer podstawowy dla aplikacji 2. IBM x3650m3 medycznych IM; AMMS, EDM, 2010/1 24 GB Rack 2U erejestracja oraz administracyjnych 1 IM (przechowuje bazy danych tych aplikacji) 3. IBM x3620m3 2010/1 6 GB Rack 2U RIS; erejestracja 4. IBM x3620m3 5. Producent nieznany (specyfikacja: Intel Core 2 Duo E4500 2,2GHz) 1 2010/1 1 6 GB Rack 2U 2007 2 GB Tower Serwer plików PACS/WEB; RIS; Baza danych RIS; PACS 36 z 175

Opis Przedmiotu Zamówienia 6. Producent nieznany (specyfikacja: Intel Core 2 Duo E4500 2,2GHz) 7. IBM x3550m4 2013 32 GB Rack 1U 8. IBM x3550m4 2013 32 GB Rack 1U 2007 2 GB Tower Serwer procesów wymiany Infomedica Serwer dla funkcjonalności WEB i mobilnej, Serwer domenowy, serwer aplikacyjny modułu generowania EDM dla HIS Serwer dla funkcjonalności WEB i mobilnej, Serwer domenowy Szpital Specjalistyczny im. J. Dietla w Krakowie 1. HP RP5470 UX PA-RISC 2001 2GB RACK 6U HIS/LIS/RIS 2. NTT TYTAN 4205 WINSER 2008 4GB RACK 3U Administracja+ serwer plików 3. NTT TYTAN WINSER 2003 2009 8GB RACK 2U PACS 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 produkcj i 1. Brak Pojemność Jakie dane są przechowywan e Rodzaj dysków [SATA / FATA] Krakowskie Centrum Rehabilitacji i Ortopedii Nie Nie dotyczy Nie dotyczy Nie dotyczy dotyczy Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie 1. EMC, VNX5100 2011 60 TB Medyczne i SSD/NLSAS/SAT administracyjne A 2. EMC, CLARiiON AX4 2008 10 TB Archiwa FC/SATA 3. HP, AiO1200r,5 2007 5 TB Bieżące kopie baz danych SATA Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 2x 1TB; 1. IBM DS3512 2009 PACS 5x300MB Szpital Wojewódzki im. św. Łukasza w Tarnowie Brak 1. Fujitsu; Eternus SAS-DX60 10TB PACS SAS danych Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 1. IBM Storwize V3700 z 6 2013 6X2TB repozytorium SAS SAS (SATA) 37 z 175

Opis Przedmiotu Zamówienia dyskami 2TB SAS Nearline dokumentów, dokumenty użytkowników, kopie zapasowe Szpital Specjalistyczny im. J. Dietla w Krakowie 1. HP MSA P2000 2012 12TB Dane administracyjne SAS 2. NTT 2008 18TB Dane medyczne SATA Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. 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 produkcj i 1. Brak pojemność Jakie dane są przechowywan e Oprogramowanie do backupu Krakowskie Centrum Rehabilitacji i Ortopedii Nie Nie dotyczy Nie dotyczy Nie dotyczy dotyczy Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Medyczne i 1. Quantum, Scalar i40 2011 40x5TB administracyjne IBM Tivoli Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 1. HP StorageWorks MSL 2024 2010 20x1,6 TB PACS Firmeware HP 2. SUN Oracle Storagetek SL24 2011 20x1,6 TB Simple Firmeware Oracle Szpital Wojewódzki im. św. Łukasza w Tarnowie 7 Taśm 1. Fujitsu; Eternus LT20 2010 LTO4 800GB/szt PACS 7 Taśm Archiwum 2. Fujitsu; Eternus LT20 2011 LTO4 Diagnostyki 800GB/szt Laboratoryjnej 1. Brak 1. Brak ARCserve r15 ARCserve r15 Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Nie Nie dotyczy Nie dotyczy Nie dotyczy dotyczy Szpital Specjalistyczny im. J. Dietla w Krakowie Nie Nie dotyczy Nie dotyczy Nie dotyczy dotyczy Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. Firmeware 1 HP StorageWorks MSL 4048 2010 48x800GB PACS Synektik HP, 38 z 175

Opis Przedmiotu Zamówienia 3.1.5. Połączenia sieciowe oraz sieć NAS 3.1.5.1. Krakowskie Centrum Rehabilitacji i Ortopedii Krakowskie Centrum Rehabilitacji posiada w chwili obecnej rozwinięta strukturę informatyczną. Jej trzon stanowi sieć teleinformatyczna wraz z urządzeniami aktywnymi (switch) oraz zespół 3 serwerów. Na obecną chwilę sukcesywnie rozwijana sieć teleinformatyczna o architekturze magistrali (kolejno łączono ze sobą budynki: 1-2, 2-7, 7-4, 4-15, 4-16), rozbudowana została o połączenia światłowodowe zaznaczone na czerwono Bud. 2 23 aktywne gniazda Bud. 1 Serwerownia 30 aktywnych gniazd Bud. 7 Na obecną chwile nie wykorzystywany Bud. 3 3 aktywne gniazda Bud. 15 2 aktywne gniazda Bud. 10 1 gniazdo aktywne Bud. 4 16 aktywnych gniazd Bud. 16 8 aktywnych gniazd Bud. 5 2 gniazda aktywne 39 z 175

Opis Przedmiotu Zamówienia 3.1.5.2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Uwagi (opis): szkielet sieciowy serwerowni oparty jest o zwirtualizowane przełączniki Cicso Catalyst 6500 połączone z przełącznikami brzegowymi Catalyst 3750 i 2960 za pomocą dwóch uplinków LACP 1G lub 10G. Serwery typu Rack oraz system HP blade połączone są 2 interfejsami do przełączników szkieletowych. Macierze dyskowe EMC VNX5100 w układzie lustra połączone są za pomocą 2 niezależnych traktów FC opartych na przełącznikach Cisco MDS9000 z systemem HP blade c7000 oraz z serwerami typu Rack za pomocą kart HBA. 40 z 175

Opis Przedmiotu Zamówienia 3.1.5.3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Główny Punkt Dystrybucyjny (GPD) znajduje się w budynku Pulmonologii. w pomieszczeniu serwerowni na parterze 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 Punkt DR (istniejący) zlokalizowany w budynku Dyrekcji 41 z 175

Opis Przedmiotu Zamówienia 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.4. Szpital Wojewódzki im. św. Łukasza w Tarnowie Bud. D Bud. C GPD - H Bud. A PD - G PD - CHD GPD - A PD - B PD - T Bud. H PD - I PD - O PD - C PD - Z PD - J Bud. Techniczny + Centrala Bud. Uzależnienia PD - Tech PD - K PD - L PD - Dializy PD - P PD - Centr Bud. Radioterapia Bud. B PD - Analit PD - D PD - F PD - RT1 PD - RT2 PD - BOP 1. GPD A GPD H - połączenie światłowodowe 12 włókien oraz 6 włókien 2. GPD A PD B - połączenie światłowodowe 8 włókien 3. GPD A PD T - połączenie światłowodowe 8 włókien 4. GPD A PD C - połączenie światłowodowe 8 włókien 5. GPD A PD Z - połączenie światłowodowe 8 włókien 6. GPD A PD J - połączenie światłowodowe 6 włókien 7. GPD A PD P - połączenie światłowodowe 6 włókien 8. GPD A PD Dializy - połączenie kat 6 9. GPD A PD D - połączenie światłowodowe 6 włókien 10. GPD A PD I - połączenie światłowodowe 4 włókna 11. GPD A PD G - połączenie światłowodowe 6 włókien 12. GPD A PD RT1 - połączenie światłowodowe 6 włókien 13. GPD A PD RT2 - połączenie światłowodowe 6 włókien 14. GPD A PD BOP - połączenie światłowodowe 8 włókien 42 z 175

Opis Przedmiotu Zamówienia 15. GPD H PD CHD - połączenie kat 6 16. GPD H PD O - połączenie światłowodowe 8 włókien 17. GPD H PD K - połączenie światłowodowe 8 włókien 18. GPD H PD L - połączenie światłowodowe 6 włókien 19. PD RT2 PD Centr - połączenie światłowodowe 6 włókien 20. PD Centr PD Tech - połączenie światłowodowe 6 włókien 21. PD F PD D - połączenie kat 6 22. PD K PD L - połączenie światłowodowe 6 włókien W GPD A urządzenie NAS 1 TB (QNAP TS 419U) W GPD H 2 urządzenia NAS 1TB/urządzenie (QNAP TS 419U) 3.1.5.5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Budynek Strzelecka 2: 3 punkty dystrybucyjne, + serwerownia wyposażone w UPS (do 2 minut o zaniku zasilania podane zostanie zasilanie awaryjne z agregatu), Budynek Strzelecka 2A serwerownia - wyposażone w UPS (do 2 minut o zaniku zasilania podane zostanie zasilanie awaryjne z agregatu), podłączone do dedykowanej sieci 43 z 175

Opis Przedmiotu Zamówienia 3.1.5.6. Szpital Specjalistyczny im. J. Dietla w Krakowie cat. 5e światłowód 10Gb (Wszystkie połączenia posiadają backup podwójny ring) 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.7. 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). 44 z 175

Opis Przedmiotu Zamówienia 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. 45 z 175

Opis Przedmiotu Zamówienia L.P. 3.1.6. Sprzęt komputerowy Rok Typ produkcji [terminal/pc] System operacyjny Krakowskie Centrum Rehabilitacji i Ortopedii 1. Brak danych PC Windows (XP;7) 70 Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie 1. 2004 PC Windows XP 22 2. 2005 PC Windows XP 36 3. 2006 PC Windows XP 49 4. 2007 PC Windows XP 52 5. 2008 PC Windows XP 50 6. 2009 PC Windows XP 49 7. 2010 PC Windows XP 73 8. 2011 PC Windows XP 120 9. 2012 PC Windows XP 116 10. 2013 PC Windows 7 300 11. 2007 Terminal Linux 80 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 Szpital Wojewódzki im. św. Łukasza w Tarnowie 1. 2007-2013 PC Windows (XP;Vista;7) 650 Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 1. 2008-2010 PC Windows XP 77 2. 2008 PC Windows VISTA 6 3. 2010-2013 PC Windows 7 70 1. 2008, 2012, 2013 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 Ilość [szt.] 3.2. Infrastruktura sieciowa 3.2.1. Sieć szkieletowa L.P Podmiot technologia 1. 2. 3. 4. 5. Krakowskie Centrum Rehabilitacji i Ortopedii Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Szpital Wojewódzki im. św. Łukasza w Tarnowie Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie przepustowo ść Światłowód 1Gb Nie Światłowód SM 1Gb/10Gb Tak Światłowód 1Gb/10Gb Nie Światłowód MM/SM 1Gb/10Gb Tak UTP kat 5e 1Gb Nie Redundancja [TAK/NIE] 46 z 175

Opis Przedmiotu Zamówienia 6. 7. Szpital Specjalistyczny im. J. Dietla w Krakowie Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. Światłowód 10Gb Tak Światłowód 1Gb/10Gb Nie 3.2.2. Sieć pozioma L.P Podmiot technologia 1. 2. 3. 4. 5. 6. 7. Krakowskie Centrum Rehabilitacji i Ortopedii Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Szpital Wojewódzki im. św. Łukasza w Tarnowie Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Szpital Specjalistyczny im. J. Dietla w Krakowie Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. 3.2.3. Węzły pośrednie L.P Podmiot ilość 1. 2. 3. 4. 5. 6. 7. Krakowskie Centrum Rehabilitacji i Ortopedii Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Szpital Wojewódzki im. św. Łukasza w Tarnowie Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Szpital Specjalistyczny im. J. Dietla w Krakowie Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. przepustowo ść UTP 100 Mb 5e UTP 1Gb 5/6 UTP 100Mb/1Gb 5/6e kategoria UTP/FTP 100Mb/1Gb 5e/6/7 UTP 1Gb 5e UTP 1Gb 5e/6 UTP/FTP 100Mb/1Gb 5e/6 Odrębne zasilania [TAK / NIE / CZĘŚCIO WO] UPS [TAK / NIE / CZĘŚCIOW O] Dostęp chroniony [TAK / NIE / CZĘŚCIOWO] 10 Nie Tak Częściowo 24 Tak Tak Tak 23 Nie Nie Częściowo 20 TAK 4 7 Częściowo (1) Częściowo (2 z zasilaniem) Częściowo (1) Tak Częściowo (2) Częściowo Nie Częściowo 18 Częściowo Częściowo Częściowo L.P 1. 2. 3. 4. 5. 6. 7. 3.2.4. Urządzenia UTM Podmiot Krakowskie Centrum Rehabilitacji i Ortopedii Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Szpital Wojewódzki im. św. Łukasza w Tarnowie Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Szpital Specjalistyczny im. J. Dietla w Krakowie Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o. [TAK / NIE] (model) Nie Tak (WatchGuard, XTM 5 series) Tak (MikroTik Board 1000) ilość Nie dotyczy Redundan cja Nie dotyczy 1 Tak 2010 1 Nie 2009 TAK 1 Nie 2011 Tak(Fortinet Fortigate 80C) Tak (Juniper SSG140) TAK (Linuks - Slackware) 1 Nie 2009 1 Nie 2009 Rok produkcji 1 Nie 2010 Nie dotyczy 47 z 175

Opis Przedmiotu Zamówienia 3.2.5. Urządzenia aktywne lista 3.2.5.1. Krakowskie Centrum Rehabilitacji i Ortopedii L.P. Producent Model Rok produkcji Ilość 1. Planet FGSW-2620VM 2013 1 2. Planet FGSW-4840S 2013 1 3. Planet FGSW-2620VM 2013 1 4. Planet GSD-802S 2007 1 5. Planet FGSW-2620VM 2013 1 6. Planet FGSW-2620VM 2013 1 7. Planet SGSW-2402 2007 1 8. Planet FGSW-2620VM 2013 1 9. 3COM 3C16487 Baseline Switch 2824- SFP Plus 2007 1 3.2.5.2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie L.P. Producent Model Rok produkcji Ilość 1. CISCO AIR-CT5508-100-K9Z 2011 2 2. CISCO PWR-RPS2300 2011 9 3. CISCO VS-C6509VE-S72010G 2011 2 4. CISCO WS-C2960-24TT-L 2011 2 5. CISCO WS-C2960G-24TC-L 2011 6 6. CISCO WS-C2960G-48TC-L 2011 2 7. CISCO WS-C3750E-24PD-S 2011 14 8. CISCO WS-C3750G-24PS-S 2011 1 9. CISCO WS-C3750G-24TS-S1U 2011 6 10. CISCO WS-C3750G-48PS-S 2011 14 11. CISCO WS-C3750G-48TS-S 2011 9 12. CISCO WS-C3750X-48P 2013 4 13. CISCO 3750x48ps 2013 3 14. CISCO WS-C3750X-48P-S 2013 7 15. CISCO WS-C3750X-48P 2013 2 16. CISCO WS-C2960-24LT-L 2013 2 3.2.5.3. 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 48 z 175

Opis Przedmiotu Zamówienia 3.2.5.4. Szpital Wojewódzki im. św. Łukasza w Tarnowie L.P. Producent Model Rok produkcji Ilość 1. 3Com Baseline Switch 2924-SFP Plus Brak danych 3 2. 3Com SuperStack 3 Switch 3300 XM Brak danych 2 3. 3Com SuperStack 3 Switch 4500 26-Port Brak danych 7 4. 3Com Switch 3300 Brak danych 2 5. 3Com Switch 4200 26 Port Brak danych 3 6. 3Com Switch 4200G 48-port Brak danych 1 7. 3Com Switch 4210 26-Port Brak danych 1 8. 3Com Switch 4210 52-Port Brak danych 4 9. 3Com Switch 4226T Brak danych 1 10. 3Com Switch 4400 Brak danych 3 11. 3Com Switch 4500 50-Port Brak danych 7 12. 3Com Switch 5500G-EI Brak danych 1 13. Asus GigaX1008 Brak danych 5 14. CellPipe 7130RG Brak danych 1 15. Cisco 800 Series Brak danych 2 16. Cisco Linksys SRW2048 Brak danych 1 17. D-Link DE-805TP Brak danych 1 18. D-Link DE-816TP Brak danych 1 19. D-Link DE-824TP Brak danych 1 20. D-Link DES-1024D Brak danych 2 21. Edimax ES-3124RL Brak danych 10 22. Edimax EW7206APg Brak danych 1 23. HP ProCurve 2610-24 Brak danych 1 24. HP V1910-24G Switch Brak danych 1 25. McAfee UTM Firewall Brak danych 1 26. Mikrotik Routerboard 750GL Brak danych 1 27. Planet FH803 Brak danych 1 28. Planet WAP-1966 Brak danych 1 29. Qnap TS-419U+ Brak danych 1 30. Edimax BR-6104K Brak danych 2 31. Linksys RV082 Brak danych 4 32. NETASQ NG1000-A Brak danych 1 33. SMC Networks SMC-EZ1016DT Brak danych 1 34. Zyxel N4100 Brak danych 1 35. 3Com Baseline Switch 2924-SFP Plus Brak danych 3 3.2.5.5. Szpital Specjalistyczny im. J. Dietla w Krakowie L.P. Producent model Rok produkcji Ilość 1. Netgear M5300-52G +2 x SFP10Gb + 2 moduły stack 2013 9 2. Netgear GS752TXS +2xSFP 10Gb 2012 4 3. 3com serii 4200 2010 3 4. 3com 24 port 2011 2 3.2.5.6. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie L.P. Producent model Rok produkcji Ilość 1. Planet FGSW-4840S 2006 1 2. Planet FGSW-4840S 2006 1 3. 3COM Baseline 2952 2010 1 4. 3COM Baseline 2952 2010 1 5. 3COM Baseline 2952 2010 1 6. HP E4210G-24G 2010 1 7. HP E4210G-24G 2010 1 49 z 175

Opis Przedmiotu Zamówienia 3.2.5.7. 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 ProCurve 5412zl 2008 1 7. HP ProCurve 5406zl 2010 1 8. HP Storage Works 8/20q Fibre Channel Switch 2010 1 9. HP Brocade 8/12C SAN 2010 1 10. HP Brocade 8/12C SAN 2013 1 LP. 3.3. Łącza internetowe Operat or 1. TP SA 2. TP SA 1. ACK Cyfron et 2. Orange Serwero wnia Technolog ia przyłącza Ilość stałych adresów IP Przepust owość downloa d [Mbps] Przepu stowo ść upload [Mbps] Szczyt owe obciąż enie Pozostały czas trwania umowy [mies.] Krakowskie Centrum Rehabilitacji i Ortopedii Budynek nr 1 DSL 1 4 1 100% 12 Tak Budynek nr 1 DLS 1 2 0,25 100% 12 Tak Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie serwerow nia A / Ethernet/ Pawilon światłowód 250 100 100 100% A-IV ul Ułanów 29 DSL/linia kablowa 2 2 2 100% Beztermin owa Beztermin owa Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Serwero 1. TP SA wnia RTG Neostrada 5 40 4 90% 2 Tak 1. TOI Szpital Wojewódzki im. św. Łukasza w Tarnowie Bezprzewo dowo 30 25 25 100% umowa beztermin owa Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 1. Mirolan Strzeleck a 2 / 2A Radiowe 8 10 10 100% 9 Tak 2. TP SA Strzeleck a 2 / 2A DSL 5 2 1 100% 9 Tak 1. Fiberte ch 2. TP SA 1. Netia SA Szpital Specjalistyczny im. J. Dietla w Krakowie Skarbow a 1 Światłowód 8 10 10 50% 12 Tak Skarbow a 1 ADSL 6 4 1 100% 22 Tak Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Kraków, os. Złotej Jesieni 1, Światłowód 4 50 50 80% 9 Tak 31-826 Czy są warunki do zwiększenia przepustowo ści Tak Tak Tak planowana przełączenie z bezprzewodo wego na światłowód 50 z 175

Opis Przedmiotu Zamówienia 2. Exatel SA Kraków Kraków, os. Złotej Jesieni 1, 31-826 Kraków Radiowe 16 40 40 80% Brak danych Tak Szacując, że do obsługi MSIM będzie konieczne łącze o min. przepustowości 20 Mbps (zarówno upload, jak i download) łącza następujących jednostek są niewystarczające do obsługi MSIM: 1. Krakowskie Centrum Rehabilitacji i Ortopedii 2. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu (tylko upload) 3. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 4. Szpital Specjalistyczny im. J. Dietla w Krakowie 3.4. Procedury bezpieczeństwa Nazwa jednostki Krakowskie Centrum Rehabilitacji i Ortopedii Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Szpital Wojewódzki im. św. Łukasza w Tarnowie Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Szpital Specjalistyczny im. J. Dietla w Krakowie Wdrożona Polityka Bezpieczeństwa Tak Tak Nie (zamierza wdrożyć w 2014r) Tak Tak Tak System zarządzania Bezpieczeństwem Informacji Tak Tak Nie Nie Nie Tak Procedury dotyczące bezpieczeństwa Informacji Norma: PN-ISO/IEC 27001:2007 Dostęp do aplikacji dziedzinowych na podstawie rejestru pracowników uprawnionych do korzystania z systemu komputerowego, (prowadzonego przez informatyka we współpracy z działem kadr) Norma: ISO 9001:2008 Istniejące procedury: -Nadawania zmiany i odbierania uprawnień w systemach Active Direktory, Infomedica Medyczna, Infomedica Administracyjna, Laboratorium, poczta elektroniczna, e-zapotrzebowania. 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 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 Instrukcja Zarządzania Systemem Informatycznym służącym do przetwarzania danych osobowych instrukcja ta jest integralną częścią Polityki Bezpieczeństwa Informacji Macierz dostępu, wnioski o dostęp przechowywane u informatyka, użytkownicy systemu przeszkoleni z zakresu ochrony danych osobowych i zapoznani z procedurami bezpieczeństwa danych, Polityka bezpieczeństwa, IZSI Istniejące procedury: - 1. Instrukcja zarządzania systemem informatycznym (IZSI) 51 z 175

Opis Przedmiotu Zamówienia Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Tak Tak 2 Polityka Bezpieczeństwa Informacji (PI) 3 Procedura bezpieczeństwa danych w ISO 9001:2010 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. 52 z 175

3.5. Oprogramowanie dziedzinowe 3.5.1. System HIS L.P. Podmiot Producent Nazwa Wersja wsparcie [TAK/NIE] 1. Krakowskie Centrum Rehabilitacji i Ortopedii Asseco Infomedica 4.32.0.2 Tak 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Asseco InfoMedica 4.32.2 Tak 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Politechnika Poznańska ESKULAP 4.4.1 bw Tak 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie Asseco InfoMedica 4.32.0.0 Tak 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 6. Szpital Specjalistyczny im. J. Dietla w Krakowie 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Asseco GEM Informatyczne Systemy InfoMedica AMMS InfoMedica 4.32.2 AMMS 5.12.2.6 Tak SIS Brak wersjonowania Tak Comarch (Esaprojekt) Optimed 6.00.360 Tak 3.5.2. System LIS - analityka L.P. Podmiot producent Nazwa Wersja wsparcie Integracja z HIS 1. Krakowskie Centrum Rehabilitacji i Ortopedii Zewnętrzne (Brak Nie Brak Brak danych o producencie) dotyczy Tak 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Asseco InfoMedica 4.28.0 Tak Tak 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Politechnika Poznańska ESKULAP 2.3.0 s Tak Tak 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie ProfLab ProfLab 1.0.9.50 Nie Tak 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Asseco InfoMedica 4.32 Tak Tak 6. Szpital Specjalistyczny im. J. Dietla w Krakowie 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. GEM Informatyczne Systemy SIS Brak wersjonowania Marcel Centrum 2.440.10.1285 Tak Tak 3.5.3. System LIS - bakteriologia L.P. Podmiot producent Nazwa Wersja wsparcie Integracja z HIS 1. Krakowskie Centrum Rehabilitacji i Ortopedii Zewnętrzne (Brak Nie Brak Brak danych o producencie) dotyczy Tak 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Biomerieux Mikrobionet 2.0 Tak Tak 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Politechnika Poznańska ESKULAP 1.2.1 h Tak Tak 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie Proflab ProfLab 1.0.9.50 Tak Tak 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Asseco InfoMedica 4.32 Tak Tak TAK Tak

Opis Przedmiotu Zamówienia 6. Szpital Specjalistyczny im. J. Dietla w Krakowie 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. GEM Informatyczne Systemy SIS Brak wersjonowania Marcel Centrum 2.440.10.1285 Tak Tak TAK Tak 3.5.4. System RIS L.P. Podmiot Producent Nazwa Wersja wsparcie Integracja z HIS (wyniki opisowe) 1. Krakowskie Centrum Rehabilitacji i Ortopedii G&K Medical Systems Pergamon MED 1.1 Tak Nie 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie CGM NetRAAD 6.21.4 Tak Tak 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Agfa IMPAX 2.3.0 r Tak Tak 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie Gabos Medicus 3.860 Tak Tak 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie TMS-Soft TMS ORION 1.4.327 Tak Tak 6. Szpital Specjalistyczny im. J. Dietla w Krakowie GEM Systemy Brak SIS Informatyczne wersjonowania Tak Tak 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Comarch (Esaprojekt) CRID 3.1.14.4 Tak Tak 3.5.5. System PACS L.P. Podmiot producent Nazwa Wersja wsparcie Integracja z HIS 1. Krakowskie Centrum Rehabilitacji i Ortopedii G&K Medical Systems PergamonMED 1.1 Tak Nie 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie MediMatic ComPACS 10.6.3.3 CGM NetRAAD 6.21.4 Tak Tak 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Agfa IMPAX 6.4.0.4 513 Tak Nie 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie Infinitt Healthcare Infinitt 3.0.11.3(BN8) Tak Tak 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Ashvins Archive Nie MedicalCommunication PACS-WEB 2009 Tak (Link do s Soft (ASHVINS) WebExtreme obrazów) 2009 Ostatnia do 6. Szpital Specjalistyczny im. J. Dietla w Krakowie PIXEL ExPACS wygaśnięcia wsparcia, tj. Tak Nie 01.12.2016 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Synektik ARPACS 2.143.145. Tak Tak 54 z 175

Opis Przedmiotu Zamówienia L. P. 3.5.6. E-Rejestracja Podmiot 1. Krakowskie Centrum Rehabilitacji i Ortopedii Tak 2. 3. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Szpital Specjalistyczny Nowym Sączu im. J. Śniadeckiego w 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 6. Szpital Specjalistyczny im. J. Dietla w Krakowie 7. L. P. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. 3.5.7. Elektroniczna Dokumentacja Medyczna Podmiot Czy jest świadczona Nie, (w trakcie wdrożenia) Producent Nazwa/Uwagi Wersja Grupa Leonardo Asseco Arkusz e-rejestracji na stronie www Medyczny Portal Informacyjny erejestracja 1.0 Nie Brak danych (w trakcie wdrożenia) Nie Brak Brak Brak Nie Nie (w trakcie projektowania) Tak Nie (w trakcie projektowania) Tak Czy jest świadczona Jeszcze wybrano Asseco nie Planowane wdrożenie w roku 2014 Szpitalny Informacyjny Portal Brak 3.1.0.29914 zintegrowany HIS Brak Brak Brak Nie Szpital Specjalistyczny im. L.Rydygiera sp. z o.o. Dział Informatyki Oprogramowanie autorskie wykonane we własnym zakresie Producent Nazwa/Uwagi Wersja z Możliwość podłączenie pozostałych Nie Nie 1.0 Nie. 1. Krakowskie Centrum Rehabilitacji i Ortopedii Nie Brak Brak Brak Brak 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Nie Brak Brak Brak Brak 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Nie Brak Brak Brak Brak 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie Nie Brak Brak Brak Brak 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Tak Asseco EDM 1.2.2 Nie 6. Szpital Specjalistyczny im. J. Dietla w Krakowie Nie Brak Brak Brak Brak 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Nie Brak Brak Brak Brak Nie Ograniczenia licencyjne i techniczne Możliwość podłączenie pozostałych 55 z 175

3.5.8. 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 i zintegrowanie jej z już obecnym rozwiązaniami. 3.6. Rodzaje przetwarzanych danych Legenda: 01 - Krakowskie Centrum Rehabilitacji i Ortopedii 02 - Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie 03 - Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 04 - Szpital Wojewódzki im. św. Łukasza w Tarnowie 05 - Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 06 - Szpital Specjalistyczny i. J. Dietla w Krakowie 07 - 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 04 05 06 07 dokumenty podstawowe - priorytet 1 1 Formularz historii choroby HIS HIS HIS HIS HIS HIS HIS 2 Wywiad lekarski HIS HIS HIS HIS HIS HIS HIS 3 Epikryza HIS HIS HIS HIS HIS HIS HIS 4 Karta informacyjna z leczenia szpitalnego HIS HIS HIS HIS HIS HIS HIS 5 Opis przebiegu leczenia - HIS HIS HIS HIS HIS - 6 Wyniki badań laboratoryjnych analityka HIS HIS HIS HIS HIS HIS HIS/LIS 7 Wyniki badan laboratoryjnych bakteriologia HIS HIS HIS HIS HIS HIS HIS/LIS 8 Wyniki badań diagnostyki obrazowej opis - HIS HIS HIS HIS HIS HIS/RIS 9 Wyniki konsultacji - HIS HIS - HIS HIS - 10 Protokół operacyjny HIS HIS HIS HIS - HIS HIS 11 Karta zleceń lekarskich HIS HIS HIS HIS HIS HIS - dokumenty rzadko spotykane w HIS - priorytet 2 12 Wywiad epidemiologiczny - HIS 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 - - HIS HIS 15 Plan opieki - - HIS - HIS HIS - 16 Karta gorączkowa - - HIS HIS HIS HIS HIS 17 Karta indywidualnej opieki pielęgniarskiej - - - - HIS HIS - 18 Karta obserwacyjna - - HIS - - HIS - 19 Karta wywiadu pielęgniarskiego - HIS HIS - HIS HIS -

20 Raport pielęgniarski - - - - HIS HIS - dokumenty nie wychodzące ze szpitala - brak konieczności wymiany pomiędzy jednostkami 21 Karta procesu sterylizacji - - - - - - - 22 Karta kwalifikacyjna do zabiegu - - HIS - HIS HIS - 23 Karta przebiegu znieczulenia - - HIS - HIS HIS - 24 Okołooperacyjna Karta Kontrolna - HIS - - - - - 25 Karta zabiegów fizjoterapeutycznych - - - - - HIS - 26 Karty TISS - HIS - HIS - - - 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 04 05 06 07 Ilość hospitalizacji w roku 1643 26000 28000 31000 5500 15000 28000 Roczny przyrost danych [MB]- priorytet 1 1 Formularz historii choroby 431 7800 8400 9300 1650 4500 8400 2 Wywiad lekarski 431 7800 8400 9300 1650 4500 8400 3 Epikryza 431 7800 8400 9300 1650 4500 8400 4 Karta informacyjna z leczenia szpitalnego 431 7800 8400 9300 1650 4500 8400 5 Opis przebiegu leczenia 431 7800 8400 9300 1650 4500 8400 6 Wyniki badań laboratoryjnych analityka 431 7800 8400 9300 1650 4500 8400 7 Wyniki badan laboratoryjnych bakteriologia 431 7800 8400 9300 1650 4500 8700 8 Wyniki badań diagnostyki obrazowej opis 431 7800 8400 9300 1650 4500 45000 9 Wyniki konsultacji 431 7800 8400 9300 1650 4500 8400 10 Protokół operacyjny 25 468 504 558 0 270 504 11 Karta zleceń lekarskich 431 7800 8400 9300 1650 4500 8400 dokumenty rzadko spotykane w HIS - priorytet 2 12 Wywiad epidemiologiczny 431 7800 8400 9300 1650 4500 8400 13 Karta Oceny Ryzyka Zakażenia przy Przyjęciu do Szpitala 431 7800 8400 9300 1650 4500 8400 14 Ocena ryzyka związanego ze stanem odżywienia 431 7800 8400 9300 1650 4500 8400 dokumenty pielęgniarskie - priorytet 3 15 Plan opieki 431 7800 8400 9300 1650 4500 8400 16 Karta gorączkowa 431 7800 8400 9300 1650 4500 8400 17 Karta indywidualnej opieki pielęgniarskiej 431 7800 8400 9300 1650 4500 8400 18 Karta obserwacyjna 431 7800 8400 9300 1650 4500 8400 19 Karta wywiadu pielęgniarskiego 431 7800 8400 9300 1650 4500 8400 20 Raport pielęgniarski 431 7800 8400 9300 1650 4500 8400 57 z 175

W poniższej tabeli wskazano roczny przyrost danych medycznych obrazowych w [GB] L.P. Podmiot Roczny przyrost danych w [GB] 1. Krakowskie Centrum Rehabilitacji i Ortopedii 35 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie 3000 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 1900 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie 1450 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 1000 6. Szpital Specjalistyczny im. J. Dietla w Krakowie 8000 7. 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. W obszarze usługi e-rejestracja sytuacja jest inna, ponieważ funkcjonalność tej usługi wiąże je w ścisły sposób z oprogramowaniem klasy HIS. Użytkownicy ze strony szpitali oczekują wręcz, że usługa będzie zintegrowana w stopniu maksymalnym z oprogramowaniem klasy HIS, będąc dla nich przezroczysta. 3.7.1. Opieka serwisowa (ilość miesięcy do wygaśnięcia umowy) L.P Podmiot HIS LIS RIS PACS 1. Umowa 1. przedłużan Krakowskie Centrum Rehabilitacji i a co rok na Ortopedii 12 17 27 27 miesięcy. 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie 1 1 8 8 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu 1 1 1 1 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie 24 12 12 12 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie 13 3 2 2 6. Szpital Specjalistyczny im. J. Dietla w Krakowie 26 26 26 36 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. 13 17 13 24 3.7.2. Opieka serwisowa (SLA czas reakcji na błąd krytyczny w godzinach) L.P Podmiot HIS LIS RIS PACS 1. Krakowskie Centrum Rehabilitacji i 48 48 24 24 58 z 175

2. 3. 4. 5. 6. 7. Ortopedii Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Szpital Wojewódzki im. św. Łukasza w Tarnowie Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Szpital Specjalistyczny im. J. Dietla w Krakowie Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. 4 4 1 1 48 48 48 48 72 48 48 48 72 72 72 72 8 8 8 12 24 24 24 24 3.7.3. Integracja z systemem HIS L.P Podmiot LIS RIS PACS 1. Krakowskie Centrum Rehabilitacji i Ortopedii Tak Nie Nie 2. Krakowski Szpital Specjalistyczny im. Jana Pawła II w Krakowie Tak Tak Tak 3. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu Tak Tak Nie 4. Szpital Wojewódzki im. św. Łukasza w Tarnowie Tak Tak Nie 5. Wojewódzki Specjalistyczny Szpital im. św. Ludwika w Krakowie Tak Tak Nie 6. Szpital Specjalistyczny im. J. Dietla w Krakowie Tak Tak Nie 7. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o. Tak Tak Tak 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. 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. Pobranie EDM powinno być możliwe przy pomocy usług sieciowych z poziomu platformy regionalnej oraz przy pomocy oprogramowania dziedzinowego HIS, które dla lekarzy stanowi podstawowe narzędzie pracy. Dla pacjentów przewiduje się pobranie EDM przy użyciu dedykowanych narzędzi opracowywanych przez CSIOZ (IKP). 59 z 175

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. Komponent regionalny i komponenty lokalne muszą być wdrożone co najmniej we wskazanym podziale funkcjonalnym (podział może zostać rozszerzony, ale nie może zostać zawężony). 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 dowolnej EDM, zgodnie z potrzebami i oczekiwaniami poszczególnych Podmiotów. Repozytorium EDM musi wystawiać i obsługiwać interfejs przekazywania i rejestracji EDM zgodnie z wytycznymi ITI-41 profilu integracyjnego XDS.b. Repozytorium EDM musi obsługiwać interfejs pozwalający na pobranie EDM uwierzytelnionemu użytkownikowi zgodnie z wytycznymi ITI- 43. 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. System HIS (jako system zewnętrzny do dostosowania) System HIS Szpitala jest systemem dziedzinowym, będący przedmiotem zamówienia tylko w obszarze jego dostosowania do generowania, przesyłania i odczytywania EDM zgodnie z założeniami Repozytorium EDM. System HIS musi przekazywać EDM opatrzoną podpisem elektronicznym do Repozytorium EDM zgodnie z interfejsem ITI-41. System HIS musi być klientem usług wyszukiwania, pobierania, transformacji i e-rejestracji, co oznacza, że z poziomu systemu HIS musi być dostęp do wszystkich funkcjonalności oferowanych przez te usługi. Funkcjonalność usług musi być zintegrowana z logiką systemu HIS. Systemy HIS występujące u Partnerów Projektu muszą być dostosowane do wymagań stawianych przez system MSIM, w szczególności: Systemy HIS musza generować EDM zgodnie z wymaganiami interfejsów systemu MSIM Systemy HIS muszą być klientami usług wyszukiwania, pobierania i transformacji EDM Systemy HIS muszą być klientami usługi e-rejestracja i posiadać moduły pozwalające na integracje z systemem e-rejestracji znajdującym się w regionie Systemy HIS muszą wykorzystywać usługę podpisu elektronicznego w zakresie podpisywania EDM z poziomu systemów HIS W przypadku, gdy Szpital posiada moduł do generowania EDM jako część zintegrowanego systemu HIS, Wykonawca musi wykorzystać i dostosować ten moduł do funkcjonowania w Systemie MSIM. Dostosowanie oznacza przekazanie EDM do repozytorium EDM z wykorzystaniem interfejsu ITI-41. 60 z 175

4.1.3. Systemy dziedzinowe (źródłowe) 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) 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.4. Usługa e-rejestracja (lokalna) Usługa e-rejestracja lokalnej jest wydzieloną usługą aplikacyjną lub częścią systemu dziedzinowego HIS. Usługa e-rejestracja lokalnej musi być zintegrowana z systemami dziedzinowymi oraz pozostałymi komponentami systemu MSIM w zakresie obsługi procesu e-rejestracji zgodnie z analizą procesów biznesowych przedstawioną w modelu dynamicznym Systemu. Wykonawca musi wdrożyć część lokalną usługi e-rejestracja na podstawie analizy aktualnie posiadanego przez Partnerów Projektu oprogramowania w tym obszarze, w szczególności u Partnerów posiadających już oprogramowanie e-rejestracja Wykonawca musi zintegrować się z tym rozwiązaniem i rozbudować je do potrzeb projektu MSIM Projekt pilotażowy. 4.1.5. 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). 4.1.6. Usługa integracji Usługa integracji musi obsługiwać komunikację z węzłem regionalnym oraz platformą P1 Usługa integracji musi obsługiwać komunikację z przewidzianymi systemami dziedzinowymi, w tym: Wystawiać interfejsy zgodnie z wytycznymi profilu XDS.b Obsługiwać wywołania interfejsów Umożliwiać definiowanie procesów biznesowych związanych z przetwarzaniem EDM Integracja poszczególnych podsystemów powinna odbywać się za pomocą usług sieciowych w oparciu o szyny danych regionalną i lokalne umieszczone w szpitalach. Wykonawca przygotuje w uzgodnieniu z Wnioskodawcą Projekt Techniczny Systemu MSIM, w którym przedstawi założenia dot. integracji istniejących systemów u Partnerów projektu z projektowanym Systemem MSIM. Wykonawca Systemu MSIM przeanalizuje rozwiązania wdrożone u Partnerów Projektu w kontekście możliwości ich wykorzystania w ramach realizacji zadania implementacji i wdrożenia MSIM. W przypadku systemów dziedzinowych HIS niezbędna będzie ich integracja z wdrażanymi w ramach projektu lub istniejącym repozytoriami EDM a następnie z warstwą regionalną, w szczególności z systemem e-rejestracji. 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 IKP. Zostanie stworzona platforma integrująca (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 61 z 175

zaplanowano zakup 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 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 v.3, 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). 4.1.7. 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 rozwiązanie było w możliwie największym stopniu odporne 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. Dla pacjentów źródłem identyfikacji będzie P1 (obsługiwany przez wydzieloną usługę) lub w przypadku usługi e-rejestracja baza wewnętrzna. 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. 62 z 175

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. 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ć: Przeglądanie rejestru EDM Skonstruowanie i wysłanie zapytania o pozycję rejestru Wyświetlenie wyników zapytania Przeglądanie historii Przeglądanie praw dostępu Wnioskowanie o zmianę praw dostępu Edycję profilu użytkownika 4.2.5. Usługa pobierania EDM Musi umożliwiać klientom (np. systemowi P1 w zakresie IKP) przesłanie zapytania do repozytorium EDM zgodnie z wytycznymi ITI-43 profilu integracyjnego XDS.b. Usługa musi umożliwiać: Przeglądanie repozytorium EDM Skonstruowanie i wysłanie zapytania o pozycję repozytorium Wyświetlenie wyników zapytania Zamówienie EDM (pobranie w trybie asynchronicznym) Odebranie EDM po wcześniejszym zamówieniu Przeglądanie zamówionej EDM Przeglądanie historii Przeglądanie praw dostępu Wnioskowanie o zmianę praw dostępu Edycję profilu użytkownika Usługa musi wspierać możliwość 3-poziomowego wyboru zakresu pobieranej dokumentacji medycznej, co oznacza, że klient usługi będzie mógł skorzystać z następujących wariantów zamówienia/pobrania dokumentacji: 63 z 175

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ść). 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) Wszystkie funkcje usługi dla klientów muszą być dostępne przez interfejs webowy. 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. 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: 64 z 175

Odwzorowanie terminu z jednego słownika do innego Wyszukanie terminu Wyszukanie podobnego terminu Wyszukanie najbliższego terminu 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) 4.2.9. Usługa synchronizacji rejestrów EDM Usługa musi umożliwiać synchronizację regionalnego i lokalnych rejestrów 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). 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, itp.) 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. 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 65 z 175

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.2.12. Moduł analiz i raportów Moduł odpowiedzialny za wykonywanie analiz i generowanie raportów. Umożliwiać będzie m. in. generowanie zestawień/raportów pozwalających na weryfikację czy przyjęte wskaźniki są dotrzymane. 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 szynie usług (regionalnej lub lokalnej). Integracja pomiędzy lokalnym EDM a systemami dziedzinowymi musi następować w oparciu o paradygmat usługowy, co oznacza że pomiędzy lokalnym repozytorium EDM a systemami dziedzinowymi istnieje warstwa integracji w postaci szyny usług, na której uruchomione są usługi przekazywania i rejestracji EDM zgodnie z profilem integracyjnym XDS.b. 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. 66 z 175

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. 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. 67 z 175

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 5.2.3. Grupy procesów Opracowane procesy biznesowe są tematycznie pogrupowane i przedstawione wspólnie na diagramach. Bezpośrednią zależność procesów przedstawiono na diagramach za pomocą związków w postaci przerywanych strzałek - tak jak to pokazano poniżej. 68 z 175