Contract

Załącznik nr 9

Dotyczy przetargu nieograniczonego na zamówienie pn.:Stworzenie oraz kompletne wdrożenie Małopolskiego Systemu Informacji Medycznej - projekt pilotażowy, w ramach Małopolskiego Regionalnego Programu Operacyjnego na lata 2007 – 2013 (399/ZP/2014).

Opis przedmiotu zamówienia (OPZ)

Małopolski System Informacji Medycznej – projekt pilotażowy

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łniać system MSIM 11

2.3. Koncepcja wykonania i dostawy, instalacji, konfiguracji, wdrożenia, uruchomienia oraz integracji systemu MSIM 15

2.4. Dyslokacja elementów systemu 18

2.5. Zasady budowy reguł interoperacyjności w systemie 19

2.6. Koncepcja synchronizacji czasu – normalizacji czasu 19

2.7. Koncepcja autentykacji i identyfikacji użytkowników 20

2.8. Koncepcja współpracy z Internetowym Kontem Pacjenta (IKP) 20

2.9. Koncepcja przesyłania dokumentacji o dużej pojemności 22

2.10. Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych jednostek 23

2.11. Schemat połączeń pomiędzy elementami systemu 23

2.12. Interfejsy komunikacyjne z innymi systemami informatycznymi 27

2.13. Koncepcja komunikacji pomiędzy jednostkami 28

2.14. Koncepcja przesyłu danych pomiędzy jednostkami 30

2.15. Integracja systemów oraz danych z innych systemów do wdrażanego systemu MSIM 31

2.16. Koncepcja wirtualizacji zasobów informatycznych 31

3. Analiza stanu aktualnego 31

3.1. Infrastruktura informatyczna 31

3.2. Infrastruktura sieciowa 39

3.3. Łącza internetowe 41

3.4. Procedury bezpieczeństwa 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 77

6.5. Wymagania skalowalności 78

6.6. Wymagania wolumenu przetwarzanych danych 78

6.7. Wymagania niezawodności 78

6.8. Wymagania bezpieczeństwa 79

6.9. Ochrona danych osobowych 80

6.10. Wymagania systemu zarządzania tożsamością 81

6.11. Procedury nadawania/zmiany/odbierania uprawnień 82

6.12. Repozytorium EDM 82

6.13. Usługa e-Rejestracja 84

6.14. Wymagania warstwy integracji 89

7. Infrastruktura 91

7.1. Infrastruktura serwerowa 98

7.2. Komunikacja 111

7.3. Bezpieczeństwo 119

7.4. Pozostałe elementy 127

7.5. Oprogramowanie systemowe 131

8. Platforma danych 137

8.1. Metadane dla źródeł danych 137

8.2. Model biznesowy platformy danych 138

9. Metodyka wdrożenia Systemu 139

9.1. Dokumentacja 139

9.2. Szkolenia 142

9.3. Odbiór 148

9.4. Eksploatacja 150

10. Gwarancja oraz wsparcie 152

10.1. Gwarancja 152

10.2. Wsparcie 155

11. Licencjonowanie 157

1.Wstęp

Przedmiotem zamówienia jest stworzenie oraz kompletne wdrożenie jednolitej zintegrowanej platformy wymiany danych Medycznych i udostępnienie elektronicznych usług medycznych w skali regionu.

Założeniem projektu MSIM (Małopolski System Informacji Medycznej) – projekt pilotażowy jest stworzenie regionalnego systemu informacji medycznej – narzędzia informatycznego pozwalającego na wymianę dokumentacji medycznej pomiędzy podmiotami leczniczymi w województwie małopolskim.

Projekt planowany jest do realizacji jako indywidualny projekt kluczowy Małopolskiego Regionalnego Programu Operacyjnego na lata 2007-2013 i umieszczony jest w Indykatywnym Wykazie Indywidualnych Projektów Kluczowych Małopolskiego Regionalnego Programu Operacyjnego na lata 2007-2013.

W projekcie bierze udział Urząd Marszałkowski oraz jako partnerzy 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. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.

Przedmiotem niniejszego zamówienia jest:

1. Dostawa dokumentacji,

2. Przygotowanie koncepcji wdrożenia,

3. Dostawa licencji,

4. Dostawa oprogramowania wytwarzanego na potrzeby Zamówienia,

5. Dostawa oprogramowania standardowego oraz systemowego,

6. Dostawa, instalacja, integracja i konfiguracja infrastruktury sprzętowej oraz programowej,

7. Szkolenia oraz instruktarze stanowiskowe,

8. Gwarancja.

Szczegółowe wymagania dla powyższych produktów zdefiniowane zostały w kolejnych rozdziałach.

2.Wymagania podstawowe do realizacji Systemu MSIM

2.1.Założenia projektowe

2.1.1.Warstwy MSIM

System MSIM ma zapewniać rozdzielność warstwy regionalnej i warstwy lokalnej. Planowane rozwiązanie nie pozwala na bezpośredni dostęp do systemów dziedzinowych Szpitali z poziomu warstwy regionalnej.

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.

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.

Rysunek 2. Metody integracji w MSIM.

Zamawiający jednocześnie nie określa sposobu wewnętrznej wymiany danych w ramach dostarczanych w ramach zamówienia modułów (tj. w przypadku, gdy oprogramowanie Wykonawcy będzie miało jakąś wewnętrzną strukturę – to nie określa sposobu wymiany danych w ramach oferowanego oprogramowania).

2.1.2. Wymiana EDM

W zakresie wymiany EDM rozwiązanie przewiduje podział funkcjonalny na warstwę lokalną i warstwę regionalną według poniższych wytycznych.

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:

• Podstawowa dokumentacja medyczna (m. in. dokumentacja zewnętrzna: karta informacyjna, karta porady specjalistycznej, karta informacyjna SOR).

• Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza objętość).

• Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość)

Wymagane rozwiązanie zapewni w przypadku konieczności zapoznania się z bardziej szczegółową dokumentacją pobranie jej w komplecie dla danego pobytu, przez co gwarantuje się analizę danych diagnostycznych i z procesu leczenia w kontekście całego pobytu. Eliminuje to zagrożenie opierania się podczas decyzji leczniczych na pobranym dokumencie (np. z danymi diagnostyki laboratoryjnej) bez kontekstu procesu leczenia wdrożonego podczas danego pobytu.

W ramach części regionalnej, zostanie zorganizowane pojedyncze źródło identyfikacji pacjentów, pojedynczy rejestr dokumentów (baza danych gdzie przechowywane będą metadane wszystkich dokumentów).

W warstwie regionalnej będzie realizowana większość usług (np. wyszukiwanie, przeglądanie, pobieranie, przekazywanie do innych podmiotów). Rozwiązanie takie minimalizuje warunki techniczne potrzebne w warstwie lokalnej do sprawnego funkcjonowania systemu–wszelkie zapytania od strony klientów obsługiwane są wyłącznie z wykorzystaniem warstwy regionalnej.

Przedmiotem zamówienia w ramach MSIM jest:

• warstwa regionalna (rejestr EDM),

• EDM w warstwie lokalnej,

• adapter komunikacyjny.

Pozostałe elementy wymiany EDM są realizowane w toku umów z dostawcami HIS.

2.1.3. E-Rejestracja

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.

Rysunek 4. Wymiana danych w ramach e-Rejestracji.

Użytkownik ma możliwość rejestracji na wskazany termin i anulowania wizyty. Z e-Rejestracji mogą korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi (pacjenci). W ramach usługi powinien funkcjonować system komunikatów (powiadomień dla użytkowników końcowych w formie np. wiadomości e-mail i SMS) dotyczących: potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno przez użytkownika jak i w lokalnym systemie medycznym HIS). W szczególności usługa obejmuje następujące funkcjonalności:

• Przegląd listy usług możliwych do realizacji w placówce Zamawiającego dla pacjenta.

• Przegląd listy usług możliwych do rezerwacji przez Internet.

• Możliwość rezerwacji terminu usługi do wybranej poradni lub wybranego lekarza.

• Określenie celu wizyty u lekarza, z podziałem na: przypadek nagły incydentalny, stan nagły przy chorobie przewlekłej, wizytę kontrolną, wizytę po kolejną receptę, wizytę po skierowanie na badanie specjalistyczne.

• Udostępnienie danych o zaplanowanych wizytach i usługach.

• Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana).

• Możliwość wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko pacjenta, numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla pacjenta.

• Dostęp do informacji o lokalizacji miejsca wykonania usługi.

• Możliwość odwołania rezerwacji.

• Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail).

Zamówieniem objęta jest:

• e-Rejestracja na poziomie regionalnym integrująca jednostki w ramach MSIM,

• dostarczenie, zainstalowanie i skonfigurowanie serwera e-mail na potrzeby powiadomień MSM.

Współpraca z dostawcami HIS i dostarczenie interfejsów jest poza zamówieniem (realizowana w toku odrębnych umów). Poza zamówieniem jest również dostarczenie bramki SMS.

Poza tą rejestracją mogą występować inne moduły e-Rejestracji na poziomie poszczególnych partnerów, jednak – o ile zostanie utrzymana decyzja o ich eksploatacji. Zamawiający nie wymaga przeprowadzania integracji pomiędzy e-Rejestracją na poziomie regionalnym, a ewentualnymi rejestracjami lokalnymi.

2.1.4. Podstawowe standardy wykonania MSIM

Głównym celem proponowanego rozwiązania jest usprawnienie zarządzania i podniesienie jakości procesów leczniczych w podmiotach leczniczych objętych systemem, poprzez rozbudowę
i rozszerzenie stanu istniejącego przedstawionego w analizie stanu obecnego. Rozbudowa ma na celu bezpieczne i zgodne z prawem wytwarzanie, przechowywanie, oraz przekazywanie dokumentów medycznych pomiędzy jednostkami oraz integrację z tworzoną na szczeblu krajowym Elektroniczną Platformą Gromadzenia Informacji O Zdarzeniach Medycznych (projekt P1).

W celu zapewnienia dalszej łatwej rozbudowy oraz integracji z nowymi systemami wymaga się, aby system w jak największym stopniu oparty był o obowiązujące w tej dziedzinie na świecie standardy
i dobre praktyki. Najszerzej przyjętym w chwili obecnej standardem dotyczącym przekazywania dokumentacji pomiędzy szpitalami jest profil XDS.b proponowany przez międzynarodową organizację IHE Wykonawca powinien dostarczać WebSerwis’y umożliwiające zewnętrzną wymianę danych zgodnie z profilem XDS.b, jakkolwiek nie jest wymagane, aby Wykonawca korzystał z tego standardu w komunikacji w ramach komunikacji pomiędzy dostarczanymi komponentami MSIM. Profil ten opisuje procesy i komunikaty jakie muszą zostać wymienione pomiędzy dwoma jednostkami, aby nastąpiło poprawne przekazanie dokumentu medycznego. Standard wspierany jest obecnie przez większość głównych dostawców oprogramowania medycznego na świecie.

Sam układ dokumentu medycznego powinien być zdefiniowany w języku XML, w oparciu
o najszerzej przyjęty na świecie format dokumentu opracowany przez organizację HL7 CDAR2 na 0-xxx xxxxxxxx xxxxxxxxxxxxxxxxxx (x xxxxxxxx, 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.

• 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
i udostępniania dokumentacji medycznej zamawianej przez pacjenta za pomocą IKP. Wymiana dokumentacji medycznej w ramach platformy integracyjnej będzie realizowana zgodne z przyjętymi standardowymi protokołami w ochronie zdrowia (HL7 CDA R2 na poziomie 3-cim interoperacyjności, DICOM, XML i PDF zgodne z Rozporządzeniem Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania) w zakresie przekazywanym do lokalnych EDM przez systemy HIS.

• Wdrożenie elektronicznych usług medycznych

Zakłada się uruchomienie elektronicznych usług dostępnych w warstwie regionalnej systemu MSIM:

1. Wyszukiwanie dokumentacji medycznej pacjenta:

Usługa dostępna dla personelu medycznego będzie umożliwiać wyszukanie dokumentacji pacjenta wg określonych kryteriów takich jak dane pacjenta, rodzaju usługi medycznej, data czy jednostka medyczna. Wynik wyszukiwania będzie miał postać listy z możliwością jej pogrupowanej wg określonych kryteriów takich jak jednostka medyczna, rodzaj usługi medycznej czy data wykonania usługi.

2. Wymiana oraz udostępnianie dokumentacji medycznej pomiędzy jednostkami medycznymi:

Usługa dostępna dla personelu medycznego będzie umożliwiać pobranie dokumentacji medycznej pacjenta zgromadzonej w jednostkach medycznych uczestniczących
w projekcie. Zakres wymienianych danych pomiędzy jednostkami może być różny
i zależy od specjalizacji danej jednostki, a także od zasobu dokumentacji gromadzonej
w jej systemach dziedzinowych. Dokumentacja będzie pobierana z listy uzyskanej
w procesie wyszukiwania.

W przypadku konieczności pobrania pełnej dokumentacji medycznej pacjenta
z konkretnego pobytu/wizyty wymaga się możliwość jej zamówienia/pobrania jedynie
w trzech wariantach możliwych do wybrania przez Użytkownika:

• Podstawowa dokumentacja medyczna (m. in. dokumentacja zewnętrzna: karta informacyjna, karta porady specjalistycznej, karta informacyjna SOR).

• Pełna dokumentacja medyczna z hospitalizacji/wizyty bez danych obrazowych (mniejsza objętość).

• Pełna dokumentacja medyczna z hospitalizacji/wizyty z danymi obrazowymi w jakości diagnostycznej (duża objętość)

3. Udostępnianie dokumentacji medycznej pacjentowi (w tym wyników badań):

Usługa będzie umożliwiać pobranie przez pacjenta dokumentacji medycznej zgromadzonej w jednostkach medycznych uczestniczących w projekcie. W ramach wdrożenia usługi zostanie wykonana integracja z Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (projekt P1)
w zakresie Internetowego Konta Pacjenta (IKP), funkcjonującego w ramach platformy P1, dzięki któremu pacjent będzie miał możliwość zamawiania dokumentacji medycznej. Wskazana przez pacjenta dokumentacja będzie udostępniana z poziomu systemu MSIM. Integracja z IKP będzie obejmować zestawienie szyfrowanego połączenia pozwalającego na udostępnianie/przesyłanie EDM, którą zamówił pacjent (w IKP pacjent powinien otrzymać informację o sposobie udostępnienia dokumentacji, np. link do udostępnionej dokumentacji znajdującej się w EDM w warstwie lokalnej MSIM).

W ramach usługi realizowany będzie scenariusz:

• pacjent przy użyciu IKP wyszukuje w wykazie interesującą go dokumentację medyczną,

• za pomocą usługi dostępnej w IKP pacjent zamawia interesująca go dokumentację medyczną,

• System MSIM obsługuje żądanie we właściwy sposób, umożliwiając przesył dokumentacji medycznej,

• pacjent pobiera zamówioną dokumentację medyczną.

4. Elektroniczna rejestracja pacjentów (e-Rejestracja)

Szczególną usługą realizowaną w ramach komponentu regionalnego jest usługa
e-Rejestracji. Usługa e-Rejestracji udostępnia funkcjonalność rezerwacji usług medycznych w jednostkach ochrony zdrowia zintegrowanych z MSIM. Użytkownik ma możliwość rejestracji na wskazany termin i anulowania wizyty. Z e-Rejestracji mogą korzystać wyłącznie zarejestrowani na poziomie regionalnym użytkownicy końcowi (pacjenci). W ramach usługi powinien funkcjonować system komunikatów (powiadomień dla użytkowników końcowych w formie np. wiadomości e-mail i SMS) dotyczących: potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno przez użytkownika jak i w lokalnym systemie medycznym HIS). W szczególności usługa obejmuje następujące funkcjonalności:

• Rejestrację terminu wizyty

• Anulowanie terminu wizyty

• Przeglądanie terminów (przyszłych aktywnych, przyszłych zarejestrowanych, przyszłych anulowanych i historycznych)

• Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail)

5. Portal Informacyjny e-Zdrowie.

Portal będzie miał postać aplikacji webowej prezentującej informację
o projekcie, świadczonych usługach, uczestniczących partnerach. Na portalu będą udostępniane:

• Informacje o jednostkach ochrony zdrowia, które są zintegrowane z MSIM
  w ramach projektu (w tym lista usług świadczony przez te podmioty),

• Wyszukiwarka usług medycznych (wg typu usługi oraz wg jednostki ochrony zdrowia),

• Dane kontaktowe do jednostek ochrony zdrowia (tel. do placówki, poszczególnych specjalistów, informacji, rejestracji

• Informacje nt. możliwości skorzystania z e-rejestracji (wraz z krótkim instruktażem jak z korzystać z rozwiązania na portalu oraz charakterystyka
  e-usługi –– FAQ),

• Funkcjonalność umożliwiająca rejestrację oraz założenie konta,

• Informacje o projekcie MSIM.

Ponadto w ramach wdrożenia systemu MSIM dostępne będą:

• Mobilna wersja portalu informacyjnego e-Zdrowie.

• 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.

4. System MSIM musi być przygotowany na integrację z lokalnymi systemami dziedzinowymi w ramach interfejsów zgodnych ze standardem opisanym w Załączniku 9A.:

5. Zakres wymienianych danych pomiędzy jednostkami może być różny i zależy od możliwości systemów dziedzinowych danej jednostki ochrony zdrowia.

6. Podłączenie nowej jednostki ochrony zdrowa do MSIM nie może wymagać od dostawcy systemu dziedzinowego dla danej jednostki ochrony zdrowia żadnej specyficznej wiedzy (np. z zakresu kryptografii) poza umiejętnością implementacji webservices zgodnie
   z dokumentacją protokołu wymiany danych.

7. Wymiana informacji w ramach sieci pomiędzy jednostkami ochrony zdrowa
   z wykorzystaniem MSIM, realizującej e-Usługi ma wykorzystywać interfejsy wymiany danych zgodne z przyjętymi standardowymi protokołami w ochronie zdrowia (m. in. HL7 CDA R2 na poziomie interoperacyjności 3-cim, DICOM, XML i PDF zgodne z Rozporządzeniem Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania). W przypadku konieczności standardowe protokoły mogą zostać rozbudowane o dodatkowe elementy, nie występujące w w/w protokołach.

2.3.Koncepcja wykonania i dostawy, instalacji, konfiguracji, wdrożenia, uruchomienia oraz integracji systemu MSIM

Wdrożenie należy rozumieć jako szereg uporządkowanych i zorganizowanych działań mających na celu wykonanie opisanego w OPZ Systemu MSIM. Wdrożenie będzie realizowane w ramach powołanych do tego celu struktur organizacyjnych po stronie Zamawiającego oraz Wykonawcy.

Wykonawca ponosi odpowiedzialność za swoich pracowników i szkody przez nich poczynione
w lokalizacjach instalacji infrastruktury sprzętowej.

W ramach dokumentu „Plan Wdrożenia Projektu” zostaną przez Wykonawcę przygotowane informacje na temat struktury organizacyjnej zarządzania projektem, w tym muszą zostać powołane minimum następujące role w projekcie:

1. Kierownik Projektu ze strony Zamawiającego,

2. Kierownik Projektu ze strony Wykonawcy,

3. Zespół realizacyjny po stronie Wykonawcy.

W ramach struktury organizacyjnej procesu wdrożenia musi zostać również powołany Komitet Sterujący minimum w składzie:

1. Przewodniczący – przedstawiciel Zamawiającego,

2. Główny Dostawca – przedstawiciel Wykonawcy,

3. Główny Odbiorca – przedstawiciel Zamawiającego.

Każda z tych ról ma prawo powołać swoich specjalistów dziedzinowych odpowiadających za operacyjną realizację projektu. Szczegółowe zadania i kompetencje Komitetu Sterującego zostaną szczegółowo opisane w Planie Wdrożenia Projektu.

W ramach procesu Wdrożenia zaplanowano, iż nastąpią po sobie chronologicznie następujące działania:

1. Przygotowanie Analizy przedwdrożeniowej Systemu MSIM

Pierwszym zadaniem do wykonania w ramach procesu wdrożenia jest opracowanie przez Wykonawcę w porozumieniu z Zamawiającym Analizy przedwdrożeniowej MSIM.

Dokument ten stanowić będzie bazowy zapis opisujący budowany System MSIM. Na podstawie zapisów w tym dokumencie będą prowadzone i odbierane poszczególne zadania realizowane przy budowie Systemu MSIM.

Dokument ten wraz z SIWZ będą stanowiły podstawę do weryfikacji funkcjonalnej i jakościowej Systemu MSIM w trakcie odbiorów.

2. Dostawa instalacja i konfiguracja infrastruktury Sieciowej

Dostawa instalacja i konfiguracja infrastruktury sieciowej jest zadaniem mającym na celu budowę lub modernizację pasywnego sprzętu sieciowego oraz dostawę, instalację i konfigurację aktywnego sprzętu sieciowego do wskazanych lokalizacji według przygotowanego przez Wykonawcę wspólnie z Zamawiającym harmonogramu w porozumieniu z Partnerami Projektu. Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to z bieżącą pracą Partnerów Projektu. Harmonogram musi być przedstawiony jako diagram Gantta, który obejmuje zadania wraz z ich następnikami, datę rozpoczęcia, datę zakończenia zadania, czas trwania (liczony w dniach roboczych), podmiot odpowiedzialny za realizację zadania, % postęp w realizacji zadania.

Wymagania w zakresie organizacji prac instalacyjnych:

1. Wykonawca będzie dostarczał pasywny sprzęt sieciowy sukcesywnie w ilości niezbędnej do prowadzenia prac instalacyjnych zgodnie z harmonogramem.

2. 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.

3. 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.

4. Za sprzęt sieciowy zapewniany w ramach realizacji przedmiotu zamówienia do czasu podpisania protokołu odbioru odpowiada Wykonawca.

3. Dostawa instalacja i konfiguracja infrastruktury sprzętowej

Dostawa instalacja i konfiguracja infrastruktury sprzętowej jest zadaniem mającym na celu dostarczenie zamawianego sprzętu do wskazanych lokalizacji według przygotowanego przez Wykonawcę wspólnie z Xxxxxxxxxxxx harmonogramu w porozumieniu z Partnerami Projektu.

Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to z bieżącą pracą Partnerów Projektu.

Wymagania w zakresie logistyki dostaw:

1. Wykonawca ma zapewnić wniesienie dostarczonego sprzętu do miejsca (pomieszczenia) u Partnera Projektu oraz w lokalizacji warstwy regionalnej MSIM.

2. 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.

3. 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.

4. Za infrastrukturę sprzętową zapewnianą w ramach realizacji przedmiotu zamówienia do czasu podpisania protokołu odbioru odpowiada Wykonawca.

4. Dostawa, instalacja i konfiguracja Oprogramowania systemowego i narzędziowego

W ramach zadania dostawy, instalacji oraz konfiguracji Oprogramowania systemowego
i narzędziowego Wykonawca ma dokonać instalacji i konfiguracji wymaganego oprogramowania systemowego i narzędziowego na dostarczonym uprzednio sprzęcie. Dostawa i instalacja ma być wykonana we wskazanych lokalizacjach zgodnie z Planem Wdrożenia Projektu. Po zakończeniu instalacji, zainstalowane oprogramowanie musi zostać skonfigurowane tak aby działało poprawnie zgodnie z jego przeznaczeniem i wymaganą architekturą rozwiązania Systemu MSIM oraz oferowało funkcjonalność opisaną w SIWZ, a także zapewniać prawidłową pracę Oprogramowania aplikacyjnego.

5. Dostawa, instalacja i konfiguracja Oprogramowania aplikacyjnego

W ramach zadania dostawy instalacji i konfiguracji oprogramowania aplikacyjnego Wykonawca ma dokonać instalacji i konfigurację zamawianego oprogramowania aplikacyjnego. Dostawa instalacja i konfiguracja ma być wykonana we wskazanych lokalizacjach oraz zgodnie z Planem Wdrożenia Projektu. Po zakończeniu prac instalacyjnych oprogramowanie musi zostać skonfigurowane tak aby oferowało funkcjonalność opisaną w SIWZ oraz zgodnie z wymaganą architekturą rozwiązania Systemu MSIM.

6. Integracja MSIM z Partnerami Projektu i Podmiotami leczniczymi

Zadania te polegają na integracji wskazanych jednostek ochrony zdrowia w ramach Systemu MSIM, zgodnie z wymaganą architekturą rozwiązania systemu MSIM oraz określonymi elementami warstwy integracji Systemu MSIM. Głównym celem integracji jest uruchomienie e-Usług w zakresie synchronizacji i wymiany danych pomiędzy warstwą regionalną MSIM, a warstwami lokalnymi Partnerów Projektu.

7. Testy

Celem przeprowadzenia testów jest weryfikacja przez Zamawiającego, czy wszystkie prace wykonane w trakcie budowania Systemu MSIM zostały wykonane prawidłowo i zgodnie z założeniami funkcjonalnymi i jakościowymi. Testy będą przeprowadzane zarówno przez pracowników Partnerów Projektów jak i wskazanych przez Zamawiającego osób i podmiotów zewnętrznych.

W celu przeprowadzenia testów Wykonawca przygotuje kompletne środowisko testowe oraz scenariusze testowe.

Pozytywne zakończenie testów wraz z usunięciem wskazanych wad jest niezbędne aby dla poszczególnych komponentów oraz Systemu MSIM dokonać odbiorów w ramach poszczególnych etapów oraz odbioru końcowego.

8. Odbiór końcowy

Zadanie to ma na celu potwierdzenie wykonanie wszystkich zadań wynikających z Projektu, w tym odebrania wszystkich Komponentów i etapów Projektu oraz dostarczenia wszystkich wymaganych
w zamówieniu dokumentów. Dokonanie odbioru końcowego zakończy prace przy budowie Systemu MSIM i będzie podstawą do przekazania Systemu MSIM do użytkowania produkcyjnego.

Wykonawca ma przekazać protokoły odbioru końcowego z rozpisaniem na składowe będące elementami całego systemu MSIM w uzgodnieniu z Zamawiającym.

2.4.Dyslokacja elementów systemu

Lista lokalizacji, w których należy zainstalować elementy systemu

1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu

2. Szpital Specjalistyczny im. J. Dietla w Krakowie

3. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.(gdzie zlokalizowane są dwie serwerownie do których dostarczona zostanie infrastruktura zamawiana w ramach MSIM)

Ponadto Projekt musi umożliwiać przyłączenie do niego w dalszym okresie kolejnych jednostek ochrony zdrowia.

Zgodnie z podziałem funkcjonalnym System składa się z komponentu regionalnego oraz komponentu lokalnego.

Komponent lokalny umieszony zostanie w następujących lokalizacjach:

1. Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu

2. Szpital Specjalistyczny im. J. Dietla w Krakowie

3. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.

Komponent regionalny umieszony zostanie w lokalizacji:

1. Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.

Lista lokalizacji jest aktualna na dzień 6.10.2014.

Cała komunikacja mająca na celu przekazanie dokumentacji ze Szpitala występującego
o dokumentację do szpitala udostępniającego dokumentację jest realizowana za pośrednictwem warstwy regionalnej MSIM.

Rysunek 5. Koncepcja komunikacji w MSIM.

2.5.Zasady budowy reguł interoperacyjności w systemie

Zakres i znaczenie metadanych EDM oraz schematów atomowych dla repozytorium EDM i rejestru EDM powinien być zgodny z wytycznymi profilu integracyjnego XDS.b, a w szczególności z tabelą 4.3.1.1-3 dokumentu „IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction and Content Specifications” (dostępny na stronie: xxxx://xxx.xxx.xxx/xxxxxxxxXxxxx/Xxxxxxxxx/XXX/XXX_XXX_XX_Xxx0.xxx).

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.

Algorytm znakowania czasem powinien być oparty o przesyłanie skrótów dokumentów do usługi (serwera znakowania czasem) i znakowaniu wyłącznie skrótów dokumentów.

Architektura takiego rozwiązania implikuje w warstwie regionalnej istnienie 2 usług infrastrukturalnych:

• Usługa znakowania czasem

• Usługa weryfikacji znaku czasu

System powinien wykorzystywać usługę znacznika czasu realizowaną przez Centrum Autoryzacji (CAPE w Małopolsce)), przez zastosowanie funkcjonującej obecnie w Centrum aplikacji PentaSCAPE-TSA Service. Aktualna wydajność usługi powinna być wystarczająca do planowej skali systemu.

Certyfikaty, listy CRL oraz inne dane przechowywane przez Centrum Certyfikacji znakowane są wiarygodnym czasem pochodzącym z wzorcowego zaufanego serwera czasu.

Usługa znakowania czasem musi posiadać wydajność na poziomie oferowanym przez CAPE
w Małopolsce.

2.7.Koncepcja autentykacji i identyfikacji użytkowników

Identyfikacja, uwierzytelnianie i autoryzacja użytkowników (osób oraz systemów) powinna być oparta o mechanizm scentralizowany, który logicznie wydziela 2 warstwy:

• Identity provider (dostawca tożsamości) pełniący funkcję weryfikującą – funkcja powinna być dostępna z poziomu komponentu regionalnego jak wspólna usługa infrastrukturalna.

• Klientów usługi, którzy potrzebuję rzetelnej i aktualnej informacji o tożsamości uczestników komunikacji – funkcja ta będzie wykorzystywana głównie przez komponent lokalny.

Rozwiązanie powinno być oparte o jeden wspólny serwer certyfikacyjny, każdy użytkownik będzie miał klucz/token weryfikowany przez serwer certyfikacji. Zakłada się wykorzystanie działającego Centrum Autoryzacji podpisu elektronicznego w ramach Urzędu Marszałkowskiego(CAPE w Małopolsce).

Usługa uwierzytelniania powinna być oparta o mechanizm jednokrotnego logowania (ang. Single Sign On – SSO) w obrębie aplikacji wytworzonych w ramach projektu. W ramach MSIM powstanie usługa pozwalająca poszczególnym HIS-om wykorzystanie tego mechanizmu w ramach poszczególnych instalacji. Kwestia zaimplementowania SSO w ramach poszczególnych HIS jest elementem odrębnego zamówienia udzielonego wykonawcom HIS.

Na potrzeby usługi e-Rejestracja wymagane będzie utworzenie niezależnego repozytorium tożsamości dla Pacjentów, którzy będą chcieli korzystać z funkcjonalności rezerwowania wizyt
w placówce medycznej.

Konta tych pacjentów a w konsekwencji ich dane osobowe muszą być zabezpieczone mechanizmami odpowiadającymi poziomowi wysokiemu zgodnie z Rozporządzeniem Ministra Spraw Wewnętrznych
i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych

W celu zapewnienia bezpieczeństwa danych osobowych dla potwierdzenia rejestracji wymagana będzie wizyta w placówce z wydrukowanym formularzem rejestracji celem potwierdzenia danych osobowych i otrzymania hasła pierwszego logowania.

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ń.

Xxxx prac nad wdrożeniem IKP wygląda następująco:

• Prototyp Internetowego Konta Pacjenta został wdrożony w 2011 roku i objął pacjentów chorych na cukrzycę w wieku od 18 lat leczących się w Krakowie.

• W lutym 2014 zakończono realizację Projektu Zintegrowanych prototypów Internetowego Konta Pacjenta oraz e-Recepty. System przetestowano w trzech miastach – Gdańsku, Olsztynie i Warszawie.

Wykonawca systemu MSIM musi przewidzieć w ramach usługi wykonanie 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.

• 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:

• 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. Xxxxxxx Xxxxxxxxx).

2.10.Koncepcja rozwoju systemu, kolejnych etapów, dołączania kolejnych jednostek

W ramach koncepcji rozwoju systemu przewiduje się:

1. Zdefiniowanie i udostępnienie standardów warstwy integracji, w którego skład wchodzi
   m. in. interfejs integracji regionalnej odpowiedzialny za wymianę danych, umożliwiający komunikację elektroniczną pomiędzy regionem a lokalnymi systemami informatycznymi (standardy zapytań, struktur baz danych) – Wykonawca przygotuje taki dokument na etapie realizacji projektu.

2. Rozwój na poziomie warstwy regionalnej e-Usług dostarczanych wszystkim obywatelom, usługi integrujące działania jednostek służby zdrowia i usługi dedykowane organom działającym na poziomie regionalnym i ponadregionalnym– do realizacji w ramach kolejnych projektów.

3. System zarządczy dla Województwa Małopolskiego – w zakresie przewidzianym OPZ,

4. Integracja z pozostałymi systemami regionalnymi w dziedzinie e-Zdrowia,
   w tym systemami i usługami wytwarzanymi w ramach projektów CSIOZ oraz innych platform regionalnych, np. PSIM (Podkarpacki System Informacji Medycznej)– w tym zakresie wymagane jest zagwarantowanie integracji z w ramach zaleceń CSIOZ w okresie gwarancji.

Architektura warstwy regionalnej ma zapewniać łatwą modyfikowalność systemu w przyszłości. Modyfikowalność systemu jest rozumiana jako co najmniej:

• Podłączanie nowych jednostek do systemu poprzez konfiguracje

• Rozszerzanie zakresu wymienianych danych poprzez konfiguracje

• Rozszerzanie funkcjonalności poprzez podłączanie dodatkowych modułów

W tym zakresie Wykonawca przygotuje standardy integracji.

2.11.Schemat połączeń pomiędzy elementami systemu

Sekcja przedstawia schemat połączeń pomiędzy elementami systemu, w tym połączeń sieciowych.

Sieć

Sieć połączeń pomiędzy poszczególnym uczestnikami projektu musi zostać zbudowana
z wykorzystaniem posiadanego przez uczestników projektu łącza internetowego. W ramach publicznej sieci Internet zostanie zbudowana dedykowana sieć VPN, która połączy wszystkich uczestników projektu. W związku z tym, dane nie mogą być przesyłane w postaci jawnej lecz należy je szyfrować. Zakłada się w tym celu wykorzystanie mechanizmu IPsec (Internet Protocol Security), dzięki któremu urządzenia tworzą tzw. tunele IPsec. Dane przed wyjściem do Internetu są szyfrowane przez brzegowe urządzenie UTM znajdujące się w Szpitalu. Natomiast na końcu tunelu dane są odszyfrowywane przez brzegowe urządzenie UTM znajdujące się w lokalizacji regionalnej. W sytuacji przesyłania danych z Regionu do Szpitali kolejność szyfrowania będzie odwrotna.

Takie tunele będę na stałe zestawione pomiędzy poszczególnymi Szpitalami, a Regionem. Układ ten przedstawia poniższy rysunek.

Rysunek 6:Schemat połączeń VPN (źródło: opracowanie własne)

Dzięki temu, wszystkie dane przechodzące przez Internet są bezpieczne. Również pracownicy zdalni mogą łączyć się do sieci firmowej poprzez tunel IPsec, umożliwia to bezpiecznie korzystanie
z zasobów sieci firmowej np. z domu. W tym przypadku sieć VPN ma strukturę gwiazdy.

Na poniższym rysunku został przedstawiony schemat połączeń infrastruktury sprzętowej dla projektu MSIM.

W warstwie technicznej schemat połączeń pomiędzy elementami systemu oparty jest o następujące typy połączeń:

• Tunele VPN szyfrowane protokołem SSL pomiędzy warstwą regionalną a poszczególnymi komponentami lokalnymi,

• Łącze Ethernet 1Gb w zakresie sieci LAN,

• Połączenia z wykorzystaniem protokołu FC dla sieci SAN pomiędzy macierzami a serwerami.

Szpital lokalny 3

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

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

Rysunek 9.Schemat połączeń infrastruktury sprzętowej w lokalizacji Lokalnej.

2.12.Interfejsy komunikacyjne z innymi systemami informatycznymi

System MSIM wykorzystuje następujące zewnętrzne interfejsy:

• System HIS, gdzie zakres i tryb wymiany danych określony jest interfejsem ITI-41

• Lokalny systemu lub moduł e-Rejestracji, gdzie zakres i tryb integracja określony jest definicją procesów biznesowych z grupy e-Rejestracji (rozdział 2)

• P1 (IKP), gdzie zakres i tryb wymiany danych określony jest interfejsem właściwym dla klientów rejestru i repozytorium EDM

• Centrum Autoryzacji podpisu elektronicznego w Małopolsce(CAPE w Małopolsce), gdzie zakres i tryb integracji musi odpowiadać wymaganej funkcjonalności usługi podpisu elektronicznego dla EDM

Wytyczne dla komunikacji z platformą P1:

• Komunikacja z platformą P1 następuje w oparciu o reguły tworzenia Elektronicznej Dokumentacji Medycznej i model transportowy danych o Zdarzeniach Medycznych oraz Indeksie EDM, gdzie platforma P1 jest rejestrem EDM

• Komunikat przekazania informacji o zdarzeniu medycznym jest inicjowany przez komponent regionalny, który przekazuje komunikat do platformy P1 analogicznie do zdarzenia rejestracji EDM przekazywanego przez komponent lokalny do komponentu regionalnego

• System dziedzinowy musi wytworzyć a komponent regionalny musi przygotować komunikat do platformy P1 zgodnie z ostatnią aktualną wersją wytycznych dostępnych na stronach CSIOZ

Wykonawca jest zobowiązany do przygotowania opisu interfejsów, ich wykonania i przetestowania na zasadach odrębności w stosunku do pozostałych funkcji systemu MSIM (interfejsy można testować
w oderwaniu od samego systemu).

2.13.Koncepcja komunikacji pomiędzy jednostkami

Cała komunikacja mająca na celu przekazanie dokumentacji ze Szpitala występującego
o dokumentację do szpitala udostępniającego dokumentację jest realizowana za pośrednictwem warstwy regionalnej MSIM.

Rysunek 10.Schemat koncepcji komunikacji

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

2.14.Koncepcja przesyłu danych pomiędzy jednostkami

Proces udostępnienia dokumentu zilustrowany został na poniższym rysunku:

Rysunek 11. Schemat procesu udostępniania dokumentu

W ramach systemu MSIM przesył danych pomiędzy jednostkami powinien być realizowany
w przypadku udostępniania dokumentacji medycznej. Scenariusz udostępniania dokumentacji medycznej jest następujący:

1. Użytkownik za pomocą aplikacji typu klient wyszukuje dokument pacjenta w rejestrze na podstawie metadanych.

2. System regionalny sprawdza uprawnienia użytkownika.

3. Repozytorium Regionalne kontaktuje się z repozytorium jednostki w którym przechowywana jest dokumentacja.

4. Dokumentacja wysyłana jest z repozytorium, w którym weryfikowana jest jej poprawność.

5. Dokumentacja wysyłana jest z warstwy regionalnej MSIM do użytkownika.

6. Po potwierdzeniu przesłania dokumentacji do Użytkownika, w warstwie regionalnej zostaje odnotowany fakt udostępnienia Elektronicznej Dokumentacji Medycznej zawierający co najmniej dane o: użytkowniku, dacie, czasie udostępnienia, wersji przekazanych dokumentów).

2.15.Integracja systemów oraz danych z innych systemów do wdrażanego systemu MSIM

System MSIM wykorzystuje następujące zewnętrzne interfejsy i w takim zakresie musi być zintegrowany z systemami zewnętrznymi udostępniającymi lub wykorzystującymi interfejsy:

• System HIS, gdzie zakres i tryb wymiany danych określony jest interfejsem ITI-41

• Lokalny systemu lub moduł e-Rejestracji, gdzie zakres i tryb integracja określony jest definicją procesów biznesowych z grupy e-Rejestracji (rozdział 2)

• P1, gdzie zakres i tryb wymiany danych określony jest interfejsem właściwym dla klientów rejestru i repozytorium EDM, tj. ITI-18 i ITI-43

• Centrum Autoryzacji podpisu elektronicznego w Małopolsce, gdzie zakres i tryb integracji musi odpowiadać wymaganej funkcjonalności usługi podpisu elektronicznego dla EDM.

2.16.Koncepcja wirtualizacji zasobów informatycznych

Wymagana jest dostawa oprogramowania do wirtualizacji z licencjami wystarczającymi dla uruchomienia na dostarczonym sprzęcie 40 serwerów wirtualnych.

Wykonawca musi opracować i uzgodnić z Zamawiającym plan wirtualizacji zasobów obejmujących zakres, tryb i konfigurację zasobów wirtualizowanych biorąc pod uwagę charakterystykę Systemu MSIM, zasady wirtualizacji poszczególnych Partnerów oraz przesłanki wydajnościowe
i bezpieczeństwa.

Wymagania na oprogramowanie do wirtualizacji przedstawiono w sekcji z oprogramowaniem standardowym (infrastruktura).

3.Analiza stanu aktualnego

3.1.Infrastruktura informatyczna

3.1.1.Serwerownia

Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu

L.P.	Parametr	Serwerownia 1	Serwerownia 2	Xxxxxxxxxxx 0
	Xxxxx	00-000 Xxxx Xxxx, Xxxxxxx 00	00-000 Xxxx Xxxx, Xxxxxxx 00	00-000 Xxxx Xxxx, Xxxxxxx 00
	Lokalizacja w budynku	33-300 Nowy Sącz, Xxxxxxx 0, Xxxxxxx xxxxxx	00-000 Xxxx Xxxx, Xxxxxxx 0, Xxxxxxx xxxxxx - RTG	00-000 Xxxx Xxxx, Xxxxxxx 0,Xxxxxxx onkologiczny
	Powierzchnia użytkowa [m2] /wysokość [m]	10/2,98	8/2,54	6/2,96
	Czy jest wolne miejsce na dodatkową szafę	Tak	Tak	Tak
	Ilość szaf RACK/Ilość wolnego miejsca [U]	1/5	1/0	3/5
	ZABEZPIECZENIA FIZYCZNE
	System alarmowy	Nie	Nie	Tak
	Monitoring video	Nie	Nie	Nie
	Kontrola dostępu	Nie	Nie	Nie
	Ochrona fizyczna	Nie	Nie	Nie
	Drzwi antywłamaniowe	Nie	Nie	Nie
	Zabezpieczenie okien	Tak	Tak	Nie
	Sygnalizacja pożaru	Nie	Nie	Tak
	System gaszenia pożaru gazem obojętnym	Nie	Nie	Nie
	Gaśnica CO2	Nie	Nie	Nie
	Kontrola temperatury	Nie	Nie	Nie
	Kontrola wilgoci	Nie	Nie	Nie
	Podłoga techniczna	Nie	Nie	Nie
	ZAGROŻENIA
	Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski)	Tak (niski)	Tak (niski)	Nie
	Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski)	Tak (niski)	Tak (niski)	Nie
	INNE
	Ilość klimatyzatorów	1	1	1
	Łączna wydajność klimatyzatorów [kW]	5,2	8,8	7,1
	PRZYŁĄCZA TELETECHNICZNE
	Wolne przyłącza sieci logicznej [szt.]	12	24	24
	Zapas dla przyłączenia urządzeń do sieci elektrycznej [A]	Tak	Tak	Tak
	Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A]	Tak/ 25	Tak/ 25	Tak/ 25
	Wydzielony obwód zasilania [TAK/NIE]	Nie	Nie	Nie
	System zasilania awaryjnego [TAK/NIE]	Tak	Tak	Tak
	Centralny UPS [TAK/NIE]/Moc [kVA]	Nie	Nie	Nie
	Agregat prądotwórczy [TAK/NIE]/Moc [kVA]	Nie	Nie	Nie
	ZIDENTYFIKOWANE RYZYKA
	Konieczność rozbudowy sieci logicznej	Tak	Tak	Tak
	Konieczność rozbudowy sieci elektrycznej	Tak	Tak	Tak

Szpital Specjalistyczny im. J. Dietla w Krakowie

L.P.	Parametr	Serwerownia 1	Serwerownia 2	Serwerownia 3
	Adres	00-000 Xxxxxx, xx. Xxxxxxxx 0	00-000 Xxxxxx, xx Xxxxx 00
	Lokalizacja w budynku	00-000 Xxxxxx, xx. Xxxxxxxx 0 Główna lokalizacja	00-000 Xxxxxx, xx Xxxxx 00, 2km od Głównej Lokalizacji
	Powierzchnia użytkowa [m2] /wysokość [m]	18/2,90	12/2,70
	Czy jest wolne miejsce na dodatkową szafę	Tak	Tak
	Ilość szaf RACK/Ilość wolnego miejsca [U]	4/70	3/26
	ZABEZPIECZENIA FIZYCZNE
	System alarmowy	Nie	Tak
	Monitoring video	Nie	Tak
	Kontrola dostępu	Nie	Tak
	Ochrona fizyczna	Tak	Tak
	Drzwi antywłamaniowe	Nie	Nie
	Zabezpieczenie okien	Nie	Nie dotyczy (brak okien)
	Sygnalizacja pożaru	Tak	Tak
	System gaszenia pożaru gazem obojętnym	Nie	Nie
	Gaśnica CO2	Tak	Tak
	Kontrola temperatury	Nie	Nie
	Kontrola wilgoci	Nie	Nie
	Podłoga techniczna	Nie	Nie
	ZAGROŻENIA
	Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski)	Nie	Nie
	Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski)	Nie	Nie
	INNE
	Ilość klimatyzatorów	2	2
	Łączna wydajność klimatyzatorów [kW]	6	4
	PRZYŁĄCZA TELETECHNICZNE
	Wolne przyłącza sieci logicznej [szt.]	90	120
	Zapas dla przyłączenia urządzeń do sieci elektrycznej [A]	8	20
	Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A]	Tak/8	Tak/20
	Wydzielony obwód zasilania [TAK/NIE]	Tak	Tak
	System zasilania awaryjnego [TAK/NIE]	Nie	Tak
	Centralny UPS [TAK/NIE]/Moc [kVA]	Nie	Tak/2KVA
	Agregat prądotwórczy [TAK/NIE]/Moc [kVA]	Nie	Tak/650kVA
	ZIDENTYFIKOWANE RYZYKA
	Konieczność rozbudowy sieci logicznej	Nie	Nie
	Konieczność rozbudowy sieci elektrycznej	Nie	Nie

Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxxx Krakowie sp. z o.o.

L.P.	Parametr	Serwerownia 1	Serwerownia 2	Serwerownia 3
	Adres	Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx	Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx
	Lokalizacja w budynku	Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx	Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx
	Powierzchnia użytkowa [m2] /wysokość [m]	13/3	30/3
	Czy jest wolne miejsce na dodatkową szafę	Tak	Tak
	Ilość szaf RACK/Ilość wolnego miejsca [U]	5/42	Brak
	ZABEZPIECZENIA FIZYCZNE
	System alarmowy	Nie	Tak
	Monitoring video	Tak	Tak
	Kontrola dostępu	Nie	Nie
	Ochrona fizyczna	Nie	Nie
	Drzwi antywłamaniowe	Nie	Nie
	Zabezpieczenie okien	Brak okien	Tak
	Sygnalizacja pożaru	Tak	Tak
	System gaszenia pożaru gazem obojętnym	Nie	Nie
	Gaśnica CO2	Tak	Tak
	Kontrola temperatury	Tak	Nie
	Kontrola wilgoci	NIe	Nie
	Podłoga techniczna	NIe	Nie
	ZAGROŻENIA
	Obecność sieci wod-kan (poz. zagrożenia: wysoki, średni, niski)	Nie (niski)	Nie (niski)
	Obecność instalacji grzewczych (poz. zagrożenia: wysoki, średni, niski)	Tak (niski)	Tak (niski)
	INNE
	Ilość klimatyzatorów	2	0
	Łączna wydajność klimatyzatorów [kW]	7 kW	0
	PRZYŁĄCZA TELETECHNICZNE
	Wolne przyłącza sieci logicznej [szt.]	70	22
	Zapas dla przyłączenia urządzeń do sieci elektrycznej [A]	6kW	Brak - do uruchomienia w zależności od potrzeb
	Zapas mocy dla przyłączenia urządzeń do sieci elektrycznej [TAK/NIE]/[A]	Tak /200kW	Tak/200kW
	Xxxxxxxxxx xxxxx xxxxxxxxx [TAK/NIE]	Tak	Nie
	System zasilania awaryjnego [TAK/NIE]	Tak	Nie
	Centralny UPS [TAK/NIE]/Moc [kVA]	Tak /20kVA	Nie
	Agregat prądotwórczy [TAK/NIE]/Moc [kVA]	Tak /2x 540kVA (dla całego szpitala)
	ZIDENTYFIKOWANE RYZYKA
	Konieczność rozbudowy sieci logicznej	Tak	Tak
	Konieczność rozbudowy sieci elektrycznej	Tak	Tak

3.1.2.Serwery

L.P	Producent - model	Rok produkcji	RAM	Obudowa [Tower / RACK-xU]	Rola (zadanie)
Szpital Specjalistycznyim. J. Śniadeckiego w Nowym Sączu
	Optimus Nserwer	2005	2GB	Tower	Auto ID
	Optimus Xxxxxxx	0000	0XX	Xxxxx	Xxxxxx XX
	IBM x3650	2009	6GB	Rack 2U	Simple ERP
	SUN x4170	2011	24GB	Rack 1U	Eskulap – terminale
	SUN x4170	2012	24GB	Rack 1U	Eskulap – terminale
	SUN x4170	2012	20GB	Rack 1U	Eskulap – terminale
	HP ML350	2011	4GB	Rack 4U	Impax
	HP ML350	2011	2GB	Rack 4U	Impax
Szpital Specjalistyczny im. J. Dietla w Krakowie
	HP RP5470 UX XX-XXXX	0000	2GB	RACK 6U	HIS/LIS/RIS
	NTT TYTAN 4205 WINSER	2008	4GB	RACK 3U	Administracja+ serwer plików
	NTT TYTAN WINSER 2003	2009	8GB	RACK 2U	PACS
	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
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.
	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

3.1.3.Macierze

L.P	Producent - model	Rok produkcji	Pojemność	Jakie dane są przechowywane	Rodzaj dysków [SATA / FATA]
Szpital Specjalistycznyim. J. Śniadeckiego w Nowym Sączu
	IBM DS3512	2009	2x 1TB; 5x300MB	PACS	SAS (SATA)
Szpital Specjalistyczny im. J. Dietla w Krakowie
	HP MSA P2000	2012	12TB	Dane administracyjne	SAS
	NTT	2008	18TB	Dane medyczne	SATA
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.
	HP MSA P2000	2009	5TB	PACS	SAS
	HP 2312fc	2010	12TB	PACS	SAS
	HP MSA P2000 G3	2012	32TB	HIS,Archiwa	SAS
	HP MSA2000	2012	24TB	Dane administracyjne	SAS

3.1.4.Biblioteka taśmowa

L.P	Producent - model	Rok produkcji	Pojemność	Jakie dane są przechowywane	Oprogramowanie do backupu
Szpital Specjalistycznyim. J. Śniadeckiego w Nowym Sączu
	HP StorageWorks MSL 0000	0000	00x0,6 TB	PACS	Firmeware HP
	SUN Oracle Storagetek SL24	2011	20x1,6 TB	Simple	Firmeware Oracle
Szpital Specjalistyczny im. J. Dietla w Krakowie
	Brak	Nie dotyczy	Nie dotyczy	Nie dotyczy	Nie dotyczy
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.
1	HP StorageWorks MSL 4048	2010	48x800GB	PACS	Firmeware HP, Synektik

3.1.5.Połączenia sieciowe oraz sieć NAS

Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu

Główny Punkt Dystrybucyjny (GPD) znajduje się w pomieszczeniu serwerowni na parterze
w budynku Pulmonologii.

Oprócz tego w budynkach znajdują lokalne punkty dystrybucyjne, są to:

• Punkty 4P0, 4P1, 4P3, 4P4 (zlokalizowane na piętrach 0, 1, 3 i 4 Budynku 4)

• Punkty 3P-1, 3P0, 3P1, 3P2, 3P3 zlokalizowane na piętrach -1, 0, 1, 2 i 3 Budynku 3

• Punkt PU zlokalizowany w budynku Pulmonologii

• Punkt PS zlokalizowany w budynku Kliniki Psychiatrycznej

• Punkt TE zlokalizowany w dziale technicznym

• Punkt DR (istniejący) zlokalizowany w budynku Dyrekcji

• Punkt RTG (istniejący) na parterze budynku 4

Punkty zostały połączone okablowaniem światłowodowym wielodomowym OM3 o różnej liczbie włókien. Załączony rysunek ilustruje schemat sieci logicznej.

Podstawą do opracowania zagadnień związanych z okablowaniem strukturalnym są normy okablowania strukturalnego:

• ISO/IEC11801 wyd. II

• EN50173-1 wyd. II

• TIA/EIA 569A

• PN-EN50173-1 + AC

• TIA/EIA 568B

Szpital Specjalistyczny im. J. Dietla w Krakowie

cat. 5e

światłowód 10Gb (Wszystkie połączenia posiadają backup – podwójny ring)

cat 6

światłowód 1 Gb

łącze LINK 4Mb/1Mb od 1.02.2013 światłowód 100M

iSCASI, FC, SCASI

Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.

Sieć informatyczna w Szpitalu zbudowana jest w topologii rozszerzonej gwiazdy. Szkielet sieci zbudowany na 6-cio światłowodach MM 50/125 które łączą centralny punkt dystrybucyjny (MDF serwerownia) z lokalnymi punktami dystrybucyjnymi (IDF)usytuowanymi na poszczególnych piętrach. Stacje robocze użytkowników komunikują się z przełącznikiem brzegowymi HP ProCurve 2610 po skrętce miedzianej cat.5e/6 z prędkością 100/1000 Mbps (w zależności od parametrów switch). Komunikacja w obrębie sieci szkieletowej odbywa się z prędkością 1/10Gbps.Szkielet sieci spina modularny przełącznik szkieletowy HP ProCurve 5412zl.

W obrębie serwerowni funkcjonuje sieć pamięci masowej SAN zbudowana w technologii Fibre Channel w skład której wchodzi: 5 macierzy dyskowych HP MSA, system serwerowy HP Blade, 3 serwery Rackowe, biblioteka taśmowa MSL4048.Komunikację pomiędzy urządzeniami serwerowymi
i zasobami pamięci zapewniają 3 switche FC(HP StorageWorks 8/20q oraz Brocade 8/12C). Komunikacja w strukturze FC odbywa się z prędkością 8Gbps.

Na rysunku poniżej przedstawiony jest schemat infrastruktury FC.

3.1.6.Sprzęt komputerowy

L.P.	Rok produkcji	Typ [terminal/PC]	System operacyjny	Ilość [szt.]
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
1.	2011	Terminale	Windows serwer 2008	200
2.	2005-2012	PC	Windows XP	65
3.	2011	PC	Windows VISTA	5
4.	2012-2013	PC	Windows 7	20
5.	2013	PC	Windows 8	1
Szpital Specjalistyczny im. J. Dietla w Krakowie
1.	2008, 2012, 2013	Terminal	Linux	140
2.	2005-2013	PC	Windows (XP; VISTA; 7)	110
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. Z o.o.
0	0000-0000	PC	Windows XP PRO, 7 PRO	574

1. Infrastruktura sieciowa

3.1.1.Sieć szkieletowa

L.P	Podmiot	Technologia	Przepustowość	Redundancja [TAK/NIE]
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Światłowód	1Gb/10Gb	Nie
	Szpital Specjalistyczny im. J. Dietla w Krakowie	Światłowód	10Gb	Tak
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.	Światłowód	1Gb/10Gb	Nie

3.1.2.Sieć pozioma

L.P	Podmiot	Technologia	Przepustowość	Kategoria
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	UTP	100Mb/1Gb	5/6e
	Szpital Specjalistyczny im. J. Dietla w Krakowie	UTP	1Gb	5e/6
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.	UTP/FTP	100Mb/1Gb	5e/6

3.1.3.Węzły pośrednie

L.P	Podmiot	Ilość	Odrębne zasilania [TAK / NIE / CZĘŚCIOWO]	UPS [TAK / NIE / CZĘŚCIOWO]	Dostęp chroniony [TAK / NIE / CZĘŚCIOWO]
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	23	Nie	Nie	Częściowo
	Szpital Specjalistyczny im. J. Dietla w Krakowie	7	Częściowo (2 z zasilaniem)	Częściowo (2)	Częściowo
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.	18	Częściowo	Częściowo	Częściowo

3.1.4.Urządzenia UTM

L.P	Podmiot	[TAK / NIE] (model)	ilość	Redun-dancja	Rok produkcji
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Tak (MikroTik Board 1000)	1	Nie	2009
	Szpital Specjalistyczny im. J. Dietla w Krakowie	Tak (Juniper SSG140)	1	Nie	2009
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.	TAK (Linuks - Slackware)	1	Nie	2010

3.1.5.Urządzenia aktywne – lista

Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu

L.P.	Producent	Model	Rok produkcji	Ilość
	Allied Telesis	AT-8000S/24	2009	4
	Allied Telesis	AT-8000GS/24	2010	20
	Allied Telesis	AT-8100S/48	2009	1
	Allied Telesis	AT-9000/24	2009	2
	Allied Telesis	AT-x900/24	2010	1
	Allied Telesis	AT-9000/52	2012	2
	Allied Telesis	AT-x600/24	2010,2012	2
	Allied Telesis	AT-MC101xL	2009	2
	Allied Telesis	AT-G6f Rapier	2007	1
	Allied Telesis	AT-8 PoE	2009	2
	Allied Telesis	AT-8000S/48	2009	1

Szpital Specjalistyczny im. J. Dietla w Krakowie

L.P.	Producent	Model	Rok produkcji	Ilość
	Netgear	M5300-52G +2 x SFP10Gb + 2 moduły stack	2013	9
	Netgear	GS752TXS +2xSFP 10Gb	2012	4
	3com	serii 4200	2010	3
	3com	24 port	2011	2

Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp z o.o.

L.P.	Producent	Model	Rok produkcji	Ilość
	HP	ProCurve 2610	2010	24
	HP	ProCurve 2610	2008	6
	HP	ProCurve 2610	2009	5
	HP	ProCurve 2810	2007	2
	HP	ProCurve 2910al-48G	2010	3
	HP	ProCurve5412zl	2008	1
	HP	ProCurve5406zl	2010	1
	HP	Storage Works 8/20q Fibre Channel Switch	2010	1
	HP	Brocade 8/12C SAN	2010	1
	HP	Brocade 8/12C SAN	2013	1

3.2.Łącza internetowe

LP.	Operator	Serwerownia	Technologia przyłącza	Ilość stałych adresów IP	Przepustowość download [Mbps]	Przepustowość upload [Mbps]	Szczytowe obciążenie	Pozostały czas trwania umowy [mies.]	Czy są warunki do zwiększenia przepustowości
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
	TP SA	Serwerownia RTG	Neostrada	5	40	4	90%	2	Tak
Szpital Specjalistyczny im. J. Dietla w Krakowie
	Fibertech	Xxxxxxxx 0	Światłowód	8	10	10	50%	12	Tak
	TP SA	Xxxxxxxx 0	ADSL	6	4	1	100%	22	Tak
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.
	Netia SA	Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx	Światłowód	4	50	50	80%	9	Tak
	Exatel SA	Kraków, xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx	Radiowe	16	40	40	80%	Brak danych	Tak

Szacując, że do obsługi MSIM będzie konieczne łącze o min. przepustowości 20 Mbps (zarówno upload, jak i download) łącza w Szpitalu Specjalistycznym im. J. Śniadeckiego w Nowym Sączu (tylko upload), oraz Szpitalu Specjalistycznym im. J. Dietla w Krakowie są niewystarczające do obsługi MSIM.

Dostarczenie niezbędnych łącz, których mowa wyżej nie jest elementem zamówienia.

3.3.Procedury bezpieczeństwa

Nazwa jednostki	Wdrożona Polityka Bezpieczeństwa	System zarządzania Bezpieczeństwem Informacji	Procedury dotyczące bezpieczeństwa Informacji
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Nie (zamierza wdrożyć w 2014r)	Nie	Istniejące procedury: - Instrukcja zarządzania systemami informatycznymi służącymi do przetwarzania danych osobowych - procedury archiwizacji danych - procedury nadawania i odbierania uprawnień w szpitalu wdrożone są procedury ISO w zakresie nadawania uprawnień użytkownikom systemu; rozwiązania w zakresie bezpieczeństwa to: karty chipowe (klucze), konta domenowe, konta do systemu informatycznego HIS, RIS, LIS oraz do systemów administracyjnych
Szpital Specjalistyczny im. J. Dietla w Krakowie	Tak	Tak	Istniejące procedury: - 1. Instrukcja zarządzania systemem informatycznym (IZSI) 2 Polityka Bezpieczeństwa Informacji (PI) 3 Procedura bezpieczeństwa danych w ISO 9001:2010
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	Tak	Tak	Istniejące procedury: - - instrukcja zarządzania systemem informatycznym - polityka bezpieczeństwa informacji - procedura bezpieczeństwa danych w ISO 9001:2008 - Procedura zarządzania uprawnieniami w systemach informatycznych - w szpitalu uruchomiono działania zmierzające do uzyskania normy PN-ISO/IEC 27001

Poza Szpitalem Specjalistycznym im. J. Śniadeckiego w Nowym Sączu, wszystkie pozostałe Szpitale posiadają opracowane Polityki Bezpieczeństwa. Oznacza to, że w Szpitalach tych są opracowane zasady i dostępne narzędzia formalne opisujące co najmniej przydzielanie i odbieranie uprawnień dostępu do systemów medycznych oraz polityki haseł.

Są to minimalne konieczne narzędzia formalne do wdrożenia na ich podstawie systemu MSIM oraz określenia zasad dostępu do niego. W ramach prac projektowych należy wypracować ujednoliconą politykę bezpieczeństwa dla systemu MSIM.

Wykonawca systemu MSIM w ramach realizacji projektu opracuje dokumentację ochrony danych osobowych na którą składać się będą następujące dokumenty:

• Polityka bezpieczeństwa danych osobowych,

• Instrukcja zarządzania systemem służącym do przetwarzania danych osobowych.

3.4.Oprogramowanie dziedzinowe

3.4.1.System HIS

L.P.	Podmiot	Producent	Nazwa	Wersja	Wsparcie [TAK/NIE]
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Politechnika Poznańska	ESKULAP	4.4.1 bw	Tak
	Szpital Specjalistyczny im. J. Dietla w Krakowie	GEM Systemy Informatyczne	SIS	Brak wersjonowania	Tak
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	Comarch (Esaprojekt)	Optimed	6.00.360	Tak

3.4.2.System LIS - analityka

L.P.	Podmiot	Producent	Nazwa	Wersja	Wsparcie [TAK/NIE]	Integra-cja z HIS
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Politechnika Poznańska	ESKULAP	2.3.0 s	Tak	Tak
	Szpital Specjalistyczny im. J. Dietla w Krakowie	GEM Systemy Informatyczne	SIS	Brak wersjonowania	Tak	Tak
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	Xxxxxx	Centrum	2.440.10.1285	Tak	Tak

3.4.3.System LIS - bakteriologia

X.X	Xxxxxxx	Producent	Nazwa	Wersja	Wsparcie	Integra-cja z HIS
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Politechnika Poznańska	ESKULAP	1.2.1 h	Tak	Tak
	Szpital Specjalistyczny im. J. Dietla w Krakowie	GEM Systemy Informatyczne	SIS	Brak wersjonowania	TAK	Tak
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	Xxxxxx	Centrum	2.440.10.1285	Tak	Tak

3.4.4.System RIS

L.P.	Podmiot	Producent	Nazwa	Wersja	Wsparcie	Integra-cja z HIS (wyniki opisowe)
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Agfa	IMPAX	2.3.0 r	Tak	Tak
	Szpital Specjalistyczny im. J. Dietla w Krakowie	GEM Systemy Informatyczne	SIS	Brak wersjonowania	Tak	Tak
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	Comarch (Esaprojekt)	CRID	3.1.14.4	Tak	Tak

3.4.5.System PACS

X.X	Xxxxxxx	Producent	Nazwa	Wersja	Wspa-rcie	Integ-racja z HIS
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Agfa	IMPAX	6.4.0.4 513	Tak	Nie
	Szpital Specjalistyczny im. J. Dietla w Krakowie	PIXEL	ExPACS	Ostatnia do wygaśnięcia wsparcia, tj. 01.12.2016	Tak	Nie
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	Synektik	ARPACS	2.143.145.	Tak	Tak

3.4.6.E-Rejestracja

L.P.	Podmiot	Czy jest świadczona?	Producent	Nazwa/Uwagi	Wersja	Wsparcie	Integracja z HIS	Możliwość podłączenie pozostałych
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Nie	Brak	Brak	Brak	Nie	Nie	Nie
	Szpital Specjalistyczny im. J. Dietla w Krakowie	Nie (w trakcie projektowania)	Brak	Brak	Brak	Nie	Nie	Nie
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	Tak	Szpital Specjalistyczny im. L. Rydygiera Sp. z o.o. Dział Informatyki	Oprogramowanie autorskie wykonane we własnym zakresie	1.0	Tak.	Nie.	Nie.

3.4.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.5.Rodzaje przetwarzanych danych

Legenda:

01- Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu

02- Szpital Specjalistyczny i. J. Dietla w Krakowie

03- Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.

W poniższej tabeli wskazano system, z którego jest możliwość importu danych (HIS / LIS / RIS)

	Podmiot	01	02	03
	dokumenty podstawowe - priorytet 1
1	Formularz historii choroby	HIS	HIS	HIS
2	Wywiad lekarski	HIS	HIS	HIS
3	Xxxxxxxx	HIS	HIS	HIS
4	Karta informacyjna z leczenia szpitalnego	HIS	HIS	HIS
5	Opis przebiegu leczenia	HIS	HIS	-
6	Wyniki badań laboratoryjnych – analityka	HIS	HIS	HIS/LIS
7	Wyniki badan laboratoryjnych – bakteriologia	HIS	HIS	HIS/LIS
8	Wyniki badań diagnostyki obrazowej – opis	HIS	HIS	HIS/RIS
9	Wyniki konsultacji	HIS	HIS	-
10	Protokół operacyjny	HIS	HIS	HIS
11	Xxxxx zleceń lekarskich	HIS	HIS	-
	dokumenty rzadko spotykane w HIS - priorytet 2
12	Wywiad epidemiologiczny	HIS	HIS	-
13	Xxxxx Xxxxx Xxxxxx Zakażenia przy Przyjęciu do Szpitala	HIS	HIS	-
14	Ocena ryzyka związanego ze stanem odżywienia	HIS	HIS	HIS
	dokumenty pielęgniarskie - priorytet 3
15	Plan opieki	HIS	HIS	-
16	Xxxxx xxxxxxxxxx	HIS	HIS	HIS
17	Karta indywidualnej opieki pielęgniarskiej	-	HIS	-
18	Xxxxx obserwacyjna	HIS	HIS	-
19	Xxxxx wywiadu pielęgniarskiego	HIS	HIS	-
20	Raport pielęgniarski	-	HIS	-
	dokumenty nie wychodzące ze szpitala - brak konieczności wymiany pomiędzy jednostkami
21	Karta procesu sterylizacji	-	-	-
22	Karta kwalifikacyjna do zabiegu	HIS	HIS	-
23	Xxxxx xxxxxxxxx znieczulenia	HIS	HIS	-
24	Okołooperacyjna Karta Kontrolna	-	-	-
25	Karta zabiegów fizjoterapeutycznych	-	HIS	-
26	Karty TISS	-	-	-
27	Inne np. zgoda pacjenta na wykonanie badania lub zabiegu	-	-	HIS

Powyższe dokumenty w postaci elektronicznej mają charakter sformatowanych plików tekstowych
o niewielkim rozmiarze. Rozmiar każdego z nich nie jest ściśle określony ze względu na zmienność tekstów, które te dokumenty zawierają. Można szacować że ich rozmiar będzie ograniczony do kilkuset kilobajtów. Wszyscy partnerzy projektu zadeklarowali gotowość udostępniania oraz chęć korzystania z dokumentacji medycznej poprzez MSIM pod warunkiem że będzie to zgodne
z obowiązującymi przepisami prawa.

W poniższej tabeli wskazano szacowany roczny przyrost tekstowych danych medycznych
w [MB] przyjmując średnią wielkość pojedynczego dokumentu medycznego skonwertowanego do formatu pdf: 300kb uwzględniając liczbę pobytów oraz szacowaną częstość występowania danej dokumentacji. Przyjęto na potrzeby szacowania że zabiegi operacyjne dotyczą 6 % hospitalizacji (wyliczenia dokonano na podstawie danych statystycznych z 2007 roku).

	Podmiot	01	02	03
	Ilość hospitalizacji w roku	28000	15000	28000
	Roczny przyrost danych [MB]- priorytet 1
1	Formularz historii choroby	8400	4500	8400
2	Wywiad lekarski	8400	4500	8400
3	Epikryza	8400	4500	8400
4	Karta informacyjna z leczenia szpitalnego	8400	4500	8400
5	Opis przebiegu leczenia	8400	4500	8400
6	Wyniki badań laboratoryjnych – analityka	8400	4500	8400
7	Wyniki badan laboratoryjnych – bakteriologia	8400	4500	8700
8	Wyniki badań diagnostyki obrazowej – opis	8400	4500	45000
9	Wyniki konsultacji	8400	4500	8400
10	Protokół operacyjny	504	270	504
11	Karta zleceń lekarskich	8400	4500	8400
	dokumenty rzadko spotykane w HIS - priorytet 2
12	Wywiad epidemiologiczny	8400	4500	8400
13	Karta Oceny Ryzyka Zakażenia przy Przyjęciu do Szpitala	8400	4500	8400
14	Ocena ryzyka związanego ze stanem odżywienia	8400	4500	8400
	dokumenty pielęgniarskie - priorytet 3
15	Plan opieki	8400	4500	8400
16	Karta gorączkowa	8400	4500	8400
17	Karta indywidualnej opieki pielęgniarskiej	8400	4500	8400
18	Karta obserwacyjna	8400	4500	8400
19	Karta wywiadu pielęgniarskiego	8400	4500	8400
20	Raport pielęgniarski	8400	4500	8400

W poniższej tabeli wskazano roczny przyrost danych medycznych obrazowych w [GB]

L.P.	Podmiot	Roczny przyrost danych w [GB]
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	1900
	Szpital Specjalistyczny im. J. Dietla w Krakowie	8000
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	3000

Analiza systemów dziedzinowych u Partnerów Projektu oraz rodzajów przetwarzanej dokumentacji pokazuje, że podstawowym i często jedynym systemem dziedzinowym, który daje możliwość integracji w zakresie EDM, jest oprogramowanie klasy HIS. Dodatkowo analiza wskazała, że większość podstawowej dokumentacji medycznej jest możliwa do wyeksportowania z używanego oprogramowania klasy HIS.

3.6.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.6.1.Opieka serwisowa (ilość miesięcy do wygaśnięcia umowy)

X.X	Xxxxxxx	HIS	LIS	RIS	PACS
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	1	1	1	1
	Szpital Specjalistyczny im. J. Dietla w Krakowie	26	26	26	36
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	13	17	13	24

3.6.2.Opieka serwisowa (SLA – czas reakcji na błąd krytyczny w godzinach)

X.X	Xxxxxxx	HIS	LIS	RIS	PACS
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	48	48	48	48
	Szpital Specjalistyczny im. J. Dietla w Krakowie	8	8	8	12
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	24	24	24	24

3.6.3.Integracja z systemem HIS

L.P	Podmiot	LIS	RIS	PACS
	Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	Tak	Tak	Nie
	Szpital Specjalistyczny im. J. Dietla w Krakowie	Tak	Tak	Nie
	Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie Sp. z o.o.	Tak	Tak	Tak

3.6.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.7.Funkcjonalność Centrum Autoryzacji Podpisu Elektronicznego (CAPE)

Obecnie funkcjonująca w Centrum aplikacja PentaSCAPE RA-Service umożliwia uzyskanie certyfikatu na podstawie żądania w formacie PKCS#10. Nie ma określonych wymagań dot. zawartości żądania PKCS#10 (do certyfikatu pobierany jest jedynie klucz publiczny). CAPE obsługuje klucze i rozmiary zgodne z profilem certyfikatu użytego w PentaSCAPE Ra-Service do wystawienia certyfikatu.

Usługa umożliwiająca uzyskanie certyfikatu udostępniana jest poprzez interfejs WWW, w którym uwierzytelnianie odbywa się poprzez podanie loginu i hasła.

Usługa znakowania czasem realizowana jest za pomocą dostępnej przez protokół http aplikacji PentaSCAPE-TSAService i zgodna ze standardem RFC 3161.

Nie przeprowadzano testów wydajnościowych usługi. Aktualna wydajność usługi powinna być wystarczająca do planowanej skali systemu.

Ścieżka certyfikacyjna certyfikatu TSA obejmuje certyfikaty CA o nazwach wyróżniających: 'CN=RootCA, O=Województwo Małopolskie, C=PL' i 'CN=Centrum Autoryzacji w Małopolsce, O=Województwo Małopolskie, C=PL'.

Odpowiedzi OCSP podpisywane są kluczem dedykowanym. Nie przeprowadzano testów wydajnościowych usługi OCSP.

Usługa wydawania certyfikatów w centrum CAPE będzie dostępna bez ograniczeń licencyjnych.

Zamawiający zapewnia dostęp do interfejsu API umożliwiającego wykorzystanie CAPE w procesach autoryzacji dokumentów.

W załączniku 9B do SIWZ znajdują się wyciągi ze spisów treści dokumentacji CAPE, która zostanie udostępniona wybranemu Wykonawcy.

3.8.Lokalne słowniki dokumentów

Lokalne słowniki dokumentów w większości jednostek pokrywają się, ponieważ wynikają
z obowiązującego prawodawstwa. Wszystkie rodzaje dokumentów są zdefiniowane w ramach systemu HIS, choć dotyczą również danych pochodzących z innych systemów dziedzinowych (LIS, RIS). Różnice między dokumentami wynikają ze specjalizacji jednostek oraz nieprecyzyjnego dookreślenia formatu dokumentacji przez ustawodawcę. Ponadto w jednostkach używa się dokumentów medycznych opracowanych na potrzeby własne szpitala (np. w Szpitalu Specjalistycznym im. J. Dietla w Krakowie Karta Przymusu). Kluczowym elementem systemu będzie wymiana dokumentacji medycznej w zw. z czym jeżeli niezbędne będzie w celu wykonania poprawnej integracji dostosowanie/ujednolicenie istniejących słowników, formatów danych i standardów danych słownikowych składowanych i udostępnianych należy to uwzględnić i wykonać we wdrożeniu.

4.Model statyczny

System MSIM składa się z komponentu regionalnego i komponentu lokalnego.

Wykonawca musi wdrożyć komponent regionalny w Szpitalu Specjalistycznym im. Ludwika Rydygiera w Krakowie sp. z o.o.

Wykonawca musi wdrożyć komponenty lokalne w każdym Szpitalu uczestniczącym
w projekcie.

4.1.Komponent lokalny

Komponent lokalny składa się z następujących jednostek funkcjonalnych:

4.1.1.Repozytorium EDM

Repozytorium EDM to moduł odpowiedzialny za przyjmowanie i przechowywanie dokumentów medycznych z systemów źródłowych funkcjonujących w Szpitalach. Moduł ten odpowiada za gromadzenie, przetwarzanie EDM zgodnej ze standardem HL7 CDA R2 na 3-cim poziomie interoperacyjności,.

Repozytorium EDM musi wystawiać i obsługiwać interfejs przekazywania i rejestracji EDM zgodnie
z wytycznymi ITI-41 profilu integracyjnego XDS.b (nie dotyczy architektury wewnętrznej systemu).

Repozytorium EDM musi obsługiwać interfejs pozwalający na pobranie EDM uwierzytelnionemu użytkownikowi zgodnie z wytycznymi ITI-43 (nie dotyczy architektury wewnętrznej systemu).

Repozytorium EDM musi wspierać opcję (rozszerzenie) profilu integracyjnego XDS.b związaną
z obsługą asynchronicznej wymiany wiadomości (ang. „Asynchronous Web Services Exchange Option”).

4.1.2.Systemy dziedzinowe (źródłowe): HIS, LIS, RIS a MSIM

Systemy dziedzinowe to systemy informatyczne wspierające działalność leczniczą szpitala w tzw. części białej, które w kontekście niniejszego projektu stanowią źródło EDM. Systemy źródłowe (za wyjątkiem systemu HIS – w zakresie integracji pomiędzy lokalnym EDM, a HIS oraz e-Rejestracją z wykorzystaniem interfejsu opracowanego przez dostawcę HIS) nie są objęte w jakikolwiek sposób przedmiotem zamówienia. Ich dostosowanie do funkcjonowania zgodnie z zaproponowanymi interfejsami stanowi przedmiot odrębnych działań realizacyjnych.

Systemami dziedzinowymi w kontekście niniejszego projektu są systemy HIS, LIS, RIS i inne,
w których generowana jest EDM.

4.1.3.Usługa podpisu elektronicznego dla EDM

Usługa podpisu elektronicznego dla EDM musi obsługiwać funkcję podpisywania i weryfikacji podpisu elektronicznego związanego z wdrożonym systemem tożsamości z wykorzystaniem Centrum Autoryzacji (CAPE w Małopolsce).

Usługa podpisu elektronicznego musi być zgodna z funkcjonującą Polityką Certyfikacji CAPE
w Małopolsce.

Usługa musi integrować się z funkcjami CAPE w zakresie znakowania czasem oraz wykorzystania podpisu elektronicznego oraz pozostałych usług CAPE oraz wystawiać te usługi dla pozostałych komponentów Systemu MSIM, w tym repozytorium EDM, rejestru EDM oraz systemów dziedzinowych (w szczególności HIS).

4.1.4.Usługa buforowania dla klienta pobierania EDM

Usługa istnieje w celu pośredniczenia w asynchronicznym trybie pobierania EDM. Klient korzystający z usługi pobierania EDM w trybie asynchronicznym zamawia zgromadzenie EDM (np. z kilku różnych źródeł o znacznym wolumenie), a następnie usługa buforowania przejmuje w jego imieniu proces zgromadzenia EDM.

Usługa musi obsługiwać 2 interfejsy komunikacji:

• Push - w momencie wystąpienia zdarzenia zakończenia pobrania EDM wysyłany jest komunikat o gotowości do jej pobrania do zarejestrowanego klienta

• Pull – w momencie odebrania komunikatu od klienta wysyłana jest gotowa EDM lub
  w przypadku jej braku (np. trwa proces buforowania) zwracany jest komunikat o stanie procesu (np. procent i wolumen pobranych już danych w odniesieniu do całości)

Wymaga się aby nana etapie Analizy Przedwdrożeniowej, Wykonawca przedstawił możliwe warianty zapewnienia odporności do wyboru przez Zamawiającego na awarię w warstwie sieciowej (np. na zagrożenia typu przerwy w połączeniu).

4.2.Komponent regionalny

Komponent regionalny składa się z następujących jednostek funkcjonalnych:

4.2.1.Rejestr EDM

Rejestr EDM musi przechowywać scentralizowane informacje o miejscu składowania i fakcie wytworzenia wraz z informacją o wersjonowaniu wszystkich dokumentów medycznych
w podmiotach biorących udział w Projekcie.

Za pomocą odpowiednich interfejsów uwierzytelniony Użytkownik Systemu MSIM będzie mógł odpytać warstwę regionalną o dokumenty w innych jednostkach oraz pobrać je w całości lub częściowo.

Rejestr EDM musi obsługiwać interfejs ITI-42 w zakresie rejestracji EDM.

Rejestr EDM musi obsługiwać interfejs ITI-18 w zakresie obsługi zapytań od użytkowników Systemu MSIM.

4.2.2.Źródło identyfikacji pacjentów

Źródło identyfikacji pacjentów musi jednoznacznie określać tożsamość pacjenta na podstawie jego właściwości.

Źródło identyfikacji musi obsługiwać interfejs ITI-42 w zakresie rejestracji EDM.

Źródło identyfikacji musi obsługiwać interfejs ITI-18 w zakresie obsługi zapytań od użytkowników Systemu MSIM.

4.2.3.Usługa uwierzytelniania i autoryzacji użytkowników

System musi przechowywać tożsamości użytkowników Systemu MSIM, w tym personelu medycznego
i obsługi technicznej.

Musi przechowywać prawa dostępu użytkowników Systemu MSIM.

Musi umożliwiać dodawanie, modyfikowanie i usuwanie użytkowników.

Musi umożliwiać tworzenie grup użytkowników.

Grupy użytkowników związane ze struktura organizacyjną projektu (w tym Podmiotu) powinny być wprowadzone i skonfigurowane przed uruchomieniem Systemu MSIM oraz możliwe do edycji
w każdym momencie.

Określanie praw dostępu musi być możliwe na poziomie grup użytkowników.

Do nawiązywania zdalnych połączeń administracyjnych muszą być stosowane protokoły komunikacyjne zapewniające bezpieczne uwierzytelnianie oraz poufność i integralność przesyłanych danych.

Uwierzytelnianie w MSIM musi być oparte na PKI z CAPE w Małopolsce (Certificate Authority).
W szczególności uwierzytelnianie połączeń IPSec VPN ma być realizowane poprzez certyfikaty klientów VPN, wystawiane dla każdego z użytkowników indywidualnie przez CAPE (Centrum Autoryzacji podpisu elektronicznego). W zależności od uprawnień mogą być wystawiane osobne certyfikaty.

Uwierzytelniania w MSIM może być realizowane przy pomocy innych metod uwierzytelnienia tylko
w uzgodnieniu z Zamawiającym. W szczególności zakłada się, że uwierzytelnianie Pacjentów (klientów) usługi e-Rejestracja powinno odbywać się przy pomocy metody opartej na loginie/haśle.

Ważność certyfikatu musi być weryfikowana w CAPE on-line przy pomocy protokołu OCSP lub podobnego.

Bezpieczeństwo kluczy powinno być realizowane z wykorzystaniem Polityki Certyfikacji CA MSIM. Polityka certyfikacji powinna być oparta na RFC3647 “Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Framework”.

Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) 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ć:

1. Przeszukiwanie rejestru EDM,

2. Odpowiedź na zapytania o pozycję rejestru,

3. Zwracanie wyników zapytania,

Z uwzględnieniem praw dostępu użytkownika.

Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi.

4.2.5.Usługa pobierania EDM

Musi umożliwiać klientom(systemom klienckim) przesłanie zapytania do rejestru EDM zgodnie z wytycznymi ITI-18 profilu integracyjnego XDS.b.

Usługa musi umożliwiać:

4. Dostęp do repozytorium EDM,

5. Odpowiadać na zapytania o pozycję repozytorium,

6. Zwracać wyników zapytania,

7. Zamówienie EDM (pobranie w trybie asynchronicznym),

8. Odebranie EDM po wcześniejszym zamówieniu,

Z uwzględnieniem praw dostępu.

Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi.

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:

9. Przegląd listy usług możliwych do realizacji w placówce Zamawiającego dla pacjenta,

10. Przegląd listy usług możliwych do rezerwacji przez Internet,

11. Możliwość zdalnego zgłoszenia wniosku o rezerwację terminu usługi z preferowanymi terminami (zakres dat, dni tygodnia, przed południem, po południu): do Pracowni Diagnostycznej lub Gabinetu Xxxxxxxxxxx,

12. 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,

13. Udostępnienie danych o zaplanowanych wizytach i usługach,

14. Prezentacja informacji o stanie usługi (zaplanowana, anulowana, wykonana),

15. Możliwość wydruku potwierdzenia rezerwacji: data i godzina usługi, imię i nazwisko pacjenta, numer rezerwacji, miejsce wykonania usługi, informacje dodatkowe dla pacjenta,

16. Dostęp do informacji o lokalizacji miejsca wykonania usługi,

17. Możliwość odwołania rezerwacji.

18. Zmianę danych osobowych (imię, nazwisko, adres, nr telefonu, adres e-mail)

Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi.

4.2.7.Usługa komunikacji z P1 (IKP)

Usługa odpowiedzialna za komunikację z P1 zgodnie z wytycznymi i interfejsem platformy P1.

Usługa musi umożliwiać przetworzenie zapytania o EDM przez Pacjenta i wywołać odpowiednie usługi w systemie MSIM.

Usługa musi umożliwiać wyszukanie EDM uwierzytelnionemu w P1 Pacjentowi.

Usługa musi umożliwiać pobranie EDM uwierzytelnionemu przez P1 Pacjentowi.

Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi.

4.2.8.Usługa słownikowa

Celem funkcjonowania usługi słownikowej jest posiadanie jednolitej terminologii w EDM będącej przedmiotem wymiany w projekcie MSIM.

Usługa słownikowa pośredniczy w dostępie do słowników oferowanych przez platformę P1, tj.:

19. ICD-10,

20. ICD-9,

21. ICF,

22. ICNP

Usługa umożliwia klientom, w szczególności systemom dziedzinowym, na:

23. Wyszukanie pełno tekstowe terminu,

24. Wyszukanie nadrzędnego terminu (w drzewie taksonomicznym),

25. Wyszukanie listy podrzędnych terminów (w drzewie taksonomicznym),

26. Pobranie dowolnego poddrzewa słownika (np. wszystkich terminów podrzędnych dla danego terminu).

Wymagane jest opracowanie zarówno webowego jak i programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi.

4.2.9.Usługa synchronizacji rejestrów EDM

Usługa musi umożliwiać synchronizację regionalnego i lokalnych EDM.

Usługa musi umożliwiać synchronizację ręczną (na żądanie).

Usługa musi umożliwiać konfigurowania interwału synchronizacji przez administratora ze względu na czas i rodzaj zdarzenia (np. otrzymanie nowego zapisu od rejestru, przesłanie dokumentacji do repozytorium lub dowolnego interfejsu wystawianego na szynie usług – regionalnie lub lokalnie).

Wymagane jest opracowanie programowego (umożliwiającego wywołanie przez inne oprogramowanie) interfejsu do usługi.

4.2.10.Portal informacyjny

Portal informacyjny musi być aplikacją webową prezentującą informacje o projekcie, świadczonych usługach, uczestniczących partnerach.

Portal musi być narzędziem klasy CMS umożliwiającym dostosowywanie oraz dodawanie treści przez użytkowników po stronie Zamawiającego.

Portal musi posiadać możliwość dowolnej edycji i wprowadzania tekstu, w m. in. tym tworzenia podstron, linkowania, podłączanie zdjęć.

Portal musi posiadać szatę graficzną uzgodnioną i zaakceptowaną przez Zamawiającego.

Portal musi zawierać odnośniki do wszystkich usług systemu, stanowiąc centralny punkt dostępu do systemu MSIM.

Portal musi być zintegrowany ze stroną województwa małopolskiego, oznaczony logiem projektu oraz banerami wymaganymi przepisami UE.

Z portalu musi być możliwe przejście do wszystkich usługi w tym e-Rejestracji.

Na portalu udostępnione będą:

27. Informacje o jednostkach ochrony zdrowia, które są zintegrowane z MSIM w ramach projektu (w tym lista usług świadczony przez te podmioty)

28. Wyszukiwarka usług medycznych (wg typu usługi oraz wg jednostki ochrony zdrowia)

29. Dane kontaktowe do jednostek ochrony zdrowia (tel. do placówki, poszczególnych specjalistów, informacji, rejestracji)

30. 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)

31. Funkcjonalność umożliwiająca rejestrację oraz założenie konta

32. Informacje o projekcie MSIM

Wszystkie powyższe dane, opisy, grafiki, funkcjonalności do portalu wprowadzi Wykonawca.

4.2.11.Panel administratora

Panel zawiera wszystkie funkcje potrzebne do administracji Systemem MSIM dla uprawnionych użytkowników (administratorów).

Panel musi posiadać interfejs webowy.

Panel dostępny jest z poziomu komponentu regionalnego w strefie umożliwiającą bezpieczną pracę administracyjną.

Moduł w szczególności musi spełniać następujące funkcje:

33. dodawanie użytkowników,

34. nadawanie i modyfikacja uprawnień,

35. parametryzacja ustawień synchronizacji z innymi systemami,

36. dodawanie podmiotów,

37. konfiguracja modułów wymiany danych,

38. konfiguracja modułu e-Rejestracji,

39. 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:

40. ITI-41 w zakresie dostarczania i rejestrowania dokumentów w repozytorium,

41. ITI-42 w zakresie rejestrowania dokumentów w rejestrze

42. ITI-43 w zakresie pozyskiwania dokumentów z repozytorium

43. ITI-18 w zakresie zapytań do rejestru

44. ITI-8 oraz ITI-44 w zakresie identyfikacji pacjenta przez rejestr

wraz z rozszerzeniami przewidzianymi wytycznymi w sprawie reguł tworzenia i modelu transportowego EDM publikowanymi przez CSIOZ.

Warstwa regionalna komunikuje się z lokalną szyną usług lub bezpośrednio lokalnym EDM. Dopuszcza się również możliwość istnienia serwerów buforowania po obu stronach (wstępne przetwarzanie, redukcja pasma transferowego).

Konstrukcja warstwy integracyjnej w warstwie regionalnej z wykorzystaniem powyższych standardów
w zakresie usług wyszukiwania EDM w rejestrze (ITI-18) oraz pobierania EDM w repozytoriach (ITI-43) musi umożliwiać integrację z innymi systemami regionalnymi i lokalnymi w obszarze e-Zdrowia.

5.Model dynamiczny

5.1.Wprowadzenie

Analiza zakładów opieki zdrowotnej uczestniczących w projekcie, w tym analiza ich umocowania prawnego, rodzaju wykonywanej działalności, a także stan informatyzacji wykazany w audycie IT wskazuje, że najistotniejszymi z punktu widzenia projektowanego systemu procesami biznesowymi dla badanych Podmiotów są procesy związane z dwoma obszarami: obszarem przekazywania elektronicznej dokumentacji medycznej (EDM) oraz z obszaru elektronicznej usługi rejestracji. Z tego tytułu zdecydowano się na wskazanie następujących procesów biznesowych jako najistotniejszych dla badanych zakładów opieki zdrowotnej:

1. Wyszukiwanie elektronicznej dokumentacji medycznej,

2. Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym,

3. Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym,

4. Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z wykorzystaniem IKP,

5. Rezerwacja terminu wizyty,

6. Anulowanie rezerwacji terminu wizyty.

Niniejszy dokument przedstawia raport z analizy powyżej zidentyfikowanej listy procesów biznesowych.

5.2.Metoda opisu

Każdy z procesów biznesowych został przedstawiony w formie opisowej i graficznej.

5.2.1.Opis procesu

Pierwszą częścią opisu jest forma tabelaryczna. Opis procesu w tej części zawiera następujące informacje:

• Nazwa procesu – zawiera identyfikator procesu oraz nazwę właściwą procesu. Identyfikator proces został dodany do nazw procesu w celu umożliwienia i ułatwienia identyfikacji procesów na diagramach zbiorczych przedstawiający grupy procesów.

• Identyfikator procesu – unikalny identyfikator procesu umożliwiający identyfikację procesu
  w całości dokumentacji.

• Wersja procesu – numer kolejny wersji procesu.

• Cel procesu – przedstawia podstawowy cel procesu biznesowego.

• Uczestnicy procesu – przedstawia listę uczestników danego procesu, w tym systemy zewnętrzne (np. system P1 w zakresie IKP).

• Warunki wejściowe do procesu – zawiera listę warunków wejściowych do procesu biznesowego, w tym również dane wejściowe.

• Warunki wyjściowe z procesu – zawiera listę warunków wyjściowych, w tym dane wyjściowe
  z procesu biznesowego.

• Opis procesu - właściwy opis procesu przedstawiony w postaci kolejnych kroków procesu. Poszczególne kroki procesu opisane są w sposób narratywny; jednocześnie mają one swoje odpowiedniki w reprezentacji graficznej procesu, przy czym na diagramie ich nazwy są już skrócone. Jest to spowodowane z 2 względów. Po pierwsze w celu zachowania przejrzystości diagramu. Po drugie – nazwy na diagramie oznaczające czynności stanową równocześnie nazwy kluczowych przypadków użycia warunkujących funkcjonalności systemu informatycznego wspierającego realizację opracowanych procesów biznesowych.

5.2.2.Graficzna prezentacja procesu

Proces biznesowy opisany w postaci tabelarycznej został również przedstawiony w postaci graficznej. Zawiera ona poszczególne kroki procesu oraz przepływy informacji.

Diagram procesu został przygotowany z wykorzystaniem notacji BPMN. W poszczególnych diagramach zastosowano elementy graficzne przedstawione w poniższej tabeli.

Symbol	Opis symbolu
	Element symbolizujący proces biznesowy
	Element symbolizujący zdarzenie inicjujące proces biznesowy.
	Element symbolizujący koniec procesu biznesowego.
	Element symbolizujący zdarzenie pośrednie polegające na odbiorze komunikatu
	Element symbolizujący zdarzenie pośrednie polegające na wysłaniu komunikatu
	Element symbolizujący krok procesu biznesowego (wykonaną czynność, zwaną również aktywnością)
	Element symbolizujący przepływ informacji,, tzw. MessageFlow (zaznaczony w niektórych przypadkach jako nazwa relacji)
	Element symbolizujący bramkę decyzyjną (albo)
	Element symbolizujący bramkę równoległą (i)
	Element symbolizujący bramkę LUB
	Element symbolizujący zbiór (rejestr) danych

5.2.3.Grupy procesów

Opracowane procesy biznesowe są tematycznie pogrupowane i przedstawione wspólnie na diagramach. Bezpośrednią zależność procesów przedstawiono na diagramach za pomocą związków w postaci przerywanych strzałek - tak jak to pokazano poniżej.

5.3.Mapa główna procesów biznesowych

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.

Analizowane procesy biznesowe zostały zgrupowane w 2 grupy: procesy związane z obszarem przekazywania elektronicznej dokumentacji medycznej (EDM) oraz z obszarem e-Rejestracji.

5.4.Przekazywanie EDM

Szczegółowa mapa procesów biznesowych w obszarze przekazywania EDM przedstawia informacje
o procesach biznesowych związanych z typowymi operacjami dotyczącymi elektronicznej dokumentacji medycznej. Model obejmuje procesy wyszukiwania i pobierania elektronicznej dokumentacji pacjenta zgromadzonej w jednostkach opieki zdrowotnej zintegrowanych z MSIM.

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	Pracownik medyczny wprowadza kryterium wyszukiwania elektronicznej dokumentacji medycznej (EDM) pacjenta podając, co najmniej, dane 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
Warunki wyjściowe	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.

5.4.2.BP.ERP.002 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym

Nazwa procesu	BP.ERP.002 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym
Numer procesu	BP.ERP.002
Wersja procesu	1
Cel procesu	Celem niniejszego procesu jest pobranie EDM dla pacjenta oraz jej zapisanie w lokalnym systemie
Uczestnicy procesu	pracownicy medyczni, komponent lokalny, komponent regionalny
Warunki wejściowe	Istnieje kanał komunikacyjny pomiędzy podmiotami. Znane są dane pacjenta i pobieranej EDM. Pracownik medyczny ma prawo do pobrania elektronicznej dokumentacji medycznej pacjenta. Zgoda pacjenta na udostępnienie danych elektronicznej dokumentacji medycznej.
Opis procesu	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
Warunki wyjściowe	Elektroniczny dokument medyczny lub ich zbiór zostaje zaprezentowany pracownikowi medycznemu.

Poniżej przedstawiono postać graficzną procesu biznesowego.

5.4.3.BP.ERP.003 Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym

Nazwa procesu	BP.ERP.003 Pobranie elektronicznej dokumentacji medycznej w trybie asynchronicznym
Numer procesu	BP.ERP.003
Wersja procesu	1
Cel procesu	Celem niniejszego procesu jest pobranie EDM dla pacjenta oraz jej zapisanie w lokalnym systemie
Uczestnicy procesu	pracownicy medyczni, lokalne systemy dziedzinowe, komponent regionalny
Warunki wejściowe	Istnieje kanał komunikacyjny pomiędzy podmiotami. Znane są dane pacjenta i pobieranej EDM. Pracownik medyczny ma prawo do pobrania elektronicznej dokumentacji medycznej pacjenta. Zgoda pacjenta na udostępnienie danych elektronicznej dokumentacji medycznej.
Opis procesu	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 na podstawie danych identyfikacyjnych EDM lub ich zbiór zestawia połączenie z odpowiednim repozytorium EDM Komponent regionalny zwraca komunikat do klienta o przekazaniu żądania pobrania EDM wraz z przekazaniem tokena żądania w celu późniejszego pobrania EDM Komponent regionalny pobiera z repozytorium EDM żądane pozycje Komponent regionalny na podstawie uzyskanych odpowiedzi buduje zbiór wynikowy odpowiedzi i zgłasza go do odbioru Wpływa zapytanie od klienta zawierające token żądania Komponent regionalny zwraca żądane pozycje do klienta
Warunki wyjściowe	Elektroniczny dokument medyczny lub ich zbiór zostaje zaprezentowany pracownikowi medycznemu.

Poniżej przedstawiono postać graficzną procesu biznesowego.

5.4.4.BP.ERP.004 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z wykorzystaniem IKP

Nazwa procesu	BP.ERP.004 Pobranie elektronicznej dokumentacji medycznej w trybie synchronicznym z wykorzystaniem IKP
Numer procesu	BP.ERP.004
Wersja procesu	1
Cel procesu	Xxxxx niniejszego procesu jest pobranie EDM dla pacjenta korzystającego z IKP
Uczestnicy procesu	System P1, komponent lokalny, komponent regionalny
Warunki wejściowe	Istnieje kanał komunikacyjny pomiędzy podmiotami. Znane są dane pacjenta i pobieranej EDM. Użytkownik systemu P1 ma prawo do pobrania elektronicznej dokumentacji medycznej pacjenta. Zgoda pacjenta na udostępnienie danych elektronicznej dokumentacji medycznej.
Opis procesu	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. 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 systemu IKP
Warunki wyjściowe	Elektroniczny dokument medyczny lub ich zbiór zostaje przekazany do systemu IKP

Poniżej przedstawiono postać graficzną procesu biznesowego.

5.5.e-Rejestracja

Szczegółowa mapa procesów biznesowych w obszarze e-Rejestracji obejmuje procesy związane
z usługą e-Rejestracja.

Rysunek 13 Mapa procesów biznesowych w obszarze e-Rejestracji

Usługa udostępnia funkcjonalność rezerwacji usług medycznych w jednostkach ochrony zdrowia zintegrowanych z MSIM. Użytkownik ma możliwość rejestracji na wskazany termin i anulowania wizyty. Z e-Rejestracji mogą korzystać wyłącznie zarejestrowani na poziomie regionalnym Użytkownicy Końcowi (pacjenci).

W ramach usługi zostanie wykonany system komunikatów (powiadomień dla użytkowników końcowych w formie: wiadomości e-mail oraz dodatkowo System MSIM musi być przygotowany do realizacji usługi wysyłania powiadomień SMS. Zamawiający podczas użytkowania systemu będzie miał możliwość wyboru, która forma powiadomień będzie realizowana z poziomu panelu administracyjnego) dotyczących: potwierdzenia rejestracji, zbliżającego się terminu wizyty, anulowania wizyty oraz zmiany terminu wizyty (zarówno przez użytkownika jak i w lokalnym systemie medycznym HIS).

5.5.1.PB.REJ.01 Rezerwacja terminu wizyty

Nazwa procesu	Rezerwacja terminu wizyty
Numer procesu	PB.REJ.01
Wersja procesu	1
Cel procesu	Celem procesu jest rejestracja wizyty pacjenta w ramach eUsługi - rejestracja jest wykonywana w lokalnym systemie HIS.
Uczestnicy procesu	Komponent regionalny, lokalne systemy dziedzinowe, użytkownicy końcowi(pacjenci).
Warunki wejściowe	Istnieje kanał komunikacyjny pomiędzy warstwą regionalną a warstwą lokalną. Użytkownik posiadający konto użytkownika końcowego jest zalogowany do systemu.
Opis procesu	1) Zalogowany użytkownik końcowy w warstwie regionalnej wskazuje okres świadczenia (symbolicznie, np. wtorek do południa) na konkretną usługę realizowaną (przez konkretny personel) w konkretnym miejscu. 2) Użytkownik wybiera formularz rejestracji. 3) Komponent regionalny przekazuje żądanie zablokowania terminu wizyty do odpowiedniego Podmiotu. 4) System lokalny HIS blokuje wskazany termin dla wybranej usługi (ewentualnie w połączeniu z personelem lub komórką organizacyjną). 5) Użytkownik wypełnia formularz rejestracji. Zawartość formularza jest uzależniona od jednostki ochrony zdrowia i typu usługi. Formularz jest wstępnie wypełniony przez system danymi pobranymi z konta użytkownika oraz uzupełniony o dane wynikające z wybranej przez użytkownika usługi. Komponent regionalny sprawdza kompletność i poprawność wypełnienia formularza rejestracji i informuje o efekcie kontroli użytkownika. Użytkownik poprawia zgłoszone błędy. 6) Warstwa regionalna weryfikuje kolizje rezerwacji. Sprawdzane jest, czy istnieją jakieś rezerwacje na ten sam dzień i na tę samą godzinę, co wskazany termin. 7) Jeżeli wystąpiła kolizja, to Komponent regionalny informuje o tym użytkownika i kończy proces rezerwacji terminu wizyty. Jednocześnie warstwa regionalna wysyła do warstwy lokalnej żądanie zwolnienia zablokowanego terminu. System lokalny odblokowuje wskazany termin wizyty. 8) Jeśli wybrany termin jest poprawny, to użytkownik otrzymuje możliwość ostatecznego potwierdzenia wysłania rezerwacji albo anulowania rezerwacji wybranego terminu. 9) Jeżeli użytkownik zrezygnuje z rezerwacji wskazanego terminu wizyty, to warstwa regionalna wysyła do warstwy lokalnej żądanie zwolnienia zablokowanego terminu. System lokalny odblokowuje wskazany termin wizyty. 10) Jeśli użytkownik potwierdzi rezerwację, to system regionalny wysyła do odpowiedniego Podmiotu dane wymagane do zarejestrowania pacjenta. 11) Lokalny system HIS weryfikuje otrzymane dane pod kątem możliwości zapisania w HIS rejestracji dla określonego pacjenta. 12) Jeśli przesłane dane nie umożliwiają rejestracji pacjenta na wybraną usługę, to system lokalny przesyła do warstwy regionalnej informację o odrzuceniu rezerwacji i odblokowuje wskazany termin wizyty. 13) Jeżeli weryfikacja przesłanych danych przebiegnie pomyślnie, to system lokalny rezerwuje wskazany termin wizyty i wysyła do komponentu regionalnego potwierdzenie przyjęcia rejestracji. 14) Warstwa regionalna informuje użytkownika o przyjęciu rezerwacji terminu wizyty i zapisuje rejestrację w danych przechowywanych na jego koncie. 15) W zależności od konfiguracji komponent regionalny wysyła do użytkownika końcowego powiadomienia potwierdzające rejestrację w postaci wiadomości SMS i/lub e-mail. 16) W przypadku braku informacji zwrotnej od warstwy lokalnej, z potwierdzeniem lub odrzuceniem rejestracji, warstwa regionalna informuje o tym użytkownika i jednocześnie wysyła do skutku dane rezerwacji do lokalnego systemu HIS.
Warunki wyjściowe	W lokalnym systemie medycznym HIS zostaje zapisana rezerwacja terminu wizyty na wybraną usługę medyczną. W danych historii rejestracji na koncie użytkownika końcowego zostaje zapisana rezerwacja.

Poniżej przedstawiono postać graficzną procesu biznesowego.

5.5.2.PB.REJ.02 Anulowanie rezerwacji terminu wizyty

Nazwa procesu	Anulowanie rezerwacji terminu wizyty
Numer procesu	PB.REJ.02
Wersja procesu	1
Cel procesu	Celem procesu jest anulowanie rezerwacji wizyty w ramach eUsługi.
Uczestnicy procesu	Komponent regionalny, lokalne systemy dziedzinowe, użytkownicy końcowi(pacjenci).
Warunki wejściowe	Istnieje kanał komunikacyjny pomiędzy warstwą regionalną a warstwą lokalną. Użytkownik posiadający konto użytkownika końcowego jest zalogowany do systemu. W lokalnym systemie medycznym HIS istnieje zapisana rezerwacja terminu wizyty na usługę medyczną.
Opis procesu	1) Zalogowany użytkownik, chcący anulować rezerwację wskazanej wizyty, wybiera opcję anulowania. 2) Użytkownik zatwierdza decyzję o rezygnacji z wizyty we wskazanym terminie. 3) Warstwa regionalna wyświetla informację o anulowaniu wizyty i przekazuje do odpowiedniego Podmiotu żądanie anulowania rejestracji w lokalnym systemie HIS. 4) System lokalny anuluje wskazaną rejestrację i przekazuje do warstwy regionalnej potwierdzenie anulowania. 5) W wyniku potwierdzenia system regionalny zmienia status rejestracji w danych rejestracji. 6) W zależności od konfiguracji warstwa regionalna wysyła do użytkownika końcowego powiadomienia o anulowaniu wizyty w postaci wiadomości SMS i/lub e-mail.
Warunki wyjściowe	Rezerwacja terminu wizyty na usługę medyczną w lokalnym systemie medycznym HIS zostaje anulowana. W danych historii rejestracji na koncie użytkownika końcowego status rezerwacji wskazanej do anulowania zostaje ustawiony na wartość „Anulowana”.

Poniżej przedstawiono postać graficzną procesu biznesowego.

6.Wymagania Systemu MSIM

6.1.Wymagania ogólne

1. Cały dostarczony sprzęt musi być fabrycznie nowy, tzn. nieużywany przed dniem dostarczenia.

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.

3. Cały dostarczony sprzęt i oprogramowanie musi zawierać wszelkie niezbędne licencje do realizacji założonych funkcjonalności na czas nieograniczony.

4. Wszelkie aplikacje internetowe/intranetowe muszą działać w technologii co najmniej trójwarstwowej z wyodrębnionymi co najmniej warstwami :

   1. Bazy danych

   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.

   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.

5. Architektura rozwiązania e-usług ma się składać z co najmniej następujących elementów logicznych:

   1. Broker informacji (jako element regionalnej szyny usług),odpowiedzialny za propagowanie zapytań o dane oraz udzielanych odpowiedzi pomiędzy poszczególnymi jednostkami ochrony zdrowia a MSIM,

6. Broker odpowiada za:

   1. przekazanie komunikatu zawierającego pytanie do wskazanej jednostki.

   2. przekazanie uzyskanej odpowiedzi do jednostki, która zadała pytanie.

   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.

7. System musi umożliwiać wydajną, efektywną i ergonomiczną pracę dla jednocześnie zalogowanych minimum 2100 użytkowników bez utraty wydajności.

8. Dostarczone urządzenia powinny posiadać certyfikat(oznaczenie) CE (Conformité Européenne).

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.

10. Eksport danych z bazy i Repozytorium EDM nie będzie wymagał poniesienia żadnych dodatkowych kosztów przez Zamawiającego na rzecz Wykonawcy.

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.

12. Nowe wersje produktu nie mogą odbierać możliwości korzystania ze wsparcia
    z poprzednich wersji w okresie długości ich życia.

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.

14. Wykonawca musi przeprowadzić wizję lokalną w celu uszczegółowienia zakresu prac adaptacyjnych w serwerowniach Partnerów.

6.2.Wymagania ogólne interfejsu użytkownika

Nr funkcjonalności	Funkcjonalność
IU.1	Interfejs użytkownika
IU.1.1	Wszystkie aplikacje wchodzące w skład systemu MSIM muszą posiadać spójny wygląd.
IU.1.2	System musi być dostępny dla użytkownika w języku polskim (może nie dotyczyć narzędzi administracyjnych firm trzecich, w których dopuszcza się interfejs w języku angielskim).
IU.1.3	Zamawiający wymaga aby dostęp do elementów systemu dostępnych przez przeglądarkę internetową mógł być realizowany z minimum następujących przeglądarek: Mozilla Firefox, Google Chrome, Internet Explorer. Wymagane jest, aby wskazane elementy systemu posiadały możliwość dostosowywania do pojawiających się w przyszłości nowych wersjach wskazanych przeglądarek internetowych przez okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego.

6.3.Wymagania prawne, organizacyjne i funkcjonalne

Umowy z dostawcami oprogramowania wykluczają samowolne zmiany struktur danych oraz dostęp do nich spoza aplikacji licencjodawców. Dlatego jakiekolwiek pobieranie danych z systemów dziedzinowych musi być realizowane za pośrednictwem narzędzi dostarczanych przez producentów oprogramowania dziedzinowego. Wymiana danych odbywa się wyłącznie za pośrednictwem webserwisów dostarczanych przez producentów zgodnie ze specyfikacją w Załączniku 9A.Dokumentacja medyczna podlega szczególnej ochronie wynikającej z ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych. Jak wynika z jej przepisów dane szczególnie wrażliwe, jakimi są dane o stanie zdrowia, kodzie genetycznym, nałogach lub życiu seksualnym, nie mogą być przetwarzane w przypadkach innych niż wymienione w ustawie. Istotne dla omawianego zagadnienia jest dopuszczenie przetwarzania tych danych, jeżeli osoba, której dane dotyczą wyrazi zgodę na przetwarzanie (zgoda musi być wyrażona na piśmie).Jeżeli przepisy innych ustaw zezwalają na przetwarzanie tych danych bez zgody tej osoby, stwarzając jednocześnie pełne gwarancje ich ochrony oraz jeżeli jest ono prowadzone w celu ochrony stanu zdrowia, świadczenia usług medycznych lub leczenia pacjentów przez osoby trudniące się zawodowo leczeniem lub świadczeniem innych usług medycznych, zarządzenia udzielaniem usług medycznych i zapewniono pełne gwarancje ochrony tych danych. Ograniczenia nie dotyczą jednak zbiorczej dokumentacji medycznej, anonimizowanych danych, uniemożliwiających zidentyfikowanie podmiotu, którego dotyczą. Przepisy te, pozwalające na przetwarzanie dokumentacji medycznej we wskazanych wyżej warunkach, umożliwiają funkcjonowanie systemów zarówno regionalnych, jak i lokalnych. Istotny z punktu widzenia ochrony danych osobowych wymóg wprowadza jednak ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowie w artykule 35, stanowiąc, że usługobiorca może nie wyrazić zgody na przetwarzanie jego jednostkowych danych medycznych w module statystyczno – rozliczeniowym Systemu Informacji Medycznej.

Dane przechowywane są przez wskazane w przepisach podmioty, ponadto ustawa o ochronie danych osobowych wprowadza możliwość outsourcingu. Zgodnie z art. 31 ust. 1: Administrator danych może powierzyć innemu podmiotowi, w drodze umowy zawartej na piśmie, przetwarzanie danych. Umowa ta musi być zawarta na piśmie i powinna szczegółowo określać zakres i cel przetwarzania tych danych.

Repozytoria EDM, prowadzone przez szpitale, będą gromadzić dane dotyczące usługobiorców, udzielonych, udzielanych i planowanych świadczeniach opieki zdrowotnej. Zgodnie z art. 24 ustawy
z dnia 6 listopada 2008 r. prawach pacjenta i Rzeczniku Praw Pacjenta podmiot udzielający świadczeń zdrowotnych jest obowiązany prowadzić, przechowywać i udostępniać dokumentację medyczną w sposób określony w ustawie oraz zapewnić ochronę danych zawartych w tej dokumentacji. Artykuł 25 tej ustawy wskazuje, że dokumentacja ta powinna zawierać, co najmniej:

1. Oznaczenie usługobiorcy, pozwalające na ustalenie jego tożsamości:

   1. Nazwisko i imię (imiona),

   2. Datę urodzenia,

   3. Oznaczenie płci,

   4. Adres miejsca zamieszkania,

   5. 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ść,

   6. W przypadku gdy pacjentem jest osoba małoletnia, całkowicie ubezwłasnowolniona lub niezdolna do świadomego wyrażenia zgody – nazwisko i imię (imiona) przedstawiciela ustawowego oraz adres jego miejsca zamieszkania;

2. oznaczenie podmiotu udzielającego świadczeń zdrowotnych ze wskazaniem komórki organizacyjnej, w której udzielono świadczeń zdrowotnych;

3. opis stanu zdrowia pacjenta lub udzielonych mu świadczeń zdrowotnych;

4. datę sporządzenia.

Przepisy te dają podstawy prawne do gromadzenia na bieżąco przez lokalne repozytoria wytwarzanej na bieżąco elektronicznej dokumentacji medycznej. Szczegółowy zakres gromadzonej przez szpitale dokumentacji wskazuje Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania w paragrafie 12, wyróżniając dokumentację indywidualną wewnętrzną, dokumentację zbiorczą wewnętrzną, dokumentację indywidualną zewnętrzną oraz dokumentację zbiorczą zewnętrzną. Mówi ono również
o wymaganiach dotyczących prowadzenia dokumentacji w postaci elektronicznej (rozdział 8). System teleinformatyczny, w jakim prowadzona jest dokumentacja powinien zapewniać:

1. zabezpieczenie dokumentacji przez uszkodzeniem lub utratą,

2. zachowanie integralności i wiarygodności dokumentacji,

3. stały dostęp do dokumentacji dla osób uprawnionych oraz zabezpieczenie przed dostępem osób nieuprawnionych,

4. identyfikację osoby udzielającej świadczeń zdrowotnych i rejestrowanych przez nią zmian,
   w szczególności dla odpowiednich rodzajów dokumentacji przyporządkowanie cech informacyjnych, zgodna z §10 ust. 1 pkt 3 lit. a-d,

5. udostępnienie, w tym przed eksport w postaci elektronicznej dokumentacji albo części dokumentacji będącej formą dokumentacji określonej w rozporządzeniu, w formacie XML
   i PDF,

6. eksport całości danych w formacie XML, w sposób zapewniający możliwość odtworzenia tej dokumentacji w innym systemie teleinformatycznym,

7. wydrukowanie dokumentacji w formach określonych w rozporządzeniu.

Zgodnie z założeniami, jedną z funkcjonalności lokalnego repozytorium EDM powinno być udostępnianie na bieżąco dokumentacji uprawnionym podmiotom. Jak wynika z ustawy
o prawach pacjenta i Rzeczniku Praw Pacjenta, podmiotami tymi są przede wszystkim podmioty udzielające świadczeń zdrowotnych (dokumentacja jest im udostępniana, o ile jest to niezbędne do zapewnienia ciągłości leczenia), a także organy władzy publicznej, Narodowy Fundusz Zdrowia, organy samorządu zawodów medycznych oraz konsultanci krajowi i wojewódzcy, w zakresie, w jakim jest to niezbędne do wykonywania przez nie swych zadań. Dopuszczalne jest również udostępnianie dokumentacji podmiotom, które na mocy art. 119 ust. 1 i 2 ustawy z dnia 15 kwietnia 2011 r.
o działalności leczniczej przeprowadzają kontrolę na zlecenie ministra do spraw zdrowia (x.xx. wojewoda, konsultanci krajowi, jednostki organizacyjnie podległe lub nadzorowane przez ministra do spraw zdrowia). Pozostałe podmioty, którym jednostki lokalne mogą udostępniać dokumentację są wymienione enumeratywnie w art. 26 ustawy o prawach pacjenta i Rzeczniku Praw Pacjenta. Nie wszystkie jednak są uprawnione do dostępu do dokumentacji w tym samym stopniu – w większości przypadków ograniczone jest to do zakresu, jaki jest niezbędny do zrealizowania powierzonych im zadań. Wspomniane wyżej wymagania dla systemów teleinformatycznych, w których prowadzona jest dokumentacja elektroniczna (Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania) gwarantują możliwość udostępniania dokumentacji za pośrednictwem systemu. Dodatkowo Rozporządzenie określa, że takie udostępnianie uprawnionym podmiotom i organom ma nastąpić bez zbędnej zwłoki.

Ponadto ustawa z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych nakłada na świadczeniodawców działających w ramach umów z Narodowym Funduszem Zdrowia obowiązek gromadzenia i przekazywania do Funduszu danych dotyczących udzielanych świadczeń. Szczegółowo regulują to wydane na jej podstawie rozporządzenia: w sprawie zakresu niezbędnych informacji gromadzonych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeń ze środków publicznych (na podstawie art. 190 ust. 1) oraz w sprawie zakresu niezbędnych informacji gromadzonych w systemie informatycznym Narodowego Funduszu Zdrowia oraz zakresu
i sposobu ich przekazywania ministrowi właściwemu do spraw zdrowia oraz wojewodom i sejmikom województw (na podstawie art. 190 ust. 3). Precyzują one, co ma znajdować się w rejestrach świadczeń zdrowotnych oraz podają zakres informacji przekazywanych ministrowi właściwemu do spraw zdrowia, Narodowemu Xxxxxxxxxx Xxxxxxx, innemu podmiotowi zobowiązanemu do finansowania świadczeń ze środków publicznych, a także wojewodom i sejmikom województw.

Na przełomie roku 2013 i 2014 CSIOZ wydało wytyczne w zakresie przetwarzania, gromadzenie
i udostępniania EDM. W kontekście Projektu do najważniejszych z nich należą:

• Reguły tworzenia i model transportowy EDM (dostępny na stronie xxxxx://x0.xxxxx.xxx.xx/0/Xxxxxx/xxxxxXxxxxXxxxxXxxxxx/000),

• Wytyczne dla systemu bezpiecznego przetwarzania EDM (dostępny na stronie xxxx://xxxxx.xxx.xx/xxxxxXxxxxx.xxx?xxx000),

• Polska Implementacja Krajowa HL7 CDA (pl-cda-) (dostępny na stronie xxxx://xxx.xxxxx.xxx.xx/XX0XXX/xx-xxx-xxxx-xx-XX/),

• Reguły biznesowe i walidacyjne dla Elektronicznej Dokumentacji Medycznej (dostępny na stronie xxxx://xxx.xxxxx.xxx.xx/xxxx.xxx?xxx0x/Xxxx),

• Model Transportowy danych o zdarzeniach medycznych (dostępny na stronie xxxx://xxx.xxxxx.xxx.xx/xxxxxxxxxx.xxx?xxx00),

• Opis hierarchii węzłów ISO OID w Regułach EDM (dostępny na stronie xxxx://xxx.xxxxx.xxx.xx/xxxx.xxx?xxx0x/Xxxx),

• Wytyczne, zasady i rekomendacje dotyczące bezpiecznego przetwarzania EDM (dostępny na stronie xxxx://xxx.xxxxx.xxx.xx/xxxx.xxx?xxx0x/XXXx),

• Zbiór: xxxx://xxx.xxxxx.xxx.xx/xxxxxx.xxx.

Reguły tworzenia i model transportowy EDM opisują zasady tworzenia i przekazywania EDM do platformy P1. W szczególności wprowadzają profil XDS.b jako obowiązujący przy wymianie EDM, przy czym istotnemu rozszerzeniu ulegają elementy profilu XDS.b w zakresie obsługi zdarzeń medycznych. Istotność rozszerzenia polega na tym, że czysty profil XDS.b jest systemem wymiany dokumento-centrycznym, w którym podstawowym elementem wymiany pozostaje dokument. Polskie rozszerzenia profilu XDS.b wprowadzone przez CSIOZ zmieniają ten model co do istoty na model zdarzenio-centryczny, w którym podstawową jednostką wymiany są dane o zdarzeniach. Wystąpienie zdarzenia może pociągać ze sobą powstanie i przesłanie dokumentu, ale nie musi.

Wytyczne dla systemu bezpiecznego przetwarzania EDM przedstawiają wytyczne i rekomendacje dla usługodawców w zakresie budowania i stosowania systemu bezpiecznego przetwarzania EDM. Ich wykorzystanie powinno mieć charakter wybiórczy, w zależności od wybranego wariantu realizacji systemu bezpieczeństwa.

Z wyżej przywołanych przepisów wywnioskować można, że repozytorium lokalne może komunikować się z indeksem regionalnym (tzw. rejestrem EDM), o ile spełnione będą warunki dotyczące bezpieczeństwa samego systemu teleinformatycznego oraz zasad i okoliczności udostępniania określonych danych.

Udostępnianie dokumentacji medycznej w postaci elektronicznej za pośrednictwem MSIM będzie wymagało uwiarygodnienia jej poprzez podpis elektroniczny. Będzie się to wiązało z opracowaniem odpowiednich procedur oraz wyposażeniem personelu medycznego w narzędzia umożliwiające realizację podpisu, jeżeli taki nie będzie już wdrożony.

Wdrożenie MSIM w szpitalach będzie wiązało się z koniecznością wprowadzenia procedur nadawania, modyfikacji i odbierania uprawnień personelowi medycznemu w zakresie danych udostępnianych w ramach MSIM.

System MSIM musi być zgodny z następującymi standardami, aktami prawnymi, normami oraz wytycznymi CSIOZ.

Standardy branżowe:

1. IHE Cross-Enterprise Document Sharing (XDS), w szczególności profil integracyjny, który standaryzuje rozdzielność 4 bytów ze względu na różną odpowiedzialność: repozytorium dokumentów, rejestr dokumentów, systemy źródłowe dokumentów, konsumentów dokumentów. W ramach zgodności z XDS przewiduje się zgodność z następującymi wytycznymi standardu XDS.b:

   1. ITI-41 w zakresie dostarczania i rejestrowania dokumentów w repozytorium,

   2. ITI-42 w zakresie rejestrowania dokumentów w rejestrze,

   3. ITI-43 w zakresie pozyskiwania dokumentów z repozytorium,

   4. ITI-18 w zakresie zapytań do rejestru,

   5. ITI-8 oraz ITI-44 w zakresie identyfikacji pacjenta przez rejestr.

2. HL7 CDA R2 na 3-cim poziomie interoperacyjności, który standaryzuje strukturę dokumentów elektronicznych

Standardy funkcjonalne:

1. SOA, w tym zawieranie funkcjonalności związanych z integracją w postaci adapterów
   i wystawianych w postaci usług oraz stosowanie standardów:

   1. WSDL w zakresie specyfikacji interfejsów,

   2. XML w zakresie języka strukturalnego,

   3. PSOAP w zakresie standardu przesyłania komunikatów,

   4. Szyn usługowych w zakresie warstwy integracji.

2. WS-Security w zakresie projektowania i realizacji usług bezpieczeństwa, w tym:

   1. SAML dla uwierzytelniania i autoryzacji użytkowników.

3. Metodyka PRINCE2 w zakresie zarządzania projektem.

Akty prawne:

• Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz.U. 2011 r. Nr 113 poz. 657, z późn. zm.).

• Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. 2013 nr 0 poz. 1114).

• Ustawa z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych (Dz.U. 2008 r. Nr 164 poz. 1027, z późn. zm.).

• Ustawa z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym (Dz.U. 2013 r. Nr 0 poz.757).

• Ustawa z dnia 15 kwietnia 2011 r. o działalności leczniczej (Dz.U. 2013 r. Nr 0, poz. 217).

• Ustawa z dnia 6 września 2001 r. prawo farmaceutyczne (Dz.U. 2008 r. Nr 45 poz. 271, z późn. zm.).

• Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. 2012 r. Nr 0 poz. 159).

• Ustawa z dnia 5 grudnia 1996 r. o zawodach lekarza i lekarza dentysty (Dz.U. 2011 r. Nr 277 poz. 1634).

• Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. 2014 r. Nr 0 poz. 1114).

• Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U. 2014 r. Nr 0 poz. 1182).

• Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. 2010 r. Nr 182 poz. 1228).

• Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. 2013 r. Nr 0 poz. 262).

• Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U. 2011 r. Nr 206 poz. 1216, z późn. zm.).

• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji
  w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2012 r. Nr 0 poz. 526).

• Rozporządzenie Ministra Zdrowia z dnia 25 marca 2013 r. w sprawie klasyfikacji danych
  i systemu kodów w Systemie Informacji Medycznej (Dz.U. 2013 r. Nr 0 poz. 473).

• Rozporządzenie Ministra Zdrowia z dnia 28 marca 2013 r. w sprawie wymagań dla Systemu Informacji Medycznej (Dz.U. 2013 r. Nr 0 poz. 463).

• Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010 r. w sprawie rodzajów
  i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U. 2014 r. Nr 0 poz. 177 z późn. zm.).

• Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r.
  w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych
  i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. 2004 r. Nr 100 poz. 1024).

• Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U. 2006 r. Nr 206 poz. 1518).

• Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 6 maja 2014 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz.U. 2014 Nr 0 poz. 584).

• Rozporządzenie Ministra Spraw Wewnętrznych i administracji z dnia 18 maja 2011 r.
  w sprawie rodzaju i zakresu oraz sposobu przetwarzania dokumentacji medycznej
  w zakładach opieki zdrowotnej utworzonych przez ministra właściwego do spraw wewnętrznych (Dz.U. 2011 r. Nr 125, poz. 712).

• Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 5 czerwca 2014 r. w sprawie zasad potwierdzania, przedłużania ważności, unieważniania oraz wykorzystania profilu zaufanego elektronicznej platformy usług administracji publicznej (Dz. U. 2014 nr 0 poz. 778).

• Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 18 maja 2011 r.
  w sprawie rodzaju i zakresu oraz sposobu przetwarzania dokumentacji medycznej
  w zakładach opieki zdrowotnej utworzonych przez ministra właściwego do spraw wewnętrznych (Dz.U. 2011 r. Nr 125 poz. 712).

• Dyrektywa 95/46/We Parlamentu Europejskiego i Rady z 24 października 1995 r.
  w sprawie ochrony osób fizycznych w zakresie przetwarzania danych osobowych
  i swobodnego przepływu tych danych do spraw wewnętrznych.

Normy:

• Norma PN-EN 13606-4:2009 Informatyka w ochronie zdrowia - Przesyłanie elektronicznej dokumentacji zdrowotnej - Część 4: Bezpieczeństwo danych.

• Norma PN-EN ISO 13606-5:2010 - Informatyka w ochronie zdrowia -- Przesyłanie elektronicznej dokumentacji zdrowotnej -- Część 5: Specyfikacja interfejsu.

• Norma PN-ISO/IEC 27005:2014-01 Technika informatyczna - Techniki bezpieczeństwa - Zarządzanie ryzykiem w bezpieczeństwie informacji.

• Norma ISO/IEC 27033 Information technology - Security techniques - Network security,

• PN-ISO/IEC 27001 Technika informatyczna - Techniki bezpieczeństwa - Systemy zarządzania bezpieczeństwem informacji – Wymagania.

• PN-ISO/IEC 17799 Technika informatyczna - Techniki bezpieczeństwa - Praktyczne zasady zarządzania bezpieczeństwem informacji wraz z PN-ISO/IEC 17799:2007/Ap1:2010 – normy te są dokładnym przekładem treści z norm ISO/IEC 27002.

• Norma PN-I-13335-1:1999 Technika informatyczna - Wytyczne do zarządzania bezpieczeństwem systemów informatycznych - Pojęcia i modele bezpieczeństwa systemów informatycznych.

• Norma PN-I-13335-2:2003 Technika informatyczna – Planowanie i zarządzanie bezpieczeństwem systemów informatycznych.

• Norma PN-ISO/IEC 24762:2010 Technika informatyczna – Techniki bezpieczeństwa. Wytyczne dla usług odtwarzania techniki teleinformatycznej po katastrofie.

• Norma PN-EN ISO 10781: 2011 - Model funkcjonalny systemu elektronicznej dokumentacji zdrowotnej, wersja 1.1.

• Norma PN-EN ISO 21549-3:2014-05 Informatyka medyczna - Dane karty zdrowia pacjenta – Część 3: Ograniczony zestaw danych klinicznych,

• Norma ISO 18308:2011 – Informatyka w ochronie zdrowia - Wymagania dla architektury elektronicznej dokumentacji medycznej.

Wytyczne CSIOZ w zakresie integracji z P1 oraz w zakresie EDM, w szczególności aktualne wersje następujących dokumentów:

• Reguły tworzenia i model transportowy EDM

• Wytyczne dla systemu bezpiecznego przetwarzania EDM

6.4.Wymagania wydajnościowe systemu

1. Czas dostępu do informacji o EDM gromadzonych w warstwie regionalnej liczony jako czas od wysłania zapytania do dostarczenia odpowiedzi z rejestru EDM nie może być dłuższy niż 3 sekundy.

2. Czas dostępu do EDM gromadzonej w warstwie lokalnej w trybie synchronicznym liczony jako czas od wysłania zapytania do otrzymania EDM nie może być dłuższy niż 10 sekund. Po przekroczeniu tego czasu System musi przechodzić w tryb pobierania asynchronicznego.

3. Dostarczana infrastruktura musi pozwalać na sprzętowe i programowe tworzenie klastrów wydajnościowych oraz niezawodnościowych.

6.5.Wymagania skalowalności

1. Klaster serwerów aplikacji musi mieć możliwość budowy z wielu instancji serwerów aplikacji działających równocześnie w taki sposób, aby zapewnić dwa podstawowe mechanizmy: skalowalność oraz niezawodność. Serwery aplikacji tworzących klaster muszą mieć możliwość pracy w ramach tej samej fizycznej maszyny bądź na różnych fizycznych maszynach w ramach infrastruktury lokalnej. „Pojemność” klastra można zwiększyć poprzez dodanie nowych instancji do klastra, instancje te mogą być uruchomione na tej samej fizycznej maszynie, bądź na innych fizycznych maszynach.

2. Komplet dla infrastruktury sprzętowej oznacza 1 szt. urządzenia wraz z niezbędnym okablowaniem umożliwiającym ich podłączenie. W przypadku oprogramowania komplet oznacza taką ilość oprogramowania, która będzie pokrywać cały sprzęt przewidziany do dostarczenia w danym szpitalu dla jednej serwerowni.

6.6.Wymagania wolumenu przetwarzanych danych

1. Warstwa regionalna musi umożliwiać zainstalowanie i funkcjonowanie komponentu regionalnego Systemu MSIM

2. Warstwa lokalna musi umożliwiać zainstalowanie i funkcjonowania komponentu lokalnego Systemu MSIM

3. System musi umożliwiać gromadzenie EDM w lokalnych repozytorium danych będących częścią komponentu lokalnego

4. System musi umożliwiać gromadzenie metadanych EDM w regionalnym rejestrze danych będącego częścią komponentu regionalnego

5. Komponent regionalny musi gromadzić dane w trybie produkcyjnym, w trybie backupu
   i archiwizacji.

6.7.Wymagania niezawodności

1. System musi umożliwiać odtworzenie danych na podstawie kopii zapasowej, w szczególności musi umożliwiać:

1. wykonywanie kopii zapasowych danych w trakcie pracy systemu,

2. szybkie odtworzenie danych.

2. Łączny czas niedostępności systemu nie może przekroczyć 2 dni w ciągu roku

3. Maksymalny czas odtwarzania po awarii nie powinien przekraczać 5 godzin (w dni robocze) lub 1 dnia (w dni świąteczne).

4. System musi pracować w trybie 24/7/365 bez zdefiniowanych przerw w pracy, bez względu na czynności związane z utrzymaniem systemu (nie dotyczy instalacji nowych wersji oprogramowania) z niezawodnością 99,5 %.

5. Po wystąpieniu, a następnie ustąpieniu awarii sieci lub usługi zewnętrznej system musi samodzielnie, automatycznie, bez ingerencji operatora wznowić pracę.

6. W przypadku wystąpienia większego obciążenia niż określono w wymaganiach wydajnościowych, przestają one obowiązywać, jednakże system powinien zachować przewidzianą wymaganiami funkcjonalność.

7. System ma mieć możliwość tworzenia zapasowych kopii baz danych. Kopie zapasowe muszą pozwalać na przywrócenie stanu baz danych z maksymalną stratą danych z 1 godziny.

6.8.Wymagania bezpieczeństwa

1. System MSIM może być dostępny tylko dla uwierzytelnionych użytkowników, za wyjątkiem użytkowników anonimowych portalu 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. x.xx.: daty, definiowanego przedziału czasowego, użytkownika, identyfikatora, czynności, innych oraz zapewniać możliwość ich eksportu.

6. System musi umożliwiać dostęp do logów zdarzeń tylko administratorowi. Musi być zapewniona wiarygodność i bezpieczeństwo logów.

7. System musi umożliwiać odnotowanie daty wykonania każdej operacji oraz identyfikatora użytkownika wykonującego operację.

8. System musi posiadać mechanizmy uniemożliwiające edycję i usuwanie plików zawierających logi zdarzeń systemowych oraz chroniące przed możliwością ich przepełnienia.

9. System musi zapewniać synchronizację zegara systemowego ze źródłami czasu za pomocą protokołu NTP lub mechanizmów Active Directory w celu utrzymania wiarygodności logów systemowych.

10. System musi umożliwiać korzystanie z protokołu SSL dla zabezpieczenia przesyłanych informacji lub w inny sposób zapewniać szyfrowanie przesyłania danych.

11. System musi umożliwiać zdefiniowanie reguł określających wymaganą siłę stosowanych haseł dla różnych grup użytkowników w szczególności:

1. minimalnej i maksymalnej dopuszczalnej długości hasła,

2. stosowania znaków alfanumerycznych i specjalnych,

3. maksymalnej długość okresu ważności hasła,

4. liczby haseł zapamiętywanych w historii haseł (blokowanie możliwości ich ponownego użycia).

12. System musi umożliwiać automatyczne zamykanie sesji dostępu użytkownika po upływie definiowanego w konfiguracji systemu czasu od momentu przerwania pracy z systemem (np. zamknięcia przeglądarki).

13. System musi zapewniać monitorowanie prób naruszenia bezpieczeństwa systemu,
    w tym prób nieuprawnionego dostępu do Systemu (tj. próby nieudane, ostrzeżenia systemowe i błędy).

14. System musi zapewniać monitorowanie operacji uprzywilejowanych, tj. wykorzystanie uprawnień administratora, uruchamianie aplikacji i ich zamykanie.

15. System musi wykonywać kopie zapasowe systemu zgodnie z ustalonym harmonogramem.

16. System ma zapewniać poufność wymienianych danych.

17. System ma zapewniać rozliczalność wymienianych danych. Rozliczalność rozumiana jest jako zachowanie wszelkich informacji nt. jakie dane kiedy i komu były udostępniane.

18. System musi zapewniać integralność wymienianych danych. System ma zapewniać aby dane nie zostały zmienione w trakcie przesyłania pomiędzy jednostkami.

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:

  • Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. 1997 nr 133 poz. 883).,

  • 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:

  • PN-ISO/IEC 27001:2013 Technika informatyczna. Techniki bezpieczeństwa. Systemy zarządzania bezpieczeństwem informacji. Wymagania,

  • PN-ISO/IEC 17799:2007 Technika informatyczna. Techniki bezpieczeństwa. Praktyczne zasady zarządzania bezpieczeństwem informacji.

3. Polityka Bezpieczeństwa Danych Osobowych - swoim zakresem dokument obejmie min.:

• Cel i zakres polityki bezpieczeństwa,

• Organizacja bezpieczeństwa informacji,

• Struktura ról i obowiązków w zakresie ochrony danych osobowych,

• Wykaz zbiorów danych osobowych i pomieszczeń, w których są przetwarzane Dane Osobowe,

• Sposób przepływu danych,

• Opis struktury zbiorów danych,

• Zabezpieczenia organizacyjne,

• Zabezpieczenia techniczne,

• Monitorowanie zabezpieczeń,

• Wzory oświadczeń.

4. Instrukcja Zarządzania Systemem Informatycznym - swoim zakresem dokument obejmie min.:

• Charakterystyka systemów informatycznych przetwarzających dane osobowe,

• Procedury nadawania uprawnień do przetwarzania danych i rejestrowania tych uprawnień w systemie informatycznym oraz wskazanie osób odpowiedzialnych za te czynności,

• Metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem
  i użytkowaniem,

• Procedury rozpoczęcia, zawieszenia i zakończenia pracy przeznaczone dla użytkowników systemu,

• Procedury tworzenia kopii zapasowych zbiorów danych oraz programów i narzędzi programowych służących do ich przetwarzania,

• Sposób, miejsce i okres przechowywania nośników informacji,

• Sposób zabezpieczenia systemu informatycznego przed działalnością oprogramowania, którego celem jest uzyskanie nieuprawnionego dostępu do systemu informatycznego,

• Procedury wykonywania przeglądów i konserwacji systemów oraz nośników informacji służących do przetwarzania danych,

• Procedury postępowania z urządzeniami, dyskami lub innymi informatycznymi nośnikami zawierającymi dane osobowe, przeznaczonymi do likwidacji, przekazania innemu podmiotowi i naprawy,

• Procedury postępowania w sytuacji naruszenia ochrony danych osobowych.

• Wzory oświadczeń, protokołów innych dokumentów w kontekście powyższych zapisów.

6.10.Wymagania systemu zarządzania tożsamością

System zarządzania tożsamością musi posiadać funkcjonalności nie mniejsze niż:

1. Konfiguracja i zarządzanie polityką bezpieczeństwa w zakresie:

   1. Polityki bezpieczeństwa haseł

   2. Polityki kontroli dostępu

   3. Polityki zarządzania uprawnieniami,

2. Gromadzenie w jednym miejscu pełnych informacji o użytkowniku, takich jak: miejsce
   w hierarchii służbowej, dane kontaktowe, uprawnia dostępu (do urządzeń sieciowych, komputerów, systemów informatycznych, pomieszczeń), data przyznania, odebrania uprawnień oraz data ich ważności, informacja o uprawnieniach zawodowych, wydane certyfikaty, e-podpisy, rola w sytuacji awaryjnej,

3. Możliwość uzyskania informacji o przydzielonych aktywach do użytkownikach, takich jak: komputer, samochód, telefon, licencje i ich okresie ważności,

4. Identyfikacja płynących ryzyk biznesowych wynikających z nadania danych uprawnień,

5. Informacja o przypisanej grupie użytkowników i udzielonych prawach dostępu,

6. Możliwość uzyskania informacji o nadaniu wyższych praw dostępu użytkownikowi,
   z jakiej przyczyny, na jaki czas,

7. Zaprojektowanie i zarządzanie workflow: wnioskowania, akceptowania i nadawania uprawnie minimum przy wykorzystaniu 2 poziomowej akceptacji,

8. Rozdzielenie grup i ról dostępu do systemu,

9. Zarządzanie dostępem użytkowników od zasobów informatycznych i ich danych poziomów administracyjnych,

10. Możliwość łatwego blokowania i odbieranie praw dostępu do systemu,

11. Łatwość przeprowadzania przeglądu praw dostępu na indywidualnych i grupowych pracowników,

12. Integracja z formalnymi procedurami nadawania i odbierania praw dostępu do systemów,

13. Alarmowanie o próbie nieautoryzowanego logowania do danego systemu,

14. Alarmowanie o zalogowaniu się pracownika który jest obecnie na urlopie,

15. Możliwość łatwej i szybkiej weryfikacji przyznanych praw dostępu,

16. Nadawanie dodatkowych praw dostępu z możliwością ograniczania i kontrolowania,

17. System nadawania haseł powinien być kontrolowany i wymuszany do natychmiastowej zmiany bezpiecznego hasła po pierwszym logowaniu użytkownika,

18. Dostarczanie nowych, zastępczych haseł po uprzedniej weryfikacji pracownika
    w sytuacji kiedy zapomni swojego hasła,

19. Hasło powinno być wymuszane do zmiany co 30 dni (konstrukcja hasła: 8 znaków, trój rodzajowo-znakowe),

20. Przeglądanie i ponowne nadawanie praw dostępu użytkownikom zmieniającym stanowisko pracy,

21. Dodatkowe uwierzytelnianie się przy połączeniach zewnętrznych np. stosując technikę kryptograficzna, tokeny sprzętowe lub protokoły „wezwanie-odpowiedź”,

22. Ograniczanie trwania połączenia zewnętrznego (zamykanie sesji po pewnym czasie),

23. Archiwizowanie wszystkich zmian zachodzących w danym profilu tożsamości użytkownika (pełna historia użytkownika),

24. Tworzenie i monitorowanie kopii zapasowych informacji i konfiguracji przechowywanych
    w systemie kontroli dostępu.

6.11.Procedury nadawania/zmiany/odbierania uprawnień

Dla systemu MSIM zostaną opracowane następujące procedury w ramach procesu kontroli dostępu do zasobów:

1. Polityka kontroli dostępu,

2. Procedura nadawania uprawnień do systemu,

3. Procedura zmiany uprawnień do systemu,

4. Procedura odbierania uprawnień do systemu,

5. Procedura przeglądu uprawnień użytkowników,

6. Procedura nadawania zdalnego dostępu (obejmująca użytkowników oraz dostawców usług).

System MSIM zakłada następujące grupy użytkowników:

• Użytkownicy uprawnieni do korzystania z usługi wyszukiwania EDM,

• Użytkownicy uprawnieni do korzystania z usługi pobierania EDM,

• Użytkownicy uprawnieni do korzystania z usługi e-Rejestracja,

• Administratorzy systemu,

• Administratorzy usług,

• Administratorzy baz danych,

• Administratorzy sieci,

• Administratorzy infrastruktury sprzętowej.

6.12.Repozytorium EDM

1. Repozytorium EDM odpowiada za przyjmowanie, gromadzenie, przetwarzanie dowolnej EDM zgodnej ze standardem HL7CD na poziomie 3-cim.

2. Repozytorium EDM musi wystawiać i obsługiwać interfejs przekazywania i rejestracji EDM zgodnie z wytycznymi ITI-41 profilu integracyjnego XDS.b.

3. Repozytorium EDM musi obsługiwać interfejs pozwalający na pobranie EDM uwierzytelnionemu użytkownikowi zgodnie z wytycznymi ITI- 43

4. Repozytorium EDM musi wspierać opcję (rozszerzenie) profilu integracyjnego XDS.b związaną z obsługą asynchronicznej wymiany wiadomości (ang. „Asynchronous Web Services Exchange Option”)

5. Repozytorium integruje się z mechanizmami nadawania w sposób atomowy uprawnień do obiektów przetrzymywanych w repozytorium. Dla każdego obiektu możliwe jest zdefiniowanie przynajmniej następujących uprawnień: wyświetlenie metadanych i udostępnienie dokumentu

6. Repozytorium przechowuje informację o zgodach pacjenta na udostępnianie dokumentów w ramach jednostki, oraz na udostępnianie dokumentu poza jednostkę

7. Repozytorium integruje się z zewnętrznym dostawcą znaczników czasu oraz z zewnętrznym Centrum Autoryzacji(CAPE w Małopolsce), co pozwala na automatyczne znakowanie dokumentów. Wykonawca wykonuje integrację z CAPE w Małopolsce w zakresie znakowania czasem oraz wykorzystania podpisu.

8. Repozytorium implementuje mechanizm wersjonowania dokumentów.

9. Repozytorium przechowuje rejestr obiektów złożonych w repozytorium wraz z zestawem metadanych opisujących każdy z dokumentów.

10. Repozytorium oblicza identyfikator hash jednoznacznie związanego z zawartością dokumentu.

11. Repozytorium udostępnia interface podpisywania dokumentów podpisem elektronicznym.

12. W ramach przechowywania identyfikatorów repozytorium posługuje się standardem OID.

13. Repozytorium odrzuca próbę rejestracji dokumentu o tym samym identyfikatorze

14. Repozytorium każdej jednostki jest definiowane oddzielnie, wraz z własnym unikalnym identyfikatorem repozytorium. Repozytorium skonstruowane jest w taki sposób, że współpracuje z wielu różnymi repozytoriami w ramach jednej domeny

15. Repozytorium modyfikuje metadane dokumentu dodając tylko i wyłącznie: id repozytorium, skrót dokumentu (hash), wielkość dokumentu.

16. Repozytorium jest neutralne pod względem zawartości, ale jest w stanie dodatkowo wydobywać informacje z plików w formatach HL7 CDA R2 na 3-cim poziomie interoperacyjności, DICOM.

17. Repozytorium przechowuje informacje o tym na jakim medium przechowywany jest dokument.

18. Repozytorium pozwala na zniszczenie dokumentów po upływie okresu retencji.

19. Repozytorium wyposażone jest w interface web services pozwalający na pobranie dowolnego dokumentu o znanym identyfikatorze.

20. Repozytorium obsługuje standard WS-Trust umożliwiający delegację uprawnień użytkowników zewnętrznych poprzez zaufanego brokera bezpieczeństwa oraz współpracę z systemem STS.

21. Repozytorium przechowuje tokeny SAML związane z udostępnieniem dokumentu użytkownikowi poprzez okres retencji dokumentu.

22. Rejestr jest wyposażony jest w interface webservices pozwalający na przeszukiwanie dokumentów dla użytkowników wewnętrznych zgodnie z posiadanymi przez użytkownika uprawnieniami.

23. Repozytorium przechowuje wszystkie żądania udostępnienia dokumentu, wraz z informacją czy żądanie pojawiło się od użytkownika wewnętrznego, zewnętrznego i czy skończyło się udostępnieniem dokumentu czy też odmową udostępnienia.

24. Repozytorium posiada interfejsy umożliwiające eksport pojedynczych dokumentów bądź całych zbiorów dokumentów. Eksportowane obiekty mogą być dodatkowo opatrzone podpisem elektronicznym zapewniającym integralność eksportowanych danych

25. Repozytorium pozwala na przesyłanie oraz udostępnianie dokumentów oraz metadanych . Interface webservice pozwala na dodawanie dowolnych metadanych.

27. Repozytorium integruje się z domeną identyfikacji pacjenta (pojedynczym źródłem tożsamości pacjenta).

28. W ramach integracji webservices repozytorium obsługuje standard WS-Security.

29. Repozytorium może być zintegrowane z systemami wykonującymi transformację dokumentów (transkrypcję tekstu, wykonywanie skrótów i rekompresji dokumentów)

30. Treść dokumentów przechowywanych Repozytorium jest w postaci zaszyfrowanej.

31. Każdy z obiektów, w zależności od typu, może być opisywany za pomocą zbioru metadanych. Każda z metadanych może być definiowana jako wymagana, lub opcjonalna. Definicje wymaganych/opcjonalnych metadanych uzależnione są od typu obiektu/dokumentu.

32. Dla każdego obiektu repozytorium obsługuje co najmniej następujący zestaw metadanych: identyfikator pacjenta, imię i nazwisko pacjenta, płeć pacjenta, początek i koniec zdarzenia medycznego, data utworzenia dokumentu, nazwa i rodzaj dokumentu, rodzaj i nazwa jednostki medycznej, unikalny identyfikator dokumentu, grupa bezpieczeństwa.

33. Dokumenty umieszczone w repozytorium nie mogą być modyfikowane oraz usuwane przed upływem okresu retencji. Repozytorium umożliwia natomiast wykonywanie adnotacji do dokumentów oraz zamianę dokumentów. Repozytorium przechowuje zarówno dokument oryginalny, adnotację oraz ewentualny dokument zamieniający (replacement document).Repozytorium przechowuje relacje pomiędzy dokumentami oryginalnym, zamieniającym oraz adnotacją.

34. Repozytorium posiada wbudowane mechanizmy pozwalające na pełno tekstowe przeszukiwanie zarówno meta-danych, jak i merytorycznej zawartości przechowywanego dokumentu.

35. Repozytorium posiada wbudowane mechanizmy pozwalające na zbieranie danych z obszaru wydajności działania oprogramowania (performance monitoring).

36. Repozytorium posiada natywne wsparcie do wdrożeń w środowiskach klastrowych.

6.13.Usługa e-Rejestracja

Wymagania minimalne dla usługi e-Rejestracji

Nr funkcjonalności	Funkcjonalność
e-R.1	Wymagania ogólne
e-R.1.1	Informacje podstawowe funkcjonowania e-Rejestracji
e-R.1.1.1	e-Rejestracja zostanie zainicjowana z portalu e-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
e-R.2.1	Rejestracja wizyty Formatka Rejestracji wywoływana jest po wyborze przez pacjenta (Użytkownik końcowy) danej usługi w danej jednostce służby zdrowia
e-R.2.1.2	Zawartość formatki „Wymagane dane rejestracji” może być różna dla danej jednostki ochrony zdrowia oraz typu usługi medycznej, w zakresie danych do uzupełnienia w postaci pól formatek.
e-R.2.2	Wymagane dane rejestracji:
e-R.2.2.1	Dane Użytkownika końcowego są automatycznie podpowiadane w polach formatki zgodnie z danymi na koncie Użytkownika końcowego oraz planowanym miejscem wykonania usługi i jej rodzajem zgodnie z dokonanym wyborem.
e-R.2.2.2	Użytkownik wypełnia pozostałe dane niezbędne do rejestracji na formatce.
e-R.2.2.3	Należy podać wymagany zakres danych niezbędny do zapisu rejestracji (dane wymagane i nie wymagane)
e-R.2.2.4	Należy podać dane dotyczące skierowania w czasie rejestracji w przypadku wymagalności danych dotyczących skierowania dla realizacji danej usługi
e-R.2.2.5	Dane muszą być podpowiadane do wyboru w postaci pola do uzupełnienia, listy rozwijanej z zaznaczeniem wszystkich, jednej lub kilku opcji wyboru (opcja w zależności od rodzaju listy rozwijanej)
e-R.2.3	Wysłanie lub anulowanie rezerwacji wizyty (Użytkownik końcowy potwierdza wysłanie rezerwacji lub ją anuluje)
e-R.2.3.1	W przypadku anulowania zamknięcie okna rejestracji
e-R.2.3.2	W przypadku wysłania, informacja graficzna w oknie rejestracji o przetwarzaniu informacji o rezerwacji, z prośbą o oczekiwanie
e-R.2.4	Brak potwierdzenia Rezerwacji on-line
e-R.2.4.1	W przypadku niemożliwości zakończenia we wskazanym czasie przetwarzania informacji o rezerwacji i braku informacji zwrotnej z potwierdzeniem lub odrzuceniem rejestracji:
e-R.2.5	Zamknięcie okna z informacją graficzną w oknie rejestracji o przetwarzaniu
e-R.2.5.1	System zapisuje rezerwacje w historii danych konta użytkownika końcowego z określonym statusem.
e-R.2.5.2	Rezerwacja wysyłana jest do skutku, celem potwierdzenia lub odrzucenia rejestracji
e-R.2.6	Walidacja danych Rezerwacji
e-R.2.6.1	Walidacja kompletności wypełnienia danych wymaganych na formatce „Wymagane dane rejestracji” przed wysyłaniem danych do lokalnego Systemu medycznego (HIS) danej jednostki ochrony zdrowia, a w przypadku braku wypełnienia informacja zwrotna z zaznaczeniem danych nie wypełnionych.
e-R.2.6.2	Walidacja kolizji rezerwacji w komponencie regionalnym.
e-R.2.6.3	Wykrywanie i blokowanie wielokrotnych e-Rezerwacji tej samej usługi jednego dnia.,
e-R.2.6.4	Wykrywanie i blokowanie wielokrotnej e-Rezerwacji różnych usług jednego dnia na tę samą godzinę.
e-R.2.6.5	Komunikat zwrotny o wykryciu kolizji rezerwacji.
e-R.2.7	Potwierdzenie lub odrzucenie Rejestracji wizyty Po dokonaniu Rejestracji do Systemu medycznego (HIS) w jednostce ochrony zdrowia, gdzie będzie realizowana usługa, Użytkownik końcowy dostaje informacje zwrotną na ekran:
e-R.2.7.1	Potwierdzającą przyjęcie Rejestracji wizyty.
e-R.2.7.2	Podać treść informacji zwrotnej zawierającej co najmniej: a) Informacja potwierdzająca przyjęcie Rejestracji, b) Unikalny numer rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja, c) Imię i nazwisko Użytkownika końcowego, d) Numer ID Użytkownika końcowego, e) PESEL, f) Rodzaj usługi, g) Miejsce wykonania usługi, h) Planowana data wykonana usługi, i) Informacje dodatkowe.
e-R.2.7.3	Odrzucenie przyjęcia Rezerwacji wizyty Podać treść informacji zwrotnej zawierającej co najmniej: a) Informację zwrotną odrzucającą przyjęcie Rezerwacji, b) Informację o przyczynie odrzucenia, Informacja generowana automatycznie co do treści wg rodzaju odrzucenia, np. zajęty termin c) Informacje dodatkowe
e-R.2.7.4	Możliwość wydruku potwierdzenia Rezerwacji wizyty
e-R.2.7.5	Zapisanie Rejestracji w historii moich danych na koncie Użytkowania końcowego
e-R.2.8	Anulowanie Rejestracji
e-R.2.8.1	Wybór opcji Anulowania wskazanej Rejestracji powoduje wyświetlenie informacji potwierdzającej fakt anulowania otwartej Rejestracji.
e-R.2.9	Użytkownik końcowy potwierdza wysłanie Anulowania Rejestracji lub ją anuluje. a) W przypadku anulowania zamknięcie okna informacyjnego.
e-R.2.9.1	W przypadku potwierdzenia Anulowania Rejestracji wyświetlenie kolejnej informacji potwierdzającej fakt Anulowania otwartej Rejestracji a) W przypadku anulowania zamknięcie okna informacyjnego. b) W przypadku potwierdzenia, następuje wysłanie zgody na Anulowanie i następuje zamknięcie okna informacyjnego
e-R.2.9.2	Następuje zapisanie zmiany statusu w historii moich danych na koncie użytkownika końcowego, w wyniku Anulowania Rejestracji w lokalnym systemie medycznym HIS.
e-R.2.9.3	Anulowanie Rejestracji wysyłane jest do skutku, celem potwierdzenia Anulowania.
e-R.2.10	Komunikat systemowy potwierdzający Rejestrację
e-R.2.10.1	Potwierdzenie Rejestracji wysyłane jest na wskazany przez Użytkownika końcowego adres e-mail o treści jak wyświetlonej na ekranie w wyniku potwierdzenia przyjęcia Rejestracji wizyty.
e-R.2.11	Tytuł wiadomości e-mail jest generowany automatycznie i zawiera część: stałą (co najmniej):
e-R.2.11.0.1	podać treść
e-R.2.11.0.2	ID Użytkownika końcowego
e-R.2.11.1	zmienną (co najmniej):
e-R.2.11.1.1	Unikalny NR Rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja
e-R.2.11.1.2	Planowany termin wizyty
e-R.2.11.1.3	Wiadomość e-mail jest sformatowana w treści gotowej do wydruku
e-R.2.12	System musi być gotowy do realizacji funkcjonalności: Potwierdzenie Rejestracji wysyłanego w postaci SMS na wskazany przez Użytkownika końcowego nr telefonu o wskazanej treści.
e-R.2.12.1	Wiadomości SMS jest generowana automatycznie i zawiera część:
e-R.2.12.1.1	stałą (co najmniej):
e-R.2.12.1.1.1	podać treść
e-R.2.12.1.1.2	ID Użytkownika końcowego
e-R.2.12.1.2	zmienną (co najmniej):
e-R.2.12.1.2.1	Unikalny NR Rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja
e-R.2.12.1.2.2	Planowany termin wizyty
e-R.2.13	Komunikaty systemowe potwierdzające akcje obsługi Rejestracji
e-R.2.13.1	W wyniku zbliżającego się terminu wizyty lokalny System medyczny (HIS) przekazuje zawartość dla wiadomości SMS i/lub e-mail z powiadomieniem o zdarzeniu
e-R.2.13.2	Wiadomości SMS jest generowana automatycznie i zawiera część:
e-R.2.13.3	stałą (co najmniej):
e-R.2.13.3.1	podać treść
e-R.2.13.3.2	ID Użytkownika końcowego
e-R.2.13.4	zmienną (co najmniej):
e-R.2.13.4.1	Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja
e-R.2.13.4.2	Planowany termin wizyty
e-R.2.13.5	Wiadomości e-mail jest generowana automatycznie i zawiera część:
e-R.2.13.6	stałą (co najmniej):
e-R.2.13.6.1	podać treść
e-R.2.13.6.2	ID Użytkownika końcowego
e-R.2.13.7	zmienną (co najmniej):
e-R.2.13.7.1	Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja
e-R.2.13.7.2	Planowany termin wizyty
e-R.2.13.7.3	Wiadomość e-mail jest sformatowana w treści gotowej do wydruku
e-R.2.14	W wyniku Anulowania wizyty w lokalnym Systemie medycznym HIS, przekazuje on wiadomość SMS i/lub e-mail z powiadomieniem o określonej treści:
e-R.2.15	Wiadomość SMS jest generowana automatycznie i zawiera część:
e-R.2.16	stałą (co najmniej):
e-R.2.16.0.1	podać treść
e-R.2.16.0.2	ID Użytkownika końcowego
e-R.2.16.1	zmienną (co najmniej):
e-R.2.16.1.1	Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja
e-R.2.16.1.2	Planowany termin wizyty
e-R.2.17	Wiadomość e-mail jest generowana automatycznie i zawiera część:
e-R.2.17.1	stałą (co najmniej):
e-R.2.17.1.1	podać treść
e-R.2.17.1.2	ID Użytkownika końcowego
e-R.2.17.2	zmienną (co najmniej):
e-R.2.17.2.1	Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja
e-R.2.17.2.2	Planowany termin wizyty
e-R.2.17.2.3	Wiadomość e-mail jest sformatowana w treści gotowej do wydruku
e-R.2.17.2.4	Zapisanie zmiany statusu Rejestracji w historii moich danych na koncie użytkowania końcowego
e-R.2.18	W wyniku zmiany terminu wizyty w lokalnym Systemie medycznym HIS, przekazuje on wiadomość SMS i/lub e-mail z powiadomieniem o określonej treści:
e-R.2.18.1	Wiadomości SMS jest generowana automatycznie i zawiera część:
e-R.2.18.1.1	stałą (co najmniej):
e-R.2.18.1.1.1	podać treść
e-R.2.18.1.1.2	ID Użytkownika końcowego
e-R.2.18.1.2	zmienną (co najmniej):
e-R.2.18.1.2.1	Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana rejestracja
e-R.2.18.1.2.2	Stary termin wizyty
e-R.2.18.1.2.3	Planowany termin wizyty
e-R.2.18.2	Wiadomość e-mail jest generowana automatycznie i zawiera część:
e-R.2.18.2.1	stałą (co najmniej):
e-R.2.18.2.1.1	podać treść
e-R.2.18.2.1.2	ID Użytkownika końcowego
e-R.2.18.2.2	zmienną (co najmniej):
e-R.2.18.2.2.1	Unikalny NR rejestracji z Systemu medycznego (HIS) w jednostce gdzie została zapisana Rejestracja
e-R.2.18.2.2.2	Stary termin wizyty
e-R.2.18.2.2.3	Planowany termin wizyty
e-R.2.18.2.2.4	Wiadomość e-mail jest sformatowana w treści gotowej do wydruku
e-R.2.18.2.2.5	Zapisanie zmiany statusu rejestracji w historii moich danych na koncie użytkowania końcowego
e-R.2.18.3	W wyniku zakończenia wizyty
e-R.2.18.3.1	Zapisanie zmiany statusu Rejestracji w historii moich danych na koncie użytkowania końcowego
e-R.3	Nadzór nad procesami nieuprawnionego korzystania
e-R.3.1	System musi wspierać nadzór nad rejestracją Pacjentów do badań diagnostycznych obrazowych. Nadzór ma na celu uniknięcie sytuacji, w których Pacjenci rejestrują się na badania u tego samego świadczeniodawcy na podstawie 2 różnych skierowań od różnych lekarzy, a badanie to ma dotyczyć tych samych okolic ciała.
e-R.3.2	System musi wspierać proces weryfikacji e-Rejestracji do oddziałów szpitalnych w zakresie rejestracji na podstawie więcej niż jednego skierowania do szpitala. Wsparcie ma na celu uniknięcie sytuacji, w których Pacjent na podstawie różnych skierowań rejestruje się na pobyt w wielu oddziałach, np. na podstawie dwóch różnych skierowań rejestruje się na pobyt w jednym oddziale, a na podstawie drugiego skierowania rezerwuje termin w innym oddziale. Pobyt w pierwszym oddziale kończy się, ale termin planowanego przyjęcia do drugiego oddziału jest wyznaczony przed upływem 14 dni od wypisu z poprzedniego oddziału.

6.14.Wymagania warstwy integracji

Nr funkcjonalności	Funkcjonalność
Int.1	Szyna usług w warstwie regionalnej
Int.1.1	Szyna usług zapewnia komunikację i wymianę danych pomiędzy jednostkami ochrona zdrowia zintegrowanymi z MSIM.
Int.1.2	Szyna usług dostarcza jednorodny zestaw komend, kolejek, funkcji, procedur, komunikatów oraz mechanizmów wymiany danych, definiując sposób dostępu do Istniejących i Lokalnych systemów informatycznych działających w jednostkach ochrony zdrowia zintegrowanych z MSIM. Zestaw ten, jest taki sam dla wszystkich jedenastek ochrony zdrowia zintegrowanych z MSIM, umożliwiając standaryzację w komunikacji pomiędzy nimi. Standaryzacja ta realizowana jest na poziomie API i zapewnia, że wszystkie jedenastki ochrony zdrowia zintegrowane z MSIM używają takich samych mechanizmów do wymiany danych i komunikacji.
Int.1.3	Szyna usług ma posiadać możliwość przetwarzania sekwencyjnego jak i równoległego komunikatów modułów systemu, z możliwością powtórzeń operacji, których wykonanie z jakiś przyczyn nie powiodło się. W przypadku wystąpienia błędów w trakcie przetwarzania komunikatów przez szynę usług, błędy te powinny być w sposób prosty identyfikowane, poprzez przypisanie ich do: nazwa modułu, nazwa obiektu, metoda, czas wystąpienia błędu.
Int.1.4	Szyna usług ma być zgodna ze standardami: WSDL 1.x, SOAP 1.1, SOAP 1.2, SOAP WITH ATTACHMENTS
Int.1.5	Szyna usług ma umożliwiać implementację komunikacji pomiędzy Lokalnymi systemami informatycznymi na podstawie posiadanych adapterów.
Int.1.6	Szyna usług ma umożliwiać transformację danych, transformację komunikatów np. xpath/xslt/xquery.
Int.1.7	Szyna usług ma umożliwiać wzbogacanie transformacji danych o warunki logiczne lub ograniczenia.
Int.1.8	Szyna usług ma obsługiwać wiele warstw transportowych np.: JMS, HTTP,FTP, TCP.
Int.1.9	Szyna usług ma umożliwiać monitorowanie poprawnej pracy usług.
Int.2	Szyna usług zapewni realizację odpowiedniego poziomu bezpieczeństwa w zakresie:
Int.2.0.1	Uwierzytelniania
Int.2.0.2	Kontroli dostępu
Int.2.0.3	Zarządzania użytkownikami, grupami i rolami
Int.2.0.4	Przechowywania i walidacji certyfikatów, haseł, klucza
Int.2.0.5	Audytowania zdarzeń bezpieczeństwa
Int.2.1	Szyna usług zapewni dostępność mechanizmów uwierzytelniania i szyfrowania usług takich jak: użytkownik/hasło, weryfikacja hostów, brak uwierzytelniania, certyfikaty x.509
Int.2.2	Szyna usług zapewni możliwość ograniczenia czasu wywołań dla usług oraz Szyna usług ma zawierać zestawienie adapterów do systemów i standardów zewnętrznych np: -, nfs, pliki lokalne, http, smtp, ftp, jms, -, jdbc, edi, oracle, db2.
Int.2.3	Szyna usług zapewni obsługę komunikatów typu np.: SOAP, XML, FTP, SMTP.
Int.2.4	Szyna usług zapewni możliwość eksportu ustawień konfiguracyjnych i importu na innej instancji Szyny Usług.
Int.2.5	Szyna usług ma mieć wbudowaną obsługę mechanizmów kolejkowych.
Int.2.6	Szyna usług ma zapewnić obsługę mechanizmów autoryzacji i autentykacji pozwalających na integrację z systemem ePUAPePUAP
Int.3	Interfejs integracji regionalnej
Int.3.1	Interfejs integracji musi działać w oparciu o publiczne standardy.Musi istnieć możliwość jego realizacji bez wykorzystania komercyjnych mechanizmów oraz oprogramowania komercyjnego po stronie warstwy lokalnej j
Int.3.2	Interfejs integracji musi być skalowalny do obsługi do min 150 jednostek ochrony zdrowia.
Int.4	Wykonawca musi przekazać zamawiającemu dokumentację interfejsu integracji zawierającą następujące elementy:
Int.4.0.1	Struktura komunikatów.
Int.4.0.2	Opis przepływu informacji z wykorzystaniem jednej z powszechnie stosowanych notacji, np. UML.
Int.4.1	Wykonawca ma wybudować interfejs integracji służący do wymiany danych pomiędzy MSIM a Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (P1))

7.Infrastruktura

Wykonawca musi dostarczyć infrastrukturę sprzętowo-programową zgodnie ze specyfikacjami przedstawionymi w niniejszym rozdziale oraz w liczbie przedstawionej w następujących tabelach. Jeżeli w szczegółowym opisie przedmiotu zamówienia zostały wskazane znaki towarowe, patenty lub pochodzenie Zamawiający w każdym przypadku dopuszcza rozwiązania równoważne pod względem x.xx. funkcji, materiałów, jakości, parametrów. Użyty w specyfikacjach termin lokalizacja odnosi się do fizycznej lokalizacji (serwerowni) pojedynczego Partnera Projektu, w którym będzie wdrożony komponent lokalny lub regionalny, co oznacza, że Projekt obejmuje 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.

ID Wymagania	Opis wymagania
WYMGW.1.	Gwarancja na sprzęt i oprogramowanie przez okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego Systemu.
WYMGW.2.	Wsparcie sprzętu i oprogramowania przez okres wskazany w ofercie lecz nie mniej niż 5 lat licząc od daty odbioru końcowego Systemu.
WYMGW.3.	Oferowane urządzenia musza być fabrycznie nowe i pochodzić z autoryzowanego kanału dystrybucji producenta.

W poniższej tabeli przedstawiono wykaz serwerowni do których w ramach przedmiotu zamówienia zostanie przez Wykonawcę dostarczona infrastruktura:

Partner Projektu		Serwerownia podstawowa – lokalizacja	Serwerownia zapasowa – lokalizacja	Dodatkowe uwagi
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu	33-300 Nowy Sącz, Xxxxxxx 0, Xxxxxxx xxxxxx		00-000 Xxxx Xxxx, Xxxxxxx 0, Xxxxxxx xxxxxx - RTG	Kompletna warstwa lokalna – serwerownia podstawowa UTM/przełączniki ETHERNET w obu lokalizacjach - redundantnie (serwerownia podstawowa oraz zapasowa)
Szpital Specjalistyczny im. J. Dietla w Krakowie	31-121 Kraków, ul. Skarbowa 4		00-000 Xxxxxx, xx Xxxxx 00	Kompletna warstwa lokalna – serwerownia podstawowa UTM/przełączniki ETHERNET w obu lokalizacjach - redundantnie (serwerownia podstawowa oraz zapasowa)
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.– warstwa lokalna	xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx			Kompletna warstwa lokalna – serwerownia podstawowa
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.– warstwa regionalna	xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx: poziom +I piętro (naklejka serwerowni 1)		xx. Xxxxxx Xxxxxxx 0, 00-000 Xxxxxx: poziom-1 piwnica (centrala telefoniczna- naklejka serwerownia 2)	Kompletna warstwa lokalna / klimatyzacja – serwerownia podstawowa Kompletna warstwa regionalna – serwerownia podstawowa Serwery / Szafy RACK / Macierz / Biblioteka taśmowa / Przełączniki FC / przełączniki ETHERNET / Adaptery Mini GBIC / Konsola KVM / UTM / Urządzenia podtrzymujące zasilanie w obu lokalizacjach- redundantnie (serwerownia podstawowa oraz zapasowa)

Dostawy realizowane będą w podziale na Partnerów Projektu zgodnie z poniższym zakresem rzeczowym, gdzie ilości zostały wskazane jako komplet (kpl.), który powinien zawierać wszelkie elementy dostarczone przez producenta sprzętu lub oprogramowania (w tym w szczególności licencje, nośniki ze sterownikami oraz oprogramowaniem, elementy montażowe, zaślepki, kable, instrukcje) oraz wszelkie elementy niezbędne do poprawnej konfiguracji, prawidłowego podłączenia oraz działania zarówno elementów dostarczonych pomiędzy sobą, elementów dostarczonych z istniejącą infrastruktura partnera oraz innych jednostek biorących udział w projekcie, jak i poprawności działania całego systemu MSIM zgodnie z założeniami projektu. W przypadku nie wykorzystywanych portów, slotów i zatok, półek – należy dostarczyć stosowne zaślepki. Okablowanie dostarczone powinno umożliwiać połączenie urządzeń na maksymalnej przepustowości dla danej pary urządzeń (np.
w przypadku połączenia portów 100Mbit z portem 1Gbit jest to 100Mbit, w przypadku 2 portów 1Gbit jest to 1Gbit). Wersje instalacyjne oraz instrukcje oprogramowania, które nie posiadają nośników
i instrukcji w formie papierowej, a jedynie licencje w wersji elektronicznej, należy przekazać zamawiającemu na nośniku lub nośnikach typu Archival grade. Licencje należy przekazać w wersji papierowej, a w przypadku licencji w wersji elektronicznej, dodatkowo w postaci wydruku.

Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu

Oprogramowanie: zakup licencji	Liczba (kpl.)
Repozytorium Lokalne EDM	1
Oprogramowania systemowe	Liczba (kpl.)
Oprogramowanie do backupu	1
Oprogramowanie do wirtualizacji	1
Oprogramowanie zabezpieczające	1
Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową	1
Oprogramowanie serwera aplikacji	1
Oprogramowanie bazy danych	1
System operacyjny	1
Infrastruktura sprzętowa	Liczba (kpl.)
Serwer Aplikacyjny	1
Serwer Pomocniczy	1
Serwer Bazodanowy	1
Szafa Rack	1
Macierz	1
Biblioteka taśmowa	1
Konsola KVM	1
Przełącznik Ethernet	2
Urządzenie UTM	2
Urządzenia podtrzymujące zasilanie	1
Klimatyzacja	1
Infrastruktura podpisu elektronicznego	1

Szpital Specjalistyczny im. J. Dietla w Krakowie

Oprogramowanie: zakup licencji	Liczba (kpl.)
Repozytorium Lokalne EDM	1
Oprogramowania systemowe	Liczba (kpl.)
Oprogramowanie do backupu	1
Oprogramowanie do wirtualizacji	1
Oprogramowanie zabezpieczające	1
Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową	1
Oprogramowanie serwera aplikacji	1
Oprogramowanie bazy danych	1
System operacyjny	1
Infrastruktura sprzętowa	Liczba (kpl.)
Serwer Aplikacyjny	1
Serwer Pomocniczy	1
Serwer Bazodanowy	1
Szafa Rack	1
Macierz	1
Biblioteka taśmowa	1
Konsola KVM	1
Przełącznik Ethernet	2
Urządzenie UTM	2
Urządzenia podtrzymujące zasilanie	1
Klimatyzacja	1
Infrastruktura podpisu elektronicznego	1

Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.

Oprogramowanie: zakup licencji	Liczba (kpl.)
Repozytorium Lokalne EDM	1
Oprogramowania systemowe	Liczba (kpl.)
Oprogramowanie do backupu	1
Oprogramowanie do wirtualizacji	1
Oprogramowanie zabezpieczające	1
Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową	1
Oprogramowanie serwera aplikacji	1
Oprogramowanie bazy danych	1
System operacyjny	1
Infrastruktura sprzętowa	Liczba (kpl.)
Serwer Aplikacyjny	1
Serwer Pomocniczy	1
Serwer Bazodanowy	1
Szafa Rack	1
Macierz	1
Biblioteka taśmowa	1
Konsola KVM	1
Przełącznik Ethernet	2
Urządzenie UTM	2
Urządzenia podtrzymujące zasilanie	1
Klimatyzacja	1
Infrastruktura podpisu elektronicznego	1

Infrastruktura podpisu elektronicznego, która zlokalizowana będzie w trzech Szpitalach jako element warstwy lokalnej w projekcie przedstawia się następująco:

Infrastruktura podpisu elektronicznego	Liczba (kpl.)	Liczba (szt.)
Czytniki kart	3	700
Karty kryptograficzne		700
Naklejki		1400
Folia		11
Zestawy czyszczące		5
Szpital Specjalistyczny im. J. Śniadeckiego w Nowym Sączu
Czytniki kart	1	174
Karty kryptograficzne		174
Szpital Specjalistyczny im. J. Dietla w Krakowie
Czytniki kart	1	193
Karty kryptograficzne		193
Szpital Specjalistyczny im. Xxxxxxx Xxxxxxxxx w Krakowie sp. z o.o.
Czytniki kart	1	333
Karty kryptograficzne		333

System oraz akcesoria służące do personalizacji kart		Liczba (szt.)
Urząd Marszałkowski Województwa Małopolskiego
Naklejki		1400
Folia		11
Zestawy czyszczące		5
System personalizacji wraz dokumentacją		1

Wykonawca przeprowadzi instalację oraz konfigurację elementów infrastruktury podpisu elektronicznego w siedzibie każdego uczestnika projektu (w miejscach wskazanych przez Zamawiającego)w ilości zgodnej z powyższym zestawieniem. Personalizacja oraz nadruk kart zostanie wykonany przez pracowników Urzędu Marszałkowskiego Województwa Małopolskiego.

W warstwie regionalnej, która zlokalizowana będzie w Szpitalu Specjalistycznym im. Ludwika Rydygiera w Krakowie zakres planowanych zakupów w projekcie przedstawia się następująco:

Oprogramowanie w warstwie regionalnej	Liczba (kpl.)
Rejestr EDM	1
E-rejestracja	1
Oprogramowanie portalowe	1
Oprogramowanie systemowe	Liczba (kpl.)
Oprogramowanie do backupu	2
Oprogramowanie do wirtualizacji	2
Oprogramowanie zabezpieczające	2
Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową	2
Oprogramowanie bazodanowe	2
Oprogramowanie serwera aplikacji	2
System operacyjny	2
Infrastruktura regionalna	Liczba (kpl.)
Serwer Aplikacyjny	2
Serwer Bazodanowy	2
Serwer Pomocniczy	2
Szafa Rack	2
Macierz	2
Biblioteka taśmowa	2
Przełącznik Ethernet	2
Przełącznik FC	2
Adaptery Mini GBIC	24
Konsola KVM	2
UTM Region	2
Klimatyzacja – Region	1
Urządzenia podtrzymujące zasilanie – Region	2

Budowa infrastruktury sprzętowej na potrzeby projektu MSIM obejmuje kompleksową infrastrukturę sprzętowo-programową w warstwie regionalnej oraz lokalnej, pozwalającą w przypadku warstwy regionalnej na jej niezależne i dowolne umieszczenie bez konieczności dodatkowej rozbudowy. Zakłada się połączenie Szpitali objętych projektem MSIM siecią VPN oraz wykonanie regionalnej
i lokalnych dedykowanych dla potrzeb Systemu EDM struktur sprzętowo-sieciowych.

Projektując infrastrukturę sprzętową pod system EDM zasadniczym elementem było uniknięcie pojedynczych punktów awarii całości rozwiązania. Tam gdzie było to możliwe elementy infrastruktury są podwojone, w szczególności w warstwie regionalnej. Redundancja warstwy regionalnej pozwala na zachowanie ciągłości działania w przypadku awarii jednej z lokalizacji. W warstwie lokalnej zdecydowano się na rozwiązanie z pojedynczym kompletem serwerów i macierzy.

System EDM będzie posiadał wysoki poziom ciągłości działania, co jest kluczową cechą koncepcji przechowywania i udostępniania dokumentacji medycznej w formie elektronicznej.

Dla komponentu regionalnego:

Sekcja	Nazwa	Liczba (kpl.)
	Serwer Aplikacyjny	2
	Error: Reference source not found	2
	Error: Reference source not found	2
	Error: Reference source not found	2
	Macierz – Region	2
	Biblioteka taśmowa	2
	Przełącznik Fiber Channel	2
	Przełącznik Ethernet - Region	2
7.2.2.	Adaptery Mini GBIC	24
7.2.3.	Xxxxxxx XXX	0
	XXX - Xxxxxx	2
7.3.2.	Urządzenia podtrzymujące zasilanie – Region	2
7.4.2.	Klimatyzacja – Region	1
7.4.4.	Urządzenie do administracji MSIM	1
7.5.1.	Oprogramowanie do backupu	2
7.5.2.	Oprogramowanie do wirtualizacji	2
7.5.3.	Oprogramowanie zabezpieczające	2
7.5.4.	Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową	2
7.5.5.	System operacyjny	2
7.5.6.	Oprogramowanie bazy danych	2
7.5.7.	Oprogramowanie serwera aplikacji	2

Dla komponentu lokalnego:

Sekcja	Nazwa	Liczba (kpl.)
	Serwer Aplikacyjny	3
	Error: Reference source not found	3
	Error: Reference source not found	3
	Szafa	3
	Macierz – Szpitale	3
	Biblioteka taśmowa	3
	Przełącznik Ethernet - Szpitale	6
7.2.3.	Xxxxxxx XXX	0
	UTM – Szpitale	6
7.3.3.	Urządzenia podtrzymujące zasilanie – Szpitale	3
7.3.4.	Infrastruktura podpisu elektronicznego	3
7.4.3.	Klimatyzacja – Szpitale	3
7.5.1.	Oprogramowanie do backupu	3
7.5.2.	Oprogramowanie do wirtualizacji	3
7.5.3.	Oprogramowanie zabezpieczające	3
7.5.4.	Oprogramowanie do zarządzania - monitorowania infrastrukturą sprzętową	3
7.5.5.	System operacyjny	3
7.5.6.	Oprogramowanie bazy danych	3
7.5.7.	Oprogramowanie serwera aplikacji	3

Wszystkie niewymienione w tabeli elementy infrastruktury dostarczane są zgodnie z opisem we właściwej sekcji.

7.1.Infrastruktura serwerowa

Sekcja przedstawia zestawienie elementów infrastruktury serwerowej niezbędnych do realizacji projektu wraz z wyszczególnieniem ich parametrów technicznych. Wszystkie wykazane parametry techniczne mają charakter specyfikacji minimalnych.

7.1.1.Serwery – Region

Serwer Aplikacyjny

Poniżej przedstawiono wymagania dla Serwera Aplikacyjnego.

ID Wymagania	Opis wymagania
	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.
	Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Płyta główna musi być zaprojektowana przez producenta xxxxxxx i oznaczona jego znakiem firmowym.
	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.
	Minimum2zainstalowane procesory.
	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.
	Minimum 2 sloty PCI-Express generacji 3, w tym jeden slot x16 (szybkość slotu – bus width).
	Minimum 4 złącza typu 1GbEthernet RJ-45.
	Minimum jedna karta FC zapewniająca minimum 2 interfejsy FC,, każdy min. 8Gb.
	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.
	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.
	Serwer wyposażony w wewnętrzny napęd DVD lub Blue-ray.
	Minimum 4 szt. portów USB.
	Serwer wyposażony w kartę zdalnego zarządzania zapewniającą: Zdalne włączanie/wyłączanie/restart. Zdalny dostęp z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu. Zdalną identyfikację fizycznego serwera za pomocą sygnalizatora optycznego. Podłączanie zdalnych napędów CD-ROM/DVD/ISO/Blue-ray z możliwością bootowania z w/w napędów. Podgląd logów sprzętowych serwera i karty. Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od jego stanu (także podczas startu, restartu OS).
	Zintegrowana karta graficzna.
	2 szt. zasilaczy, redundantne, hot plug.
	Chłodzenie: 2 szt (redundantne), hot plug.
	Możliwość zainstalowania modułu TPM na płycie głównej serwera.
	Wspierane systemy operacyjne: Microsoft Windows 2012, Oracle Linux 6, Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11, VMware ESXi 5.
	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.

Serwer Bazodanowy

Poniżej przedstawiono wymagania dla Serwera Bazodanowego.

ID wymagania	Opis wymagania
	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.
	Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Płyta główna musi być zaprojektowana przez producenta xxxxxxx i oznaczona jego znakiem firmowym.
	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.
	Minimum2zainstalowane procesory.
	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.
	Minimum 2 sloty PCI-Express generacji 3, w tym jeden slot x16 (szybkość slotu – bus width).
	Minimum 4 złącza typu 1GbEthernet RJ-45.
	Minimum jedna karta FC zapewniająca minimum 2 interfejsy FC,, każdy min. 8Gb.
	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.
	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.
	Serwer wyposażony w wewnętrzny napęd DVD lub Blue-ray.
	Minimum 4 szt. portów USB.
	Serwer wyposażony w kartę zdalnego zarządzania zapewniającą: Zdalne włączanie/wyłączanie/restart. Zdalny dostęp z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu. Zdalną identyfikację fizycznego serwera za pomocą sygnalizatora optycznego. Podłączanie zdalnych napędów CD-ROM/DVD/ISO/Blue-ray z możliwością bootowania z w/w napędów. Podgląd logów sprzętowych serwera i karty. Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od jego stanu (także podczas startu, restartu OS).
	Zintegrowana karta graficzna.
	2 szt. zasilaczy, redundantne, hot plug.
	Chłodzenie: 2 szt. (redundantne), hot plug.
	Możliwość zainstalowania modułu TPM na płycie głównej serwera.
	Wspierane systemy operacyjne: Microsoft Windows 2012, Oracle Linux 6, Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11, VMware ESXi 5.
	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.

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
	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.
	Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Płyta główna musi być zaprojektowana przez producenta xxxxxxx i oznaczona jego znakiem firmowym.
	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.
	Minimum1zainstalowany procesor.
	Minimum min. 64GB 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.
	Minimum 6 slotów PCI-Express, w tym min. 1 sloty x16 (szybkość slotu – bus width).
	Minimum 4 złącza typu 1GbEthernet RJ-45.
	8 interfejsów FC 8Gb. Minimum 4 karty FC zapewniająca minimum 2 interfejsy FC, każdy min. 8Gb.
	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.
	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.
	Serwer wyposażony w wewnętrzny napęd DVD lub Blue-ray.
	Minimum 4 szt. portów USB.
	Serwer wyposażony w kartę zdalnego zarządzania zapewniającą: Zdalne włączanie/wyłączanie/restart. Zdalny dostęp z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu. Zdalną identyfikację fizycznego serwera za pomocą sygnalizatora optycznego. Podłączanie zdalnych napędów CD-ROM/DVD/ISO/Blue-ray z możliwością bootowania z w/w napędów. Podgląd logów sprzętowych serwera i karty. Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od jego stanu (także podczas startu, restartu OS).
	Zintegrowana karta graficzna.
	2 szt. zasilaczy, redundantne, hot plug.
	Chłodzenie: 2 szt. (redundantne), hot plug.
	Możliwość zainstalowania modułu TPM na płycie głównej serwera (w dedykowanym tylko dla tego modułu gnieździe/miejscu).
	Wspierane systemy operacyjne: Microsoft Windows 2012, Oracle Linux 6, Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11, VMware ESXi 5.
	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.

Szafa RACK

Poniżej przedstawiono wymagania dla Szafy Rack.

ID wymagania	Opis wymagania
	Szafa serwerowa 19” o wewnętrznej przestrzeni do montażu urządzeń 42U, zewnętrzne wymiar szafy: 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.
	Wykonawca zobowiązany jest dostarczyć: 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

Serwer Aplikacyjny

Poniżej przedstawiono wymagania dla Serwera Aplikacyjnego.

ID wymagania	Opis wymagania
	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.
	Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Płyta główna musi być zaprojektowana przez producenta xxxxxxx i oznaczona jego znakiem firmowym.
	Procesory minimum sześciordzeniowe, x86 - 64 bity, osiągający w testach 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.
	Minimum2zainstalowane procesory.
	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.
	Minimum 2 sloty PCI-Express generacji 3, w tym jeden slot x16 (szybkość slotu – bus width).
	Minimum 4 złącza typu 1GbEthernet RJ-45.
	Minimum dwie karty FC zapewniające minimum 4 interfejsy FC,, każdy o przepustowości min. 8Gb
	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.
	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.
	Serwer wyposażony w wewnętrzny napęd DVD lub Blue-ray.
	Minimum 4 szt. portów USB.
	Serwer wyposażony w kartę zdalnego zarządzania zapewniającą: Zdalne włączanie/wyłączanie/restart. Zdalny dostęp z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu. Zdalną identyfikację fizycznego serwera za pomocą sygnalizatora optycznego. Podłączanie zdalnych napędów CD-ROM/DVD/ISO/Blue-ray z możliwością bootowania z w/w napędów. Podgląd logów sprzętowych serwera i karty. Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od jego stanu (także podczas startu, restartu OS).
	Zintegrowana karta graficzna.
	2 szt. zasilaczy, redundantne, hot plug.
	Chłodzenie: 2 szt. (redundantne), hot plug.
	Możliwość zainstalowania modułu TPM na płycie głównej serwera.
	Wspierane systemy operacyjne: Microsoft Windows 2012R2, Oracle Linux 6, Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11, VMware ESXi 5.
	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.

Serwer Bazodanowy

Poniżej przedstawiono wymagania dla Serwera Bazy danych.

ID wymagania	Opis wymagania
	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.
	Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Płyta główna musi być zaprojektowana przez producenta xxxxxxx i oznaczona jego znakiem firmowym.
	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.
	Minimum1 zainstalowany procesor.
	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.
	Minimum 2 sloty PCI-Express generacji 3, w tym jeden slot x16 (szybkość slotu – bus width).
	Minimum 4 złącza typu 1GbEthernet RJ-45.
	Minimum dwie karty FC zapewniająca minimum 4 interfejsy FC,, każdy o przepustowości min. 8Gb.
	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.
	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.
	Serwer wyposażony w wewnętrzny napęd DVD lub Blue-ray.
	Minimum 4 szt. portów USB.
	Serwer wyposażony w kartę zdalnego zarządzania zapewniającą: Zdalne włączanie/wyłączanie/restart. Zdalny dostęp z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu. Zdalną identyfikację fizycznego serwera za pomocą sygnalizatora optycznego. Podłączanie zdalnych napędów CD-ROM/DVD/ISO/Blue-ray z możliwością bootowania z w/w napędów. Podgląd logów sprzętowych serwera i karty. Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od jego stanu (także podczas startu, restartu OS).
	Zintegrowana karta graficzna.
	2 szt. zasilaczy, redundantne, hot plug.
	Chłodzenie: 2 szt. (redundantne), hot plug.
	Możliwość zainstalowania modułu TPM na płycie głównej serwera.
	Wspierane systemy operacyjne: Microsoft Windows 2012R2, Oracle Linux 6, Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11, VMware ESXi 5.
	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.

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
	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.
	Płyta główna z możliwością zainstalowania minimum dwóch procesorów. Płyta główna musi być zaprojektowana przez producenta xxxxxxx i oznaczona jego znakiem firmowym.
	Procesory minimum sześciordzeniowe, x86 - 64 bity, osiągający w testach 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.
	Minimum2zainstalowane procesory.
	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.
	Minimum 2 sloty PCI-Express generacji 3, w tym jeden slot x16 (szybkość slotu – bus width).
	Minimum 4 złącza typu 1GbEthernet RJ-45.
	Minimum dwie karty FC zapewniające minimum 4 interfejsy FC,, każdy o przepustowości min. 8Gb
	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.
	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.
	Serwer wyposażony w wewnętrzny napęd DVD lub Blue-ray.
	Minimum 4 szt. portów USB.
	Serwer wyposażony w kartę zdalnego zarządzania zapewniającą: Zdalne włączanie/wyłączanie/restart. Zdalny dostęp z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu. Zdalną identyfikację fizycznego serwera za pomocą sygnalizatora optycznego. Podłączanie zdalnych napędów CD-ROM/DVD/ISO/Blue-ray z możliwością bootowania z w/w napędów. Podgląd logów sprzętowych serwera i karty. Przejęcie pełnej konsoli tekstowej i graficznej serwera niezależnie od jego stanu (także podczas startu, restartu OS).
	Zintegrowana karta graficzna.
	2 szt. zasilaczy, redundantne, hot plug.
	Chłodzenie: 2 szt. (redundantne), hot plug.
	Możliwość zainstalowania modułu TPM na płycie głównej serwera.
	Wspierane systemy operacyjne: Microsoft Windows 2012R2, Oracle Linux 6, Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11, VMware ESXi 5.
	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.

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
	Szafa serwerowa 19” o wewnętrznej przestrzeni do montażu urządzeń 42U, zewnętrzne wymiar szafy: 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.
	Wykonawca zobowiązany jest dostarczyć: 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

Macierz – Region

Poniżej przedstawiono wymagania dla Macierzy dla warstwy regionalnej.

ID wymagania	Opis wymagania
	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.
	Macierz musi być przystosowana do zamontowania w oferowanej szafie rack 19’’ wraz z zestawem szyn montażowych oraz kompletem kabli zasilających.
	Wysokość obudowy maksymalnie powinna wynosić 8U.
	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: wartość średniego czasu dostępu podawana przez producenta sprzętu dla oferowanego typu dysku maksymalnie 8.5 ms lub mniej, wyposażony w 2 szt. lub więcej portów SAS lub FC każdy o przepustowości 6Gb/s lub więcej.
	Pojemność dyskowa dla systemu backupu i archiwizacji danych: Sumaryczna pojemność 24 TB lub więcej w postaci 8 szt. identycznych dysków. Każdy dysk o następujących parametrach: wartość średniego czasu dostępu podawana przez producenta sprzętu dla oferowanego typu dysku maksymalnie 9.0 ms lub mniej, wyposażony w 2 szt. lub więcej portów SAS lub FC każdy o przepustowości 6Gb/s lub więcej.
	Dyski muszą być wymieniane podczas pracy systemu dyskowego bez konieczności przerywania obsługi serwerów.
	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.
	Oferowana Macierz Dyskowa musi posiadać funkcjonalność: 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. Tworzenie Globalnego dysku spare. 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.
	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.
	Zdalna replikacja musi odbywać się przy wykorzystaniu jedynie zasobów sprzętowych Macierzy Dyskowej w trybie asynchronicznym.
	Rozbudowa o opisaną funkcjonalność zdalnej replikacji musi odbyć się przez instalację dodatkowych licencji, bez konieczności dokupowania dodatkowych elementów sprzętowych.
	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.
	Standard FC 8 Gb: wszystkie porty połączone w taki sposób aby występowała transmisja blokowa pomiędzy oferowanymi serwerami a macierzą dyskową. co najmniej 4 pary (8szt.) portów FC 8Gb. każdy port o paśmie 8Gb/s lub więcej. 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. 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. 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.
	Standard ETHERNET : 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ń wykonywanych przez system. W konfiguracji maksymalnej dla danego systemu dyskowego przewidzianego przez producenta systemu.
	Nadmiarowy, odporny na awarię połowy wentylatorów, system chłodzenia wymienny podczas pracy systemu dyskowego, bez konieczności przerywania zadań wykonywanych przez system. W konfiguracji maksymalnej dla danego systemu dyskowego przewidzianego przez producenta systemu.

Macierz – Szpitale

Poniżej przedstawiono wymagania dla macierzy zlokalizowanej w warstwie lokalnej.

ID wymagania	Opis wymagania
	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.
	Macierz musi być przystosowana do zamontowania w oferowanej szafie Rack 19’’ wraz z zestawem szyn montażowych oraz kompletem kabli zasilających.
	Wysokość obudowy maksymalnie powinna wynosić 8U.
	Pojemność dyskowa dla danych produkcyjnych: Sumaryczna pojemność 6 TB lub więcej w postaci 10 szt. identycznych dysków. Każdy dysk o następujących parametrach: wartość średniego czasu dostępu podawana przez producenta sprzętu dla oferowanego typu dysku maksymalnie 8.5 ms lub mniej, wyposażony w 2 szt. lub więcej portów SAS lub FC każdy o przepustowości 6Gb/s lub więcej.
	Pojemność dyskowa dla systemu backupu i archiwizacji danych: Sumaryczna pojemność 24 TB lub więcej w postaci 8 szt. identycznych dysków. Każdy dysk o następujących parametrach: wartość średniego czasu dostępu podawana przez producenta sprzętu dla oferowanego typu dysku maksymalnie 9.0 ms lub mniej, wyposażony w 2 szt. lub więcej portów SAS lub FC każdy o przepustowości 6Gb/s lub więcej.
	Dyski muszą być wymieniane podczas pracy systemu dyskowego bez konieczności przerywania obsługi serwerów.
	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.
	Oferowana Macierz Dyskowa musi posiadać funkcjonalność: 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. Tworzenie Globalnego dysku spare. 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.
	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.
	Zdalna replikacja musi odbywać się przy wykorzystaniu jedynie zasobów sprzętowych Macierzy Dyskowej w trybie asynchronicznym.
	Rozbudowa o opisaną funkcjonalność zdalnej replikacji musi odbyć się przez instalację dodatkowych licencji, bez konieczności dokupowania dodatkowych elementów sprzętowych.
	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.
	Standard FC 8 Gb: wszystkie porty połączone w taki sposób aby występowała transmisja blokowa pomiędzy oferowanymi serwerami a macierzą dyskową co najmniej 4 pary (8szt.) portów FC 8Gb. każdy port o paśmie 8Gb/s lub więcej. 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. 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. 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.
	Standard ETHERNET : 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. W konfiguracji maksymalnej dla danego systemu dyskowego przewidzianego przez producenta systemu.
	Nadmiarowy, odporny na awarię połowy wentylatorów, system chłodzenia wymienny podczas pracy systemu dyskowego, bez konieczności przerywania zadań wykonywanych przez system. W konfiguracji maksymalnej dla danego systemu dyskowego przewidzianego przez producenta systemu.

Biblioteka taśmowa

Poniżej przedstawiono wymagania dla biblioteki taśmowej dla warstwy regionalnej oraz lokalnej.

ID wymagania	Opis wymagania
	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.
	Co najmniej 8 slotów przeznaczonych na zestaw taśm składających się z: 8 sztuk taśm w standardzie LTO5 lub lepszym o pojemności co najmniej 3 TB każda. 1 szt. taśmy czyszczącej zestawu kodów kreskowych w celu identyfikacji każdej z dostarczonych taśm.
	Co najmniej 1 port FC 8Gb/s w standardzie umożliwiającym podłączenie do portu FC przełącznika FC.
	Wyposażony w co najmniej 1 napęd o parametrach: standard LTO5 lub lepszy. 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

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
	Przełącznik musi posiadać, co najmniej 24 porty FC. Co najmniej 24 porty muszą być aktywne i obsadzone wkładkami 8Gb SFP SW.
	Przełącznik musi obsługiwać minimum porty typu: E_Port, F_Port, M_Port.
	Przełącznik musi posiadać minimum dwa zasilacze i dwa wentylatory.
	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).
	Zagregowana przepustowość przełącznika musi wynosić minimum 768Gb/s full duplex.(chodzi tu możliwości potencjalne przełącznika).
	Zarządzanie przełącznikiem musi się odbywać minimum za pomocą: przeglądarki WWW, programu Telnet oraz protokołu SNMP.
	Przełącznik musi umożliwiać instalację w standardowej szafie Rack 19”.
	Przełącznik musi posiadać funkcję definiowania tzw. Stref (ang. Zoning).
	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.
	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 - Region

Poniżej przedstawiono wymagania dla przełączników Ethernet zlokalizowanych w warstwie regionalnej.

ID wymagania	Opis wymagania
	Przełącznik musi być dedykowanym urządzeniem sieciowym przystosowanym do montażu w szafie Rack.
	Przełącznik musi posiadać nie mniej niż 48 porty dostępowe Ethernet 10/100/1000 BASE-T
	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+
	Jeżeli do zamontowania portów typu uplink wymagany jest dodatkowy moduł, taki moduł należy dostarczyć wraz z przełącznikiem.
	Porty typu uplink 1 Gbe SFP muszą obsługiwać moduły SFP następujących standardów:1000BASE-T, 1000BASE-SX, 1000BASE-LH
	Porty typu uplink 10 GbE SFP+ muszą obsługiwać moduły SFP+ następujących standardów:10GBASE-SR, 10GBASE-LR, 10GBASE-LRM
	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
	Przełącznik musi mieć możliwość podłączenia redundantnego zasilana wewnętrznego.
	Przełącznik musi posiadać port konsoli
	Przełącznik musi być wyposażony w nie mniej niż 512 MB pamięci Flash oraz 512 MB pamięci DRAM.
	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.
	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
	Przełącznik musi posiadać możliwość zarządzania i monitorowania przez centralny system zarządzania i monitorowania.
	Musi istnieć możliwość definiowania wielu poziomów dostępu administracyjnego do urządzenia
	Na przełączniku musi istnieć możliwość zdefiniowania wielu użytkowników, którzy będą zarządzać urządzeniem.
	Uwierzytelnianie administratorów musi odbywać się z użyciem: lokalnej bazy skonfigurowanej na przełączniku, przy pomocy protokołu RADIUS oraz TACACS+
	Przełącznik musi mieć możliwość synchronizacji zegara czasu za pomocą protokołu NTP
	Przełącznik musi obsługiwać protokół SNMP w wersji v1, v2c,,v3
	Przełącznik musi obsługiwać co najmniej 32 000 adresów MAC
	Przełącznik musi obsługiwać ramki Jumbo (9216 bajtów)
	Przełącznik musi obsługiwać sieci VLAN zgodne ze standardem 802.1Q
	Ilość obsługiwanych VLAN-ID nie może być mniejsza niż 4000.
	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
	Przełącznik musi wspierać Private VLAN (PVLAN)
	Przełącznik musi wspierać protokół 802.1x
	Urządzenie musi obsługiwać agregację połączeń zgodnie ze standardem 802.3ad
	Przełącznik musi mieć możliwość zgrupowania co najmniej 8 połączeń w jednym zagregowanym połączeniu
	Przełącznik musi być kompatybilny z protokołem Spanning Tree 802.1d
	Przełącznik musi być kompatybilny z protokołem Rapid Spanning Tree 802.1w
	Przełącznik musi obsługiwać protokół Multiple Spanning Tree 802.1s
	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
	Przełącznik musi obsługiwać protokół LLDP oraz LLDP-MED.
	Przełącznik musi obsługiwać routing pomiędzy podsieciami VLAN (Inter-VLAN routing)
	Przełącznik musi mieć możliwość konfiguracji tras statycznych oraz obsługiwać protokoły routingu dynamicznego RIP, OSPF,
	Urządzenie musi obsłużyć co najmniej 12 000 tras routingu
	Przełącznik musi obsługiwać funkcjonalność PBR (Policy Based Routing);
	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.
	Przełącznik musi wspierać protokół VRRP (Virtual Router Redundancy Protocol)
	Urządzenie musi posiadać mechanizmy priorytetyzowania i zarządzania ruchem sieciowym (QoS) w warstwie 2 i 3
	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
	Urządzenie musi mieć możliwość filtracji ruchu (listy kontroli dostępu ACL) na podstawie kryteriów z warstw 2-4
	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)
	Musi istnieć możliwość logowania lub zliczania pakietów, które odpowiadają kryteriom zawartym w regułach filtrowania ruchu ACL
	Ilość możliwych do skonfigurowania reguł filtrowania ruchu ACL nie może być mniejsza niż 7000
	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.
	Przełącznik musi posiadać możliwość uruchomienia funkcjonalności DHCP: DHCP Server oraz DHCP Relay
	Przełącznik musi zapewniać obsługę ruchu Multicast, oraz posiadać funkcjonalność IGMP oraz IGMP snooping
	Przełącznik musi obsługiwać protokoły routingu multicast: PIM-SM, PIM-SSM, PIM‑DM
	Urządzenie musi mieć możliwość kopiowania ruchu z jednego wybranego portu na inny wskazany port w celu analizy tego ruchu (port mirroring)
	Musi istnieć możliwość połączenia kilku przełączników tej samej rodziny w stos.
	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)
	Przełączniki połączone w stos powinny być traktowane jako jeden przełącznik przez protokół Spanning Tree
	Przełączniki tworzące stos muszą być zarządzane, jakby były jednym przełącznikiem
	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
	Przełącznik musi być dedykowanym urządzeniem sieciowym przystosowanym do montażu w szafie Rack.
	Przełącznik musi posiadać nie mniej niż 48 porty dostępowe Ethernet 10/100/1000 BASE-T
	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+
	Jeżeli do zamontowania portów typu uplink wymagany jest dodatkowy moduł, taki moduł należy dostarczyć wraz z przełącznikiem.
	Porty typu uplink 1 Gbe SFP muszą obsługiwać moduły SFP następujących standardów:1000BASE-T, 1000BASE-SX, 1000BASE-LH.
	Porty typu uplink 10 GbE SFP+ muszą obsługiwać moduły SFP+ następujących standardów:10GBASE-SR, 10GBASE-LR, 10GBASE-LRM
	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
	Przełącznik musi mieć możliwość podłączenia redundantnego zasilana wewnętrznego.
	Przełącznik musi posiadać port konsoli
	Przełącznik musi być wyposażony w nie mniej niż512 MBMB pamięci Flash oraz 512 MB pamięci DRAM.
	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.
	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
	Przełącznik musi posiadać możliwość zarządzania i monitorowania przez centralny system zarządzania i monitorowania.
	Musi istnieć możliwość definiowania wielu poziomów dostępu administracyjnego do urządzenia
	Na przełączniku musi istnieć możliwość zdefiniowania wielu użytkowników, którzy będą zarządzać urządzeniem.
	Uwierzytelnianie administratorów musi odbywać się z użyciem: lokalnej bazy skonfigurowanej na przełączniku, przy pomocy protokołu RADIUS oraz TACACS+
	Przełącznik musi mieć możliwość synchronizacji zegara czasu za pomocą protokołu NTP
	Przełącznik musi obsługiwać protokół SNMP w wersji v1, v2c,,v3
	Przełącznik musi obsługiwać co najmniej 32 000 adresów MAC
	Przełącznik musi obsługiwać ramki Jumbo (9216 bajtów)
	Przełącznik musi obsługiwać sieci VLAN zgodne ze standardem 802.1Q
	Ilość obsługiwanych VLAN-ID nie może być mniejsza niż 4000.
	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
	Przełącznik musi wspierać Private VLAN (PVLAN)
	Przełącznik musi wspierać protokół 802.1x
	Urządzenie musi obsługiwać agregację połączeń zgodnie ze standardem 802.3ad
	Przełącznik musi mieć możliwość zgrupowania co najmniej 8 połączeń w jednym zagregowanym połączeniu
	Przełącznik musi być kompatybilny z protokołem Spanning Tree 802.1d
	Przełącznik musi być kompatybilny z protokołem Rapid Spanning Tree 802.1w
	Przełącznik musi obsługiwać protokół Multiple Spanning Tree 802.1s
	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
	Przełącznik musi obsługiwać protokół LLDP oraz LLDP-MED.
	Przełącznik musi obsługiwać routing pomiędzy podsieciami VLAN (Inter-VLAN routing)
	Przełącznik musi mieć możliwość konfiguracji tras statycznych oraz obsługiwać protokoły routingu dynamicznego RIP, OSPF,
	Urządzenie musi obsłużyć co najmniej 12 000 tras routingu.
	Przełącznik musi obsługiwać funkcjonalność PBR (Policy Based Routing);
	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.
	Przełącznik musi wspierać protokół VRRP (Virtual Router Redundancy Protocol)
	Urządzenie musi posiadać mechanizmy priorytetyzowania i zarządzania ruchem sieciowym (QoS) w warstwie 2 i 3
	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
	Urządzenie musi mieć możliwość filtracji ruchu (listy kontroli dostępu ACL) na podstawie kryteriów z warstw 2-4
	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)
	Musi istnieć możliwość logowania lub zliczania pakietów, które odpowiadają kryteriom zawartym w regułach filtrowania ruchu ACL
	Ilość możliwych do skonfigurowania reguł filtrowania ruchu ACL nie może być mniejsza niż 7000
	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.
	Przełącznik musi posiadać możliwość uruchomienia funkcjonalności DHCP: DHCP Server oraz DHCP Relay
	Przełącznik musi zapewniać obsługę ruchu Multicast, oraz posiadać funkcjonalność IGMP oraz IGMP snooping
	Przełącznik musi obsługiwać protokoły routingu multicast: PIM-SM, PIM-SSM, PIM‑DM
	Urządzenie musi mieć możliwość kopiowania ruchu z jednego wybranego portu na inny wskazany port w celu analizy tego ruchu (port mirroring)
	Musi istnieć możliwość połączenia kilku przełączników tej samej rodziny w stos.
	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)
	Przełączniki połączone w stos powinny być traktowane jako jeden przełącznik przez protokół Spanning Tree
	Przełączniki tworzące stos muszą być zarządzane, jakby były jednym przełącznikiem
	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.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 , i .

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
	Konstrukcja: Przystosowana do zamontowania w oferowanej szafie Rack19", metalowa, 1U.
	Max. ilość podłączonych PC: 8 komputerów z wyjściem VGA i 2 x PS/2 lub USB.
	Podłączenie do PC: Kabel zintegrowany.
	Zintegrowana klawiatura oraz urządzenie wskazujące (touchpad).
	Złącze łańcuchowe: min. 1 szt.
	Emulacja: klawiatury / myszy PS/2.
	Możliwość wyboru aktywnego portu.
	Monitor LCD min. 17" 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.

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

UTM - Region

Poniżej przedstawiono wymagania dla UTM w warstwie regionalnej.

ID wymagania	Opis wymagania
	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ę.
	System zabezpieczeń nie może posiadać ograniczeń licencyjnych dotyczących liczby chronionych komputerów w sieci wewnętrznej lub innych.
	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ń.
	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.
	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.
	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.
	System zabezpieczeń musi realizować zadania kontroli dostępu (filtracji ruchu sieciowego), wykonując kontrolę na poziomie warstwy sieciowej, transportowej
	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).
	System zabezpieczeń musi umożliwiać zestawianie zabezpieczonych kryptograficznie tuneli VPN w oparciu o standardy IPSec i IKE w konfiguracji site-to-site.
	System zabezpieczeń musi wykonywać zarządzanie pasmem sieci (QoS), a także ustawiania dla dowolnych aplikacji pasma maksymalnego.
	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.
	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.
	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.
	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.
	System zabezpieczeń zapewnia możliwość bezpiecznego zdalnego dostępu do chronionych zasobów w oparciu o standard SSL VPN.
	System zabezpieczeń musi posiadać możliwość pracy w konfiguracji odpornej na awarie w trybie Active-Passive oraz w trybie Active-Active.
	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.
	W ramach postępowania musi zostać dostarczone jedno kompletne, gotowe do pracy urządzenie.
	Urządzenie powinno posiadać funkcje: systemu antywirusowego, DLP, Proxy, Stateful Inspection.
	Możliwość dwuskładnikowego logowania się (token fizyczny, aplikacja na telefon lub SMS).

UTM – Szpitale

Poniżej przedstawiono wymagania dla UTM zlokalizowanych w warstwie lokalnej.

ID wymagania		Opis wymagania
	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ę.
	System zabezpieczeń nie może posiadać ograniczeń licencyjnych dotyczących liczby chronionych komputerów w sieci wewnętrznej.
	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ń.
	Urządzenie zabezpieczeń musi być wyposażone w co najmniej 8 portów Ethernet 10/100/1000.
	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.
	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.
	System zabezpieczeń musi realizować zadania kontroli dostępu (filtracji ruchu sieciowego), wykonując kontrolę na poziomie warstwy sieciowej, transportowej.
	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).
	System zabezpieczeń musi umożliwiać zestawianie zabezpieczonych kryptograficznie tuneli VPN w oparciu o standardy IPSec i IKE w konfiguracji site-to-site.
	System zabezpieczeń musi wykonywać zarządzanie pasmem sieci (QoS), a także ustawiania dla dowolnych aplikacji pasma maksymalnego.
	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.
	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.
	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.
	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.
	System zabezpieczeń zapewnia możliwość bezpiecznego zdalnego dostępu do chronionych zasobów w oparciu o standard SSL VPN.
	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.
	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.
	W ramach postępowania musi zostać dostarczone jedno kompletne, gotowe do pracy urządzenie.
	Urządzenie powinno posiadać funkcje: systemu antywirusowego, DLP, Proxy, Stateful Inspection.
	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
	Przystosowana do zamontowania w oferowanej szafie Rack 19’’ wraz z zestawem szyn montażowych oraz kompletem kabli zasilających o wysokości maksymalnie 4U.
	Moc pozorna zasilacza powinna być nie mniejsza niż 3300 VA.
	Moc rzeczywista zasilacza powinna być nie mniejsza niż 3 000 W.
	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%.
	Musi istnieć możliwość wydłużenia czasu pracy na baterii poprzez zastosowanie dodatkowych modułów bateryjnych.
	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)
	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
	Przystosowana do zamontowania w oferowanej szafie Rack 19’’ wraz z zestawem szyn montażowych oraz kompletem kabli zasilających o wysokości maksymalnie 4U.
	Moc pozorna zasilacza powinna być nie mniejsza niż 3300 VA.
	Moc rzeczywista zasilacza powinna być nie mniejsza niż 3 000 W.
	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%.
	Musi istnieć możliwość wydłużenia czasu pracy na baterii poprzez zastosowanie dodatkowych modułów bateryjnych.
	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).
	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
	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 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.
	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
	Infrastruktura podpisu elektronicznego dla systemu funkcjonuje w oparciu o istniejące CAPE w Małopolsce
	Infrastruktura podpisu elektronicznego musi świadczyć usługę znakowania czasem z minimalną wydajnością oferowaną przez CAPE w Małopolsce
	Infrastruktura podpisu elektronicznego musi świadczyć usługę OCSP z minimalną wydajnością oferowaną przez CAPE w Małopolsce
	Infrastruktura podpisu elektronicznego musi świadczyć usługę archiwizacji podpisów z minimalną wydajnością oferowaną przez CAPE w Małopolsce
	Infrastruktura podpisu elektronicznego musi świadczyć usługę recertyfikacji podpisów z minimalną wydajnością oferowaną przez CAPE w Małopolsce
	Czytniki kart muszą obsługiwać dwie karty jednocześnie.

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:

   1. Tytuł zawierający neutralne informacje o dokumencie,

   2. Zakres, metrykę dokumentu (wersja, data)

   3. Spis treści wraz z listą wszystkich diagramów, tabel i załączników

   4. Lista Dystrybucyjna

   5. Lista wszystkich formularzy wymaganych dla działania PCD

   6. Odniesienie do Standardów, regulacji zewnętrznych, itp.

   7. Struktura organizacyjna dokumentu

2. Opracowanie Streszczenia dla Kierownictwa:

   1. Ogólna deklaracja zarządcza przedstawiająca rolę i zadania PCD

   2. Krótki opis głównych scenariuszy katastrofy w zakresie: personelu, systemów, budynków, infrastruktury publicznej itp.

   3. Krótkie przedstawienie spraw otwartych związanych z PCD z deklaracją ich wykonania (wł. zadania i termin wykonania)

3. Business Impact Analysis

   1. 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)

   2. Dołączone potwierdzenia wł. procesów, że przypisane zasoby IT są adekwatne
      i wystarczające

   3. Lista Kontaktowa dostawców i outsourcerów dla krytycznych procesów biznesowych

4. Procedury eskalacyjne

   1. Przedstawienie zasad i ogólnych reguł postępowania podczas ogłoszenia stanu katastrofy

   2. Plan ewakuacji

   3. Procedura powiadamiania o katastrofie

5. Lokalizacje

   1. Lista wszystkich lokalizacji i siedzib

   2. 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

   1. Opis bezpiecznego wyłączenia systemu, przeniesienia infrastruktury z zachowaniem względów bezpieczeństwa danych, wznowienia pracy sytemu.

   2. Wykonanie testów

7. Organizacja na czas katastrofy

   1. Przedstawienie i opis struktury Sztabu Kryzysowego – struktura, zadania, procedury

   2. 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

   1. 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

   2. Realizacja PCD – procedury odtworzeniowe z podziałem na zespoły awaryjne
      i diagramy decyzyjne,

   3. Wznowienie normalnej pracy MSIM – powrót z trybu awaryjnego – zespoły, zadania, diagramy decyzyjne, procedury relokacji.

9. Opracowanie scenariuszy testowych PCD:

   1. Zdefiniowanie niezbędnych rodzajów testów, wraz ze wszystkimi rolami, które muszą wziąć udział w testach,

   2. Rekomendacje dotyczące cykliczności rodzajów testów.

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 x.xx.:

  • Rejestru EDM

  • Bazy użytkowników i praw dostępu

  • Bazy konfiguracji

  • 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,

• 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.

1. Powinny istnieć dwa repozytoria kopii zapasowych: główne i zapasowe.

2. Warunki, które powinna spełniać lokalizacja repozytorium zapasowego:

1. Różne położenie geograficzne w stosunku do repozytorium głównego,

2. Komunikacja z lokalizacją głównego repozytorium dwoma niezależnymi drogami,

3. 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:

1. Zapewnienie poufności danych przez:

1. Zaszyfrowanie nośnika,

2. Przewożenie kopii bezpieczeństwa w postaci niezaszyfrowanej wyłącznie w obecności dwóch pracowników.

2. Nie pozostawianie kopii bezpieczeństwa bez nadzoru,

3. 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.

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
	Dostarczany sprzęt serwerowy musi być dostarczony wraz okablowaniem pozwalającym podpięcie go do sieci elektrycznej
	Dostarczany sprzęt serwerowy musi być dostarczony wraz okablowaniem pozwalającym podpięcie go do sieci LAN i SAN
	Dostarczany sprzęt sieciowy musi być dostarczony wraz okablowaniem pozwalającym podpięcie go do sieci elektrycznej
	Dostarczany sprzęt sieciowy musi być dostarczony wraz okablowaniem pozwalającym podpięcie go do sieci LAN i SAN
	Szafa RACK musi zostać dostarczona wraz wyposażeniem pozwalającym na montaż dostarczanego sprzętu serwerowego i sieciowego.
	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.
	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.
	Dostarczony sprzęt musi być dostarczony wraz z PDU oraz licencjami oprogramowania do monitorowania PDU.
	Czujniki temperatury.

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
	Urządzenie podstropowe o mocy minimum 8kWz zewnętrznym wymiennikiem ciepła
	Automatyczne utrzymywanie zadanej temperatury
	Sterowanie pilotem
	Tryb pracy całorocznej
	Automatyczne informowanie o awarii w działaniu
	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.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
	Urządzenie podstropowe o mocy minimum 5kWz zewnętrznym wymiennikiem ciepła
	Automatyczne utrzymywanie zadanej temperatury
	Sterowanie pilotem
	Tryb pracy całorocznej
	Automatyczne informowanie o awarii w działaniu
	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

LAPTOP
WYMUADM.1.	Ekran	Minimum 12,5" o maksymalnej rozdzielczościminimum 1366x768z podświetleniem w technologii LED
WYMUADM.2.	Procesor	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: xxxx://xxx.xxxxxxxxxxxx.xxx/xxxx_xxx_xxxx.xxxx).Xx oferty należy załączyć wydruk z ww. strony potwierdzający, że zaoferowany procesor spełnia wymagania.
WYMUADM.3.	Chipset	Dostosowany do oferowanego procesora
WYMUADM.4.	Pamięć RAM	Minimum 4GB DDR3 minimum 1333MHz
WYMUADM.5.	Dysk twardy (pojemność i typ)	Minimum 250 GB SATA: HDD (minimum 7200 obr/min) lub SSD
WYMUADM.6.	Karta graficzna	Zintegrowana, Zapewniająca sprzętowe wsparcie dla minimum DirectX 11 oraz minimum Shader Model 5.0
WYMUADM.7.	Karta dźwiękowa	Zintegrowana, wbudowane głośniki stereo oraz mikrofon
WYMUADM.8.	Karta sieciowa	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
WYMUADM.9.	Porty/złącza	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 złącza USB). Wbudowany czytnik linii papilarnych, wbudowany czytnik kart pamięci SD.
WYMUADM.10.	Klawiatura i urządzenie wskazujące	Klawiatura w układzie „polski programisty”, Touchpad
WYMUADM.11	Napęd optyczny	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.
WYMUADM.12.	Kamera	Wbudowana w obudowę laptopa
WYMUADM.13.	Bateria	Czas pracy na baterii minimum 3 godziny
WYMUADM.14.	Xxxxxxxx	Xxx
WYMUADM.15.	System operacyjny	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.
WYMUADM.16.	Waga	Max 1,65 kg z baterią (bez napędu optycznego DVD +/- RW)
WYMUADM.17.	Dodatkowe wyposażenie	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
WYMUADM.18.	Rodzaj matrycy	Monitor ciekłokrystaliczny
WYMUADM.19.	Przekątna ekranu	Minimum 21,5 cala
WYMUADM.20.	Maksymalna rozdzielczość	Minimum 1920x1080
WYMUADM.21.	Jasność	Minimum 250 cd/m2
WYMUADM.22.	Kontrast	Minimum 1000:1
WYMUADM.23.	Kąty widzenia (pion/poziom)	Minimum 160/170 stopni
WYMUADM.24.	Złącza	Minimum 1 złącze D-SUB wraz z przewodem, minimum 1 złącze DVI wraz z przewodem, minimum 2 porty USB wraz z przewodem
WYMUADM.25.	Podstawa	Regulowana wysokości, regulowany kąt nachylenia
STACJA DOKUJĄCA (REPLIKATOR PORTÓW)
WYMUADM.26.	Dedykowany replikator portów (nie zajmujący złącza USB) z zasilaczem, umożliwiającym ładowanie baterii laptopa z poziomu stacji dokującej	Wbudowane złącza: minimum 1xVGA, minimum 3xUSB, minimum 1xRJ-45

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
	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
	Oprogramowanie musi być dostarczone w liczbie licencji umożliwiającej przeprowadzenie backupu na wszystkich dostarczonych serwerach w ramach jednej lokalizacji.
	Oprogramowanie musi umożliwiać wykonywanie kopi zapasowych środowisk przyłączonych do sieci ETHERNET z systemami operacyjnymi z rodziny Microsoft Windows oraz Linux
	Oprogramowanie powinno posiadać licencję na backup samego siebie
	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
	Oprogramowanie do tworzenia kopi zapasowych musi posiadać następujące funkcje:
	umożliwiać wykonywania kopii pełnych i przyrostowych, umożliwiać backup pracujących baz danych typu on-line(np. SQL Server, Oracle Database) oraz środowisk wirtualnych (np. VMWare vSphere 5, Citrix XenServer), 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
	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.
	Dostarczone licencje muszą obsługiwać nielimitowaną ilość pamięci RAM.
	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.
	Oprogramowanie do wirtualizacji musi być wspierane przez producenta oferowanych serwerów opisanych w niniejszej specyfikacji oraz współpracować z oferowanym oprogramowaniem zarządzającym.
	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ęć.
	Oprogramowanie do wirtualizacji musi obsługiwać procesory zainstalowane w oferowanych serwerach.
	Oprogramowanie do wirtualizacji musi być umożliwiać dynamiczną zmianę wielkości utworzonych w systemie wolumenów dyskowych.
	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ść).
	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.
	Oprogramowanie do zarządzania wirtualizacyjnymi systemami operacyjnymi musi co najmniej: umożliwiać jednoczesne zarządzanie trzema wirtualizacyjnymi systemami operacyjnymi oraz zainstalowanymi na nich wirtualnymi maszynami. 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). umożliwiać tworzenie profili użytkowników mających prawa tylko do odczytu lub odczytu i zapisu do poszczególnych wirtualizacyjnych systemów operacyjnych. oferować scentralizowany serwer licencyjny, z którego licencje są delegowane na poszczególne wirtualizacyjne systemy operacyjne. monitorować utylizację pamięci, procesorów wirtualizacyjnych systemów operacyjnych jak i samych wirtualnych maszyn.

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
	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.
	Wymaga się dostarczenia licencji dla urządzeń UTM w liczbie pozwalającej na ochronę antywirusową serwerów w ramach danej lokalizacji.
	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, administracyjny interfejs graficzny, konfigurację zakresu oraz poziomu ochrony, zabezpieczenia przed wyłączeniem klienta przez użytkownika stacji roboczej, a w razie złamania tych zabezpieczeń – centralna sygnalizacja wyłączenia klienta, ochronę antywirusową systemu monitorowana i zarządzana z pojedynczej, centralnej konsoli, możliwość instalacji konsoli zarządzania niezależnie na wielu stacjach komputerowych lub serwerach.

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
	Zdalne włączanie/wyłączanie/restart niezależnie dla każdego serwera.
	Zdalne udostępnianie napędu CD-ROM/DVD/ISO na potrzeby każdego serwera z możliwością bootowania z w/w napędów.
	Zdalny dostęp do urządzań z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu.
	W danym momencie musi być niezależny, równoległy dostęp do konsol tekstowych i graficznych wszystkich serwerów w ramach infrastruktury.
	Zdalna identyfikacja fizycznego serwera i obudowy za pomocą sygnalizatora optycznego.
	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, 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: 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). Możliwość kontroli wersji zainstalowanych sterowników/agentów na serwerach, możliwość przeprowadzania uaktualnień sterowników/agentów zdalnie z systemu zarządzania. Możliwość zdalnej reakcji na zdarzenia w infrastrukturze np. poprzez automatyczne wykonywanie skryptów, możliwość automatycznego powiadamiania administratorów przez e-mail. 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. Możliwość monitorowania zużycia energii dla jednego lub grupy serwerów. Możliwość nakładania limitów zużycia mocy na serwer lub grupę serwerów (w ramach możliwości technologii x86-64). Możliwość uzyskania szczegółowych informacji o serwerze odnośnie jego komponentów, firmware, systemu operacyjnego, adresu IP. Monitorowanie utylizacji następujących podzespołów serwera: procesor, pamięć, dyski twarde, interfejsy sieciowe.
	Licencje na powyższą funkcjonalność na serwery dostarczane w ramach jednej lokalizacji.
	Zamawiający wymaga dokumentacji w języku polskim (alternatywnie dopuszcza się język angielskim)..
	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
	System operacyjny musi posiadać architekturę 64 bitową.
	System operacyjny musi pracować w architekturze zgodnej ze standardem x86.
	System operacyjny musi wspierać pamięć RAM co najmniej do wielkości 768GB.
	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.
	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.
	System operacyjny musi pozwolić na prawidłową i bezawaryjną pracę oprogramowanie aplikacyjnego oraz systemowego.
	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.
	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.
	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

Poniżej przedstawiono wymagania dla oprogramowania baz danych.

ID wymagania	Opis wymagania
	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.
	Oferowany motor bazy danych musi posiadać wsparcie producenta realizowane w trybie 24/7 poprzez dedykowany portal internetowy oraz dedykowaną linię telefoniczną
	Dostarczona licencja musi być licencją dożywotnią
	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
	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).
	Oferowany motor bazy danych musi posiadać możliwość przeźroczystego dla aplikacji szyfrowania danych
	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
	Motor bazy danych powinien udostępniać możliwość zrównoleglenia operacji SQL (zapytania, instrukcje DML, ładowanie danych, tworzenie indeksów, przenoszenie tabel/indeksów pomiędzy przestrzeniami danych) oraz procesów wykonywania kopii bezpieczeństwa bądź odtwarzania.
	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.
	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)
	Infrastruktura motoru bazy danych musi posiadać możliwość zarządzania klastrami baz danych

7.5.7.Oprogramowanie serwera aplikacji

ID wymagania	Opis wymagania
	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.
	Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać zarządzanie i monitorowanie wieloma serwerami aplikacyjnymi z jednej konsoli
	Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać zarządzanie i monitorowanie wielu aplikacji wdrożonych na różnych instancjach serwera aplikacyjnego
	Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać zarządzanie klastrami serwerów aplikacyjnych
	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
	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
	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 do porównywania z przyszłymi danymi
	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
	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
	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
	Infrastruktura serwera aplikacji musi posiadać możliwość ograniczenia liczby sesji HTTP w serwerze tworzonych przez daną aplikację
	Infrastruktura serwera aplikacji musi posiadać możliwość rozdziału ruchu (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.
	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.)
	Infrastruktura serwera aplikacji musi posiadać możliwość konfiguracji i zarządzania środowiskiem serwerów aplikacyjnych równocześnie poprzez: konsole webowe, skrypty, programowo, SNMP
	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.)
	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)
	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)
	Infrastruktura serwera aplikacji musi posiadać wbudowany mechanizm automatycznej naprawy transakcji podczas restartu serwera aplikacyjnego
	Infrastruktura serwera aplikacji musi posiadać możliwość zarządzania i monitorowania wieloma serwerami aplikacyjnymi z jednej konsoli
	Infrastruktura serwera aplikacji musi posiadać możliwość zarządzania i monitorowania wielu aplikacji wdrożonych na różnych instancjach serwera aplikacyjnego
	Infrastruktura serwera aplikacji musi posiadać możliwość zarządzania klastrami serwerów aplikacyjnych

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-Transaction and Content Specifications”(dostępny na stronie: xxxx://xxx.xxx.xxx/xxxxxxxxXxxxx/Xxxxxxxxx/XXX/XXX_XXX_XX_Xxx0.xxx)..

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.

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
	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: Przypadki użycia Architekturę komponentów aplikacji Projekt Techniczny Systemu MSIM Plan Wdrożenia Projektu Wykonawca przedstawi do akceptacji Zamawiającemu spis treści Analizy przedwdrożeniowej. 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 Xxxxxxxxxxx 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. 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 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 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: Opis zadań jakie muszą zostać wykonane (kroki) dla nowych jednostek. Przypisaniu zadań do ról/osób. 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 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.
	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 Xxxxxxxxxxx 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.

Każde szkolenie musi być zakończone wypełnieniem ankiet ewaluacyjnych szkolenie. Ankieta musi obejmować x.xx. 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 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:

    1. Wskazanie terminu oraz lokalizacji poszczególnych szkoleń

    2. Imię i nazwisko trenera wiodącego oraz trenera wspierającego

    3. 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:

• Wprowadzenie do Systemu MSIM,

• Omówienie procesu zamawiania dokumentacji i obsługi IKP,

• 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:

• Wprowadzenie do Systemu MSIM,

• 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 e-Rejestracji	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).

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:

   1. Wskazanie terminu oraz lokalizacji poszczególnych szkoleń

   2. Imię i nazwisko trenera wiodącego oraz trenera wspierającego

   3. 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:

    1. wymagane jest dostarczenie materiałów szkoleniowych wytworzonych przez ośrodek certyfikacyjny

    2. 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:

Nazwa szkolenia	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
Akredytowane szkolenie z zakresu dostarczonego serwera aplikacji	3	2	5
Akredytowane szkolenie z zakresu administracji dostarczonej infrastruktury sieciowej	3	2	5
Akredytowane szkolenie z zakresu dostarczonego oprogramowania bazy danych	2	2	5
Akredytowane szkolenie z zakresu dostarczonej usługi katalogowej	1	2	5
Konfiguracja urządzeń sieciowych wykorzystywanych przez system (szkolenia autoryzowany przez producentów zależne od sprzętu dostarczanego przez Wykonawcę).	3	2	5
Administracja systemami operacyjnymi wykorzystywanymi przez system	2	2	5
Administracja bazami danych wykorzystywanymi przez system	2	2	5

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)

• 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 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 oznacza to, że zaakceptował przedstawiony do akceptacji materiał.

3. Wykonawca w terminie 5 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 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ł.

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.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:

1. lista przeprowadzonych szkoleń (nazwa, czas i miejsce szkolenia),

2. liczba osób przeszkolonych na każdym szkoleniu,

3. nazwę osoby szkolącej,

4. czas trwania szkolenia,

5. zakres szkolenia, z załączonymi materiałami,

6. wyniki „Ankiety oceny szkolenia”,

7. oceny z egzaminu weryfikującego przyswojenie wiedzy otrzymane przez poszczególne osoby szkolone,

8. 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:

1. lista przeprowadzonych instruktaży (nazwa, czas i miejsce szkolenia),

2. liczba osób przeszkolonych w ramach instruktażu,

3. nazwę osoby szkolącej,

4. czas trwania szkolenia,

5. zakres szkolenia, z załączonymi materiałami,

6. 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:

1. Zawartość Raportu zgodna ze stanem faktycznym;

2. Liczba odbytych godzin szkoleń oraz instruktaży stanowiskowych zgodna
   z przedmiotem zamówienia;

3. W przypadku szkoleń pozytywna średnia ocena każdego ze szkoleń, potwierdzona wypełnionymi i podpisanymi przez wszystkich uczestników „Ankietami oceny szkolenia”;

4. Lista osób biorących udział w szkoleniu lub instruktaży stanowiskowym potwierdzona podpisami uczestników.

5. 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:

1. akceptacja – produkt szkoleniowy zostaje uznany za odebrany;

2. 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.

9.3.Odbiór

Wykonawca musi przeprowadzić testy zgodnie z opracowanym przez niego i zatwierdzonym przez Xxxxxxxxxxxxx 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)

• 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.

1. Plan testów musi zawierać co najmniej:

• 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.

2. Zamawiający wniesie ewentualne uwagi do przedstawionego Planu testu do 10 dni roboczych.

3. Wykonawca uwzględni uwagi Zamawiającego oraz przekaże poprawiony Plan testów5 dni roboczych.

4. Brak akceptacji Planu testu uniemożliwia rozpoczęcie testów funkcjonalnych danego Komponentu.

5. Plan testów musi obejmować testowanie wszystkich wymagań Systemu, w tym co najmniej następujących funkcji Systemu:

   1. Usługa e-Rejestracja

   2. Repozytorium EDM

   3. Rejestr EDM

6. 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.

7. Plan testów musi zawierać co najmniej:

• 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

8. Zamawiający wniesie ewentualne uwagi do przedstawionego Planu testu do 10 dni roboczych.

9. Wykonawca uwzględni uwagi Zamawiającego oraz przekaże poprawiony Plan testów5 dni roboczych.

10. 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 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 dla eksploatacji dostarczonego rozwiązania w trakcie obowiązywania okresu gwarancji.

ID wymagania	Opis wymagania
	Wykonawca musi informować Zamawiającego pisemnie o wszystkich wymaganych aktualizacjach wszystkich systemów i komponentów dostarczonych w niniejszym zamówieniu.
	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 standardowego oraz dostarczyć opis procedur pozyskiwania informacji o dostępności aktualizacji oraz sposobu instalacji aktualizacji. Wykonawca będzie aktualizował oprogramowanie wchodzące w zakres projektu MSIM do najnowszej obowiązującej wersji.
	Wykonawca musi zapewnić zdalny dostęp do środowiska. Zdalny dostęp musi być realizowany z wykorzystaniem bezpiecznego kanału transmisji opartego o VPN.
	Wykonawca zapewni konsultacje na potrzeby Zamawiającego w ramach eksploatacji zgodnie z wytycznymi Umowy.
	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).

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 –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 –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 aplikacji drogą elektroniczną na wskazany adres e-mail Zamawiającego

• Wykonawca zobowiązany jest do udostępniania nowych poprawek i nowych wersji aplikacji 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 na każde pisemne żądanie wniesione przez Zamawiającego

• Wraz z nową wersją lub nową poprawką, 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 aplikacji działających na środowisku produkcyjnym odbywa się
  w terminach zaproponowanych przez Wykonawcę i zaaprobowanych przez Zamawiającego

• Każda dostarczana aktualizacja 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
AWARIA	24/7/365		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	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.
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 nie później niż 4 dni roboczych od dnia przyjęcia zgłoszenia	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 procedury naprawy przez producenta w chwili przyjęcia zgłoszenia - niezwłocznie nie później niż 4 dni roboczych od dnia udostępnienia przez producenta procedury naprawy.
USTERKA			niezwłocznie nie później niż 3 dni roboczych od dnia przyjęcia zgłoszenia	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	w przypadku, gdy producent zapewnia procedurę naprawy - niezwłocznie nie później niż 14 dni roboczych od dnia przyjęcia zgłoszenia, w przypadku braku procedury naprawy przez producenta w chwili przyjęcia zgłoszenia - niezwłocznie nie później niż 14 dni roboczych od dnia udostępnienia przez producenta procedury 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 aplikacjach biznesowych 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
AWARIA	W dni robocze pomiędzy 700 a 2000. Zgłoszenie przesłane po 2000, traktowane jest jak zgłoszenie przyjęte w następnym dniu roboczym o 700	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
BŁĄD		niezwłocznie nie później niż 1 dni robocze od dnia przyjęcia zgłoszenia	nie dotyczy	niezwłocznie nie później niż 4 dni roboczych od dnia przyjęcia zgłoszenia
USTERKA		niezwłocznie nie później niż 3 dni roboczych od dnia przyjęcia zgłoszenia	nie dotyczy	niezwłocznie nie później niż 14 dni roboczych od dnia przyjęcia zgłoszenia

Definicje klasyfikacji zgłoszenia wad:

1. Awaria – należy przez to rozumieć:

   1. 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.

1. 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.

2. 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.

1. 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).

2. 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.

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 WYKONAWCY	CZAS REAKCJI WYKONAWCY	CZAS NAPRAWY
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 przyjęcia zgłoszenia

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.

12.1.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	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ż 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 x.xx. 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: 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.

13.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.