Małopolski System Informacji Medycznej – projekt pilotażowy

Transkrypt

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
Opis Przedmiotu Zamówienia
1.
Wstęp ....................................................................................................................................................... 4
2.
Wymagania podstawowe do realizacji Systemu MSIM ............................................................................. 5
2.1. Założenia projektowe .............................................................................................................................. 5
2.2. Ogólne wymagania jakie powinien spełniad system MSIM................................................................... 11
2.3. Koncepcja wykonania i dostawy, instalacji, konfiguracji, wdrożenia, uruchomienia oraz integracji
systemu MSIM ................................................................................................................................................... 15
2.4. Dyslokacja elementów systemu ............................................................................................................ 18
2.5. Zasady budowy reguł interoperacyjności w systemie ........................................................................... 19
2.6. Koncepcja synchronizacji czasu – normalizacji czasu ............................................................................ 19
2.7. Koncepcja autentykacji i identyfikacji użytkowników ........................................................................... 20
2.8. Koncepcja współpracy z Internetowym Kontem Pacjenta (IKP) ............................................................ 21
2.9. Koncepcja przesyłania dokumentacji o dużej pojemności ..................................................................... 22
2.10.
Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych jednostek ............................. 23
2.11.
Schemat połączeo pomiędzy elementami systemu ........................................................................... 23
2.12.
Interfejsy komunikacyjne z innymi systemami informatycznymi ...................................................... 27
2.13.
Koncepcja komunikacji pomiędzy jednostkami ................................................................................. 28
2.14.
Koncepcja przesyłu danych pomiędzy jednostkami ........................................................................... 30
2.15.
Integracja systemów oraz danych z innych systemów do wdrażanego systemu MSIM.................... 31
2.16.
Koncepcja wirtualizacji zasobów informatycznych ........................................................................... 31
3. Analiza stanu aktualnego ........................................................................................................................ 31
3.1. Infrastruktura informatyczna ................................................................................................................ 31
3.2. Infrastruktura sieciowa ......................................................................................................................... 39
3.3. Łącza internetowe ................................................................................................................................. 41
3.4. Procedury bezpieczeostwa .................................................................................................................... 42
3.5. Oprogramowanie dziedzinowe .............................................................................................................. 43
3.6. Rodzaje przetwarzanych danych ........................................................................................................... 45
3.7. Gwarancja i serwis ................................................................................................................................ 47
3.8. Lokalne słowniki dokumentów .............................................................................................................. 48
4. Model statyczny ..................................................................................................................................... 49
4.1. Komponent lokalny................................................................................................................................ 49
4.2. Komponent regionalny .......................................................................................................................... 50
4.3. Interfejsy................................................................................................................................................ 54
5. Model dynamiczny ................................................................................................................................. 55
5.1. Wprowadzenie ...................................................................................................................................... 55
5.2. Metoda opisu ........................................................................................................................................ 55
5.3. Mapa główna procesów biznesowych ................................................................................................... 57
5.4. Przekazywanie EDM .............................................................................................................................. 58
5.5. e-Rejestracja .......................................................................................................................................... 65
6. Wymagania Systemu MSIM .................................................................................................................... 71
6.1. Wymagania ogólne ............................................................................................................................... 71
6.2. Wymagania ogólne interfejsu użytkownika .......................................................................................... 72
6.3. Wymagania prawne, organizacyjne i funkcjonalne .............................................................................. 72
6.4. Wymagania wydajnościowe systemu ................................................................................................... 78
6.5. Wymagania skalowalności .................................................................................................................... 78
6.6. Wymagania wolumenu przetwarzanych danych .................................................................................. 78
6.7. Wymagania niezawodności................................................................................................................... 78
6.8. Wymagania bezpieczeostwa ................................................................................................................. 79
6.9. Ochrona danych osobowych ................................................................................................................. 80
6.10.
Wymagania systemu zarządzania tożsamością ................................................................................ 81
6.11.
Procedury nadawania/zmiany/odbierania uprawnieo ..................................................................... 82
6.12.
Repozytorium EDM ............................................................................................................................ 83
6.13.
Usługa e-Rejestracja.......................................................................................................................... 84
6.14.
Wymagania warstwy integracji ........................................................................................................ 90
7. Infrastruktura ......................................................................................................................................... 91
Strona 2 z 161
7.1. Infrastruktura serwerowa ..................................................................................................................... 99
7.2. Komunikacja ........................................................................................................................................ 112
7.3. Bezpieczeostwo ................................................................................................................................... 120
7.4. Pozostałe elementy ............................................................................................................................. 129
7.5. Oprogramowanie systemowe ............................................................................................................. 132
8. Platforma danych ................................................................................................................................. 139
8.1. Metadane dla źródeł danych ............................................................................................................... 139
8.2. Model biznesowy platformy danych.................................................................................................... 140
9. Metodyka wdrożenia Systemu ............................................................................................................. 141
9.1. Dokumentacja ..................................................................................................................................... 141
9.2. Szkolenia.............................................................................................................................................. 145
9.3. Odbiór.................................................................................................................................................. 151
9.4. Eksploatacja ........................................................................................................................................ 153
10.
Gwarancja oraz wsparcie .................................................................................................................. 155
10.1.
Gwarancja ....................................................................................... Błąd! Nie zdefiniowano zakładki.
10.2.
Wsparcie.......................................................................................... Błąd! Nie zdefiniowano zakładki.
11.
Licencjonowanie ............................................................................................................................... 161
Strona 3 z 161
1. Wstęp
Przedmiotem zamówienia jest stworzenie oraz kompletne wdrożenie jednolitej zintegrowanej platformy
wymiany danych Medycznych i udostępnienie elektronicznych usług medycznych w skali regionu.
Założeniem projektu MSIM (Małopolski System Informacji Medycznej) – projekt pilotażowy jest
stworzenie regionalnego systemu informacji medycznej – narzędzia informatycznego pozwalającego
na wymianę dokumentacji medycznej pomiędzy podmiotami leczniczymi w województwie
małopolskim.
Projekt planowany jest do realizacji jako indywidualny projekt kluczowy Małopolskiego Regionalnego
Programu Operacyjnego na lata 2007-2013 i umieszczony jest w Indykatywnym Wykazie
Indywidualnych Projektów Kluczowych Małopolskiego Regionalnego Programu Operacyjnego na lata
2007-2013.
W projekcie bierze udział Urząd Marszałkowski oraz jako partnerzy 3podmioty lecznicze z terenu
województwa małopolskiego:



Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu,
Szpital Specjalistyczny im. J. Dietla w Krakowie,
Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o.
Przedmiotem niniejszego zamówienia jest:
1.
2.
3.
4.
5.
6.
7.
8.
Dostawa dokumentacji,
Przygotowanie koncepcji wdrożenia,
Dostawa licencji,
Dostawa oprogramowania wytwarzanego na potrzeby Zamówienia,
Dostawa oprogramowania standardowego oraz systemowego,
Dostawa, instalacja, integracja i konfiguracja infrastruktury sprzętowej oraz programowej,
Szkolenia oraz instruktarze stanowiskowe,
Gwarancja.
Szczegółowe wymagania dla powyższych produktów zdefiniowane zostały w kolejnych rozdziałach.
Strona 4 z 161
2. Wymagania podstawowe do realizacji Systemu MSIM
2.1. Założenia projektowe
2.1.1.Warstwy MSIM
System MSIM ma zapewniać rozdzielność warstwy regionalnej i warstwy lokalnej. Planowane
rozwiązanie nie pozwala na bezpośredni dostęp do systemów dziedzinowych Szpitali z poziomu
warstwy regionalnej.
Warstwa regionalna
Warstwa lokalna
HIS
LIS
RIS
PACS
.
Rysunek 1. Separacja dostępu do systemów dziedzinowych (źródłowych).
Wymiana Elektronicznej Dokumentacji Medycznej jest realizowana dwustronnie na osi Warstwa
lokalna ↔Warstwa regionalna oraz HIS ↔ Warstwa lokalna. Z kolei e-Rejestracja jest zasilana za
pośrednictwem WebService’ów i może się komunikować z HIS w zakresie wymiany grafików,
terminów, informacji o kolejkach oczekujących. Pozostałe systemy dziedzinowe takie jak LIS, RIS,
PACS nie są integrowane z warstwą lokalną (ew. pośrednio poprzez HIS). Integracja systemami LIS,
RIS i PACS jest poza zakresem zamówienia. W zakres zamówienia wchodzi integracja z
interfejsami do systemów HIS opracowanymi przez wykonawców tych systemów (wyciąg z
umów jest załączony do SIWZ.
Pod względem architektury rozwiązania cały system wymiany dokumentów i danych medycznych jest
podzielony na część regionalną, w której funkcjonować będą elementy systemu odpowiadające za
interoperacyjność rozwiązania oraz część lokalną, działającą w poszczególnych jednostkach
medycznych wchodzących w skład domeny. Dokumentacja medyczna jest gromadzona w EDM, które
są elementem dostawy w warstwie lokalnej, natomiast warstwa regionalna zawiera jedynie jej indeks.
W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji pacjentów,
pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą metadane wszystkich
dokumentów). Ustalany jest też schemat i zasady identyfikacji obiektów powstających w systemie oraz
ich wersjonowaniem.
Strona 5 z 161
W poszczególnych szpitalach zostaną utworzone Lokalne Repozytoria EDM, które pozwalać będą na
gromadzenie, przechowywanie i przesyłanie zgodnie z przepisami (Ustawa z dnia 28 kwietnia 2011 r.
o systemie informacji w ochronie zdrowia oraz Rozporządzenie Ministra Zdrowia z dnia 21 grudnia
2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania)
dokumentacji medycznej. Integracja warstwy regionalnej i lokalnej powinna odbywać się za pomocą
usług sieciowych w oparciu o regionalną szynę danych. W szpitalach będzie konieczne wykonanie
integracji z WebSerwisami dostawców HIS wykonanymi w ramach odrębnego zlecenia.
Warstwa regionalna MSIM
Regionalna Szyna Usług
Warstwa lokalna MSIM
Integracja z WebSerwisami dostawców HIS
HIS
Rysunek 2. Metody integracji w MSIM.
Zamawiający jednocześnie nie określa sposobu wewnętrznej wymiany danych w ramach
dostarczanych w ramach zamówienia modułów (tj. w przypadku, gdy oprogramowanie Wykonawcy
będzie miało jakąś wewnętrzną strukturę – to nie określa sposobu wymiany danych w ramach
oferowanego oprogramowania).
Strona 6 z 161
2.1.2. Wymiana EDM
W zakresie wymiany EDM rozwiązanie przewiduje podział funkcjonalny na warstwę lokalną i warstwę
regionalną według poniższych wytycznych.
Rejestr dokumentów EDM
(warstwa regionalna MSIM)
EDM
Adapter komunikacyjny
(warstwa lokalna MSIM)
(warstwa lokalna MSIM)
Interfejs z HIS
HIS
Rysunek 3. Wymiana danych w zakresie EDM.
Warstwa lokalna – gdzie będzie wdrożony moduł odpowiedzialny za wytwarzanie, gromadzenie
i przesyłanie EDM oraz usługi towarzyszące pozwalające na integrację z węzłem regionalnym.
W warstwie lokalnej będzie gromadzona EDM zgodna z Załącznikiem9A „Standard wymiany danych
pomiędzy HIS i MSIM”, zgodnie zobowiązującymi przepisami. Za pomocą odpowiednich usług i
serwisów informacja o wytworzeniu dokumentacji medycznej będzie przesyłana do warstwy
regionalnej, gdzie zostanie utworzony indeks z podstawowymi informacjami dotyczącymi tego
dokumentu. Pozwoli to na poziomie regionalnym przechowywać scentralizowane informacje o miejscu
składowania i fakcie wytworzenia wraz z informacją o wersjonowaniu wszystkich dokumentów
medycznych w podmiotach biorących udział w Projekcie. Wiarygodność EDM będzie wymagała
poświadczenia przy użyciu mechanizmów zaimplementowanych w systemie.
Za pomocą odpowiednich interfejsów uwierzytelniony Użytkownik będzie mógł odpytać warstwę
regionalną o dokumenty w innych jednostkach oraz pobrać je w całości lub częściowo. Dostęp do
dokumentacji będzie autoryzowany, co oznacza, że użytkownik będzie mógł otrzymać dokumenty, do
których ma prawo.
W poszczególnych szpitalach uczestniczących zostaną wdrożone i wykorzystane repozytoria lokalne,
których głównym zadaniem będzie przyjmowanie i przechowywanie zgodnie z przepisami wskazanymi
w dalszej części dokumentów medycznych z systemów dziedzinowych (HIS, LIS, RIS lub innych)
funkcjonujących w szpitalach.
Warstwa regionalna – gdzie wdrożony będzie rejestr EDM, który zawiera rejestr dokumentów czyli
tzw. indeks EDM znajdującej się we wszystkich lokalnych repozytoriach EDM.
W przypadku konieczności pobrania przez lekarza pełnej dokumentacji medycznej pacjenta
z konkretnego pobytu/wizyty wymaga się możliwość jej zamówienia/pobrania jedynie
w trzech wariantach możliwych do wybrania przez Użytkownika:
Strona 7 z 161



Podstawowa dokumentacja medyczna (m. in. dokumentacja zewnętrzna: karta informacyjna,
karta porady specjalistycznej, karta informacyjna SOR).
Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza
objętość).
Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości
diagnostycznej (duża objętość)
Wymagane rozwiązanie zapewni w przypadku konieczności zapoznania się z bardziej szczegółową
dokumentacją pobranie jej w komplecie dla danego pobytu, przez co gwarantuje się analizę danych
diagnostycznych i z procesu leczenia w kontekście całego pobytu. Eliminuje to zagrożenie opierania
się podczas decyzji leczniczych na pobranym dokumencie (np. z danymi diagnostyki laboratoryjnej)
bez kontekstu procesu leczenia wdrożonego podczas danego pobytu.
W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji pacjentów,
pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą metadane wszystkich
dokumentów).
W warstwie regionalnej będzie realizowana większość usług (np. wyszukiwanie, przeglądanie,
pobieranie, przekazywanie do innych podmiotów). Rozwiązanie takie minimalizuje warunki techniczne
potrzebne w warstwie lokalnej do sprawnego funkcjonowania systemu–wszelkie zapytania od strony
klientów obsługiwane są wyłącznie z wykorzystaniem warstwy regionalnej.
Przedmiotem zamówienia w ramach MSIM jest:



warstwa regionalna (rejestr EDM),
EDM w warstwie lokalnej,
adapter komunikacyjny.
Pozostałe elementy wymiany EDM są realizowane w toku umów z dostawcami HIS.
Strona 8 z 161
2.1.3. E-Rejestracja
Szczególną
usługą
realizowaną
w
ramach
komponentu
regionalnego
jest
usługa
e-Rejestracji. Usługa e-Rejestracji udostępnia funkcjonalność rezerwacji usług medycznych
w jednostkach ochrony zdrowia zintegrowanych z MSIM.
e-Rejestracja MSIM
(warstwa regionalna MSIM)
e-Rejestracja
partnera
(poza MSIM)
HIS
Rysunek 4. Wymiana danych w ramach e-Rejestracji.
Użytkownik ma możliwość rejestracji na wskazany termin i anulowania wizyty. Z e-Rejestracji mogą
korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi (pacjenci). W
ramach usługi powinien funkcjonować system komunikatów (powiadomień dla użytkowników
końcowych w formie np. wiadomości e-mail i SMS) dotyczących: potwierdzenia rejestracji,
zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno przez
użytkownika jak i w lokalnym systemie medycznym HIS). W szczególności usługa obejmuje
następujące funkcjonalności:

Przegląd listy usług możliwych do realizacji w placówce Zamawiającego dla pacjenta.

Przegląd listy usług możliwych do rezerwacji przez Internet.

Możliwość rezerwacji terminu usługi do wybranej poradni lub wybranego lekarza.

Określenie celu wizyty u lekarza, z podziałem na: przypadek nagły incydentalny, stan nagły
przy chorobie przewlekłej, wizytę kontrolną, wizytę po kolejną receptę, wizytę po skierowanie
na badanie specjalistyczne.

Udostępnienie danych o zaplanowanych wizytach i usługach.

Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana).

Możliwość wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko pacjenta,
numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla pacjenta.

Dostęp do informacji o lokalizacji miejsca wykonania usługi.

Możliwość odwołania rezerwacji.

Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail).
Zamówieniem objęta jest:
Strona 9 z 161


e-Rejestracja na poziomie regionalnym integrująca jednostki w ramach MSIM,
dostarczenie, zainstalowanie i skonfigurowanie serwera e-mail na potrzeby powiadomień
MSM.
Współpraca z dostawcami HIS i dostarczenie interfejsów jest poza zamówieniem (realizowana w toku
odrębnych umów). Poza zamówieniem jest również dostarczenie bramki SMS.
Poza tą rejestracją mogą występować inne moduły e-Rejestracji na poziomie poszczególnych
partnerów, jednak – o ile zostanie utrzymana decyzja o ich eksploatacji. Zamawiający nie wymaga
przeprowadzania integracji pomiędzy e-Rejestracją na poziomie regionalnym, a ewentualnymi
rejestracjami lokalnymi.
2.1.4. Podstawowe standardy wykonania MSIM
Głównym celem proponowanego rozwiązania jest usprawnienie zarządzania i podniesienie jakości
procesów leczniczych w podmiotach leczniczych objętych systemem, poprzez rozbudowę
i rozszerzenie stanu istniejącego przedstawionego w analizie stanu obecnego. Rozbudowa ma na
celu bezpieczne i zgodne z prawem wytwarzanie, przechowywanie, oraz przekazywanie dokumentów
medycznych pomiędzy jednostkami oraz integrację z tworzoną na szczeblu krajowym Elektroniczną
Platformą Gromadzenia Informacji O Zdarzeniach Medycznych (projekt P1).
W celu zapewnienia dalszej łatwej rozbudowy oraz integracji z nowymi systemami wymaga się, aby
system w jak największym stopniu oparty był o obowiązujące w tej dziedzinie na świecie standardy
i dobre praktyki. Najszerzej przyjętym w chwili obecnej standardem dotyczącym przekazywania
dokumentacji pomiędzy szpitalami jest profil XDS.b proponowany przez międzynarodową organizację
IHE Wykonawca powinien dostarczać WebSerwis’y umożliwiające zewnętrzną wymianę danych
zgodnie z profilem XDS.b, jakkolwiek nie jest wymagane, aby Wykonawca korzystał z tego standardu
w komunikacji w ramach komunikacji pomiędzy dostarczanymi komponentami MSIM. Profil ten opisuje
procesy i komunikaty jakie muszą zostać wymienione pomiędzy dwoma jednostkami, aby nastąpiło
poprawne przekazanie dokumentu medycznego. Standard wspierany jest obecnie przez większość
głównych dostawców oprogramowania medycznego na świecie.
Sam układ dokumentu medycznego powinien być zdefiniowany w języku XML, w oparciu
o najszerzej przyjęty na świecie format dokumentu opracowany przez organizację HL7 CDAR2 na 3cim poziomie interoperacyjności (w zakresie, gdy to jest możliwe w pozostałych wypadkach należy
stosować poziom 2-gi i 1-szy – w szczególności dla zeskanowanych dokumentów dopuszcza się 1-szy
poziom interoperacyjności). HL7 CDAR2 na trzecim poziomie interoperacyjności zostało także
zaproponowane jako podstawowy format dokumentów medycznych na poziomie krajowym przez
Centrum Systemów Informatycznych w Ochronie Zdrowia.
Na etapie Analizy Przedwdrożeniowej uwzględniona zostanie kwestia dostosowania/ujednolicenia
istniejących słowników, formatów danych i standardów danych słownikowych w celu wykonania
poprawnej integracji/wymiany danych pomiędzy systemami dziedzinowymi zlokalizowanymi w
warstwach lokalnych, a warstwą regionalną.
Pod względem architektury rozwiązania cały system wymiany dokumentów i danych medycznych
podzielony powinien być na część regionalną, w której funkcjonować będą elementy systemu
odpowiadające za interoperacyjność rozwiązania oraz część lokalną, działającą w poszczególnych
jednostkach medycznych. Warstwa regionalna może być posadowiona w lokalizacji jednego
z uczestników projektu.
W przyszłości planuje się rozwój systemu co najmniej w następujących aspektach:


Podłączanie nowych jednostek do systemu.
Rozszerzanie zakresu wymienianych danych zarówno w aspekcie dodatkowych danych do
obecnie wymienianych dokumentów, jak i podłączania nowych systemów dziedzinowych.
Strona 10 z 161

Rozszerzanie funkcjonalności poprzez podłączanie dodatkowych modułów.
2.2. Ogólne wymagania jakie powinien spełniać system MSIM
2.2.1.Główne założeniasystemu MSIM

Integracja systemów informatycznych (HIS, RIS, LIS, PACS, innych) jednostek
medycznych.
Wymagane jest udostępnienie interfejsów pozwalających w przyszłości na integrację z
systemami partnerów (tj. sama integracja jest poza zakresem zamówienia). Wyjątkiem są
systemy HIS, gdzie integracja jest zapewniona przez umowy będące załącznikiem do SIWZ.
Integracja ta musi pozwalać systemom dziedzinowym na zasilenie lokalnych EDM
dokumentami medycznymi wytworzonymi przez te systemy funkcjonujące w jednostkach
medycznych z Repozytorium Elektronicznej Dokumentacji Medycznej. W warstwie lokalnej
(jednostkach medycznych) zaimplementowany zostanie moduł gromadzenia danych
odbierający dokumentację medyczną wytwarzaną w systemach dziedzinowych
funkcjonujących w jednostce. W warstwie regionalnej wdrożona zostanie platforma integrująca
odpowiedzialna za komunikację pomiędzy jednostkami medycznymi oraz udostępnianie,
przesłanie do zamawiającego (pacjenta, jednostki medycznej) dokumentacji medycznej
gromadzonej w ramach systemów dziedzinowych tych jednostek. Ponadto niezbędna będzie
integracja warstwy regionalnej z Elektroniczną Platformą Gromadzenia, Analizy i
Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (P1)) w szczególności w
zakresie IKPw zakresie zgodnym z aktualną dokumentacją projektu P1.

System udostępniania dokumentacji medycznej
Wymagane jest dostarczenie infrastruktury sprzętowej i programowej oraz wdrożenie usługi
pozwalającej na udostępnianie w jednostkach medycznych (warstwa lokalna systemu MSIM)
w jednym miejscu (moduł wymiany danych) dokumentacji medycznej z różnych systemów
dziedzinowychfunkcjonujących w tych jednostkach(ewentualna wymiana danych z systemami
RIS. LIS, PACS i innych będzie się odbywać za pośrednictwem HIS).. Rozwiązanie będzie
zbudowane w architekturze rozproszonej – moduł wymiany zostanie zaimplementowany w
każdej jednostce medycznej uczestniczącej w projekcie (w szczególności może być
zrealizowany przez lokalny EDM dostarczony w ramach projektu). Szczególowa koncepcja
mumodułu w zostanie określona na etapie Analizy przedwdrożeniowej. Komunikacja
pomiędzy modułami,a także dostęp do dokumentacji medycznej będzie realizowany za
pomocą usług uruchomionych na platformie integującej w warstwie regionalnej systemu
MSIM.

Wdrożenie platformy integrującej wymianę elektronicznej dokumentacji medycznej na
poziomie regionalnym
Wymaga się stworzenia platformy integrującej (warstwa regionalna systemu MSIM)
z wykorzystaniem technologii szyny danych oraz interfejsów integracyjnych, która zapewni
komunikację i wymianę dokumentacji medycznej pomiędzy jednostkami medycznymi
w regionie a także umożliwi dostęp do dokumentacji dla pacjenta. W ramach tego elementu
ma zostać zrealizowane dostarczenie infrastruktury sprzętowej i programowej oraz wdrożenie
usług umożliwiających wyszukiwanie, prezentację oraz wymianę/udostępnianie dokumentacji
medycznej. Platforma ta zostanie zintegrowana z projektem P1 w zakresie indeksowania
Strona 11 z 161
i udostępniania dokumentacji medycznej zamawianej przez pacjenta za pomocą IKP.
Wymiana dokumentacji medycznej w ramach platformy integracyjnej będzie realizowana
zgodne z przyjętymi standardowymi protokołami w ochronie zdrowia (HL7 CDA R2 na
poziomie 3-cim interoperacyjności, DICOM, XML i PDF zgodne z Rozporządzeniem Ministra
Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz
sposobu jej przetwarzania) w zakresie przekazywanym do lokalnych EDM przez systemy HIS.

Wdrożenie elektronicznych usług medycznych
Zakłada się uruchomienie elektronicznych usług dostępnych w warstwie regionalnej systemu
MSIM:
1.
Wyszukiwanie dokumentacji medycznej pacjenta:
Usługa dostępna dla personelu medycznego będzie umożliwiać wyszukanie
dokumentacji pacjenta wg określonych kryteriów takich jak dane pacjenta, rodzaju usługi
medycznej, data czy jednostka medyczna. Wynik wyszukiwania będzie miał postać listy
z możliwością jej pogrupowanej wg określonych kryteriów takich jak jednostka
medyczna, rodzaj usługi medycznej czy data wykonania usługi.
2.
Wymiana oraz
medycznymi:
udostępnianie
dokumentacji
medycznej
pomiędzy
jednostkami
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:



3.
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ść)
Udostępnianie dokumentacji medycznej pacjentowi (w tym wyników badań):
Usługa będzie umożliwiać pobranie przez pacjenta dokumentacji medycznej
zgromadzonej w jednostkach medycznych uczestniczących w projekcie. W ramach
wdrożenia usługi zostanie wykonana integracja z Elektroniczną Platformą Gromadzenia,
Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (projekt P1)
w zakresie Internetowego Konta Pacjenta (IKP), funkcjonującego w ramach platformy
P1, dzięki któremu pacjent będzie miał możliwość zamawiania dokumentacji medycznej.
Wskazana przez pacjenta dokumentacja będzie udostępniana z poziomu systemu
MSIM. Integracja z IKP będzie obejmować zestawienie szyfrowanego połączenia
pozwalającego na udostępnianie/przesyłanie EDM, którą zamówił pacjent (w IKP
pacjent powinien otrzymać informację o sposobie udostępnienia dokumentacji, np. link
do udostępnionej dokumentacji znajdującej się w EDM w warstwie lokalnej MSIM).
Strona 12 z 161
W ramach usługi realizowany będzie scenariusz:
4.
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ą.
Elektroniczna rejestracja pacjentów (e-Rejestracja)
Szczególną usługą realizowaną w ramach komponentu regionalnego jest usługa
e-Rejestracji. Usługa e-Rejestracji udostępnia funkcjonalność rezerwacji usług
medycznych w jednostkach ochrony zdrowia zintegrowanych z MSIM. Użytkownik ma
możliwość rejestracji na wskazany termin i anulowania wizyty. Z e-Rejestracji mogą
korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi
(pacjenci). W ramach usługi powinien funkcjonować system komunikatów
(powiadomień dla użytkowników końcowych w formie np. wiadomości e-mail i SMS)
dotyczących: potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania
wizyty oraz zmiany terminu wizyty (zarówno przez użytkownika jak i w lokalnym
systemie medycznym HIS). W szczególności usługa obejmuje następujące
funkcjonalności:
 Rejestrację terminu wizyty
 Anulowanie terminu wizyty
 Przeglądanie terminów (przyszłych aktywnych, przyszłych zarejestrowanych,
przyszłych anulowanych i historycznych)
 Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail)
5.
Portal Informacyjny e-Zdrowie.
Portal
będzie
miał
postać
aplikacji
webowej
prezentującej
informację
o projekcie, świadczonych usługach, uczestniczących partnerach. Na portalu będą
udostępniane:

Informacje o jednostkach ochrony zdrowia, które są zintegrowane z MSIM
w ramach projektu (w tym lista usług świadczony przez te podmioty),

Wyszukiwarka usług medycznych (wg typu usługi oraz wg jednostki ochrony
zdrowia),

Dane kontaktowe do jednostek ochrony zdrowia (tel. do placówki, poszczególnych
specjalistów, informacji, rejestracji

Informacje nt. możliwości skorzystania z e-rejestracji (wraz z krótkim instruktażem
jak
z korzystać
z rozwiązania
na
portalu
oraz charakterystyka
e-usługi –– FAQ),

Funkcjonalność umożliwiająca rejestrację oraz założenie konta,

Informacje o projekcie MSIM.
Ponadto w ramach wdrożenia systemu MSIM dostępne będą:

Mobilna wersja portalu informacyjnego e-Zdrowie.
Strona 13 z 161

Usługa podpisu elektronicznego dla EDM.
UsługapodpisuelektronicznegodlaEDMbędzieobsługiwaćfunkcjepodpisywania
i weryfikacji podpisu elektronicznego z wykorzystaniem Centrum Autoryzacji (CAPE w
Małopolsce). Centrum CAPE będzie wykorzystywane w zakresie:
a.) wydawania certyfikatów elektronicznych do podpisywania (przyjmowanie wniosku
o certyfikat w postaci pliku PKCS#10 i udostępnianie wygenerowanego certyfikatu)
b.) znakowania czasem (usługa znakowania czasem zgodna ze standardem RFC
3161.

Usługa Single Sign-On (SSO) spełniająca następujące wymagania:
a.) System powinien zapewnić funkcjonalność pojedynczego uwierzytelniania
użytkowników w obrębie dostarczanej platformy oraz dostarczanych aplikacji
dziedzinowych
b.) System powinien zapewnić interfejs API umożliwiający podłączenie do systemu
SSO zewnętrznych aplikacji dziedzinowych. Prace integracyjne po stronie
zewnętrznych aplikacji dziedzinowych nie są objęte niniejszym postępowaniem
c.) Uwierzytelnianie użytkowników musi być realizowane na podstawie jednoznacznie
przydzielonego loginu oraz hasła użytkownika.

Serwer mailowy na potrzeby powiadomień MSIM
Wszystkie realizowane przez System MSIM usługi elektroniczne będą dostępne przy pomocy
dedykowanych interfejsów dostępu jako API dla systemów informatycznych jak iw trybie graficznym
dla użytkowników portalu.

Zapewnienie interoperacyjności
Rozwiązanie ma opierać się założenie przekazywania pomiędzy podmiotami elektronicznej
dokumentacji medycznej w ustandaryzowanym formacie możliwym do odczytania
w dowolnej lokalizacji. Elementem odpowiedzialnym za przekazywanie dokumentacji medycznej
wraz z zapewnieniem prawidłowego uwierzytelnienia użytkowników będzie warstwa regionalna, co
uniezależnia rozwiązanie od poszczególnych podmiotów. Rozwiązanie takie pozwala na
wzajemny dostęp uprawnionych użytkowników z wszystkich podmiotów dołączonych do MSIM do
wszystkich wytwarzanych w formie elektronicznej dokumentów medycznych dostępnych
w ramach MSIM. W celu zapewnienia bezpieczeństwa przesyłu danych zakłada się zestawienie
bezpiecznego, bezpośredniego i szyfrowanego połączenia pomiędzy jednostkami medycznymi.
Połączenie VPN będzie charakteryzować się dużą efektywnością oraz zapewni wysoki poziom
bezpieczeństwa.
2.2.2.Wymagania ogólne dla systemu MSIM
1.
System MSIM ma umożliwić wymianę EDM pomiędzy jednostkami ochrony zdrowia
zintegrowanymi z MSIM.
2.
System MSIM ma umożliwić wymianę dokumentacji medycznej w ramach e-Usług
pomiędzy jednostkami ochrony zdrowia zintegrowanymi z MSIM.
3.
Wymiana dokumentacji medycznej ma być realizowana z wykorzystaniem technologii
szyny danych oraz interfejsów integracyjnych.
Strona 14 z 161
4.
5.
6.
7.
System MSIM musi być przygotowany na integrację z lokalnymi systemami
dziedzinowymi w ramach interfejsów zgodnych ze standardem opisanym w Załączniku
9A.:
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.
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.
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.
2.
3.
Kierownik Projektu ze strony Zamawiającego,
Kierownik Projektu ze strony Wykonawcy,
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.
2.
3.
Przewodniczący – przedstawiciel Zamawiającego,
Główny Dostawca – przedstawiciel Wykonawcy,
Główny Odbiorca – przedstawiciel Zamawiającego.
Każda z tych ról ma prawo powołać swoich specjalistów dziedzinowych odpowiadających za
operacyjną realizację projektu. Szczegółowe zadania i kompetencje Komitetu Sterującego zostaną
szczegółowo opisane w Planie Wdrożenia Projektu.
W ramach procesu Wdrożenia zaplanowano, iż nastąpią po sobie chronologicznie następujące
działania:
1
Przygotowanie Analizy przedwdrożeniowej Systemu MSIM
Pierwszym zadaniem do wykonania w ramach procesu wdrożenia jest opracowanie przez
Wykonawcę w porozumieniu z Zamawiającym Analizy przedwdrożeniowej MSIM.
Dokument ten stanowić będzie bazowy zapis opisujący budowany System MSIM. Na podstawie
zapisów w tym dokumencie będą prowadzone i odbierane poszczególne zadania realizowane
przy budowie Systemu MSIM.
Strona 15 z 161
Dokument ten wraz z SIWZ będą stanowiły podstawę do weryfikacji funkcjonalnej i jakościowej
Systemu MSIM w trakcie odbiorów.
2
Dostawa instalacja i konfiguracja infrastruktury Sieciowej
Dostawa instalacja i konfiguracja infrastruktury sieciowej jest zadaniem mającym na celu budowę
lub modernizację pasywnego sprzętu sieciowego oraz dostawę, instalację i konfigurację
aktywnego sprzętu sieciowego do wskazanych lokalizacji według przygotowanego przez
Wykonawcę wspólnie z Zamawiającym harmonogramu w porozumieniu z Partnerami Projektu.
Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało
to z bieżącą pracą Partnerów Projektu. Harmonogram musi być przedstawiony jako diagram
Gantta, który obejmuje zadania wraz z ich następnikami, datę rozpoczęcia, datę zakończenia
zadania, czas trwania (liczony w dniach roboczych), podmiot odpowiedzialny za realizację
zadania, % postęp w realizacji zadania.
Wymagania w zakresie organizacji prac instalacyjnych:
3
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.
Dostawa instalacja i konfiguracja infrastruktury sprzętowej
Dostawa instalacja i konfiguracja infrastruktury sprzętowej jest zadaniem mającym na celu
dostarczenie zamawianego sprzętu do wskazanych lokalizacji według przygotowanego przez
Wykonawcę wspólnie z Zamawiającym harmonogramu w porozumieniu z Partnerami Projektu.
Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało
to z bieżącą pracą Partnerów Projektu.
Wymagania w zakresie logistyki dostaw:
a)
Wykonawca ma zapewnić wniesienie dostarczonego sprzętu do miejsca (pomieszczenia) u
Partnera Projektu oraz w lokalizacji warstwy regionalnej MSIM.
b)
Wykonawca będzie dostarczał sprzęt sukcesywnie w terminie bezpośrednio poprzedzającym
jego instalację i w sposób dopasowany do możliwości logistycznych zamawiającego i
Partnerów Projektu. Zakres i wielkości dostaw należy każdorazowo uzgodnić z
Zamawiającym.
c)
Za przechowywanie narzędzi i materiałów (w tym infrastruktury sprzętowej) w miejscu
instalacji odpowiada Wykonawca. Wykonawca zobowiązany jest zagwarantować
przechowywanie materiałów zgodnie z wymaganiami producenta.
Strona 16 z 161
d)
4
Za infrastrukturę sprzętową zapewnianą w ramach realizacji przedmiotu zamówienia do
czasu podpisania protokołu odbioru odpowiada Wykonawca.
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 eUsług w zakresie synchronizacji i wymiany danych pomiędzy warstwą regionalną MSIM, a
warstwami lokalnymi Partnerów Projektu.
7
Testy
Celem przeprowadzenia testów jest weryfikacja przez Zamawiającego, czy wszystkie prace
wykonane w trakcie budowania Systemu MSIM zostały wykonane prawidłowo i zgodnie z
założeniami funkcjonalnymi i jakościowymi. Testy będą przeprowadzane zarówno przez
pracowników Partnerów Projektów jak i wskazanych przez Zamawiającego osób i podmiotów
zewnętrznych.
W celu przeprowadzenia testów Wykonawca przygotuje kompletne środowisko testowe oraz
scenariusze testowe.
Pozytywne zakończenie testów wraz z usunięciem wskazanych wad jest niezbędne aby dla
poszczególnych komponentów oraz Systemu MSIM dokonać odbiorów w ramach poszczególnych
etapów oraz odbioru końcowego.
8
Odbiór końcowy
Zadanie to ma na celu potwierdzenie wykonanie wszystkich zadań wynikających z Projektu, w tym
odebrania wszystkich Komponentów i etapów Projektu oraz dostarczenia wszystkich wymaganych
w zamówieniu dokumentów. Dokonanie odbioru końcowego zakończy prace przy budowie
Systemu MSIM i będzie podstawą do przekazania Systemu MSIM do użytkowania produkcyjnego.
Strona 17 z 161
Wykonawca ma przekazać protokoły odbioru końcowego z rozpisaniem na składowe będące
elementami całego systemu MSIM w uzgodnieniu z Zamawiającym.
2.4. Dyslokacja elementów systemu
Lista lokalizacji, w których należy zainstalować elementy systemu
1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
2. Szpital Specjalistyczny im. J. Dietla w Krakowie
3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o.(gdzie zlokalizowane są
dwie serwerownie do których dostarczona zostanie infrastruktura zamawiana w ramach
MSIM)
Ponadto Projekt musi umożliwiać przyłączenie do niego w dalszym okresie kolejnych jednostek
ochrony zdrowia.
Zgodnie z podziałem funkcjonalnym System składa się z komponentu regionalnego oraz komponentu
lokalnego.
Komponent lokalny umieszony zostanie w następujących lokalizacjach:
1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
2. Szpital Specjalistyczny im. J. Dietla w Krakowie
3. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o.
Komponent regionalny umieszony zostanie w lokalizacji:
1. Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o.
Lista lokalizacji jest aktualna na dzień 6.10.2014.
Strona 18 z 161
Cała komunikacja mająca na celu przekazanie dokumentacji ze Szpitala występującego
o dokumentację do szpitala udostępniającego dokumentację jest realizowana za pośrednictwem
warstwy regionalnej MSIM.
Rysunek 5. Koncepcja komunikacji w MSIM.
2.5. Zasady budowy reguł interoperacyjności w systemie
Zakres i znaczenie metadanych EDM oraz schematów atomowych dla repozytorium EDM i rejestru
EDM powinien być zgodny z wytycznymi profilu integracyjnego XDS.b, a w szczególności z tabelą
4.3.1.1-3 dokumentu „IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): CrossTransaction
and
Content
Specifications”
(dostępny
na
stronie:
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf).
Nie ma potrzeby tworzenia formularzy elektronicznych w zakresie przekazywania EDM, ponieważ
odbywa się ona w całości z wykorzystaniem usług sieciowych i interakcji pomiędzy systemami.
2.6. Koncepcja synchronizacji czasu – normalizacji czasu
Synchronizacja i znakowanie czasem elektronicznej dokumentacji medycznej następuje
w oparciu o usługę znakowania czasem (TSS – Time Stamping Service). Usługa znakowania czasem
powinna być świadczona centralnie, co w przypadku systemu MSIM oznacza, że usługa będzie
świadczona przez komponent regionalny rozwiązania, jako jedna ze wspólnych usług
infrastrukturalnych.
Strona 19 z 161
Algorytm znakowania czasem powinien być oparty o przesyłanie skrótów dokumentów do usługi
(serwera znakowania czasem) i znakowaniu wyłącznie skrótów dokumentów.
Architektura takiego rozwiązania implikuje w warstwie regionalnej istnienie 2 usług infrastrukturalnych:


Usługa znakowania czasem
Usługa weryfikacji znaku czasu
System powinien wykorzystywać usługę znacznika czasu realizowaną przez Centrum Autoryzacji
(CAPE w Małopolsce)), przez zastosowanie funkcjonującej obecnie w Centrum aplikacji PentaSCAPETSA Service. Aktualna wydajność usługi powinna być wystarczająca do planowej skali systemu.
Certyfikaty, listy CRL oraz inne dane przechowywane przez Centrum Certyfikacji znakowane są
wiarygodnym czasem pochodzącym z wzorcowego zaufanego serwera czasu.
Usługa znakowania czasem musi posiadać wydajność na poziomie oferowanym przez CAPE
w Małopolsce.
2.7. Koncepcja autentykacji i identyfikacji użytkowników
Identyfikacja, uwierzytelnianie i autoryzacja użytkowników (osób oraz systemów) powinna być oparta
o mechanizm scentralizowany, który logicznie wydziela 2 warstwy:


Identity provider (dostawca tożsamości) pełniący funkcję weryfikującą – funkcja powinna być
dostępna z poziomu komponentu regionalnego jak wspólna usługa infrastrukturalna.
Klientów usługi, którzy potrzebuję rzetelnej i aktualnej informacji o tożsamości uczestników
komunikacji – funkcja ta będzie wykorzystywana głównie przez komponent lokalny.
Rozwiązanie powinno być oparte o jeden wspólny serwer certyfikacyjny, każdy użytkownik będzie miał
klucz/token weryfikowany przez serwer certyfikacji. Zakłada się wykorzystanie działającego Centrum
Autoryzacji podpisu elektronicznego w ramach Urzędu Marszałkowskiego(CAPE w Małopolsce).
Usługa uwierzytelniania powinna być oparta o mechanizm jednokrotnego logowania (ang. Single Sign
On – SSO) w obrębie aplikacji wytworzonych w ramach projektu. W ramach MSIM powstanie usługa
pozwalająca poszczególnym HIS-om wykorzystanie tego mechanizmu w ramach poszczególnych
instalacji. Kwestia zaimplementowania SSO w ramach poszczególnych HIS jest elementem
odrębnego zamówienia udzielonego wykonawcom HIS.
Na potrzeby usługi e-Rejestracja wymagane będzie utworzenie niezależnego repozytorium
tożsamości dla Pacjentów, którzy będą chcieli korzystać z funkcjonalności rezerwowania wizyt
w placówce medycznej.
Konta tych pacjentów a w konsekwencji ich dane osobowe muszą być zabezpieczone mechanizmami
odpowiadającymi poziomowi wysokiemu zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych
i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych
oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy
informatyczne służące do przetwarzania danych osobowych
W celu zapewnienia bezpieczeństwa danych osobowych dla potwierdzenia rejestracji wymagana
będzie wizyta w placówce z wydrukowanym formularzem rejestracji celem potwierdzenia danych
osobowych i otrzymania hasła pierwszego logowania.
Strona 20 z 161
2.8. Koncepcja współpracy z Internetowym Kontem Pacjenta (IKP)
W celu zapewnienia wymiany informacji pomiędzy usługodawcami, a platformą P1 zostały wybrane
standardy komunikacji, które sprawią, że proces ten będzie mógł przebiegać w sposób zunifikowany.
Z uwagi na interoperacyjność oraz wytyczne CSIOZ wybrany został standard IHE XDS.b, który
gwarantuje obsługę wymaganych procesów w warunkach polskiej ochrony zdrowia, jak również
komunikację międzynarodową.
Platforma P1 wykorzystuje dwa główne profile IHE w celu komunikacji między systemami:
 IHE XDS.b - wykorzystywany do wymiany informacji o dokumentach medycznych
(rozszerzona o informacje o zdarzeniu medycznym, w ramach którego dokumentacja ta
powstała),
 IHE XDM - wykorzystywany do importu do P1 dokumentów z placówek likwidowanych.
Platforma P1 wykorzystuje również standard:
 HL7 CDA R2 na 3-cim poziomie interoperacyjności- w zakresie transferu nie obrazowych
danych medycznych,
 DICOM – w zakresie gromadzenia i przekazywania informacji o miejscu przechowywania
danych obrazowych.
Współpraca z platformą P1 odbywać się będzie za pomocą wymiany komunikatów w postaci plików
XML (standard XML Schema). System zapewni wsparcie dla standardu przesyłania komunikatów
SOAP (w wersji co najmniej 1.1) z załącznikami. Do opisu struktury i semantyki serwisu sieciowego
(webservices) zostanie wykorzystany standard WSDL (wersja co najmniej 1.1). Każdy dokument
wysyłany do platformy P1 będzie podlegał regułom walidacyjnym przypisanym do konkretnego
dokumentu. Reguły walidacyjne przypisane do dokumentu nadrzędnego mają zastosowanie do
obiektów powiązanych podrzędnych.
System zapewni możliwość zabezpieczania wysyłanych komunikatów zgodnie ze specyfikacją WS
Security (OASIS Standard 1.1) oraz wykorzystania modelu X.509 Token Profile 1.1.
System zapewni możliwość wysyłania komunikatów obsługiwanych przez system centralny zgodnie ze
wskazaną w niniejszej SIWZ dokumentacją projektu P1.
Zgodnie z założeniami Internetowe Konto Pacjenta umożliwiać będzie gromadzenie w jednym miejscu
wszystkich informacji dotyczących stanu zdrowia pacjenta. Szybki dostęp do systemu będzie wspierać
lekarza przy podejmowaniu optymalnych decyzji i wzmacnia skuteczność leczenia. Pacjentowi
natomiast, zapewnia możliwość zarządzania własną dokumentacją medyczną, w szczególności
umożliwi łatwy i szybki dostęp do skierowań, recept czy zaświadczeń.
Stan prac nad wdrożeniem IKP wygląda następująco:


Prototyp Internetowego Konta Pacjenta został wdrożony w 2011 roku i objął pacjentów
chorych na cukrzycę w wieku od 18 lat leczących się w Krakowie.
W lutym 2014 zakończono realizację Projektu Zintegrowanych prototypów Internetowego
Konta Pacjenta oraz e-Recepty. System przetestowano w trzech miastach – Gdańsku,
Olsztynie i Warszawie.
Wykonawca systemu MSIM musi przewidzieć w ramach usługi wykonanie wymiany komunikatów,
które pomiędzy MSIM, a Systemem P1 zgodnie z regułami tworzenia ww. elektronicznych
dokumentów medycznych, które zostały opublikowane na stronach CSIOZ – odnośniki do tych
dokumentów znajdują się w niniejszej SIWZ.
Wdrożony system MSIM musi być otwarty na system P1 w zakresie IKP ze względu na poniższe
warunki:

Istnienie jednego, centralnego rejestru EDM w warstwie regionalnej obejmującego całą EDM
w Podmiotach objętych Projektem, a w konsekwencji posiadaniu zintegrowanej informacji
o całej EDM.
Strona 21 z 161

Rejestr EDM zgodnie z wytycznymi będzie realizowany na podstawie standardów
komunikacji, również w zakresie e-zdrowia, które nie są cechą szczególną koncepcji, lecz
powszechnie uznanym standardem komunikacji w podobnych rozwiązaniach. Wykorzystanie
standardowego interfejsu komunikacji przez rejestr EDM oznacza, że integracja z każdym
klientem rejestru powinna być maksymalnie uproszczona.
Współpraca z CSIOZ w ramach systemu P1 w zakresie IKP odbywać się powinna na poziomie
aplikacji pozwalającej na dostęp do konta pacjenta, w której będzie on miał możliwość zamawiania
dokumentacji medycznej, która będzie następnie udostępniana/przesyłana za pomocą usługi
dostępnej w warstwie regionalnej systemu MSIM. Integracja z P1 w zakresie IKP będzie obejmować
zestawienie szyfrowanego połączenia pozwalającego na udostępnianie/przesyłanie danych
medycznych, które zamówił pacjent. W ramach usługi realizowany będzie scenariusz:





pacjent w IKP wyszukuje w wykazie interesującą go dokumentację medyczną (na podstawie
indeksu zlokalizowanego w warstwie regionalnej),
za pomocą usługi dostępnej w P1 pacjent zamawia interesująca go dokumentację medyczną,
zlecenie zostaje przekazane do placówki, która udostępnia wskazaną dokumentację,
placówka udostępnia zamówioną dokumentację medyczną,
pacjent pobiera zamówioną dokumentację medyczną.
W ramach integracji z CSIOZ należy zapewnić możliwość:


przekazania tożsamości pacjenta do systemu MSIM, tak aby pacjent mógł wykorzystać usługę
wyszukiwania i pobierania EDM,
przekazywania zgód pacjentów na udostępnianie dokumentacji medycznej.
Przekazywanie tożsamości pomiędzy Systemem MSIM, a Platformą P1 musi spełniać wszystkie
wymagania prawne związane z anonimizacją danych Pacjentów.
W zakresie zamówienia jest dostosowywanie MSIM do aktualnych wytycznych CSIOZ w zakresie
platformy P1 przez okres wskazany w ofercie lecz nie mniej niż 5 lat od daty odbioru końcowego
systemu, w tym uzyskiwanie wszystkich wymaganych certyfikacji.
2.9. Koncepcja przesyłania dokumentacji o dużej pojemności
W przypadku dokumentacji medycznej głównym elementem wytwarzającym dane o dużej pojemności
są dane obrazowe. W związku z czym System musi mieć możliwość 3-poziomowego wyboru zakresu
pobieranej dokumentacji medycznej. Takie rozwiązanie pozwala na ograniczenie ruchu i nie
obciążanie łączy bez uzasadnienia. Uwierzytelniony użytkownik będzie mógł skorzystać
z następujących wariantów zamówienia/pobrania dokumentacji:



Podstawowa dokumentacja medyczna (dokumentacja zewnętrzna: karta informacyjna, karta
porady specjalistycznej, karta informacyjna SOR),
Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza
objętość),
Pełna dokumentacja medyczna z konkretnej hospitalizacji/wizyty z danymi obrazowymi
w jakości diagnostycznej (duża objętość).
Przesył pełnej dokumentacji medycznej z danymi obrazowymi w jakości diagnostycznej o dużej
objętości będzie wspomagany poprze mechanizm dynamicznego przydzielana przepustowości łącza,
dający wyższy priorytet dla bieżącej obsługi jednostki szpitalnej, a niższy dla wymiany dokumentacji.
Stworzenie mechanizmu przesyłu danych o dużej objętości (dane obrazowe) ma być funkcjonalnością
zaimplementowaną w MSIM. Dostęp do danych obrazowych będzie zrealizowany:
Strona 22 z 161


za pomocą interfejsu opracowanego przez Wykonawcę MSIM, do którego będą dołączane
poszczególne PACS-y. Zadaniem Wykonawcy MSIM jest w tym przypadku stworzenie
WebServisów, za pomocą, których będzie możliwa wymiana danych obrazowych (w formacie
DICOM). Integracja MSIM z poszczególnymi systemami PACS nie jest elementem
niniejszego zamówienia.
Przez interfejs z systemem HIS (opisanym w załączniku 9A do SIWZ). Zadaniem Wykonawcy
MSIM jest zapewnienie dostępu do danych obrazowych w przypadku gdy PACS jest
bezpośrednio zintegrowany z HIS (sytuacja taka ma miejsce w Szpitalu im. Ludwika
Rydygiera).
2.10. Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych
jednostek
W ramach koncepcji rozwoju systemu przewiduje się:
1. Zdefiniowanie i udostępnienie standardów warstwy integracji, w którego skład wchodzi
m. in. interfejs integracji regionalnej odpowiedzialny za wymianę danych, umożliwiający
komunikację elektroniczną pomiędzy regionem a lokalnymi systemami informatycznymi
(standardy zapytań, struktur baz danych) – Wykonawca przygotuje taki dokument na
etapie realizacji projektu.
2. Rozwój na poziomie warstwy regionalnej e-Usług dostarczanych wszystkim obywatelom,
usługi integrujące działania jednostek służby zdrowia i usługi dedykowane organom
działającym na poziomie regionalnym i ponadregionalnym– do realizacji w ramach
kolejnych projektów.
3. System zarządczy dla Województwa Małopolskiego – w zakresie przewidzianym OPZ,
4. Integracja z pozostałymi systemami regionalnymi w dziedzinie e-Zdrowia,
w tym systemami i usługami wytwarzanymi w ramach projektów CSIOZ oraz innych
platform regionalnych, np. PSIM (Podkarpacki System Informacji Medycznej)– w tym
zakresie wymagane jest zagwarantowanie integracji z w ramach zaleceń CSIOZ w
okresie gwarancji.
Architektura warstwy regionalnej ma zapewniać łatwą modyfikowalność systemu w przyszłości.
Modyfikowalność systemu jest rozumiana jako co najmniej:
 Podłączanie nowych jednostek do systemu poprzez konfiguracje
 Rozszerzanie zakresu wymienianych danych poprzez konfiguracje
 Rozszerzanie funkcjonalności poprzez podłączanie dodatkowych modułów
W tym zakresie Wykonawca przygotuje standardy integracji.
2.11. Schemat połączeń pomiędzy elementami systemu
Sekcja przedstawia schemat połączeń pomiędzy elementami systemu, w tym połączeń sieciowych.
Sieć
Sieć połączeń pomiędzy poszczególnym uczestnikami projektu musi zostać zbudowana
z wykorzystaniem posiadanego przez uczestników projektu łącza internetowego. W ramach publicznej
sieci Internet zostanie zbudowana dedykowana sieć VPN, która połączy wszystkich uczestników
projektu. W związku z tym, dane nie mogą być przesyłane w postaci jawnej lecz należy je szyfrować.
Zakłada się w tym celu wykorzystanie mechanizmu IPsec (Internet Protocol Security), dzięki któremu
urządzenia tworzą tzw. tunele IPsec. Dane przed wyjściem do Internetu są szyfrowane przez
brzegowe urządzenie UTM znajdujące się w Szpitalu. Natomiast na końcu tunelu dane są
odszyfrowywane przez brzegowe urządzenie UTM znajdujące się w lokalizacji regionalnej. W sytuacji
przesyłania danych z Regionu do Szpitali kolejność szyfrowania będzie odwrotna.
Strona 23 z 161
Takie tunele będę na stałe zestawione pomiędzy poszczególnymi Szpitalami, a Regionem. Układ ten
przedstawia poniższy rysunek.
Rysunek 6:Schemat połączeń VPN (źródło: opracowanie własne)
Dzięki temu, wszystkie dane przechodzące przez Internet są bezpieczne. Również pracownicy zdalni
mogą łączyć się do sieci firmowej poprzez tunel IPsec, umożliwia to bezpiecznie korzystanie
z zasobów sieci firmowej np. z domu. W tym przypadku sieć VPN ma strukturę gwiazdy.
Na poniższym rysunku został przedstawiony schemat połączeń infrastruktury sprzętowej dla projektu
MSIM.
W warstwie technicznej schemat połączeń pomiędzy elementami systemu oparty jest o następujące
typy połączeń:



Tunele VPN szyfrowane protokołem SSL pomiędzy warstwą regionalną a poszczególnymi
komponentami lokalnymi,
Łącze Ethernet 1Gb w zakresie sieci LAN,
Połączenia z wykorzystaniem protokołu FC dla sieci SAN pomiędzy macierzami a serwerami.
Strona 24 z 161
Szpital lokalny 3
Rysunek 7. Schemat połączeń pomiędzy elementami systemu
Rysunek 8.Schemat połączeń infrastruktury sprzętowej w lokalizacji Regionalnej.
Strona 26 z 161
Rysunek 9.Schemat połączeń infrastruktury sprzętowej w lokalizacji Lokalnej.
2.12. Interfejsy komunikacyjne z innymi systemami informatycznymi
System MSIM wykorzystuje następujące zewnętrzne interfejsy:

System HIS, gdzie zakres i tryb wymiany danych określony jest interfejsem ITI-41



Lokalny systemu lub moduł e-Rejestracji, gdzie zakres i tryb integracja określony jest definicją
procesów biznesowych z grupy e-Rejestracji (rozdział 2)
P1 (IKP), gdzie zakres i tryb wymiany danych określony jest interfejsem właściwym dla
klientów rejestru i repozytorium EDM
Centrum Autoryzacji podpisu elektronicznego w Małopolsce(CAPE w Małopolsce), gdzie
zakres i tryb integracji musi odpowiadać wymaganej funkcjonalności usługi podpisu
elektronicznego dla EDM
Wytyczne dla komunikacji z platformą P1:



Komunikacja z platformą P1 następuje w oparciu o reguły tworzenia Elektronicznej
Dokumentacji Medycznej i model transportowy danych o Zdarzeniach Medycznych oraz
Indeksie EDM, gdzie platforma P1 jest rejestrem EDM
Komunikat przekazania informacji o zdarzeniu medycznym jest inicjowany przez komponent
regionalny, który przekazuje komunikat do platformy P1 analogicznie do zdarzenia rejestracji
EDM przekazywanego przez komponent lokalny do komponentu regionalnego
System dziedzinowy musi wytworzyć a komponent regionalny musi przygotować komunikat
do platformy P1 zgodnie z ostatnią aktualną wersją wytycznych dostępnych na stronach
CSIOZ
Wykonawca jest zobowiązany do przygotowania opisu interfejsów, ich wykonania i przetestowania na
zasadach odrębności w stosunku do pozostałych funkcji systemu MSIM (interfejsy można testować
w oderwaniu od samego systemu).
2.13. Koncepcja komunikacji pomiędzy jednostkami
Cała komunikacja mająca na celu przekazanie dokumentacji ze Szpitala występującego
o dokumentację do szpitala udostępniającego dokumentację jest realizowana za pośrednictwem
warstwy regionalnej MSIM.
Strona 28 z 161
Rysunek 10.Schemat koncepcji komunikacji
Takie rozwiązanie pozwala na zachowanie wysokiego poziomu bezpieczeństwa przez ustanowienie
tylko jednego kanału komunikacji pomiędzy szpitalem, a warstwą regionalna, przez który
przeprowadzony jest cały proces komunikacji.
Strona 29 z 161
2.14. Koncepcja przesyłu danych pomiędzy jednostkami
Proces udostępnienia dokumentu zilustrowany został na poniższym rysunku:
Rysunek 11. Schemat procesu udostępniania dokumentu
W ramach systemu MSIM przesył danych pomiędzy jednostkami powinien być realizowany
w przypadku udostępniania dokumentacji medycznej. Scenariusz udostępniania dokumentacji
medycznej jest następujący:
1. Użytkownik za pomocą aplikacji typu klient wyszukuje dokument pacjenta w rejestrze na
podstawie metadanych.
2. System regionalny sprawdza uprawnienia użytkownika.
3. Repozytorium Regionalne kontaktuje się z repozytorium jednostki w którym przechowywana
jest dokumentacja.
4. Dokumentacja wysyłana jest z repozytorium, w którym weryfikowana jest jej poprawność.
5. Dokumentacja wysyłana jest z warstwy regionalnej MSIM do użytkownika.
6. Po potwierdzeniu przesłania dokumentacji do Użytkownika, w warstwie regionalnej zostaje
odnotowany fakt udostępnienia Elektronicznej Dokumentacji Medycznej zawierający co
najmniej dane o: użytkowniku, dacie, czasie udostępnienia, wersji przekazanych
dokumentów).
Strona 30 z 161
2.15. Integracja systemów oraz danych z innych systemów do wdrażanego
systemu MSIM
System MSIM wykorzystuje następujące zewnętrzne interfejsy i w takim zakresie musi być
zintegrowany z systemami zewnętrznymi udostępniającymi lub wykorzystującymi interfejsy:




System HIS, gdzie zakres i tryb wymiany danych określony jest interfejsem ITI-41
Lokalny systemu lub moduł e-Rejestracji, gdzie zakres i tryb integracja określony jest definicją
procesów biznesowych z grupy e-Rejestracji (rozdział 2)
P1, gdzie zakres i tryb wymiany danych określony jest interfejsem właściwym dla klientów
rejestru i repozytorium EDM, tj. ITI-18 i ITI-43
Centrum Autoryzacji podpisu elektronicznego w Małopolsce, gdzie zakres i tryb integracji musi
odpowiadać wymaganej funkcjonalności usługi podpisu elektronicznego dla EDM.
2.16. Koncepcja wirtualizacji zasobów informatycznych
Wymagana jest dostawa oprogramowania do wirtualizacji z licencjami wystarczającymi dla
uruchomienia na dostarczonym sprzęcie 40 serwerów wirtualnych.
Wykonawca musi opracować i uzgodnić z Zamawiającym plan wirtualizacji zasobów obejmujących
zakres, tryb i konfigurację zasobów wirtualizowanych biorąc pod uwagę charakterystykę Systemu
MSIM, zasady wirtualizacji poszczególnych Partnerów oraz przesłanki wydajnościowe
i bezpieczeństwa.
Wymagania na oprogramowanie do wirtualizacji przedstawiono w sekcji z oprogramowaniem
standardowym (infrastruktura).
3. Analiza stanu aktualnego
3.1. Infrastruktura informatyczna
3.1.1.Serwerownia
3.1.1.1.
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
L.P.
1.
Parametr
Serwerownia 1
Serwerownia 2
Serwerownia 3
Adres
33-300
Nowy
Sącz, Młyńska
10
33-300
Nowy
Sącz, Młyńska
10
33-300
Nowy
Sącz, Młyńska 10
2.
Lokalizacja w budynku
3.
4.
5.
Powierzchnia użytkowa [m ] /wysokość [m]
Czy jest wolne miejsce na dodatkową szafę
Ilość szaf RACK/Ilość wolnego miejsca [U]
ZABEZPIECZENIA FIZYCZNE
33-300
Nowy
Sącz, Młyńska
5,
Budynek
główny
10/2,98
Tak
1/5
33-300
Nowy
Sącz, Młyńska
5,
Budynek
główny - RTG
8/2,54
Tak
1/0
33-300
Nowy
Sącz,
Młyńska
5,Budynek
onkologiczny
6/2,96
Tak
3/5
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
System alarmowy
Monitoring video
Kontrola dostępu
Ochrona fizyczna
Drzwi antywłamaniowe
Zabezpieczenie okien
Sygnalizacja pożaru
System gaszenia pożaru gazem obojętnym
Gaśnica CO2
Kontrola temperatury
Nie
Nie
Nie
Nie
Nie
Tak
Nie
Nie
Nie
Nie
Nie
Nie
Nie
Nie
Nie
Tak
Nie
Nie
Nie
Nie
Tak
Nie
Nie
Nie
Nie
Nie
Tak
Nie
Nie
Nie
2
Strona 31 z 161
16.
17.
Kontrola wilgoci
Podłoga techniczna
ZAGROŻENIA
Nie
Nie
Nie
Nie
Nie
Nie
18.
Obecność sieci wod-kan
(poz. zagrożenia: wysoki, średni, niski)
Obecność instalacji grzewczych
INNE
Tak (niski)
Tak (niski)
Nie
Tak (niski)
Tak (niski)
Nie
20.
21.
Ilość klimatyzatorów
Łączna wydajność klimatyzatorów [kW]
PRZYŁĄCZA TELETECHNICZNE
1
5,2
1
8,8
1
7,1
22.
23.
Wolne przyłącza sieci logicznej [szt.]
Zapas dla przyłączenia urządzeń do sieci
elektrycznej [A]
Zapas mocy dla przyłączenia urządzeń do
sieci elektrycznej [TAK/NIE]/[A]
Wydzielony obwód zasilania [TAK/NIE]
System zasilania awaryjnego [TAK/NIE]
Centralny UPS [TAK/NIE]/Moc [kVA]
Agregat prądotwórczy [TAK/NIE]/Moc [kVA]
ZIDENTYFIKOWANE RYZYKA
12
Tak
24
Tak
24
Tak
Tak/ 25
Tak/ 25
Tak/ 25
Nie
Tak
Nie
Nie
Nie
Tak
Nie
Nie
Nie
Tak
Nie
Nie
Konieczność rozbudowy sieci logicznej
Konieczność rozbudowy sieci elektrycznej
Tak
Tak
Tak
Tak
Tak
Tak
19.
24.
25.
26.
27.
28.
29.
30.
3.1.1.2.
Szpital Specjalistyczny im. J. Dietla w Krakowie
L.P.
1.
Parametr
Serwerownia 1
Serwerownia 2
Adres
2.
3.
4.
5.
31-121 Kraków,
ul. Skarbowa 1
31-121 Kraków,
ul. Skarbowa 4
Główna
lokalizacja
18/2,90
Tak
4/70
31-121 Kraków,
ul Focha 33
31-121 Kraków,
ul Focha 33,
2km od Głównej
Lokalizacji
12/2,70
Tak
3/26
6.
7.
8.
9.
10.
11.
System alarmowy
Monitoring video
Kontrola dostępu
Ochrona fizyczna
Nie
Nie
Nie
Tak
Nie
Nie
12.
13.
14.
15.
16.
17.
Gaśnica CO2
Kontrola wilgoci
Podłoga techniczna
ZAGROŻENIA
Tak
Nie
Tak
Nie
Nie
Nie
Tak
Tak
Tak
Tak
Nie
Nie
dotyczy
(brak okien)
Tak
Nie
Tak
Nie
Nie
Nie
18.
INNE
Nie
Nie
Nie
Nie
2
6
2
4
19.
20.
21.
2
Serwerownia 3
Strona 32 z 161
22.
23.
24.
25.
26.
27.
28.
29.
30.
elektrycznej [A]
Zapas mocy dla przyłączenia urządzeń do
sieci elektrycznej [TAK/NIE]/[A]
90
8
120
20
Tak/8
Tak/20
Tak
Nie
Nie
Nie
Tak
Tak
Tak/2KVA
Tak/650kVA
Nie
Nie
Nie
Nie
3.1.1.3.
Szpital Specjalistyczny im. Ludwika Rydygieraw Krakowie sp. z o.o.
L.P.
1.
Parametr
Serwerownia 1
Serwerownia 2
Adres
2.
3.
4.
5.
Kraków,
os.
Złotej Jesieni 1,
31-826 Kraków
Kraków,
os.
Złotej Jesieni 1,
31-826 Kraków
13/3
Tak
5/42
Kraków,
os.
Złotej Jesieni 1,
31-826 Kraków
Kraków,
os.
Złotej Jesieni 1,
31-826 Kraków
30/3
Tak
Brak
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
System alarmowy
Monitoring video
Kontrola dostępu
Ochrona fizyczna
Gaśnica CO2
Kontrola wilgoci
Podłoga techniczna
ZAGROŻENIA
Nie
Tak
Nie
Nie
Nie
Brak okien
Tak
Nie
Tak
Tak
NIe
NIe
Tak
Tak
Nie
Nie
Nie
Tak
Tak
Nie
Tak
Nie
Nie
Nie
18.
INNE
Nie (niski)
Nie (niski)
Tak (niski)
Tak (niski)
20.
21.
2
7 kW
0
0
22.
23.
elektrycznej [A]
70
6kW
24.
Zapas mocy dla przyłączenia urządzeń do sieci
elektrycznej [TAK/NIE]/[A]
Tak /200kW
22
Brak
do
uruchomienia w
zależności
od
potrzeb
Tak/200kW
19.
25.
26.
27.
28.
2
Tak
Nie
Tak
Nie
Tak /20kVA
Nie
Tak /2x 540kVA (dla
szpitala)
Serwerownia 3
całego
29.
Tak
Tak
Strona 33 z 161
30.
Tak
Tak
3.1.2.Serwery
L.P
Producent - model
Rok
produkcji
RAM
Obudowa
[Tower /
RACK-xU]
Rola (zadanie)
Szpital Specjalistycznyim. J. Śniadeckiego w Nowym Sączu
Optimus Nserwer
2005
2GB
Tower
Auto ID
Optimus Nserwer
2005
3GB
Tower
Simple KP
IBM x3650
2009
6GB
Rack 2U
Simple ERP
SUN x4170
2011
24GB
Rack 1U
Eskulap – terminale
SUN x4170
2012
24GB
Rack 1U
SUN x4170
2012
20GB
Rack 1U
HP ML350
2011
4GB
Rack 4U
Impax
HP ML350
2011
2GB
Rack 4U
Impax
1.
2.
3.
4.
5.
6.
7.
8.
4.
5.
6.
HP RP5470 UX PA- 2001
2GB
RACK 6U
HIS/LIS/RIS
RISC
NTT TYTAN 4205 2008
4GB
RACK 3U
Administracja+ serwer plików
WINSER
NTT TYTAN WINSER 2009
8GB
RACK 2U
PACS
2003
DELL (PACS) LX
2011
8GB
Rack 2U
PACS
HP BLADE 620c
2012
16GB
Rack
Dystrybucja obrazów DiCOM
HP BLADE 620c
2012
16GB
Rack
Serwer Terminali
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
HP ML 110 G4
2007
4GB
Rack
Obsługa ZDL
SuntarNET
2007
4GB
Rack
Serwer plików
HP DL 380 G5
2008
16GB
Rack
Infomedica
HP DL 380 G5
2008
16GB
Rack
HIS - zapasowy
HP DL 380 G5
2008
4GB
Rack
Dostęp do WAN (serwer typu UTM)
HP DL 160 G6
2009
4GB
Rack
Serwer plików
HP BL460c G6
2010
16GB
Blade
PACS
HP BL460c G6
2010
16GB
Blade
PACS
HP BL460c G6
2010
32GB
Blade
HIS, RIS
HP BL460c G6
2010
16GB
Blade
Hyper-V, WSUS, drERYK
HP BL460c G6
2010
16GB
Blade
Hyper-V, Serwer Kaspersky, eWUŚ
HP DL 120 G6
2010
4GB
Rack
Kontroler domeny
HP DL 120 G6
2010
4GB
Rack
Kontroler domeny
HP DL 160 G6
2010
4GB
Rack
Płatnik, Intranet
HP DL 360 G6
2010
4GB
Rack
Serwer plików
HP DL 120 G6
2011
4GB
Rack
PCM,
HP DL 360 G7
2012
4GB
Rack
Poczta, witryna WWW
HP BL460c G8
2013
64GB
Blade
EDM
HP BL460c G8
2013
64GB
Blade
EDM
1.
2.
3.
3.1.3.Macierze
L.P
1.
Producent - model
IBM DS3512
Rok
produkcji
Pojemność
Jakie dane są
przechowywane
2009
2x
1TB; PACS
5x300MB
1.
HP MSA P2000
2.
NTT
2012
12TB
Dane
administracyjne
2008
18TB
Dane medyczne
Rodzaj dysków
[SATA / FATA]
SAS (SATA)
SAS
SATA
Strona 34 z 161
L.P
1.
2.
3.
4.
Producent - model
HP MSA P2000
HP 2312fc
HP MSA P2000 G3
HP MSA2000
Rok
produkcji
2009
2010
2012
2012
Pojemność
5TB
12TB
32TB
24TB
Jakie dane są
przechowywane
PACS
PACS
HIS,Archiwa
Dane
administracyjne
Rodzaj dysków
[SATA / FATA]
SAS
SAS
SAS
SAS
3.1.4.Biblioteka taśmowa
L.P
1.
2.
Producent - model
Rok
produkcji
Pojemność
Jakie dane są
przechowywane
HP StorageWorks MSL 2010
20x1,6 TB
PACS
2024
SUN Oracle Storagetek 2011
20x1,6 TB
Simple
SL24
Nie
Nie dotyczy
Nie dotyczy
dotyczy
Oprogramowanie
do backupu
Firmeware HP
Firmeware Oracle
1.
Brak
1
HP StorageWorks MSL 2010
48x800GB
PACS
Firmeware
4048
Synektik
Nie dotyczy
HP,
Strona 35 z 161
3.1.5.Połączenia sieciowe oraz sieć NAS
3.1.5.1.
Główny Punkt Dystrybucyjny (GPD) znajduje się w pomieszczeniu serwerowni na parterze
w budynku Pulmonologii.
Oprócz tego w budynkach znajdują lokalne punkty dystrybucyjne, są to:





Punkty 4P0, 4P1, 4P3, 4P4 (zlokalizowane na piętrach 0, 1, 3 i 4 Budynku 4)
Punkty 3P-1, 3P0, 3P1, 3P2, 3P3 zlokalizowane na piętrach -1, 0, 1, 2 i 3 Budynku 3
Punkt PU zlokalizowany w budynku Pulmonologii
Punkt PS zlokalizowany w budynku Kliniki Psychiatrycznej
Punkt TE zlokalizowany w dziale technicznym
Strona 36 z 161


Punkt DR (istniejący) zlokalizowany w budynku Dyrekcji
Punkt RTG (istniejący) na parterze budynku 4
Punkty zostały połączone okablowaniem światłowodowym wielodomowym OM3 o różnej liczbie
włókien. Załączony rysunek ilustruje schemat sieci logicznej.
Podstawą do opracowania zagadnień związanych z okablowaniem strukturalnym są normy
okablowania strukturalnego:





ISO/IEC11801 wyd. II
EN50173-1 wyd. II
TIA/EIA 569A
PN-EN50173-1 + AC
TIA/EIA 568B
3.1.5.2.
cat. 5e
światłowód 10Gb (Wszystkie połączenia posiadają backup – podwójny ring)
Strona 37 z 161
cat 6
światłowód 1 Gb
łącze LINK 4Mb/1Mb od 1.02.2013 światłowód 100M
iSCASI, FC, SCASI
3.1.5.3.
Sieć informatyczna w Szpitalu zbudowana jest w topologii rozszerzonej gwiazdy. Szkielet sieci
zbudowany na 6-cio światłowodach MM 50/125 które łączą centralny punkt dystrybucyjny (MDF
serwerownia) z lokalnymi punktami dystrybucyjnymi (IDF)usytuowanymi na poszczególnych piętrach.
Stacje robocze użytkowników komunikują się z przełącznikiem brzegowymi HP ProCurve 2610 po
skrętce miedzianej cat.5e/6 z prędkością 100/1000 Mbps (w zależności od parametrów switch).
Komunikacja w obrębie sieci szkieletowej odbywa się z prędkością 1/10Gbps.Szkielet sieci spina
modularny przełącznik szkieletowy HP ProCurve 5412zl.
W obrębie serwerowni funkcjonuje sieć pamięci masowej SAN zbudowana w technologii Fibre
Channel w skład której wchodzi: 5 macierzy dyskowych HP MSA, system serwerowy HP Blade, 3
serwery Rackowe, biblioteka taśmowa MSL4048.Komunikację pomiędzy urządzeniami serwerowymi
i zasobami pamięci zapewniają 3 switche FC(HP StorageWorks 8/20q oraz Brocade 8/12C).
Komunikacja w strukturze FC odbywa się z prędkością 8Gbps.
Na rysunku poniżej przedstawiony jest schemat infrastruktury FC.
Strona 38 z 161
3.1.6.Sprzęt komputerowy
L.P.
Rok
produkcji
Typ
[terminal/PC]
Ilość
[szt.]
System operacyjny
1.
2011
Terminale
Windows serwer 2008
2.
2005-2012
PC
Windows XP
3.
2011
PC
Windows VISTA
4.
2012-2013
PC
Windows 7
20
5.
2013
PC
Windows 8
1
1.
2.
2008, 2012,
2013
2005-2013
1
2004-2013
200
65
5
Terminal
Linux
140
PC
Windows (XP; VISTA; 7)
110
Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. Z o.o.
PC
Windows XP PRO, 7 PRO
574
3.2. Infrastruktura sieciowa
3.2.1.Sieć szkieletowa
L.P
Podmiot
Technologia
Przepustowość
1.
Szpital
Specjalistyczny
im.
J.
Śniadeckiego w Nowym Sączu
Szpital Specjalistyczny im. J. Dietla w
Krakowie
Szpital Specjalistyczny im. Ludwika
Rydygiera w Krakowie sp. z o.o.
Światłowód
1Gb/10Gb
Redundancja
[TAK/NIE]
Nie
Światłowód
10Gb
Tak
Światłowód
1Gb/10Gb
Nie
2.
3.
3.2.2.Sieć pozioma
Podmiot
Technologia
Przepustowość
Kategoria
Szpital Specjalistyczny im. J. Śniadeckiego
w Nowym Sączu
Krakowie
UTP
100Mb/1Gb
5/6e
UTP
1Gb
5e/6
3.
Szpital
Specjalistyczny
im.
UTP/FTP
100Mb/1Gb
5e/6
L.P
Podmiot
Ilość
1.
Szpital
Specjalistyczny
im.
J.
Śniadeckiego w Nowym Sączu
Krakowie
23
Szpital Specjalistyczny im. Ludwika
18
L.P
1.
2.
Ludwika
3.2.3.Węzły pośrednie
2.
3.
7
Odrębne
zasilania
[TAK / NIE
/
CZĘŚCIO
WO]
Nie
UPS
[TAK / NIE /
CZĘŚCIOW
O]
Dostęp
chroniony
[TAK / NIE /
CZĘŚCIOWO]
Nie
Częściowo
Częściowo
(2
z
zasilaniem)
Częściowo
Częściowo
(2)
Częściowo
Częściowo
Częściowo
Strona 39 z 161
3.2.4.Urządzenia UTM
L.P
Podmiot
1.
w Nowym Sączu
Krakowie
Szpital
Specjalistyczny
im.
Ludwika
2.
3.
[TAK / NIE]
(model)
Tak
(MikroTik
Board 1000)
Tak
(Juniper
SSG140)
TAK (Linuks Slackware)
ilość
1
Redundancja
Nie
Rok
produkcji
2009
1
Nie
2009
1
Nie
2010
3.2.5.Urządzenia aktywne – lista
3.2.5.1.
L.P.
1.
Producent
Model
Rok produkcji
Ilość
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
Allied Telesis
AT-x600/24
2012
2010,2012
2
7.
8.
Allied Telesis
AT-MC101xL
2009
2
9.
Allied Telesis
AT-G6f Rapier
2007
1
10.
Allied Telesis
AT-8 PoE
2009
11.
Allied Telesis
AT-8000S/48
2009
2
1
3.2.5.2.
L.P.
Producent
Model
1.
Netgear
2.
3.
4.
Netgear
3com
3com
M5300-52G +2 x SFP10Gb + 2
moduły stack
GS752TXS +2xSFP 10Gb
serii 4200
24 port
3.2.5.3.
2
Rok
produkcji
2013
Ilość
2012
2010
2011
4
3
2
9
Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp z o.o.
L.P.
1.
2.
3.
4.
5.
6.
7.
8.
Producent
Model
Rok produkcji
Ilość
HP
HP
HP
HP
HP
HP
HP
HP
2010
2008
2009
2007
2010
2008
2010
2010
24
6
5
2
3
1
1
1
9.
10.
HP
HP
ProCurve 2610
ProCurve 2610
ProCurve 2610
ProCurve 2810
ProCurve 2910al-48G
ProCurve5412zl
ProCurve5406zl
Storage Works 8/20q Fibre Channel
Switch
Brocade 8/12C SAN
Brocade 8/12C SAN
2010
2013
1
1
Strona 40 z 161
3.3. Łącza internetowe
Przepustowość
upload [Mbps]
Szczytowe
obciążenie
Pozostały czas
trwania umowy
[mies.]
Czy są warunki do
zwiększenia
przepustowości
4
90%
2
Tak
10
1
50%
100%
12
22
Tak
Tak
Światłowód
4
50
50
80%
9
Tak
Radiowe
Brak danych
Tak
Technologia
przyłącza
Ilość
stałych
adresów IP
Przepustowość
download
[Mbps]
LP.
Operator
Serwerownia
1.
TP SA
Serwerownia
Neostrada
5
40
RTG
1.
2.
Fibertech
TP SA
Skarbowa 1
Skarbowa 1
1.
Netia SA
2.
Exatel SA
Kraków,
os.
Złotej Jesieni 1,
31-826 Kraków
Kraków,
os.
Złotej Jesieni 1,
31-826 Kraków
Światłowód
8
10
ADSL
6
4
16
40
40
80%
Szacując, że do obsługi MSIM będzie konieczne łącze o min. przepustowości 20 Mbps (zarówno upload, jak i download) łącza w Szpitalu Specjalistycznym
im. J. Śniadeckiego w Nowym Sączu (tylko upload), oraz Szpitalu Specjalistycznym im. J. Dietla w Krakowie są niewystarczające do obsługi MSIM.
Dostarczenie niezbędnych łącz, których mowa wyżej nie jest elementem zamówienia.
3.4. Procedury bezpieczeństwa
Nazwa jednostki
Szpital
Specjalistyczny im.
J. Śniadeckiego w
Nowym Sączu
Wdrożona
Polityka
Bezpiecze
ństwa
Nie
(zamierza
wdrożyć w
2014r)
System
zarządzania
Bezpieczeń
stwem
Informacji
Nie
Procedury dotyczące bezpieczeństwa Informacji
Istniejące procedury: - Instrukcja zarządzania systemami
informatycznymi służącymi do przetwarzania danych
osobowych
- procedury archiwizacji danych
- procedury nadawania i odbierania uprawnień w szpitalu
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.
Ludwika Rydygiera
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
1.
Politechnika Poznańska
ESKULAP
4.4.1 bw
Wsparcie
[TAK/NIE]
Tak
2.
GEM Systemy Informatyczne
SIS
Brak wersjonowania
Tak
3.
Comarch (Esaprojekt)
Optimed
6.00.360
Tak
3.5.2.System LIS - analityka
L.P
.
Podmiot
Producent
Nazwa
Wersja
Wsparcie
[TAK/NIE]
1.
ESKULAP
2.3.0 s
Tak
Integra
-cja z
HIS
Tak
2.
SIS
Brak wersjonowania
Tak
Tak
3.
GEM Systemy
Informatyczne
Marcel
Centrum
2.440.10.1285
Tak
Tak
L.P
Podmiot
Producent
Nazwa
Wersja
Wspar
cie
1.
ESKULAP
1.2.1 h
Tak
Integra
-cja z
HIS
Tak
2.
SIS
Tak
Brak
wersjonowania
2.440.10.1285
TAK
3.
GEM Systemy
Informatyczne
Marcel
Tak
Tak
3.5.3.System LIS - bakteriologia
Centrum
3.5.4.System RIS
L.P.
Podmiot
Producent
Nazwa
Wersja
Wspa
rcie
Integra
-cja z
HIS
(wyniki
opisowe)
1.
Agfa
IMPAX
2.3.0 r
Tak
Tak
2.
SIS
Tak
Brak
wersjonowania
3.1.14.4
Tak
3.
GEM
Systemy
Informatyczne
Comarch (Esaprojekt)
Tak
Tak
L.P
Podmiot
Producent
Nazwa
Wersja
Wspa
-rcie
1.
Agfa
IMPAX
6.4.0.4 513
Tak
Integracja z
HIS
Nie
2.
PIXEL
ExPACS
Tak
Nie
3.
Synektik
ARPACS
Ostatnia do
wygaśnięcia
wsparcia, tj.
01.12.2016
2.143.145.
Tak
Tak
CRID
3.5.5.System PACS
3.5.6.E-Rejestracja
Nie
Integra
cja z
HIS
Nie
Możliwość
podłączenie
pozostałych
Nie
Brak
Nie
Nie
Nie
1.0
Tak.
Nie.
Nie.
L.P.
Podmiot
Czy jest
świadczona?
Producent
Nazwa/Uwagi
Wersja
Wspa
rcie
1.
Szpital Specjalistyczny im. J. Śniadeckiego w
Nowym Sączu
Nie
Brak
Brak
Brak
Nie (w trakcie
projektowania)
Tak
Brak
Brak
Szpital
Specjalistyczny im.
L. Rydygiera Sp. z
o.o. Dział
Informatyki
Oprogramowanie
autorskie
wykonane we
własnym zakresie
2.
3.
Szpital Specjalistyczny im. Ludwika Rydygiera w
Krakowie Sp. z o.o.
Strona 44 z 161
3.5.7.Wnioski
Integracja wymienionych systemów z HIS realizowana jest w zakresie wysyłania zlecenia
i odbierania wyniku. Wynik nie zawiera danych obrazowych PACS. Z powyższego zestawienia danych
wynika że większość systemów (za wyjątkiem PACS) jest już zintegrowana z HIS.
Analiza poziomu dojrzałości usługi e-Rejestracja wykazuje, że jest to usługa, która na poziomie
lokalnym obecna jest w jednostkach na bardzo zróżnicowanym poziomie. Niektórzy Partnerzy Projektu
nie posiadają takiej usługi, u niektórych jest ona na bardzo niskim poziomie dojrzałości lub jej
wdrożenie jest dopiero planowane. Niektórzy Partnerzy posiadają taką usługę wdrożoną
i zintegrowaną z oprogramowaniem HIS. Uruchomienie usługi e-Rejestracja w skali całego regionu
wymaga jednak dodatkowych działań związanych z dostarczeniem części regionalnej rozwiązania.
3.6. Rodzaje przetwarzanych danych
Legenda:
01- Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
02- Szpital Specjalistyczny i. J. Dietla w Krakowie
03- Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie Sp. z o.o.
W poniższej tabeli wskazano system, z którego jest możliwość importu danych (HIS / LIS / RIS)
Podmiot
01
02
03
dokumenty podstawowe - priorytet 1
1
Formularz historii choroby
HIS
HIS
HIS
2
Wywiad lekarski
HIS
HIS
HIS
3
Epikryza
HIS
HIS
HIS
4
Karta informacyjna z leczenia szpitalnego
HIS
HIS
HIS
5
Opis przebiegu leczenia
HIS
HIS
-
6
Wyniki badań laboratoryjnych – analityka
HIS
HIS
HIS/LIS
7
Wyniki badan laboratoryjnych – bakteriologia
HIS
HIS
HIS/LIS
8
Wyniki badań diagnostyki obrazowej – opis
HIS
HIS
HIS/RIS
9
Wyniki konsultacji
HIS
HIS
-
10
Protokół operacyjny
HIS
HIS
HIS
11
Karta zleceń lekarskich
HIS
HIS
-
HIS
HIS
-
HIS
HIS
-
HIS
HIS
HIS
dokumenty rzadko spotykane w HIS priorytet 2
12
Wywiad epidemiologiczny
13
Karta Oceny Ryzyka
Przyjęciu do Szpitala
14
Ocena ryzyka
odżywienia
Zakażenia
związanego
ze
przy
stanem
dokumenty pielęgniarskie - priorytet 3
15
Plan opieki
HIS
HIS
-
16
Karta gorączkowa
HIS
HIS
HIS
17
Karta indywidualnej opieki pielęgniarskiej
-
HIS
-
18
Karta obserwacyjna
HIS
HIS
-
19
Karta wywiadu pielęgniarskiego
HIS
HIS
-
20
Raport pielęgniarski
-
HIS
-
-
-
-
dokumenty nie wychodzące ze szpitala brak konieczności wymiany pomiędzy
jednostkami
21
Karta procesu sterylizacji
Opis przedmiotu zamówienia
22
Karta kwalifikacyjna do zabiegu
HIS
HIS
-
23
Karta przebiegu znieczulenia
HIS
HIS
-
24
Okołooperacyjna Karta Kontrolna
-
-
-
25
Karta zabiegów fizjoterapeutycznych
-
HIS
-
26
Karty TISS
-
-
-
27
Inne np. zgoda pacjenta na wykonanie
badania lub zabiegu
-
-
HIS
Powyższe dokumenty w postaci elektronicznej mają charakter sformatowanych plików tekstowych
o niewielkim rozmiarze. Rozmiar każdego z nich nie jest ściśle określony ze względu na zmienność
tekstów, które te dokumenty zawierają. Można szacować że ich rozmiar będzie ograniczony do
kilkuset kilobajtów. Wszyscy partnerzy projektu zadeklarowali gotowość udostępniania oraz chęć
korzystania z dokumentacji medycznej poprzez MSIM pod warunkiem że będzie to zgodne
z obowiązującymi przepisami prawa.
W poniższej tabeli wskazano szacowany roczny przyrost tekstowych danych medycznych
w [MB] przyjmując średnią wielkość pojedynczego dokumentu medycznego skonwertowanego do
formatu pdf: 300kb uwzględniając liczbę pobytów oraz szacowaną częstość występowania danej
dokumentacji. Przyjęto na potrzeby szacowania że zabiegi operacyjne dotyczą 6 % hospitalizacji
(wyliczenia dokonano na podstawie danych statystycznych z 2007 roku).
Podmiot
01
02
03
Ilość hospitalizacji w roku
28000
15000
28000
Roczny przyrost danych [MB]- priorytet 1
1
Formularz historii choroby
8400
4500
8400
2
Wywiad lekarski
8400
4500
8400
3
Epikryza
8400
4500
8400
4
Karta informacyjna z leczenia szpitalnego
8400
4500
8400
5
Opis przebiegu leczenia
8400
4500
8400
6
Wyniki badań laboratoryjnych – analityka
8400
4500
8400
7
Wyniki badan laboratoryjnych – bakteriologia
8400
4500
8700
8
Wyniki badań diagnostyki obrazowej – opis
8400
4500
45000
9
Wyniki konsultacji
8400
4500
8400
10
Protokół operacyjny
504
270
504
11
Karta zleceń lekarskich
8400
4500
8400
dokumenty rzadko spotykane w HIS - priorytet 2
12
Wywiad epidemiologiczny
8400
4500
8400
13
Karta Oceny Ryzyka Zakażenia przy Przyjęciu do
8400
Szpitala
4500
8400
14
Ocena ryzyka związanego ze stanem odżywienia
8400
4500
8400
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
dokumenty pielęgniarskie - priorytet 3
Strona 46 z 161
W poniższej tabeli wskazano roczny przyrost danych medycznych obrazowych w [GB]
L.P.
1.
2.
3.
Podmiot
Roczny przyrost
danych w [GB]
1900
8000
3000
Analiza systemów dziedzinowych u Partnerów Projektu oraz rodzajów przetwarzanej dokumentacji
pokazuje, że podstawowym i często jedynym systemem dziedzinowym, który daje możliwość integracji
w zakresie EDM, jest oprogramowanie klasy HIS. Dodatkowo analiza wskazała, że większość
podstawowej dokumentacji medycznej jest możliwa do wyeksportowania z używanego
oprogramowania klasy HIS.
3.7. Gwarancja i serwis
Zapisy gwarancyjne oraz serwisowe umów podpisanych między szpitalami i dostawcami
aplikacji/systemów dziedzinowych, nie gwarantują bez kosztowego przeprowadzenia integracji MSIM
z systemami dziedzinowymi. Integracja zawsze skutkuje poniesieniem jej kosztów, można co najwyżej
wpływać na rozmiar tych kosztów. W celu ich ograniczenia najważniejsze wydaje się doprowadzenie
do stanu, w którym integracja z MSIM dotyczyłaby jak najmniejszej ilości systemów.
W obszarze wymiany EDM optymalnym rozwiązaniem wydaje się integracja podstawowego systemu
dziedzinowego, czyli oprogramowania klasy HIS, z Repozytorium Elektronicznej Dokumentacji
Medycznej.
3.7.1.Opieka serwisowa (ilość miesięcy do wygaśnięcia umowy)
L.P
1.
2.
3.
Podmiot
HIS
LIS
RIS
PACS
w Nowym Sączu
Krakowie
Szpital
Specjalistyczny
im.
Ludwika
Rydygiera w Krakowie Sp. z o.o.
1
1
1
1
26
26
26
36
13
17
13
24
3.7.2.Opieka serwisowa (SLA – czas reakcji na błąd krytyczny w godzinach)
L.P
1.
2.
3.
Podmiot
HIS
LIS
RIS
PACS
w Nowym Sączu
Krakowie
Szpital
Specjalistyczny
im.
Ludwika
48
48
48
48
8
8
8
12
24
24
24
24
3.7.3.Integracja z systemem HIS
L.P
1.
2.
3.
Podmiot
LIS
RIS
PACS
w Nowym Sączu
Krakowie
Szpital
Specjalistyczny
im.
Ludwika
Tak
Tak
Nie
Tak
Tak
Nie
Tak
Tak
Tak
Strona 47 z 161
3.7.4.Wnioski
Na potrzeby MSIM informacje należy podzielić na dwie główne grupy: Informacje znakowe oraz
informacje graficzne. Dla informacji graficznych głównym miejscem przechowywania jest system
PACS. Informacje tekstowe ewidencjonowane są w wielu systemach medycznych, przy czym systemy
HIS pełnią rolę pośredniczącą.
Wykorzystanie w systemie MSIM repozytorium EDM powoduje więc ograniczenie kosztów integracji.
W przypadku usługi e-Rejestracja sposób jej wykonania jest pochodną oczekiwań użytkowników
i specyficznej sytuacji produktowej w tym zakresie.
3.8. Funkcjonalność Centrum Autoryzacji Podpisu Elektronicznego (CAPE)
Obecnie funkcjonująca w Centrum aplikacja PentaSCAPE RA-Service umożliwia uzyskanie certyfikatu
na podstawie żądania w formacie PKCS#10. Nie ma określonych wymagań dot. zawartości żądania
PKCS#10 (do certyfikatu pobierany jest jedynie klucz publiczny). CAPE obsługuje klucze i rozmiary
zgodne z profilem certyfikatu użytego w PentaSCAPE Ra-Service do wystawienia certyfikatu.
Usługa umożliwiająca uzyskanie certyfikatu udostępniana jest poprzez interfejs WWW, w którym
uwierzytelnianie odbywa się poprzez podanie loginu i hasła.
Usługa znakowania czasem realizowana jest za pomocą dostępnej przez protokół http aplikacji
PentaSCAPE-TSAService i zgodna ze standardem RFC 3161.
Nie przeprowadzano testów wydajnościowych usługi. Aktualna wydajność usługi powinna być
wystarczająca do planowanej skali systemu.
Ścieżka certyfikacyjna certyfikatu TSA obejmuje certyfikaty CA o nazwach wyróżniających:
'CN=RootCA, O=Województwo Małopolskie, C=PL' i 'CN=Centrum Autoryzacji w Małopolsce,
O=Województwo Małopolskie, C=PL'.
Odpowiedzi OCSP podpisywane
wydajnościowych usługi OCSP.
są
kluczem
dedykowanym.
Nie
przeprowadzano
testów
Usługa wydawania certyfikatów w centrum CAPE będzie dostępna bez ograniczeń licencyjnych.
Zamawiający zapewnia dostęp do interfejsu API umożliwiającego wykorzystanie CAPE w procesach
autoryzacji dokumentów.
W załączniku 9B do SIWZ znajdują się wyciągi ze spisów treści dokumentacji CAPE, która zostanie
udostępniona wybranemu Wykonawcy.
3.9. Lokalne słowniki dokumentów
Lokalne słowniki dokumentów w większości jednostek pokrywają się, ponieważ wynikają
z obowiązującego prawodawstwa. Wszystkie rodzaje dokumentów są zdefiniowane w ramach
systemu HIS, choć dotyczą również danych pochodzących z innych systemów dziedzinowych (LIS,
RIS). Różnice między dokumentami wynikają ze specjalizacji jednostek oraz nieprecyzyjnego
dookreślenia formatu dokumentacji przez ustawodawcę. Ponadto w jednostkach używa się
dokumentów medycznych opracowanych na potrzeby własne szpitala (np. w Szpitalu
Specjalistycznym im. J. Dietla w Krakowie Karta Przymusu). Kluczowym elementem systemu będzie
wymiana dokumentacji medycznej w zw. z czym jeżeli niezbędne będzie w celu wykonania poprawnej
integracji dostosowanie/ujednolicenie istniejących słowników, formatów danych i standardów danych
słownikowych składowanych i udostępnianych należy to uwzględnić i wykonać we wdrożeniu.
Strona 48 z 161
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
w projekcie.
musi
wdrożyć
komponenty
lokalne
w
każdym
Szpitalu
uczestniczącym
4.1. Komponent lokalny
Komponent lokalny składa się z następujących jednostek funkcjonalnych:
4.1.1.Repozytorium EDM
Repozytorium EDM to moduł odpowiedzialny za przyjmowanie i przechowywanie dokumentów
medycznych z systemów źródłowych funkcjonujących w Szpitalach. Moduł ten odpowiada za
gromadzenie, przetwarzanie EDM zgodnej ze standardem HL7 CDA R2 na 3-cim poziomie
interoperacyjności,.
Repozytorium EDM musi wystawiać i obsługiwać interfejs przekazywania i rejestracji EDM zgodnie
z wytycznymi ITI-41 profilu integracyjnego XDS.b (nie dotyczy architektury wewnętrznej systemu).
Repozytorium EDM musi obsługiwać interfejs pozwalający na pobranie EDM uwierzytelnionemu
użytkownikowi zgodnie z wytycznymi ITI-43 (nie dotyczy architektury wewnętrznej systemu).
Repozytorium EDM musi wspierać opcję (rozszerzenie) profilu integracyjnego XDS.b związaną
z obsługą asynchronicznej wymiany wiadomości (ang. „Asynchronous Web Services Exchange
Option”).
4.1.2.Systemy dziedzinowe (źródłowe): HIS, LIS, RIS a MSIM
Systemy dziedzinowe to systemy informatyczne wspierające działalność leczniczą szpitala w tzw.
części białej, które w kontekście niniejszego projektu stanowią źródło EDM. Systemy źródłowe (za
wyjątkiem systemu HIS – w zakresie integracji pomiędzy lokalnym EDM, a HIS oraz e-Rejestracją z
wykorzystaniem interfejsu opracowanego przez dostawcę HIS) nie są objęte w jakikolwiek sposób
przedmiotem zamówienia. Ich dostosowanie do funkcjonowania zgodnie z zaproponowanymi
interfejsami stanowi przedmiot odrębnych działań realizacyjnych.
Systemami dziedzinowymi w kontekście niniejszego projektu są systemy HIS, LIS, RIS i inne,
w których generowana jest EDM.
4.1.3.Usługa podpisu elektronicznego dla EDM
Usługa podpisu elektronicznego dla EDM musi obsługiwać funkcję podpisywania i weryfikacji podpisu
elektronicznego związanego z wdrożonym systemem tożsamości z wykorzystaniem Centrum
Autoryzacji (CAPE w Małopolsce).
Usługa podpisu elektronicznego musi być zgodna z funkcjonującą Polityką Certyfikacji CAPE
w Małopolsce.
Usługa musi integrować się z funkcjami CAPE w zakresie znakowania czasem oraz wykorzystania
podpisu elektronicznego oraz pozostałych usług CAPE oraz wystawiać te usługi dla pozostałych
komponentów Systemu MSIM, w tym repozytorium EDM, rejestru EDM oraz systemów dziedzinowych
(w szczególności HIS).
Strona 49 z 161
4.1.4.Usługa buforowania dla klienta pobierania EDM
Usługa istnieje w celu pośredniczenia w asynchronicznym trybie pobierania EDM. Klient korzystający
z usługi pobierania EDM w trybie asynchronicznym zamawia zgromadzenie EDM (np. z kilku różnych
źródeł o znacznym wolumenie), a następnie usługa buforowania przejmuje w jego imieniu proces
zgromadzenia EDM.
Usługa musi obsługiwać 2 interfejsy komunikacji:

Push - w momencie wystąpienia zdarzenia zakończenia pobrania EDM wysyłany jest
komunikat o gotowości do jej pobrania do zarejestrowanego klienta
 Pull – w momencie odebrania komunikatu od klienta wysyłana jest gotowa EDM lub
w przypadku jej braku (np. trwa proces buforowania) zwracany jest komunikat o stanie
procesu (np. procent i wolumen pobranych już danych w odniesieniu do całości)
Wymaga się aby nana etapie Analizy Przedwdrożeniowej, Wykonawca przedstawił możliwe warianty
zapewnienia odporności do wyboru przez Zamawiającego na awarię w warstwie sieciowej (np. na
zagrożenia typu przerwy w połączeniu).
4.2. Komponent regionalny
Komponent regionalny składa się z następujących jednostek funkcjonalnych:
4.2.1.Rejestr EDM
Rejestr EDM musi przechowywać scentralizowane informacje o miejscu składowania i fakcie
wytworzenia wraz z informacją o wersjonowaniu wszystkich dokumentów medycznych
w podmiotach biorących udział w Projekcie.
Za pomocą odpowiednich interfejsów uwierzytelniony Użytkownik Systemu MSIM będzie mógł
odpytać warstwę regionalną o dokumenty w innych jednostkach oraz pobrać je w całości lub
częściowo.
Rejestr EDM musi obsługiwać interfejs ITI-42 w zakresie rejestracji EDM.
Rejestr EDM musi obsługiwać interfejs ITI-18 w zakresie obsługi zapytań od użytkowników Systemu
MSIM.
4.2.2.Źródło identyfikacji pacjentów
Źródło identyfikacji pacjentów musi jednoznacznie określać tożsamość pacjenta na podstawie jego
właściwości.
Źródło identyfikacji musi obsługiwać interfejs ITI-42 w zakresie rejestracji EDM.
Źródło identyfikacji musi obsługiwać interfejs ITI-18 w zakresie obsługi zapytań od użytkowników
Systemu MSIM.
4.2.3.Usługa uwierzytelniania i autoryzacji użytkowników
System musi przechowywać tożsamości użytkowników Systemu MSIM, w tym personelu medycznego
i obsługi technicznej.
Musi przechowywać prawa dostępu użytkowników Systemu MSIM.
Musi umożliwiać dodawanie, modyfikowanie i usuwanie użytkowników.
Musi umożliwiać tworzenie grup użytkowników.
Grupy użytkowników związane ze struktura organizacyjną projektu (w tym Podmiotu) powinny być
wprowadzone i skonfigurowane przed uruchomieniem Systemu MSIM oraz możliwe do edycji
w każdym momencie.
Strona 50 z 161
Określanie praw dostępu musi być możliwe na poziomie grup użytkowników.
Do nawiązywania zdalnych połączeń administracyjnych muszą być stosowane protokoły
komunikacyjne zapewniające bezpieczne uwierzytelnianie oraz poufność i integralność przesyłanych
danych.
Uwierzytelnianie w MSIM musi być oparte na PKI z CAPE w Małopolsce (Certificate Authority).
W szczególności uwierzytelnianie połączeń IPSec VPN ma być realizowane poprzez certyfikaty
klientów VPN, wystawiane dla każdego z użytkowników indywidualnie przez CAPE (Centrum
Autoryzacji podpisu elektronicznego). W zależności od uprawnień mogą być wystawiane osobne
certyfikaty.
Uwierzytelniania w MSIM może być realizowane przy pomocy innych metod uwierzytelnienia tylko
w uzgodnieniu z Zamawiającym. W szczególności zakłada się, że uwierzytelnianie Pacjentów
(klientów) usługi e-Rejestracja powinno odbywać się przy pomocy metody opartej na loginie/haśle.
Ważność certyfikatu musi być weryfikowana w CAPE on-line przy pomocy protokołu OCSP lub
podobnego.
Bezpieczeństwo kluczy powinno być realizowane z wykorzystaniem Polityki Certyfikacji CA MSIM.
Polityka certyfikacji powinna być oparta na RFC3647 “Internet X.509 Public Key Infrastructure,
Certificate Policy and Certification Practices Framework”.
Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie
przez inne oprogramowanie) interfejsu do usługi.
4.2.4.Usługa wyszukiwania EDM
Musi umożliwiać klientom (np. systemowi P1 w zakresie IKP lub aplikacjom webowym) przesłanie
zapytania do rejestru EDM zgodnie z wytycznymi ITI-18 profilu integracyjnego XDS.b.
Usługa wyszukiwania EDM musi umożliwiać:
 Przeszukiwanie rejestru EDM,
 Odpowiedź na zapytania o pozycję rejestru,
 Zwracanie wyników zapytania,
Z uwzględnieniem praw dostępu użytkownika.
4.2.5.Usługa pobierania EDM
Musi umożliwiać klientom(systemom klienckim) przesłanie zapytania do rejestru EDM zgodnie z
wytycznymi ITI-18 profilu integracyjnego XDS.b.
Usługa musi umożliwiać:
 Dostęp do repozytorium EDM,
 Odpowiadać na zapytania o pozycję repozytorium,
 Zwracać wyników zapytania,
 Zamówienie EDM (pobranie w trybie asynchronicznym),
 Odebranie EDM po wcześniejszym zamówieniu,
Z uwzględnieniem praw dostępu.
Strona 51 z 161
4.2.6.Usługa e-Rejestracja (regionalna)
Usługa e-Rejestracji udostępnia funkcjonalność rezerwacji usług medycznych w jednostkach ochrony
zdrowia zintegrowanych z MSIM. Użytkownik ma możliwość rejestracji usługi medycznej na wskazany
termin i anulowania tej wizyty. Z usługi e-Rejestracji mogą korzystać wyłącznie zarejestrowani na
poziomie regionalnym użytkownicy końcowi (pacjenci). W ramach e-usługi powinien funkcjonować
system komunikatów (powiadomień dla użytkowników końcowych w formie wiadomości e-mail oraz
System MSIM musi być przygotowano do wysyłania wiadomości SMS ) dotyczących: potwierdzenia
rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno
przez użytkownika jak i w lokalnym systemie medycznym HIS).
W szczególności usługa obejmuje następujące funkcjonalności:










Przegląd listy usług możliwych do realizacji w placówce Zamawiającego dla pacjenta,
Przegląd listy usług możliwych do rezerwacji przez Internet,
Możliwość zdalnego zgłoszenia wniosku o rezerwację terminu usługi z preferowanymi
terminami (zakres dat, dni tygodnia, przed południem, po południu): do Pracowni
Diagnostycznej lub Gabinetu Lekarskiego,
Umożliwia określenia celu wizyty u lekarza, z podziałem na: przypadek nagły incydentalny,
stan nagły przy chorobie przewlekłej, wizytę kontrolną, wizytę po kolejną receptę, wizytę po
skierowanie na badanie specjalistyczne,
Udostępnienie danych o zaplanowanych wizytach i usługach,
Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana),
Możliwość wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko pacjenta,
numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla pacjenta,
Dostęp do informacji o lokalizacji miejsca wykonania usługi,
Możliwość odwołania rezerwacji.
Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail)
4.2.7.Usługa komunikacji z P1 (IKP)
Usługa odpowiedzialna za komunikację z P1 zgodnie z wytycznymi i interfejsem platformy P1.
Usługa musi umożliwiać przetworzenie zapytania o EDM przez Pacjenta i wywołać odpowiednie usługi
w systemie MSIM.
Usługa musi umożliwiać wyszukanie EDM uwierzytelnionemu w P1 Pacjentowi.
Usługa musi umożliwiać pobranie EDM uwierzytelnionemu przez P1 Pacjentowi.
4.2.8.Usługa słownikowa
Celem funkcjonowania usługi słownikowej jest posiadanie jednolitej terminologii w EDM będącej
przedmiotem wymiany w projekcie MSIM.
Usługa słownikowa pośredniczy w dostępie do słowników oferowanych przez platformę P1, tj.:




ICD-10,
ICD-9,
ICF,
ICNP
Usługa umożliwia klientom, w szczególności systemom dziedzinowym, na:

Wyszukanie pełno tekstowe terminu,
Strona 52 z 161



Wyszukanie nadrzędnego terminu (w drzewie taksonomicznym),
Wyszukanie listy podrzędnych terminów (w drzewie taksonomicznym),
Pobranie dowolnego poddrzewa słownika (np. wszystkich terminów podrzędnych dla danego
terminu).
4.2.9.Usługa synchronizacji rejestrów EDM
Usługa musi umożliwiać synchronizację regionalnego i lokalnych 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
oprogramowanie) interfejsu do usługi.
4.2.10.
(umożliwiającego
wywołanie
przez
inne
Portal informacyjny
Portal informacyjny musi być aplikacją webową prezentującą informacje o projekcie, świadczonych
usługach, uczestniczących partnerach.
Portal musi być narzędziem klasy CMS umożliwiającym dostosowywanie oraz dodawanie treści przez
użytkowników po stronie Zamawiającego.
Portal musi posiadać możliwość dowolnej edycji i wprowadzania tekstu, w m. in. tym tworzenia
podstron, linkowania, podłączanie zdjęć.
Portal musi posiadać szatę graficzną uzgodnioną i zaakceptowaną przez Zamawiającego.
Portal musi zawierać odnośniki do wszystkich usług systemu, stanowiąc centralny punkt dostępu do
systemu MSIM.
Portal musi być zintegrowany ze stroną województwa małopolskiego, oznaczony logiem projektu oraz
banerami wymaganymi przepisami UE.
Z portalu musi być możliwe przejście do wszystkich usługi w tym e-Rejestracji.
Na portalu udostępnione będą:

Informacje o jednostkach ochrony zdrowia, które są zintegrowane z MSIM w ramach projektu
(w tym lista usług świadczony przez te podmioty)
 Wyszukiwarka usług medycznych (wg typu usługi oraz wg jednostki ochrony zdrowia)
 Dane kontaktowe do jednostek ochrony zdrowia (tel. do placówki, poszczególnych
specjalistów, informacji, rejestracji)
 Informacje nt. możliwości skorzystania z e-rejestracji (wraz z krótkim instruktażem jak
z korzystać z rozwiązania na portalu oraz charakterystyka e-usługi - FAQ)
 Funkcjonalność umożliwiająca rejestrację oraz założenie konta
 Informacje o projekcie MSIM
Wszystkie powyższe dane, opisy, grafiki, funkcjonalności do portalu wprowadzi Wykonawca.
4.2.11.
Panel administratora
Panel zawiera wszystkie funkcje potrzebne do administracji Systemem MSIM dla uprawnionych
użytkowników (administratorów).
Panel musi posiadać interfejs webowy.
Strona 53 z 161
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
transportowego EDM publikowanymi przez CSIOZ.
w sprawie reguł
tworzenia i modelu
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 (ITI43) musi umożliwiać integrację z innymi systemami regionalnymi i lokalnymi w obszarze e-Zdrowia.
Strona 54 z 161
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.
2.
3.
4.
Wyszukiwanie elektronicznej dokumentacji medycznej,
Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym,
Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym,
Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z wykorzystaniem
IKP,
5. Rezerwacja terminu wizyty,
6. Anulowanie rezerwacji terminu wizyty.
Niniejszy dokument przedstawia raport z analizy powyżej zidentyfikowanej listy procesów
biznesowych.
5.2. Metoda opisu
Każdy z procesów biznesowych został przedstawiony w formie opisowej i graficznej.
5.2.1.Opis procesu
Pierwszą częścią opisu jest forma tabelaryczna. Opis procesu w tej części zawiera następujące
informacje:








Nazwa procesu – zawiera identyfikator procesu oraz nazwę właściwą procesu. Identyfikator
proces został dodany do nazw procesu w celu umożliwienia i ułatwienia identyfikacji procesów
na diagramach zbiorczych przedstawiający grupy procesów.
Identyfikator procesu – unikalny identyfikator procesu umożliwiający identyfikację procesu
w całości dokumentacji.
Wersja procesu – numer kolejny wersji procesu.
Cel procesu – przedstawia podstawowy cel procesu biznesowego.
Uczestnicy procesu – przedstawia listę uczestników danego procesu, w tym systemy
zewnętrzne (np. system P1 w zakresie IKP).
Warunki wejściowe do procesu – zawiera listę warunków wejściowych do procesu
biznesowego, w tym również dane wejściowe.
Warunki wyjściowe z procesu – zawiera listę warunków wyjściowych, w tym dane wyjściowe
z procesu biznesowego.
Opis procesu - właściwy opis procesu przedstawiony w postaci kolejnych kroków procesu.
Poszczególne kroki procesu opisane są w sposób narratywny; jednocześnie mają one swoje
odpowiedniki w reprezentacji graficznej procesu, przy czym na diagramie ich nazwy są już
skrócone. Jest to spowodowane z 2 względów. Po pierwsze w celu zachowania przejrzystości
diagramu. Po drugie – nazwy na diagramie oznaczające czynności stanową równocześnie
nazwy kluczowych przypadków użycia warunkujących funkcjonalności systemu
informatycznego wspierającego realizację opracowanych procesów biznesowych.
Strona 55 z 161
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
komunikatu
zdarzenie
pośrednie
polegające
na
odbiorze
Element symbolizujący
komunikatu
zdarzenie
pośrednie
polegające
na
wysłaniu
Element symbolizujący krok procesu biznesowego (wykonaną czynność,
zwaną również aktywnością)
Element symbolizujący przepływ informacji,, tzw. MessageFlow (zaznaczony w
niektórych przypadkach jako nazwa relacji)
Element symbolizujący bramkę decyzyjną (albo)
Element symbolizujący bramkę równoległą (i)
Element symbolizujący bramkę LUB
Element symbolizujący zbiór (rejestr) danych
Strona 56 z 161
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
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łów na procesów biznesow ych
analysis Mapa procesów biznesow ych w obszarze przekazyw ania EDM
«BusinessProcess»
BP.ERP.001 Wyszukiw anie
elektronicznej dokumentacj i
medycznej
«BusinessProcess»
BP.ERP.002 Pobranie
medycznej w trybie
synchronicznym
«BusinessProcess»
BP.ERP.003 Pobranie
medycznej w trybie
asynchronicznym
«BusinessProcess»
BP.ERP.004 Pobranie
medycznej w trybie
synchronicznym z
w ykorzystaniem IKP
Business Process Mapa procesów biznesow ych w obszarze e-rej estracj i
«BusinessProcess»
PB.REJ.01 Rezerw acj a
terminu w izyty
«BusinessProcess»
PB.REJ.02 Anulow anie
rezerw acj i terminu w izyty
Analizowane procesy biznesowe zostały zgrupowane w 2 grupy: procesy związane z obszarem
przekazywania elektronicznej dokumentacji medycznej (EDM) oraz z obszarem e-Rejestracji.
Strona 57 z 161
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 biznesow ych w obszarze przekazyw ania EDM
«BusinessProcess»
BP.ERP.001 Wyszukiw anie
medycznej
«BusinessProcess»
BP.ERP.002 Pobranie
medycznej w trybie
synchronicznym
«BusinessProcess»
BP.ERP.003 Pobranie
medycznej w trybie
asynchronicznym
«BusinessProcess»
BP.ERP.004 Pobranie
medycznej w trybie
synchronicznym z
w ykorzystaniem 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
Strona 58 z 161
2.
3.
4.
5.
Warunki wyjściowe

pozwalające na jego identyfikację.
Komponent regionalny sprawdza czy są obsługiwane zgody na wyszukiwanie
EDM dla danego pacjenta, czyli ERP.
Komponent regionalny odnajduje zarejestrowaną w rejestrze EDM i pozyskuje
zbiór metadanych EDM spełniający kryteria wyszukiwania.
Zbiór zawierający metadane EDM spełniający kryteria jest przekazywany do
klienta
Metadane EDM są prezentowane Pracownikowi medycznemu
Zbiór metadanych dotyczących EDM zostaje zeprezentowany pracownikowi
medycznemu.
Zaprezentowany zbiór metadanych dotyczących EDM jest zgodny z zapytaniem

Poniżej przedstawiono postać graficzną procesu biznesowego.
analysis BP.ERP.001 Wyszukiw anie elektronicznej dokumentacj i medycznej
«Pool» Konsument EDM
Zapoznaj się z
odmową dostępu
«SequenceFlow»
Wypełnij kryterium
wyszukiwania
Zapoznaj się z EDM
«SequenceFlow»
«Pool» Komponent regionalny
«SequenceFlow»
«Gateway» Czy są
obsługiwane zgody
ERP?
[Nie]
[Tak]
«SequenceFlow»
Przekaż wynik
«Gateway» Czy
odmowny
istnieje zgoda
«SequenceFlow»
[Nie]
«SequenceFlow»
pacjenta?
[Tak]
«SequenceFlow»
«Gateway»
Odpytaj rejestr EDM
«SequenceFlow»
«SequenceFlow»
Zbuduj odpowiedź o
EDM
Rejestr EDM
5.4.2.BP.ERP.002 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym
Nazwa procesu
BP.ERP.002 Pobranie
synchronicznym
elektronicznej
Strona 59 z 161
dokumentacji
medycznej
w
trybie
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




Opis procesu
1.
2.
3.
4.
5.
6.
7.
Warunki wyjściowe

Znane są dane pacjenta i pobieranej EDM.
Pracownik medyczny ma prawo do pobrania elektronicznej dokumentacji
medycznej pacjenta.
medycznej.
Pracownik medyczny wybiera z listy dostępnych EDM (zaprezentowanych
przez metadane z rejestru) dokładnie jedną EDMlub ich zbiór.
Komponent regionalny sprawdza czy są obsługiwane zgody na pobranie EDM
dla danego pacjenta, czyli ERP.
Komponent regionalny na podstawie danych identyfikacyjnych EDM lub ich
zbiór zestawia połączenie z odpowiednim repozytorium EDM
Komponent regionalny pobiera z repozytorium EDM żądane pozycje
Komponent regionalny na podstawie uzyskanych odpowiedzi buduje zbiór
wynikowy odpowiedzi
Komponent regionalny zwraca żądane pozycje do klienta
Wynik prezentowany jest pracownikowi medycznemu w sposób umożliwiający
jego zapisanie na komputerze klienta
Elektroniczny dokument medyczny lub ich zbiór zostaje zaprezentowany
pracownikowi medycznemu.
Strona 60 z 161
analysis BP.ERP.002 Pobranie elektronicznej dokumentacj i medycznej w trybie synchronicznym
Zapisz EDM
Konieczność dostępu do
EDM pacjenta
Wybierz EDM
Koniec
Zapoznaj się z EDM
lub z wynikiem
odmownym
Interpretacja wyniku
Żądanie pobrania EDM
Czy są obsługiwane
zgody ERP?
Zbuduj odpowiedź o
EDM
[TAK]
Czy istnieje
zgoda pacjenta?
[NIE]
Przekaż wynik
odmowny
[TAK]
Odpytaj repozytorium
EDM
[NIE]
«Pool» Komponent lokalny
Pobierz EDM
Żadanie wyszukania EDM
Repozytorium
EDM
5.4.3.BP.ERP.003 Pobranie
asynchronicznym
elektronicznej
Nazwa procesu
BP.ERP.003
Pobranie
asynchronicznym
Numer procesu
BP.ERP.003
Wersja procesu
1
dokumentacji
elektronicznej
Strona 61 z 161
medycznej
dokumentacji
medycznej
w
trybie
w
trybie
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




Opis procesu
1.
2.
3.
4.
5.
6.
7.
8.
Warunki wyjściowe

Pracownik medyczny ma prawo do pobrania elektronicznej dokumentacji
medycznej pacjenta.
medycznej.
Pracownik medyczny wybiera z listy dostępnych EDM (zaprezentowanych
przez metadane z rejestru) dokładnie jedną EDMlub ich zbiór.
Żądanie pobrania EDM jest przekazane do komponentu regionalnego.
Komponent regionalny zwraca komunikat do klienta o przekazaniu żądania
pobrania EDM wraz z przekazaniem tokena żądania w celu późniejszego
pobrania EDM
wynikowy odpowiedzi i zgłasza go do odbioru
Wpływa zapytanie od klienta zawierające token żądania
Komponent regionalny zwraca żądane pozycje do klienta
Elektroniczny dokument medyczny lub ich zbiór zostaje zaprezentowany
pracownikowi medycznemu.
Strona 62 z 161
analysis BP.ERP.003 Pobranie elektronicznej dokumentacj i medycznej w trybie asynchronicznym
Przechowania tokena
żądania
Token
żadania
Koniec
EDM pacjenta
Zapisz EDM
Potrzeba
zapytania o
dostępność
zamówionej
EDM
Koniec
Otrzymanie
komunikatu o
przekazaniu żądania
Zapoznaj się z EDM
Zapytanie o
dostępność
Komunikat o przekazaniu żądania
zamówionej EDM
Wybierz EDM
Co zrobić z otrzymaną EDM?
EDM
Otrzymanie
komunikatu o braku
możlwości pobrania
EDM
Typ odpowiedzi
[TAK]
[NIE]
Żadanie wznowienia
transakcji
asynchronicznej
Czy zamówiona EDM jest już dostępna? [TAK]
zgody ERP?
[TAK]
Czy istnieje
zgoda pacjenta?
[NIE]
[TAK]
[NIE]
Przekaż wynik
odmowny
Zbuduj odpowiedź o
EDM
Czy transakcja
zawiera token?
[NIE] Odpytaj repozytorium
EDM
Pobierz EDM
Repozytorium
EDM
5.4.4.BP.ERP.004 Pobranie elektronicznej
synchronicznym z wykorzystaniem IKP
dokumentacji
medycznej
w
trybie
medycznej
w
trybie
Nazwa procesu
BP.ERP.004 Pobranie elektronicznej
synchronicznym z wykorzystaniem IKP
Numer procesu
BP.ERP.004
Wersja procesu
1
Cel procesu
Celem niniejszego procesu jest pobranie EDM dla pacjenta korzystającego z IKP
Uczestnicy procesu
System P1, komponent lokalny, komponent regionalny
Warunki wejściowe

dokumentacji
Strona 63 z 161



Opis procesu
1.
2.
3.
4.
5.
6.
Warunki wyjściowe

Użytkownik systemu P1 ma prawo do pobrania elektronicznej dokumentacji
medycznej pacjenta.
medycznej.
Użytkownik systemu P1 wykonuje żądanie pobrania EDM. Użytkownik
systemu P1 występuje w roli Konsumenta EDM.
Komponent regionalny sprawdza czy są obsługiwane zgody na wyszukiwanie
EDM dla danego pacjenta, czyli ERP.
wynikowy odpowiedzi
Komponent regionalny zwraca żądane pozycje do systemu IKP
Elektroniczny dokument medyczny lub ich zbiór zostaje przekazany do systemu
IKP
Strona 64 z 161
analysis BP.ERP.004 Pobranie elektronicznej dokumentacj i medycznej w trybie synchronicznym z w ykorzystaniem IKP
«Pool» System IKP (Konsument EDM)
Zapisz EDM
EDM pacjenta
Wybierz EDM
Koniec
Interpretacja wyniku
Zapoznaj się z EDM
lub z wynikiem
odmownym
Zbuduj odpowiedź o
EDM
zgody ERP?
[TAK]
Czy istnieje
zgoda pacjenta?
[NIE]
Przekaż wynik
odmowny
[TAK]
[NIE]
Odpytaj repozytorium
EDM
Pobierz EDM
Repozytorium
EDM
5.5. e-Rejestracja
Szczegółowa mapa procesów biznesowych w obszarze e-Rejestracji obejmuje procesy związane
z usługą e-Rejestracja.
Strona 65 z 161
Business Process Model procesów biznesow ych
«BusinessProcess»
PB.REJ.01 Rezerw acj a
terminu w izyty
«BusinessProcess»
PB.REJ.02 Anulow anie
rezerw acj i terminu w izyty
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


Opis procesu
Istnieje kanał komunikacyjny pomiędzy warstwą regionalną a warstwą
lokalną.
Użytkownik posiadający konto użytkownika końcowego jest zalogowany do
systemu.
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ść
Strona 66 z 161
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.
Strona 67 z 161
analysis PB.REJ.01 Rezerw acj a terminu w izyty
«Lane»
Katalogi
Danych
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
«SequenceFlow»
«DataInputAssociation»
«DataOutputAssociation»
Wysyłaj rezerwację do
skutku (celem
potwierdzenia lub
odrzucenia rejestracji)
«SequenceFlow»
Wybierz formularz
rejestracji
Termin
wizyty
Wyślij powiadomienie
«SequenceFlow»
Koniec
Wypełnij formularz
danych rezerwacji
«Lane» e-Rejestracja
Zapisz rejestrację w
historii rejestracji
«SequenceFlow»
:External Reference
«SequenceFlow»
Weryfikuj kolizje
rezerwacji
«SequenceFlow»
Poinformuj o przyjęciu
rejestracji
«SequenceFlow»
Czy wykryto
kolizję?
«SequenceFlow»
[Nie]
Potwierdź wysłanie
rezerwacji lub anuluj
[Tak]
«SequenceFlow»
unikalny numer
rejestracji w HIS
Poinformuj o kolizji
Czy
«SequenceFlow»
potwierdzono
wysłanie
rezerwacji?
«SequenceFlow»
[Nie]
«SequenceFlow»
Wyślij rezerwację
wizyty do jednostki
«SequenceFlow»
[Tak]
opieki medycznej
«SequenceFlow»
«MessageFlow»
«MessageFlow»
«MessageFlow»
Poinformuj o odrzuceniu
przyjęcia rejestracji
«MessageFlow»
«MessageFlow»
«SequenceFlow»
Zweryfikuj rezerwację
Wyślij potwierdzenie
przyjęcia rejestracji
Zablokuj wskazany termin
dla uslugi (i personelu)
«SequenceFlow»
[Nie]
«SequenceFlow»
baza HIS
«SequenceFlow»
Odblokuj wskazany
termin
[Tak]
Zarejestruj pacjenta «SequenceFlow» zarezerwuj termin
Czy przyjęto
wizyty
rejestrację wizyty?
Wyślij informacje o
odrzuceniu rejestracji
«SequenceFlow»
«SequenceFlow»
«SequenceFlow»
Koniec
upłynął czas na
potwierdzenie
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



Opis procesu
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ą.
1) Zalogowany użytkownik, chcący anulować rezerwację wskazanej wizyty, wybiera
Strona 68 z 161
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”.
Strona 69 z 161
«Lane»
Katalogi
Danych
analysis PB.REJ.02 Anulow anie rezerw acj i terminu w izyty
Rejestr Użytkowników
Końcowych
Dane listy
rejestracji
Konieczność
anulowania
rezerwacji terminu
wizyty
Potwierdź decyzję o
anulowaniu rejestracji
«Lane» e-Rejestracja
Wskaż rejestrację, którą
należy anulować
Czy użytkownik
potwierdził decyzję?
:External Reference
[Nie]
skonfigurowano
powiadomienie
SMS'em
[Tak]
Wyświetl informację o
anulowaniu rejestracji
Zmień status rejestracji
w danych rejestracji
Wyślij SMS z
powiadomieniem
«SequenceFlow»
«SequenceFlow»
Koniec
Żądanie anulowania
rejestracji w HIS
skonfigurowano
powiadomienie
e-mail'em
Anulowanie
Rejestracji
Potwierdzenie
Anulowania
baza HIS
Anuluj wskazaną
rejestrację
Potwierdź
anulowanie
rejestracji
Strona 70 z 161
Wyślij e-mail z
powiadomieniem
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.
I.1.1.6.
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,
Broker odpowiada za:
I.1.1.6.1.
przekazanie
jednostki.
komunikatu
zawierającego
pytanie
do
wskazanej
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).
Strona 71 z 161
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
Strona 72 z 161
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,
Strona 73 z 161
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 (m.in.
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 Funduszowi Zdrowia, 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
(dostępny
na
https://p1.csioz.gov.pl/1/Tresci/pokazPelnyWidokTresci/756),
Wytyczne dla systemu bezpiecznego przetwarzania EDM (dostępny na
http://csioz.gov.pl/indexDetail.php?id=246),
Polska
Implementacja
Krajowa
HL7
CDA
(pl-cda-)
(dostępny
na
http://www.csioz.gov.pl/HL7POL/pl-cda-html-pl-PL/),
Strona 74 z 161
stronie
stronie
stronie





Reguły biznesowe i walidacyjne dla Elektronicznej Dokumentacji Medycznej (dostępny na
stronie http://www.csioz.gov.pl/file.php?s=d2k/Mzc=),
Model Transportowy danych o zdarzeniach medycznych (dostępny na stronie
http://www.csioz.gov.pl/publikacja.php?id=15),
Opis hierarchii węzłów ISO OID w Regułach EDM (dostępny na stronie
http://www.csioz.gov.pl/file.php?s=d2k/Mzk=),
Wytyczne, zasady i rekomendacje dotyczące bezpiecznego przetwarzania EDM (dostępny na
stronie http://www.csioz.gov.pl/file.php?s=d2k/NDA=),
Zbiór: http://www.csioz.gov.pl/wiedza.php.
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 dokumentocentrycznym, w którym podstawowym elementem wymiany pozostaje dokument. Polskie rozszerzenia
profilu XDS.b wprowadzone przez CSIOZ zmieniają ten model co do istoty na model zdarzeniocentryczny, 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:
Strona 75 z 161
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).
Strona 76 z 161






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:
Strona 77 z 161


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.
Strona 78 z 161
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 informacyjnego.
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ć resetowanie haseł użytkownikom poprzez wysyłanie na wskazany
adres email użytkownika linku, który umożliwia zmianę 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. m.in.: 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).
Strona 79 z 161
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.
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.
bezpieczeństwa. Systemy zarządzania bezpieczeństwem
Wymagania,
o
PN-ISO/IEC
17799:2007
bezpieczeństwa. Praktyczne
informacji.
Strona 80 z 161
Techniki
informacji.
Technika
informatyczna.
Techniki
zasady zarządzania bezpieczeństwem
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 w zakresie:
a) Polityki bezpieczeństwa haseł
b) Polityki kontroli dostępu
c) Polityki zarządzania uprawnieniami,
Strona 81 z 161
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.
2.
3.
4.
5.
6.
Polityka kontroli dostępu,
Procedura nadawania uprawnień do systemu,
Procedura zmiany uprawnień do systemu,
Procedura odbierania uprawnień do systemu,
Procedura przeglądu uprawnień użytkowników,
Procedura nadawania zdalnego dostępu (obejmująca użytkowników oraz dostawców usług).
Strona 82 z 161
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
uwierzytelnionemu użytkownikowi zgodnie z wytycznymi ITI- 43
na
pobranie
EDM
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ś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.
Strona 83 z 161
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
użytkownikowi poprzez okres retencji dokumentu.
z
udostępnieniem
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 metadanych .
Interface webservice pozwala na dodawanie dowolnych metadanych.
26.
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
Strona 84 z 161
e-R.1.1
Informacje podstawowe funkcjonowania e-Rejestracji
e-R.1.1.1
e-Rejestracja zostanie zainicjowana z portalu 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-Rejestracjaa 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-Rejestracjaa zintegrowanym lokalnym systemem
dziedzinowym HIS.
e-R.2
Rejestracja
Rejestracja wizyty
e-R.2.1
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
Strona 85 z 161
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
Strona 86 z 161
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
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
e-R.2.12.1.2
e-R.2.12.1.2.1
Unikalny NR Rejestracji z Systemu medycznego (HIS) w jednostce gdzie
została zapisana rejestracja
Strona 87 z 161
skutku, celem
potwierdzenia
e-R.2.12.1.2.2
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
e-R.2.13.3
e-R.2.13.3.1
podać treść
e-R.2.13.3.2
e-R.2.13.4
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
e-R.2.13.5
Wiadomości e-mail jest generowana automatycznie i zawiera część:
e-R.2.13.6
e-R.2.13.6.1
podać treść
e-R.2.13.6.2
e-R.2.13.7
e-R.2.13.7.1
e-R.2.13.7.2
e-R.2.13.7.3
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
e-R.2.16.0.1
podać treść
e-R.2.16.0.2
e-R.2.16.1
e-R.2.16.1.1
e-R.2.16.1.2
e-R.2.17
Wiadomość e-mail jest generowana automatycznie i zawiera część:
e-R.2.17.1
e-R.2.17.1.1
podać treść
e-R.2.17.1.2
e-R.2.17.2
Strona 88 z 161
e-R.2.17.2.1
e-R.2.17.2.2
e-R.2.17.2.3
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
e-R.2.18.1.1
e-R.2.18.1.1.1
podać treść
e-R.2.18.1.1.2
e-R.2.18.1.2
e-R.2.18.1.2.1
e-R.2.18.1.2.2
Stary termin wizyty
e-R.2.18.1.2.3
e-R.2.18.2
Wiadomość e-mail jest generowana automatycznie i zawiera część:
e-R.2.18.2.1
e-R.2.18.2.1.1
podać treść
e-R.2.18.2.1.2
e-R.2.18.2.2
e-R.2.18.2.2.1
zapisana Rejestracja
e-R.2.18.2.2.2
Stary termin wizyty
e-R.2.18.2.2.3
e-R.2.18.2.2.4
e-R.2.18.2.2.5
Zapisanie zmiany statusu rejestracji w historii moich danych na koncie
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
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
Strona 89 z 161
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
Strona 90 z 161
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
m.in. 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 5 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.
Strona 91 z 161
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
autoryzowanego kanału dystrybucji producenta.
nowe
i
pochodzić
z
W poniższej tabeli przedstawiono wykaz serwerowni do których w ramach przedmiotu zamówienia
zostanie przez Wykonawcę dostarczona infrastruktura:
Strona 92 z 161
Partner Projektu
Serwerownia
podstawowa –
lokalizacja
Serwerownia
zapasowa –
lokalizacja
Dodatkowe uwagi
Szpital Specjalistyczny im.
J. Śniadeckiego w Nowym
Sączu
33-300 Nowy Sącz,
Młyńska 5, Budynek
główny
33-300 Nowy Sącz,
Młyńska 5, Budynek
główny - RTG
Kompletna warstwa lokalna – serwerownia podstawowa
UTM/przełączniki ETHERNET w obu lokalizacjach - redundantnie (serwerownia podstawowa
oraz zapasowa)
J. Dietla w Krakowie
31-121 Kraków, ul.
Skarbowa 4
31-121 Kraków, ul
Focha 33
UTM/przełączniki ETHERNET w obu lokalizacjach - redundantnie (serwerownia podstawowa
oraz zapasowa)
Ludwika
Rydygiera
w
Krakowie
sp.
z
o.o.–
warstwa lokalna
os. Złotej Jesieni 1, 31-826
Kraków
Ludwika
Rydygiera
w
Krakowie
sp.
z
o.o.–
warstwa regionalna
os. Złotej Jesieni 1, 31-826
Kraków: poziom +I piętro
(naklejka serwerowni 1)
os. Złotej Jesieni 1,
31-826 Kraków:
poziom-1 piwnica
(centrala
telefonicznanaklejka
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 Archival grade. Licencje należy przekazać w wersji
papierowej, a w przypadku licencji w wersji elektronicznej, dodatkowo w postaci wydruku.
Oprogramowanie: zakup licencji
Repozytorium Lokalne EDM
Oprogramowania systemowe
Liczba (kpl.)
1
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
Liczba (kpl.)
1
Liczba (kpl.)
1
1
Oprogramowanie
do
zarządzania
1
-
monitorowania
1
1
1
System operacyjny
1
Liczba (kpl.)
Serwer Aplikacyjny
1
Serwer Pomocniczy
1
Serwer Bazodanowy
1
Szafa Rack
1
Macierz
1
Biblioteka taśmowa
1
Konsola KVM
1
2
Urządzenie UTM
2
1
Klimatyzacja
1
1
Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o.
Liczba (kpl.)
1
Liczba (kpl.)
1
1
1
1
1
1
System operacyjny
1
Liczba (kpl.)
Serwer Aplikacyjny
1
Serwer Pomocniczy
1
Serwer Bazodanowy
1
Szafa Rack
1
Macierz
1
Biblioteka taśmowa
1
Konsola KVM
1
Strona 95 z 161
2
Urządzenie UTM
2
1
Klimatyzacja
1
1
Infrastruktura podpisu elektronicznego, która zlokalizowana będzie w trzech Szpitalach jako element
warstwy lokalnej w projekcie przedstawia się następująco:
Liczba (kpl.)
Liczba (szt.)
Czytniki kart
700
Karty kryptograficzne
700
3
Naklejki
1400
Folia
11
Zestawy czyszczące
5
Czytniki kart
174
1
174
Czytniki kart
193
1
193
Szpital Specjalistyczny im. Ludwika Rydygiera w Krakowie sp. z o.o.
Czytniki kart
333
1
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.)
2
Strona 96 z 161
2
2
2
Oprogramowanie bazodanowe
2
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
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
7.1.1.1
Serwer Aplikacyjny
Liczba (kpl.)
2
7.1.1.2
2
Serwer Bazodanowy
7.1.1.3
2
Serwer Pomocniczy
7.1.1.4
2
Strona 97 z 161
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
Konsola KVM
2
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
2
7.5.2
2
7.5.3
2
7.5.4
Oprogramowanie do zarządzania - monitorowania infrastrukturą
sprzętową
2
7.5.5
System operacyjny
2
7.5.6.A
Oprogramowanie bazy danych - Region
2
7.5.7
2
Dla komponentu lokalnego:
Sekcja
Nazwa
7.1.2.1
Serwer Aplikacyjny
Liczba (kpl.)
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
Konsola KVM
3
7.3.1.2
UTM – Szpitale
6
7.3.3
Urządzenia podtrzymujące zasilanie – Szpitale
3
7.3.4
3
Strona 98 z 161
7.4.3
Klimatyzacja – Szpitale
3
7.5.1
3
7.5.2
3
7.5.3
3
7.5.4
Oprogramowanie do zarządzania - monitorowania infrastrukturą
sprzętową
3
7.5.5
System operacyjny
3
7.5.6.B
Oprogramowanie bazy danych - Szpitale
3
7.5.7
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
7.1.1.1.
Serwer Aplikacyjny
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
serwera
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.
Minimum2zainstalowane 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).
WYMSA.7.
Minimum 4 złącza typu 1GbEthernet RJ-45.
Strona 99 z 161
ID Wymagania
Opis wymagania
WYMSA.8.
Minimum jedna karta FC zapewniająca minimum 2 interfejsy FC,, każdy min.
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 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.
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 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.
7.1.1.2.
Serwer Bazodanowy
Poniżej przedstawiono wymagania dla Serwera Bazodanowego.
ID wymagania
Opis wymagania
WYMSB.1.
WYMSB.2.
Strona 100 z 161
ID wymagania
Opis wymagania
główna
musi
być
zaprojektowana
przez
producenta
serwera
WYMSB.3.
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.
WYMSB.4.
WYMSB.5.
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.
WYMSB.6.
Minimum 2 sloty PCI-Express generacji 3, w tym jeden slot x16 (szybkość slotu
– bus width).
WYMSB.7.
WYMSB.8.
Minimum jedna karta FC zapewniająca minimum 2 interfejsy FC,, każdy min.
8Gb.
WYMSB.9.
WYMSB.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 kontrolera dyskowego o
dodatkowe funkcje, takie jak RAID 6, 60.
WYMSB.11.
WYMSB.12.
WYMSB.13.
sprzętu.
optycznego.
d) Podłączanie
zdalnych
napędów
f) Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od
jego stanu (także podczas startu, restartu OS).
WYMSB.14.
WYMSB.15.
WYMSB.16.
Chłodzenie: 2 szt. (redundantne), hot plug.
WYMSB.17.
WYMSB.18.
Wspierane systemy operacyjne: Microsoft Windows 2012, Oracle Linux 6, Red
Strona 101 z 161
ID wymagania
Opis wymagania
WYMSB.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.
7.1.1.3.
Serwer Pomocniczy
Serwer pomocniczy pełni następujące funkcje: serwer backupu, serwer zarządzania, serwer testowy
(środowisko testowe), serwer wirtualizacji oraz serwera integracji.
ID wymagania
Opis wymagania
WYMSBZ.1.
WYMSBZ.2.
główna
musi
być
zaprojektowana
przez
producenta
serwera
WYMSBZ.3.
Procesory minimum sześciordzeniowy, x86 - 64 bity, osiągający w testach
SPECint_rate2006 wynik nie gorszy niż 310 punktów dla konfiguracji testowej z
dwoma procesorami. Zamawiający nie wymaga złożenia wraz z ofertą wyników w/w
testów.
WYMSBZ.4.
Minimum1zainstalowany procesor.
WYMSBZ.5.
w min. 24 gniazd na moduły pamięci. Możliwość instalacji w serwerze min. 768GB
WYMSBZ.6.
Minimum 6 slotów PCI-Express, w tym min. 1 sloty x16 (szybkość slotu – bus
width).
WYMSBZ.7.
WYMSBZ.8.
8 interfejsów FC 8Gb. Minimum 4 karty FC zapewniająca minimum 2 interfejsy FC,
każdy min. 8Gb.
WYMSBZ.9.
Wewnętrzne wnęki dyskowe przygotowane doinstalacji 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.
WYMSBZ.10.
zawartości pamięci cache w razie braku zasilania. Możliwe konfiguracje 0, 1, 10, 5,
50 Możliwość rozbudowy kontrolera dyskowego o dodatkowe funkcje, takie jak
RAID 6, 60.
WYMSBZ.11.
WYMSBZ.12.
WYMSBZ.13.
Strona 102 z 161
ID wymagania
Opis wymagania
instalacji specyficznych komponentów programowych producenta sprzętu.
optycznego.
d) Podłączanie
zdalnych
napędów
WYMSBZ.14.
WYMSBZ.15.
WYMSBZ.16.
WYMSBZ.17.
Możliwość zainstalowania modułu TPM na płycie
(w dedykowanym tylko dla tego modułu gnieździe/miejscu).
WYMSBZ.18.
Wspierane systemy operacyjne: Microsoft Windows 2012, Oracle Linux 6, Red Hat
Enterprise Linux 6, SUSE Linux Enterprise Server 11, VMware ESXi 5.
WYMSBZ.19.
Dostarczony system operacyjny: system operacyjny (OS)) wspierany na serwerze,
wymagany do instalacji i poprawnego działania oprogramowania do wykonywania
backupu wraz z niezbędnymi komponentami.
7.1.1.4.
głównej
serwera
Szafa RACK
Poniżej przedstawiono wymagania dla Szafy Rack.
ID wymagania
Opis wymagania
WYMRACK.1.
Szafa serwerowa 19” o wewnętrznej przestrzeni do montażu urządzeń 42U,
zewnętrzne wymiar szafy:





WYMRACK.2.
Wykonawca zobowiązany jest dostarczyć:



WYMRACK.3.
Wysokość max 210cm.
Szerokość max 100cm.
Głębokość max 113 cm.
Obciążenie statyczne szafy nie mniejsze niż 1300kg.
Drzwi przednie perforowane(perforacja na poziomie min. 80%), drzwi tylnie
dzielone – dwustronne.
Zestaw zaślepek (każda o wys. 1U, montowana bez użycia narzędzi)
pozwalających na zasłonięcie wolnego miejsca w szafie.
Stabilizator (zestaw elementów stabilizujących szafę) zapobiegający
wywróceniu szafy.
Zestaw elementów uziemiających.
Min. 2 PDU, każdy z zabezpieczeniem 32 A (moduły rozprowadzenia zasilania),
zapewniające
redundancję
podłączenia
zasilana
do
serwerów
i macierzy razem dostarczające min. 8 gniazd C19 (16A) i min. 48 gniazd C13.
7.1.2.Serwery- Szpitale
7.1.2.1.
Serwer Aplikacyjny
Poniżej przedstawiono wymagania dla Serwera Aplikacyjnego.
Strona 103 z 161
ID wymagania
Opis wymagania
WYMSP.1.
WYMSP.2.
główna
musi
być
zaprojektowana
przez
producenta
serwera
WYMSP.3.
SPECint_Baserate2006Basewynik 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.
WYMSP.4.
WYMSP.5.
Minimum min. 96GB pamięci RAM RDIMM.Serwer musi być wyposażony
WYMSP.6.
bus width).
WYMSP.7.
WYMSP.8.
Minimum dwie karty FC zapewniające minimum 4 interfejsy FC,, każdy
o przepustowości min. 8Gb
WYMSP.9.
Wewnętrzne wnęki dyskowe przygotowane do instalacji i działania minimum ośmiu
twarde każdy o parametrach: 300GB, prędkość obrotowa 10000 obrotów/minutę,
SAS 6G, Hot-Plug.
WYMSP.10.
50. Możliwość rozbudowy kontrolera dyskowego o dodatkowe funkcje, takie jak
RAID 6, 60.
WYMSP.11.
WYMSP.12.
WYMSP.13.
optycznego.
d) Podłączanie
zdalnych
napędów
WYMSP.14.
WYMSP.15.
Strona 104 z 161
ID wymagania
Opis wymagania
WYMSP.16.
WYMSP.17.
WYMSP.18.
Wspierane systemy operacyjne: Microsoft Windows 2012R2, Oracle Linux 6, Red
WYMSP.19.
7.1.2.2.
Serwer Bazodanowy
Poniżej przedstawiono wymagania dla Serwera Bazy danych.
ID wymagania
Opis wymagania
WYMSZSB.1.
WYMSZSB.2.
główna
musi
być
zaprojektowana
przez
producenta
serwera
WYMSZSB.3.
Procesory minimum sześciordzeniowy, x86 - 64 bity, osiągający w testach
SPECint_rate2006 wynik nie gorszy niż 500 punktów dla konfiguracji testowej z
dwoma procesorami. Zamawiający nie wymaga złożenia wraz z ofertą wyników
w/w testów.
WYMSZSB.4.
Minimum1 zainstalowany procesor.
WYMSZSB.5.
WYMSZSB.6.
bus width).
WYMSZSB.7.
WYMSZSB.8.
Minimum dwie karty FC zapewniająca minimum 4 interfejsy FC,, każdy
o przepustowości min. 8Gb.
WYMSZSB.9.
WYMSZSB.10.
zawartości pamięci cache w razie braku zasilania. Możliwe konfiguracje 0, 1, 10,
5, 50 Możliwość rozbudowy kontrolera dyskowego o dodatkowe funkcje, takie jak
RAID 6, 60.
WYMSZSB.11.
Strona 105 z 161
ID wymagania
Opis wymagania
WYMSZSB.12.
WYMSZSB.13.
sprzętu.
optycznego.
d) Podłączanie
zdalnych
napędów
WYMSZSB.14.
WYMSZSB.15.
WYMSZSB.16.
WYMSZSB.17.
WYMSZSB.18.
WYMSZSB.19.
Dostarczony system operacyjny: system operacyjny (OS) wspierany na serwerze,
7.1.2.3. Serwer Pomocniczy
Serwer pomocniczy pełniący następujące funkcje: serwer backupu, serwer zarządzania, serwer
testowy (środowisko testowe), serwer wirtualizacji oraz serwera integracji.
ID wymagania
Opis wymagania
WYMSP.1.
WYMSP.2.
główna
musi
być
zaprojektowana
przez
producenta
serwera
WYMSP.3.
SPECint_Baserate2006Basewynik 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.
WYMSP.4.
WYMSP.5.
Minimum min. 96GB pamięci RAM RDIMM.Serwer musi być wyposażony
Strona 106 z 161
ID wymagania
Opis wymagania
WYMSP.6.
bus width).
WYMSP.7.
WYMSP.8.
Minimum dwie karty FC zapewniające minimum 4 interfejsy FC,, każdy
o przepustowości min. 8Gb
WYMSP.9.
Wewnętrzne wnęki dyskowe przygotowane do instalacji i działania minimum ośmiu
twarde każdy o parametrach: 300GB, prędkość obrotowa 10000 obrotów/minutę,
SAS 6G, Hot-Plug.
WYMSP.10.
50. Możliwość rozbudowy kontrolera dyskowego o dodatkowe funkcje, takie jak
RAID 6, 60.
WYMSP.11.
WYMSP.12.
WYMSP.13.
g) Zdalne włączanie/wyłączanie/restart.
h) Zdalny dostęp z poziomu przeglądarki internetowej, bez konieczności
Zdalną identyfikację fizycznego serwera za pomocą sygnalizatora
optycznego.
j) Podłączanie
zdalnych
napędów
k) Podgląd logów sprzętowych serwera i karty.
l) Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od jego
i)
WYMSP.14.
WYMSP.15.
WYMSP.16.
WYMSP.17.
WYMSP.18.
WYMSP.19.
7.1.2.4.
Szafa RACK
Wykonawca musi dostarczyć poniżej określoną szafę typu Rack do każdego Partnera Projektu
zgodnie z tabelą z rozdziału 7.
ID wymagania
Opis wymagania
WYMRACK.1.
Szafa serwerowa 19” o wewnętrznej przestrzeni do montażu urządzeń 42U,
zewnętrzne wymiar szafy:
Strona 107 z 161
ID wymagania
Opis wymagania





WYMRACK.2.
Wykonawca zobowiązany jest dostarczyć:



WYMRACK.3.
Wysokość max 210cm.
Szerokość max 100cm.
Głębokość max 113 cm.
Obciążenie statyczne szafy nie mniejsze niż 1300kg.
Drzwi przednie perforowane(perforacja na poziomie min. 80%), drzwi tylnie
dzielone – dwustronne.
Zestaw zaślepek (każda o wys. 1U, montowana bez użycia narzędzi)
pozwalających na zasłonięcie wolnego miejsca w szafie.
Stabilizator (zestaw elementów stabilizujących szafę) zapobiegający
wywróceniu szafy.
Zestaw elementów uziemiających.
Min. 2 PDU, każdy z zabezpieczeniem 32 A (moduły rozprowadzenia zasilania),
zapewniające
redundancję
podłączenia
zasilana
do
serwerów
i macierzy razem dostarczające min. 8 gniazd C19 (16A) i min. 48 gniazd C13.
7.1.3.Pamięci masowe
7.1.3.1.
Macierz – Region
Poniżej przedstawiono wymagania dla Macierzy dla warstwy regionalnej.
ID wymagania
Opis wymagania
WYMRM.1.
Zamawiający nie dopuszcza rozwiązań opartych o wirtualizator zasobów
dyskowych, gdzie kilka urządzeń fizycznych posiadających niezależne porty do
transmisji danych oraz posiadające niezależną pamięć buforująca Cache
maskowane
są
przez
kontroler
bądź
kontrolery
z zainstalowanym
oprogramowaniem wirtualizującym zasoby dyskowe.
WYMRM.2.
Macierz musi być przystosowana do zamontowania w oferowanej szafie rack 19’’
wraz z zestawem szyn montażowych oraz kompletem kabli zasilających.
WYMRM.3.
Wysokość obudowy maksymalnie powinna wynosić 8U.
WYMRM.4.
Pojemność dyskowa dla danych produkcyjnych:
Sumaryczna pojemność 14,4 TB lub więcej w postaci 24 szt. identycznych dysków.
Każdy dysk o następujących parametrach:
a) wartość średniego czasu dostępu podawana przez producenta sprzętu dla
oferowanego typu dysku maksymalnie 8.5 ms lub mniej,
b) wyposażony w 2 szt. lub więcej portów SAS lub FC każdy
o przepustowości 6Gb/s lub więcej.
WYMRM.5.
Pojemność dyskowa dla systemu backupu i archiwizacji danych:
Sumaryczna pojemność 24 TB lub więcej w postaci 8 szt. identycznych dysków.
WYMRM.6.
Dyski muszą być wymieniane podczas pracy systemu dyskowego bez konieczności
przerywania obsługi serwerów.
WYMRM.7.
Musi istnieć możliwość rozbudowy Macierzy Dyskowej do co najmniej 96 Dysków
Strona 108 z 161
ID wymagania
Opis wymagania
Twardych w celu powiększenia przez Zamawiającego dostępnej pojemności
dyskowej dla danych produkcyjnych albo pojemności dyskowej dla danych
archiwizacji.
Zamawiający dopuszcza rozbudowę Macierzy Dyskowej jedynie poprzez
dołączenie dodatkowych półek dyskowych do zaoferowanej Macierzy Dyskowej.
Zaoferowana Macierz Dyskowa musi posiadać komplet licencji pozwalających na
obsługę co najmniej 96 dysków twardych dowolnej wielkości.
WYMRM.8.
Oferowana Macierz Dyskowa musi posiadać funkcjonalność:
a) Tworzenia jednego z wybranych poziomów RAID 0,1,1+0, 5,5+0,6 na
wszystkich zaoferowanych i dostępnych dyskach twardych danego typu.
b) Tworzenie Globalnego dysku spare.
c) Wykonywania na żądanie, przy pomocy wyłącznie mechanizmów Macierzy
Dyskowej i bez przerywania pracy serwerów korzystających z zasobów tej
macierzy, 64 lub więcej kopii tych samych danych w ramach systemu
dyskowego bez potrzeby rezerwowania dodatkowej przestrzeni dyskowej
na potrzeby tej kopii.
WYMRM.9.
Możliwość rozbudowy Macierzy Dyskowej o funkcjonalność zdalnej replikacji
danych (bez przerywania pracy systemu produkcyjnego) pomiędzy co najmniej
jedną macierzą dyskową tego samego typu co zaoferowana Macierz Dyskowa.
WYMRM.10.
Zdalna replikacja musi odbywać się przy wykorzystaniu jedynie zasobów
sprzętowych Macierzy Dyskowej w trybie asynchronicznym.
WYMRM.11.
Rozbudowa o opisaną funkcjonalność zdalnej replikacji musi odbyć się przez
instalację dodatkowych licencji, bez konieczności dokupowania dodatkowych
elementów sprzętowych.
WYMRM.12.
Macierz musi być wyposażona w co najmniej dwa kontrolery dyskowe, każdy z nich
wyposażony w co najmniej 4 szt. portów FC 8Gb.
WYMRM.13.
Standard FC 8 Gb:
a) wszystkie porty połączone w taki sposób aby występowała transmisja
blokowa pomiędzy oferowanymi serwerami a macierzą dyskową.
b) co najmniej 4 pary (8szt.) portów FC 8Gb.
c) każdy port o paśmie 8Gb/s lub więcej.
d) co najmniej dwie pary portów (4szt.) musi znajdować się na osobnym
kontrolerze dyskowym, tak aby w razie awarii jednego z kontrolerów nie
następowała przerwa w dostępie do zasobów dyskowych macierzy.
e) na każde 2 pary portów (4szt) musi przypadać co najmniej 4GB pamięci
buforującej zapisy i odczyty. Pamięć buforująca musi być nieulotna lub
podtrzymywana bateryjnie.
f) do każdego portu macierzy FC 8Gb należy dostarczyć zestaw kabli o
długości co najmniej 5mb umożliwiających podłączenie macierzy do portów
FC 8Gb zaoferowanych przełączników FC 8GB opisanych powyżej.
WYMRM.14.
Standard ETHERNET :

WYMRM.15.
co najmniej 1 port w standardzie ETHERNET min. 100 Mb/s umożliwiający
dostęp do systemu zarządzania oferowaną macierzą dyskową
Nadmiarowy, odporny na awarię połowy zasilaczy, system zasilania wymienny
podczas pracy systemu dyskowego, bez konieczności przerywania zadań
Strona 109 z 161
ID wymagania
Opis wymagania
wykonywanych przez system.
W konfiguracji maksymalnej dla danego systemu dyskowego przewidzianego przez
producenta systemu.
WYMRM.16.
Nadmiarowy, odporny na awarię połowy wentylatorów, system chłodzenia
wymienny podczas pracy systemu dyskowego, bez konieczności przerywania
zadań wykonywanych przez system.
producenta systemu.
7.1.3.2.
Macierz – Szpitale
Poniżej przedstawiono wymagania dla macierzy zlokalizowanej w warstwie lokalnej.
ID wymagania
Opis wymagania
WYMSZM.1.
Zamawiający nie dopuszcza rozwiązań opartych o wirtualizator zasobów
dyskowych, gdzie kilka urządzeń fizycznych posiadających niezależne porty do
transmisji danych oraz posiadające niezależną pamięć buforująca Cache
maskowane
są
przez
kontroler
bądź
kontrolery
z zainstalowanym
oprogramowaniem wirtualizującym zasoby dyskowe.
WYMSZM.2.
Macierz musi być przystosowana do zamontowania w oferowanej szafie Rack 19’’
wraz z zestawem szyn montażowych oraz kompletem kabli zasilających.
WYMSZM.3.
Wysokość obudowy maksymalnie powinna wynosić 8U.
WYMSZM.4.
Pojemność dyskowa dla danych produkcyjnych:
WYMSZM.5.
Pojemność dyskowa dla systemu backupu i archiwizacji danych:
WYMSZM.6.
Dyski muszą być wymieniane podczas pracy systemu dyskowego bez konieczności
przerywania obsługi serwerów.
WYMSZM.7.
Musi istnieć możliwość rozbudowy Macierzy Dyskowej do co najmniej 96 Dysków
Twardych w celu powiększenia przez Zamawiającego dostępnej pojemności
dyskowej dla danych produkcyjnych albo pojemności dyskowej dla danych
archiwizacji. Zamawiający dopuszcza rozbudowę Macierzy Dyskowej jedynie
poprzez dołączenie dodatkowych półek dyskowych do zaoferowanej Macierzy
Dyskowej. Zaoferowana Macierz Dyskowa musi posiadać komplet licencji
pozwalających na obsługę co najmniej 96 dysków twardych dowolnej wielkości.
Strona 110 z 161
ID wymagania
Opis wymagania
WYMSZM.8.
Oferowana Macierz Dyskowa musi posiadać funkcjonalność:
a) Tworzenia jednego z wybranych poziomów RAID 0,1,1+0, 5,5+0,6 na
wszystkich zaoferowanych i dostępnych dyskach twardych danego typu.
b) Tworzenie Globalnego dysku spare.
c) Wykonywania na żądanie, przy pomocy wyłącznie mechanizmów Macierzy
Dyskowej i bez przerywania pracy serwerów korzystających z zasobów tej
macierzy, 64 lub więcej kopii tych samych danych w ramach systemu
dyskowego bez potrzeby rezerwowania dodatkowej przestrzeni dyskowej
na potrzeby tej kopii.
WYMSZM.9.
Możliwość rozbudowy Macierzy Dyskowej o funkcjonalność zdalnej replikacji
danych (bez przerywania pracy systemu produkcyjnego) pomiędzy co najmniej
jedną macierzą dyskową tego samego typu co zaoferowana Macierz Dyskowa.
WYMSZM.10.
Zdalna replikacja musi odbywać się przy wykorzystaniu jedynie zasobów
sprzętowych Macierzy Dyskowej w trybie asynchronicznym.
WYMSZM.11.
Rozbudowa o opisaną funkcjonalność zdalnej replikacji musi odbyć się przez
instalację dodatkowych licencji, bez konieczności dokupowania dodatkowych
elementów sprzętowych.
WYMSZM.12.
Macierz musi być wyposażona w co najmniej dwa kontrolery dyskowe, każdy z nich
wyposażony w co najmniej 1 szt. portów SAS.
WYMSZM.13.
Standard FC 8 Gb:
a) wszystkie porty połączone w taki sposób aby występowała transmisja
blokowa pomiędzy oferowanymi serwerami a macierzą dyskową
b) co najmniej 4 pary (8szt.) portów FC 8Gb.
c) każdy port o paśmie 8Gb/s lub więcej.
d) co najmniej dwie pary portów (4szt.) musi znajdować się na osobnym
kontrolerze
dyskowym,
tak
aby
w
razie
awarii
jednego
z kontrolerów nie następowała przerwa w dostępie do zasobów dyskowych
macierzy.
e) na każde 2 pary portów (4szt) musi przypadać co najmniej 4GB pamięci
buforującej zapisy i odczyty. Pamięć buforująca musi być nieulotna lub
podtrzymywana bateryjnie.
f) do każdego portu macierzy FC 8Gb należy dostarczyć zestaw kabli
o długości co najmniej 5mb umożliwiających podłączenie macierzy do
portów FC 8Gb zaoferowanych przełączników FC 8GB opisanych powyżej.
WYMSZM.14.
Standard ETHERNET :

WYMSZM.15.
co najmniej 1 sztuka port w standardzie ETHERNET min. 100 Mb/s
umożliwiający dostęp do systemu zarządzania oferowaną macierzą
dyskową
Nadmiarowy, odporny na awarię połowy zasilaczy, system zasilania wymienny
podczas pracy systemu dyskowego, bez konieczności przerywania zadań
wykonywanych przez system.
producenta systemu.
WYMSZM.16.
Nadmiarowy, odporny na awarię połowy wentylatorów, system chłodzenia
wymienny podczas pracy systemu dyskowego, bez konieczności przerywania
Strona 111 z 161
ID wymagania
Opis wymagania
zadań wykonywanych przez system.
producenta systemu.
7.1.3.3.
Biblioteka taśmowa
Poniżej przedstawiono wymagania dla biblioteki taśmowej dla warstwy regionalnej oraz lokalnej.
ID wymagania
Opis wymagania
WYMBT.1.
Biblioteka musi być przystosowana do zamontowania w oferowanej szafie Rack
19’’ wraz z zestawem szyn montażowych oraz kompletem kabli zasilających
o wysokości maksymalnie 2U.
WYMBT.2.
Co najmniej 8 slotów przeznaczonych na zestaw taśm składających się z:
a) 8 sztuk taśm w standardzie LTO5 lub lepszym o pojemności co najmniej 3
TB każda.
b) 1 szt. taśmy czyszczącej
c) zestawu kodów kreskowych w celu identyfikacji każdej z dostarczonych
taśm.
WYMBT.3.
Co najmniej 1 port FC 8Gb/s w standardzie umożliwiającym podłączenie do portu
FC przełącznika FC.
WYMBT.4.
Wyposażony w co najmniej 1 napęd o parametrach:
a) standard LTO5 lub lepszy.
b) przepustowość co najmniej 980 GB/hr przy kompresji 2:1
7.2. Komunikacja
Sekcja przedstawia zestawienie elementów infrastruktury telekomunikacyjnej niezbędnych do
realizacji projektu wraz z wyszczególnieniem ich parametrów technicznych.
7.2.1.Przełączniki
7.2.1.1.
Przełącznik Fiber Channel – Region
Poniżej przedstawiono wymagania dla Przełączników Fiber Channel, które dostarczone muszą być dla
warstwy regionalnej.
ID wymagania
Opis wymagania
WYMFBC.1.
Przełącznik musi posiadać, co najmniej 24 porty FC. Co najmniej 24 porty muszą
być aktywne i obsadzone wkładkami 8Gb SFP SW.
WYMFBC.2.
Przełącznik musi obsługiwać minimum porty typu: E_Port, F_Port, M_Port.
WYMFBC.3.
Przełącznik musi posiadać minimum dwa zasilacze i dwa wentylatory.
WYMFBC.4.
Przełącznik musi obsługiwać minimum następujące systemy operacyjne: Windows
Server 2008, Windows 2003, Windows 2012, Windows 2012R2, Red Hat Linux,
Red Hat Linux Advanced Server, SUSE Linux, SUSE Linux Enterprise Server
(SLES).
WYMFBC.5.
Zagregowana przepustowość przełącznika musi wynosić minimum 768Gb/s full
duplex.(chodzi tu możliwości potencjalne przełącznika).
Strona 112 z 161
ID wymagania
Opis wymagania
WYMFBC.6.
Zarządzanie przełącznikiem musi się odbywać minimum za pomocą: przeglądarki
WWW, programu Telnet oraz protokołu SNMP.
WYMFBC.7.
Przełącznik musi umożliwiać instalację w standardowej szafie Rack 19”.
WYMFBC.8.
Przełącznik musi posiadać funkcję definiowania tzw. Stref (ang. Zoning).
WYMFBC.9.
Przełącznik musi posiadać możliwość agregowania pojedynczych połączeń
w jedno logiczne połączenie (ISL Trunking) po dokupieniu odpowiedniej licencji w
przyszłości.
WYMFBC.10.
Urządzenie musi zostać skonfigurowane
na docelowym
środowisku
Zamawiającego, a jego konfiguracja musi zostać udokumentowana dla
i w oparciu o dostarczoną infrastrukturę sprzętową i dostarczone licencje
oprogramowania. Konfiguracja musi uwzględniać wydzielenie stref bezpieczeństwa
w
oparciu
o
specyfikę
przetwarzanych
danych
w
systemie
i uwzględniając komunikację z urządzeń mobilnych.
7.2.1.2.
Przełącznik Ethernet - Region
Poniżej przedstawiono wymagania dla przełączników Ethernet zlokalizowanych w warstwie
regionalnej.
ID wymagania
Opis wymagania
WYMRETH.1.
Przełącznik musi być dedykowanym urządzeniem sieciowym przystosowanym do
montażu w szafie Rack.
WYMRETH.2.
Przełącznik musi posiadać nie mniej niż 48 porty dostępowe Ethernet
10/100/1000 BASE-T
WYMRETH.3.
Przełącznik musi mieć możliwość zamontowania co najmniej 4 portów typu uplink
1 Gbe SFP, lub zamiennie 2 portów 10 Gbe SFP+
WYMRETH.4.
Jeżeli do zamontowania portów typu uplink wymagany jest dodatkowy moduł, taki
moduł należy dostarczyć wraz z przełącznikiem.
WYMRETH.5.
Porty typu uplink 1 Gbe SFP muszą obsługiwać moduły SFP następujących
standardów:1000BASE-T, 1000BASE-SX, 1000BASE-LH
WYMRETH.6.
Porty typu uplink 10 GbE SFP+ muszą obsługiwać moduły SFP+ następujących
standardów:10GBASE-SR, 10GBASE-LR, 10GBASE-LRM
WYMRETH.7.
Wszystkie porty dostępowe oraz porty typu uplink muszą być aktywne w tym
samym momencie – nie dopuszcza się rozwiązania wykorzystującego zamiennie
portów dostępowych lub portów typu uplink
WYMRETH.8.
Przełącznik musi
wewnętrznego.
WYMRETH.9.
Przełącznik musi posiadać port konsoli
WYMRETH.10.
Przełącznik musi być wyposażony w nie mniej niż 512 MB pamięci Flash oraz 512
MB pamięci DRAM.
WYMRETH.11.
Przełącznik musi posiadać slot umożliwiający podłączenie zewnętrznego nośnika
danych lub posiada wsparcie dla protokołów, które dają możliwość
magazynowania konfiguracji i obrazów oprogramowania na zewnętrznym
mieć
możliwość
Strona 113 z 161
podłączenia
redundantnego
zasilana
ID wymagania
Opis wymagania
urządzeniu.
WYMRETH.12.
zarządzanie przełącznikiem musi odbywać się przy pomocy linii komend CLI
przez port konsoli, telnet, sshv1, sshv2, oraz przy pomocy interfejsu WWW
z wykorzystaniem protokołów http oraz https
WYMRETH.13.
Przełącznik musi posiadać możliwość zarządzania i monitorowania przez
centralny system
zarządzania i monitorowania.
WYMRETH.14.
Musi istnieć możliwość definiowania wielu poziomów dostępu administracyjnego
do urządzenia
WYMRETH.15.
Na przełączniku musi istnieć możliwość zdefiniowania wielu użytkowników, którzy
będą zarządzać urządzeniem.
WYMRETH.16.
Uwierzytelnianie administratorów musi odbywać się z użyciem: lokalnej bazy
skonfigurowanej na przełączniku, przy pomocy protokołu RADIUS oraz TACACS+
WYMRETH.17.
Przełącznik musi mieć możliwość synchronizacji zegara czasu za pomocą
protokołu NTP
WYMRETH.18.
Przełącznik musi obsługiwać protokół SNMP w wersji v1, v2c,,v3
WYMRETH.19.
Przełącznik musi obsługiwać co najmniej 32 000 adresów MAC
WYMRETH.20.
Przełącznik musi obsługiwać ramki Jumbo (9216 bajtów)
WYMRETH.21.
Przełącznik musi obsługiwać sieci VLAN zgodne ze standardem 802.1Q
WYMRETH.22.
Ilość obsługiwanych VLAN-ID nie może być mniejsza niż 4000.
WYMRETH.23.
Przynależność portów do wybranych sieci VLAN musi być oparta na: manualnej
konfiguracji przynależności portu do sieci VLAN, na podstawie adresu MAC
podłączonego urządzenia oraz z wykorzystaniem protokołu 802.1x
WYMRETH.24.
Przełącznik musi wspierać Private VLAN (PVLAN)
WYMRETH.25.
Przełącznik musi wspierać protokół 802.1x
WYMRETH.26.
Urządzenie musi obsługiwać agregację połączeń zgodnie ze standardem 802.3ad
WYMRETH.27.
Przełącznik musi mieć możliwość zgrupowania co najmniej 8 połączeń w jednym
zagregowanym połączeniu
WYMRETH.28.
Przełącznik musi być kompatybilny z protokołem Spanning Tree 802.1d
WYMRETH.29.
Przełącznik musi być kompatybilny z protokołem Rapid Spanning Tree 802.1w
WYMRETH.30.
Przełącznik musi obsługiwać protokół Multiple Spanning Tree 802.1s
WYMRETH.31.
Przełącznik musi zapewniać ochronę aktywnej topologii Spanning Tree, dzięki
takim mechanizmom jak: BPDU guard/protect, Loop guard/protect, Root
guard/protect lub dzięki innym, analogicznym mechanizmom
WYMRETH.32.
Przełącznik musi obsługiwać protokół LLDP oraz LLDP-MED.
WYMRETH.33.
Przełącznik musi obsługiwać routing pomiędzy podsieciami VLAN (Inter-VLAN
routing)
WYMRETH.34.
Przełącznik musi mieć możliwość konfiguracji tras statycznych oraz obsługiwać
Strona 114 z 161
ID wymagania
Opis wymagania
protokoły routingu dynamicznego RIP, OSPF,
WYMRETH.35.
Urządzenie musi obsłużyć co najmniej 12 000 tras routingu
WYMRETH.36.
Przełącznik musi obsługiwać funkcjonalność PBR (Policy Based Routing);
WYMRETH.37.
Musi istnieć możliwość obsługi protokołów routingu: BGP, oraz IS-IS. W celu
obsługi tych protokołów dopuszcza się możliwość wykupienia licencji, lub zakup
wyższej wersji oprogramowania, które obsłuży protokoły routingu wymienione
w tym punkcie. Na obecnym etapie wdrożenia, licencja nie musi być dostarczona
wraz z urządzeniem.
WYMRETH.38.
Przełącznik musi wspierać protokół VRRP (Virtual Router Redundancy Protocol)
WYMRETH.39.
Urządzenie musi posiadać mechanizmy priorytetyzowania i zarządzania ruchem
sieciowym (QoS) w warstwie 2 i 3
WYMRETH.40.
Musi istnieć możliwość klasyfikacji ruchu na podstawie: interfejsu, adresu MAC,
adresu IP, portówTCP/IP, sieci VLAN, pól: 802.1p, DSCP/IP Precedence
WYMRETH.41.
Urządzenie musi mieć możliwość filtracji ruchu (listy kontroli dostępu ACL) na
podstawie kryteriów z warstw 2-4
WYMRETH.42.
Przełącznik musi obsługiwać filtrację ruchu (listy kontroli dostępu ACL) na
poziomie pojedynczego portu fizycznego, jak i na poziomie interfejsu logicznego
VLAN (filtracja ruchu pomiędzy sieciami VLAN)
WYMRETH.43.
Musi istnieć możliwość logowania lub zliczania pakietów, które odpowiadają
kryteriom zawartym w regułach filtrowania ruchu ACL
WYMRETH.44.
Ilość możliwych do skonfigurowania reguł filtrowania ruchu ACL nie może być
mniejsza niż 7000
WYMRETH.45.
Przełącznik musi obsługiwać następujące mechanizmy bezpieczeństwa:
limitowanie adresów MAC na porcie, konfiguracja dozwolonych adresów MAC na
porcie, DHCP snooping, Dynamic ARP Inspection, IP source guard.
WYMRETH.46.
Przełącznik musi posiadać możliwość uruchomienia funkcjonalności DHCP:
DHCP Server oraz DHCP Relay
WYMRETH.47.
Przełącznik musi zapewniać obsługę
funkcjonalność IGMP oraz IGMP snooping
WYMRETH.48.
Przełącznik musi obsługiwać protokoły routingu multicast: PIM-SM, PIM-SSM,
PIM-DM
WYMRETH.49.
Urządzenie musi mieć możliwość kopiowania ruchu z jednego wybranego portu
na inny wskazany port w celu analizy tego ruchu (port mirroring)
WYMRETH.50.
Musi istnieć możliwość połączenia kilku przełączników tej samej rodziny w stos.
WYMRETH.51.
Przełączniki połączone w stos z punktu widzenia sieci powinny być widziane jako
jeden przełącznik. (Np.: musi istnieć możliwość stworzenia agregacji połączeń z
użyciem protokołu 802.3ad dla portów znajdujących się na różnych
przełącznikach, ale będących częścią tego samego stosu)
WYMRETH.52.
Przełączniki połączone w stos powinny być traktowane jako jeden przełącznik
przez protokół Spanning Tree
WYMRETH.53.
Przełączniki
tworzące
stos
muszą
być
Strona 115 z 161
ruchu
Multicast,
zarządzane,
oraz
posiadać
jakby były jednym
ID wymagania
Opis wymagania
przełącznikiem
WYMRETH.54.
WYMRETH.55.
7.2.1.3.
Urządzenie musi zostać skonfigurowane na docelowym środowisku
Zamawiającego, a jego konfiguracja musi zostać udokumentowana dla i w oparciu
o dostarczoną infrastrukturę sprzętową i dostarczone licencje oprogramowania.
Konfiguracja musi uwzględniać wydzielenie stref bezpieczeństwa w oparciu
o specyfikę przetwarzanych danych w systemie i uwzględniając komunikację
z urządzeń mobilnych.
Przełącznik Ethernet - Szpitale
Poniżej przedstawiono wymagania dla przełączników Ethernet zlokalizowanych na poziomie Szpitali.
ID wymagania
Opis wymagania
WYMSZETH.1.
Przełącznik musi być dedykowanym urządzeniem sieciowym przystosowanym do
montażu w szafie Rack.
WYMSZETH.2.
Przełącznik musi posiadać nie mniej niż 48 porty dostępowe Ethernet
10/100/1000 BASE-T
WYMSZETH.3.
Przełącznik musi mieć możliwość zamontowania co najmniej 4 portów typu uplink
1 Gbe SFP, lub zamiennie 2 portów 10 Gbe SFP+
WYMSZETH.4.
Jeżeli do zamontowania portów typu uplink wymagany jest dodatkowy moduł, taki
moduł należy dostarczyć wraz z przełącznikiem.
WYMSZETH.5.
Porty typu uplink 1 Gbe SFP muszą obsługiwać moduły SFP następujących
standardów:1000BASE-T, 1000BASE-SX, 1000BASE-LH.
WYMSZETH.6.
Porty typu uplink 10 GbE SFP+ muszą obsługiwać moduły SFP+ następujących
standardów:10GBASE-SR, 10GBASE-LR, 10GBASE-LRM
WYMSZETH.7.
Wszystkie porty dostępowe oraz porty typu uplink muszą być aktywne w tym
samym momencie – nie dopuszcza się rozwiązania wykorzystującego zamiennie
portów dostępowych lub portów typu uplink
WYMSZETH.8.
Przełącznik musi
wewnętrznego.
WYMSZETH.9.
Przełącznik musi posiadać port konsoli
mieć
możliwość
podłączenia
redundantnego
zasilana
WYMSZETH.10. Przełącznik musi być wyposażony w nie mniej niż512 MBMB pamięci Flash oraz
512 MB pamięci DRAM.
WYMSZETH.11. Przełącznik musi posiadać slot umożliwiający podłączenie zewnętrznego nośnika
danych lub posiada wsparcie dla protokołów, które dają możliwość
magazynowania konfiguracji i obrazów oprogramowania na zewnętrznym
urządzeniu.
WYMSZETH.12. zarządzanie przełącznikiem musi odbywać się przy pomocy linii komend CLI
przez port konsoli, telnet, sshv1, sshv2, oraz przy pomocy interfejsu WWW
z wykorzystaniem protokołów http oraz https
WYMSZETH.13. Przełącznik musi posiadać możliwość zarządzania i monitorowania przez
Strona 116 z 161
ID wymagania
Opis wymagania
centralny system
zarządzania i monitorowania.
WYMSZETH.14. Musi istnieć możliwość definiowania wielu poziomów dostępu administracyjnego
do urządzenia
WYMSZETH.15. Na przełączniku musi istnieć możliwość zdefiniowania wielu użytkowników, którzy
będą zarządzać urządzeniem.
WYMSZETH.16. Uwierzytelnianie administratorów musi odbywać się z użyciem: lokalnej bazy
skonfigurowanej na przełączniku, przy pomocy protokołu RADIUS oraz TACACS+
WYMSZETH.17. Przełącznik musi mieć możliwość synchronizacji zegara czasu za pomocą
protokołu NTP
WYMSZETH.18. Przełącznik musi obsługiwać protokół SNMP w wersji v1, v2c,,v3
WYMSZETH.19. Przełącznik musi obsługiwać co najmniej 32 000 adresów MAC
WYMSZETH.20. Przełącznik musi obsługiwać ramki Jumbo (9216 bajtów)
WYMSZETH.21. Przełącznik musi obsługiwać sieci VLAN zgodne ze standardem 802.1Q
WYMSZETH.22. Ilość obsługiwanych VLAN-ID nie może być mniejsza niż 4000.
WYMSZETH.23. Przynależność portów do wybranych sieci VLAN musi być oparta na: manualnej
konfiguracji przynależności portu do sieci VLAN, na podstawie adresu MAC
podłączonego urządzenia oraz z wykorzystaniem protokołu 802.1x
WYMSZETH.24. Przełącznik musi wspierać Private VLAN (PVLAN)
WYMSZETH.25. Przełącznik musi wspierać protokół 802.1x
WYMSZETH.26. Urządzenie musi obsługiwać agregację połączeń zgodnie ze standardem 802.3ad
WYMSZETH.27. Przełącznik musi mieć możliwość zgrupowania co najmniej 8 połączeń w jednym
zagregowanym połączeniu
WYMSZETH.28. Przełącznik musi być kompatybilny z protokołem Spanning Tree 802.1d
WYMSZETH.29. Przełącznik musi być kompatybilny z protokołem Rapid Spanning Tree 802.1w
WYMSZETH.30. Przełącznik musi obsługiwać protokół Multiple Spanning Tree 802.1s
WYMSZETH.31. Przełącznik musi zapewniać ochronę aktywnej topologii Spanning Tree, dzięki
takim mechanizmom jak: BPDU guard/protect, Loop guard/protect, Root
guard/protect lub dzięki innym, analogicznym mechanizmom
WYMSZETH.32. Przełącznik musi obsługiwać protokół LLDP oraz LLDP-MED.
WYMSZETH.33. Przełącznik musi obsługiwać routing pomiędzy podsieciami VLAN (Inter-VLAN
routing)
WYMSZETH.34. Przełącznik musi mieć możliwość konfiguracji tras statycznych oraz obsługiwać
protokoły routingu dynamicznego RIP, OSPF,
WYMSZETH.35. Urządzenie musi obsłużyć co najmniej 12 000 tras routingu.
WYMSZETH.36. Przełącznik musi obsługiwać funkcjonalność PBR (Policy Based Routing);
WYMSZETH.37. Musi istnieć możliwość obsługi protokołów routingu: BGP, oraz IS-IS. W celu
obsługi tych protokołów dopuszcza się możliwość wykupienia licencji, lub zakup
Strona 117 z 161
ID wymagania
Opis wymagania
wyższej wersji oprogramowania, które obsłuży protokoły routingu wymienione w
tym punkcie. Na obecnym etapie wdrożenia, licencja nie musi być dostarczona
wraz z urządzeniem.
WYMSZETH.38. Przełącznik musi wspierać protokół VRRP (Virtual Router Redundancy Protocol)
WYMSZETH.39. Urządzenie musi posiadać mechanizmy priorytetyzowania i zarządzania ruchem
sieciowym (QoS) w warstwie 2 i 3
WYMSZETH.40. Musi istnieć możliwość klasyfikacji ruchu na podstawie: interfejsu, adresu MAC,
adresu IP, portów TCP/IP, sieci VLAN, pól: 802.1p, DSCP/IP Precedence
WYMSZETH.41. Urządzenie musi mieć możliwość filtracji ruchu (listy kontroli dostępu ACL) na
podstawie kryteriów z warstw 2-4
WYMSZETH.42. Przełącznik musi obsługiwać filtrację ruchu (listy kontroli dostępu ACL) na
poziomie pojedynczego portu fizycznego, jak i na poziomie interfejsu logicznego
VLAN (filtracja ruchu pomiędzy sieciami VLAN)
WYMSZETH.43. Musi istnieć możliwość logowania lub zliczania pakietów, które odpowiadają
kryteriom zawartym w regułach filtrowania ruchu ACL
WYMSZETH.44. Ilość możliwych do skonfigurowania reguł filtrowania ruchu ACL nie może być
mniejsza niż 7000
WYMSZETH.45. Przełącznik musi obsługiwać następujące mechanizmy bezpieczeństwa:
limitowanie adresów MAC na porcie, konfiguracja dozwolonych adresów MAC na
porcie, DHCP snooping, Dynamic ARP Inspection, IP source guard.
WYMSZETH.46. Przełącznik musi posiadać możliwość uruchomienia funkcjonalności DHCP:
DHCP Server oraz DHCP Relay
WYMSZETH.47. Przełącznik musi zapewniać obsługę
funkcjonalność IGMP oraz IGMP snooping
ruchu
Multicast,
oraz
posiadać
WYMSZETH.48. Przełącznik musi obsługiwać protokoły routingu multicast: PIM-SM, PIM-SSM,
PIM-DM
WYMSZETH.49. Urządzenie musi mieć możliwość kopiowania ruchu z jednego wybranego portu
na inny wskazany port w celu analizy tego ruchu (port mirroring)
WYMSZETH.50. Musi istnieć możliwość połączenia kilku przełączników tej samej rodziny w stos.
WYMSZETH.51. Przełączniki połączone w stos z punktu widzenia sieci powinny być widziane jako
jeden przełącznik. (Np.: musi istnieć możliwość stworzenia agregacji połączeń
z użyciem protokołu 802.3ad dla portów znajdujących się na różnych
przełącznikach, ale będących częścią tego samego stosu)
WYMSZETH.52. Przełączniki połączone w stos powinny być traktowane jako jeden przełącznik
przez protokół Spanning Tree
WYMSZETH.53. Przełączniki tworzące
przełącznikiem
stos
muszą
być
zarządzane,
jakby były jednym
WYMSZETH.54.
WYMSZETH.55. Urządzenie musi zostać skonfigurowane na docelowym środowisku
Zamawiającego, a jego konfiguracja musi zostać udokumentowana dla i w oparciu
o dostarczoną infrastrukturę sprzętową i dostarczone licencje oprogramowania.
Strona 118 z 161
ID wymagania
Opis wymagania
Konfiguracja musi uwzględniać wydzielenie stref bezpieczeństwa w oparciu
o specyfikę przetwarzanych danych w systemie i uwzględniając komunikację
z urządzeń mobilnych.
7.2.2.Adaptery Mini GBIC – Region
Poniżej przedstawiono wymagania dla adaptera Mini GBIC, który musi być dostarczony dla warstwy
regionalnej.
ID wymagania
Opis wymagania
WYMMGB.1
Interfejsy optyczne pasujące do przełączników Ethernetowych zapewniające
transfer 1Gb/s na światłowodzie wielomodowym (adaptery 1000BaseSX) dla
przełączników szkieletowych oraz dystrybucyjnych.
WYMMGB.2
Interfejsy optyczne pasujące do przełączników Fiber Chanel zapewniające transfer
8Gb/s na światłowodzie wielomodowym.
WYMMGB.3
Wymagane jest, aby adaptery MiniGBIC były w pełni kompatybilne z portami
w dostarczanych przełącznikach opisanych w pkt 7.2.1.1, 7.2.1.2i 7.2.1.3.
7.2.3.Konsola KVM – Region, Szpitale
Poniżej przedstawiono wymagania dla konsoli KVM, która zgodnie z założeniami dostarczona będzie
do warstwy regionalnej oraz lokalnej.
ID wymagania
Opis wymagania
WYMKVM.1.
Konstrukcja: Przystosowana do zamontowania w oferowanej szafie Rack19",
metalowa, 1U.
WYMKVM.2.
Max. ilość podłączonych PC: 8 komputerów z wyjściem VGA i 2 x PS/2 lub USB.
WYMKVM.3.
Podłączenie do PC: Kabel zintegrowany.
WYMKVM.4.
Zintegrowana klawiatura oraz urządzenie wskazujące (touchpad).
WYMKVM.5.
Złącze łańcuchowe: min. 1 szt.
WYMKVM.6.
Emulacja: klawiatury / myszy PS/2.
WYMKVM.7.
Możliwość wyboru aktywnego portu.
WYMKVM.8.
WYMKVM.9.
a) Monitor LCD min. 17"
b) Rozdzielczość min. 1280 x 1024 lub min. 1440 x 900
Wymagany kabel KVM (USB oraz Video – np. D-SUB) na serwer, umożliwiający
podłączenie do serwera.
Strona 119 z 161
7.3. Bezpieczeństwo
Sekcja przedstawia zestawienie elementów infrastruktury sprzętowo-programowej związanej
z bezpieczeństwem Systemu niezbędnych do realizacji projektu wraz z wyszczególnieniem ich
parametrów technicznych.
7.3.1.Urządzenia zabezpieczające UTM
7.3.1.1.
UTM - Region
Poniżej przedstawiono wymagania dla UTM w warstwie regionalnej.
ID wymagania
Opis wymagania
WYMRUTM.1.
System zabezpieczeń musi być dostarczony jako dedykowane urządzenie
zabezpieczeń sieciowych (appliance). W architekturze systemu musi występować
separacja modułu zarządzania i modułu przetwarzania danych. Zamawiający
dopuszcza rozwiązanie w którym zarządzanie platformą odbywa się za pomocą
dedykowanej wirtualnej instancji systemu - logicznie odseparowanej od części
obsługującej ruch tranzytowy, pod warunkiem, że sam ruch sieciowy nie jest
przepuszczany przez tę instancję.
WYMRUTM.2.
System zabezpieczeń nie może posiadać ograniczeń licencyjnych dotyczących
liczby chronionych komputerów w sieci wewnętrznej lub innych.
WYMRUTM.3.
Urządzenie zabezpieczeń musi posiadać przepływność nie mniej niż 1 Gb/s dla
kontroli firewall (w tym kontrola aplikacji), nie mniej niż 1 Gb/s dla kontroli
zawartości (w tym kontrola AV, IPS) i obsługiwać nie mniej niż 250 000
jednoczesnych połączeń.
WYMRUTM.4.
Urządzenie zabezpieczeń musi być wyposażone w co najmniej 4 portów Ethernet
10/100/1000-BASE-T oraz 4 portów Gigabit SFP.
WYMRUTM.5.
System zabezpieczeń musi mieć możliwość pracy w trybie rutera (tzn.
w warstwie 3 modelu OSI) oraz w trybie transparentnym. Funkcjonując w trybie
transparentnym urządzenie nie może posiadać skonfigurowanych adresów IP na
interfejsach sieciowych jak również nie może wprowadzać segmentacji sieci.
WYMRUTM.6.
Urządzenie musi obsługiwać protokół Ethernet z obsługą sieci VLAN poprzez
tagowanie zgodne z IEEE 802.1q. Urządzenie musi obsługiwać nie mniej niż 10
wirtualnych ruterów posiadających odrębne tabele rutingu. Urządzenie musi
obsługiwać protokoły routingu dynamicznego, nie mniej niż BGP.
WYMRUTM.7.
System zabezpieczeń musi realizować zadania kontroli dostępu (filtracji ruchu
sieciowego), wykonując kontrolę na poziomie warstwy sieciowej, transportowej
WYMRUTM.8.
System zabezpieczeń musi zapewniać inspekcję komunikacji szyfrowanej HTTPS
(HTTP szyfrowane protokołem SSL) dla ruchu wychodzącego do serwerów
zewnętrznych
(np.
komunikacji
użytkowników
korzystających
z Internetu) oraz ruchu przychodzącego do serwerów wew. System musi mieć
możliwość deszyfracji niezaufanego ruchu HTTPS i poddania go właściwej
inspekcji nie mniej niż: wykrywanie i blokowanie ataków typu exploit (ochrona
Intrusion Prevention), wirusy i inny złośliwy kod (ochrona AntiVirus).
WYMRUTM.9.
System
zabezpieczeń
musi
umożliwiać
zestawianie
zabezpieczonych
kryptograficznie tuneli VPN w oparciu o standardy IPSec i IKE w konfiguracji siteto-site.
Strona 120 z 161
ID wymagania
Opis wymagania
WYMRUTM.10. System zabezpieczeń musi wykonywać zarządzanie pasmem sieci (QoS),
a także ustawiania dla dowolnych aplikacji pasma maksymalnego.
WYMRUTM.11. System zabezpieczeń musi posiadać możliwość uruchomienia modułu inspekcji
antywirusowej, kontrolującego przynajmniej pocztę elektronicznej (SMTP, POP3),
FTP oraz HTTP i HTTPS bez konieczności dokupywania jakichkolwiek
komponentów, poza subskrypcją. Baza AV musi być regularnie aktualizowana
w sposób automatyczny.
WYMRUTM.12. System zabezpieczeń transparentnie ustala tożsamość użytkowników sieci.
Polityka kontroli dostępu (firewall) precyzyjnie definiuje prawa dostępu
użytkowników do określonych usług sieci i jest utrzymana nawet gdy użytkownik
zmieni lokalizację i adres IP.
WYMRUTM.13. Zarządzanie systemu zabezpieczeń musi odbywać się z linii poleceń (CLI),
graficznej konsoli Web GUI oraz scentralizowanego systemu zarządzania. Dostęp
do urządzenia i zarządzanie z sieci muszą być zabezpieczone kryptograficznie
(przez szyfrowanie komunikacji). System zabezpieczeń musi pozwalać na
zdefiniowanie wielu administratorów o różnych uprawnieniach.
WYMRUTM.14. System zabezpieczeń musi wykonywać statyczną i dynamiczną translację adresów
NAT. Mechanizmy NAT muszą umożliwiać co najmniej dostęp wielu komputerów
posiadających adresy prywatne do Internetu z wykorzystaniem jednego
publicznego adresu IP oraz udostępnianie usług serwerów o adresacji prywatnej w
sieci Internet.
WYMRUTM.15. System zabezpieczeń zapewnia możliwość bezpiecznego zdalnego dostępu do
chronionych zasobów w oparciu o standard SSL VPN.
WYMRUTM.16. System zabezpieczeń musi posiadać możliwość pracy w konfiguracji odpornej na
awarie w trybie Active-Passive oraz w trybie Active-Active.
WYMRUTM.17. Pomoc techniczna oraz szkolenia z produktu muszą być dostępne w Polsce. Usługi
te muszą być świadczone w języku polskim w autoryzowanym ośrodku
edukacyjnym.
WYMRUTM.18. W ramach postępowania musi zostać dostarczone jedno kompletne, gotowe do
pracy urządzenie.
WYMRUTM.19. Urządzenie powinno posiadać funkcje:




systemu antywirusowego,
DLP,
Proxy,
Stateful Inspection.
WYMRUTM.20. Możliwość dwuskładnikowego logowania się (token fizyczny, aplikacja na telefon
lub SMS).
7.3.1.2.
UTM – Szpitale
Poniżej przedstawiono wymagania dla UTM zlokalizowanych w warstwie lokalnej.
ID wymagania
Opis wymagania
WYMSZUTM.1. System zabezpieczeń musi być dostarczony jako dedykowane urządzenie
zabezpieczeń sieciowych (appliance). W architekturze systemu musi
Strona 121 z 161
ID wymagania
Opis wymagania
występować separacja modułu zarządzania i modułu przetwarzania danych.
Zamawiający dopuszcza rozwiązanie w którym zarządzanie platformą odbywa
się za pomocą dedykowanej wirtualnej instancji systemu - logicznie
odseparowanej od części obsługującej ruch tranzytowy, pod warunkiem, że sam
ruch sieciowy nie jest przepuszczany przez tę instancję.
WYMSZUTM.2. System zabezpieczeń nie może posiadać ograniczeń licencyjnych dotyczących
liczby chronionych komputerów w sieci wewnętrznej.
WYMSZUTM.3. Urządzenie zabezpieczeń musi posiadać przepływność nie mniej niż 250 Mb/s
dla kontroli firewall (w tym kontrola aplikacji), nie mniej niż 100 Mb/s dla kontroli
zawartości (w tym kontrola AV, IPS)) i obsługiwać nie mniej niż 64 000
jednoczesnych połączeń.
WYMSZUTM.4. Urządzenie zabezpieczeń musi być wyposażone w co najmniej 8 portów
Ethernet 10/100/1000.
WYMSZUTM.5. System zabezpieczeń musi mieć możliwość pracy w trybie rutera (tzn. w
warstwie 3 modelu OSI) oraz w trybie transparentnym. Funkcjonując w trybie
transparentnym urządzenie nie może posiadać skonfigurowanych adresów IP
na interfejsach sieciowych jak również nie może wprowadzać segmentacji sieci.
WYMSZUTM.6. Urządzenie musi obsługiwać protokół Ethernet z obsługą sieci VLAN poprzez
tagowanie zgodne z IEEE 802.1q. Urządzenie musi obsługiwać nie mniej niż 3
wirtualne rutery posiadających odrębne tabele rutingu. Urządzenie musi
obsługiwać protokoły routingu dynamicznego, nie mniej niż BGP.
WYMSZUTM.7. System zabezpieczeń musi realizować zadania kontroli dostępu (filtracji ruchu
sieciowego), wykonując kontrolę na poziomie warstwy sieciowej, transportowej.
WYMSZUTM.8. System zabezpieczeń musi zapewniać inspekcję komunikacji szyfrowanej
HTTPS (HTTP szyfrowane protokołem SSL) dla ruchu wychodzącego do
serwerów zewnętrznych (np. komunikacji użytkowników surfujących w
Internecie) oraz ruchu przychodzącego do serwerów firmy. System musi mieć
możliwość deszyfracji niezaufanego ruchu HTTPS i poddania go właściwej
inspekcji nie mniej niż: wykrywanie i blokowanie ataków typu exploit (ochrona
Intrusion Prevention), wirusy i inny złośliwy kod (ochrona AntiVirus).
WYMSZUTM.9. System zabezpieczeń musi umożliwiać zestawianie zabezpieczonych
kryptograficznie tuneli VPN w oparciu o standardy IPSec i IKE w konfiguracji
site-to-site.
WYMSZUTM.10. System zabezpieczeń musi wykonywać zarządzanie pasmem sieci (QoS),
a także ustawiania dla dowolnych aplikacji pasma maksymalnego.
WYMSZUTM.11. System zabezpieczeń musi posiadać możliwość uruchomienia modułu inspekcji
antywirusowej, kontrolującego przynajmniej pocztę elektronicznej (SMTP,
POP3), FTP oraz HTTP i HTTPS bez konieczności dokupywania jakichkolwiek
komponentów, poza subskrypcją. Baza AV musi być regularnie aktualizowana w
sposób automatyczny.
WYMSZUTM.12. System zabezpieczeń transparentnie ustala tożsamość użytkowników sieci.
Polityka kontroli dostępu (firewall) precyzyjnie definiuje prawa dostępu
użytkowników do określonych usług sieci i jest utrzymana nawet gdy użytkownik
zmieni lokalizację i adres IP.
Strona 122 z 161
ID wymagania
Opis wymagania
WYMSZUTM.13. Zarządzanie systemu zabezpieczeń musi odbywać się z linii poleceń (CLI),
graficznej konsoli Web GUI oraz scentralizowanego systemu zarządzania.
Dostęp do urządzenia i zarządzanie z sieci muszą być zabezpieczone
kryptograficznie (poprzez szyfrowanie komunikacji). System zabezpieczeń musi
pozwalać na zdefiniowanie wielu administratorów o różnych uprawnieniach.
WYMSZUTM.14. System zabezpieczeń musi wykonywać statyczną i dynamiczną translację
adresów NAT. Mechanizmy NAT muszą umożliwiać co najmniej dostęp wielu
komputerów posiadających adresy prywatne do Internetu z wykorzystaniem
jednego publicznego adresu IP oraz udostępnianie usług serwerów o adresacji
prywatnej w sieci Internet.
WYMSZUTM.15. System zabezpieczeń zapewnia możliwość bezpiecznego zdalnego dostępu do
chronionych zasobów w oparciu o standard SSL VPN.
WYMSZUTM.16. System zabezpieczeń musi posiadać możliwość pracy w konfiguracji odpornej
na awarie w trybie Active-Passive oraz w trybie Active-Active. Moduł ochrony
przed awariami musi monitorować i wykrywać uszkodzenia elementów
sprzętowych i programowych systemu zabezpieczeń oraz łączy sieciowych.
WYMSZUTM.17. Pomoc techniczna oraz szkolenia z produktu muszą być dostępne w Polsce.
Usługi te muszą być świadczone w języku polskim w autoryzowanym ośrodku
edukacyjnym.
WYMSZUTM.18. W ramach postępowania musi zostać dostarczone jedno kompletne, gotowe do
pracy urządzenie.
WYMSZUTM.19. Urządzenie powinno posiadać funkcje:




systemu antywirusowego,
DLP,
Proxy,
Stateful Inspection.
WYMSZUTM.20. Możliwość dwuskładnikowego logowania się (token fizyczny, aplikacja na telefon
lub SMS).
7.3.2.Urządzenia podtrzymujące zasilanie – Region
Poniżej przedstawione zostały wymagania dla urządzeń podtrzymujących zasilanie dla warstwy
regionalnej.
ID wymagania
Opis wymagania
WYMSZZAR.1.
Przystosowana do zamontowania w oferowanej szafie Rack 19’’ wraz
z zestawem szyn montażowych oraz kompletem kabli zasilających o
wysokości maksymalnie 4U.
WYMSZZAR.2.
Moc pozorna zasilacza powinna być nie mniejsza niż 3300 VA.
WYMSZZAR.3.
Moc rzeczywista zasilacza powinna być nie mniejsza niż 3 000 W.
WYMSZZAR.4.
Wymagany minimalny czas pracy na baterii nie może być krótszy niż 4 minut
przy 100% obciążeniu oraz 12 minut przy obciążeniu równym 50%.
WYMSZZAR.5.
Musi istnieć możliwość wydłużenia czasu pracy na
zastosowanie dodatkowych modułów bateryjnych.
Strona 123 z 161
baterii
poprzez
WYMSZZAR.6.
Zasilacz powinien być wyposażony w:
-minimum 6 gniazd z utrzymaniem zasilania w standardzie IEC320 C13 (10A)
-minimum 2 gniazda z utrzymaniem zasilania w standardzie IEC320 C19 (16A)
WYMSZZAR.7.
Zasilacz powinien umożliwiać podłączenie go do sieci ETHERNET oraz
umożliwiać monitorowanie za pomocą protokołów SNMP oraz Telnet.
Dopuszcza się aby interfejs sieciowy był zainstalowany jako moduł.
7.3.3.Urządzenia podtrzymujące zasilanie – Szpitale
Poniżej przedstawiono wymagania dla urządzeń podtrzymujących zasilanie w warstwie lokalnej.
ID wymagania
Opis wymagania
WYMSZZAS.1.
Przystosowana do zamontowania w oferowanej szafie Rack 19’’ wraz
z zestawem szyn montażowych oraz kompletem kabli zasilających o wysokości
maksymalnie 4U.
WYMSZZAS.2.
Moc pozorna zasilacza powinna być nie mniejsza niż 3300 VA.
WYMSZZAS.3.
Moc rzeczywista zasilacza powinna być nie mniejsza niż 3 000 W.
WYMSZZAS.4.
Wymagany minimalny czas pracy na baterii nie może być krótszy niż 4 minut przy
100% obciążeniu oraz 12 minut przy obciążeniu równym 50%.
WYMSZZAS.5.
Musi istnieć możliwość wydłużenia czasu pracy na baterii poprzez zastosowanie
dodatkowych modułów bateryjnych.
WYMSZZAS.6.
Zasilacz powinien być wyposażony w:
a) minimum 6 gniazd z utrzymaniem zasilania w standardzie IEC320 C13
(10A).
b) minimum 2 gniazda z utrzymaniem zasilania w standardzie IEC320 C19
(16A).
WYMSZZAS.7.
Zasilacz powinien umożliwiać podłączenie go do sieci ETHERNET oraz umożliwiać
monitorowanie za pomocą protokołów SNMP oraz Telnet. Dopuszcza się aby
interfejs sieciowy był zainstalowany jako moduł.
7.3.4.Infrastruktura podpisu elektronicznego - Szpitale
Poniżej przedstawiono wymagania dla infrastruktury podpisu elektronicznego, która dostarczona
zostanie do warstwy lokalnej.
ID wymagania
Opis wymagania
WYMPKI.1.
Wykonawca musi dostarczyć infrastrukturę sprzętową oraz programową niezbędną
do obsługi podpisu elektronicznego dla każdego Szpitala uczestniczącego w
projekcie składającą się z:




Czytników kart umożliwiających odczyt jednocześnie dwóch kart
mikroprocesorowych wraz ze sterownikami w liczbie odpowiadającej liczbie
stanowisk komputerowych we wszystkich Szpitalach dla pracowników
medycznych i techników
Kart kryptograficznych będących jednocześnie zbliżeniowymi
Naklejek na karty kryptograficzne w celu ich personalizacji (kolor biały),
które mogą być zadrukowane termotransferowych
Zestawów czyszczących do drukarek EvolisDualys3 Smart umożliwiającej
Strona 124 z 161
ID wymagania
Opis wymagania



WYMPKI.2.
prawidłowy na
druk dostarczonych kart kryptograficznych oraz naklejek na wszystkie
dostarczone karty kryptograficzne
Folii YMCKO do kolorowego nadruku na kartach do drukarek
termotransferowych EvolisDualys 3 Smart w liczbie umożliwiającej
swobodny nadruk dostarczonych kart kryptograficznych oraz naklejek na
karty kryptograficzne
System personalizacji wraz dokumentacją w języku polskim umożliwiający
zadruk kart przy użyciu drukarek Evolis Dualys 3 Smart. System pozwoli na
zadruk
dostarczonych
kart
zarówno
w
pionie
jak
i poziomie na całej powierzchni karty lub wyłącznie w wybranym miejscu,
dodanie
zdjęcia
w
dowolnym
kształcie
i
miejscu
wraz
z personalizowanym opisem, w zakresie: imię, nazwisko, departament,
zespół, nr porządkowy, logo.
Infrastruktura podpisu elektronicznego dla każdego Szpitala uczestniczącego w
projekcie musi być dostarczona w liczbie umożliwiającej funkcjonowanie systemu
MSIM, w tym łącznie dla 3 Szpitali muszą zostać dostarczonego najmniej:






Czytniki kart: 700 szt.
Karty kryptograficzne: 700 szt.
Naklejki: 2 x 700szt. = 1400 szt.
Folia: 11 szt.
Zestawy czyszczące: 5 szt.
System personalizacji wraz dokumentacją: 1 szt.
WYMPKI.3.
Czytniki kart muszą zostać dostarczone wraz ze sterownikami umożliwiającymi
pracę co najmniej w następujących systemach operacyjnych: Windows 7 i 8 (32 i
64bit), Server 2003, Linux
WYMPKI.4.
Infrastruktura podpisu elektronicznego dla systemu funkcjonuje w oparciu
o istniejące CAPE w Małopolsce
WYMPKI.5.
Infrastruktura podpisu elektronicznego musi świadczyć usługę znakowania czasem
z minimalną wydajnością oferowaną przez CAPE w Małopolsce
WYMPKI.6.
Infrastruktura podpisu elektronicznego musi świadczyć
z minimalną wydajnością oferowaną przez CAPE w Małopolsce
WYMPKI.7.
Infrastruktura podpisu elektronicznego musi świadczyć usługę archiwizacji
podpisów z minimalną wydajnością oferowaną przez CAPE w Małopolsce
WYMPKI.8.
Infrastruktura podpisu elektronicznego musi świadczyć usługę recertyfikacji
podpisów z minimalną wydajnością oferowaną przez CAPE w Małopolsce
WYMPKI.9.
Czytniki kart muszą obsługiwać dwie karty jednocześnie.
usługę
OCSP
7.3.5.Procedury instalacji, uruchomienia systemu oraz disaster recovery
Dla Systemu wymagane jest opracowanie szczegółowego Planu Ciągłości Działania obejmującego:
1. Ogólna zawartość PCD:
a. Tytuł zawierający neutralne informacje o dokumencie,
b. Zakres, metrykę dokumentu (wersja, data)
c.
Spis treści wraz z listą wszystkich diagramów, tabel i załączników
d. Lista Dystrybucyjna
e. Lista wszystkich formularzy wymaganych dla działania PCD
Strona 125 z 161
f.
Odniesienie do Standardów, regulacji zewnętrznych, itp.
g. Struktura organizacyjna dokumentu
2. Opracowanie Streszczenia dla Kierownictwa:
a. Ogólna deklaracja zarządcza przedstawiająca rolę i zadania PCD
b. Krótki opis głównych scenariuszy katastrofy w zakresie: personelu, systemów,
budynków, infrastruktury publicznej itp.
c.
Krótkie przedstawienie spraw otwartych związanych z PCD z deklaracją ich wykonania
(wł. zadania i termin wykonania)
3. Business Impact Analysis
a. Lista procesów krytycznych (w tym procesów obsługiwanych przez outsourcing) wraz
z opisującymi je parametrami (MTD, RPO, RTO, wł. procesu, zmapowanie na zasoby
IT)
b. Dołączone potwierdzenia wł. procesów, że przypisane zasoby IT są adekwatne
i wystarczające
c.
Lista Kontaktowa dostawców i outsourcerów dla krytycznych procesów biznesowych
4. Procedury eskalacyjne
a. Przedstawienie zasad i ogólnych reguł postępowania podczas ogłoszenia stanu
katastrofy
b. Plan ewakuacji
c.
Procedura powiadamiania o katastrofie
5. Lokalizacje
a. Lista wszystkich lokalizacji i siedzib
b. Specyfikacja lokalizacji (osoby kontaktowe, mapy lokalizacji zapasowych, opis
infrastruktury, ilość miejsc DR, opis konfiguracji DR dla pracowników)
6. Opracowanie scenariusza zmiany lokalizacji warstwy regionalnej oraz warstwy lokalnej
a. Opis bezpiecznego wyłączenia systemu, przeniesienia infrastruktury z zachowaniem
względów bezpieczeństwa danych, wznowienia pracy sytemu.
b. Wykonanie testów
7. Organizacja na czas katastrofy
a. Przedstawienie i opis struktury Sztabu Kryzysowego – struktura, zadania, procedury
b. Przedstawienie i opis Zespołów Awaryjnych – odpowiedzialność z podziałem na
procesy krytyczne, struktura org, matryca odpowiedzialności (zastępstwa), zadania
i procedury.
8. Fazy Planu awaryjnego
a. Powiadomienie i inicjacja PCD – warunki, procedury z podziałem dla wszystkich
biorących w tym udział zespołów awaryjnych i członków Sztabu Kryzysowego
b. Realizacja PCD – procedury odtworzeniowe z podziałem na zespoły awaryjne
i diagramy decyzyjne,
c.
Wznowienie normalnej pracy MSIM – powrót z trybu awaryjnego – zespoły, zadania,
diagramy decyzyjne, procedury relokacji.
9. Opracowanie scenariuszy testowych PCD:
a. Zdefiniowanie niezbędnych rodzajów testów, wraz ze wszystkimi rolami, które muszą
wziąć udział w testach,
b. Rekomendacje dotyczące cykliczności rodzajów testów.
Strona 126 z 161
7.3.6.Środowisko testowe
W ramach komponentu regionalnego wymaga się utworzenia środowiska testowego, które przy
pomocy zdalnego dostępu umożliwi testowanie funkcjonowania następujących elementów Systemu:









Lokalne Repozytorium EDM,
Komunikacja komponentu lokalnego z komponentem regionalnym,
Komunikacja systemów źródłowych z repozytorium EDM w ramach komponentu lokalnego,
Rejestr EDM,
System bezpieczeństwa, w tym usługa uwierzytelniania i autoryzacji,
Systemu e-Rejestracji,
Portalowi e-zdrowie,
Weryfikacji kolejnych aktualizacji systemu przed wgraniem ich produkcyjnie na serwery,
Inne – wskazane przez Zamawiającego w ramach dostarczonych funkcjonalności.
Środowisko testowe musi funkcjonować w warunkach odpowiadającym warunkom rzeczywistym.
7.3.7.Środowisko backupowe
W ramach Projektu Wykonawca musi opracować system backupu oparty o bibliotekę taśmową wraz
z oprogramowaniem automatyzującym backup zgodnie z zaplanowaną polityką backupu (backup
pełny i przyrostowy). Planowana jest pełna replikacja danych do drugiej serwerowni pełniącej funkcję
serwerowni zapasowej. W celu zapewnienia pełnej redundancji również na poziomie backupu,
planowane jest jego wdrożenie w obydwu serwerowniach.
W ramach prac projektowych Wykonawca zobowiązany jest do przygotowania procedur oraz
dokumentacji backupu uwzględniających co najmniej:





Role odpowiedzialne za proces backupu wraz z przypisanymi odpowiedzialnościami
Terminy wykonywania backupu pełnego (rekomendowane – co najmniej raz na dobę)
Zasady tworzenia kopii przyrostowej
Czas przetrzymywania kopii pełnych
Wykorzystywane narzędzia.
Dodatkowo Wykonawca zobowiązany będzie do przygotowania procedur odtworzenia danych z kopii
zapasowej.
W ramach komponentu regionalnego wymaga się utworzenia środowiska backupowego, które
umożliwia:



Wykonywanie kopii zapasowych danych gromadzonych w warstwie regionalnej, w tym m.in.:
o Rejestru EDM
o Bazy użytkowników i praw dostępu
o Bazy konfiguracji
o Bazy rejestrów, np. rejestru pobrań, żądań
Odtwarzanie danych z utworzonych kopii zapasowych
Definiowane polityk tworzenia kopii zapasowych
Polityka wykonywania backupu powinna uwzględniać następujące elementy:




Cel,
Zakres,
Procedury szczegółowe,
Zakres danych objętych backupem,
Strona 127 z 161



Rodzaje backupu,
Zasady przechowywania kopii w tym kopii archiwalnych,
Wymagania szczegółowe dotyczące wykonywania kopii zapasowych.
7.3.8.Środowisko archiwizacji
W ramach komponentu regionalnego nie planuje się utworzenia środowiska archiwizacji.
W ramach komponentu lokalnego wymaga się utworzenia środowiska archiwizacji dla repozytorium
EDM zgodnie z wymaganiami stawianymi przez Rozporządzenie Ministra Zdrowia w sprawie rodzajów
i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania.
Wytyczne przechowywania kopii zapasowych muszą uwzględniać następujące wymagania:
1. Kopie zapasowe powinny być przechowywane na nośnikach taśmowych bądź na innych
nośnikach np. płytach DVD, Bluray które mogą być przenoszone fizycznie w łatwy sposób
pomiędzy lokalizacjami.
2. Powinny istnieć dwa repozytoria kopii zapasowych: główne i zapasowe.
3. Warunki, które powinna spełniać lokalizacja repozytorium zapasowego:
a. Różne położenie geograficzne w stosunku do repozytorium głównego,
b. Komunikacja z lokalizacją głównego repozytorium dwoma niezależnymi drogami,
c.
Możliwość fizycznego dostarczenia nośników kopii zapasowych do lokalizacji głównego
repozytorium w ciągu 6 godzin.
4. Kopie zapasowe powinny znajdować się w szafie, która powinna chronić przed:

Kradzieżą,

Polem elektromagnetycznym,

Wysoką temperaturą,

Wilgocią.
5. W przypadku transportowania nośników z kopiami zapasowymi poza lokalizację główną,
należy zapewnić bezpieczne warunki transportu poprzez:
a. Zapewnienie poufności danych przez:
i. Zaszyfrowanie nośnika,
ii. Przewożenie kopii bezpieczeństwa w postaci niezaszyfrowanej wyłącznie w obecności
dwóch pracowników.
b. Nie pozostawianie kopii bezpieczeństwa bez nadzoru,
c.
Umieszczanie nośników w bezpiecznych pojemnikach zabezpieczających je przed
zniszczeniem.
6. Nośniki kopii zapasowych, które zawierają archiwalne dane i są uszkodzone lub nie można
ich ponownie wykorzystać, muszą być niezwłocznie zniszczone w sposób uniemożliwiający
odtworzenie zapisanych na nich danych.
Strona 128 z 161
7.4. Pozostałe elementy
7.4.1.Akcesoria
Poniżej przedstawiono wymagania dla akcesoriów, które musza być dostarczone w ramach realizacji
przedmiotu zamówienia.
ID wymagania
Opis wymagania
WYMAKCES.1.
Dostarczany sprzęt serwerowy musi być dostarczony
pozwalającym podpięcie go do sieci elektrycznej
wraz
okablowaniem
WYMAKCES.2.
Dostarczany sprzęt serwerowy musi być dostarczony
pozwalającym podpięcie go do sieci LAN i SAN
wraz
okablowaniem
WYMAKCES.3.
Dostarczany sprzęt sieciowy musi być dostarczony
pozwalającym podpięcie go do sieci elektrycznej
wraz
okablowaniem
WYMAKCES.4.
Dostarczany sprzęt sieciowy musi być dostarczony
pozwalającym podpięcie go do sieci LAN i SAN
wraz
okablowaniem
WYMAKCES.5.
Szafa RACK musi zostać dostarczona wraz wyposażeniem pozwalającym na montaż
dostarczanego sprzętu serwerowego i sieciowego.
WYMAKCES.6.
Urządzenia wymagające montażu w szafach RACK muszą być dostarczone wraz z
całą niezbędną infrastrukturą umożliwiającą ich montaż w szafie RACK, np. wraz z
szynami RACK.
WYMAKCES.7.
Wykonawca musi dostarczyć urządzenia pomiarowe umożliwiające pomiar
temperatury dostarczonych urządzeń serwerowych, sieciowych i klimatyzacji
z dokładnością do 0,1 st. C.
WYMAKCES.8.
Dostarczony sprzęt musi być dostarczony
oprogramowania do monitorowania PDU.
WYMAKCES.9.
Czujniki temperatury.
wraz
z
PDU
oraz
licencjami
7.4.2.Klimatyzacja – Region
Poniżej przedstawiono wymagania dla klimatyzacji, która musi być dostarczona do warstwy
regionalnej w ramach realizacji przedmiotu zamówienia.
ID wymagania
Opis wymagania
WYMKLIREG.1. Urządzenie podstropowe o mocy minimum 8kWz zewnętrznym wymiennikiem
ciepła
WYMKLIREG.2. Automatyczne utrzymywanie zadanej temperatury
WYMKLIREG.3. Sterowanie pilotem
WYMKLIREG.4. Tryb pracy całorocznej
WYMKLIREG.5. Automatyczne informowanie o awarii w działaniu
WYMKLIREG.6. Urządzenie musi być dostarczone wraz z niezbędnymi elementami
umożliwiającymi jego podłączenie i uruchomienie, w tym wpięcie w system
monitorowania danej lokalizacji. Klimatyzatory mają mieć możliwość
udostępniania informacji o działaniu po protokole SMTP do systemu zarządzania i
monitorowania infrastrukturą sprzętową
Strona 129 z 161
7.4.3.Klimatyzacja – Szpitale
Poniżej przedstawiono wymagania dla klimatyzacji, która musi być dostarczona do warstwy lokalnej w
ramach realizacji przedmiotu zamówienia.
ID wymagania
Opis wymagania
WYMKLISZP.1. Urządzenie podstropowe o mocy minimum 5kWz zewnętrznym wymiennikiem
ciepła
WYMKLISZP.2. Automatyczne utrzymywanie zadanej temperatury
WYMKLISZP.3. Sterowanie pilotem
WYMKLISZP.4. Tryb pracy całorocznej
WYMKLISZP.5. Automatyczne informowanie o awarii w działaniu
WYMKLISZP.6. Urządzenie musi być dostarczone wraz z niezbędnymi elementami umożliwiającymi
jego podłączenie i uruchomienie, w tym wpięcie w system monitorowania danej
lokalizacji. Klimatyzatory mają mieć możliwość udostępniania informacji o działaniu
po protokole SMTP do systemu zarządzania i monitorowania infrastrukturą
sprzętową.
7.4.4.Urządzenie do administracji systemem - Region
Poniżej przedstawiono wymagania dla urządzania do administracji systemem, które dostarczone musi
byćwraz z infrastrukturą dedykowaną do warstwy regionalnej.
ID wymagania
Parametr i opis wymagania
WYMUADM.1.
Ekran
WYMUADM.2.
Procesor
WYMUADM.3.
WYMUADM.4.
WYMUADM.5.
WYMUADM.6.
Chipset
Pamięć RAM
Dysk twardy
(pojemność i typ)
Karta graficzna
WYMUADM.7.
WYMUADM.8.
Karta dźwiękowa
Karta sieciowa
WYMUADM.9.
Porty/złącza
LAPTOP
Minimum 12,5" o maksymalnej rozdzielczościminimum
1366x768z podświetleniem w technologii LED
Procesor
zaprojektowany
do
pracy
w
komputerach
przenośnych,
osiągający
w teście PassMark CPU Mark jednokrotnie w okresie od
dnia publikacji ogłoszenia o zamówieniu do dnia
otwarcia ofert minimum 4400 punktów (na podstawie
wyników
opublikowanych
na
stronie:
http://www.cpubenchmark.net/high_end_cpus.html).Do
oferty należy załączyć wydruk z ww. strony
potwierdzający, że zaoferowany procesor spełnia
wymagania.
Dostosowany do oferowanego procesora
Minimum 4GB DDR3 minimum 1333MHz
Minimum 250 GB SATA: HDD (minimum 7200 obr/min)
lub SSD
Zintegrowana, Zapewniająca sprzętowe wsparcie dla
minimum DirectX 11 oraz minimum Shader Model 5.0
Zintegrowana, wbudowane głośniki stereo oraz mikrofon
Wbudowany port sieci LAN 10/100/1000 Ethernet RJ-45
zintegrowany z płytą główną wspierający funkcję Wake
on LAN (funkcja włączana przez użytkownika) i PXE
oraz WLAN 802.11 b/g/n, wbudowany moduł Bluetooth,
wbudowany modem 3G
Wbudowane: minimum 2 x USB minimum 2.0, VGA,
wyjście słuchawkowe, wejście zasilania (DC-in).
Możliwość podłączenia od spodu laptopa dedykowanej
stacji dokującej/replikatora portów(nie zajmującego
Strona 130 z 161
WYMUADM.10.
WYMUADM.11
Klawiatura i
urządzenie
wskazujące
Napęd optyczny
WYMUADM.12.
WYMUADM.13.
Kamera
Bateria
WYMUADM.14.
WYMUADM.15.
Zasilacz
System operacyjny
WYMUADM.16.
Waga
WYMUADM.17.
Dodatkowe
wyposażenie
złącza USB). Wbudowany czytnik linii papilarnych,
wbudowany czytnik kart pamięci SD.
Klawiatura w układzie „polski programisty”, Touchpad
DVD +/- RW wewnętrzny lub zewnętrzny (np. dołączany
do portu USB). Dopuszcza się aby napęd optyczny DVD
+/- RW był wbudowany w stację dokującą/ replikator
portów. Dołączone oprogramowanie w języku polskim
do nagrywania płyt.
Wbudowana w obudowę laptopa
Czas pracy na baterii minimum 3 godziny
Tak
Zainstalowany Microsoft Windows 8Professional 64-bit
PL
(z
możliwością
downgrade
do
Windows
7Professional 64-bit PL) lub równoważny gdzie
zainstalowany system operacyjny umożliwi zalogowanie
się laptopa do posiadanej przez Zamawiającego
Domeny Microsoft Active Directory oraz musi posiadać
natywną
funkcjonalność
przetwarzania
polityk
domenowych Microsoft AD GPO. Nośnik do instalacji
oryginalnego systemu operacyjnego.
Max 1,65 kg z baterią (bez napędu optycznego DVD +/RW)
•
•
•
•
WYMUADM.18.
WYMUADM.19.
WYMUADM.20.
WYMUADM.24.
Rodzaj matrycy
Przekątna ekranu
Maksymalna
rozdzielczość
Jasność
Kontrast
Kąty
widzenia
(pion/poziom)
Złącza
WYMUADM.25.
Podstawa
WYMUADM.21.
WYMUADM.22.
WYMUADM.23.
WYMUADM.26.
Dwukomorowa torba, dostosowana wymiarami do
rozmiarów laptopa
Mysz
bezprzewodowa,
optyczna,
z mikroodbiornikiem podłączanym do portu USB z
minimum dwoma klawiszami oraz rolką (scroll)
Zewnętrzna
klawiatura
bezprzewodowa
z mikroodbiornikiem podłączanym do portu USB
Dołączony nośnik ze sterownikami.
MONITOR
Monitor ciekłokrystaliczny
Minimum 21,5 cala
Minimum 1920x1080
Minimum 250 cd/m2
Minimum 1000:1
Minimum 160/170 stopni
Minimum 1 złącze D-SUB wraz z przewodem, minimum
1 złącze DVI wraz z przewodem, minimum 2 porty USB
wraz z przewodem
Regulowana wysokości, regulowany kąt nachylenia
STACJA DOKUJĄCA (REPLIKATOR PORTÓW)
Dedykowany
Wbudowane złącza: minimum 1xVGA, minimum 3xUSB,
replikator portów
minimum 1xRJ-45
(nie zajmujący
złącza USB)
Strona 131 z 161
z zasilaczem,
umożliwiającym
ładowanie baterii
laptopa
z poziomu stacji
dokującej
7.5. Oprogramowanie systemowe
Sekcja przedstawia zestawienie elementów oprogramowania systemowego i narzędziowego
niezbędne do realizacji projektu wraz z wyszczególnieniem ich parametrów technicznych.
Dostarczona oprogramowanie musi umożliwiać obsługę w m. in. w języku polskim (alternatywnie
dopuszcza się język angielskim).
7.5.1.Oprogramowanie do backupu
Poniżej przedstawiono wymagania dla oprogramowania do backupu.
ID wymagania
Opis wymagania
WYMBCK.1.
Oprogramowanie do tworzenia kopi zapasowych musi współpracować
z macierzami oraz biblioteką taśmową dostarczonymi w ramach zamówienia
w pełnym zakresie funkcjonalności
WYMBCK.2.
Oprogramowanie musi być dostarczone w liczbie licencji umożliwiającej
przeprowadzenie backupu na wszystkich dostarczonych serwerach w ramach
jednej lokalizacji.
WYMBCK.3.
Oprogramowanie musi umożliwiać wykonywanie kopi zapasowych środowisk
przyłączonych do sieci ETHERNET z systemami operacyjnymi z rodziny
Microsoft Windows oraz Linux
WYMBCK.4.
Oprogramowanie powinno posiadać licencję na backup samego siebie
WYMBCK.5.
Oprogramowanie musi posiadać graficzny interfejs użytkownika dla
Administratora, który pozwoli na wykonanie wszystkich funkcji związanych
w tworzeniem i zarządzaniem kopiami zapasowymi
WYMBCK.6.
Oprogramowanie do tworzenia kopi zapasowych musi posiadać następujące
funkcje:
a) umożliwiać wykonywania kopii pełnych i przyrostowych,
b) umożliwiać backup pracujących baz danych typu on-line(np. SQL
Server, Oracle Database) oraz środowisk wirtualnych (np. VMWare
vSphere 5, Citrix XenServer),
c) umożliwiać dołączenie własnych poleceń przed i po wykonaniu backupu.
7.5.2.Oprogramowanie do wirtualizacji
Poniżej przedstawiano wymagania dla oprogramowania do wirtualizacji.
ID wymagania
Opis wymagania
WYMWIR.1.
Oprogramowanie musi zostać dostarczone w liczbie licencji, która umożliwia
instalację wirtualizacyjnego systemu operacyjnego na co najmniej trzech
serwerach co najmniej dwu procesorowych, o łącznej liczbie 6 procesorów lub
więcej.
Strona 132 z 161
ID wymagania
Opis wymagania
WYMWIR.2.
Dostarczone licencje muszą obsługiwać 4 TB lub więcej pamięci RAM.
WYMWIR.3.
Muszą zostać dostarczone odpowiednie licencje na oprogramowanie,
umożliwiające zdalne, jednoczesne zarządzanie co najmniej trzema
wirtualizacyjnymi systemami operacyjnymi oraz zainstalowanymi na nich
wirtualnymi maszynami.
WYMWIR.4.
Oprogramowanie do wirtualizacji musi być wspierane przez producenta
oferowanych serwerów opisanych w niniejszej specyfikacji oraz współpracować
z oferowanym oprogramowaniem zarządzającym.
WYMWIR.5.
Oprogramowanie do wirtualizacji musi być uruchamiane bezpośrednio na
sprzęcie serwera i wirtualizować na potrzeby wirtualnych maszyn jego zasoby
sieciowe, dyskowe, procesor oraz pamięć.
WYMWIR.6.
Oprogramowanie do wirtualizacji musi obsługiwać procesory zainstalowane
w oferowanych serwerach.
WYMWIR.7.
Oprogramowanie do wirtualizacji musi być umożliwiać dynamiczną zmianę
wielkości utworzonych w systemie wolumenów dyskowych.
WYMWIR.8.
Oprogramowanie do wirtualizacji musi udostępniać funkcję łączenia minimum
trzech wirtualizacyjnych systemów operacyjnych w klaster niezawodnościowy,
zapewniający, w razie uszkodzenia, któregoś z serwerów(opisanych w niniejszej
specyfikacji) automatyczną migrację, wszystkich uruchomionych na nich
wirtualnych maszyn na kolejny, dostępny serwer w klastrze (licencje dla tej
funkcjonalności są obligatoryjnym elementem oferty. W momencie składania
oferty wirtualizacyjny system operacyjny musi posiadać, w pełni działającą tą
funkcjonalność).
WYMWIR.9.
Oprogramowanie do wirtualizacji musi wspierać instalację na wirtualnych
maszynach co najmniej następujących systemów operacyjnych: systemy
operacyjne z rodziny Windows (w szczególności Microsoft Windows Server
2012, 2012R2, Microsoft Windows 7, Microsoft Windows 8), z rodziny Linux (co
najmniej jedna z następujących dystrybucji Red Hat, SuSE, Ubuntu), Solaris.
WYMWIR.10.
Oprogramowanie do zarządzania wirtualizacyjnymi systemami operacyjnymi
musi co najmniej:
a) umożliwiać jednoczesne zarządzanie trzema wirtualizacyjnymi systemami
operacyjnymi oraz zainstalowanymi na nich wirtualnymi maszynami.
b) umożliwiać zarządzanie wirtualizacyjnymi systemami operacyjnymi
z dowolnej stacji roboczej w sieci z zainstalowanym systemem operacyjnym
Zamawiający zezwala na instalację na wspomnianych stacjach roboczych
oprogramowania służącego do podłączenia się do systemu zarządzania).
c) umożliwiać tworzenie profili użytkowników mających prawa tylko do odczytu
lub odczytu i zapisu do poszczególnych wirtualizacyjnych systemów
operacyjnych.
d) oferować scentralizowany serwer licencyjny, z którego licencje są
delegowane na poszczególne wirtualizacyjne systemy operacyjne.
e) monitorować utylizację pamięci, procesorów wirtualizacyjnych systemów
operacyjnych jak i samych wirtualnych maszyn.
Strona 133 z 161
7.5.3.Oprogramowanie zabezpieczające
Poniżej przedstawiono wymagania dla oprogramowania zabezpieczającego przeznaczonego dla
dostarczanych w ramach zamówienia urządzeń. Ochrona antywirusowa dotyczy zaoferowanych
serwerów z systemami operacyjnymi. Ich ilość będzie wynikała z koncepcji Wykonawcy.
Oprogramowanie antywirusowe należy dostarczyć na wszystkie systemy operacyjne zgodnie z
zaproponowaną przez Wykonawcę koncepcją.
ID wymagania
Opis wymagania
WYMZAB.1.
Oprogramowanie zabezpieczające musi zapewniać ochronę antywirusowa
serwerów pracujących pod kontrolą systemu operacyjnego Linux oraz rodziny MS
Windows Server zaoferowanych przez Wykonawcę w ofercie.
WYMZAB.2.
Wymaga się dostarczenia licencji dla urządzeń UTM w liczbie pozwalającej na
ochronę antywirusową serwerów w ramach danej lokalizacji.
WYMZAB.3.
Oprogramowanie do realizacji funkcji bezpieczeństwa musi posiadać następujące
funkcjonalności:
możliwość automatycznego aktualizowania bazy wirusów,
strukturę klient serwer,
możliwość ochrony stacji roboczych i serwerów,
centralną konsolę zarządzania,
automatyczną aktualizację bazy wirusów przez oprogramowanie klienckie
zainstalowane na stacjach komputerowych lub serwerach,
f) administracyjny interfejs graficzny,
g) konfigurację zakresu oraz poziomu ochrony,
h) zabezpieczenia przed wyłączeniem klienta przez użytkownika stacji
roboczej, a w razie złamania tych zabezpieczeń – centralna sygnalizacja
wyłączenia klienta,
i) ochronę
antywirusową
systemu
monitorowana
i
zarządzana
z pojedynczej, centralnej konsoli,
j) możliwość instalacji konsoli zarządzania niezależnie na wielu stacjach
komputerowych lub serwerach.
a)
b)
c)
d)
e)
7.5.4.Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową
Poniżej przedstawiono wymagania do zarządzania – monitorowania infrastrukturą sprzętową.
ID wymagania
Opis wymagania
WYMMON.1.
Zdalne włączanie/wyłączanie/restart niezależnie dla każdego serwera.
WYMMON.2.
Zdalne udostępnianie napędu CD-ROM/DVD/ISO na potrzeby każdego serwera
WYMMON.3.
Zdalny dostęp do urządzań z poziomu przeglądarki internetowej, bez konieczności
WYMMON.4.
W danym momencie musi być niezależny, równoległy dostęp do konsol tekstowych
i graficznych wszystkich serwerów w ramach infrastruktury.
WYMMON.5.
Zdalna identyfikacja fizycznego serwera i obudowy za pomocą sygnalizatora
optycznego.
WYMMON.6.
Wymaga się aby zarządzanie całą infrastrukturą odbywało się w oparciu
o jednolite oprogramowanie. Oprogramowanie musi w sposób graficzny
wizualizować stan poszczególnych elementów infrastruktury (stan normalnej pracy,
Strona 134 z 161
ID wymagania
Opis wymagania
uwagi, awarie) a jednocześnie pozwalać na zarządzanie w sposób integralny i w
oparciu o pojedynczy serwer zarządzania.
Oprogramowanie to musi wykorzystywać standardowe protokoły sieciowe takie jak:
HTTP, SNMP, WBEM. W szczególności oprogramowanie to musi posiadać
następujące funkcjonalności:
a) Graficzne zobrazowanie stanu infrastruktury z możliwością przejścia od
widoku ogólnego do widoku szczegółowego każdego z elementów
infrastruktury (architektura drill-down).
b) Możliwość kontroli wersji zainstalowanych sterowników/agentów na
serwerach, możliwość przeprowadzania uaktualnień sterowników/agentów
zdalnie z systemu zarządzania.
c) Możliwość zdalnej reakcji na zdarzenia w infrastrukturze np. poprzez
automatyczne wykonywanie skryptów, możliwość automatycznego
powiadamiania administratorów przez e-mail.
d) Dostęp do aplikacji zarządzającej powinien być możliwy z serwera
zarządzającego lub dowolnego innego miejsca przez przeglądarkę
internetową (połączenie szyfrowane SSL) bez konieczności instalowania
dodatkowego oprogramowania producenta serwera.
e) Możliwość monitorowania zużycia energii dla jednego lub grupy serwerów.
f) Możliwość nakładania limitów zużycia mocy na serwer lub grupę serwerów
(w ramach możliwości technologii x86-64).
g) Możliwość uzyskania szczegółowych informacji o serwerze odnośnie jego
komponentów, firmware, systemu operacyjnego, adresu IP.
h) Monitorowanie utylizacji następujących podzespołów serwera: procesor,
pamięć, dyski twarde, interfejsy sieciowe.
WYMMON.7.
Licencje na powyższą funkcjonalność na serwery dostarczane w ramach jednej
lokalizacji.
WYMMON.8.
Zamawiający wymaga dokumentacji w języku polskim (alternatywnie dopuszcza się
język angielskim)..
WYMMON.9.
Oprogramowanie oraz dostarczony sprzętu muszą umożliwiać zdalny dostęp do
urządzeń fizycznych, w tym zdalne zarządzanie.
7.5.5.System operacyjny
Poniżej przedstawiono wymagania dla systemów operacyjnych.
ID wymagania
Opis wymagania
WYMSO.1.
System operacyjny musi posiadać architekturę 64 bitową.
WYMSO.2.
System operacyjny musi pracować w architekturze zgodnej ze standardem x86.
WYMSO.3.
System operacyjny musi wspierać pamięć RAM co najmniej do wielkości 768GB.
WYMSO.4.
System operacyjny musi pozwalać na budowę serwerowych klastrów wysokiej
dostępności i wysokiego bezpieczeństwa. Koncepcja funkcjonowania systemu
będzie ustalona na etapie analizy przedwdrożeniowej.
WYMSO.5.
System operacyjny musi wspierać co najmniej następujące oprogramowanie do
wirtualizacji: VMware, OVM, KVM (należy przez to rozumieć techniczną
możliwość wirtualizacji, a nie certyfikację producenta systemu operacyjnego dla
wymienionych technologii.
WYMSO.6.
System
operacyjny musi pozwolić
na prawidłową i bezawaryjną pracę
Strona 135 z 161
ID wymagania
Opis wymagania
oprogramowanie aplikacyjnego oraz systemowego.
WYMSO.7.
System operacyjny musi pozwolić na uruchomienie wszystkich funkcji
oprogramowania aplikacyjnego i narzędziowego opisanego w Opisie Przedmiotu
Zamówienia w ramach jednej lokalizacji. Zamawiający dopuszcza sytuacje, gdy w
jednej lokalizacji funkcjonują różne systemy operacyjne (np. Windows i Linux).
Zamawiający dopuszcza również, aby część funkcji systemu była realizaowana
przy pomocy urządzeń typu appliance. Szczegółowa koncepcja powinna zostać
opracowana na etapie analizy przedwdrożeniowej.
WYMSO.8.
Zamawiający wymaga przeanalizowania, zaproponowania i udokumentowania
konfiguracji klastra wydajnościowego i bezpieczeństwa w oparciu o dostarczoną
infrastrukturę sprzętową i dostarczone licencje oprogramowania.
WYMSO.9.
Dostarczone oprogramowanie musi umożliwiać wirtualizację zasobów od warstwy
systemu operacyjnego. Wymaga się, aby Wykonawca wykonał analizę, projekt
i dokumentację konfiguracji środowisk wirtualnych w oparciu o dostarczoną
infrastrukturę sprzętową i dostarczone licencje oprogramowania.
7.5.6.Oprogramowanie bazy danych
A. Oprogramowanie bazy danych - Region
Poniżej przedstawiono wymagania dla oprogramowania baz danych dla warstwy regionalnej.
ID wymagania
Opis wymagania
WYMOBD.1.
W ramach przedmiotu Zamówienia musi zostać dostarczony komplet licencji na
oprogramowanie Baz danych, zgodny z Dokumentacją Projektową w zakresie
architektury dla Oprogramowania systemowego, który pozwoli na uruchomienie
wszystkich funkcjonalności oprogramowania aplikacyjnego opisanego w Opisie
Przedmiotu Zamówienia w ramach jednej lokalizacji na zaoferowanym sprzęcie.
WYMOBD.2.
Oferowany motor bazy danych musi posiadać wsparcie Wykonawcy realizowane
w trybie 24/7 poprzez portal internetowy oraz linię telefoniczną
WYMOBD.3.
Dostarczona licencja musi być licencją dożywotnią
WYMOBD.4.
Oferowany motor bazy danych musi wspierać konfigurację klastra
wydajnościowego oraz bezpieczeństwa w trybie active-active dla co najmniej 4
fizycznych CPU z możliwością skalowania w górę bez konieczności zmiany wersji
licencji
WYMOBD.5.
Zwiększenie bądź zmniejszenie liczby serwerów obsługujących klastrową bazę
danych nie może powodować konieczności reorganizacji fizycznej (zmiana
organizacji plików danych) oraz logicznej struktury baz danych (tabel / indeksów).
WYMOBD.6.
Oferowany motor bazy danych musi posiadać możliwość przeźroczystego dla
aplikacji szyfrowania danych
WYMOBD.7.
Oferowany motor bazy danych musi realizować funkcjonalność ochrony dowolnej
tabeli przed użytkownikami administracyjnymi, posiadającymi najwyższe
systemowe uprawnienia (np. select_any_table), tak aby nie było możliwości
odczytania informacji
WYMOBD.8.
Motor bazy danych powinien udostępniać możliwość zrównoleglenia operacji SQL
(zapytania, instrukcje DML, ładowanie danych, tworzenie indeksów, przenoszenie
Strona 136 z 161
tabel/indeksów pomiędzy przestrzeniami danych) oraz procesów wykonywania
kopii bezpieczeństwa bądź odtwarzania.
WYMOBD.9.
Rozwiązanie musi pozwalać na określenie dodatkowych warunków
uwierzytelniania lub wykonania operacji na bazie, tak aby realizacja określonych
działań w bazie możliwa była tylko w godzinach pracy, z określonej adresacji IP.
WYMOBD.10.
Rozwiązanie musi pozwalać na raportowanie wszystkich prób naruszenia
w obszarze szczególnie chronionym (np. próba nieuprawnionego dostępu do
tabeli pacjentów)
WYMOBD.11.
Infrastruktura motoru bazy danych musi posiadać możliwość zarządzania
klastrami baz danych
B. Oprogramowanie bazy danych - Szpitale
Poniżej przedstawiono wymagania dla oprogramowania baz danych dla warstwy lokalnej.
ID wymagania
Opis wymagania
WYMOBDSZP.1. W ramach przedmiotu Zamówienia musi zostać dostarczony komplet licencji na
oprogramowanie Baz danych, zgodny z Dokumentacją Projektową w zakresie
architektury dla Oprogramowania systemowego, który pozwoli na uruchomienie
wszystkich funkcjonalności oprogramowania aplikacyjnego opisanego w Opisie
Przedmiotu Zamówienia w ramach jednej lokalizacji na zaoferowanym sprzęcie.
WYMOBDSZP.2. Dostarczona licencja musi być licencją dożywotnią
WYMOBDSZP.3. Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML
(INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza
modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych
(np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba
zalogowania użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto
mechanizm wyzwalaczy powinien umożliwiać oprogramowanie obsługi instrukcji
DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych
widokach (views).
WYMOBDSZP.4. Procedury i funkcje składowane powinny mieć możliwość parametryzowania za
pomocą parametrów prostych jak i parametrów o typach złożonych,
definiowanych przez użytkownika. Funkcje powinny mieć możliwość zwracania
rezultatów jako zbioru danych, możliwego do wykorzystania jako źródło danych w
instrukcjach SQL (czyli występujących we frazie FROM). Ww. jednostki
programowe powinny umożliwiać wywoływanie instrukcji SQL (zapytania,
instrukcje DML, DDL), umożliwiać jednoczesne otwarcie wielu tzw. kursorów
pobierających paczki danych (wiele wierszy za jednym pobraniem) oraz wspierać
mechanizmy transakcyjne (np. zatwierdzanie bądź wycofanie transakcji wewnątrz
procedury).
WYMOBDSZP.5. Możliwość wykonywania kopii bezpieczeństwa w trybie online (hot backup)
WYMOBDSZP.6. Wsparcie protokołu XA
WYMOBDSZP.7. Możliwość otworzenia wielu aktywnych zbiorów rezultatów (zapytań, instrukcji
DML) w jednej sesji bazy danych
WYMOBDSZP.8. Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich
rozmiar (liczbę wierszy)
Strona 137 z 161
WYMOBDSZP.9. Skalowanie rozwiązań opartych o architekturę trójwarstwową: możliwość
uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z
serwera aplikacyjnego do serwera bazy danych
7.5.7.Oprogramowanie serwera aplikacji
ID wymagania
Opis wymagania
WYMOSA.1.
W ramach przedmiotu Zamówienia musi zostać dostarczony komplet licencji na
oprogramowanie serwera aplikacji, zgodny z Dokumentacją Projektową
w zakresie architektury dla Oprogramowania systemowego, który pozwoli na
uruchomienie wszystkich funkcjonalności oprogramowania aplikacyjnego
opisanego w Opisie Przedmiotu Zamówienia w ramach jednej lokalizacji.
WYMOSA.2.
Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać zarządzanie
i monitorowanie wieloma serwerami aplikacyjnymi z jednej konsoli
WYMOSA.3.
i monitorowanie wielu aplikacji wdrożonych na różnych instancjach serwera
aplikacyjnego
WYMOSA.4.
klastrami serwerów aplikacyjnych
WYMOSA.5.
Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać monitorowanie
zasobów serwerów aplikacyjnych takich jak póle połączeń, kolejek, źródeł danych
WYMOSA.6.
Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać monitorowanie
w czasie rzeczywistym zdarzeń płynących z wielu serwerów aplikacyjnych z
możliwością wyspecyfikowania: - Poziomów zdarzeń krytycznych oraz ostrzeżeń Różnych metod notyfikacji o zdarzeniach - Definiowanie reguł notyfikacyjnych Możliwości podpięcia akcji naprawczych pod zdarzenie
WYMOSA.7.
Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać raportowanie
wydajności systemów z możliwością:


Wyspecyfikowania zakresu czasowego wyświetlanych danych
Zapisania aktualnych danych wydajnościowych jako wzorca
porównywania z przyszłymi danymi
do
WYMOSA.8.
Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać dostęp do
logów zarządzanych serwerów aplikacyjnych z możliwością: - Filtrowania po czasie
wpisu do logów - Filtrowania poziomie zalogowanej informacji (error, warning, etc.)
- Pobrania pliku logu lub wyeksportowania wiadomości do pliku
WYMOSA.9.
Infrastruktura serwera aplikacji musi posiadać wbudowaną możliwość konfiguracji
ochrony serwerów aplikacyjnych (i aplikacji) przed przeciążeniem. Dla przykładu:
jeśli liczba żądań do serwera/aplikacji jest zbyt duża, serwer powinien przekierować
nowe żądania do innych instancji w klastrze
WYMOSA.10.
Infrastruktura serwera aplikacji musi umożliwiać automatyczny restart serwera i/lub
aplikacji w sytuacji ich zawieszenia (braku odpowiedzi), pojawienia się błędów o
braku pamięci lub zbyt długiego wykonywania się wątków
WYMOSA.11.
Infrastruktura serwera aplikacji musi posiadać możliwość ograniczenia liczby sesji
HTTP w serwerze tworzonych przez daną aplikację
WYMOSA.12.
Infrastruktura serwera aplikacji musi posiadać możliwość rozdziału ruchu
Strona 138 z 161
ID wymagania
Opis wymagania
(protokołów) na różne interfejsy sieciowe (lub adresy IP). Np. możliwość
rozdzielenia ruchu administracyjny/monitoringu od ruchu aplikacyjnego do ruchu
związanego z funkcjonowaniem klastra (replikacja sesji) – dane związane z tymi
funkcjami mogą być przesyłane poprzez inne karty sieciowe/podsieci.Ruch
sieciowy na potrzeby aplikacji powinien być rozdzielony od ruchu sieciowego na
potrzeby komunikacji klastra. Sposób implementacji należy do Wykonawcy.
WYMOSA.13.
Infrastruktura serwera aplikacji musi posiadać możliwość automatycznego
i ręcznego restartu (migracji) instancji serwerów aplikacyjnych na innych fizycznych
maszynach w razie awarii, wraz z przeniesieniem istotnych dla przetwarzania
danych. Automatyczna rekonfiguracja serwerów aplikacyjnych po restarcie (zmiana
adresu IP, itp.)
WYMOSA.14.
Infrastruktura serwera aplikacji musi posiadać możliwość konfiguracji
i zarządzania środowiskiem serwerów aplikacyjnych równocześnie poprzez:
konsole webowe, skrypty, programowo, SNMP
WYMOSA.15.
Infrastruktura serwera aplikacji musi posiadać możliwość łatwego rozszerzania
funkcjonalności oferowanych przez konsole administracyjne. Rozszerzenia nie
powinny wymagać zmian w kodzie istniejących konsol. Rozszerzenia nie powinny
wymagać zmian w przypadku przyszłych aktualizacji (upgrade wersji serwera
aplikacyjnego, itp.)
WYMOSA.16.
Infrastruktura serwera aplikacji musi posiadać możliwość wprowadzania zmian
w konfiguracji środowiska serwerów aplikacyjnych w sposób transakcyjny (albo
wszystkie zmiany zostaną poprawnie wprowadzone albo żadna zmiana nie będzie
wprowadzona)
WYMOSA.17.
Infrastruktura serwera aplikacji musi posiadać możliwość automatycznego
tworzenia skryptów konfiguracyjnych (rejestrowanie wykonywanych zmian,
a następnie ich zapisywanie do pliku, tak, aby później taki plik uruchomić
w postaci skryptu)
WYMOSA.18.
Infrastruktura serwera aplikacji musi posiadać wbudowany mechanizm
automatycznej naprawy transakcji podczas restartu serwera aplikacyjnego
WYMOSA.19.
Infrastruktura serwera aplikacji musi posiadać możliwość
i monitorowania wieloma serwerami aplikacyjnymi z jednej konsoli
WYMOSA.20.
Infrastruktura serwera aplikacji musi posiadać możliwość zarządzania
i monitorowania wielu aplikacji wdrożonych na różnych instancjach serwera
aplikacyjnego
WYMOSA.21.
Infrastruktura serwera aplikacji musi posiadać możliwość zarządzania klastrami
serwerów aplikacyjnych
zarządzania
8. Platforma danych
8.1. Metadane dla źródeł danych
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-
Strona 139 z 161
Transaction
and
Content
Specifications”(dostępny
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf)..
na
stronie:
Zakres i obligatoryjność metadanych z powyższej tabeli jest właściwa dla każdego klienta
repozytorium i rejestru EDM, w tym dla systemów dziedzinowych Szpitali.
8.2. Model biznesowy platformy danych
System gromadzenia EDM (repozytorium EDM) pozostaje częścią warstwy lokalnej Systemu MSIM,
a więc pozostaje własnością Szpitala, który odpowiada za jego utrzymanie i rozwój zgodnie
z wytycznymi projektu MSIM – projekt pilotażowy.
Rejestr EDM pozostaje częścią warstwy regionalnej Systemu MSIM.
Strona 140 z 161
9. Metodyka wdrożenia Systemu
9.1. Dokumentacja
Wykonawca musi dostarczyć dokumentację w języku polskim, zgodnie z następującymi wymaganiami.
ID wymagania
Opis wymagania
DOK.1
Wykonawca zobowiązany jest do przekazania w wersji papierowej 1 egzemplarz
oraz wersji elektronicznej po 2 egzemplarze (w wersji.docx oraz.pdf) dokumentacji
wymaganej poniższymi wymaganiami na trwałym nośniku (np. CD lub DVD lub
pendrive, itp.).
Na każdym nośniku dodatkowo poza przekazywaną dokumentacją musi być
dostępny plik zawierający poniższy wykaz:
 Nazwa pliku (tożsama nazwie dokumentu)
 Wersja pliku (tożsama wersji dokumentu)
 Data opracowania pliku
 Autorzy dokumentu
Wykonawca przeprowadzi Analizę przedwdrożeniową, która zawierać będzie co
najmniej:
 Dla każdej dostarczanej aplikacji biznesowej:
o Przypadki użycia
o Architekturę komponentów aplikacji
 Projekt Techniczny Systemu MSIM
 Plan Wdrożenia Projektu
Wykonawca przedstawi do akceptacji Zamawiającemu spis treści Analizy
przedwdrożeniowej.
DOK.2
1. Zamawiający dokona akceptacji przedstawionego spisu treści Analizy
przedwdrożeniowej w terminie 2 dni roboczych lub zgłosi pisemnie uwagi w tym
terminie (uwagi będą konkretne w jasny sposób informujące jakie modyfikacje
przedstawionego materiału powinien wprowadzić Wykonawca, aby Zamawiający
dokonał jego akceptacji).
2. Jeżeli Zamawiający nie wniesie uwag w terminie 2 dni roboczych oznacza to,
że zaakceptował przedstawiony do akceptacji materiał.
3. Wykonawca w terminie 2 dni roboczych wprowadzi modyfikacje wynikające z
przedstawionych uwag lub wyjaśni z jakiego powodu odrzucił uwagi.
4. Zamawiający w terminie 1 dnia roboczego zweryfikuje poprawiony spis treści
Analizy przedwdrożeniowej i dokona akceptacji. Jeżeli Zamawiający nie zgłosi
zastrzeżeń co do powodów ewentualnego odrzucenia uwag w przeciągu 1 dnia
roboczego oznacza to, że zaakceptował przedstawiony do akceptacji materiał.
5. W przypadku sporu dotyczącego ewentualnych odrzuconych uwag
kierownictwo projektu przygotuje rekomendację dla Komitetu sterującego, który
podejmie ostateczną decyzję dotyczącą kwestii spornych.
DOK.3
DOK.4
6.
Procedura akceptacji spisu treści Analizy przedwdrożeniowej nie może
powodować wstrzymania prac dotyczących dokumentu Analizy.
W ramach analizy przedwdrożeniowej musi zostać przeprowadzona wizja lokalna
w terminach uzgodnionych z Partnerami Projektu. Jej wyniki Wykonawca
zobowiązany jest przedstawić w dokumencie Analiza przedwdrożeniowa.
Wykonawca w ramach Analizy przedwdrożeniowej opracuje Harmonogram
wdrożenia, który zawierać będzie co najmniej:
 Plan dostaw infrastruktury sprzętowej oraz sieciowej (w postaci diagramu
Strona 141 z 161
ID wymagania
Opis wymagania
Gantta ze wskazaniem planowanych dat oraz czasu trwania dostaw)
Plan kolejności instalacji/konfiguracji i wdrożenia poszczególnych
komponentów (aplikacji biznesowych, aplikacji infrastrukturalnych,
oprogramowania standardowego, systemowego, itd.)
Wykonawca opracuje Plan Komunikacji dla projektu MSIM – projekt pilotażowy
w ramach którego będą zebrane informacje nt.:
 Danych kontaktowych członków zespołu projektowego
 Zasady komunikacji (formalnej oraz operacyjnej)
 Przyporządkowanie ról projektowych do osób zaangażowanych w prace
projektowe (w tym odpowiedzialność za dany produkt/komponent).
Wykonawca opracuje Dokumentację projektową na którą składają się co najmniej:
 Zaktualizowany Projekt techniczny
 Dokumentację techniczną powykonawczą
 Dokumentacje konfiguracyjną poszczególnych urządzeń i oprogramowania
 Schemat połączeń wszystkich urządzeń wchodzących w zakres projektu
 Zestawienie wszystkich adresacji serwerów, loginów, haseł wraz
aplikacjami oraz systemami do logowania
 Zestawienie ważności wszystkich certyfikatów, gwarancji, licencji
 Zestawienie nr seryjnych, nazw własnych, modeli poszczególnych
elementów oprogramowania i sprzętu.
 Zestawienia telefonów infolinii, serwisowych wraz z nazwami firmami oraz
godzinami pracy w celu zgłoszenia urządzeń do napraw
 Procedury testowe dla przeprowadzenia weryfikacji poprawności działania
poszczególnego oprogramowania i sprzętu (z podziałem na testy
miesięczne, kwartalne)
 Dokumentację użytkownika i administratora
 Dokumentację testową
 Dokumentację interfejsów integracji
 Dokumentacja w zakresie bezpieczeństwa i przetwarzania danych
osobowych zgodna z zapisami Generalnego Inspektora Ochrony Danych
Osobowych
w zakresie opracowania i wdrożenia polityki bezpieczeństwa.
Dokumentacja użytkownika oraz dokumentacja administratora powinny dodatkowo:
 Zawierać zrzuty ekranów demonstrujące oczekiwane stany zachowania
systemu w kluczowych punktach przebiegu najczęściej wykonywanych
operacji
 Być przygotowane w wersji dokumentu elektronicznego (.pdf.,.doc) oraz
HTML
 Zawierać szczegółowe omówienie wszystkich funkcji systemu. Lista funkcji
powinna być ułożona w kolejności alfabetycznej lub w postaci indeksu
 Mieć charakter procesowy, opisujący sposób postępowania użytkownika
w celu uzyskania konkretnego i oczekiwanego przez niego efektu z
pomocą zrzutów ekranowych i krótkich opisów tekstowych
Dokumentacja interfejsów integracji musi zawierać co najmniej:
 Strukturę komunikatów
 Opis przepływu informacji z wykorzystaniem jednej z powszechnie
stosowanych notacji np. UML
 Schemat komunikacji pomiędzy warstwa regionalną a lokalną
Dokumentacja interfejsów integracji musi stanowić komplet wymagań oraz
wytycznych dla podmiotów leczniczych, które dołączane będą do warstwy

DOK.5
DOK.6
DOK.7
DOK.8
Strona 142 z 161
ID wymagania
DOK.9
DOK.10
DOK.11
DOK.12
Opis wymagania
regionalnej (a nie są objęte niniejszym projektem).
Wykonawca musi opracować:
 Harmonogram integracji Partnerów Projektu z warstwą regionalną
 Procedury integracyjne dedykowane dla Partnerów Projektu
 Procedury integracyjne dla nowo podłączanych jednostek do warstwy
regionalnej (nie objętych niniejszym projektem) obejmujące co najmniej:
o Opis zadań jakie muszą zostać wykonane (kroki) dla nowych
jednostek.
o Przypisaniu zadań do ról/osób.
o Warunki rozpoczęcia procedury (np. formalne zatwierdzenie
włączenia jednostki do Systemu) oraz jej zakończenia.
Wykonawca musi opracować szczegółowy projekt techniczny dostarczanego
rozwiązania umożliwiający instalację i konfigurację wszystkich wymaganych
komponentów oraz aplikacji. Jako Projekt techniczny rozumie się dokumentację
opisującą szczegółową konfigurację komponentów, ich wzajemnych relacji
i powiązań umożliwiających zainstalowanie, podłączenie, uruchomienie i poprawną
pracę poszczególnych aplikacji i systemów.
Projekt techniczny musi obejmować co najmniej następujące informacje:
 Model architektury logicznej (listę i opis komponentów, wraz z wykazem
oprogramowania, za pomocą którego dany komponent jest realizowany,
interfejsy logiczne pomiędzy komponentami Systemu)
 Model architektury technicznej (wykaz oprogramowania standardowego,
wykaz oprogramowania dedykowanego budowanego w ramach niniejszego
postępowania, konfigurację oprogramowania, opis interfejsów z systemami
zewnętrznymi wraz ze specyfikacją komunikacji, rozmieszczenie
oprogramowania w architekturze fizycznej)
 Architektura fizyczna (opis dostarczonego sprzętu w tym nazwa/typ
urządzenia, rola w systemie, parametry, numer seryjny; architektura
fizyczna
rozwiązania,
architektura
sieciowa,
projekt
instalacji
dostarczanego rozwiązania, konfigurację urządzeń)
 Model projektowy (model bazy danych, interfejsy międzysystemowe),
 Schemat strukturalny/blokowy podłączenia wszystkich elementów
infrastruktury sprzętowej osobno dla regionu i jednostek lokalnych oraz dla
całego systemu MSIM (z uwzględnieniem projektu okablowania,
podłączenia poszczególnych portów oraz gniazd)
 Dokumentacja procesu wytwórczego dla oprogramowania dedykowanego
budowanego na potrzeby niniejszego zamówienia (opis standardów pisania
kodów źródłowych, opis wykorzystanych technologii w tym języki
programowania, biblioteki).
Wykonawca musi opracować Dokumentację użytkownika w tym podręcznik
użytkownika, administratora oraz instrukcje stanowiskowe dla każdej aplikacji
biznesowej.
Wykonawca musi opracować Dokumentację administratora, która zawierać będzie
co najmniej:
 Procedury administracyjne
 Procedury instalacji i konfiguracji
 Procedury bieżących działań administracyjnych
 Procedury okresowych/planowanych działań administracyjnych
 Procedury aktualizacji standardowych elementów dostarczonego
rozwiązania
 Procedurę dołączania nowych jednostek do warstwy regionalnej
Strona 143 z 161
ID wymagania
Opis wymagania

DOK.13
DOK.14
DOK.15
DOK.16
DOK.17
DOK.18
DOK.19
DOK.20
DOK.21
DOK.22
Procedury awaryjne (w tym wykonanie kopii bezpieczeństwa – pełnej oraz
przyrostowej, postępowanie w przypadku awarii systemu)
 Procedur Distater Recovery ze scenariuszami awarii oraz procedur działań
odtworzeniowych i uruchomieniowych mających na celu zminimalizowanie
strat danych oraz zminimalizowanie czasu niedostępności usług
Wykonawca musi opracować dokumentację testów, na którą składają się co
najmniej:
 scenariusze testowe umożliwiające weryfikację poprawności instalacji
i konfiguracji zainstalowanych komponentów. Za kompletność scenariuszy
testowych odpowiada Wykonawca.
 Scenariusze testów (w tym przypadki testowe) dla testów integracyjnych na
etapie dołączania nowych jednostek do Systemu MSIM
 Plan testów
 Raport z testów (zgodny z zaakceptowaną Procedurą testów). Raport
z testów potwierdza i podsumowuje przeprowadzone testy i stanowi
załącznik do protokołu odbioru Komponentu.
Plan testów musi zawierać co najmniej:
 proponowany czas trwania testu
 podstawowe informacje na temat przedmiotu testów,
 zakres testów (wykaz wymagań dla każdej z testowanych aplikacji
biznesowych),
 scenariusz testów danej Funkcjonalności, wraz z informacją o konfiguracji
(jeżeli jest wymagana dodatkowa), kryteria akceptacyjne.
Scenariusze testowe akceptowane będą przez Zamawiającego przed
rozpoczęciem testów.
Wykonawca
musi
opracować
szczegółową
dokumentację
techniczną
powykonawczą zawierającą dokładny opis konfiguracji zainstalowanych
komponentów poszczególnych aplikacji oraz systemów.
Wykonawca dostarczy pliki źródłowe dokumentacji, tak, aby była możliwa ich
modyfikacja.
Wykonawca dostarczy równocześnie Zamawiającemu pełną dokumentację
standardowo dostarczaną przez producentów do dostarczonego sprzętu oraz
oprogramowania.
Wykonawca dostarczy Zamawiającemu dokumentację oraz karty gwarancyjne dla
oprogramowania oraz sprzętu wchodzącego w zakres systemu MSIM
obowiązujące dla całego okresu gwarancyjnego.
Wykonawca
dostarczy
Zamawiającemu
dokumentację
licencyjną
dla
oprogramowania oraz sprzętu wchodzącego w zakres systemu MSIM.
Wykonawca dostarczy Zamawiającemu kody źródłowe systemu MSIM.
Wykonawca dostarczy Zamawiającemu dokumentację do systemu personalizacji.
1. Dokumentacja, o której mowa w wymaganiach DOK.2, DOK.3. DOK.4. DOK.5
należy dostarczyć w ramach Etapu I – Analiza przedwdrożeniowa
2. Dokumentacja, o której mowa wymaganiach: DOK.6, DOK.7, DOK.8, DOK.11,
DOK.12, DOK.15, DOK.17, DOK.18, DOK.19, DOK.20, DOK.21 należy dostarczyć
najpóźniej w ramach Etapu VIII – Odbiór końcowy
3.
Dokumentacja, o której mowa wymaganiach: DOK.9 należy dostarczyć
najpóźniej w ramach etapu VI – Integracja systemu MSIM
4. Dokumentację, o której mowa w wymaganiu DOK.10 – zgodnie z zasadą
opisaną w pytaniu do wymagania DOK.10
5.
Dokumentację, o której mowa w wymaganiu DOK.13, DOK.14 należy
dostarczyć najpóźniej w ramach etapu 7 – testy i szkolenia
6. Dokumentację, o której mowa w wymaganiu DOK.16 należy dostarczyć na
etapie zależnym od rodzaju dokumentacji, której dotyczą pliki źródłowe zgodnie z
poprzednimi punktami.
Strona 144 z 161
ID wymagania
Opis wymagania
DOK.23
1. Zamawiający dokona akceptacji przedstawionej dokumentacji w terminie 5 dni
roboczych (dla Planu komunikacji i Spisu treści analizy 2 dni roboczych) lub zgłosi
pisemnie uwagi w tym terminie (uwagi będą konkretne w jasny sposób informujące
jakie modyfikacje przedstawionego materiału powinien wprowadzić Wykonawca,
aby Zamawiający dokonał jego akceptacji).
2. Jeżeli Zamawiający nie wniesie uwag w terminie 5 dni roboczych (dla Planu
komunikacji i Spisu treści analizy 2 dni roboczych) oznacza to, że zaakceptował
przedstawiony do akceptacji materiał.
3. Wykonawca w terminie 5 dni roboczych (dla Planu komunikacji i Spisu treści
analizy 2 dni roboczych) wprowadzi modyfikacje wynikające z przedstawionych
uwag lub wyjaśni z jakiego powodu odrzucił uwagi.
4. Zamawiający w terminie 2 dni roboczych (dla Planu komunikacji i Spisu treści
analizy 1 dnia roboczego) zweryfikuje poprawiony materiał i dokona akceptacji.
Jeżeli Zamawiający nie zgłosi zastrzeżeń co do powodów ewentualnego
odrzucenia uwag w przeciągu 2 dni roboczych (dla Planu komunikacji i Spisu treści
analizy 1 dnia roboczego) oznacza to, że zaakceptował przedstawiony do
akceptacji materiał.
5. W przypadku sporu dotyczącego ewentualnych odrzuconych uwag kierownictwo
projektu przygotuje rekomendację dla Komitetu sterującego, który podejmie
ostateczną decyzję dotyczącą kwestii spornych.
9.2. Szkolenia
Wykonawca zobowiązany jest do przygotowania materiałów szkoleniowych, umożliwiających
samodzielnie zapoznanie się z funkcjami Systemu.
W ramach realizacji przedmiotu zamówienia Wykonawca zobowiązuje się do przeprowadzenia
szkoleń. Celem tych szkoleń będzie teoretyczne i praktyczne przygotowanie osób pełniących funkcje
administratorów Systemu, oraz osób odpowiedzialnych za merytoryczne wsparcie pracowników
Podmiotów. Szkolenia te zostaną przeprowadzone w Krakowie. Wykonawca zapewni salę
szkoleniową. Sala szkoleniowa powinna być odpowiednio wyposażona w sprzęt umożliwiający
przeprowadzenie szkolenia (np. komputery, switch, rzutnik i ekran). Wykonawca zapewni poczęstunek
dla każdego uczestnika w czasie szkolenia (kawa, herbata, ciastka) oraz lunch. Każdy dzień
szkoleniowy będzie obejmował 8 godzin zajęć (przez godzinę zajęć należy rozumieć 45 minut).
Szkolenia kierowane dla obsługi technicznej muszą być certyfikowane. W ramach szkoleń
certyfikowanych Wykonawca zapewni (i sfinansuje) możliwość jednorazowego zdawania egzaminu dla
każdego z uczestników szkolenia potwierdzającego zdobycie odpowiednich kwalifikacji niezbędnych
w celu prawidłowej realizacji, utrzymania i rozwijania produktów Projektu.
Szkolenia certyfikowane to szkolenia zakończone uzyskaniem oficjalnego certyfikatu w zakresie
objętym szkoleniem. Są one wymagane także w zakresie produktów wytworzonych przez
Wykonawcę. Szkolenia akredytowane to szkolenia w zakresie produktów innych podmiotów lub
Wykonawcy dostarczanych w ramach projektu zgodnie z systemem szkoleń dla tych produktów.
Wykonawca odpowiada za odpowiedni dobór treści szkoleniowych z punktu widzenia administracji i
eksploatacji MSIM. W przypadku, gdy w zakresie produktu innego podmiotu lub wykonawcy możliwe
jest zastosowanie ścieżki kończącej się certyfikatem. Zamawiający dopuszcza szkolenie
certyfikowane.
Każde szkolenie musi być zakończone wypełnieniem ankiet ewaluacyjnych szkolenie. Ankieta musi
obejmować m.in. organizację szkolenia, treść szkolenia (w tym przygotowanie prowadzących
szkolenie). Wykonawca zobowiązany jest w terminie określonym w Umowie do przedstawienia
zbiorczego raportu ze szkoleń. Warunkiem zatwierdzenia poprawnej realizacji szkoleń jest dodatkowo
pozytywna ocena z ankiet (tj. dla 5 punktowej skali, szkolenie musi zostać ocenione na poziomie 3,5
pkt), w przypadku gdy szkolenie nie otrzyma minimalnej wymaganej liczby punktów Wykonawca
zobowiązany jest do ponownego przeprowadzenia szkolenia w terminie uzgodnionym z
Strona 145 z 161
Zamawiającym. Dla ponownego szkolenia obowiązują wszystkie warunki jak dla szkolenia
pierwotnego.
9.2.1.Zakres szkoleń – wymagania dla szkoleń dla użytkowników Systemu
Ogólne wymagania dla szkoleń dla użytkowników Systemu tj. końcowych użytkowników Systemu (np.
lekarze, pielęgniarki oddziałowe) delegowanych przez Zamawiającego:
1. Każde ze szkoleń musi być prowadzone przez trenera wiodącego oraz trenera
wspomagającego
2. Na co najmniej 3 dni robocze przed terminem rozpoczęciem szkoleń uczestniczy szkoleń
otrzymają wersje elektroniczne materiałów szkoleniowych
3. Szkolenia prowadzone będą w grupach maksymalnie 16 osobowych, Zamawiający dopuszcza
łączenie grup szkoleniowych pomiędzy Podmiotami (warunkiem jest zgoda Podmiotów)
4. Przez dzień szkoleniowy należy rozumieć 8 godzin zajęć.
5. Dla szkoleń w wymiarze pełnego dnia wymagane są 2 przerwy kawowe (20 minutowe) oraz
jedną na lunch (40 minutową).
6. Dla szkoleń w wymiarze połowy dnia wymaga jest jedna przerwa kawowa (20 minutowa)
7. Szkolenia muszą rozpoczynać się o godz. 8.00.
8. Szkolenia muszą być prowadzone w wydzielonych blokach tematycznych.
9. Uczestniczy szkoleń muszą otrzymać komplet materiałów w wersji papierowej
(zbindowanych).
10. Szkolenia oraz materiały muszą być przygotowane w języku polskim.
11. Na co najmniej 10 dni roboczych przed rozpoczęciem szkoleń Wykonawca zobowiązany jest
do przedstawienia szczegółowego harmonogramu szkoleń obejmującego:
a. Wskazanie terminu oraz lokalizacji poszczególnych szkoleń
b. Imię i nazwisko trenera wiodącego oraz trenera wspierającego
c. Szczegółowy program szkolenia – obejmującego wszystkie bloki tematyczne
Harmonogram szkoleń w przeciągu 3 dni roboczych zostanie zaakceptowany przez
Zamawiającego lub zgłoszone zostaną uwagi do zaproponowanych terminów szkoleń,
lokalizacji lub/oraz zakresu tematycznego – wówczas Wykonawca ma 2 dni robocze na
przedstawienie zaktualizowanego harmonogramu szkoleń
12. Po zakończeniu szkolenia Wykonawca wystawi certyfikat potwierdzający uczestnictwo
w szkoleniu, ze wskazaniem zakresu merytorycznego szkoleń oraz informacją
o współfinansowaniu szkolenia ze środków UE. Wzór certyfikatu podlegać będzie akceptacji
Zamawiającego.
13. Szkolenia musza być prowadzone na instancji testowej systemu MSIM.
Zakres merytoryczny szkoleń.
Szkolenie „Obsługa Systemu MSIM w zakresie przekazywania i wykorzystywania Elektronicznej
Dokumentacji Medycznej” musi obejmować co najmniej:




Wprowadzenie do Systemu MSIM,
Omówienie procesu przekazywania i wykorzystywania EDM,
Przykładowe scenariusze wykorzystania Systemu MSIM we wsparciu procesu zarządzania
EDM,
Ćwiczenia praktyczne z wykorzystaniem Systemu MSIM.
Szkolenie „Obsługa Systemu MSIM z zakresie zamawiania dokumentacji i obsługi IKP” musi
obejmować co najmniej:


Omówienie procesu zamawiania dokumentacji i obsługi IKP,
Strona 146 z 161


Przykładowe scenariusze wsparcia narzędziowego do zamawiania dokumentacji i obsługi IKP,
Ćwiczenia praktyczne.
Szkolenie „Obsługa Systemu MSIM z zakresie e-Rejestracji” musi obejmować co najmniej:




Omówienie procesu e-Rejestracji,
Przykładowe scenariusze wykorzystania Systemu MSIM we wsparciu procesu e-Rejestracji,
Ćwiczenia praktyczne.
Wykonawca przeprowadzi następujące szkolenia dla użytkowników Systemu:
Nazwa szkolenia
liczba dni
szkoleniowych
dla każdego
Podmiotu
liczba szkoleń dla
każdego Podmiotu
Maksymalna liczba
osób w grupie
Obsługa Systemu MSIM w zakresie
przekazywania i wykorzystywania
Elektronicznej Dokumentacji Medycznej
1
2
16
Obsługa Systemu MSIM z zakresie
zamawiania dokumentacji i obsługi IKP
0,5
1
16
Obsługa Systemu MSIM z zakresie eRejestracji
0,5
2
16
9.2.2.Zakres szkoleń – wymagania dla szkoleń dla obsługi technicznej Systemu
Szkolenia przeprowadzone przez Wykonawcę mają na celu umożliwienie Zamawiającemu na
samodzielne konfigurowanie wszystkich urządzeń i systemów oraz baz, które dostarczone zostaną
w ramach realizacji przedmiotu zamówienia. W przypadku zastosowania takich rozwiązań
technicznych, dla których szkolenia z załączonej listy nie będą wystarczające, aby spełnić powyższy
cel, Wykonawca zobowiązany jest do rozszerzenia listy oraz zakresu szkoleń. Rozszerzenie zakresu
przeprowadzonych szkoleń nie będzie powodować dodatkowych kosztów ze strony Zamawiającego.
Uczestnikami szkoleń dla obsługi technicznej Systemu będą osoby odpowiedzialne za administrację
i utrzymanie systemu oraz merytoryczne wsparcie pozostałych pracowników w zakresie obsługi
systemów wdrażanych w ramach Projektu, delegowane przez Zamawiającego (maksymalnie 5 osoby
na jedno szkolenie).
Poniżej przedstawiono minimalne ogólne wymagania dla szkoleń dedykowanych dla obsługi
technicznej systemu MSIM:
1. Każde ze szkoleń musi być prowadzone przez trenera wiodącego (dla grup szkoleniowych,
które przekraczają 10 osób Zamawiający wymaga udziału trenera wspierającego)
2. Na co najmniej 3 dni robocze przed terminem rozpoczęciem szkoleń uczestniczy szkoleń
otrzymają wersje elektroniczne materiałów szkoleniowych
3. Szkolenia prowadzone będą w grupach maksymalnie 12 osobowych, Zamawiający dopuszcza
łączenie grup szkoleniowych pomiędzy Podmiotami (warunkiem jest zgoda Podmiotów)
4. Przez dzień szkoleniowy należy rozumieć 8 godzin zajęć.
5. Dla szkoleń w wymiarze pełnego dnia wymagane są 2 przerwy kawowe (20 minutowe) oraz
jedną na lunch (40 minutową).
6. Szkolenia muszą być prowadzone w wydzielonych blokach tematycznych.
7. Uczestniczy szkoleń muszą otrzymać komplet materiałów w wersji papierowej
(zbindowanych).
Strona 147 z 161
8. Szkolenia oraz materiały muszą być przygotowane w języku polskim dla szkoleń
prowadzonych przez Wykonawcę. Dopuszcza się szkolenia i materiały angielskojęzyczne w
przypadku, gdy dotyczą oprogramowania narzędziowego występującego wyłącznie w wersji
angielskiej i posiadających wyłącznie angielskojęzyczna dokumentację producenta.
9. Na co najmniej 10 dni roboczych przed rozpoczęciem szkoleń Wykonawca zobowiązany jest
do przedstawienia szczegółowego harmonogramu szkoleń obejmującego:
a. Wskazanie terminu oraz lokalizacji poszczególnych szkoleń
b. Imię i nazwisko trenera wiodącego oraz trenera wspierającego
c. Szczegółowy program szkolenia – obejmującego wszystkie bloki tematyczne
Harmonogram szkoleń w przeciągu 3 dni roboczych zostanie zaakceptowany przez
Zamawiającego lub zgłoszone zostaną uwagi do zaproponowanych terminów szkoleń,
lokalizacji lub/oraz zakresu tematycznego – wówczas Wykonawca ma 2 dni robocze na
przedstawienie zaktualizowanego harmonogramu szkoleń
10. Po zakończeniu szkolenia, które prowadzone jest przez trenerów Wykonawcy, Wykonawca
wystawi certyfikat potwierdzający uczestnictwo w szkoleniu, ze wskazaniem zakresu
merytorycznego szkoleń oraz informacją o współfinansowaniu szkolenia ze środków UE. Wzór
certyfikatu podlegać będzie akceptacji Zamawiającego.
11. Szkolenia musza być prowadzone na instancji testowej systemu MSIM.
12. Dla szkoleń oznaczonych jako akredytowane:
a. wymagane jest dostarczenie materiałów szkoleniowych wytworzonych przez ośrodek
certyfikacyjny
b. Zamawiający dopuszcza szkolenia akredytowane prowadzone w języku angielskim
(wówczas osoby oddelegowane na szkolenie będą posiadali znajomość języka
angielskiego pozwalającą na przyswojenie wiedzy w trakcie szkoleń).
Zakres merytoryczny szkoleń dla obsługi technicznej Systemu MSIM
Wykonawca przeprowadzi następujące szkolenia dla obsługi technicznej Systemu:
Liczba dni
szkoleniowych
Liczba szkoleń
Maksymalna liczba
uczestników na
szkoleniu
Modelowanie procesów prostych i
złożonych z wykorzystaniem
dostarczonej szyny usług
3
2
5
Administrowanie i zaawansowane
użytkowanie komponentu
regionalnego Systemu
2
1
2
Administrowanie i zaawansowane
użytkowanie komponentu lokalnego
Systemu
2 dla każdego
Podmiotu
1 dla każdego
Podmiotu
2
Szkolenie z zakresu dostarczonego
serwera aplikacji
3
2
5
Szkolenie z zakresu administracji
dostarczonej infrastruktury sieciowej
3
2
5
Szkolenie z zakresu dostarczonego
oprogramowania bazy danych
2
2
5
Szkolenie z zakresu dostarczonej
usługi katalogowej
1
2
5
Konfiguracja urządzeń sieciowych
wykorzystywanych przez system
3
2
5
Nazwa szkolenia
Strona 148 z 161
Liczba dni
szkoleniowych
Liczba szkoleń
Maksymalna liczba
uczestników na
szkoleniu
Administracja systemami
operacyjnymi wykorzystywanymi
przez system
2
2
5
Administracja
bazami
danych
wykorzystywanymi przez system
2
2
5
Nazwa szkolenia
(szkolenia autoryzowany przez
producentów zależne od sprzętu
dostarczanego przez Wykonawcę).
Terminy realizacji poszczególnych szkoleń muszą być ujęte w harmonogramie projektu.
9.2.3.Harmonogram szkoleń
Zgodnie z powyższymi wymaganiami przeprowadzenie szkoleń poprzedzone jest uzgodnieniem planu
szkoleń oraz przygotowaniem materiałów szkoleniowych. Właściwe szkolenia organizowane są
w terminach, które powinny być ustalone w okresie poprzedzającym szkolenia. Dopiero wtedy znany
będzie dokładny kalendarz i wymagania osób uczestniczących w szkoleniach. W poniższym
harmonogramie wykazano jedynie listę zadań zarówno przygotowawczych, jak i właściwych dla
szkoleń i przytoczono orientacyjne terminy (w skali miesiąca). Zakres szkoleń, harmonogram oraz
materiały przygotuje Wykonawca i przedstawi do akceptacji Zamawiającemu.
Nazwa zadana
2015
1
2
3
4
5
6
Przygotowanie materiałów szkoleniowych
Przygotowanie Planów szkoleń
Przeprowadzenie szkoleń dla użytkowników Systemu
Przeprowadzenie szkoleń dla obsługi technicznej Systemu
9.2.4.Instruktaże stanowiskowe
Wykonawca oprócz ww. szkoleń będzie zobowiązany do przeprowadzenia instruktaży
stanowiskowych dla administratorów z podstawowych elementów niezbędnych do utrzymania systemu
w warstwie regionalnej oraz w warstwie lokalnej dla każdego Podmiotu (z warstwy sprzętowo
programowej). W ramach instruktaży dla komponentu lokalnego przeszkolone zostaną po 2 osoby
z każdego Podmiotu. Instruktaże dla komponentu regionalnego zostaną przeprowadzone oddzielnie.
Instruktaże zostaną przeprowadzone w siedzibach Podmiotów. Zamawiający zapewni pomieszczenia
wyposażone w sprzęt umożliwiający przeprowadzenie instruktaży. Każdy dzień instruktażowy będzie
obejmował 8 godzin zajęć.
W ramach instruktaży uczestnicy otrzymają komplet materiałów instruktażowych (w wersji papierowej
oraz elektronicznej) obejmujących swoim zakresem cały instruktaż. Instruktaże powinny być
realizowane w języku polskim. Materiały będą w języku polskim.
Zakres instruktaży będzie obejmował:

2 dni – instruktaż z administrowania komponentu regionalnego (instruktaż przeprowadzony
dla administratorów – max. 6 osób)

1 dzień – instruktaż z administrowania komponentu lokalnego osobny dla każdego
z Podmiotów (po 2 osoby z każdego Podmiotu)
Strona 149 z 161

1 dzień – instruktaż z przekazywanych przez Wykonawcę procedur utrzymaniowych dla
komponentu regionalnego (max. 4 osób) oraz dla komponentu lokalnego (po 2 osoby
z każdego Podmiotu)
Terminy instruktaży w zakresie komponentów lokalnych zostaną uzgodnione z Podmiotami oraz
wprowadzone do harmonogramu Projektu.
Terminy instruktaży w zakresie komponentu regionalnego uzgodnione zostaną z przedstawicielami
UMWM oraz przedstawicielami Podmiotu, który pełnić będzie rolę Podmiotu Wiodącego
odpowiedzialnego za administrację oraz utrzymanie komponentu regionalnego. Terminy instruktaży
muszą być wprowadzone do harmonogramu Projektu.
Warunkiem rozpoczęcia instruktaży stanowiskowych jest akceptacja przez Zamawiającego zakresu
instruktaży oraz materiałów dydaktycznych wspierających instruktaż. Zamawiający dopuszcza
materiały e-learning, które udostępnione będą na portalu WWW Zamawiającego.
1. Zamawiający dokona akceptacji zakresu instruktaży i materiałów dydaktycznych w terminie 5
2.
3.
4.
5.
dni roboczych lub zgłosi pisemnie uwagi w tym terminie (uwagi będą konkretne w jasny
sposób informujące jakie modyfikacje przedstawionego materiału powinien wprowadzić
Wykonawca, aby Zamawiający dokonał jego akceptacji).
Jeżeli Zamawiający nie wniesie uwag w terminie 5 dni roboczych oznacza to, że zaakceptował
przedstawiony do akceptacji materiał.
Wykonawca w terminie 5 dni roboczych wprowadzi modyfikacje wynikające z przedstawionych
uwag lub wyjaśni z jakiego powodu odrzucił uwagi.
Zamawiający w terminie 2 dni roboczych zweryfikuje poprawiony materiał i dokona akceptacji.
Jeżeli Zamawiający nie zgłosi zastrzeżeń co do powodów ewentualnego odrzucenia uwag w
przeciągu 2 dni roboczych oznacza to, że zaakceptował przedstawiony do akceptacji materiał.
W przypadku sporu dotyczącego ewentualnych odrzuconych uwag kierownictwo projektu
przygotuje rekomendację dla Komitetu sterującego, który podejmie ostateczną decyzję
dotyczącą kwestii spornych.
9.2.5.Odbiór szkoleń
Odbiory produktów szkoleniowych (w tym instruktaży szkoleniowych) wykonanych przez Wykonawcę
w ramach realizacji zamówienia będą odbywały się zgodnie z przedstawioną poniżej procedurą.
1. Po przeprowadzeniu szkoleń oraz instruktaży stanowiskowych będących elementem
przedmiotu
zamówienia
Wykonawca
przekazuje
Zamawiającemu
„Raport
z przeprowadzonych szkoleń”, zwany w dalszej części niniejszego rozdziału „Raportem”.
Odbiór szkoleń oraz instruktaży stanowiskowych zostanie dokonany przez Zamawiającego
poprzez akceptację Raportu.
2. Raport w przypadku szkoleń musi zawierać następujące elementy:
a. lista przeprowadzonych szkoleń (nazwa, czas i miejsce szkolenia),
b. liczba osób przeszkolonych na każdym szkoleniu,
c. nazwę osoby szkolącej,
d. czas trwania szkolenia,
e. zakres szkolenia, z załączonymi materiałami,
f. wyniki „Ankiety oceny szkolenia”,
g. oceny z egzaminu weryfikującego przyswojenie wiedzy otrzymane przez
poszczególne osoby szkolone,
h. załącznikami do raportu będą kopie list obecności na szkoleniach zawierające
dane o uczestnikach szkolenia: imię, nazwisko, nazwa komórki organizacyjnej,
telefon, adres poczty elektronicznej, dane trenera (imię, nazwisko, adres poczty
elektronicznej), wypełnione karty (formularze) egzaminacyjne osób szkolonych
oraz ankiet ewaluacyjnych.
3. Raport w przypadku instruktaży stanowiskowych musi zawierać następujące elementy:
a. lista przeprowadzonych instruktaży (nazwa, czas i miejsce szkolenia),
b. liczba osób przeszkolonych w ramach instruktażu,
Strona 150 z 161
nazwę osoby szkolącej,
czas trwania szkolenia,
zakres szkolenia, z załączonymi materiałami,
załącznikami do raportu będą kopie list obecności w ramach instruktaży
szkoleniowych zawierające dane o uczestnikach szkolenia: imię, nazwisko,
nazwa komórki organizacyjnej, telefon, adres poczty elektronicznej, dane
trenera (imię, nazwisko, adres poczty elektronicznej.
4. Kryteria akceptacji produktów szkoleniowych są następujące:
a. Zawartość Raportu zgodna ze stanem faktycznym;
b. Liczba odbytych godzin szkoleń oraz instruktaży stanowiskowych zgodna
z przedmiotem zamówienia;
c. W przypadku szkoleń pozytywna średnia ocena każdego ze szkoleń,
potwierdzona wypełnionymi i podpisanymi przez wszystkich uczestników
„Ankietami oceny szkolenia”;
d. Lista osób biorących udział w szkoleniu lub instruktaży stanowiskowym
potwierdzona podpisami uczestników.
e. W przypadku szkoleń – w ramach każdego ze szkoleń, co najmniej 80%
szkolonych otrzymało ocenę pozytywną ze sprawdzianu wiedzy.
5. Zamawiający w ciągu do 10 dni roboczych, począwszy od dnia następnego po dniu
otrzymania Raportu od Wykonawcy, przedstawia decyzję o odbiorze Raportu. Możliwe są
następujące decyzje:
a. akceptacja – produkt szkoleniowy zostaje uznany za odebrany;
b. odrzucenie – produkt szkoleniowy podlega ponownie procedurze odbioru po
usunięciu uchybień w przeprowadzeniu szkoleń lub wprowadzeniu w Raporcie
wskazanych poprawek.
6. W przypadku określonym w punkcie 5.b razem z decyzją Zamawiającego przedstawiana jest
lista elementów Raportu, które muszą zostać skorygowane.
7. W przypadku określonym w punkcie 6, w przypadku uchybień w przeprowadzeniu szkoleń
Wykonawca może zaproponować rozwiązanie, które nie wymaga ponownego
przeprowadzania szkolenia. Jeżeli Zamawiający uzna jednak, iż przeprowadzone szkolenia
w sposób istotny odbiegały od ustalonego zakresu merytorycznego lub posiadały inną
istotną wadę wskazaną przez Zamawiającego, Zamawiający może żądać ponownej
realizacji szkolenia.
8. W przypadku określonym w punkcie 5.b Wykonawca dokonuje niezbędnych poprawek
w terminie uzgodnionym z Zamawiającym, jednak nie dłuższym niż 10 dni roboczych od
otrzymania raportu, po czym przedstawia Zamawiającemu do odbioru nową wersję Raportu.
Kolejne wersje muszą być przedstawiane w sposób pozwalający na łatwe określenie miejsc,
w których wykonane zostały zmiany.
9. W przypadku kolejnych wersji Raportu uwagi Zamawiającego odnoszą się jedynie do
elementów Raportu, które uległy zmianie w stosunku do poprzedniej wersji.
10. Ostateczny odbiór produktu odbywa się na podstawie protokołu odbioru.
c.
d.
e.
f.
9.3. Odbiór
Wykonawca musi przeprowadzić testy zgodnie z opracowanym przez niego i zatwierdzonym przez
Zamawiającego Planem testów wraz ze scenariuszami testowymi.
Zakres testów w ramach Systemu MSIM obejmuje co najmniej:
 Testy funkcjonalne (IKP, portal e-Zdrowie, e-Rejestracja, EDM)
 Testy integracyjne (z systemami dziedzinowymi w przypadku warstw lokalnych oraz
z warstwami lokalnymi w przypadku warstwy regionalnej, z systemami do podpisywania
dokumentacji podpisem elektronicznym, P1 w zakresie IKP, e-rejestracji)
 Testy bezpieczeństwa (również VPN, SSL, uwierzytelnianie, podpisywanie)
Strona 151 z 161


Testy wydajnościowe
Testy ergonomii
Wykonawca w terminie uzgodnionym z Zamawiającym dla poszczególnych testów funkcjonalnych
przekaże do akceptacji Zamawiającemu plan i zakres testów.
a)
b)
c)
d)
e)
f)

proponowany czas trwania testu wraz z iteracjami,

podstawowe informacje na temat przedmiotu testów,

nazwę Komponentu, nazwę Modułu Funkcjonalnego, nazwę Funkcjonalności,

scenariusz testów danej Funkcjonalności, wraz z informacją o konfiguracji (jeżeli jest
wymagana dodatkowa), kryteria akceptacyjne.
Zamawiający wniesie ewentualne uwagi do przedstawionego Planu testu do 10 dni
roboczych.
Wykonawca uwzględni uwagi Zamawiającego oraz przekaże poprawiony Plan testów5 dni
roboczych.
Brak akceptacji Planu testu uniemożliwia rozpoczęcie testów funkcjonalnych danego
Komponentu.
Plan testów musi obejmować testowanie wszystkich wymagań Systemu, w tym co najmniej
następujących funkcji Systemu:
a. Usługa e-Rejestracja
b. Repozytorium EDM
c. Rejestr EDM
Zamawiający może zrezygnować z testowania wybranych wymagań Systemu
Dodatkowo przed przystąpieniem do testów funkcjonalnych Wykonawca jest zobowiązany przedstawić
Dokumentację użytkową zgodną z testowaną w danej iteracji wersją Systemu MSIM.
Przeprowadzenie testów musi być zakończone opracowaniem Raportu z testów. Raport z testów musi
być przyjęty przez Zamawiającego bez zastrzeżeń.
Wykonawca w terminie uzgodnionym z Zamawiającym dla testów integracyjnych przekaże do
akceptacji Zamawiającemu plan i zakres testów.
g)
h)
i)
j)

proponowany czas trwania testu wraz z iteracjami,

podstawowe informacje na temat przedmiotu testów,

adresację wymagań integracyjnych w przyporządkowaniu do przypadków
testowych/scenariuszy testowych

scenariusz testów integracyjnych
Zamawiający wniesie ewentualne uwagi do przedstawionego Planu testu do 10 dni
roboczych.
Wykonawca uwzględni uwagi Zamawiającego oraz przekaże poprawiony Plan testów5 dni
roboczych.
Brak akceptacji Planu testu uniemożliwia rozpoczęcie testów integracyjnych.
Dodatkowo przed przystąpieniem do testów integracyjnych muszą być zakończone wynikami
pozytywnymi testy funkcjonalne. W przypadku konieczności powtórzenia testów integracyjnych
Zamawiający wskaże scenariusze testowe, które będą realizowane w danej iteracji testów.
Przeprowadzenie testów musi być zakończone opracowaniem Raportu z testów. Raport z testów musi
być przyjęty przez Zamawiającego bez zastrzeżeń.
Odbiór Komponentu
Odbiór Komponentu musi odbywać się w terminach wskazanych w Harmonogramie projektu.
W ramach odbioru Komponentów musi nastąpić weryfikacja ilościowa oraz jakościowa tzn. czy
Strona 152 z 161
wszystkie produkty spełniają wymagania i kryteria jakościowe dla produktów. Odbiór Komponentu
musi być potwierdzony Protokołem Odbioru Komponentu podpisanym bez zastrzeżeń przez
Zamawiającego oraz Wykonawcę (Protokół Odbioru Komponentu musi być sporządzony w 3
egzemplarzach po 2 sztuki dla Zamawiającego i jednej dla Wykonawcy).
Dokonanie odbioru Komponentu, nie pozbawia Zamawiającego roszczenia wobec Wykonawcy
o usunięcie wad, które ujawnią się w odebranych już Komponentach, w trakcie realizacji kolejnych
etapów przedmiotu Umowy, a także w okresie gwarancji.
Odbiór Etapu
Odbiór Etapu musi odbywać się w terminach wskazanych w Harmonogramie projektu. W ramach
Odbioru Etapu weryfikowana jest kompletność odbioru poszczególnych Komponentów wchodzących
w skład danego etapu. Wykonawca przystępując do odbioru Etapu musi przedstawić:
 Komplet dokumentacji wymaganej w danym Etapie
 Raporty z testów (o ile odbywały się w danym Etapie)
 Protokoły odbioru Komponentów
 Gwarancje na Komponenty odbierane w danym Etapie
 Licencje na Komponenty odbierane w danym Etapie
Odbiór Etapu potwierdzany jest podpisanym bez zastrzeżeń Protokołem Odbioru Etapu przez
Zamawiającego oraz Wykonawcę (Protokół Odbioru Etapu musi być sporządzony w 3 egzemplarzach
po 2 sztuki dla Zamawiającego i jednej dla Wykonawcy).
Dokonanie Odbioru Etapu, nie pozbawia Zamawiającego roszczenia wobec Wykonawcy o usunięcie
wad, które ujawnią się w odebranych już Produktach i Komponentach wykonanych i dostarczonych
w ramach etapu, w trakcie realizacji kolejnych etapów przedmiotu Umowy, a także w okresie
gwarancji.
Wady Produktów i Komponentów wykonanych i dostarczonych w ramach konkretnego etapu,
zdiagnozowane w etapach późniejszych, zostaną niezwłocznie (jednak nie później niż w terminie
wskazanym przez Zamawiającego) usunięte przez Wykonawcę bez odrębnego wynagrodzenia.
Zamawiający nie przewiduje, w związku z opisanymi w zdaniach poprzednich okolicznościami, zmiany
terminów wykonywania przedmiotu Umowy, w tym kolejnych etapów.
9.4. Eksploatacja
Poniżej przedstawiono wymagania
obowiązywania okresu gwarancji.
dla
eksploatacji
dostarczonego
rozwiązania
w
trakcie
ID wymagania
Opis wymagania
ESK.1
Wykonawca musi informować Zamawiającego pisemnie o wszystkich wymaganych
aktualizacjach wszystkich systemów i komponentów dostarczonych w niniejszym
zamówieniu.
ESK.2
ESK.3
Wykonawca musi informować Zamawiającego o:
 Terminie wygaśnięcia certyfikatów z wyprzedzeniem minimum 10 dni
roboczych
 Pojawiających się aktualizacjach oprogramowania (systemowego,
serwerowego)
 Planowanych przeglądach serwisowych
Wykonawca zobowiązany jest zapewnić dostęp Zamawiającemu do aktualizacji
oprogramowania Dedykowanego oraz dostarczyć opis procedur pozyskiwania
informacji o dostępności aktualizacji oprogramowania standardowego (w zakresie
poprawek) i dedykowanego (w zakresie poprawek oraz nowych wersji) oraz
sposobu instalacji aktualizacji. Wykonawca będzie aktualizował oprogramowanie
Dedykowane wchodzące w zakres projektu MSIM do najnowszej obowiązującej
wersji i standardowe w zakresie poprawek wymaganych do właściwego
funkcjonowania MSIM. Aktualizacja oprogramowania standardowego do nowszej
Strona 153 z 161
ID wymagania
Opis wymagania
ESK.4
wersji (nowa wersja produktu) jest wymagane wyłącznie o ile jest to niezbędne do
właściwego funkcjonowania MSIM.
Wykonawca będzie na bieżąco przekazywał wszelkie hasła do MSIM.
Wykonawca musi zapewnić zdalny dostęp do środowiska. Zdalny dostęp musi być
realizowany z wykorzystaniem bezpiecznego kanału transmisji opartego o VPN.
ESK.5
Wykonawca zapewni konsultacje na potrzeby Zamawiającego w ramach
eksploatacji zgodnie z wytycznymi Umowy.
ESK.6
ESK.7
ESK.8
Wykonawca będzie aktualizował kody źródłowe systemu MSIM w terminie do 10
dniu od daty przyjęcia przez Zamawiającego przetestowanej wersji produkcyjnej
oprogramowania, potwierdzonej protokołem odbioru (każda z wersji
oprogramowania będzie zawierała kolejny nr porządkowy).
Wykonawca będzie dostosowywał system MSIM do przepisów prawa regulujących
ten obszar, kolejnych wdrażanych w ramach Projektu P1 funkcji IKP realizowanych
przez CSIOZ oraz regulacji obowiązujących w Urzędzie Marszałkowskim
Województwa Małopolskiego, gdzie Wykonawca wykona modyfikacje / aktualizacje
systemu, logo, kontentów, banerów, stopek, nazw, które będą niezbędne w celu
jego dostosowania do wymagań określonych w przepisach prawa regulujących ten
obszar. Zamawiający opracuje i przekaże Wykonawcy wzory logo, kontentów,
banerów, stopek i nazw, oraz wskaże miejsca, w których należy dokonać
powyższych modyfikacji. Wzory elementów graficznych będą przekazywane jako
pliki w formacie zapewniającym poprawne wyświetlenie przez przeglądarkę
internetową (tj. jako pliki graficzne GIF, JPG lub PNG o rozdzielczości wskazanej
przez Wykonawcę) w terminie do 20 dni.
Wykonawca będzie dostosowywał bezpłatnie system MSIM do ewentualnych zmian
wprowadzanych w interfejsach do systemów HIS o ile zmiany te wynikają ze zmian
w MSIM leżących po stronie Wykonawcy MSIM (np. sposobu świadczenia usług
gwarancyjnych).
Strona 154 z 161
10.
Gwarancja oraz rękojmia
10.1. Wymagania gwarancyjne
Na potrzeby niniejszej SIWZ wprowadza się następujące definicje:







Dokumentacja wszelka dokumentacja dostarczana przez Wykonawcę w ramach realizacji
Umowy, sporządzona przez Wykonawcę w zakresie i formie określonej w wymaganiach.
Dostawa
Sprzedaż i dostarczenie przez Wykonawcę Oprogramowania wraz z
odpowiednią Dokumentacją.
Oprogramowanie aplikacyjne (Dedykowane)
–oprogramowanie i skrypty wraz z
kompletnymi kodami źródłowymi, wytworzone i dostarczone przez Wykonawcę w ramach
realizacji Umowy, wraz z Dokumentacją i Modyfikacjami.
Oprogramowanie narzędziowe (Standardowe) –oprogramowanie powszechnie dostępne
oraz jego dokumentacja, będące przedmiotem Dostaw w ramach realizacji Umowy, na które
producent udziela Zamawiającemu licencji na warunkach i zasadach określonych w Umowie
oraz umowach licencyjnych Oprogramowania, dostarczane przez Wykonawcę wraz z licencją
producenta oraz Dokumentacją i Modyfikacjami.
Oprogramowanie -Oprogramowanie aplikacyjne oraz Oprogramowanie narzędziowe.
Modyfikacje wyższe wersje Oprogramowania (update/upgrade), patche i programy korekcji
błędów Oprogramowania, udostępnione przez Wykonawcę na rzecz Zamawiającego, wraz z
odnoszącą się do tego Dokumentacją
System lub System MSIM–Oprogramowanie realizujące wymagania funkcjonalne opisane w
SIWZ skonfigurowane i zainstalowane na dostarczonym, zainstalowanym i skonfigurowanym
sprzęcie przewidzianym w SIWZ
Wykonawca udziela Zamawiającemu gwarancji jakości i rękojmi za wady na okres wskazany w ofercie
lecz nie mniej niż 5 lat, liczony od daty odbioru wszystkich produktów projektu (tj. liczona będzie od
daty podpisania protokołu odbioru końcowego).
W ramach gwarancji Wykonawca będzie świadczył usługi gwarancji w zakresie oprogramowania
zgodnie z następującymi wytycznymi:






Dopuszcza się zmianę kwalifikacji zgłoszenia wady, wyłącznie po uprzedniej zgodzie
Zamawiającego. Do czasu potwierdzenia zmiany kwalifikacji, uznaje się za obowiązującą
kwalifikację pierwotną
Wykonawca zobowiązany jest do świadczenia gwarancji bezpośrednio w lokalizacjach
wskazanych przez Zamawiającego na terenie województwa małopolskiego
Usunięcie wady nastąpi poprzez przekazanie poprawki lub nowej wersji. Każda nowa
poprawka lub nowa wersja musi posiadać unikalny numer. Zasady wersjonowania poprawek
i nowych wersji zostaną przekazane przez Wykonawcę w terminie 15 dni roboczych od dnia
podpisania Umowy
Wykonawca zobowiązany jest do przekazywania Zamawiającemu informacji o nowych
poprawkach i nowych wersjach oprogramowania standardowego oraz Aplikacyjnego drogą
elektroniczną na wskazany adres e-mail Zamawiającego
Wykonawca zobowiązany jest do udostępniania nowych poprawek i nowych wersji
Oprogramowania Aplikacyjnego poprzez ustaloną witrynę internetową nieodpłatnie
Wykonawca zobowiązany jest do wysłania do Zamawiającego nośnika DVD/BLUERAY
zawierającego nową poprawkę lub nową wersję Oprogramowania Aplikacyjnego na każde
pisemne żądanie wniesione przez Zamawiającego
Strona 155 z 161




Wraz z nową wersją lub nową poprawką Oprogramowania Aplikacyjnego, Wykonawca
zobowiązany jest do przekazania nowej wersji dokumentacji wraz z procedurą instalacji oraz
informacją o parametryzacji i konfiguracji.
Wykonawca w okresie trwania gwarancji, do 5 dnia każdego miesiąca, przedstawi
Zamawiającemu raport zawierający co najmniej: numer zgłoszenia, kwalifikację zgłoszenia,
godzinę i datę zgłoszenia, temat zgłoszenia, status zgłoszenia, godzinę i datę dostarczenia
rozwiązania zastępczego (dla awarii), godzinę i datę usunięcia wady, godzinę i datę
wykonania reakcji Wykonawcy, czas naprawy, czas opóźnienia w postaci godzin lub dni (jeżeli
jest) dla rozwiązania zastępczego lub usunięcia wady za cały poprzedni miesiąc.
Wykonanie aktualizacji Oprogramowania Aplikacyjnego działającego na środowisku
produkcyjnym
odbywa
się
w terminach zaproponowanych przez Wykonawcę i zaaprobowanych przez Zamawiającego
Każda dostarczana aktualizacja Oprogramowania Aplikacyjnego musi być udokumentowana
testami na środowisku testowym Zamawiającego, które zakończą się wynikiem pozytywnym
Zamawiający zgłaszać będzie wady poprzez zgłoszenie faksem pod podany w umowie numer lub
poprzez system zgłoszeń udostępniony przez Wykonawcę. Czas wprowadzenia zgłoszenia jest
równoznaczny z rozpoczęciem czasów reakcji o których mowa poniżej. Czasy podane w poniższych
tabelach są liczone bez przerw.
Usuwanie wad w oprogramowaniu standardowym (w którego skład wchodzi: oprogramowanie
systemów operacyjnych, oprogramowanie baz danych, oprogramowanie serwerów aplikacyjnych oraz
oprogramowanie szyny danych )realizowane będzie w następujących terminach:
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
CZAS REAKCJI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS NAPRAWY

niezwłocznie,
nie później niż 4
godzin od czasu
przyjęcia
zgłoszenia
AWARIA
niezwłocznie, nie
później niż 8
godziny
od czasu przyjęcia
zgłoszenia
24/7/365

BŁĄD
niezwłocznie nie
później niż 1 dni
robocze od dnia
przyjęcia
zgłoszenia

w przypadku,
gdy producent
zapewnia
procedurę
naprawy - nie
dotyczy,
w przypadku
braku
procedury
naprawy przez
producenta
niezwłocznie
Strona 156 z 161
w przypadku, gdy
producent zapewnia
procedurę naprawy niezwłocznie, nie później
niż 24 godziny od czasu
przyjęcia zgłoszenia

w przypadku braku
procedury naprawy przez
producenta w chwili
przyjęcia zgłoszenia niezwłocznie, nie później
niż 24 godziny od dnia
udostępnienia przez
producenta procedury
naprawy.

w przypadku, gdy
producent zapewnia
procedurę naprawy niezwłocznie nie później
niż 4 dni roboczych od
dnia przyjęcia zgłoszenia,

w przypadku braku
producenta w chwili
przyjęcia zgłoszenia niezwłocznie nie później
nie później niż
4 dni roboczych
od dnia
przyjęcia
zgłoszenia

niezwłocznie nie
roboczych od
dnia przyjęcia
zgłoszenia
USTERKA

w przypadku,
gdy producent
zapewnia
procedurę
naprawy - nie
dotyczy,
w przypadku
braku
procedury
naprawy przez
producenta
niezwłocznie
nie później niż
14 dni
roboczych od
dnia przyjęcia
zgłoszenia
dnia udostępnienia przez
naprawy.

w przypadku, gdy
producent zapewnia
procedurę naprawy niezwłocznie nie później
dnia przyjęcia zgłoszenia,

w przypadku braku
producenta w chwili
przyjęcia zgłoszenia niezwłocznie nie później
dnia udostępnienia przez
naprawy.
Przez udostępnienie przez producenta procedury naprawy rozumiane jest:


W przypadku oprogramowania komercyjnego pojawienie się na oficjalnych stronach
producenta odpowiedniej łatki zapewniającej naprawę wady, względnie innej informacji (np.
zmiany ustawień konfiguracyjnych),
W przypadku oprogramowania typu open source pojawienie się na oficjalnych stronach
projektu (w tym oficjalnych forach) odpowiedniej łatki zapewniającej naprawę wady, względnie
innej informacji (np. zmiany ustawień konfiguracyjnych).
Usuwanie wad w Oprogramowaniu Aplikacyjnym realizowane będzie w następujących terminach:
KWALIFIKACJA
ZGŁOSZENIA
WADY
AWARIA
BŁĄD
OKRES
DOSTĘPNOŚCI
WYKONAWCY
W dni robocze
00
pomiędzy 7 a
00
20 . Zgłoszenie
00
przesłane po 20 ,
traktowane jest
jak zgłoszenie
przyjęte w
następnym dniu
00
roboczym o 7
USTERKA
CZAS REAKCJI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
niezwłocznie, nie
później niż 4 godzin
od czasu przyjęcia
zgłoszenia
niezwłocznie, nie
później niż 8
godziny
od czasu
przyjęcia
zgłoszenia
niezwłocznie, nie później
niż 48 godziny
od czasu przyjęcia
zgłoszenia
niezwłocznie nie
robocze od dnia
nie dotyczy
niezwłocznie nie później
dnia przyjęcia zgłoszenia
niezwłocznie nie
roboczych od dnia
nie dotyczy
niezwłocznie nie później
dnia przyjęcia zgłoszenia
Definicje klasyfikacji zgłoszenia wad:
1)
Awaria – należy przez to rozumieć:
Strona 157 z 161
CZAS NAPRAWY
Wadę Oprogramowania aplikacyjnego lub narzędziowego powodującą funkcjonowanie
Oprogramowania niezgodnie z opisem SIWZ oraz Dokumentacji, która uniemożliwia
pracę Systemu, wprowadza niespójność w bazie danych lub zaburzenia w integralności
danych. Sytuacja, w której System w ogóle nie funkcjonuje lub nie jest możliwe
realizowanie istotnych funkcjonalności Systemu (tj. funkcji przewidzianej w dokumentacji
systemu, związanej bezpośrednio z realizacją procesów opisanych w rozdziale 5. – model
dynamiczny), a w szczególności:
 nie działa którakolwiek z usług (wyspecyfikowanych w OPZ),
 nie działa portal informacyjny e-zdrowie,
 nie działa szyna danych,
 nie ma możliwości prowadzenia usługi e-rejestracji z wykorzystaniem
Oprogramowania aplikacyjnego u Partnerów Projektu,
 nie ma możliwości prowadzenia usług w obszarach integrowanych w ramach projektu
systemów,
 nie ma możliwości poprawnego generowania istotnych raportów, wyciągów
z Oprogramowania aplikacyjnego,
 nie ma możliwości wytwarzania, gromadzenia i przesyłania EDM oraz użycia usług
towarzyszących pozwalające na integracje z węzłem regionalnym,
 nie ma możliwości wymiany dokumentacji pomiędzy komponentem regionalnym
a którymkolwiek z Partnerów projektu lub Podmiotem leczniczym, pomiędzy nimi lub
pomiędzy platformą P1 – z przyczyn leżących po stronie oprogramowania lub sprzętu
dostarczonego przez Wykonawcę, po dniu odbioru Końcowego Projektu.
 nie ma możliwości poprawnego użycia wykorzystywanych w ramach i z poziomu
systemu MSIM funkcjonalności Centrum Autoryzacji podpisu elektronicznego
w Małopolsce – z przyczyn leżących po stronie oprogramowania lub sprzętu
dostarczonego przez Wykonawcę, po dniu odbioru Końcowego Projektu,
 nie ma możliwości wyszukiwania dokumentacji medycznej pacjenta,
 nie ma możliwości wymiany oraz udostępniania dokumentacji medycznej pomiędzy
jednostkami medycznymi,
 nie ma możliwości udostępnianie dokumentacji medycznej pacjentowi (w tym wyników
badań),
 nie działa którekolwiek ze środowisk: wirtualizacyjne, bazodanowe, aplikacyjne,
testowe, backupu, integracyjne oraz zabezpieczające,
 nie działają usługi synchronizacyjne.
b)
Wadę urządzenia w obszarze Infrastruktury sprzętowej (wyspecyfikowanego w OPZ),
oznaczającą brak działania lub niepoprawne działanie urządzenia lub jego części w tym
sterowników, uniemożliwiające jego użytkowanie.
c)
Wadę urządzenia lub elementu w obszarze Infrastruktury sieciowej(wyspecyfikowanego
w OPZ), oznaczające brak działania lub niepoprawne działanie urządzenia lub jego części
w tym sterowników, uniemożliwiające jego użytkowanie.
Błąd–– należy przez to rozumieć Wadę Oprogramowania aplikacyjnego lub narzędziowego,
oznaczającą jego funkcjonowanie niezgodne z opisem w Dokumentacji (OPZ) oraz SIWZ,
powodujące błędne zapisy w bazie danych lub uniemożliwiające działanie mniej istotnej
funkcjonalności w Systemie (tj. funkcji przewidzianej w dokumentacji systemu, jednak nie
związanej bezpośrednio z realizacją procesów opisanych w rozdziale 5. – model dynamiczny).
Usterka – należy przez to rozumieć Wadę Oprogramowania aplikacyjnego lub narzędziowego,
oznaczającą jego funkcjonowanie niezgodne z opisem Dokumentacji (OPZ) oraz SIWZ,
utrudniającą pracę Użytkownikowi wewnętrznemu w ten sposób, że aby osiągnąć rezultat
funkcji opisanej w dokumentacji systemu musi on wykonywać nie przewidziane w niej
czynności.
a)
2)
3)
W ramach gwarancji Wykonawca będzie świadczył usługi gwarancji w zakresie dostarczanej
infrastruktury zgodnie z następującymi wytycznymi:
Usuwanie wad urządzeń w obszarze Infrastruktury informatycznej w przypadku stwierdzenia przez
Zamawiającego awarii w jego działaniu realizowane będzie na następujących warunkach:
OKRES
DOSTĘPNOŚCI
CZAS REAKCJI WYKONAWCY
Strona 158 z 161
CZAS NAPRAWY
WYKONAWCY
Infrastruktura
sprzętowa
24/7/365
Niezwłocznie, nie później niż 4 godzin
od godziny przyjęcia zgłoszenia Wady
naprawa w miejscu instalacji
Niezwłocznie nie później
niż 48 godzin od czasu
W przypadku konieczności zabrania urządzenia przez Wykonawcę do naprawy poza miejsce instalacji
urządzenia lub wymiany urządzenia na inne wolne od wad, dyski twarde lub inne pamięci masowe
pozostają w miejscu instalacji urządzenia.
W przypadku niemożliwości usunięcia awarii urządzenia zostanie ono wymienione na nowe co
najmniej o równoważnych lub wyższych parametrach. Uszkodzone dyski twarde lub inne pamięci
masowe pozostają u Zamawiającego.
W przypadku, gdy awaria urządzenia wymaga odtworzenia, instalacji, konfiguracji oprogramowania
Wykonawca wykona wszystkie czynności celem przywrócenia stanu aplikacji sprzed wystąpienia
awarii.
10.2. Szczegółowe zasady zgłoszeń gwarancyjnych
Wykonawca, w okresie obowiązywania gwarancji jest zobowiązany do zapewnienia funkcjonowania
kanałów zgłoszeń gwarancyjnych zgodnie z modelem ITIL w wersji 3 i musi być podzielone na 3 linie..
W dalszej części rozdziału funkcjonowanie kanałów zgłoszeń gwarancyjnych oraz komunikacja z
wykorzystaniem tych kanałów będzie nazywana łącznie wsparciem gwarancyjnym.
Poniżej przedstawiono wymagania dla sposobu funkcjonowania kanałów I, II i III linii wsparcia
gwarancyjnego, która musi być świadczona przez Wykonawcę w okresie trwania gwarancji dla
poszczególnych systemów oraz aplikacji.
ID wymagania
WSP.1
WSP.2
WSP.3
Opis wymagania
Wykonawca zobowiązany jest zapewnić wsparcie gwarancyjne, przez okres
wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego, dla
wszystkich dostarczanych komponentów, elementów i usług systemu MSIM.
Wsparcie gwarancyjne musi być dostępne w języku polskim poprzez konsultacje na
miejscu (w lokalizacji wskazanej przez Zamawiającego na terenie Krakowa), e-mail
oraz połączenia telefoniczne wg taryfy lokalnej.
W ramach wsparcia gwarancyjnego Wykonawca będzie zobowiązany do:
 świadczenia merytorycznego wsparcia podczas instalacji nowych wersji
oprogramowania, konfiguracji, wprowadzania zmian,
 uczestniczenia w procesie lokalizowania błędów w działaniu
poszczególnych aplikacji i systemów,
 usuwania wszystkich błędów,
 wsparcia merytorycznego podczas eksploatacji systemu
Wykonawca zapewni I, II oraz III linię wsparcia gwarancyjnego. Zgłoszenia, które
dotyczyć będą błędów bądź problemów z systemami/aplikacjami bądź sprzętem
dostarczonym w niniejszym zamówieniu będą kierowane do Wykonawcy poprzez
kanał zgłoszeń (narzędzie pozwalające na zgłaszanie oraz obsługę zgłoszeń).
Za przypisanie kategorii błędu odpowiada Wykonawca (w ramach I linii wsparcia
gwarancyjnego).
Wsparcie gwarancyjne musi obejmować co najmniej:
 wsparcia gwarancyjne dotyczące eksploatacji systemu przez użytkowników
końcowych,
 wsparcie gwarancyjne świadczone telefonicznie oraz pocztą elektroniczną
przez wykonawcę w zakresie administracji systemem,
 wymianę uszkodzonego sprzętu (producent wysyła sprzęt nie później niż
Strona 159 z 161
ID wymagania
Opis wymagania
następnego dnia roboczego),
dostęp do nowych wersji oprogramowania, w tym aktualizację baz, definicji
lub konfiguracji (np. bazy sygnatur ataków dla oprogramowania
antywirusowego),
 wsparcie gwarancyjne w zakresie dostępu do baz wiedzy, przewodników
konfiguracyjnych
i narzędzi diagnostycznych,
 wsparcie gwarancyjne w zakresie optymalizacji funkcjonowania systemu
(rozumianej jako zmniejszenie istniejących obciążeń oraz poprawą
wydajności i jakości pracy przez m.in. zmniejszenie liczby kliknięć oraz
czasu niezbędnego do wykonania danej czynności, zmiana sposobu
realizacji danej czynności).
Wykonawca dostarczy narzędzie pozwalające na zgłaszanie oraz obsługę zgłoszeń
gwarancyjnych (zapytań, błędów, itd.) od użytkowników. Narzędzie do obsługi
błędów musi zapewniać równoczesną pracę co najmniej 50 użytkowników
końcowych.
Wdrożone narzędzie musi mieć możliwość zwiększenia liczby użytkowników
równocześnie korzystających z narzędzia.
Narzędzie musi pozwalać co najmniej na:

WSP.4





WSP.5
WSP.6
WSP.7
Wprowadzenie zgłoszenia gwarancyjnego (błędu, pytania, itd.).
Przypisanie zgłoszenia (automatyczne bądź ręczne) do wybranej roli.
Pełną obsługę zgłoszenia (przekazywanie pomiędzy użytkownikami,
zamknięcie oraz ponowne otworzenie zgłoszenia, dodawanie komentarzy
do zgłoszenia, obserwowanie zgłoszenia, itd.).
Definiowanie workflow (procesu obsługi zgłoszenia wg ustalonych
parametrów np. typ zgłoszenia – błąd, wniosek o zmianę, wniosek
o modyfikację uprawnień; priorytet zgłoszenia, itd.).
Zarządzanie użytkownikami oraz uprawnieniami.
Narzędzie musi być dostępne poprzez interfejs www z portalu WWW e-Zdrowie.
Wykonawca odpowiada za opracowanie materiałów dla użytkowników tj. instrukcji
użytkowania narzędzia do obsługi błędów zawierającej zrzuty z ekranów wraz
z opisem czynności jakie użytkownik musi podjąć dla danej funkcji.
Wykonawca zapewni wsparcie gwarancyjne dla zespołu Zamawiającego w
zakresie eksploatacji systemu przez użytkowników. Zgłoszenia będą składane
przez Zamawiającego oficjalnym kanałem komunikacji (pismem bądź faksem).
Zlecenie będzie obejmować:
 zakres niezbędnego wsparcia gwarancyjnego,
 szacowany czas niezbędnego wsparcia gwarancyjnego
Wykonawca w trakcie obowiązywania okresu gwarancji musi zapewnić wsparcie
gwarancyjne dla administratorów warstwy regionalnej oraz lokalnej. Wsparcie to
powinno być świadczone:
 Za pośrednictwem kanału telefonicznego
 Za pośrednictwem systemu zgłoszeń
Wsparcie merytoryczne świadczone będzie w dni robocze w godz. 7 – 16.
Wykonawca musi dostarczyć wsparcie gwarancyjne sprzętu przez okres wskazany
w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego Systemu.
Strona 160 z 161
11.
Licencjonowanie
Przewiduje się dwa typy przekazania praw własności do dostarczonych produktów: przekazanie
licencji oraz przekazanie majątkowych praw autorskich.
Wykonawca musi dostarczyć licencje na okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od
daty odbioru końcowego lub bezterminowe dla:

Oprogramowania standardowego, w tym oprogramowania wskazanego w sekcji 7.5
Wykonawca musi dostarczyć majątkowe prawa autorskie umożliwiające dowolny rozwój Systemu
MSIM oraz przekazywanie praw do jego dysponowania dowolnym podmiotom trzecim (np. w celu
rozwoju) dla:




Aplikacji i komponentów wytwarzanych (ale nie konfigurowanych) na potrzeby Projektu
Konfiguracji oprogramowania standardowego
Dokumentacji
Materiałów szkoleniowych
Majątkowe prawa autorskie zostaną przekazane na następujących polach eksploatacji:
















użytkowania Systemu MSIM,
modyfikacja produktu,
konfiguracja produktu,
rozwój Systemu MSIM,
poprawy błędów,
testowania systemu pod kątem zagrożeń,
zmiany parametrów systemu,
integracji z innymi systemami,
przekazywanie praw do jego dysponowania dowolnym podmiotom trzecim,
wykorzystanie dowolnej liczby użytkowników,
wykorzystanie dowolnej liczby podmiotów,
wykorzystanie nie będzie ograniczone w czasie i zakresie,
podłączanie kolejnych podmiotów prowadzących działalność leczniczą z terenu Województwa
Małopolskiego,
wykorzystanie będzie nieodpłatne,
integracji innych jednostek medycznych,
korzystania z systemu przez inne jednostki medyczne.
Strona 161 z 161

Małopolski System Informacji Medycznej – projekt pilotażowy

Transkrypt

Podobne dokumenty

Część III

Broszura - Obróbka CNC

Zał. 1.2. do OPZ – Lista funkcji cz 2

6. Informacje z otwarcia ofert

Załącznik nr 4 - inf

Załącznik nr 10 do SIWZ Oświadczenie o części

Załącznik nr 2 FORMULARZ OFERTOWY Przedmiot zamówienia

Wykaz części zamówienia, których realizację Wykonawca zamierza

Wykaz osób, którymi dysponuje lub będzie dysponował Wykonawca