Contract
Załącznik nr 9
Dotyczy przetargu nieograniczonego na zamówienie pn.: Stworzenie oraz kompletne wdrożenie Małopolskiego Systemu Informacji Medycznej - projekt pilotażowy, w ramach Małopolskiego Regionalnego Programu Operacyjnego na lata 2007 – 2013 (399/ZP/2014).
Opis przedmiotu zamówienia (OPZ)
Małopolski System Informacji Medycznej – projekt pilotażowy
2. Wymagania podstawowe do realizacji Systemu MSIM 5
2.2. Ogólne wymagania jakie powinien spełniać system MSIM 11
2.3. Koncepcja wykonania i dostawy, instalacji, konfiguracji, wdrożenia, uruchomienia oraz integracji systemu MSIM 15
2.4. Dyslokacja elementów systemu 18
2.5. Zasady budowy reguł interoperacyjności w systemie 19
2.6. Koncepcja synchronizacji czasu – normalizacji czasu 19
2.7. Koncepcja autentykacji i identyfikacji użytkowników 20
2.8. Koncepcja współpracy z Internetowym Kontem Pacjenta (IKP) 20
2.9. Koncepcja przesyłania dokumentacji o dużej pojemności 22
2.10. Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych jednostek 23
2.11. Schemat połączeń pomiędzy elementami systemu 23
2.12. Interfejsy komunikacyjne z innymi systemami informatycznymi 27
2.13. Koncepcja komunikacji pomiędzy jednostkami 28
2.14. Koncepcja przesyłu danych pomiędzy jednostkami 30
2.15. Integracja systemów oraz danych z innych systemów do wdrażanego systemu MSIM 31
2.16. Koncepcja wirtualizacji zasobów informatycznych 31
3. Analiza stanu aktualnego 31
3.1. Infrastruktura informatyczna 31
3.2. Infrastruktura sieciowa 39
3.4. Procedury bezpieczeństwa 42
3.5. Oprogramowanie dziedzinowe 43
3.6. Rodzaje przetwarzanych danych 45
3.8. Lokalne słowniki dokumentów 48
5.3. Mapa główna procesów biznesowych 57
6.2. Wymagania ogólne interfejsu użytkownika 72
6.3. Wymagania prawne, organizacyjne i funkcjonalne 72
6.4. Wymagania wydajnościowe systemu 77
6.5. Wymagania skalowalności 78
6.6. Wymagania wolumenu przetwarzanych danych 78
6.7. Wymagania niezawodności 78
6.8. Wymagania bezpieczeństwa 79
6.9. Ochrona danych osobowych 80
6.10. Wymagania systemu zarządzania tożsamością 81
6.11. Procedury nadawania/zmiany/odbierania uprawnień 82
6.14. Wymagania warstwy integracji 89
7.1. Infrastruktura serwerowa 98
7.2. Komunikacja 111
7.3. Bezpieczeństwo 119
7.4. Pozostałe elementy 127
7.5. Oprogramowanie systemowe 131
8. Platforma danych 137
8.1. Metadane dla źródeł danych 137
8.2. Model biznesowy platformy danych 138
9. Metodyka wdrożenia Systemu 139
9.1. Dokumentacja 139
9.2. Szkolenia 142
9.3. Odbiór 148
9.4. Eksploatacja 150
10. Gwarancja oraz wsparcie 152
10.1. Gwarancja 152
10.2. Wsparcie 155
11. Licencjonowanie 157
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 3 podmioty lecznicze z terenu województwa małopolskiego:
• Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu,
• Szpital Specjalistyczny im. J. Dietla w Krakowie,
• Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx 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 wsparcie.
Szczegółowe wymagania dla powyższych produktów zdefiniowane zostały w kolejnych rozdziałach.
2. Wymagania podstawowe do realizacji Systemu MSIM
2.1. Założenia projektowe
2.1.1.Warstwy MSIM
System MSIM ma zapewniać rozdzielność warstwy regionalnej i warstwy lokalnej. Planowane rozwiązanie nie pozwala na bezpośredni dostęp do systemów dziedzinowych Szpitali z poziomu warstwy regionalnej.
Warstwa regionalna
Warstwa lokalna
HIS
LIS
RIS
PACS
.
Rysunek 1. Separacja dostępu do systemów dziedzinowych (źródłowych).
Wymiana Elektronicznej Dokumentacji Medycznej jest realizowana dwustronnie na osi Warstwa lokalna ↔ Warstwa regionalna oraz HIS ↔ Warstwa lokalna. Z kolei e-Rejestracja jest zasilana za pośrednictwem WebService’ów i może się komunikować z HIS w zakresie wymiany grafików, terminów, informacji o kolejkach oczekujących. Pozostałe systemy dziedzinowe takie jak LIS, RIS, PACS nie są integrowane z warstwą lokalną (ew. pośrednio poprzez HIS). Integracja z systemami HIS, jak i z systemami LIS, RIS i PACS jest poza zakresem zamówienia.
Pod względem architektury rozwiązania cały system wymiany dokumentów i danych medycznych jest podzielony na część regionalną, w której funkcjonować będą elementy systemu odpowiadające za interoperacyjność rozwiązania oraz część lokalną, działającą w poszczególnych jednostkach medycznych wchodzących w skład domeny. Dokumentacja medyczna jest gromadzona w EDM, które są elementem dostawy w warstwie lokalnej, natomiast warstwa regionalna zawiera jedynie jej indeks.
W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji pacjentów, pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą metadane wszystkich dokumentów). Ustalany jest też schemat i zasady identyfikacji obiektów powstających w systemie oraz ich wersjonowaniem.
W poszczególnych szpitalach zostaną utworzone Lokalne Repozytoria EDM, które pozwalać będą na gromadzenie, przechowywanie i przesyłanie zgodnie z przepisami (Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia oraz Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania) dokumentacji medycznej. Integracja warstwy regionalnej i lokalnej powinna odbywać się za pomocą usług sieciowych w oparciu o regionalną szynę danych. W szpitalach będzie konieczne wykonanie integracji z WebSerwisami dostawców HIS wykonanymi w ramach odrębnego zlecenia.
Warstwa regionalna MSIM
Regionalna Szyna Usług
Warstwa lokalna MSIM
HIS
Integracja z WebSerwisami dostawców HIS
Rysunek 2. Metody integracji w MSIM.
Zamawiający jednocześnie nie określa sposobu wewnętrznej wymiany danych w ramach dostarczanych w ramach zamówienia modułów (tj. w przypadku, gdy oprogramowanie Wykonawcy będzie miało jakąś wewnętrzną strukturę – to nie określa sposobu wymiany danych w ramach oferowanego oprogramowania).
2.1.2. Wymiana EDM
W zakresie wymiany EDM rozwiązanie przewiduje podział funkcjonalny na warstwę lokalną i warstwę regionalną według poniższych wytycznych.
Rejestr dokumentów EDM
(warstwa regionalna MSIM)
EDM
(warstwa lokalna MSIM)
Adapter komunikacyjny
(warstwa lokalna MSIM)
Interfejs z HIS
HIS
Rysunek 3. Wymiana danych w zakresie EDM.
Warstwa lokalna – gdzie będzie wdrożony moduł odpowiedzialny za wytwarzanie, gromadzenie i przesyłanie EDM oraz usługi towarzyszące pozwalające na integrację z węzłem regionalnym. W warstwie lokalnej będzie gromadzona EDM zgodna z Załącznikiem 9A „Standard wymiany danych pomiędzy HIS i MSIM”, 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.
Warstwa regionalna – gdzie wdrożony będzie rejestr EDM, który zawiera rejestr dokumentów czyli tzw. indeks EDM znajdującej się we wszystkich lokalnych repozytoriach EDM.
W przypadku konieczności pobrania przez lekarza pełnej dokumentacji medycznej pacjenta z konkretnego pobytu/wizyty wymaga się możliwość jej zamówienia/pobrania jedynie w trzech wariantach możliwych do wybrania przez Użytkownika:
• Podstawowa dokumentacja medyczna (m. in. dokumentacja zewnętrzna: karta informacyjna, karta porady specjalistycznej, karta informacyjna SOR).
• Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza objętość).
• Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość)
Wymagane rozwiązanie zapewni w przypadku konieczności zapoznania się z bardziej szczegółową dokumentacją pobranie jej w komplecie dla danego pobytu, przez co gwarantuje się analizę danych diagnostycznych i z procesu leczenia w kontekście całego pobytu. Eliminuje to zagrożenie opierania się podczas decyzji leczniczych na pobranym dokumencie (np. z danymi diagnostyki laboratoryjnej) bez kontekstu procesu leczenia wdrożonego podczas danego pobytu.
W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji pacjentów, pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą metadane wszystkich dokumentów).
W warstwie regionalnej będzie realizowana większość usług (np. wyszukiwanie, przeglądanie, pobieranie, przekazywanie do innych podmiotów). Rozwiązanie takie minimalizuje warunki techniczne potrzebne w warstwie lokalnej do sprawnego funkcjonowania systemu – wszelkie zapytania od strony klientów obsługiwane są wyłącznie z wykorzystaniem warstwy regionalnej.
Przedmiotem zamówienia w ramach MSIM jest:
• warstwa regionalna (rejestr EDM),
• EDM w warstwie lokalnej,
• adapter komunikacyjny.
Pozostałe elementy wymiany EDM są realizowane w toku umów z dostawcami HIS.
2.1.3. E-Rejestracja
e-Rejestracja partnera
(poza MSIM)
Szczególną usługą realizowaną w ramach komponentu regionalnego jest usługa e-Rejestracji. Usługa e-Rejestracji udostępnia funkcjonalność rezerwacji usług medycznych w jednostkach ochrony zdrowia zintegrowanych z MSIM.
e-Rejestracja MSIM
(warstwa regionalna MSIM)
HIS
Rysunek 4. Wymiana danych w ramach e-Rejestracji.
Użytkownik ma możliwość rejestracji na wskazany termin i anulowania wizyty. Z e-Rejestracji mogą korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi (pacjenci). W ramach usługi powinien funkcjonować system komunikatów (powiadomień dla użytkowników końcowych w formie np. wiadomości e-mail i SMS) dotyczących: potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno przez użytkownika jak i w lokalnym systemie medycznym HIS). W szczególności usługa obejmuje następujące funkcjonalności:
• Przegląd listy usług możliwych do realizacji w placówce Zamawiającego dla pacjenta.
• Przegląd listy usług możliwych do rezerwacji przez Internet.
• Możliwość rezerwacji terminu usługi do wybranej poradni lub wybranego lekarza.
• Określenie celu wizyty u lekarza, z podziałem na: przypadek nagły incydentalny, stan nagły przy chorobie przewlekłej, wizytę kontrolną, wizytę po kolejną receptę, wizytę po skierowanie na badanie specjalistyczne.
• Udostępnienie danych o zaplanowanych wizytach i usługach.
• Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana).
• Możliwość wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko pacjenta, numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla pacjenta.
• Dostęp do informacji o lokalizacji miejsca wykonania usługi.
• Możliwość odwołania rezerwacji.
• Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail).
Zamówieniem objęta jest:
• e-Rejestracja na poziomie regionalnym integrująca jednostki w ramach MSIM,
• dostarczenie, zainstalowanie i skonfigurowanie serwera e-mail na potrzeby powiadomień MSM.
Współpraca z dostawcami HIS i dostarczenie interfejsów jest poza zamówieniem (realizowana w toku odrębnych umów). Poza zamówieniem jest również dostarczenie bramki SMS.
Poza tą rejestracją mogą występować inne moduły e-Rejestracji na poziomie poszczególnych partnerów, jednak – o ile zostanie utrzymana decyzja o ich eksploatacji. Zamawiający nie wymaga przeprowadzania integracji pomiędzy e-Rejestracją na poziomie regionalnym, a ewentualnymi rejestracjami lokalnymi.
2.1.4. Podstawowe standardy wykonania MSIM
Głównym celem proponowanego rozwiązania jest usprawnienie zarządzania i podniesienie jakości procesów leczniczych w podmiotach leczniczych objętych systemem, poprzez rozbudowę i rozszerzenie stanu istniejącego przedstawionego w analizie stanu obecnego. Rozbudowa ma na celu bezpieczne i zgodne z prawem wytwarzanie, przechowywanie, oraz przekazywanie dokumentów medycznych pomiędzy jednostkami oraz integrację z tworzoną na szczeblu krajowym Elektroniczną Platformą Gromadzenia Informacji O Zdarzeniach Medycznych (projekt P1).
W celu zapewnienia dalszej łatwej rozbudowy oraz integracji z nowymi systemami wymaga się, aby system w jak największym stopniu oparty był o obowiązujące w tej dziedzinie na świecie standardy i dobre praktyki. Najszerzej przyjętym w chwili obecnej standardem dotyczącym przekazywania dokumentacji pomiędzy szpitalami jest profil XDS.b proponowany przez międzynarodową organizację IHE Wykonawca powinien dostarczać WebSerwis’y umożliwiające zewnętrzną wymianę danych zgodnie z profilem XDS.b, jakkolwiek nie jest wymagane, aby Wykonawca korzystał z tego standardu w komunikacji w ramach komunikacji pomiędzy dostarczanymi komponentami MSIM. Profil ten opisuje procesy i komunikaty jakie muszą zostać wymienione pomiędzy dwoma jednostkami, aby nastąpiło poprawne przekazanie dokumentu medycznego. Standard wspierany jest obecnie przez większość głównych dostawców oprogramowania medycznego na świecie.
Sam układ dokumentu medycznego powinien być zdefiniowany w języku XML, w oparciu o najszerzej przyjęty na świecie format dokumentu opracowany przez organizację HL7 CDA R2 na 3- cim poziomie interoperacyjności (w zakresie, gdy to jest możliwe w pozostałych wypadkach należy stosować poziom 2-gi i 1-szy – w szczególności dla zeskanowanych dokumentów dopuszcza się 1-szy poziom interoperacyjności). HL7 CDA R2 na trzecim poziomie interoperacyjności zostało także zaproponowane jako podstawowy format dokumentów medycznych na poziomie krajowym przez Centrum Systemów Informatycznych w Ochronie Zdrowia.
Na etapie Analizy Przedwdrożeniowej uwzględniona zostanie kwestia dostosowania/ujednolicenia istniejących słowników, formatów danych i standardów danych słownikowych w celu wykonania poprawnej integracji/wymiany danych pomiędzy systemami dziedzinowymi zlokalizowanymi w warstwach lokalnych, a warstwą regionalną.
Pod względem architektury rozwiązania cały system wymiany dokumentów i danych medycznych podzielony powinien być na część regionalną, w której funkcjonować będą elementy systemu odpowiadające za interoperacyjność rozwiązania oraz część lokalną, działającą w poszczególnych jednostkach medycznych. Warstwa regionalna może być posadowiona w lokalizacji jednego z uczestników projektu.
W przyszłości planuje się rozwój systemu co najmniej w następujących aspektach:
• Podłączanie nowych jednostek do systemu.
• Rozszerzanie zakresu wymienianych danych zarówno w aspekcie dodatkowych danych do obecnie wymienianych dokumentów, jak i podłączania nowych systemów dziedzinowych.
• 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ę integracji z usługami sieciowymi systemów dziedzinowych, które zostaną udostępnione przez każdego z partnerów. Integracja ta musi pozwalać systemom dziedzinowym na zasilenie lokalnych EDM dokumentami medycznymi wytworzonymi przez te systemy funkcjonujące w jednostkach medycznych z Repozytorium Elektronicznej Dokumentacji Medycznej. W warstwie lokalnej (jednostkach medycznych) zaimplementowany zostanie moduł gromadzenia danych odbierający dokumentację medyczną wytwarzaną w systemach dziedzinowych funkcjonujących w jednostce. W warstwie regionalnej wdrożona zostanie platforma integrująca odpowiedzialna za komunikację pomiędzy jednostkami medycznymi oraz udostępnianie, przesłanie do zamawiającego (pacjenta, jednostki medycznej) dokumentacji medycznej gromadzonej w ramach systemów dziedzinowych tych jednostek. Ponadto niezbędna będzie integracja warstwy regionalnej z Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (P1)) w szczególności w zakresie IKP w zakresie zgodnym z aktualną dokumentacją projektu P1.
• System udostępniania dokumentacji medycznej
Wymagane jest dostarczenie infrastruktury sprzętowej i programowej oraz wdrożenie usługi pozwalającej na udostępnianie w jednostkach medycznych (warstwa lokalna systemu MSIM) w jednym miejscu (moduł wymiany danych) dokumentacji medycznej z różnych systemów dziedzinowych funkcjonujących w tych jednostkach (ewentualna wymiana danych z systemami RIS. LIS, PACS i innych będzie się odbywać za pośrednictwem HIS). . Rozwiązanie będzie zbudowane w architekturze rozproszonej – moduł wymiany zostanie zaimplementowany w każdej jednostce medycznej uczestniczącej w projekcie (w szczególności może być zrealizowany przez lokalny EDM dostarczony w ramach projektu). Szczególowa koncepcja mumodułu w zostanie określona na etapie Analizy przedwdrożeniowej. Komunikacja pomiędzy modułami, a także dostęp do dokumentacji medycznej będzie realizowany za pomocą usług uruchomionych na platformie integującej w warstwie regionalnej systemu MSIM.
• Wdrożenie platformy integrującej wymianę elektronicznej dokumentacji medycznej na poziomie regionalnym
Wymaga się stworzenia platformy integrującej (warstwa regionalna systemu MSIM) z wykorzystaniem technologii szyny danych oraz interfejsów integracyjnych, która zapewni komunikację i wymianę dokumentacji medycznej pomiędzy jednostkami medycznymi w regionie a także umożliwi dostęp do dokumentacji dla pacjenta. W ramach tego elementu ma zostać zrealizowane dostarczenie infrastruktury sprzętowej i programowej oraz wdrożenie usług umożliwiających wyszukiwanie, prezentację oraz wymianę/udostępnianie dokumentacji medycznej. Platforma ta zostanie zintegrowana z projektem P1 w zakresie indeksowania i udostępniania dokumentacji medycznej zamawianej przez pacjenta za pomocą IKP.
Wymiana dokumentacji medycznej w ramach platformy integracyjnej będzie realizowana zgodne z przyjętymi standardowymi protokołami w ochronie zdrowia (HL7 CDA R2 na poziomie 3-cim interoperacyjności, DICOM, XML i PDF zgodne z Rozporządzeniem Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania) w zakresie przekazywanym do lokalnych EDM przez systemy HIS.
• Wdrożenie elektronicznych usług medycznych
Zakłada się uruchomienie elektronicznych usług dostępnych w warstwie regionalnej systemu MSIM:
1. Wyszukiwanie dokumentacji medycznej pacjenta:
Usługa dostępna dla personelu medycznego będzie umożliwiać wyszukanie dokumentacji pacjenta wg określonych kryteriów takich jak dane pacjenta, rodzaju usługi medycznej, data czy jednostka medyczna. Wynik wyszukiwania będzie miał postać listy z możliwością jej pogrupowanej wg określonych kryteriów takich jak jednostka medyczna, rodzaj usługi medycznej czy data wykonania usługi.
2. Wymiana oraz udostępnianie dokumentacji medycznej pomiędzy jednostkami medycznymi:
Usługa dostępna dla personelu medycznego będzie umożliwiać pobranie dokumentacji medycznej pacjenta zgromadzonej w jednostkach medycznych uczestniczących w projekcie. Zakres wymienianych danych pomiędzy jednostkami może być różny i zależy od specjalizacji danej jednostki, a także od zasobu dokumentacji gromadzonej w jej systemach dziedzinowych. Dokumentacja będzie pobierana z listy uzyskanej w procesie wyszukiwania.
W przypadku konieczności pobrania pełnej dokumentacji medycznej pacjenta z konkretnego pobytu/wizyty wymaga się możliwość jej zamówienia/pobrania jedynie w trzech wariantach możliwych do wybrania przez Użytkownika:
• Podstawowa dokumentacja medyczna (m. in. dokumentacja zewnętrzna: karta informacyjna, karta porady specjalistycznej, karta informacyjna SOR).
• Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza objętość).
• Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość)
3. Udostępnianie dokumentacji medycznej pacjentowi (w tym wyników badań):
Usługa będzie umożliwiać pobranie przez pacjenta dokumentacji medycznej zgromadzonej jednostkach medycznych uczestniczących w projekcie. W ramach wdrożenia usługi zostanie wykonana integracja z Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (projekt P1) w zakresie Internetowego Konta Pacjenta (IKP), funkcjonującego w ramach platformy P1, dzięki któremu pacjent będzie miał możliwość zamawiania dokumentacji medycznej. Wskazana przez pacjenta dokumentacja będzie udostępniana z poziomu systemu MSIM. Integracja z IKP będzie obejmować zestawienie szyfrowanego połączenia pozwalającego na udostępnianie/przesyłanie EDM, którą zamówił pacjent (w IKP pacjent powinien otrzymać informację o sposobie udostępnienia dokumentacji, np. link do udostępnionej dokumentacji znajdującej się w EDM w warstwie lokalnej MSIM).
W ramach usługi realizowany będzie scenariusz:
o pacjent przy użyciu IKP wyszukuje w wykazie interesującą go dokumentację medyczną,
o za pomocą usługi dostępnej w IKP pacjent zamawia interesująca go dokumentację medyczną,
o System MSIM obsługuje żądanie we właściwy sposób, umożliwiając przesył dokumentacji medycznej,
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
• Informacje nt. możliwości skorzystania z e-rejestracji (wraz z krótkim instruktażem jak z korzystać z rozwiązania na portalu oraz charakterystyka e-usługi –– FAQ),
• Funkcjonalność umożliwiająca rejestrację oraz założenie konta,
• Informacje o projekcie MSIM.
Ponadto w ramach wdrożenia systemu MSIM dostępne będą:
• Mobilna wersja portalu informacyjnego e-Zdrowie.
• Usługa podpisu elektronicznego dla EDM.
Usługa podpisu elektronicznego dla EDM będzie obsługiwać funkcje podpisywania i weryfikacji podpisu elektronicznego z wykorzystaniem Centrum Autoryzacji (CAPE w Małopolsce). Centrum CAPE będzie wykorzystywane w zakresie:
a.) wydawania certyfikatów elektronicznych do podpisywania (przyjmowanie wniosku o certyfikat w postaci pliku PKCS#10 i udostępnianie wygenerowanego certyfikatu)
b.) znakowania czasem (usługa znakowania czasem zgodna ze standardem RFC 3161.
• Usługa Single Sign-On (SSO) spełniająca następujące wymagania:
a.) System powinien zapewnić funkcjonalność pojedynczego uwierzytelniania użytkowników w obrębie dostarczanej platformy oraz dostarczanych aplikacji dziedzinowych
b.) System powinien zapewnić interfejs API umożliwiający podłączenie do systemu SSO zewnętrznych aplikacji dziedzinowych. Prace integracyjne po stronie zewnętrznych aplikacji dziedzinowych nie są objęte niniejszym postępowaniem
c.) Uwierzytelnianie użytkowników musi być realizowane na podstawie jednoznacznie przydzielonego loginu oraz hasła użytkownika.
• Serwer mailowy na potrzeby powiadomień MSIM
Wszystkie realizowane przez System MSIM usługi elektroniczne będą dostępne przy pomocy dedykowanych interfejsów dostępu jako API dla systemów informatycznych jak i w trybie graficznym dla użytkowników portalu.
• Zapewnienie interoperacyjności
Rozwiązanie ma opierać się założenie przekazywania pomiędzy podmiotami elektronicznej dokumentacji medycznej w ustandaryzowanym formacie możliwym do odczytania w dowolnej lokalizacji. Elementem odpowiedzialnym za przekazywanie dokumentacji medycznej wraz z zapewnieniem prawidłowego uwierzytelnienia użytkowników będzie warstwa regionalna, co uniezależnia rozwiązanie od poszczególnych podmiotów. Rozwiązanie takie pozwala na wzajemny dostęp uprawnionych użytkowników z wszystkich podmiotów dołączonych do MSIM do wszystkich wytwarzanych w formie elektronicznej dokumentów medycznych dostępnych w ramach MSIM. W celu zapewnienia bezpieczeństwa przesyłu danych zakłada się zestawienie bezpiecznego, bezpośredniego i szyfrowanego połączenia pomiędzy jednostkami medycznymi. Połączenie VPN będzie charakteryzować się dużą efektywnością oraz zapewni wysoki poziom bezpieczeństwa.
2.2.2.Wymagania ogólne dla systemu MSIM
1. System MSIM ma umożliwić wymianę EDM pomiędzy jednostkami ochrony zdrowia zintegrowanymi z MSIM.
2. System MSIM ma umożliwić wymianę dokumentacji medycznej w ramach e-Usług pomiędzy jednostkami ochrony zdrowia zintegrowanymi z MSIM.
3. Wymiana dokumentacji medycznej ma być realizowana z wykorzystaniem technologii szyny danych oraz interfejsów integracyjnych.
4. System MSIM musi być przygotowany na integrację z lokalnymi systemami dziedzinowymi w ramach interfejsów zgodnych ze standardem opisanym w Załączniku 9A.:
5. Zakres wymienianych danych pomiędzy jednostkami może być różny i zależy od możliwości systemów dziedzinowych danej jednostki ochrony zdrowia.
6. Podłączenie nowej jednostki ochrony zdrowa do MSIM nie może wymagać od dostawcy systemu dziedzinowego dla danej jednostki ochrony zdrowia żadnej specyficznej wiedzy (np. z zakresu kryptografii) poza umiejętnością implementacji webservices zgodnie z dokumentacją protokołu wymiany danych.
7. Wymiana informacji w ramach sieci pomiędzy jednostkami ochrony zdrowa z wykorzystaniem MSIM, realizującej e-Usługi ma wykorzystywać interfejsy wymiany danych zgodne z przyjętymi standardowymi protokołami w ochronie zdrowia (m. in. HL7 CDA R2 na poziomie interoperacyjności 3-cim, DICOM, XML i PDF zgodne z Rozporządzeniem Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania). W przypadku konieczności standardowe protokoły mogą zostać rozbudowane o dodatkowe elementy, nie występujące w w/w protokołach.
2.3. Koncepcja wykonania i dostawy, instalacji, konfiguracji, wdrożenia, uruchomienia oraz integracji systemu MSIM
Wdrożenie należy rozumieć jako szereg uporządkowanych i zorganizowanych działań mających na celu wykonanie opisanego w OPZ Systemu MSIM. Wdrożenie będzie realizowane w ramach powołanych do tego celu struktur organizacyjnych po stronie Zamawiającego oraz Wykonawcy.
Wykonawca ponosi odpowiedzialność za swoich pracowników i szkody przez nich poczynione w lokalizacjach instalacji infrastruktury sprzętowej.
W ramach dokumentu „Plan Wdrożenia Projektu” zostaną przez Wykonawcę przygotowane informacje na temat struktury organizacyjnej zarządzania projektem, w tym muszą zostać powołane minimum następujące role w projekcie:
1. Kierownik Projektu ze strony Zamawiającego,
2. Kierownik Projektu ze strony Wykonawcy,
3. Zespół realizacyjny po stronie Wykonawcy.
W ramach struktury organizacyjnej procesu wdrożenia musi zostać również powołany Komitet Sterujący minimum w składzie:
1. Przewodniczący – przedstawiciel Zamawiającego,
2. Główny Dostawca – przedstawiciel Wykonawcy,
3. Główny Odbiorca – przedstawiciel Zamawiającego.
Każda z tych ról ma prawo powołać swoich specjalistów dziedzinowych odpowiadających za operacyjną realizację projektu. Szczegółowe zadania i kompetencje Komitetu Sterującego zostaną szczegółowo opisane w Planie Wdrożenia Projektu.
W ramach procesu Wdrożenia zaplanowano, iż nastąpią po sobie chronologicznie następujące działania:
1 Przygotowanie Analizy przedwdrożeniowej Systemu MSIM
Pierwszym zadaniem do wykonania w ramach procesu wdrożenia jest opracowanie przez Wykonawcę w porozumieniu z Zamawiającym Analizy przedwdrożeniowej MSIM.
Dokument ten stanowić będzie bazowy zapis opisujący budowany System MSIM. Na podstawie zapisów w tym dokumencie będą prowadzone i odbierane poszczególne zadania realizowane przy budowie Systemu MSIM.
Dokument ten wraz z SIWZ będą stanowiły podstawę do weryfikacji funkcjonalnej i jakościowej Systemu MSIM w trakcie odbiorów.
2 Dostawa instalacja i konfiguracja infrastruktury Sieciowej
Dostawa instalacja i konfiguracja infrastruktury sieciowej jest zadaniem mającym na celu budowę lub modernizację pasywnego sprzętu sieciowego oraz dostawę, instalację i konfigurację aktywnego sprzętu sieciowego do wskazanych lokalizacji według przygotowanego przez Wykonawcę wspólnie z Zamawiającym harmonogramu w porozumieniu z Partnerami Projektu. Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to z bieżącą pracą Partnerów Projektu. Harmonogram musi być przedstawiony jako diagram Gantta, który obejmuje zadania wraz z ich następnikami, datę rozpoczęcia, datę zakończenia zadania, czas trwania (liczony w dniach roboczych), podmiot odpowiedzialny za realizację zadania, % postęp w realizacji zadania.
Wymagania w zakresie organizacji prac instalacyjnych:
a) Wykonawca będzie dostarczał pasywny sprzęt sieciowy sukcesywnie w ilości niezbędnej do prowadzenia prac instalacyjnych zgodnie z harmonogramem.
b) Wykonawca będzie dostarczał aktywny sprzętu sieciowego sukcesywnie w terminie bezpośrednio poprzedzającym jego instalację i w sposób dopasowany do możliwości logistycznych zamawiającego i Partnerów Projektu. Zakres i wielkości dostaw należy każdorazowo uzgodnić z Zamawiającym.
c) Za przechowywanie narzędzi i materiałów (w tym pasywnego i aktywnego sprzętu sieciowego) w miejscu instalacji odpowiada Wykonawca. Wykonawca zobowiązany jest zagwarantować przechowywanie materiałów zgodnie z wymaganiami producenta.
d) Za sprzęt sieciowy zapewniany w ramach realizacji przedmiotu zamówienia do czasu podpisania protokołu odbioru odpowiada Wykonawca.
3 Dostawa instalacja i konfiguracja infrastruktury sprzętowej
Dostawa instalacja i konfiguracja infrastruktury sprzętowej jest zadaniem mającym na celu dostarczenie zamawianego sprzętu do wskazanych lokalizacji według przygotowanego przez Wykonawcę wspólnie z Xxxxxxxxxxxx harmonogramu w porozumieniu z Partnerami Projektu.
Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to z bieżącą pracą Partnerów Projektu.
Wymagania w zakresie logistyki dostaw:
a) Wykonawca ma zapewnić wniesienie dostarczonego sprzętu do miejsca (pomieszczenia) u Partnera Projektu oraz w lokalizacji warstwy regionalnej MSIM.
b) Wykonawca będzie dostarczał sprzęt sukcesywnie w terminie bezpośrednio poprzedzającym jego instalację i w sposób dopasowany do możliwości logistycznych zamawiającego i Partnerów Projektu. Zakres i wielkości dostaw należy każdorazowo uzgodnić z Zamawiającym.
c) Za przechowywanie narzędzi i materiałów (w tym infrastruktury sprzętowej) w miejscu instalacji odpowiada Wykonawca. Wykonawca zobowiązany jest zagwarantować przechowywanie materiałów zgodnie z wymaganiami producenta.
d) Za infrastrukturę sprzętową zapewnianą w ramach realizacji przedmiotu zamówienia do czasu podpisania protokołu odbioru odpowiada Wykonawca.
4 Dostawa, instalacja i konfiguracja Oprogramowania systemowego i narzędziowego
W ramach zadania dostawy, instalacji oraz konfiguracji Oprogramowania systemowego i narzędziowego Wykonawca ma dokonać instalacji i konfiguracji wymaganego oprogramowania systemowego i narzędziowego na dostarczonym uprzednio sprzęcie. Dostawa i instalacja ma być wykonana we wskazanych lokalizacjach zgodnie z Planem Wdrożenia Projektu. Po zakończeniu instalacji, zainstalowane oprogramowanie musi zostać skonfigurowane tak aby działało poprawnie zgodnie z jego przeznaczeniem i wymaganą architekturą rozwiązania Systemu MSIM oraz oferowało funkcjonalność opisaną w SIWZ, a także zapewniać prawidłową pracę Oprogramowania aplikacyjnego.
5 Dostawa, instalacja i konfiguracja Oprogramowania aplikacyjnego
W ramach zadania dostawy instalacji i konfiguracji oprogramowania aplikacyjnego Wykonawca ma dokonać instalacji i konfigurację zamawianego oprogramowania aplikacyjnego. Dostawa instalacja
i konfiguracja ma być wykonana we wskazanych lokalizacjach oraz zgodnie z Planem Wdrożenia Projektu. Po zakończeniu prac instalacyjnych oprogramowanie musi zostać skonfigurowane tak aby oferowało funkcjonalność opisaną w SIWZ oraz zgodnie z wymaganą architekturą rozwiązania Systemu MSIM.
6 Integracja MSIM z Partnerami Projektu i Podmiotami leczniczymi
Zadania te polegają na integracji wskazanych jednostek ochrony zdrowia w ramach Systemu MSIM, zgodnie z wymaganą architekturą rozwiązania systemu MSIM oraz określonymi elementami warstwy integracji Systemu MSIM. Głównym celem integracji jest uruchomienie e- Usług w zakresie synchronizacji i wymiany danych pomiędzy warstwą regionalną MSIM, a warstwami lokalnymi Partnerów Projektu.
7 Testy
Celem przeprowadzenia testów jest weryfikacja przez Zamawiającego, czy wszystkie prace wykonane w trakcie budowania Systemu MSIM zostały wykonane prawidłowo i zgodnie z założeniami funkcjonalnymi i jakościowymi. Testy będą przeprowadzane zarówno przez pracowników Partnerów Projektów jak i wskazanych przez Zamawiającego osób i podmiotów zewnętrznych.
W celu przeprowadzenia testów Wykonawca przygotuje kompletne środowisko testowe oraz scenariusze testowe.
Pozytywne zakończenie testów wraz z usunięciem wskazanych wad jest niezbędne aby dla poszczególnych komponentów oraz Systemu MSIM dokonać odbiorów w ramach poszczególnych etapów oraz odbioru końcowego.
8 Odbiór końcowy
Zadanie to ma na celu potwierdzenie wykonanie wszystkich zadań wynikających z Projektu, w tym odebrania wszystkich Komponentów i etapów Projektu oraz dostarczenia wszystkich wymaganych w zamówieniu dokumentów. Dokonanie odbioru końcowego zakończy prace przy budowie Systemu MSIM i będzie podstawą do przekazania Systemu MSIM do użytkowania produkcyjnego.
Wykonawca ma przekazać protokoły odbioru końcowego z rozpisaniem na składowe będące elementami całego systemu MSIM w uzgodnieniu z Zamawiającym.
2.4. Dyslokacja elementów systemu
Lista lokalizacji, w których należy zainstalować elementy systemu
1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
2. Szpital Specjalistyczny im. J. Dietla w Krakowie
3. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.(gdzie zlokalizowane są dwie serwerownie do których dostarczona zostanie infrastruktura zamawiana w ramach MSIM)
Ponadto Projekt musi umożliwiać przyłączenie do niego w dalszym okresie kolejnych jednostek ochrony zdrowia.
Zgodnie z podziałem funkcjonalnym System składa się z komponentu regionalnego oraz komponentu lokalnego.
Komponent lokalny umieszony zostanie w następujących lokalizacjach:
1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
2. Szpital Specjalistyczny im. J. Dietla w Krakowie
3. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.
Komponent regionalny umieszony zostanie w lokalizacji:
1. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.
Lista lokalizacji jest aktualna na dzień 6.10.2014.
Rysunek 5. Koncepcja komunikacji w MSIM.
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 potrzebytworzenia 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:
• Usługa znakowania czasem
• Usługa weryfikacji znaku czasu
System powinien wykorzystywać usługę znacznika czasu realizowaną przez Centrum Autoryzacji (CAPE w Małopolsce)), przez zastosowanie funkcjonującej obecnie w Centrum aplikacji PentaSCAPE- 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.
2.7. Koncepcja autentykacji i identyfikacji użytkowników
Identyfikacja, uwierzytelnianie i autoryzacja użytkowników (osób oraz systemów) powinna być oparta o mechanizm scentralizowany, który logicznie wydziela 2 warstwy:
• Identity provider (dostawca tożsamości) pełniący funkcję weryfikującą – funkcja powinna być dostępna z poziomu komponentu regionalnego jak wspólna usługa infrastrukturalna.
• Klientów usługi, którzy potrzebuję rzetelnej i aktualnej informacji o tożsamości uczestników komunikacji – funkcja ta będzie wykorzystywana głównie przez komponent lokalny.
Rozwiązanie powinno być oparte o jeden wspólny serwer certyfikacyjny, każdy użytkownik będzie miał klucz / token weryfikowany przez serwer certyfikacji. Zakłada się wykorzystanie działającego Centrum Autoryzacji podpisu elektronicznego w ramach Urzędu Marszałkowskiego (CAPE w Małopolsce).
Usługa uwierzytelniania powinna być oparta o mechanizm jednokrotnego logowania (ang. Single Sign On – SSO) w obrębie aplikacji wytworzonych w ramach projektu. W ramach MSIM powstanie usługa pozwalająca poszczególnym HIS-om wykorzystanie tego mechanizmu w ramach poszczególnych instalacji. Kwestia zaimplementowania SSO w ramach poszczególnych HIS jest elementem odrębnego zamówienia udzielonego wykonawcom HIS.
Na potrzeby usługi e-Rejestracja wymagane będzie utworzenie niezależnego repozytorium tożsamości dla Pacjentów, którzy będą chcieli korzystać z funkcjonalności rezerwowania wizyt w placówce medycznej.
Konta tych pacjentów a w konsekwencji ich dane osobowe muszą być zabezpieczone mechanizmami odpowiadającymi poziomowi wysokiemu zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych
W celu zapewnienia bezpieczeństwa danych osobowych dla potwierdzenia rejestracji wymagana będzie wizyta w placówce z wydrukowanym formularzem rejestracji celem potwierdzenia danych osobowych i otrzymania hasła pierwszego logowania.
2.8. Koncepcja współpracy z Internetowym Kontem Pacjenta (IKP)
W celu zapewnienia wymiany informacji pomiędzy usługodawcami, a platformą P1 zostały wybrane standardy komunikacji, które sprawią, że proces ten będzie mógł przebiegać w sposób zunifikowany.
Z uwagi na interoperacyjność oraz wytyczne CSIOZ wybrany został standard IHE XDS.b, który gwarantuje obsługę wymaganych procesów w warunkach polskiej ochrony zdrowia, jak również komunikację międzynarodową.
Platforma P1 wykorzystuje dwa główne profile IHE w celu komunikacji między systemami:
• IHE XDS.b - wykorzystywany do wymiany informacji o dokumentach medycznych (rozszerzona o informacje o zdarzeniu medycznym, w ramach którego dokumentacja ta powstała),
• IHE XDM - wykorzystywany do importu do P1 dokumentów z placówek likwidowanych.
Platforma P1 wykorzystuje również standard:
• HL7 CDA R2 na 3-cim poziomie interoperacyjności- w zakresie transferu 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 w wersji aktualnej w okresie wykonywania usługi.
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ń.
Xxxx 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 standardowego interfejsu komunikacji przez rejestr EDM oznacza, że integracja z każdym klientem rejestru powinna być maksymalnie uproszczona.
Współpraca z CSIOZ w ramach systemu P1 w zakresie IKP odbywać się powinna na poziomie aplikacji pozwalającej na dostęp do konta pacjenta, w której będzie on miał możliwość zamawiania dokumentacji medycznej, która będzie następnie udostępniana/przesyłana za pomocą usługi dostępnej w warstwie regionalnej systemu MSIM. Integracja z P1 w zakresie IKP będzie obejmować zestawienie szyfrowanego połączenia pozwalającego na udostępnianie/przesyłanie danych medycznych, które zamówił pacjent. W ramach usługi realizowany będzie scenariusz:
• pacjent w IKP wyszukuje w wykazie interesującą go dokumentację medyczną (na podstawie indeksu zlokalizowanego w warstwie regionalnej),
• za pomocą usługi dostępnej w P1 pacjent zamawia interesująca go dokumentację medyczną,
• zlecenie zostaje przekazane do placówki, która udostępnia wskazaną dokumentację,
• placówka udostępnia zamówioną dokumentację medyczną,
• pacjent pobiera zamówioną dokumentację medyczną.
W ramach integracji z CSIOZ należy zapewnić możliwość:
• przekazania tożsamości pacjenta do systemu MSIM, tak aby pacjent mógł wykorzystać usługę wyszukiwania i pobierania EDM,
• przekazywania zgód pacjentów na udostępnianie dokumentacji medycznej.
Przekazywanie tożsamości pomiędzy Systemem MSIM, a Platformą P1 musi spełniać wszystkie wymagania prawne związane z anonimizacją danych Pacjentów.
W zakresie zamówienia jest dostosowywanie MSIM do aktualnych wytycznych CSIOZ w zakresie platformy P1 przez okres wskazany w ofercie lecz nie mniej niż 5 lat od daty odbioru końcowego systemu, w tym uzyskiwanie wszystkich wymaganych certyfikacji.
2.9. Koncepcja przesyłania dokumentacji o dużej pojemności
W przypadku dokumentacji medycznej głównym elementem wytwarzającym dane o dużej pojemności są dane obrazowe. W związku z czym System musi mieć możliwość 3-poziomowego wyboru zakresu pobieranej dokumentacji medycznej. Takie rozwiązanie pozwala na ograniczenie ruchu i nie obciążanie łączy bez uzasadnienia. Uwierzytelniony użytkownik będzie mógł skorzystać z następujących wariantów zamówienia/pobrania dokumentacji:
• Podstawowa dokumentacja medyczna (dokumentacja zewnętrzna: karta informacyjna, karta porady specjalistycznej, karta informacyjna SOR),
• Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza objętość),
• Pełna dokumentacja medyczna z konkretnej hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość).
Przesył pełnej dokumentacji medycznej z danymi obrazowymi w jakości diagnostycznej o dużej objętości będzie wspomagany poprze mechanizm dynamicznego przydzielana przepustowości łącza, dający wyższy priorytet dla bieżącej obsługi jednostki szpitalnej, a niższy dla wymiany dokumentacji.
2.10. Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych jednostek
W ramach koncepcji rozwoju systemu przewiduje się:
1. Zdefiniowanie i udostępnienie standardów warstwy integracji, w którego skład wchodzi
m. in. interfejs integracji regionalnej odpowiedzialny za wymianę danych, umożliwiający komunikację elektroniczną pomiędzy regionem a lokalnymi systemami informatycznymi (standardy zapytań, struktur baz danych) – Wykonawca przygotuje taki dokument na etapie realizacji projektu.
2. Rozwój na poziomie warstwy regionalnej e-Usług dostarczanych wszystkim obywatelom, usługi integrujące działania jednostek służby zdrowia i usługi dedykowane organom działającym na poziomie regionalnym i ponadregionalnym – do realizacji w ramach kolejnych projektów.
3. System zarządczy dla Województwa Małopolskiego – w zakresie przewidzianym OPZ,
4. Integracja z pozostałymi systemami regionalnymi w dziedzinie e-Zdrowia, w tym systemami i usługami wytwarzanymi w ramach projektów CSIOZ oraz innych platform regionalnych, np. PSIM (Podkarpacki System Informacji Medycznej) – w tym zakresie wymagane jest zagwarantowanie integracji z w ramach zaleceń CSIOZ w okresie gwarancji.
Architektura warstwy regionalnej ma zapewniać łatwą modyfikowalność systemu w przyszłości. Modyfikowalność systemu jest rozumiana jako co najmniej:
• Podłączanie nowych jednostek do systemu poprzez konfiguracje
• Rozszerzanie zakresu wymienianych danych poprzez konfiguracje
• Rozszerzanie funkcjonalności poprzez podłączanie dodatkowych modułów
W tym zakresie Wykonawca przygotuje standardy integracji.
2.11. Schemat połączeń pomiędzy elementami systemu
Sekcja przedstawia schemat połączeń pomiędzy elementami systemu, w tym połączeń sieciowych.
Sieć
Sieć połączeń pomiędzy poszczególnym uczestnikami projektu musi zostać zbudowana z wykorzystaniem posiadanego przez uczestników projektu łącza internetowego. W ramach publicznej sieci Internet zostanie zbudowana dedykowana sieć VPN, która połączy wszystkich uczestników projektu. W związku z tym, dane nie mogą być przesyłane w postaci jawnej lecz należy je szyfrować. Zakłada się w tym celu wykorzystanie mechanizmu IPsec (Internet Protocol Security), dzięki któremu urządzenia tworzą tzw. tunele IPsec. Dane przed wyjściem do Internetu są szyfrowane przez brzegowe urządzenie UTM znajdujące się w Szpitalu. Natomiast na końcu tunelu dane są odszyfrowywane przez brzegowe urządzenie UTM znajdujące się w lokalizacji regionalnej. W sytuacji przesyłania danych z Regionu do Szpitali kolejność szyfrowania będzie odwrotna.
Takie tunele będę na stałe zestawione pomiędzy poszczególnymi Szpitalami, a Regionem. Układ ten przedstawia poniższy rysunek.
Rysunek 6:Schemat połączeń VPN (źródło: opracowanie własne)
Dzięki temu, wszystkie dane przechodzące przez Internet są bezpieczne. Również pracownicy zdalni mogą łączyć się do sieci firmowej poprzez tunel IPsec, umożliwia to bezpiecznie korzystanie z zasobów sieci firmowej np. z domu. W tym przypadku sieć VPN ma strukturę gwiazdy.
Na poniższym rysunku został przedstawiony schemat połączeń infrastruktury sprzętowej dla projektu MSIM.
W warstwie technicznej schemat połączeń pomiędzy elementami systemu oparty jest o następujące typy połączeń:
• Tunele VPN szyfrowane protokołem SSL pomiędzy warstwą regionalną a poszczególnymi komponentami lokalnymi,
• Łącze Ethernet 1Gb w zakresie sieci LAN,
• Połączenia z wykorzystaniem protokołu FC dla sieci SAN pomiędzy macierzami a serwerami.
Szpital lokalny 3
Rysunek 7. Schemat połączeń pomiędzy elementami systemu
Opis Przedmiotu Zamówienia
Rysunek 8. Schemat połączeń infrastruktury sprzętowej w lokalizacji Regionalnej.
Strona 26 z 157
Rysunek 9. Schemat połączeń infrastruktury sprzętowej w lokalizacji Lokalnej.
2.12. Interfejsy komunikacyjne z innymi systemami informatycznymi
System MSIM wykorzystuje następujące zewnętrzne interfejsy:
• System HIS, gdzie zakres i tryb wymiany danych określony jest interfejsem ITI-41
• Lokalny systemu lub moduł e-Rejestracji, gdzie zakres i tryb integracja określony jest definicją procesów biznesowych z grupy e-Rejestracji (rozdział 2)
• P1 (IKP), gdzie zakres i tryb wymiany danych określony jest interfejsem właściwym dla klientów rejestru i repozytorium EDM
• Centrum Autoryzacji podpisu elektronicznego w Małopolsce (CAPE w Małopolsce), gdzie zakres i tryb integracji musi odpowiadać wymaganej funkcjonalności usługi podpisu elektronicznego dla EDM
Wytyczne dla komunikacji z platformą P1:
• Komunikacja z platformą P1 następuje w oparciu o reguły tworzenia Elektronicznej Dokumentacji Medycznej i model transportowy danych o Zdarzeniach Medycznych oraz Indeksie EDM, gdzie platforma P1 jest rejestrem EDM
• Komunikat przekazania informacji o zdarzeniu medycznym jest inicjowany przez komponent regionalny, który przekazuje komunikat do platformy P1 analogicznie do zdarzenia rejestracji EDM przekazywanego przez komponent lokalny do komponentu regionalnego
• System dziedzinowy musi wytworzyć a komponent regionalny musi przygotować komunikat do platformy P1 zgodnie z ostatnią aktualną wersją wytycznych dostępnych na stronach CSIOZ
Wykonawca jest zobowiązany do przygotowania opisu interfejsów, ich wykonania i przetestowania na zasadach odrębności w stosunku do pozostałych funkcji systemu MSIM (interfejsy można testować w oderwaniu od samego systemu).
2.13. Koncepcja komunikacji pomiędzy jednostkami
Cała komunikacja mająca na celu przekazanie dokumentacji ze Szpitala występującego o dokumentację do szpitala udostępniającego dokumentację jest realizowana za pośrednictwem warstwy regionalnej MSIM.
Rysunek 10. Schemat koncepcji komunikacji
Takie rozwiązanie pozwala na zachowanie wysokiego poziomu bezpieczeństwa przez ustanowienie tylko jednego kanału komunikacji pomiędzy szpitalem, a warstwą regionalna, przez który przeprowadzony jest cały proces komunikacji.
2.14. Koncepcja przesyłu danych pomiędzy jednostkami
Proces udostępnienia dokumentu zilustrowany został na poniższym rysunku:
Rysunek 11. Schemat procesu udostępniania dokumentu
W ramach systemu MSIM przesył danych pomiędzy jednostkami powinien być realizowany w przypadku udostępniania dokumentacji medycznej. Scenariusz udostępniania dokumentacji medycznej jest następujący:
1. Użytkownik za pomocą aplikacji typu klient wyszukuje dokument pacjenta w rejestrze na podstawie metadanych.
2. System regionalny sprawdza uprawnienia użytkownika.
3. Repozytorium Regionalne kontaktuje się z repozytorium jednostki w którym przechowywana jest dokumentacja.
4. Dokumentacja wysyłana jest z repozytorium, w którym weryfikowana jest jej poprawność.
5. Dokumentacja wysyłana jest z warstwy regionalnej MSIM do użytkownika.
6. Po potwierdzeniu przesłania dokumentacji do Użytkownika, w warstwie regionalnej zostaje odnotowany fakt udostępnienia Elektronicznej Dokumentacji Medycznej zawierający co najmniej dane o: użytkowniku, dacie, czasie udostępnienia, wersji przekazanych dokumentów).
2.15. Integracja systemów oraz danych z innych systemów do wdrażanego systemu MSIM
System MSIM wykorzystuje następujące zewnętrzne interfejsy i w takim zakresie musi być zintegrowany z systemami zewnętrznymi udostępniającymi lub wykorzystującymi interfejsy:
• System HIS, gdzie zakres i tryb wymiany danych określony jest interfejsem ITI-41
• Lokalny systemu lub moduł e-Rejestracji, gdzie zakres i tryb integracja określony jest definicją procesów biznesowych z grupy e-Rejestracji (rozdział 2)
• P1, gdzie zakres i tryb wymiany danych określony jest interfejsem właściwym dla klientów rejestru i repozytorium EDM, tj. ITI-18 i ITI-43
• Centrum Autoryzacji podpisu elektronicznego w Małopolsce, gdzie zakres i tryb integracji musi odpowiadać wymaganej funkcjonalności usługi podpisu elektronicznego dla EDM.
2.16. Koncepcja wirtualizacji zasobów informatycznych
Wymagana jest dostawa oprogramowania do wirtualizacji z licencjami wystarczającymi dla uruchomienia na dostarczonym sprzęcie 40 serwerów wirtualnych.
Wykonawca musi opracować i uzgodnić z Zamawiającym plan wirtualizacji zasobów obejmujących zakres, tryb i konfigurację zasobów wirtualizowanych biorąc pod uwagę charakterystykę Systemu MSIM, zasady wirtualizacji poszczególnych Partnerów oraz przesłanki wydajnościowe i bezpieczeństwa.
Wymagania na oprogramowanie do wirtualizacji przedstawiono w sekcji z oprogramowaniem standardowym (infrastruktura).
3. Analiza stanu aktualnego
3.1. Infrastruktura informatyczna
3.1.1.Serwerownia
3.1.1.1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
L.P. | Parametr | Serwerownia 1 | Serwerownia 2 | Serwerownia 3 |
1. | Adres | 33-300 Nowy Sącz, Xxxxxxx 00 | 00-000 Xxxx Xxxx, Xxxxxxx 00 | 00-000 Xxxx Xxxx, Xxxxxxx 00 |
2. | Lokalizacja w budynku | 33-300 Nowy Sącz, Xxxxxxx 0, Xxxxxxx xxxxxx | 00-000 Xxxx Xxxx, Xxxxxxx 0, Xxxxxxx xxxxxx - RTG | 00-000 Xxxx Xxxx, Xxxxxxx 0,Xxxxxxx onkologiczny |
3. | Powierzchnia użytkowa [m2] /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. | Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski) | Tak (niski) | Tak (niski) | Nie |
19. | Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski) | Tak (niski) | Tak (niski) | Nie |
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.2. Szpital Specjalistyczny im. J. Dietla w Krakowie
L.P. | Parametr | Serwerownia 1 | Serwerownia 2 | Serwerownia 3 |
1. | Adres | 00-000 Xxxxxx, xx. Xxxxxxxx 0 | 00-000 Xxxxxx, xx Xxxxx 00 | |
2. | Lokalizacja w budynku | 00-000 Xxxxxx, xx. Xxxxxxxx 0 Główna lokalizacja | 00-000 Xxxxxx, xx Xxxxx 00, 2km od Głównej Lokalizacji | |
3. | Powierzchnia użytkowa [m2] /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ń do sieci elektrycznej [TAK/NIE]/[A] | Tak/8 | Tak/20 |
25. | Wydzielony obwód zasilania [TAK/NIE] | Tak | Tak |
26. | System zasilania awaryjnego [TAK/NIE] | Nie | Tak |
27. | Centralny UPS [TAK/NIE]/Moc [kVA] | Nie | Tak/2KVA |
28. | Agregat prądotwórczy [TAK/NIE]/Moc [kVA] | Nie | Tak/650kVA |
ZIDENTYFIKOWANE RYZYKA | |||
29. | Konieczność rozbudowy sieci logicznej | Nie | Nie |
30. | Konieczność rozbudowy sieci elektrycznej | Nie | Nie |
3.1.1.3. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.
L.P. | Parametr | Serwerownia 1 | Serwerownia 2 | Serwerownia 3 | |||||
1. | Adres | Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx | Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx | ||||||
2. | Lokalizacja w budynku | Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx | Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx | ||||||
3. | Powierzchnia użytkowa [m2] /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 elektrycznej [A] | urządzeń | do | sieci | 6kW | Brak - do uruchomienia w zależności od potrzeb | |||
24. | Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A] | Tak /200kW | 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] | Tak /2x szpitala) | 540kVA | (dla | całego | ||||
ZIDENTYFIKOWANE RYZYKA | |||||||||
29. | Konieczność rozbudowy sieci logicznej | Tak | Tak | ||||||
30. | Konieczność rozbudowy sieci elektrycznej | Tak | Tak |
3.1.2.Serwery
L.P | Producent - model | Rok produkcji | RAM | Obudowa [Tower / RACK-xU] | Rola (zadanie) |
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | |||||
1. | Optimus Nserwer | 2005 | 2GB | Tower | Auto ID |
2. | Optimus Xxxxxxx | 0000 | 0XX | Xxxxx | Xxxxxx XX |
3. | IBM x3650 | 2009 | 6GB | Rack 2U | Simple ERP |
4. | SUN x4170 | 2011 | 24GB | Rack 1U | Eskulap – terminale |
5. | SUN x4170 | 2012 | 24GB | Rack 1U | Eskulap – terminale |
6. | SUN x4170 | 2012 | 20GB | Rack 1U | Eskulap – terminale |
7. | HP ML350 | 2011 | 4GB | Rack 4U | Impax |
8. | HP ML350 | 2011 | 2GB | Rack 4U | Impax |
Szpital Specjalistyczny im. J. Dietla w Krakowie | |||||
1. | HP RP5470 UX PA- 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. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | |||||
1. | HP ML 110 G4 | 2007 | 4GB | Rack | Obsługa ZDL |
2. | SuntarNET | 2007 | 4GB | Rack | Serwer plików |
3. | HP DL 380 G5 | 2008 | 16GB | Rack | Infomedica |
4. | HP DL 380 G5 | 2008 | 16GB | Rack | HIS - zapasowy |
5. | HP DL 380 G5 | 2008 | 4GB | Rack | Dostęp do WAN (serwer typu UTM) |
6. | HP DL 160 G6 | 2009 | 4GB | Rack | Serwer plików |
7. | HP BL460c G6 | 2010 | 16GB | Blade | PACS |
8. | HP BL460c G6 | 2010 | 16GB | Blade | PACS |
9. | HP BL460c G6 | 2010 | 32GB | Blade | HIS, RIS |
10. | HP BL460c G6 | 2010 | 16GB | Blade | Hyper-V, WSUS, drERYK |
11. | HP BL460c G6 | 2010 | 16GB | Blade | Hyper-V, Serwer Kaspersky, eWUŚ |
12. | HP DL 120 G6 | 2010 | 4GB | Rack | Kontroler domeny |
13. | HP DL 120 G6 | 2010 | 4GB | Rack | Kontroler domeny |
14. | HP DL 160 G6 | 2010 | 4GB | Rack | Płatnik, Intranet |
15. | HP DL 360 G6 | 2010 | 4GB | Rack | Serwer plików |
16. | HP DL 120 G6 | 2011 | 4GB | Rack | PCM, |
17. | HP DL 360 G7 | 2012 | 4GB | Rack | Poczta, witryna WWW |
18. | HP BL460c G8 | 2013 | 64GB | Blade | EDM |
19. | HP BL460c G8 | 2013 | 64GB | Blade | EDM |
3.1.3.Macierze
L.P | Producent - model | Rok produkcji | Pojemność | Jakie dane są przechowywane | Rodzaj dysków [SATA / FATA] |
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | |||||
1. | IBM DS3512 | 2009 | 2x 1TB; 5x300MB | PACS | SAS (SATA) |
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. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | |||||
L.P | Producent - model | Rok produkcji | Pojemność | Jakie dane są przechowywane | Rodzaj dysków [SATA / FATA] |
1. | HP MSA P2000 | 2009 | 5TB | PACS | SAS |
2. | HP 2312fc | 2010 | 12TB | PACS | SAS |
3. | HP MSA P2000 G3 | 2012 | 32TB | HIS, Archiwa | SAS |
4. | HP MSA2000 | 2012 | 24TB | Dane administracyjne | SAS |
3.1.4.Biblioteka taśmowa
L.P | Producent - model | Rok produkcji | Pojemność | Jakie dane są przechowywane | Oprogramowanie do backupu |
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | |||||
1. | HP StorageWorks MSL 0000 | 0000 | 00x0,6 TB | PACS | Firmeware HP |
2. | SUN Oracle Storagetek SL24 | 2011 | 20x1,6 TB | Simple | Firmeware Oracle |
Szpital Specjalistyczny im. J. Dietla w Krakowie | |||||
1. | Brak | Nie dotyczy | Nie dotyczy | Nie dotyczy | Nie dotyczy |
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | |||||
1 | HP StorageWorks MSL 4048 | 2010 | 48x800GB | PACS | Firmeware HP, Synektik |
3.1.5.Połączenia sieciowe oraz sieć NAS
3.1.5.1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
Główny Punkt Dystrybucyjny (GPD) znajduje się w pomieszczeniu serwerowni na parterze w budynku Pulmonologii.
Oprócz tego w budynkach znajdują lokalne punkty dystrybucyjne, są to:
• Punkty 4P0, 4P1, 4P3, 4P4 (zlokalizowane na piętrach 0, 1, 3 i 4 Budynku 4)
• Punkty 3P-1, 3P0, 3P1, 3P2, 3P3 zlokalizowane na piętrach -1, 0, 1, 2 i 3 Budynku 3
• Punkt PU zlokalizowany w budynku Pulmonologii
• Punkt PS zlokalizowany w budynku Kliniki Psychiatrycznej
• Punkt TE zlokalizowany w dziale technicznym
• Punkt DR (istniejący) zlokalizowany w budynku Dyrekcji
• Punkt RTG (istniejący) na parterze budynku 4
Punkty zostały połączone okablowaniem światłowodowym wielodomowym OM3 o różnej liczbie włókien. Załączony rysunek ilustruje schemat sieci logicznej.
Podstawą do opracowania zagadnień związanych z okablowaniem strukturalnym są normy okablowania strukturalnego:
• ISO/IEC11801 wyd. II
• EN50173-1 wyd. II
• TIA/EIA 569A
• PN-EN50173-1 + AC
• TIA/EIA 568B
3.1.5.2. Szpital Specjalistyczny im. J. Dietla w Krakowie
cat. 5e
światłowód 10Gb (Wszystkie połączenia posiadają backup – podwójny ring)
cat 6
światłowód 1 Gb
łącze LINK 4Mb/1Mb od 1.02.2013 światłowód 100M iSCASI, FC, SCASI
3.1.5.3. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.
Sieć informatyczna w Szpitalu zbudowana jest w topologii rozszerzonej gwiazdy. Szkielet sieci zbudowany na 6-cio światłowodach MM 50/125 które łączą centralny punkt dystrybucyjny (MDF serwerownia) z lokalnymi punktami dystrybucyjnymi (IDF)usytuowanymi na poszczególnych piętrach. Stacje robocze użytkowników komunikują się z przełącznikiem brzegowymi HP ProCurve 2610 po skrętce miedzianej cat.5e/6 z prędkością 100/1000 Mbps (w zależności od parametrów switch). Komunikacja w obrębie sieci szkieletowej odbywa się z prędkością 1/10Gbps. Szkielet sieci spina modularny przełącznik szkieletowy HP ProCurve 5412zl.
W obrębie serwerowni funkcjonuje sieć pamięci masowej SAN zbudowana w technologii Fibre Channel w skład której wchodzi: 5 macierzy dyskowych HP MSA, system serwerowy HP Blade, 3 serwery Rackowe, biblioteka taśmowa MSL4048. Komunikację pomiędzy urządzeniami serwerowymi i zasobami pamięci zapewniają 3 switche FC(HP StorageWorks 8/20q oraz Brocade 8/12C). Komunikacja w strukturze FC odbywa się z prędkością 8Gbps.
Na rysunku poniżej przedstawiony jest schemat infrastruktury FC.
3.1.6.Sprzęt komputerowy
L.P. | Rok produkcji | Typ [terminal/PC] | System operacyjny | Ilość [szt.] |
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 Specjalistyczny im. J. Dietla w Krakowie | ||||
1. | 2008, 2012, 2013 | Terminal | Linux | 140 |
2. | 2005-2013 | PC | Windows (XP; VISTA; 7) | 110 |
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. Z o.o. | ||||
0 | 0000-0000 | PC | Windows XP PRO, 7 PRO | 574 |
3.2. Infrastruktura sieciowa
3.2.1.Sieć szkieletowa
L.P | Podmiot | Technologia | Przepustowość | Redundancja [TAK/NIE] |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Światłowód | 1Gb/10Gb | Nie |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | Światłowód | 10Gb | Tak |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o. | Światłowód | 1Gb/10Gb | Nie |
3.2.2.Sieć pozioma
L.P | Podmiot | Technologia | Przepustowość | Kategoria |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | UTP | 100Mb/1Gb | 5/6e |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | UTP | 1Gb | 5e/6 |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o. | UTP/FTP | 100Mb/1Gb | 5e/6 |
3.2.3.Węzły pośrednie
L.P | Podmiot | Ilość | Odrębne zasilania [TAK / NIE / CZĘŚCIO WO] | UPS [TAK / NIE / CZĘŚCIOW O] | Dostęp chroniony [TAK / NIE / CZĘŚCIOWO] |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | 23 | Nie | Nie | Częściowo |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | 7 | Częściowo (2 z zasilaniem) | Częściowo (2) | Częściowo |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o. | 18 | Częściowo | Częściowo | Częściowo |
3.2.4.Urządzenia UTM
L.P | Podmiot | [TAK / NIE] (model) | ilość | Redun- dancja | Rok produkcji |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Tak (MikroTik Board 1000) | 1 | Nie | 2009 |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | Tak (Juniper SSG140) | 1 | Nie | 2009 |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o. | TAK (Linuks - Slackware) | 1 | Nie | 2010 |
3.2.5.Urządzenia aktywne – lista
3.2.5.1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
L.P. | Producent | Model | Rok produkcji | Ilość |
1. | Allied Telesis | AT-8000S/24 | 2009 | 4 |
2. | Allied Telesis | AT-8000GS/24 | 2010 | 20 |
3. | Allied Telesis | AT-8100S/48 | 2009 | 1 |
4. | Allied Telesis | AT-9000/24 | 2009 | 2 |
5. | Allied Telesis | AT-x900/24 | 2010 | 1 |
6. | Allied Telesis | AT-9000/52 | 2012 | 2 |
7. | Allied Telesis | AT-x600/24 | 2010,2012 | 2 |
8. | Allied Telesis | AT-MC101xL | 2009 | 2 |
9. | Allied Telesis | AT-G6f Rapier | 2007 | 1 |
10. | Allied Telesis | AT-8 PoE | 2009 | 2 |
11. | Allied Telesis | AT-8000S/48 | 2009 | 1 |
3.2.5.2. Szpital Specjalistyczny im. J. Dietla w Krakowie
L.P. | Producent | Model | Rok 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.3. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx 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 |
3.3. Łącza internetowe
LP. | Operator | Serwerownia | Technologia przyłącza | Ilość stałych adresów IP | Przepustowość download [Mbps] | Przepustowość upload [Mbps] | Szczytowe obciążenie | Pozostały czas trwania umowy [mies.] | Czy są warunki do zwiększenia przepustowości |
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | |||||||||
1. | TP SA | Serwerownia RTG | Neostrada | 5 | 40 | 4 | 90% | 2 | Tak |
Szpital Specjalistyczny im. J. Dietla w Krakowie | |||||||||
1. | Fibertech | Xxxxxxxx 0 | Światłowód | 8 | 10 | 10 | 50% | 12 | Tak |
2. | TP SA | Xxxxxxxx 0 | ADSL | 6 | 4 | 1 | 100% | 22 | Tak |
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | |||||||||
1. | Netia SA | Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx | Światłowód | 4 | 50 | 50 | 80% | 9 | Tak |
2. | Exatel SA | Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx | 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 w Szpitalu Specjalistycznym im. J. Śniadeckiego w Nowym Sączu (tylko upload), oraz Szpitalu Specjalistycznym im. J. Dietla w Krakowie są niewystarczające do obsługi MSIM.
Dostarczenie niezbędnych łącz, których mowa wyżej nie jest elementem zamówienia.
3.4. Procedury bezpieczeństwa
Nazwa jednostki | Wdrożona Polityka Bezpiecze ństwa | System zarządzania Bezpieczeń stwem Informacji | Procedury dotyczące bezpieczeństwa Informacji |
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Nie (zamierza wdrożyć w 2014r) | Nie | 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 |
Szpital Specjalistyczny im. J. Dietla w Krakowie | Tak | Tak | Istniejące procedury: - 1. Instrukcja zarządzania systemem informatycznym (IZSI) 2 Polityka Bezpieczeństwa Informacji (PI) 3 Procedura bezpieczeństwa danych w ISO 9001:2010 |
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | Tak | Tak | Istniejące procedury: - - instrukcja zarządzania systemem informatycznym - polityka bezpieczeństwa informacji - procedura bezpieczeństwa danych w ISO 9001:2008 - Procedura zarządzania uprawnieniami w systemach informatycznych - w szpitalu uruchomiono działania zmierzające do uzyskania normy PN-ISO/IEC 27001 |
Poza Szpitalem Specjalistycznym im. J. Śniadeckiego w Nowym Sączu, wszystkie pozostałe Szpitale posiadają opracowane Polityki Bezpieczeństwa. Oznacza to, że w Szpitalach tych są opracowane zasady i dostępne narzędzia formalne opisujące co najmniej przydzielanie i odbieranie uprawnień dostępu do systemów medycznych oraz polityki haseł.
Są to minimalne konieczne narzędzia formalne do wdrożenia na ich podstawie systemu MSIM oraz określenia zasad dostępu do niego. W ramach prac projektowych należy wypracować ujednoliconą politykę bezpieczeństwa dla systemu MSIM.
Wykonawca systemu MSIM w ramach realizacji projektu opracuje dokumentację ochrony danych osobowych na którą składać się będą następujące dokumenty:
• Polityka bezpieczeństwa danych osobowych,
• Instrukcja zarządzania systemem służącym do przetwarzania danych osobowych.
3.5. Oprogramowanie dziedzinowe
3.5.1.System HIS
L.P. | Podmiot | Producent | Nazwa | Wersja | Wsparcie [TAK/NIE] |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Politechnika Poznańska | ESKULAP | 4.4.1 bw | Tak |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | GEM Systemy Informatyczne | SIS | Brak wersjonowania | Tak |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | Comarch (Esaprojekt) | Optimed | 6.00.360 | Tak |
3.5.2.System LIS - analityka
L.P . | Podmiot | Producent | Nazwa | Wersja | Wsparcie [TAK/NIE] | Integra -cja z HIS |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Politechnika Poznańska | ESKULAP | 2.3.0 s | Tak | Tak |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | GEM Systemy Informatyczne | SIS | Brak wersjonowania | Tak | Tak |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | Xxxxxx | Centrum | 2.440.10.1285 | Tak | Tak |
3.5.3.System LIS - bakteriologia
X.X | Xxxxxxx | Producent | Nazwa | Wersja | Wspar cie | Integra -cja z HIS |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Politechnika Poznańska | ESKULAP | 1.2.1 h | Tak | Tak |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | GEM Systemy Informatyczne | SIS | Brak wersjonowania | TAK | Tak |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | Xxxxxx | Centrum | 2.440.10.1285 | Tak | Tak |
Opis Przedmiotu Zamówienia
3.5.4.System RIS
L.P. | Podmiot | Producent | Nazwa | Wersja | Wspa rcie | Integra -cja z HIS (wyniki opisowe) |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Agfa | IMPAX | 2.3.0 r | Tak | Tak |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | GEM Systemy Informatyczne | SIS | Brak wersjonowania | Tak | Tak |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | Comarch (Esaprojekt) | CRID | 3.1.14.4 | Tak | Tak |
3.5.5.System PACS
X.X | Xxxxxxx | Producent | Nazwa | Wersja | Wspa -rcie | Integ- racja z HIS |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Agfa | IMPAX | 6.4.0.4 513 | Tak | Nie |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | PIXEL | ExPACS | Ostatnia do wygaśnięcia wsparcia, tj. 01.12.2016 | Tak | Nie |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | Synektik | ARPACS | 2.143.145. | Tak | Tak |
3.5.6.E-Rejestracja
L.P. | Podmiot | Czy jest świadczona? | Producent | Nazwa/Uwagi | Wersja | Wspa rcie | Integra cja z HIS | Możliwość podłączenie pozostałych |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Nie | Brak | Brak | Brak | Nie | Nie | Nie |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | Nie (w trakcie projektowania) | Brak | Brak | Brak | Nie | Nie | Nie |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | Tak | Szpital Specjalistyczny im. L. Rydygiera Sp. z o.o. Dział Informatyki | Oprogramowanie autorskie wykonane we własnym zakresie | 1.0 | Tak. | Nie. | Nie. |
Strona 44 z 157
3.5.7.Wnioski
Integracja wymienionych systemów z HIS realizowana jest w zakresie wysyłania zlecenia i odbierania wyniku. Wynik nie zawiera danych obrazowych PACS. Z powyższego zestawienia danych wynika że większość systemów (za wyjątkiem PACS) jest już zintegrowana z HIS.
Analiza poziomu dojrzałości usługi e-Rejestracja wykazuje, że jest to usługa, która na poziomie lokalnym obecna jest w jednostkach na bardzo zróżnicowanym poziomie. Niektórzy Partnerzy Projektu nie posiadają takiej usługi, u niektórych jest ona na bardzo niskim poziomie dojrzałości lub jej wdrożenie jest dopiero planowane. Niektórzy Partnerzy posiadają taką usługę wdrożoną i zintegrowaną z oprogramowaniem HIS. Uruchomienie usługi e-Rejestracja w skali całego regionu wymaga jednak dodatkowych działań związanych z dostarczeniem części regionalnej rozwiązania i zintegrowanie jej z już obecnym rozwiązaniami.
3.6. Rodzaje przetwarzanych danych
Legenda:
01 - Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
02 - Szpital Specjalistyczny i. J. Dietla w Krakowie
03 - Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.
W poniższej tabeli wskazano system, z którego jest możliwość importu danych (HIS / LIS / RIS)
Podmiot | 01 | 02 | 03 | |
dokumenty podstawowe - priorytet 1 | ||||
1 | Formularz historii choroby | HIS | HIS | HIS |
2 | Wywiad lekarski | HIS | HIS | HIS |
3 | Xxxxxxxx | HIS | HIS | HIS |
4 | Karta informacyjna z leczenia szpitalnego | HIS | HIS | HIS |
5 | Opis przebiegu leczenia | HIS | HIS | - |
6 | Wyniki badań laboratoryjnych – analityka | HIS | HIS | HIS/LIS |
7 | Wyniki badan laboratoryjnych – bakteriologia | HIS | HIS | HIS/LIS |
8 | Wyniki badań diagnostyki obrazowej – opis | HIS | HIS | HIS/RIS |
9 | Wyniki konsultacji | HIS | HIS | - |
10 | Protokół operacyjny | HIS | HIS | HIS |
11 | Xxxxx zleceń lekarskich | HIS | HIS | - |
dokumenty rzadko spotykane w HIS - priorytet 2 | ||||
12 | Wywiad epidemiologiczny | HIS | HIS | - |
13 | Karta Oceny Ryzyka Xxxxxxxxx przy Przyjęciu do Szpitala | HIS | HIS | - |
14 | Ocena ryzyka związanego ze stanem odżywienia | HIS | HIS | HIS |
dokumenty pielęgniarskie - priorytet 3 | ||||
15 | Plan opieki | HIS | HIS | - |
16 | Xxxxx xxxxxxxxxx | HIS | HIS | HIS |
17 | Karta indywidualnej opieki pielęgniarskiej | - | HIS | - |
18 | Xxxxx obserwacyjna | HIS | HIS | - |
19 | Xxxxx wywiadu pielęgniarskiego | HIS | HIS | - |
20 | Raport pielęgniarski | - | HIS | - |
dokumenty nie wychodzące ze szpitala - brak konieczności wymiany pomiędzy jednostkami |
21 | Karta procesu sterylizacji | - | - | - |
22 | Karta kwalifikacyjna do zabiegu | HIS | HIS | - |
23 | Xxxxx xxxxxxxxx znieczulenia | HIS | HIS | - |
24 | Okołooperacyjna Karta Kontrolna | - | - | - |
25 | Karta zabiegów fizjoterapeutycznych | - | HIS | - |
26 | Karty TISS | - | - | - |
27 | Inne np. zgoda pacjenta na wykonanie badania lub zabiegu | - | - | HIS |
Powyższe dokumenty w postaci elektronicznej mają charakter sformatowanych plików tekstowych o niewielkim rozmiarze. Rozmiar każdego z nich nie jest ściśle określony ze względu na zmienność tekstów, które te dokumenty zawierają. Można szacować że ich rozmiar będzie ograniczony do kilkuset kilobajtów. Wszyscy partnerzy projektu zadeklarowali gotowość udostępniania oraz chęć korzystania z dokumentacji medycznej poprzez MSIM pod warunkiem że będzie to zgodne z obowiązującymi przepisami prawa.
W poniższej tabeli wskazano szacowany roczny przyrost tekstowych danych medycznych w [MB] przyjmując średnią wielkość pojedynczego dokumentu medycznego skonwertowanego do formatu pdf: 300kb uwzględniając liczbę pobytów oraz szacowaną częstość występowania danej dokumentacji. Przyjęto na potrzeby szacowania że zabiegi operacyjne dotyczą 6 % hospitalizacji (wyliczenia dokonano na podstawie danych statystycznych z 2007 roku).
Podmiot | 01 | 02 | 03 | |
Ilość hospitalizacji w roku | 28000 | 15000 | 28000 | |
Roczny przyrost danych [MB]- priorytet 1 | ||||
1 | Formularz historii choroby | 8400 | 4500 | 8400 |
2 | Wywiad lekarski | 8400 | 4500 | 8400 |
3 | Epikryza | 8400 | 4500 | 8400 |
4 | Karta informacyjna z leczenia szpitalnego | 8400 | 4500 | 8400 |
5 | Opis przebiegu leczenia | 8400 | 4500 | 8400 |
6 | Wyniki badań laboratoryjnych – analityka | 8400 | 4500 | 8400 |
7 | Wyniki badan laboratoryjnych – bakteriologia | 8400 | 4500 | 8700 |
8 | Wyniki badań diagnostyki obrazowej – opis | 8400 | 4500 | 45000 |
9 | Wyniki konsultacji | 8400 | 4500 | 8400 |
10 | Protokół operacyjny | 504 | 270 | 504 |
11 | Karta zleceń lekarskich | 8400 | 4500 | 8400 |
dokumenty rzadko spotykane w HIS - priorytet 2 | ||||
12 | Wywiad epidemiologiczny | 8400 | 4500 | 8400 |
13 | Karta Oceny Ryzyka Zakażenia przy Przyjęciu do Szpitala | 8400 | 4500 | 8400 |
14 | Ocena ryzyka związanego ze stanem odżywienia | 8400 | 4500 | 8400 |
dokumenty pielęgniarskie - priorytet 3 | ||||
15 | Plan opieki | 8400 | 4500 | 8400 |
16 | Karta gorączkowa | 8400 | 4500 | 8400 |
17 | Karta indywidualnej opieki pielęgniarskiej | 8400 | 4500 | 8400 |
18 | Karta obserwacyjna | 8400 | 4500 | 8400 |
19 | Karta wywiadu pielęgniarskiego | 8400 | 4500 | 8400 |
20 | Raport pielęgniarski | 8400 | 4500 | 8400 |
W poniższej tabeli wskazano roczny przyrost danych medycznych obrazowych w [GB]
L.P. | Podmiot | Roczny przyrost danych w [GB] |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | 1900 |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | 8000 |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | 3000 |
Analiza systemów dziedzinowych u Partnerów Projektu oraz rodzajów przetwarzanej dokumentacji pokazuje, że podstawowym i często jedynym systemem dziedzinowym, który daje możliwość integracji w zakresie EDM, jest oprogramowanie klasy HIS. Dodatkowo analiza wskazała, że większość podstawowej dokumentacji medycznej jest możliwa do wyeksportowania z używanego oprogramowania klasy HIS.
3.7. Gwarancja i serwis
Zapisy gwarancyjne oraz serwisowe umów podpisanych między szpitalami i dostawcami aplikacji/systemów dziedzinowych, nie gwarantują bez kosztowego przeprowadzenia integracji MSIM z systemami dziedzinowymi. Integracja zawsze skutkuje poniesieniem jej kosztów, można co najwyżej wpływać na rozmiar tych kosztów. W celu ich ograniczenia najważniejsze wydaje się doprowadzenie do stanu, w którym integracja z MSIM dotyczyłaby jak najmniejszej ilości systemów.
W obszarze wymiany EDM optymalnym rozwiązaniem wydaje się integracja podstawowego systemu dziedzinowego, czyli oprogramowania klasy HIS, z Repozytorium Elektronicznej Dokumentacji Medycznej.
3.7.1.Opieka serwisowa (ilość miesięcy do wygaśnięcia umowy)
X.X | Xxxxxxx | HIS | LIS | RIS | PACS |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | 1 | 1 | 1 | 1 |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | 26 | 26 | 26 | 36 |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | 13 | 17 | 13 | 24 |
3.7.2.Opieka serwisowa (SLA – czas reakcji na błąd krytyczny w godzinach)
X.X | Xxxxxxx | HIS | LIS | RIS | PACS |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | 48 | 48 | 48 | 48 |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | 8 | 8 | 8 | 12 |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o. | 24 | 24 | 24 | 24 |
3.7.3.Integracja z systemem HIS
L.P | Podmiot | LIS | RIS | PACS |
1. | Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | Tak | Tak | Nie |
2. | Szpital Specjalistyczny im. J. Dietla w Krakowie | Tak | Tak | Nie |
3. | Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx 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. Funkcjonalność Centrum Autoryzacji Podpisu Elektronicznego (CAPE)
Obecnie funkcjonująca w Centrum aplikacja PentaSCAPE RA-Service umożliwia uzyskanie certyfikatu na podstawie żądania w formacie PKCS#10. Nie ma określonych wymagań dot. zawartości żądania PKCS#10 (do certyfikatu pobierany jest jedynie klucz publiczny). CAPE obsługuje klucze i rozmiary zgodne z profilem certyfikatu użytego w PentaSCAPE Ra-Service do wystawienia certyfikatu.
Usługa umożliwiająca uzyskanie certyfikatu udostępniana jest poprzez interfejs WWW, w którym uwierzytelnianie odbywa się poprzez podanie loginu i hasła.
Usługa znakowania czasem realizowana jest za pomocą dostępnej przez protokół http aplikacji PentaSCAPE-TSAService i zgodna ze standardem RFC 3161.
Nie przeprowadzano testów wydajnościowych usługi. Aktualna wydajność usługi powinna być wystarczająca do planowanej skali systemu.
Ścieżka certyfikacyjna certyfikatu TSA obejmuje certyfikaty CA o nazwach wyróżniających: 'CN=RootCA, O=Wojewodztwo Malopolskie, C=PL' i 'CN=Centrum Autoryzacji w Malopolsce, O=Wojewodztwo Malopolskie, C=PL'.
Odpowiedzi OCSP podpisywane są kluczem dedykowanym. Nie przeprowadzano testów wydajnościowych usługi OCSP.
3.9. Lokalne słowniki dokumentów
Lokalne słowniki dokumentów w większości jednostek pokrywają się, ponieważ wynikają z obowiązującego prawodawstwa. Wszystkie rodzaje dokumentów są zdefiniowane w ramach systemu HIS, choć dotyczą również danych pochodzących z innych systemów dziedzinowych (LIS, RIS). Różnice między dokumentami wynikają ze specjalizacji jednostek oraz nieprecyzyjnego dookreślenia formatu dokumentacji przez ustawodawcę. Ponadto w jednostkach używa się dokumentów medycznych opracowanych na potrzeby własne szpitala (np. w Szpitalu Specjalistycznym im. J. Dietla w Krakowie Karta Przymusu). Kluczowym elementem systemu będzie wymiana dokumentacji medycznej w zw. z czym jeżeli niezbędne będzie w celu wykonania poprawnej integracji dostosowanie/ujednolicenie istniejących słowników, formatów danych i standardów danych słownikowych składowanych i udostępnianych należy to uwzględnić i wykonać we wdrożeniu.
4. Model statyczny
System MSIM składa się z komponentu regionalnego i komponentu lokalnego.
Wykonawca musi wdrożyć komponent regionalny w Szpitalu Specjalistycznym im. Ludwika Rydygiera w Krakowie sp. z o.o.
Wykonawca musi wdrożyć komponenty lokalne w każdym Szpitalu uczestniczącym w projekcie.
4.1. Komponent lokalny
Komponent lokalny składa się z następujących jednostek funkcjonalnych:
4.1.1.Repozytorium EDM
Repozytorium EDM to moduł odpowiedzialny za przyjmowanie i przechowywanie dokumentów medycznych z systemów źródłowych funkcjonujących w Szpitalach. Moduł ten odpowiada za gromadzenie, przetwarzanie EDM zgodnej ze standardem HL7 CDA R2 na 3-cim poziomie interoperacyjności,.
Repozytorium EDM musi wystawiać i obsługiwać interfejs przekazywania i rejestracji EDM zgodnie z wytycznymi ITI-41 profilu integracyjnego XDS.b (nie dotyczy architektury wewnętrznej systemu).
Repozytorium EDM musi obsługiwać interfejs pozwalający na pobranie EDM uwierzytelnionemu użytkownikowi zgodnie z wytycznymi ITI-43 (nie dotyczy architektury wewnętrznej systemu).
Repozytorium EDM musi wspierać opcję (rozszerzenie) profilu integracyjnego XDS.b związaną z obsługą asynchronicznej wymiany wiadomości (ang. „Asynchronous Web Services Exchange Option”).
4.1.2.Systemy dziedzinowe (źródłowe): HIS, LIS, RIS a MSIM
Systemy dziedzinowe to systemy informatyczne wspierające działalność leczniczą szpitala w tzw. części białej, które w kontekście niniejszego projektu stanowią źródło EDM. Systemy źródłowe (za wyjątkiem systemu HIS – w zakresie integracji pomiędzy lokalnym EDM, a HIS oraz e-Rejestracją z wykorzystaniem interfejsu opracowanego przez dostawcę HIS) nie są objęte w jakikolwiek sposób przedmiotem zamówienia. Ich dostosowanie do funkcjonowania zgodnie z zaproponowanymi interfejsami stanowi przedmiot odrębnych działań realizacyjnych.
Systemami dziedzinowymi w kontekście niniejszego projektu są systemy HIS, LIS, RIS i inne, w których generowana jest EDM.
4.1.3.Usługa podpisu elektronicznego dla EDM
Usługa podpisu elektronicznego dla EDM musi obsługiwać funkcję podpisywania i weryfikacji podpisu elektronicznego związanego z wdrożonym systemem tożsamości z wykorzystaniem Centrum Autoryzacji (CAPE w Małopolsce).
Usługa podpisu elektronicznego musi być zgodna z funkcjonującą Polityką Certyfikacji CAPE w Małopolsce.
Usługa musi integrować się z funkcjami CAPE w zakresie znakowania czasem oraz wykorzystania podpisu elektronicznego oraz pozostałych usług CAPE oraz wystawiać te usługi dla pozostałych komponentów Systemu MSIM, w tym repozytorium EDM, rejestru EDM oraz systemów dziedzinowych (w szczególności HIS).
4.1.4.Usługa buforowania dla klienta pobierania EDM
Usługa istnieje w celu pośredniczenia w asynchronicznym trybie pobierania EDM. Klient korzystający z usługi pobierania EDM w trybie asynchronicznym zamawia zgromadzenie EDM (np. z kilku różnych źródeł o znacznym wolumenie), a następnie usługa buforowania przejmuje w jego imieniu proces zgromadzenia EDM.
Usługa musi obsługiwać 2 interfejsy komunikacji:
• Push - w momencie wystąpienia zdarzenia zakończenia pobrania EDM wysyłany jest komunikat o gotowości do jej pobrania do zarejestrowanego klienta
• Pull – w momencie odebrania komunikatu od klienta wysyłana jest gotowa EDM lub w przypadku jej braku (np. trwa proces buforowania) zwracany jest komunikat o stanie procesu (np. procent i wolumen pobranych już danych w odniesieniu do całości)
Wymaga się aby nana etapie Analizy Przedwdrożeniowej, Wykonawca przedstawił możliwe warianty zapewnienia odporności do wyboru przez Zamawiającego na awarię w warstwie sieciowej (np. na zagrożenia typu przerwy w połączeniu).
4.2. Komponent regionalny
Komponent regionalny składa się z następujących jednostek funkcjonalnych:
4.2.1.Rejestr EDM
Rejestr EDM musi przechowywać scentralizowane informacje o miejscu składowania i fakcie wytworzenia wraz z informacją o wersjonowaniu wszystkich dokumentów medycznych w podmiotach biorących udział w Projekcie.
Za pomocą odpowiednich interfejsów uwierzytelniony Użytkownik Systemu MSIM będzie mógł odpytać warstwę regionalną o dokumenty w innych jednostkach oraz pobrać je w całości lub częściowo.
Rejestr EDM musi obsługiwać interfejs ITI-42 w zakresie rejestracji EDM.
Rejestr EDM musi obsługiwać interfejs ITI-18 w zakresie obsługi zapytań od użytkowników Systemu MSIM.
4.2.2.Źródło identyfikacji pacjentów
Źródło identyfikacji pacjentów musi jednoznacznie określać tożsamość pacjenta na podstawie jego właściwości.
Źródło identyfikacji musi obsługiwać interfejs ITI-42 w zakresie rejestracji EDM.
Źródło identyfikacji musi obsługiwać interfejs ITI-18 w zakresie obsługi zapytań od użytkowników Systemu MSIM.
4.2.3.Usługa uwierzytelniania i autoryzacji użytkowników
System musi przechowywać tożsamości użytkowników Systemu MSIM, w tym personelu medycznego i obsługi technicznej.
Musi przechowywać prawa dostępu użytkowników Systemu MSIM. Musi umożliwiać dodawanie, modyfikowanie i usuwanie użytkowników. Musi umożliwiać tworzenie grup użytkowników.
Grupy użytkowników związane ze struktura organizacyjną projektu (w tym Podmiotu) powinny być wprowadzone i skonfigurowane przed uruchomieniem Systemu MSIM oraz możliwe do edycji w każdym momencie.
Określanie praw dostępu musi być możliwe na poziomie grup użytkowników.
Do nawiązywania zdalnych połączeń administracyjnych muszą być stosowane protokoły komunikacyjne zapewniające bezpieczne uwierzytelnianie oraz poufność i integralność przesyłanych danych.
Uwierzytelnianie w MSIM musi być oparte na PKI z CAPE w Małopolsce (Certificate Authority). W szczególności uwierzytelnianie połączeń IPSec VPN ma być realizowane poprzez certyfikaty klientów VPN, wystawiane dla każdego z użytkowników indywidualnie przez CAPE (Centrum Autoryzacji podpisu elektronicznego). W zależności od uprawnień mogą być wystawiane osobne certyfikaty.
Uwierzytelniania w MSIM może być realizowane przy pomocy innych metod uwierzytelnienia tylko w uzgodnieniu z Zamawiającym. W szczególności zakłada się, że uwierzytelnianie Pacjentów (klientów) usługi e-Rejestracja powinno odbywać się przy pomocy metody opartej na loginie/haśle.
Ważność certyfikatu musi być weryfikowana w CAPE on-line przy pomocy protokołu OCSP lub podobnego.
Bezpieczeństwo kluczy powinno być realizowane z wykorzystaniem Polityki Certyfikacji CA MSIM. Polityka certyfikacji powinna być oparta na RFC3647 “Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Framework”.
Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfesju do usługi.
4.2.4.Usługa wyszukiwania EDM
Musi umożliwiać klientom (np. systemowi P1 w zakresie IKP lub aplikacjom webowym) przesłanie zapytania do rejestru EDM zgodnie z wytycznymi ITI-18 profilu integracyjnego XDS.b.
Usługa wyszukiwania EDM musi umożliwiać:
• Przeszukiwanie rejestru EDM,
• Odpowiedź na zapytania o pozycję rejestru,
• Zwracanie wyników zapytania,
Z uwzględnieniem praw dostępu użytkownika.
Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfesju do usługi.
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ć:
• Dostęp do repozytorium EDM,
• Odpowiadać na zapytania o pozycję repozytorium,
• Zwracać wyników zapytania,
• Zamówienie EDM (pobranie w trybie asynchronicznym),
• Odebranie EDM po wcześniejszym zamówieniu, Z uwzględnieniem praw dostępu.
Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfesju do usługi.
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 Xxxxxxxxxxx,
• Umożliwia określenia celu wizyty u lekarza, z podziałem na: przypadek nagły incydentalny, stan nagły przy chorobie przewlekłej, wizytę kontrolną, wizytę po kolejną receptę, wizytę po skierowanie na badanie specjalistyczne,
• Udostępnienie danych o zaplanowanych wizytach i usługach,
• Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana),
• Możliwość wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko pacjenta, numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla pacjenta,
• Dostęp do informacji o lokalizacji miejsca wykonania usługi,
• Możliwość odwołania rezerwacji.
• Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail)
Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfesju do usługi.
4.2.7.Usługa komunikacji z P1 (IKP)
Usługa odpowiedzialna za komunikację z P1 zgodnie z wytycznymi i interfejsem platformy P1.
Usługa musi umożliwiać przetworzenie zapytania o EDM przez Pacjenta i wywołać odpowiednie usługi w systemie MSIM.
Usługa musi umożliwiać wyszukanie EDM uwierzytelnionemu w P1 Pacjentowi. Usługa musi umożliwiać pobranie EDM uwierzytelnionemu przez P1 Pacjentowi.
Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfesju do usługi.
4.2.8.Usługa słownikowa
Celem funkcjonowania usługi słownikowej jest posiadanie jednolitej terminologii w EDM będącej przedmiotem wymiany w projekcie MSIM.
Usługa słownikowa pośredniczy w dostępie do słowników oferowanych przez platformę P1, tj.:
• ICD-10,
• ICD-9,
• ICF,
• ICNP
Usługa umożliwia klientom, w szczególności systemom dziedzinowym, na:
• Wyszukanie pełnotekstowe 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).
Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfesju do usługi.
4.2.9.Usługa synchronizacji rejestrów EDM
Usługa musi umożliwiać synchronizację regionalnego i lokalnych EDM. Usługa musi umożliwiać synchronizację ręczną (na żądanie).
Usługa musi umożliwiać konfigurowania interwału synchronizacji przez administratora ze względu na czas i rodzaj zdarzenia (np. otrzymanie nowego zapisu od rejestru, przesłanie dokumentacji do repozytorium lub dowolnego interfejsu wystawianego na szynie usług – regionalnie lub lokalnie).
Wymagane jest opracowanie programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfesju do usługi.
4.2.10. Portal informacyjny
Portal informacyjny musi być aplikacją webową prezentującą informacje o projekcie, świadczonych usługach, uczestniczących partnerach.
Portal musi być narzędziem klasy CMS umożliwiającym dostosowywanie oraz dodawanie treści przez użytkowników po stronie Zamawiającego.
Portal musi posiadać możliwość dowolnej edycji i wprowadzania tekstu, w m. in. tym tworzenia podstron, linkowania, podłączanie zdjęć.
Portal musi posiadać szatę graficzną uzgodnioną i zaakceptowaną przez Zamawiającego.
Portal musi zawierać odnośniki do wszystkich usług systemu, stanowiąc centralny punkt dostępu do systemu MSIM.
Portal musi być zintegrowany ze stroną województwa małopolskiego, oznaczony logiem projektu oraz banerami wymaganymi przepisami UE.
Z portalu musi być możliwe przejście do wszystkich usługi w tym e-Rejestracji. Na portalu udostępnione będą:
• Informacje o jednostkach ochrony zdrowia, które są zintegrowane z MSIM w ramach projektu (w tym lista usług świadczony przez te podmioty)
• Wyszukiwarka usług medycznych (wg typu usługi oraz wg jednostki ochrony zdrowia)
• Dane kontaktowe do jednostek ochrony zdrowia (tel. do placówki, poszczególnych specjalistów, informacji, rejestracji)
• Informacje nt. możliwości skorzystania z e-rejestracji (wraz z krótkim instruktażem jak z korzystać z rozwiązania na portalu oraz charakterystyka e-usługi - FAQ)
• Funkcjonalność umożliwiająca rejestrację oraz założenie konta
• Informacje o projekcie MSIM
Wszystkie powyższe dane, opisy, grafiki, funkcjonalności do portalu wprowadzi Wykonawca.
4.2.11. Panel administratora
Panel zawiera wszystkie funkcje potrzebne do administracji Systemem MSIM dla uprawnionych użytkowników (administratorów).
Panel musi posiadać interfejs webowy.
Panel dostępny jest z poziomu komponentu regionalnego w strefie umożliwiającą bezpieczną pracę administracyjną.
Moduł w szczególności musi spełniać następujące funkcje:
• dodawanie użytkowników,
• nadawanie i modyfikacja uprawnień,
• parametryzacja ustawień synchronizacji z innymi systemami,
• dodawanie podmiotów,
• konfiguracja modułów wymiany danych,
• konfiguracja modułu e-Rejestracji,
• konfiguracja usług.
4.3. Interfejsy
Każdy moduł funkcjonalny (usługa, źródło, repozytorium) musi udostępniać interfejsy dostępu w postaci usług publikowanych na regionalnej szynie usług.
Zakłada się model integracji oparty o jawne, otwarte, wyspecyfikowane w postaci języka WSDL interfejsy przyporządkowane do komponentów systemu. Każda interakcja pomiędzy komponentami systemu musi następować przy użyciu tych interfejsów. Interakcja nie może następować w postaci wywołań niejawnych. W tym celu wykorzystuje się interfejsy profilu integracyjnego XDS.b organizacji IHE, w szczególności:
• ITI-41 w zakresie dostarczania i rejestrowania dokumentów w repozytorium,
• ITI-42 w zakresie rejestrowania dokumentów w rejestrze
• ITI-43 w zakresie pozyskiwania dokumentów z repozytorium
• ITI-18 w zakresie zapytań do rejestru
• ITI-8 oraz ITI-44 w zakresie identyfikacji pacjenta przez rejestr
wraz z rozszerzeniami przewidzianymi wytycznymi w sprawie reguł tworzenia i modelu transportowego EDM publikowanymi przez CSIOZ.
Warstwa regionalna komunikuje się z lokalną szyną usług lub bezpośrednio lokalnym EDM. Dopuszcza się również możliwość istnienia serwerów buforowania po obu stronach (wstępne przetwarzanie, redukcja pasma transferowego).
Konstrukcja warstwy integracyjnej w warstwie regionalnej z wykorzystaniem powyższych standardów w zakresie usług wyszukiwania EDM w rejestrze (ITI-18) oraz pobierania EDM w repozytoriach (ITI- 43) musi umożliwiać integrację z innymi systemami regionalnymi i lokalnymi w obszarze e-Zdrowia.
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.
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.
5.3. Mapa główna procesów biznesowych
analysis Mapa procesów biznesowych w obszarze przekazywania EDM
«BusinessProcess» BP.ERP.001 Wyszukiwanie elektronicznej dokumentacji medycznej
«BusinessProcess» BP.ERP.002 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym
«BusinessProcess» BP.ERP.003 Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym
«BusinessProcess» BP.ERP.004 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z
wykorzystaniem IKP
Mapa główna procesów biznesowych stworzona jest dla zidentyfikowanych procesów biznesowych objętych Projektem MSIM – projekt pilotażowy i obejmuje listę procesów wraz z zależnościami na poziomie całości procesu.
analysis Mapa główna procesów biznesowych
Business Process Mapa procesów biznesowych w obszarze e-rejestracji
«BusinessProcess» PB.REJ.01 Rezerwacja terminu wizyty
«BusinessProcess» PB.REJ.02 Anulowanie rezerwacji terminu wizyty
Analizowane procesy biznesowe zostały zgrupowane w 2 grupy: procesy związane z obszarem przekazywania elektronicznej dokumentacji medycznej (EDM) oraz z obszarem e-Rejestracji.
5.4. Przekazywanie EDM
Szczegółowa mapa procesów biznesowych w obszarze przekazywania EDM przedstawia informacje o procesach biznesowych związanych z typowymi operacjami dotyczącymi elektronicznej dokumentacji medycznej. Model obejmuje procesy wyszukiwania i pobierania elektronicznej dokumentacji pacjenta zgromadzonej w jednostkach opieki zdrowotnej zintegrowanych z MSIM.
analysis Mapa procesów biznesowych w obszarze przekazywania EDM
«BusinessProcess» BP.ERP.001 Wyszukiwanie elektronicznej dokumentacji medycznej
«BusinessProcess» BP.ERP.002 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym
«BusinessProcess» BP.ERP.003 Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym
«BusinessProcess» BP.ERP.004 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z
wykorzystaniem IKP
Rysunek 12 Mapa procesów biznesowych w obszarze przekazywania EDM
Procesy biznesowe związane z pobieraniem EDM logicznie następują po wyszukaniu wszystkich niezbędnych informacji (metadanych) o EDM.
5.4.1.BP.ERP.001 Wyszukiwanie elektronicznej dokumentacji medycznej
Nazwa procesu | Wyszukiwanie elektronicznej dokumentacji medycznej |
Numer procesu | BP.ERP.001 |
Wersja procesu | 1 |
Cel procesu | Celem niniejszego procesu jest wyszukanie EDM pacjenta |
Uczestnicy procesu | pracownicy medyczni, komponent regionalny |
Warunki wejściowe | • Istnieje kanał komunikacyjny pomiędzy podmiotami. • Znane są dane pacjenta, dla którego wyszukiwana jest elektroniczna dokumentacja. • Pracownik medyczny ma prawo do wyszukania elektronicznej dokumentacji medycznej pacjenta. • Zgoda pacjenta na udostępnienie danych elektronicznej dokumentacji medycznej. |
Opis procesu | 1. Pracownik medyczny wprowadza kryterium wyszukiwania elektronicznej dokumentacji medycznej (EDM) pacjenta podając, co najmniej, dane |
pozwalające na jego identyfikację. 2. Komponent regionalny sprawdza czy są obsługiwane zgody na wyszukiwanie EDM dla danego pacjenta, czyli ERP. 3. Komponent regionalny odnajduje zarejestrowaną w rejestrze EDM i pozyskuje zbiór metadanych EDM spełniający kryteria wyszukiwania. 4. Zbiór zawierający metadane EDM spełniający kryteria jest przekazywany do klienta 5. Metadane EDM są prezentowane Pracownikowi medycznemu | |
Warunki wyjściowe | • Zbiór metadanych dotyczących EDM zostaje zeprezentowany pracownikowi medycznemu. • Zaprezentowany zbiór metadanych dotyczących EDM jest zgodny z zapytaniem |
analysis BP.ERP.001 Wyszukiwanie elektronicznej dokumentacji medycznej
Zapoznaj się z odmową dostępu
«SequenceFlow»
Wypełnij kryterium wyszukiwania
Zapoznaj się z EDM
«SequenceFlow»
«SequenceFlo«wG»ateway» Czy są
obsługiwane zgody
[Nie] ERP?
[Tak]
«SequenceFlow»
«Gateway» Czy istnieje zgoda
Przekaż wynik odmowny
«SequenceFlow»ta?
«Sequ[Neinec]eFlow»
[Tak]
«SequenceFlow»
«Gateway»
Odpytaj rejestr EDM «SequenceFlow»
Zbuduj odpowiedź o
«SequenceFlow» EDM
Rejestr EDM
«Pool» Konsument EDM
Poniżej przedstawiono postać graficzną procesu biznesowego.
ne
pacjen
«Pool» Kompo nt regionalny
5.4.2.BP.ERP.002 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym
Nazwa procesu | BP.ERP.002 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym |
Numer procesu | BP.ERP.002 |
Wersja procesu | 1 |
Cel procesu | Celem niniejszego procesu jest pobranie EDM dla pacjenta oraz jej zapisanie w lokalnym systemie |
Uczestnicy procesu | pracownicy medyczni, komponent lokalny, komponent regionalny |
Warunki wejściowe | • Istnieje kanał komunikacyjny pomiędzy podmiotami. • Znane są dane pacjenta i pobieranej EDM. • Pracownik medyczny ma prawo do pobrania elektronicznej dokumentacji medycznej pacjenta. • Zgoda pacjenta na udostępnienie danych elektronicznej dokumentacji medycznej. |
Opis procesu | 1. Pracownik medyczny wybiera z listy dostępnych EDM (zaprezentowanych przez metadane z rejestru) dokładnie jedną EDM lub ich zbiór. 2. Komponent regionalny sprawdza czy są obsługiwane zgody na pobranie EDM dla danego pacjenta, czyli ERP. 3. Komponent regionalny na podstawie danych identyfikacyjnych EDM lub ich zbiór zestawia połączenie z odpowiednim repozytorium EDM 4. Komponent regionalny pobiera z repozytorium EDM żądane pozycje 5. Komponent regionalny na podstawie uzyskanych odpowiedzi buduje zbiór wynikowy odpowiedzi 6. Komponent regionalny zwraca żądane pozycje do klienta 7. Wynik prezentowany jest pracownikowi medycznemu w sposób umożliwiający jego zapisanie na komputerze klienta |
Warunki wyjściowe | • Elektroniczny dokument medyczny lub ich zbiór zostaje zaprezentowany pracownikowi medycznemu. |
Poniżej przedstawiono postać graficzną procesu biznesowego.
analysis BP.ERP.002 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym
Zapisz EDM
Konieczność dostępu do EDM pacjenta
Koniec
Wybierz EDM
Interpretacja wyniku
Zapoznaj się z EDM lub z wynikiem odmownym
Żądanie pobrania EDM
Czy są obsługiwane zgody ERP?
[TAK]
Zbuduj odpowiedź o EDM
Czy istnieje zgoda pacjenta?
[NIE]
Przekaż wynik odmowny
[TAK]
[NIE]
Odpytaj repozytorium EDM
Pobierz EDM
Żadanie wyszukania EDM
Repozytorium EDM
«Pool» Komponent lokalny
«Pool» Komponent regionalny
«Pool» Konsument EDM
5.4.3.BP.ERP.003 Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym
Nazwa procesu | BP.ERP.003 Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym |
Numer procesu | BP.ERP.003 |
Wersja procesu | 1 |
Cel procesu | Celem niniejszego procesu jest pobranie EDM dla pacjenta oraz jej zapisanie w lokalnym systemie |
Uczestnicy procesu | pracownicy medyczni, lokalne systemy dziedzinowe, komponent regionalny |
Warunki wejściowe | • Istnieje kanał komunikacyjny pomiędzy podmiotami. • Znane są dane pacjenta i pobieranej EDM. • Pracownik medyczny ma prawo do pobrania elektronicznej dokumentacji medycznej pacjenta. • Zgoda pacjenta na udostępnienie danych elektronicznej dokumentacji medycznej. |
Opis procesu | 1. Pracownik medyczny wybiera z listy dostępnych EDM (zaprezentowanych przez metadane z rejestru) dokładnie jedną EDM lub ich zbiór. 2. Żądanie pobrania EDM jest przekazane do komponentu regionalnego. 3. Komponent regionalny na podstawie danych identyfikacyjnych EDM lub ich zbiór zestawia połączenie z odpowiednim repozytorium EDM 4. Komponent regionalny zwraca komunikat do klienta o przekazaniu żądania pobrania EDM wraz z przekazaniem tokena żądania w celu późniejszego pobrania EDM 5. Komponent regionalny pobiera z repozytorium EDM żądane pozycje 6. Komponent regionalny na podstawie uzyskanych odpowiedzi buduje zbiór wynikowy odpowiedzi i zgłasza go do odbioru 7. Wpływa zapytanie od klienta zawierające token żądania 8. Komponent regionalny zwraca żądane pozycje do klienta |
Warunki wyjściowe | • Elektroniczny dokument medyczny lub ich zbiór zostaje zaprezentowany pracownikowi medycznemu. |
Poniżej przedstawiono postać graficzną procesu biznesowego.
analysis BP.ERP.003 Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym
Przechowania tokena żądania
Koniec
Token żadania
Potrzeba zapytania o dostępność zamówionej EDM
Zapisz EDM
Koniec
Konieczność dostępu do EDM pacjenta
Otrzymanie komunikatu o
przekazaniu żądania
Zapoznaj się z EDM
Zapytanie o dostępność
Wybierz EDM
Komunikat o przekazaniu żądania zamówionej EDM
Co zrobić z otrzymaną EDM?
EDM
Otrzymanie komunikatu o braku możlwości pobrania
EDM
Typ odpowiedzi
[TAK]
[NIE]
Żadanie wznowienia transakcji
asynchronicznej
Żądanie pobrania EDM
Czy są obsługiwane zgody ERP?
Czy zamówiona EDM jest już dostępna? [TAK]
[TAK]
Czy istnieje zgoda pacjenta?
[NIE]
Przekaż wynik odmowny
[TAK]
[NIE]
Czy transakcja zawiera token?
Zbuduj odpowiedź o EDM
[NIE] Odpytaj repozytorium
EDM
Pobierz EDM
Żadanie wyszukania EDM
Repozytorium EDM
«Pool» Komponent lokalny
«Pool» Komponent regionalny
«Pool» Konsument EDM
5.4.4.BP.ERP.004 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z wykorzystaniem IKP
Nazwa procesu | BP.ERP.004 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z wykorzystaniem IKP |
Numer procesu | BP.ERP.004 |
Wersja procesu | 1 |
Cel procesu | Xxxxx niniejszego procesu jest pobranie EDM dla pacjenta korzystającego z IKP |
Uczestnicy procesu | System P1, komponent lokalny, komponent regionalny |
Warunki wejściowe | • Istnieje kanał komunikacyjny pomiędzy podmiotami. |
• Znane są dane pacjenta i pobieranej EDM. • Użytkownik systemu P1 ma prawo do pobrania elektronicznej dokumentacji medycznej pacjenta. • Zgoda pacjenta na udostępnienie danych elektronicznej dokumentacji medycznej. | |
Opis procesu | 1. Użytkownik systemu P1 wykonuje żądanie pobrania EDM. Użytkownik systemu P1 występuje w roli Konsumenta EDM. 2. Komponent regionalny sprawdza czy są obsługiwane zgody na wyszukiwanie EDM dla danego pacjenta, czyli ERP. 3. Komponent regionalny na podstawie danych identyfikacyjnych EDM lub ich zbiór zestawia połączenie z odpowiednim repozytorium EDM 4. Komponent regionalny pobiera z repozytorium EDM żądane pozycje 5. Komponent regionalny na podstawie uzyskanych odpowiedzi buduje zbiór wynikowy odpowiedzi 6. Komponent regionalny zwraca żądane pozycje do systemu IKP |
Warunki wyjściowe | • Elektroniczny dokument medyczny lub ich zbiór zostaje przekazany do systemu IKP |
Poniżej przedstawiono postać graficzną procesu biznesowego.
analysis BP.ERP.004 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z wykorzystaniem IKP
Zapisz EDM
Konieczność dostępu do EDM pacjenta
Koniec
Wybierz EDM
Interpretacja wyniku
Zapoznaj się z EDM lub z wynikiem odmownym
Żądanie pobrania EDM
Zbuduj odpowiedź o EDM
Czy są obsługiwane zgody ERP?
[TAK]
Czy istnieje zgoda pacjenta?
[NIE]
Przekaż wynik odmowny
[TAK]
[NIE]
Odpytaj repozytorium EDM
Pobierz EDM
Żadanie wyszukania EDM
Repozytorium EDM
«Pool» Komponent lokalny
«Pool» Komponent regionalny
«Pool» System IKP (Konsument EDM)
5.5. e-Rejestracja
Szczegółowa mapa procesów biznesowych w obszarze e-Rejestracji obejmuje procesy związane z usługą e-Rejestracja.
Business Process Model procesów biznesowych
«BusinessProcess» PB.REJ.01 Rezerwacja terminu wizyty
«BusinessProcess» PB.REJ.02 Anulowanie rezerwacji terminu wizyty
Rysunek 13 Mapa procesów biznesowych w obszarze e-Rejestracji
Usługa 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 zostanie wykonany system komunikatów (powiadomień dla użytkowników końcowych w formie: wiadomości e-mail oraz dodatkowo System MSIM musi być przygotowany do realizacji usługi wysyłania powiadomień SMS. Zamawiający podczas użytkowania systemu będzie miał możliwość wyboru, która forma powiadomień będzie realizowana z poziomu panelu administracyjnego) 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).
5.5.1.PB.REJ.01 Rezerwacja terminu wizyty
Nazwa procesu | Rezerwacja terminu wizyty |
Numer procesu | PB.REJ.01 |
Wersja procesu | 1 |
Cel procesu | Celem procesu jest rejestracja wizyty pacjenta w ramach eUsługi - rejestracja jest wykonywana w lokalnym systemie HIS. |
Uczestnicy procesu | Komponent regionalny, lokalne systemy dziedzinowe, użytkownicy końcowi (pacjenci). |
Warunki wejściowe | • Istnieje kanał komunikacyjny pomiędzy warstwą regionalną a warstwą lokalną. • Użytkownik posiadający konto użytkownika końcowego jest zalogowany do systemu. |
Opis procesu | 1) Zalogowany użytkownik końcowy w warstwie regionalnej wskazuje okres świadczenia (symbolicznie, np. wtorek do południa) na konkretną usługę realizowaną (przez konkretny personel) w konkretnym miejscu. 2) Użytkownik wybiera formularz rejestracji. 3) Komponent regionalny przekazuje żądanie zablokowania terminu wizyty do odpowiedniego Podmiotu. 4) System lokalny HIS blokuje wskazany termin dla wybranej usługi (ewentualnie w połączeniu z personelem lub komórką organizacyjną). 5) Użytkownik wypełnia formularz rejestracji. Zawartość formularza jest uzależniona od jednostki ochrony zdrowia i typu usługi. Formularz jest wstępnie wypełniony przez system danymi pobranymi z konta użytkownika oraz uzupełniony o dane wynikające z wybranej przez użytkownika usługi. Komponent regionalny sprawdza kompletność |
i poprawność wypełnienia formularza rejestracji i informuje o efekcie kontroli użytkownika. Użytkownik poprawia zgłoszone błędy. 6) Warstwa regionalna weryfikuje kolizje rezerwacji. Sprawdzane jest, czy istnieją jakieś rezerwacje na ten sam dzień i na tę samą godzinę, co wskazany termin. 7) Jeżeli wystąpiła kolizja, to Komponent regionalny informuje o tym użytkownika i kończy proces rezerwacji terminu wizyty. Jednocześnie warstwa regionalna wysyła do warstwy lokalnej żądanie zwolnienia zablokowanego terminu. System lokalny odblokowuje wskazany termin wizyty. 8) Jeśli wybrany termin jest poprawny, to użytkownik otrzymuje możliwość ostatecznego potwierdzenia wysłania rezerwacji albo anulowania rezerwacji wybranego terminu. 9) Jeżeli użytkownik zrezygnuje z rezerwacji wskazanego terminu wizyty, to warstwa regionalna wysyła do warstwy lokalnej żądanie zwolnienia zablokowanego terminu. System lokalny odblokowuje wskazany termin wizyty. 10) Jeśli użytkownik potwierdzi rezerwację, to system regionalny wysyła do odpowiedniego Podmiotu dane wymagane do zarejestrowania pacjenta. 11) Lokalny system HIS weryfikuje otrzymane dane pod kątem możliwości zapisania w HIS rejestracji dla określonego pacjenta. 12) Jeśli przesłane dane nie umożliwiają rejestracji pacjenta na wybraną usługę, to system lokalny przesyła do warstwy regionalnej informację o odrzuceniu rezerwacji i odblokowuje wskazany termin wizyty. 13) Jeżeli weryfikacja przesłanych danych przebiegnie pomyślnie, to system lokalny rezerwuje wskazany termin wizyty i wysyła do komponentu regionalnego potwierdzenie przyjęcia rejestracji. 14) Warstwa regionalna informuje użytkownika o przyjęciu rezerwacji terminu wizyty i zapisuje rejestrację w danych przechowywanych na jego koncie. 15) W zależności od konfiguracji komponent regionalny wysyła do użytkownika końcowego powiadomienia potwierdzające rejestrację w postaci wiadomości SMS i/lub e-mail. 16) W przypadku braku informacji zwrotnej od warstwy lokalnej, z potwierdzeniem lub odrzuceniem rejestracji, warstwa regionalna informuje o tym użytkownika i jednocześnie wysyła do skutku dane rezerwacji do lokalnego systemu HIS. | |
Warunki wyjściowe | • W lokalnym systemie medycznym HIS zostaje zapisana rezerwacja terminu wizyty na wybraną usługę medyczną. • W danych historii rejestracji na koncie użytkownika końcowego zostaje zapisana rezerwacja. |
Poniżej przedstawiono postać graficzną procesu biznesowego.
analysis PB.REJ.01 Rezerwacja terminu wizyty
dane z konta głównego albo wskazanego subkonta
Rejestr Użytkowników Końcowych
rejestracje na wybrany termin
Wyszukaj termin wizyty do rejestracji
Konieczność rejestracji na wizytę
dane do konfiguracji formularza
czas oczekiwania na odpowiedź z HIS
«DataInputAssociation»
«SequenceFlow»
Wysyłaj rezerwację do skutku (celem
potwierdzenia lub odrzucenia rejestracji)
«DataOutputAssociation»
«DataOutputAssociation»
«SequenceFlow»
Termin wizyty
«DataInputAssociation» Wybierz formularz
«DataInputAssociation»
rejestracji
«DataInputAssociation»
«DataInputAssociation»
Wyślij powiadomienie
«SequenceFlow»
Koniec
«DataInputAssociation»
Wypełnij formularz danych rezerwacji
Zapisz rejestrację w historii rejestracji
«SequenceFlow»
«SequenceFlow»
Weryfikuj kolizje rezerwacji
«SequenceFlow»
Poinformuj o przyjęciu rejestracji
«SequenceFlow»
Czy wykryto
«DataInputAssoc«iaDtaiotanI»nputAssociation» kolizję?
[Nie]
Potwierdź wysłanie rezerwacji lub anuluj
«SequenceFlow»
[Tak]
«DataInputAssociation»
Poinformuj o odrzuceniu przyjęcia rejestracji
Poinformuj o kolizji
«SequenceFClozyw»
potwierdzono wysłanie rezerwacji?
unikalny numer rejestracji w HIS
«SequenceFlow»
«DataOutputAssociation»
«SequenceFlow»
Wyślij rezerwację
«SequenceFlow»
[Nie]
«S[eTqauke] nceFlow» wizyty do jednostki
«SequenceFlow»
opieki medycznej
«MessageFlow»
«MessageFlow»
«MessageFlow»
«MessageFlow»
«MessageFlow»
«SequenceFlow»
Zweryfikuj rezerwację
Zablokuj wskazany termin dla uslugi (i personelu)
Wyślij potwierdzenie przyjęcia rejestracji
«SequenceFlow»
«SequenceFlow»
«DataOutputAssociation»
[Nie]
[Tak]
Zarejestruj pacjenta -
«SequenceFlow» zarezerwuj termin
Wyślij informacje o odrzuceniu rejestracji
«SequenceFlow»
baza HIS
«DataOutputAssociation»
Czy przyjęto
rejestrację wizyty?
wizyty
«SequenceFlow»
Odblokuj wskazany termin
«SequenceFlow»
«SequenceFlow»
Koniec
upłynął czas na potwierdzenie
:External Reference
«Pool» Komponent lokalny
«Pool» Komponent regionalny
«Lane» e-Rejestracja
«Lane» Katalogi Danych
5.5.2.PB.REJ.02 Anulowanie rezerwacji terminu wizyty
Nazwa procesu | Anulowanie rezerwacji terminu wizyty |
Numer procesu | PB.REJ.02 |
Wersja procesu | 1 |
Cel procesu | Celem procesu jest anulowanie rezerwacji wizyty w ramach eUsługi. |
Uczestnicy procesu | Komponent regionalny, lokalne systemy dziedzinowe, użytkownicy końcowi (pacjenci). |
Warunki wejściowe | • Istnieje kanał komunikacyjny pomiędzy warstwą regionalną a warstwą lokalną. • Użytkownik posiadający konto użytkownika końcowego jest zalogowany do systemu. • W lokalnym systemie medycznym HIS istnieje zapisana rezerwacja terminu wizyty na usługę medyczną. |
Opis procesu | 1) Zalogowany użytkownik, chcący anulować rezerwację wskazanej wizyty, wybiera |
opcję anulowania. 2) Użytkownik zatwierdza decyzję o rezygnacji z wizyty we wskazanym terminie. 3) Warstwa regionalna wyświetla informację o anulowaniu wizyty i przekazuje do odpowiedniego Podmiotu żądanie anulowania rejestracji w lokalnym systemie HIS. 4) System lokalny anuluje wskazaną rejestrację i przekazuje do warstwy regionalnej potwierdzenie anulowania. 5) W wyniku potwierdzenia system regionalny zmienia status rejestracji w danych rejestracji. 6) W zależności od konfiguracji warstwa regionalna wysyła do użytkownika końcowego powiadomienia o anulowaniu wizyty w postaci wiadomości SMS i/lub e-mail. | |
Warunki wyjściowe | • Rezerwacja terminu wizyty na usługę medyczną w lokalnym systemie medycznym HIS zostaje anulowana. • W danych historii rejestracji na koncie użytkownika końcowego status rezerwacji wskazanej do anulowania zostaje ustawiony na wartość „Anulowana”. |
Poniżej przedstawiono postać graficzną procesu biznesowego.
analysis PB.REJ.02 Anulowanie rezerwacji terminu wizyty
Rejestr Użytkowników Końcowych
Dane listy rejestracji
«DataInputAssociation»
Wskaż rejestrację, którą należy anulować
Konieczność anulowania
rezerwacji terminu wizyty
Potwierdź decyzję o anulowaniu rejestracji
:External Reference
[Nie]
Czy użytkownik potwierdził decyzję?
[Tak]
skonfigurowano powiadomienie SMS'em
Wyświetl informację o anulowaniu rejestracji
Wyślij SMS z powiadomieniem
«SequenceFlow»
Zmień status rejestracji w danych rejestracji
«SequenceFlow»
Koniec
Żądanie anulowania rejestracji w HIS
skonfigurowano powiadomienie e-mail'em
Wyślij e-mail z powiadomieniem
Anulowanie Rejestracji
Potwierdzenie Anulowania
baza HIS
Anuluj wskazaną rejestrację
Potwierdź anulowanie rejestracji
«Pool» Komponent lokalny
«Pool» Komponent regionalny
«Lane» e-Rejestracja
«Lane» Katalogi Danych
6. Wymagania Systemu MSIM
6.1. Wymagania ogólne
I.1.1.1. Cały dostarczony sprzęt musi być fabrycznie nowy, tzn. nieużywany przed dniem dostarczenia.
I.1.1.2. Dostarczone urządzenia oraz dostarczone wraz z nimi oprogramowanie muszą pochodzić z oficjalnych kanałów dystrybucyjnych producenta, zapewniających w szczególności realizację uprawnień gwarancyjnych.
I.1.1.3. Cały dostarczony sprzęt i oprogramowanie musi zawierać wszelkie niezbędne licencje do realizacji założonych funkcjonalności na czas nieograniczony.
I.1.1.4. Wszelkie aplikacje internetowe/intranetowe muszą działać w technologii co najmniej trójwarstwowej z wyodrębnionymi co najmniej warstwami :
I.1.1.4.1. Bazy danych
I.1.1.4.2. Warstwa aplikacji – logika biznesowa możliwa realizowanej na serwerze aplikacji możliwym do uruchomienia na systemach z rodziny MS Windows Server, Linux i Unix.
I.1.1.4.3. Warstwy prezentacji - interfejs użytkownika; wymagana jest obsługa przeglądarek internetowych w ich aktualnych wersjach, co najmniej MS Internet Explorer, Mozilla Firefox, Google Chrome z suportem przez okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego.
I.1.1.5. Architektura rozwiązania e-usług ma się składać z co najmniej następujących elementów logicznych:
I.1.1.5.1. Broker informacji (jako element regionalnej szyny usług), odpowiedzialny za propagowanie zapytań o dane oraz udzielanych odpowiedzi pomiędzy poszczególnymi jednostkami ochrony zdrowia a MSIM,
I.1.1.6. Broker odpowiada za:
I.1.1.6.1. przekazanie komunikatu zawierającego pytanie do wskazanej jednostki.
I.1.1.6.2. przekazanie uzyskanej odpowiedzi do jednostki, która zadała pytanie.
I.1.1.6.3. możliwość kolejkowania dystrybuowanych komunikatów oraz asynchronicznej komunikacji z węzami sieci, w celu zapewniania możliwości pozyskania danych z czasowo niedostępnych systemów źródłowych.
I.1.1.7. System musi umożliwiać wydajną, efektywną i ergonomiczną pracę dla jednocześnie zalogowanych minimum 2100 użytkowników bez utraty wydajności.
I.1.1.8. Dostarczone urządzenia powinny posiadać certyfikat (oznaczenie) CE (Conformité Européenne).
I.1.1.9. Eksport danych z bazy i repozytorium nie będzie wymagał żadnych dodatkowych prac ze strony Wykonawcy. Sposób wykonania eksportu będzie udokumentowany w odpowiedniej części dokumentacji Systemu.
I.1.1.10. Eksport danych z bazy i Repozytorium EDM nie będzie wymagał poniesienia żadnych dodatkowych kosztów przez Zamawiającego na rzecz Wykonawcy.
I.1.1.11. Produkty realizujące funkcjonalność platformy muszą mieć zagwarantowaną długość życia (wsparcia, uaktualnień) przez okres wskazany w ofercie lecz nie mniej niż 5 lat od daty wydania produktu, bez ponoszenia dodatkowych kosztów przez Zamawiającego.
I.1.1.12. Nowe wersje produktu nie mogą odbierać możliwości korzystania ze wsparcia z poprzednich wersji w okresie długości ich życia.
I.1.1.13. Gwarancja kompatybilności interfejsów programistycznych produktu przez okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego.
I.1.1.14. Wykonawca musi przeprowadzić wizję lokalną w celu uszczegółowienia zakresu prac adaptacyjnych w serwerowniach Partnerów.
6.2. Wymagania ogólne interfejsu użytkownika
Nr funkcjonalności | Funkcjonalność |
IU.1 | Interfejs użytkownika |
IU.1.1 | Wszystkie aplikacje wchodzące w skład systemu MSIM muszą posiadać spójny wygląd. |
IU.1.2 | System musi być dostępny dla użytkownika w języku polskim (może nie dotyczyć narzędzi administracyjnych firm trzecich, w których dopuszcza się interfejs w języku angielskim). |
IU.1.3 | Zamawiający wymaga aby dostęp do elementów systemu dostępnych przez przeglądarkę internetową mógł być realizowany z minimum następujących przeglądarek: Mozilla Firefox, Google Chrome, Internet Explorer. Wymagane jest, aby wskazane elementy systemu posiadały możliwość dostosowywania do pojawiających się w przyszłości nowych wersjach wskazanych przeglądarek internetowych przez okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego. |
6.3. Wymagania prawne, organizacyjne i funkcjonalne
Umowy z dostawcami oprogramowania wykluczają samowolne zmiany struktur danych oraz dostęp do nich spoza aplikacji licencjodawców. Dlatego jakiekolwiek pobieranie danych z systemów dziedzinowych musi być realizowane za pośrednictwem narzędzi dostarczanych przez producentów oprogramowania dziedzinowego. Wymiana danych odbywa się wyłącznie za pośrednictwem webserwisów dostarczanych przez producentów zgodnie ze specyfikacją w Załączniku 9A.Dokumentacja medyczna podlega szczególnej ochronie wynikającej z ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych. Jak wynika z jej przepisów dane szczególnie wrażliwe, jakimi są dane o stanie zdrowia, kodzie genetycznym, nałogach lub życiu seksualnym, nie mogą być przetwarzane w przypadkach innych niż wymienione w ustawie. Istotne dla omawianego zagadnienia jest dopuszczenie przetwarzania tych danych, jeżeli osoba, której dane dotyczą wyrazi zgodę na
przetwarzanie (zgoda musi być wyrażona na piśmie).Jeżeli przepisy innych ustaw zezwalają na przetwarzanie tych danych bez zgody tej osoby, stwarzając jednocześnie pełne gwarancje ich ochrony oraz jeżeli jest ono prowadzone w celu ochrony stanu zdrowia, świadczenia usług medycznych lub leczenia pacjentów przez osoby trudniące się zawodowo leczeniem lub świadczeniem innych usług medycznych, zarządzenia udzielaniem usług medycznych i zapewniono pełne gwarancje ochrony tych danych. Ograniczenia nie dotyczą jednak zbiorczej dokumentacji medycznej, anonimizowanych danych, uniemożliwiających zidentyfikowanie podmiotu, którego dotyczą. Przepisy te, pozwalające na przetwarzanie dokumentacji medycznej we wskazanych wyżej warunkach, umożliwiają funkcjonowanie systemów zarówno regionalnych, jak i lokalnych. Istotny z punktu widzenia ochrony danych osobowych wymóg wprowadza jednak ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowie w artykule 35, stanowiąc, że usługobiorca może nie wyrazić zgody na przetwarzanie jego jednostkowych danych medycznych w module statystyczno – rozliczeniowym Systemu Informacji Medycznej.
Dane przechowywane są przez wskazane w przepisach podmioty, ponadto ustawa o ochronie danych osobowych wprowadza możliwość outsourcingu. Zgodnie z art. 31 ust. 1: Administrator danych może powierzyć innemu podmiotowi, w drodze umowy zawartej na piśmie, przetwarzanie danych. Umowa ta musi być zawarta na piśmie i powinna szczegółowo określać zakres i cel przetwarzania tych danych.
Repozytoria EDM, prowadzone przez szpitale, będą gromadzić dane dotyczące usługobiorców, udzielonych, udzielanych i planowanych świadczeniach opieki zdrowotnej. Zgodnie z art. 24 ustawy z dnia 6 listopada 2008 r. prawach pacjenta i Rzeczniku Praw Pacjenta podmiot udzielający świadczeń zdrowotnych jest obowiązany prowadzić, przechowywać i udostępniać dokumentację medyczną w sposób określony w ustawie oraz zapewnić ochronę danych zawartych w tej dokumentacji. Artykuł 25 tej ustawy wskazuje, że dokumentacja ta powinna zawierać, co najmniej:
1) Oznaczenie usługobiorcy, pozwalające na ustalenie jego tożsamości:
a. Nazwisko i imię (imiona),
b. Datę urodzenia,
c. Oznaczenie płci,
d. Adres miejsca zamieszkania,
e. Numer PESEL, jeżeli został nadany, w przypadku noworodka – numer PESEL matki, a w przypadku osób, które nie mają nadanego numeru PESEL – rodzaj i numer dokumentu potwierdzającego tożsamość,
f. W przypadku gdy pacjentem jest osoba małoletnia, całkowicie ubezwłasnowolniona lub niezdolna do świadomego wyrażenia zgody – nazwisko i imię (imiona) przedstawiciela ustawowego oraz adres jego miejsca zamieszkania;
2) oznaczenie podmiotu udzielającego świadczeń zdrowotnych ze wskazaniem komórki organizacyjnej, w której udzielono świadczeń zdrowotnych;
3) opis stanu zdrowia pacjenta lub udzielonych mu świadczeń zdrowotnych;
4) datę sporządzenia.
Przepisy te dają podstawy prawne do gromadzenia na bieżąco przez lokalne repozytoria wytwarzanej na bieżąco elektronicznej dokumentacji medycznej. Szczegółowy zakres gromadzonej przez szpitale dokumentacji wskazuje Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania w paragrafie 12, wyróżniając dokumentację indywidualną wewnętrzną, dokumentację zbiorczą wewnętrzną, dokumentację indywidualną zewnętrzną oraz dokumentację zbiorczą zewnętrzną. Mówi ono również o wymaganiach dotyczących prowadzenia dokumentacji w postaci elektronicznej (rozdział 8). System teleinformatyczny, w jakim prowadzona jest dokumentacja powinien zapewniać:
1) zabezpieczenie dokumentacji przez uszkodzeniem lub utratą,
2) zachowanie integralności i wiarygodności dokumentacji,
3) stały dostęp do dokumentacji dla osób uprawnionych oraz zabezpieczenie przed dostępem osób nieuprawnionych,
4) identyfikację osoby udzielającej świadczeń zdrowotnych i rejestrowanych przez nią zmian, w szczególności dla odpowiednich rodzajów dokumentacji przyporządkowanie cech informacyjnych, zgodna z §10 ust. 1 pkt 3 lit. a-d,
5) udostępnienie, w tym przed eksport w postaci elektronicznej dokumentacji albo części dokumentacji będącej formą dokumentacji określonej w rozporządzeniu, w formacie XML i PDF,
6) eksport całości danych w formacie XML, w sposób zapewniający możliwość odtworzenia tej dokumentacji w innym systemie teleinformatycznym,
7) wydrukowanie dokumentacji w formach określonych w rozporządzeniu.
Zgodnie z założeniami, jedną z funkcjonalności lokalnego repozytorium EDM powinno być udostępnianie na bieżąco dokumentacji uprawnionym podmiotom. Jak wynika z ustawy o prawach pacjenta i Rzeczniku Praw Pacjenta, podmiotami tymi są przede wszystkim podmioty udzielające świadczeń zdrowotnych (dokumentacja jest im udostępniana, o ile jest to niezbędne do zapewnienia ciągłości leczenia), a także organy władzy publicznej, Narodowy Fundusz Zdrowia, organy samorządu zawodów medycznych oraz konsultanci krajowi i wojewódzcy, w zakresie, w jakim jest to niezbędne do wykonywania przez nie swych zadań. Dopuszczalne jest również udostępnianie dokumentacji podmiotom, które na mocy art. 119 ust. 1 i 2 ustawy z dnia 15 kwietnia 2011 r. o działalności leczniczej przeprowadzają kontrolę na zlecenie ministra do spraw zdrowia (x.xx. wojewoda, konsultanci krajowi, jednostki organizacyjnie podległe lub nadzorowane przez ministra do spraw zdrowia). Pozostałe podmioty, którym jednostki lokalne mogą udostępniać dokumentację są wymienione enumeratywnie w art. 26 ustawy o prawach pacjenta i Rzeczniku Praw Pacjenta. Nie wszystkie jednak są uprawnione do dostępu do dokumentacji w tym samym stopniu – w większości przypadków ograniczone jest to do zakresu, jaki jest niezbędny do zrealizowania powierzonych im zadań. Wspomniane wyżej wymagania dla systemów teleinformatycznych, w których prowadzona jest dokumentacja elektroniczna (Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania) gwarantują możliwość udostępniania dokumentacji za pośrednictwem systemu. Dodatkowo Rozporządzenie określa, że takie udostępnianie uprawnionym podmiotom i organom ma nastąpić bez zbędnej zwłoki.
Ponadto ustawa z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych nakłada na świadczeniodawców działających w ramach umów z Narodowym Funduszem Zdrowia obowiązek gromadzenia i przekazywania do Funduszu danych dotyczących udzielanych świadczeń. Szczegółowo regulują to wydane na jej podstawie rozporządzenia: w sprawie zakresu niezbędnych informacji gromadzonych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeń ze środków publicznych (na podstawie art. 190 ust. 1) oraz w sprawie zakresu niezbędnych informacji gromadzonych w systemie informatycznym Narodowego Funduszu Zdrowia oraz zakresu i sposobu ich przekazywania ministrowi właściwemu do spraw zdrowia oraz wojewodom i sejmikom województw (na podstawie art. 190 ust. 3). Precyzują one, co ma znajdować się w rejestrach świadczeń zdrowotnych oraz podają zakres informacji przekazywanych ministrowi właściwemu do spraw zdrowia, Narodowemu Fuxxxxxxxx Xxxxxxx, innemu podmiotowi zobowiązanemu do finansowania świadczeń ze środków publicznych, a także wojewodom i sejmikom województw.
Na przełomie roku 2013 i 2014 CSIOZ wydało wytyczne w zakresie przetwarzania, gromadzenie i udostępniania EDM. W kontekście Projektu do najważniejszych z nich należą:
• Reguły tworzenia i model transportowy EDM
• Wytyczne dla systemu bezpiecznego przetwarzania EDM
Reguły tworzenia i model transportowy EDM opisują zasady tworzenia i przekazywania EDM do platformy P1. W szczególności wprowadzają profil XDS.b jako obowiązujący przy wymianie EDM, przy czym istotnemu rozszerzeniu ulegają elementy profilu XDS.b w zakresie obsługi zdarzeń medycznych. Istotność rozszerzenia polega na tym, że czysty profil XDS.b jest systemem wymiany dokumento- centrycznym, w którym podstawowym elementem wymiany pozostaje dokument. Polskie rozszerzenia
profilu XDS.b wprowadzone przez CSIOZ zmieniają ten model co do istoty na model zdarzenio- centryczny, w którym podstawową jednostką wymiany są dane o zdarzeniach. Wystąpienie zdarzenia może pociągać ze sobą powstanie i przesłanie dokumentu, ale nie musi.
Wytyczne dla systemu bezpiecznego przetwarzania EDM przedstawiają wytyczne i rekomendacje dla usługodawców w zakresie budowania i stosowania systemu bezpiecznego przetwarzania EDM. Ich wykorzystanie powinno mieć charakter wybiórczy, w zależności od wybranego wariantu realizacji systemu bezpieczeństwa.
Z wyżej przywołanych przepisów wywnioskować można, że repozytorium lokalne może komunikować się z indeksem regionalnym (tzw. rejestrem EDM), o ile spełnione będą warunki dotyczące bezpieczeństwa samego systemu teleinformatycznego oraz zasad i okoliczności udostępniania określonych danych.
Udostępnianie dokumentacji medycznej w postaci elektronicznej za pośrednictwem MSIM będzie wymagało uwiarygodnienia jej poprzez podpis elektroniczny. Będzie się to wiązało z opracowaniem odpowiednich procedur oraz wyposażeniem personelu medycznego w narzędzia umożliwiające realizację podpisu, jeżeli taki nie będzie już wdrożony.
Wdrożenie MSIM w szpitalach będzie wiązało się z koniecznością wprowadzenia procedur nadawania, modyfikacji i odbierania uprawnień personelowi medycznemu w zakresie danych udostępnianych w ramach MSIM.
System MSIM musi być zgodny z następującymi standardami, aktami prawnymi, normami oraz wytycznymi CSIOZ.
Standardy branżowe:
1. IHE Cross-Enterprise Document Sharing (XDS), w szczególności profil integracyjny, który standaryzuje rozdzielność 4 bytów ze względu na różną odpowiedzialność: repozytorium dokumentów, rejestr dokumentów, systemy źródłowe dokumentów, konsumentów dokumentów. W ramach zgodności z XDS przewiduje się zgodność z następującymi wytycznymi standardu XDS.b:
a. ITI-41 w zakresie dostarczania i rejestrowania dokumentów w repozytorium,
b. ITI-42 w zakresie rejestrowania dokumentów w rejestrze,
c. ITI-43 w zakresie pozyskiwania dokumentów z repozytorium,
d. ITI-18 w zakresie zapytań do rejestru,
e. ITI-8 oraz ITI-44 w zakresie identyfikacji pacjenta przez rejestr.
2. HL7 CDA R2 na 3-cim poziomie interoperacyjności, który standaryzuje strukturę dokumentów elektronicznych
Standardy funkcjonalne:
1. SOA, w tym zawieranie funkcjonalności związanych z integracją w postaci adapterów i wystawianych w postaci usług oraz stosowanie standardów:
a. WSDL w zakresie specyfikacji interfejsów,
b. XML w zakresie języka strukturalnego,
c. PSOAP w zakresie standardu przesyłania komunikatów,
d. Szyn usługowych w zakresie warstwy integracji.
2. WS-Security w zakresie projektowania i realizacji usług bezpieczeństwa, w tym:
a. SAML dla uwierzytelniania i autoryzacji użytkowników.
3. Metodyka PRINCE2 w zakresie zarządzania projektem.
Akty prawne:
• Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz.U. 2011 r. Nr 113 poz. 657, z późn. zm.).
• Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. 2013 nr 0 poz. 1114).
• Ustawa z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych (Dz.U. 2008 r. Nr 164 poz. 1027, z późn. zm.).
• Ustawa z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym (Dz.U. 2013 r. Nr 0 poz.757).
• Ustawa z dnia 15 kwietnia 2011 r. o działalności leczniczej (Dz.U. 2013 r. Nr 0, poz. 217).
• Ustawa z dnia 6 września 2001 r. prawo farmaceutyczne (Dz.U. 2008 r. Nr 45 poz. 271, z późn. zm.).
• Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. 2012
r. Nr 0 poz. 159).
• Ustawa z dnia 5 grudnia 1996 r. o zawodach lekarza i lekarza dentysty (Dz.U. 2011 r. Nr 277 poz. 1634).
• Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. 2014 r. Nr 0 poz. 1114).
• Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U. 2014 r. Nr 0 poz. 1182).
• Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. 2010 r. Nr 182 poz. 1228).
• Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. 2013 r. Nr 0 poz. 262).
• Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U. 2011 r. Nr 206 poz. 1216, z późn. zm.).
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2012 r. Nr 0 poz. 526).
• Rozporządzenie Ministra Zdrowia z dnia 25 marca 2013 r. w sprawie klasyfikacji danych i systemu kodów w Systemie Informacji Medycznej (Dz.U. 2013 r. Nr 0 poz. 473).
• Rozporządzenie Ministra Zdrowia z dnia 28 marca 2013 r. w sprawie wymagań dla Systemu Informacji Medycznej (Dz.U. 2013 r. Nr 0 poz. 463).
• Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U. 2014 r. Nr 0 poz. 177 z późn. zm.).
• Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. 2004 r. Nr 100 poz. 1024).
• Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U. 2006 r. Nr 206 poz. 1518).
• Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 6 maja 2014 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz.U. 2014 Nr 0 poz. 584).
• Rozporządzenie Ministra Spraw Wewnętrznych i administracji z dnia 18 maja 2011 r. w sprawie rodzaju i zakresu oraz sposobu przetwarzania dokumentacji medycznej w zakładach opieki zdrowotnej utworzonych przez ministra właściwego do spraw wewnętrznych (Dz.U. 2011 r. Nr 125, poz. 712).
• Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 5 czerwca 2014 r. w sprawie zasad potwierdzania, przedłużania ważności, unieważniania oraz wykorzystania profilu zaufanego elektronicznej platformy usług administracji publicznej (Dz. U. 2014 nr 0 poz. 778).
• Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 18 maja 2011 r. w sprawie rodzaju i zakresu oraz sposobu przetwarzania dokumentacji medycznej w zakładach opieki zdrowotnej utworzonych przez ministra właściwego do spraw wewnętrznych (Dz.U. 2011 r. Nr 125 poz. 712).
• Dyrektywa 95/46/We Parlamentu Europejskiego i Rady z 24 października 1995 r. w sprawie ochrony osób fizycznych w zakresie przetwarzania danych osobowych i swobodnego przepływu tych danych do spraw wewnętrznych.
Normy:
• Norma PN-EN 13606-4:2009 Informatyka w ochronie zdrowia - Przesyłanie elektronicznej dokumentacji zdrowotnej - Część 4: Bezpieczeństwo danych.
• Norma PN-EN ISO 13606-5:2010 - Informatyka w ochronie zdrowia -- Przesyłanie elektronicznej dokumentacji zdrowotnej -- Część 5: Specyfikacja interfejsu.
• Norma PN-ISO/IEC 27005:2014-01 Technika informatyczna - Techniki bezpieczeństwa - Zarządzanie ryzykiem w bezpieczeństwie informacji.
• Norma ISO/IEC 27033 Information technology - Security techniques - Network security,
• PN-ISO/IEC 27001 Technika informatyczna - Techniki bezpieczeństwa - Systemy zarządzania bezpieczeństwem informacji – Wymagania.
• PN-ISO/IEC 17799 Technika informatyczna - Techniki bezpieczeństwa - Praktyczne zasady zarządzania bezpieczeństwem informacji wraz z PN-ISO/IEC 17799:2007/Ap1:2010 – normy te są dokładnym przekładem treści z norm ISO/IEC 27002.
• Norma PN-I-13335-1:1999 Technika informatyczna - Wytyczne do zarządzania bezpieczeństwem systemów informatycznych - Pojęcia i modele bezpieczeństwa systemów informatycznych.
• Norma PN-I-13335-2:2003 Technika informatyczna – Planowanie i zarządzanie bezpieczeństwem systemów informatycznych.
• Norma PN-ISO/IEC 24762:2010 Technika informatyczna – Techniki bezpieczeństwa. Wytyczne dla usług odtwarzania techniki teleinformatycznej po katastrofie.
• Norma PN-EN ISO 10781: 2011 - Model funkcjonalny systemu elektronicznej dokumentacji zdrowotnej, wersja 1.1.
• Norma PN-EN ISO 21549-3:2014-05 Informatyka medyczna - Dane karty zdrowia pacjenta – Część 3: Ograniczony zestaw danych klinicznych,
• Norma ISO 18308:2011 – Informatyka w ochronie zdrowia - Wymagania dla architektury elektronicznej dokumentacji medycznej.
Wytyczne CSIOZ w zakresie integracji z P1 oraz w zakresie EDM, w szczególności aktualne wersje następujących dokumentów:
• Reguły tworzenia i model transportowy EDM
• Wytyczne dla systemu bezpiecznego przetwarzania EDM
6.4. Wymagania wydajnościowe systemu
1. Czas dostępu do informacji o EDM gromadzonych w warstwie regionalnej liczony jako czas od wysłania zapytania do dostarczenia odpowiedzi z rejestru EDM nie może być dłuższy niż 3 sekundy.
2. Czas dostępu do EDM gromadzonej w warstwie lokalnej w trybie synchronicznym liczony jako czas od wysłania zapytania do otrzymania EDM nie może być dłuższy niż 10 sekund. Po przekroczeniu tego czasu System musi przechodzić w tryb pobierania asynchronicznego.
3. Dostarczana infrastruktura musi pozwalać na sprzętowe i programowe tworzenie klastrów wydajnościowych oraz niezawodnościowych.
6.5. Wymagania skalowalności
1. Klaster serwerów aplikacji musi mieć możliwość budowy z wielu instancji serwerów aplikacji działających równocześnie w taki sposób, aby zapewnić dwa podstawowe mechanizmy: skalowalność oraz niezawodność. Serwery aplikacji tworzących klaster muszą mieć możliwość pracy w ramach tej samej fizycznej maszyny bądź na różnych fizycznych maszynach w ramach infrastruktury lokalnej. „Pojemność” klastra można zwiększyć poprzez dodanie nowych instancji do klastra, instancje te mogą być uruchomione na tej samej fizycznej maszynie, bądź na innych fizycznych maszynach.
2. Komplet dla infrastruktury sprzętowej oznacza 1 szt. urządzenia wraz z niezbędnym okablowaniem umożliwiającym ich podłączenie. W przypadku oprogramowania komplet oznacza taką ilość oprogramowania, która będzie pokrywać cały sprzęt przewidziany do dostarczenia w danym szpitalu dla jednej serwerowni.
6.6. Wymagania wolumenu przetwarzanych danych
1. Warstwa regionalna musi umożliwiać zainstalowanie i funkcjonowanie komponentu regionalnego Systemu MSIM
2. Warstwa lokalna musi umożliwiać zainstalowanie i funkcjonowania komponentu lokalnego Systemu MSIM
3. System musi umożliwiać gromadzenie EDM w lokalnych repozytorium danych będących częścią komponentu lokalnego
4. System musi umożliwiać gromadzenie metadanych EDM w regionalnym rejestrze danych będącego częścią komponentu regionalnego
5. Komponent regionalny musi gromadzić dane w trybie produkcyjnym, w trybie backupu i archiwizacji.
6.7. Wymagania niezawodności
1. System musi umożliwiać odtworzenie danych na podstawie kopii zapasowej, w szczególności musi umożliwiać:
a. wykonywanie kopii zapasowych danych w trakcie pracy systemu,
b. szybkie odtworzenie danych.
2. Łączny czas niedostępności systemu nie może przekroczyć 2 dni w ciągu roku
3. Maksymalny czas odtwarzania po awarii nie powinien przekraczać 5 godzin (w dni robocze) lub 1 dnia (w dni świąteczne).
4. System musi pracować w trybie 24/7/365 bez zdefiniowanych przerw w pracy, bez względu na czynności związane z utrzymaniem systemu (nie dotyczy instalacji nowych wersji oprogramowania) z niezawodnością 99,5 %.
5. Po wystąpieniu, a następnie ustąpieniu awarii sieci lub usługi zewnętrznej system musi samodzielnie, automatycznie, bez ingerencji operatora wznowić pracę.
6. W przypadku wystąpienia większego obciążenia niż określono w wymaganiach wydajnościowych, przestają one obowiązywać, jednakże system powinien zachować przewidzianą wymaganiami funkcjonalność.
7. System ma mieć możliwość tworzenia zapasowych kopii baz danych. Kopie zapasowe muszą pozwalać na przywrócenie stanu baz danych z maksymalną stratą danych z 1 godziny.
6.8. Wymagania bezpieczeństwa
1. System MSIM może być dostępny tylko dla uwierzytelnionych użytkowników, za wyjątkiem użytkowników anonimowych portalu infomacyjnego.
2. System musi umożliwiać uwierzytelnianie i autoryzację użytkowników na podstawie informacji przechowywanej w Active Directory. Wdrożenie tego typu uwierzytelnienia dotyczy wyłącznie Szpitali, w których obecnie jest wdrożone Active Directory.
3. System musi umożliwiać uwierzytelnianie użytkowników za pomocą unikatowego identyfikatora użytkownika i niejawnego hasła.
4. System musi umożliwiać przypominanie haseł użytkownikom poprzez wysłanie przypomnienia na wskazany adres email użytkownika.
5. System musi umożliwiać dostęp do logów zdarzeń systemowych z poziomu interfejsu administracyjnego ich segregowanie wg. parametrów tj. x.xx.: daty, definiowanego przedziału czasowego, użytkownika, identyfikatora, czynności, innych oraz zapewniać możliwość ich eksportu.
6. System musi umożliwiać dostęp do logów zdarzeń tylko administratorowi. Musi być zapewniona wiarygodność i bezpieczeństwo logów.
7. System musi umożliwiać odnotowanie daty wykonania każdej operacji oraz identyfikatora użytkownika wykonującego operację.
8. System musi posiadać mechanizmy uniemożliwiające edycję i usuwanie plików zawierających logi zdarzeń systemowych oraz chroniące przed możliwością ich przepełnienia.
9. System musi zapewniać synchronizację zegara systemowego ze źródłami czasu za pomocą protokołu NTP lub mechanizmów Active Directory w celu utrzymania wiarygodności logów systemowych.
10. System musi umożliwiać korzystanie z protokołu SSL dla zabezpieczenia przesyłanych informacji lub w inny sposób zapewniać szyfrowanie przesyłania danych.
11. System musi umożliwiać zdefiniowanie reguł określających wymaganą siłę stosowanych haseł dla różnych grup użytkowników w szczególności:
a. minimalnej i maksymalnej dopuszczalnej długości hasła,
b. stosowania znaków alfanumerycznych i specjalnych,
c. maksymalnej długość okresu ważności hasła,
d. liczby haseł zapamiętywanych w historii haseł (blokowanie możliwości ich ponownego użycia).
12. System musi umożliwiać automatyczne zamykanie sesji dostępu użytkownika po upływie definiowanego w konfiguracji systemu czasu od momentu przerwania pracy z systemem (np. zamknięcia przeglądarki).
13. System musi zapewniać monitorowanie prób naruszenia bezpieczeństwa systemu, w tym prób nieuprawnionego dostępu do Systemu (tj. próby nieudane, ostrzeżenia systemowe i błędy).
14. System musi zapewniać monitorowanie operacji uprzywilejowanych, tj. wykorzystanie uprawnień administratora, uruchamianie aplikacji i ich zamykanie.
15. System musi wykonywać kopie zapasowe systemu zgodnie z ustalonym harmonogramem.
16. System ma zapewniać poufność wymienianych danych.
17. System ma zapewniać rozliczalność wymienianych danych. Rozliczalność rozumiana jest jako zachowanie wszelkich informacji nt. jakie dane kiedy i komu były udostępniane.
18. System musi zapewniać integralność wymienianych danych. System ma zapewniać aby dane nie zostały zmienione w trakcie przesyłania pomiędzy jednostkami.
19. Wymieniane dane muszą być zaszyfrowane w sposób umożliwiający ich odczytanie tylko przez adresata (jednostkę do której są skierowane).
20. System ma zapewniać uwierzytelnienie komunikujących się jednostek.
21. Wymieniane dane osobowe mają być zaszyfrowane w sposób umożliwiający ich odczytanie tylko w jednostce, dla której są przeznaczone.
22. Oprogramowanie budowane w ramach projektu musi być zabezpieczone przed automatycznym nieautoryzowanym logowaniem np. przez inne aplikacje.
23. Oprogramowanie budowane w ramach projektu musi posiadać odporność OWASP10.
24. Zarządzanie dostępem do Oprogramowania musi być zgodne 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.
25. Wykonawca musi przygotować w uzgodnieniu z Partnerami Projektu procedurę rejestracji użytkownika w Systemie MSIM oraz przygotować formularz rejestracji.
6.9. Ochrona danych osobowych
1. Dla Systemu należy opracować dokumentację Ochrony Danych Osobowych składającą się z Polityki Bezpieczeństwa Danych Osobowych oraz Instrukcji Zarządzania Systemem Służącym do Przetwarzania Danych Osobowych.
2. Polityka Bezpieczeństwa Danych Osobowych (zwana dalej PBDO) w MSIM musi być opracowywana i wdrażana zgodnie z:
• Obowiązującymi przepisami prawnymi:
o Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. 1997 nr 133 poz. 883).,
o Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 roku w sprawach dokumentacji przetwarzanych danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. 2004 nr 100 poz. 1024).
• Regulacjami wewnętrznymi MSIM,
• Wymaganiami i wytycznymi bezpieczeństwa informacji:
o PN-ISO/IEC 27001:2013 Technika informatyczna. Techniki bezpieczeństwa. Systemy zarządzania bezpieczeństwem informacji. Wymagania,
o PN-ISO/IEC 17799:2007 Technika informatyczna. Techniki bezpieczeństwa. Praktyczne zasady zarządzania bezpieczeństwem informacji.
3. Polityka Bezpieczeństwa Danych Osobowych - swoim zakresem dokument obejmie min.:
• Cel i zakres polityki bezpieczeństwa,
• Organizacja bezpieczeństwa informacji,
• Struktura ról i obowiązków w zakresie ochrony danych osobowych,
• Wykaz zbiorów danych osobowych i pomieszczeń, w których są przetwarzane Dane Osobowe,
• Sposób przepływu danych,
• Opis struktury zbiorów danych,
• Zabezpieczenia organizacyjne,
• Zabezpieczenia techniczne,
• Monitorowanie zabezpieczeń,
• Wzory oświadczeń.
4. Instrukcja Zarządzania Systemem Informatycznym - swoim zakresem dokument obejmie min.:
• Charakterystyka systemów informatycznych przetwarzających dane osobowe,
• Procedury nadawania uprawnień do przetwarzania danych i rejestrowania tych uprawnień w systemie informatycznym oraz wskazanie osób odpowiedzialnych za te czynności,
• Metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem,
• Procedury rozpoczęcia, zawieszenia i zakończenia pracy przeznaczone dla użytkowników systemu,
• Procedury tworzenia kopii zapasowych zbiorów danych oraz programów i narzędzi programowych służących do ich przetwarzania,
• Sposób, miejsce i okres przechowywania nośników informacji,
• Sposób zabezpieczenia systemu informatycznego przed działalnością oprogramowania, którego celem jest uzyskanie nieuprawnionego dostępu do systemu informatycznego,
• Procedury wykonywania przeglądów i konserwacji systemów oraz nośników informacji służących do przetwarzania danych,
• Procedury postępowania z urządzeniami, dyskami lub innymi informatycznymi nośnikami zawierającymi dane osobowe, przeznaczonymi do likwidacji, przekazania innemu podmiotowi i naprawy,
• Procedury postępowania w sytuacji naruszenia ochrony danych osobowych.
• Wzory oświadczeń, protokołów innych dokumentów w kontekście powyższych zapisów.
6.10. Wymagania systemu zarządzania tożsamością
System zarządzania tożsamością musi posiadać funkcjonalności nie mniejsze niż:
1. Konfiguracja i zarządzanie polityką bezpieczeństwa,
2. Gromadzenie w jednym miejscu pełnych informacji o użytkowniku, takich jak: miejsce w hierarchii służbowej, dane kontaktowe, uprawnia dostępu (do urządzeń sieciowych, komputerów, systemów informatycznych, pomieszczeń), data przyznania, odebrania uprawnień oraz data ich ważności, informacja o uprawnieniach zawodowych, wydane certyfikaty, e-podpisy, rola w sytuacji awaryjnej,
3. Możliwość uzyskania informacji o przydzielonych aktywach do użytkownikach, takich jak: komputer, samochód, telefon, licencje i ich okresie ważności,
4. Identyfikacja płynących ryzyk biznesowych wynikających z nadania danych uprawnień,
5. Informacja o przypisanej grupie użytkowników i udzielonych prawach dostępu,
6. Możliwość uzyskania informacji o nadaniu wyższych praw dostępu użytkownikowi, z jakiej przyczyny, na jaki czas,
7. Zaprojektowanie i zarządzanie workflow: wnioskowania, akceptowania i nadawania uprawnie minimum przy wykorzystaniu 2 poziomowej akceptacji,
8. Rozdzielenie grup i ról dostępu do systemu,
9. Zarządzanie dostępem użytkowników od zasobów informatycznych i ich danych poziomów administracyjnych,
10. Możliwość łatwego blokowania i odbieranie praw dostępu do systemu,
11. Łatwość przeprowadzania przeglądu praw dostępu na indywidualnych i grupowych pracowników,
12. Integracja z formalnymi procedurami nadawania i odbierania praw dostępu do systemów,
13. Alarmowanie o próbie nieautoryzowanego logowania do danego systemu,
14. Alarmowanie o zalogowaniu się pracownika który jest obecnie na urlopie,
15. Możliwość łatwej i szybkiej weryfikacji przyznanych praw dostępu,
16. Nadawanie dodatkowych praw dostępu z możliwością ograniczania i kontrolowania,
17. System nadawania haseł powinien być kontrolowany i wymuszany do natychmiastowej zmiany bezpiecznego hasła po pierwszym logowaniu użytkownika,
18. Dostarczanie nowych, zastępczych haseł po uprzedniej weryfikacji pracownika w sytuacji kiedy zapomni swojego hasła,
19. Hasło powinno być wymuszane do zmiany co 30 dni (konstrukcja hasła: 8 znaków, trój rodzajowo-znakowe),
20. Przeglądanie i ponowne nadawanie praw dostępu użytkownikom zmieniającym stanowisko pracy,
21. Dodatkowe uwierzytelnianie się przy połączeniach zewnętrznych np. stosując technikę kryptograficzna, tokeny sprzętowe lub protokoły „wezwanie-odpowiedź”,
22. Ograniczanie trwania połączenia zewnętrznego (zamykanie sesji po pewnym czasie),
23. Archiwizowanie wszystkich zmian zachodzących w danym profilu tożsamości użytkownika (pełna historia użytkownika),
24. Tworzenie i monitorowanie kopii zapasowych informacji i konfiguracji przechowywanych w systemie kontroli dostępu.
6.11. Procedury nadawania/zmiany/odbierania uprawnień
Dla systemu MSIM zostaną opracowane następujące procedury w ramach procesu kontroli dostępu do zasobów:
1. Polityka kontroli dostępu,
2. Procedura nadawania uprawnień do systemu,
3. Procedura zmiany uprawnień do systemu,
4. Procedura odbierania uprawnień do systemu,
5. Procedura przeglądu uprawnień użytkowników,
6. Procedura nadawania zdalnego dostępu (obejmująca użytkowników oraz dostawców usług).
System MSIM zakłada następujące grupy użytkowników:
• Użytkownicy uprawnieni do korzystania z usługi wyszukiwania EDM,
• Użytkownicy uprawnieni do korzystania z usługi pobierania EDM,
• Użytkownicy uprawnieni do korzystania z usługi e-Rejestracja,
• Administratorzy systemu,
• Administratorzy usług,
• Administratorzy baz danych,
• Administratorzy sieci,
• Administratorzy infrastruktury sprzętowej.
6.12. Repozytorium EDM
1. Repozytorium EDM odpowiada za przyjmowanie, gromadzenie, przetwarzanie dowolnej EDM zgodnej ze standardem HL7CD na poziomie 3-cim.
2. Repozytorium EDM musi wystawiać i obsługiwać interfejs przekazywania i rejestracji EDM zgodnie z wytycznymi ITI-41 profilu integracyjnego XDS.b.
3. Repozytorium EDM musi obsługiwać interfejs pozwalający na pobranie EDM uwierzytelnionemu użytkownikowi zgodnie z wytycznymi ITI- 43
4. 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”)
5. Repozytorium integruje się z mechanizmami nadawania w sposób atomowy uprawnień do obiektów przetrzymywanych w repozytorium. Dla każdego obiektu możliwe jest zdefiniowanie przynajmniej następujących uprawnień: wyświetlenie metadanych i udostępnienie dokumentu
6. Repozytorium przechowuje informację o zgodach pacjenta na udostępnianie dokumentów w ramach jednostki, oraz na udostępnianie dokumentu poza jednostkę
7. Repozytorium integruje się z zewnętrznym dostawcą znaczników czasu oraz z zewnętrznym Centrum Autoryzacji (CAPE w Małopolsce), co pozwala na automatyczne znakowanie dokumentów. Wykonawca wykonuje integrację z CAPE w Małopolsce w zakresie znakowania czasem oraz wykorzystania podpisu.
8. Repozytorium implementuje mechanizm wersjonowania dokumentów.
9. Repozytorium przechowuje rejestr obiektów złożonych w repozytorium wraz z zestawem metadanych opisujących każdy z dokumentów.
10. Repozytorium oblicza identyfikator hash jednoznacznie związanego z zawartością dokumentu.
11. Repozytorium udostępnia interface podpisywania dokumentów podpisem elektronicznym.
12. W ramach przechowywania identyfikatorów repozytorium posługuje się standardem OID.
13. Repozytorium odrzuca próbę rejestracji dokumentu o tym samym identyfikatorze
14. Repozytorium każdej jednostki jest definiowane oddzielnie, wraz z własnym unikalnym identyfikatorem repozytorium. Repozytorium skonstruowane jest w taki sposób, że współpracuje z wielu różnymi repozytoriami w ramach jednej domeny
15. Repozytorium modyfikuje metadane dokumentu dodając tylko i wyłącznie: id repozytorium, skrót dokumentu (hash), wielkość dokumentu.
16. Repozytorium jest neutralne pod względem zawartości, ale jest w stanie dodatkowo wydobywać informacje z plików w formatach HL7 CDA R2 na 3-cim poziomie interoperacyjnościinteroperacyjności, DICOM.
17. Repozytorium przechowuje informacje o tym na jakim medium przechowywany jest dokument.
18. Repozytorium pozwala na zniszczenie dokumentów po upływie okresu retencji.
19. Repozytorium wyposażone jest w interface web services pozwalający na pobranie dowolnego dokumentu o znanym identyfikatorze.
20. Repozytorium obsługuje standard WS-Trust umożliwiający delegację uprawnień użytkowników zewnętrznych poprzez zaufanego brokera bezpieczeństwa oraz współpracę z systemem STS.
21. Repozytorium przechowuje tokeny SAML związane z udostępnieniem dokumentu użytkownikowi poprzez okres retencji dokumentu.
22. Rejestr jest wyposażony jest w interface webservices pozwalający na przeszukiwanie dokumentów dla użytkowników wewnętrznych zgodnie z posiadanymi przez użytkownika uprawnieniami.
23. Repozytorium przechowuje wszystkie żądania udostępnienia dokumentu, wraz z informacją czy żądanie pojawiło się od użytkownika wewnętrznego, zewnętrznego i czy skończyło się udostępnieniem dokumentu czy też odmową udostępnienia.
24. Repozytorium posiada interfejsy umożliwiające eksport pojedynczych dokumentów bądź całych zbiorów dokumentów. Eksportowane obiekty mogą być dodatkowo opatrzone podpisem elektronicznym zapewniającym integralność eksportowanych danych
25. Repozytorium pozwala na przesyłanie oraz udostępnianie dokumentów oraz innych obiektów za pomocą webservice. Interface webservice pozwala na dodawanie dowolnych metadanych.
26. .Repozytorium zintegrowane jest z zewnętrznymi systemami zarządzania użytkownikami (LDAP).
27. Repozytorium integruje się z domeną identyfikacji pacjenta (pojedynczym źródłem tożsamości pacjenta).
28. W ramach integracji webservices repozytorium obsługuje standard WS-Security.
29. Repozytorium może być zintegrowane z systemami wykonującymi transformację dokumentów (transkrypcję tekstu, wykonywanie skrótów i rekompresji dokumentów)
30. Treść dokumentów przechowywanych Repozytorium jest w postaci zaszyfrowanej.
31. Każdy z obiektów, w zależności od typu, może być opisywany za pomocą zbioru metadanych. Każda z metadanych może być definiowana jako wymagana, lub opcjonalna. Definicje wymaganych/opcjonalnych metadanych uzależnione są od typu obiektu/dokumentu.
32. Dla każdego obiektu repozytorium obsługuje co najmniej następujący zestaw metadanych: identyfikator pacjenta, imię i nazwisko pacjenta, płeć pacjenta, początek i koniec zdarzenia medycznego, data utworzenia dokumentu, nazwa i rodzaj dokumentu, rodzaj i nazwa jednostki medycznej, unikalny identyfikator dokumentu, grupa bezpieczeństwa.
33. Dokumenty umieszczone w repozytorium nie mogą być modyfikowane oraz usuwane przed upływem okresu retencji. Repozytorium umożliwia natomiast wykonywanie adnotacji do dokumentów oraz zamianę dokumentów. Repozytorium przechowuje zarówno dokument oryginalny, adnotację oraz ewentualny dokument zamieniający (replacement document). Repozytorium przechowuje relacje pomiędzy dokumentami oryginalnym, zamieniającym oraz adnotacją.
34. Repozytorium posiada wbudowane mechanizmy pozwalające na pełno tekstowe przeszukiwanie zarówno meta-danych, jak i merytorycznej zawartości przechowywanego dokumentu.
35. Repozytorium posiada wbudowane mechanizmy pozwalające na zbieranie danych z obszaru wydajności działania oprogramowania (performance monitoring).
36. Repozytorium posiada natywne wsparcie do wdrożeń w środowiskach klastrowych.
6.13. Usługa e-Rejestracja
Wymagania minimalne dla usługi e-Rejestracji
Nr funkcjonalności | Funkcjonalność |
e-R.1 | Wymagania ogólne |
e-R.1.1 | Informacje podstawowe funkcjonowania e-Rejestracji |
e-R.1.1.1 | e-Rejestracja zostanie zainicjowana z portalu e e-Zdrowie. |
e-R.1.1.2 | Możliwość przejścia do e-Rejestracji z wyników wyszukiwania poprzez jedno kliknięcie. Zostanie otworzona formatka „Wymagane dane rejestracji”. |
e-R.1.1.3 | E-Rejestracja wysyła komunikaty dla Pacjenta e-mail lub SMS dotyczące Rejestracji. |
e-R.1.1.4 | Komunikaty systemowe obsługują wszystkie kanały komunikacji (WWW, e-mail, SMS) rejestracji dla użytkowników posiadających konto Użytkownika Końcowego. |
e-R.1.1.5 | Musi być synchronizacja on-line Rejestracji wizyty dla danej usługi medycznej pomiędzy usługą e-Rejestracja a zintegrowanym lokalnym systemem dziedzinowym HIS. |
e-R.1.1.6 | Musi być synchronizacja on-line zmiany terminu wizyty dla danej usługi medycznej pomiędzy usługą e-Rejestracja a zintegrowanym lokalnym systemem dziedzinowym HIS. |
e-R.1.1.7 | Musi być synchronizacja on-line Anulowania wizyty dla danej usługi medycznej pomiędzy usługą e-Rejestracja a zintegrowanym lokalnym systemem dziedzinowym HIS. |
e-R.2 | Rejestracja |
e-R.2.1 | Rejestracja wizyty Formatka Rejestracji wywoływana jest po wyborze przez pacjenta (Użytkownik końcowy) danej usługi w danej jednostce służby zdrowia |
e-R.2.1.2 | Zawartość formatki „Wymagane dane rejestracji” może być różna dla danej jednostki ochrony zdrowia oraz typu usługi medycznej, w zakresie danych do uzupełnienia w postaci pól formatek. |
e-R.2.2 | Wymagane dane rejestracji: |
e-R.2.2.1 | Dane Użytkownika końcowego są automatycznie podpowiadane w polach formatki zgodnie z danymi na koncie Użytkownika końcowego oraz planowanym miejscem wykonania usługi i jej rodzajem zgodnie z dokonanym wyborem. |
e-R.2.2.2 | Użytkownik wypełnia pozostałe dane niezbędne do rejestracji na formatce. |
e-R.2.2.3 | Należy podać wymagany zakres danych niezbędny do zapisu rejestracji (dane wymagane i nie wymagane) |
e-R.2.2.4 | Należy podać dane dotyczące skierowania w czasie rejestracji w przypadku wymagalności danych dotyczących skierowania dla realizacji danej usługi |
e-R.2.2.5 | Dane muszą być podpowiadane do wyboru w postaci pola do uzupełnienia, listy rozwijanej z zaznaczeniem wszystkich, jednej lub kilku opcji wyboru (opcja w zależności od rodzaju listy rozwijanej) |
e-R.2.3 | Wysłanie lub anulowanie rezerwacji wizyty (Użytkownik końcowy potwierdza wysłanie rezerwacji lub ją anuluje) |
e-R.2.3.1 | W przypadku anulowania zamknięcie okna rejestracji |
e-R.2.3.2 | W przypadku wysłania, informacja graficzna w oknie rejestracji o przetwarzaniu informacji o rezerwacji, z prośbą o oczekiwanie |
e-R.2.4 | Brak potwierdzenia Rezerwacji on-line |
e-R.2.4.1 | W przypadku niemożliwości zakończenia we wskazanym czasie przetwarzania informacji o rezerwacji i braku informacji zwrotnej z potwierdzeniem lub odrzuceniem rejestracji: |
e-R.2.5 | Zamknięcie okna z informacją graficzną w oknie rejestracji o przetwarzaniu |
e-R.2.5.1 | System zapisuje rezerwacje w historii danych konta użytkownika końcowego z określonym statusem. |
e-R.2.5.2 | Rezerwacja wysyłana jest do skutku, celem potwierdzenia lub odrzucenia rejestracji |
e-R.2.6 | Walidacja danych Rezerwacji |
e-R.2.6.1 | Walidacja kompletności wypełnienia danych wymaganych na formatce „Wymagane dane rejestracji” przed wysyłaniem danych do lokalnego Systemu medycznego (HIS) danej jednostki ochrony zdrowia, a w przypadku braku wypełnienia informacja zwrotna z zaznaczeniem danych nie wypełnionych. |
e-R.2.6.2 | Walidacja kolizji rezerwacji w komponencie regionalnym. |
e-R.2.6.3 | Wykrywanie i blokowanie wielokrotnych e-Rezerwacji tej samej usługi jednego dnia., |
e-R.2.6.4 | Wykrywanie i blokowanie wielokrotnej e-Rezerwacji różnych usług jednego dnia na tę samą godzinę. |
e-R.2.6.5 | Komunikat zwrotny o wykryciu kolizji rezerwacji. |
e-R.2.7 | Potwierdzenie lub odrzucenie Rejestracji wizyty Po dokonaniu Rejestracji do Systemu medycznego (HIS) w jednostce ochrony zdrowia, gdzie będzie realizowana usługa, Użytkownik końcowy dostaje informacje zwrotną na ekran: |
e-R.2.7.1 | Potwierdzającą przyjęcie Rejestracji wizyty. |
e-R.2.7.2 | Podać treść informacji zwrotnej zawierającej co najmniej: a) Informacja potwierdzająca przyjęcie Rejestracji, b) Unikalny numer rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja, c) Imię i nazwisko Użytkownika końcowego, d) Numer ID Użytkownika końcowego, e) PESEL, f) Rodzaj usługi, g) Miejsce wykonania usługi, h) Planowana data wykonana usługi, i) Informacje dodatkowe. |
e-R.2.7.3 | Odrzucenie przyjęcia Rezerwacji wizyty Podać treść informacji zwrotnej zawierającej co najmniej: a) Informację zwrotną odrzucającą przyjęcie Rezerwacji, b) Informację o przyczynie odrzucenia, Informacja generowana automatycznie co do treści wg rodzaju odrzucenia, np. zajęty termin c) Informacje dodatkowe |
e-R.2.7.4 | Możliwość wydruku potwierdzenia Rezerwacji wizyty |
e-R.2.7.5 | Zapisanie Rejestracji w historii moich danych na koncie Użytkowania końcowego |
e-R.2.8 | Anulowanie Rejestracji |
e-R.2.8.1 | Wybór opcji Anulowania wskazanej Rejestracji powoduje wyświetlenie informacji potwierdzającej fakt anulowania otwartej Rejestracji. |
e-R.2.9 | Użytkownik końcowy potwierdza wysłanie Anulowania Rejestracji lub ją anuluje. a) W przypadku anulowania zamknięcie okna informacyjnego. |
e-R.2.9.1 | W przypadku potwierdzenia Anulowania Rejestracji wyświetlenie kolejnej informacji potwierdzającej fakt Anulowania otwartej Rejestracji a) W przypadku anulowania zamknięcie okna informacyjnego. b) W przypadku potwierdzenia, następuje wysłanie zgody na Anulowanie i |
następuje zamknięcie okna informacyjnego | |
e-R.2.9.2 | Następuje zapisanie zmiany statusu w historii moich danych na koncie użytkownika końcowego, w wyniku Anulowania Rejestracji w lokalnym systemie medycznym HIS. |
e-R.2.9.3 | Anulowanie Rejestracji wysyłane jest do skutku, celem potwierdzenia Anulowania. |
e-R.2.10 | Komunikat systemowy potwierdzający Rejestrację |
e-R.2.10.1 | Potwierdzenie Rejestracji wysyłane jest na wskazany przez Użytkownika końcowego adres e-mail o treści jak wyświetlonej na ekranie w wyniku potwierdzenia przyjęcia Rejestracji wizyty. |
e-R.2.11 | Tytuł wiadomości e-mail jest generowany automatycznie i zawiera część: stałą (co najmniej): |
e-R.2.11.0.1 | podać treść |
e-R.2.11.0.2 | ID Użytkownika końcowego |
e-R.2.11.1 | zmienną (co najmniej): |
e-R.2.11.1.1 | Unikalny NR Rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja |
e-R.2.11.1.2 | Planowany termin wizyty |
e-R.2.11.1.3 | Wiadomość e-mail jest sformatowana w treści gotowej do wydruku |
e-R.2.12 | System musi być gotowy do realizacji funkcjonalności: Potwierdzenie Rejestracji wysyłanego w postaci SMS na wskazany przez Użytkownika końcowego nr telefonu o wskazanej treści. |
e-R.2.12.1 | Wiadomości SMS jest generowana automatycznie i zawiera część: |
e-R.2.12.1.1 | stałą (co najmniej): |
e-R.2.12.1.1.1 | podać treść |
e-R.2.12.1.1.2 | ID Użytkownika końcowego |
e-R.2.12.1.2 | zmienną (co najmniej): |
e-R.2.12.1.2.1 | Unikalny NR Rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja |
e-R.2.12.1.2.2 | Planowany termin wizyty |
e-R.2.13 | Komunikaty systemowe potwierdzające akcje obsługi Rejestracji |
e-R.2.13.1 | W wyniku zbliżającego się terminu wizyty lokalny System medyczny (HIS) przekazuje zawartość dla wiadomości SMS i/lub e-mail z powiadomieniem o zdarzeniu |
e-R.2.13.2 | Wiadomości SMS jest generowana automatycznie i zawiera część: |
e-R.2.13.3 | stałą (co najmniej): |
e-R.2.13.3.1 | podać treść |
e-R.2.13.3.2 | ID Użytkownika końcowego |
e-R.2.13.4 | zmienną (co najmniej): |
e-R.2.13.4.1 | Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja |
e-R.2.13.4.2 | Planowany termin wizyty |
e-R.2.13.5 | Wiadomości e-mail jest generowana automatycznie i zawiera część: |
e-R.2.13.6 | stałą (co najmniej): |
e-R.2.13.6.1 | podać treść |
e-R.2.13.6.2 | ID Użytkownika końcowego |
e-R.2.13.7 | zmienną (co najmniej): |
e-R.2.13.7.1 | Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja |
e-R.2.13.7.2 | Planowany termin wizyty |
e-R.2.13.7.3 | Wiadomość e-mail jest sformatowana w treści gotowej do wydruku |
e-R.2.14 | W wyniku Anulowania wizyty w lokalnym Systemie medycznym HIS, przekazuje on wiadomość SMS i/lub e-mail z powiadomieniem o określonej treści: |
e-R.2.15 | Wiadomość SMS jest generowana automatycznie i zawiera część: |
e-R.2.16 | stałą (co najmniej): |
e-R.2.16.0.1 | podać treść |
e-R.2.16.0.2 | ID Użytkownika końcowego |
e-R.2.16.1 | zmienną (co najmniej): |
e-R.2.16.1.1 | Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja |
e-R.2.16.1.2 | Planowany termin wizyty |
e-R.2.17 | Wiadomość e-mail jest generowana automatycznie i zawiera część: |
e-R.2.17.1 | stałą (co najmniej): |
e-R.2.17.1.1 | podać treść |
e-R.2.17.1.2 | ID Użytkownika końcowego |
e-R.2.17.2 | zmienną (co najmniej): |
e-R.2.17.2.1 | Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja |
e-R.2.17.2.2 | Planowany termin wizyty |
e-R.2.17.2.3 | Wiadomość e-mail jest sformatowana w treści gotowej do wydruku |
e-R.2.17.2.4 | Zapisanie zmiany statusu Rejestracji w historii moich danych na koncie użytkowania końcowego |
e-R.2.18 | W wyniku zmiany terminu wizyty w lokalnym Systemie medycznym HIS, przekazuje on wiadomość SMS i/lub e-mail z powiadomieniem o określonej treści: |
e-R.2.18.1 | Wiadomości SMS jest generowana automatycznie i zawiera część: |
e-R.2.18.1.1 | stałą (co najmniej): |
e-R.2.18.1.1.1 | podać treść |
e-R.2.18.1.1.2 | ID Użytkownika końcowego |
e-R.2.18.1.2 | zmienną (co najmniej): |
e-R.2.18.1.2.1 | Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja |
e-R.2.18.1.2.2 | Stary termin wizyty |
e-R.2.18.1.2.3 | Planowany termin wizyty |
e-R.2.18.2 | Wiadomość e-mail jest generowana automatycznie i zawiera część: |
e-R.2.18.2.1 | stałą (co najmniej): |
e-R.2.18.2.1.1 | podać treść |
e-R.2.18.2.1.2 | ID Użytkownika końcowego |
e-R.2.18.2.2 | zmienną (co najmniej): |
e-R.2.18.2.2.1 | Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana Rejestracja |
e-R.2.18.2.2.2 | Stary termin wizyty |
e-R.2.18.2.2.3 | Planowany termin wizyty |
e-R.2.18.2.2.4 | Wiadomość e-mail jest sformatowana w treści gotowej do wydruku |
e-R.2.18.2.2.5 | Zapisanie zmiany statusu rejestracji w historii moich danych na koncie użytkowania końcowego |
e-R.2.18.3 | W wyniku zakończenia wizyty |
e-R.2.18.3.1 | Zapisanie zmiany statusu Rejestracji w historii moich danych na koncie użytkowania końcowego |
e-R.3 | Nadzór nad procesami nieuprawnionego korzystania |
e-R.3.1 | System musi wspierać nadzór nad rejestracją Pacjentów do badań diagnostycznych obrazowych. Nadzór ma na celu uniknięcie sytuacji, w których Pacjenci rejestrują się na badania u tego samego świadczeniodawcy na podstawie 2 różnych skierowań od różnych lekarzy, a badanie to ma dotyczyć tych samych okolic ciała. |
e-R.3.2 | System musi wspierać proces weryfikacji e-Rejestracji do oddziałów szpitalnych w zakresie rejestracji na podstawie więcej niż jednego skierowania do szpitala. Wsparcie ma na celu uniknięcie sytuacji, w których Pacjent na podstawie różnych skierowań rejestruje się na pobyt w wielu oddziałach, np. na podstawie dwóch różnych skierowań rejestruje się na pobyt w jednym oddziale, a na podstawie drugiego skierowania rezerwuje termin w innym oddziale. Pobyt w pierwszym oddziale kończy się, ale termin planowanego przyjęcia do drugiego oddziału jest wyznaczony przed upływem 14 dni od wypisu z poprzedniego oddziału. |
6.14. Wymagania warstwy integracji
Nr funkcjonalności | Funkcjonalność |
Int.1 | Szyna usług w warstwie regionalnej |
Int.1.1 | Szyna usług zapewnia komunikację i wymianę danych pomiędzy jednostkami ochrona zdrowia zintegrowanymi z MSIM. |
Int.1.2 | Szyna usług dostarcza jednorodny zestaw komend, kolejek, funkcji, procedur, komunikatów oraz mechanizmów wymiany danych, definiując sposób dostępu do Istniejących i Lokalnych systemów informatycznych działających w jednostkach ochrony zdrowia zintegrowanych z MSIM. Zestaw ten, jest taki sam dla wszystkich jedenastek ochrony zdrowia zintegrowanych z MSIM, umożliwiając standaryzację w komunikacji pomiędzy nimi. Standaryzacja ta realizowana jest na poziomie API i zapewnia, że wszystkie jedenastki ochrony zdrowia zintegrowane z MSIM używają takich samych mechanizmów do wymiany danych i komunikacji. |
Int.1.3 | Szyna usług ma posiadać możliwość przetwarzania sekwencyjnego jak i równoległego komunikatów modułów systemu, z możliwością powtórzeń operacji, których wykonanie z jakiś przyczyn nie powiodło się. W przypadku wystąpienia błędów w trakcie przetwarzania komunikatów przez szynę usług, błędy te powinny być w sposób prosty identyfikowane, poprzez przypisanie ich do: nazwa modułu, nazwa obiektu, metoda, czas wystąpienia błędu. |
Int.1.4 | Szyna usług ma być zgodna ze standardami: WSDL 1.x, SOAP 1.1, SOAP 1.2, SOAP WITH ATTACHMENTS |
Int.1.5 | Szyna usług ma umożliwiać implementację komunikacji pomiędzy Lokalnymi systemami informatycznymi na podstawie posiadanych adapterów. |
Int.1.6 | Szyna usług ma umożliwiać transformację danych, transformację komunikatów np. xpath/xslt/xquery. |
Int.1.7 | Szyna usług ma umożliwiać wzbogacanie transformacji danych o warunki logiczne lub ograniczenia. |
Int.1.8 | Szyna usług ma obsługiwać wiele warstw transportowych np.: JMS, HTTP, FTP, TCP. |
Int.1.9 | Szyna usług ma umożliwiać monitorowanie poprawnej pracy usług. |
Int.2 | Szyna usług zapewni realizację odpowiedniego poziomu bezpieczeństwa w zakresie: |
Int.2.0.1 | Uwierzytelniania |
Int.2.0.2 | Kontroli dostępu |
Int.2.0.3 | Zarządzania użytkownikami, grupami i rolami |
Int.2.0.4 | Przechowywania i walidacji certyfikatów, haseł, klucza |
Int.2.0.5 | Audytowania zdarzeń bezpieczeństwa |
Int.2.1 | Szyna usług zapewni dostępność mechanizmów uwierzytelniania i szyfrowania usług takich jak: użytkownik/hasło, weryfikacja hostów, brak uwierzytelniania, certyfikaty x.509 |
Int.2.2 | Szyna usług zapewni możliwość ograniczenia czasu wywołań dla usług oraz Szyna usług ma zawierać zestawienie adapterów do systemów i standardów zewnętrznych np: -, nfs, pliki lokalne, http, smtp, ftp, jms, -, jdbc, edi, oracle, db2. |
Int.2.3 | Szyna usług zapewni obsługę komunikatów typu np.: SOAP, XML, FTP, SMTP. |
Int.2.4 | Szyna usług zapewni możliwość eksportu ustawień konfiguracyjnych i importu na innej instancji Szyny Usług. |
Int.2.5 | Szyna usług ma mieć wbudowaną obsługę mechanizmów kolejkowych. |
Int.2.6 | Szyna usług ma zapewnić obsługę mechanizmów autoryzacji i autentykacji pozwalających na integrację z systemem ePUAPePUAP |
Int.3 | Interfejs integracji regionalnej |
Int.3.1 | Interfejs integracji musi działać w oparciu o publiczne standardy. Musi istnieć możliwość jego realizacji bez wykorzystania komercyjnych mechanizmów oraz oprogramowania komercyjnego po stronie warstwy lokalnej j |
Int.3.2 | Interfejs integracji musi być skalowalny do obsługi do min 150 jednostek ochrony zdrowia. |
Int.4 | Wykonawca musi przekazać zamawiającemu dokumentację interfejsu integracji zawierającą następujące elementy: |
Int.4.0.1 | Struktura komunikatów. |
Int.4.0.2 | Opis przepływu informacji z wykorzystaniem jednej z powszechnie stosowanych notacji, np. UML. |
Int.4.1 | Wykonawca ma wybudować interfejs integracji służący do wymiany danych pomiędzy MSIM a Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (P1)) |
7. Infrastruktura
Wykonawca musi dostarczyć infrastrukturę sprzętowo-programową zgodnie ze specyfikacjami przedstawionymi w niniejszym rozdziale oraz w liczbie przedstawionej w następujących tabelach. Jeżeli w szczegółowym opisie przedmiotu zamówienia zostały wskazane znaki towarowe, patenty lub pochodzenie Zamawiający w każdym przypadku dopuszcza rozwiązania równoważne pod względem x.xx. funkcji, materiałów, jakości, parametrów. Użyty w specyfikacjach termin lokalizacja odnosi się do fizycznej lokalizacji (serwerowni) pojedynczego Partnera Projektu, w którym będzie wdrożony komponent lokalny lub regionalny, co oznacza, że Projekt obejmuje 7 lokalizacji komponentu lokalnego oraz 2 lokalizacje komponentu regionalnego (2 redundantne serwerownie Partnera Wiodącego).
Komplet dla infrastruktury sprzętowej oznacza 1 szt. urządzenia wraz z niezbędnym okablowaniem umożliwiającym ich podłączenie. W przypadku oprogramowania komplet oznacza taką ilość oprogramowania, która będzie pokrywać cały sprzęt przewidziany do dostarczenia w danym szpitalu dla jednej serwerowni.
ID Wymagania | Opis wymagania |
WYMGW.1. | Gwarancja na sprzęt i oprogramowanie przez okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego Systemu. |
WYMGW.2. | Wsparcie sprzętu i oprogramowania przez okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego Systemu. |
WYMGW.3. | Oferowane urządzenia musza być fabrycznie nowe i pochodzić z autoryzowanego kanału dystrybucji producenta. |
W poniższej tabeli przedstawiono wykaz serwerowni do których w ramach przedmiotu zamówienia zostanie przez Wykonawcę dostarczona infrastruktura:
Partner Projektu | Serwerownia podstawowa – lokalizacja | Serwerownia zapasowa – lokalizacja | Dodatkowe uwagi |
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | 33-300 Nowy Sącz, Xxxxxxx 0, Xxxxxxx xxxxxx | 00-000 Xxxx Xxxx, Xxxxxxx 0, Xxxxxxx xxxxxx - RTG | Kompletna warstwa lokalna – serwerownia podstawowa UTM/przełączniki ETHERNET w obu lokalizacjach - redundantnie (serwerownia podstawowa oraz zapasowa) |
Szpital Specjalistyczny im. J. Dietla w Krakowie | 31-121 Kraków, ul. Skarbowa 4 | 00-000 Xxxxxx, xx Xxxxx 00 | Kompletna warstwa lokalna – serwerownia podstawowa UTM/przełączniki ETHERNET w obu lokalizacjach - redundantnie (serwerownia podstawowa oraz zapasowa) |
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o. – warstwa lokalna | xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx | Kompletna warstwa lokalna – serwerownia podstawowa | |
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o. – warstwa regionalna | xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx: poziom +I piętro (naklejka serwerowni 1) | xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx: poziom -1 piwnica (centrala telefoniczna - naklejka serwerownia 2) | Kompletna warstwa lokalna / klimatyzacja – serwerownia podstawowa Kompletna warstwa regionalna – serwerownia podstawowa Serwery / Szafy RACK / Macierz / Biblioteka taśmowa / Przełączniki FC / przełączniki ETHERNET / Adaptery Mini GBIC / Konsola KVM / UTM / Urządzenia podtrzymujące zasilanie w obu lokalizacjach - redundantnie (serwerownia podstawowa oraz zapasowa) |
Dostawy realizowane będą w podziale na Partnerów Projektu zgodnie z poniższym zakresem rzeczowym, gdzie ilości zostały wskazane jako komplet (kpl.), który powinien zawierać wszelkie elementy dostarczone przez producenta sprzętu lub oprogramowania (w tym w szczególności licencje, nośniki ze sterownikami oraz oprogramowaniem, elementy montażowe, zaślepki, kable, instrukcje) oraz wszelkie elementy niezbędne do poprawnej konfiguracji, prawidłowego podłączenia oraz działania zarówno elementów dostarczonych pomiędzy sobą, elementów dostarczonych z istniejącą infrastruktura partnera oraz innych jednostek biorących udział w projekcie, jak i poprawności działania całego systemu MSIM zgodnie z założeniami projektu. W przypadku nie wykorzystywanych portów, slotów i zatok, półek – należy dostarczyć stosowne zaślepki. Okablowanie dostarczone powinno umożliwiać połączenie urządzeń na maksymalnej przepustowości dla danej pary urządzeń (np. w przypadku połączenia portów 100Mbit z portem 1Gbit jest to 100Mbit, w przypadku 2 portów 1Gbit jest to 1Gbit). Wersje instalacyjne oraz instrukcje oprogramowania, które nie posiadają nośników i instrukcji w formie papierowej, a jedynie licencje w wersji elektronicznej, należy przekazać zamawiającemu na nośniku lub nośnikach typu Archivalgrade. Licencje należy przekazać w wersji papierowej, a w przypadku licencji w wersji elektronicznej, dodatkowo w postaci wydruku.
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
Oprogramowanie: zakup licencji | Liczba (kpl.) |
Repozytorium Lokalne EDM | 1 |
Oprogramowania systemowe | Liczba (kpl.) |
Oprogramowanie do backupu | 1 |
Oprogramowanie do wirtualizacji | 1 |
Oprogramowanie zabezpieczające | 1 |
Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową | 1 |
Oprogramowanie serwera aplikacji | 1 |
Oprogramowanie bazy danych | 1 |
System operacyjny | 1 |
Infrastruktura sprzętowa | Liczba (kpl.) |
Serwer Aplikacyjny | 1 |
Serwer Pomocniczy | 1 |
Serwer Bazodanowy | 1 |
Szafa Rack | 1 |
Macierz | 1 |
Biblioteka taśmowa | 1 |
Konsola KVM | 1 |
Przełącznik Ethernet | 2 |
Urządzenie UTM | 2 |
Urządzenia podtrzymujące zasilanie | 1 |
Klimatyzacja | 1 |
Infrastruktura podpisu elektronicznego | 1 |
Szpital Specjalistyczny im. J. Dietla w Krakowie
Oprogramowanie: zakup licencji | Liczba (kpl.) |
Repozytorium Lokalne EDM | 1 |
Oprogramowania systemowe | Liczba (kpl.) |
Oprogramowanie do backupu | 1 |
Oprogramowanie do wirtualizacji | 1 |
Oprogramowanie zabezpieczające | 1 |
Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową | 1 |
Oprogramowanie serwera aplikacji | 1 |
Oprogramowanie bazy danych | 1 |
System operacyjny | 1 |
Infrastruktura sprzętowa | Liczba (kpl.) |
Serwer Aplikacyjny | 1 |
Serwer Pomocniczy | 1 |
Serwer Bazodanowy | 1 |
Szafa Rack | 1 |
Macierz | 1 |
Biblioteka taśmowa | 1 |
Konsola KVM | 1 |
Przełącznik Ethernet | 2 |
Urządzenie UTM | 2 |
Urządzenia podtrzymujące zasilanie | 1 |
Klimatyzacja | 1 |
Infrastruktura podpisu elektronicznego | 1 |
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.
Oprogramowanie: zakup licencji | Liczba (kpl.) |
Repozytorium Lokalne EDM | 1 |
Oprogramowania systemowe | Liczba (kpl.) |
Oprogramowanie do backupu | 1 |
Oprogramowanie do wirtualizacji | 1 |
Oprogramowanie zabezpieczające | 1 |
Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową | 1 |
Oprogramowanie serwera aplikacji | 1 |
Oprogramowanie bazy danych | 1 |
System operacyjny | 1 |
Infrastruktura sprzętowa | Liczba (kpl.) |
Serwer Aplikacyjny | 1 |
Serwer Pomocniczy | 1 |
Serwer Bazodanowy | 1 |
Szafa Rack | 1 |
Macierz | 1 |
Biblioteka taśmowa | 1 |
Konsola KVM | 1 |
Przełącznik Ethernet | 2 |
Urządzenie UTM | 2 |
Urządzenia podtrzymujące zasilanie | 1 |
Klimatyzacja | 1 |
Infrastruktura podpisu elektronicznego | 1 |
Infrastruktura podpisu elektronicznego, która zlokalizowana będzie w trzech Szpitalach jako element warstwy lokalnej w projekcie przedstawia się następująco:
Infrastruktura podpisu elektronicznego | Liczba (kpl.) | Liczba (szt.) |
Czytniki kart | 3 | 700 |
Karty kryptograficzne | 700 | |
Naklejki | 1400 | |
Folia | 11 | |
Zestawy czyszczące | 5 | |
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu | ||
Czytniki kart | 1 | 174 |
Karty kryptograficzne | 174 | |
Szpital Specjalistyczny im. J. Dietla w Krakowie | ||
Czytniki kart | 1 | 193 |
Karty kryptograficzne | 193 | |
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o. | ||
Czytniki kart | 1 | 333 |
Karty kryptograficzne | 333 | |
System oraz akcesoria służące do personalizacji kart | Liczba (szt.) |
Urząd Marszałkowski Województwa Małopolskiego | |
Naklejki | 1400 |
Folia | 11 |
Zestawy czyszczące | 5 |
System personalizacji wraz dokumentacją | 1 |
Wykonawca przeprowadzi instalację oraz konfigurację elementów infrastruktury podpisu elektronicznego w siedzibie każdego uczestnika projektu (w miejscach wskazanych przez Zamawiającego) w ilości zgodnej z powyższym zestawieniem. Personalizacja oraz nadruk kart zostanie wykonany przez pracowników Urzędu Marszałkowskiego Województwa Małopolskiego.
W warstwie regionalnej, która zlokalizowana będzie w Szpitalu Specjalistycznym im. Ludwika Rydygiera w Krakowie zakres planowanych zakupów w projekcie przedstawia się następująco:
Oprogramowanie w warstwie regionalnej | Liczba (kpl.) |
Rejestr EDM | 1 |
E-rejestracja | 1 |
Oprogramowanie portalowe | 1 |
Oprogramowanie systemowe | Liczba (kpl.) |
Oprogramowanie do backupu | 2 |
Oprogramowanie do wirtualizacji | 2 |
Oprogramowanie zabezpieczające | 2 |
Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową | 2 |
Oprogramowanie bazodanowe | 2 |
Oprogramowanie serwera aplikacji | 2 |
System operacyjny | 2 |
Infrastruktura regionalna | Liczba (kpl.) |
Serwer Aplikacyjny | 2 |
Serwer Bazodanowy | 2 |
Serwer Pomocniczy | 2 |
Szafa Rack | 2 |
Macierz | 2 |
Biblioteka taśmowa | 2 |
Przełącznik Ethernet | 2 |
Przełącznik FC | 2 |
Adaptery Mini GBIC | 24 |
Konsola KVM | 2 |
UTM Region | 2 |
Klimatyzacja – Region | 1 |
Urządzenia podtrzymujące zasilanie – Region | 2 |
Budowa infrastruktury sprzętowej na potrzeby projektu MSIM obejmuje kompleksową infrastrukturę sprzętowo-programową w warstwie regionalnej oraz lokalnej, pozwalającą w przypadku warstwy regionalnej na jej niezależne i dowolne umieszczenie bez konieczności dodatkowej rozbudowy. Zakłada się połączenie Szpitali objętych projektem MSIM siecią VPN oraz wykonanie regionalnej i lokalnych dedykowanych dla potrzeb Systemu EDM struktur sprzętowo-sieciowych.
Projektując infrastrukturę sprzętową pod system EDM zasadniczym elementem było uniknięcie pojedynczych punktów awarii całości rozwiązania. Tam gdzie było to możliwe elementy infrastruktury są podwojone, w szczególności w warstwie regionalnej. Redundancja warstwy regionalnej pozwala na zachowanie ciągłości działania w przypadku awarii jednej z lokalizacji. W warstwie lokalnej zdecydowano się na rozwiązanie z pojedynczym kompletem serwerów i macierzy.
System EDM będzie posiadał wysoki poziom ciągłości działania, co jest kluczową cechą koncepcji przechowywania i udostępniania dokumentacji medycznej w formie elektronicznej.
Dla komponentu regionalnego:
Sekcja | Nazwa | Liczba (kpl.) |
2 | ||
2 | ||
7.1.1.3 | 2 | |
Serwer Pomocniczy | ||
7.1.1.4 | 2 |
Szafa | ||
7.1.3.1 | Macierz – Region | 2 |
7.1.3.3 | Biblioteka taśmowa | 2 |
7.2.1.1 | Przełącznik Fiber Channel | 2 |
7.2.1.2 | Przełącznik Ethernet - Region | 2 |
7.2.2 | Adaptery Mini GBIC | 24 |
7.2.3 | Xxxxxxx XXX | 0 |
7.3.1.1 | UTM - Region | 2 |
7.3.2 | Urządzenia podtrzymujące zasilanie – Region | 2 |
7.4.2 | Klimatyzacja – Region | 1 |
7.4.4. | Urządzenie do administracji MSIM | 1 |
7.5.1 | Oprogramowanie do backupu | 2 |
7.5.2 | Oprogramowanie do wirtualizacji | 2 |
7.5.3 | Oprogramowanie zabezpieczające | 2 |
7.5.4 | Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową | 2 |
7.5.5 | System operacyjny | 2 |
7.5.6 | Oprogramowanie bazy danych | 2 |
7.5.7 | Oprogramowanie serwera aplikacji | 2 |
Dla komponentu lokalnego:
Sekcja | Nazwa | Liczba (kpl.) |
7.1.2.1 | Serwer Aplikacyjny | 3 |
7.1.2.2 | 3 | |
Serwer Bazodanowy | ||
7.1.2.3 | 3 | |
Serwer Pomocniczy | ||
7.1.2.4 | Szafa | 3 |
7.1.3.2 | Macierz – Szpitale | 3 |
7.1.3.3 | Biblioteka taśmowa | 3 |
7.2.1.3 | Przełącznik Ethernet - Szpitale | 6 |
7.2.3 | Xxxxxxx XXX | 0 |
7.3.1.2 | UTM – Szpitale | 6 |
7.3.3 | Urządzenia podtrzymujące zasilanie – Szpitale | 3 |
7.3.4 | Infrastruktura podpisu elektronicznego | 3 |
7.4.3 | Klimatyzacja – Szpitale | 3 |
7.5.1 | Oprogramowanie do backupu | 3 |
7.5.2 | Oprogramowanie do wirtualizacji | 3 |
7.5.3 | Oprogramowanie zabezpieczające | 3 |
7.5.4 | Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową | 3 |
7.5.5 | System operacyjny | 3 |
7.5.6 | Oprogramowanie bazy danych | 3 |
7.5.7 | Oprogramowanie serwera aplikacji | 3 |
Wszystkie niewymienione w tabeli elementy infrastruktury dostarczane są zgodnie z opisem we właściwej sekcji.
7.1. Infrastruktura serwerowa
Sekcja przedstawia zestawienie elementów infrastruktury serwerowej niezbędnych do realizacji projektu wraz z wyszczególnieniem ich parametrów technicznych. Wszystkie wykazane parametry techniczne mają charakter specyfikacji minimalnych.
7.1.1.Serwery – Region
Poniżej przedstawiono wymagania dla Serwera Aplikacyjnego.
ID Wymagania | Opis wymagania |
WYMSA.1. | Obudowa do montażu w szafie, wysokość maksymalna 2U, wymagane dostarczenie szyn montażowych do szafy, wysuwanego ramienia na kable oraz wszystkich innych niezbędnych elementów potrzebnych do instalacji i poprawnego działania serwera. |
WYMSA.2. | Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Płyta główna musi być zaprojektowana przez producenta xxxxxxx i oznaczona jego znakiem firmowym. |
WYMSA.3. | Procesory minimum sześciordzeniowe, x86 - 64 bity, osiągający w testach SPECint_rate2006 Base wynik nie gorszy niż 435 punktów dla konfiguracji testowej z dwoma procesorami. Zamawiający nie wymaga złożenia wraz z ofertą wyników w/w testów. |
WYMSA.4. | Minimum 2 zainstalowane procesory. |
WYMSA.5. | Minimum min. 96GB pamięci RAM RDIMM. Serwer musi być wyposażony w min 24 gniazd na moduły pamięci. Możliwość instalacji w serwerze min. 768GB RAM. Możliwość instalacji kości pamięci RDIMM lub UDIMM. |
WYMSA.6. | Minimum 2 sloty PCI-Express generacji 3, w tym jeden slot x16 (szybkość slotu – bus width) oraz minimum jedno gniazdo pełnej wysokości. |
WYMSA.7. | Minimum 4 złącza typu 1GbEthernet RJ-45. |
WYMSA.8. | Minimum jedna karta FC zapewniająca minimum 2 interfejsy FC,, każdy min. |
ID Wymagania | Opis wymagania |
8Gb. | |
WYMSA.9. | Wewnętrzne wnęki dyskowe przygotowane do instalacji i działania minimum ośmiu dysków SAS/SATA/SSD typu Hot-Plug. W serwerze zainstalowane min. 2 dyski twarde każdy o parametrach: 300GB, prędkość obrotowa 10000 obrotów/minutę, SAS 6G, Hot-Plug. |
WYMSA.10. | Dedykowany kontroler RAID min 512MB cache z mechanizmem podtrzymywania zawartości pamięci cache w razie braku zasilania. Możliwe konfiguracje 0, 1, 10, 5, 50 Możliwość rozbudowy wbudowanego w płytę kontrolera dyskowego o dodatkowe funkcje, takie jak RAID 6, 60. |
WYMSA.11. | Serwer wyposażony w wewnętrzny napęd DVD lub Blue-ray. |
WYMSA.12. | Minimum 4 szt. portów USB, w tym jeden wewnętrzny. |
WYMSA.13. | Serwer wyposażony w kartę zdalnego zarządzania zapewniającą: a) Zdalne włączanie/wyłączanie/restart. b) Zdalny dostęp z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu. c) Zdalną identyfikację fizycznego serwera za pomocą sygnalizatora optycznego. d) Podłączanie zdalnych napędów CD-ROM/DVD/ISO/Blue-ray z możliwością bootowania z w/w napędów. e) Podgląd logów sprzętowych serwera i karty. f) Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od jego stanu (także podczas startu, restartu OS). |
WYMSA.14. | Zintegrowana karta graficzna. |
WYMSA.15. | 2 szt. zasilaczy, redundantne, hot plug. |
WYMSA.16. | Chłodzenie: 2 szt (redundantne), hot plug. |
WYMSA.17. | Możliwość zainstalowania modułu TPM na płycie głównej serwera. |
WYMSA.18. | Wspierane systemy operacyjne: Microsoft Windows 2008R2 i 2012, Oracle Linux 6, Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11, VMware ESXi 5. |
WYMSA.19. | Dostarczony system operacyjny: system operacyjny (OS) wspierany na serwerze, wymagany do instalacji i poprawnego działania oprogramowania zarządzającego wraz z niezbędnymi komponentami. |
Poniżej przedstawiono wymagania dla Serwera Bazodanowego.
ID wymagania | Opis wymagania |
WYMSB.1. | Obudowa do montażu w szafie, wysokość maksymalna 2U, wymagane dostarczenie szyn montażowych do szafy, wysuwanego ramienia na kable oraz wszystkich innych niezbędnych elementów potrzebnych do instalacji i poprawnego działania serwera. |
WYMSB.2. | Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Płyta główna musi być zaprojektowana przez producenta xxxxxxx |