zaŁĄcznik nr 1 do siwz narodowy i o m s -c ......27 oncentra brachy system planowania leczenia 28...
TRANSCRIPT
Strona 1 z 106
Znak sprawy: PN-14/20/KT
ZAŁĄCZNIK NR 1 DO SIWZ
NARODOWY INSTYTUT ONKOLOGII IM. MARII
SKŁODOWSKIEJ-CURIE – PAŃSTWOWY INSTYTUT
BADAWCZY
OPIS PRZEDMIOTU ZAMÓWIENIA
W PROJEKCIE
„NOWOCZESNY SZPITAL, NOWOCZESNY ZOZ”
Warszawa, 2020
Strona 2 z 106
Spis treści
Rozdział I. Założenia początkowe oraz wymagania ogólne. ............................................ 5
I.1 Wymogi dotyczące interoperacyjności lub migracji dla oferowanego Szpitalnego
Systemu Informatycznego (SSI). ......................................................................................... 5
I.2 Akty prawne ............................................................................................................... 9
I.3 Przedmiot zamówienia ............................................................................................... 9
I.4 Organizacja wdrożenia ............................................................................................ 12
I.4.1 Założenia podstawowe .......................................................................................... 12
I.4.2 Przygotowanie Dokumentacji ............................................................................... 13
I.4.3 Analiza Przedwdrożeniowa ................................................................................... 13
I.4.4 Dokumentacja Powdrożeniowa ............................................................................. 15
I.4.5 Dostawa i instalacja Oprogramowania standardowego ......................................... 18
I.4.6 Dostawa, migracja, instalacja, konfiguracja i wdrożenie Oprogramowania
Szpitalnego Systemu Informatycznego (SSI) .................................................................... 18
I.4.7 Dostawa i instalacja Infrastruktury sprzętowej ..................................................... 18
I.4.8 Godziny RFC (Godziny rozwojowe) .................................................................... 19
I.4.9 Dodatkowe zobowiązania Wykonawcy ................................................................ 19
I.5 Istniejąca infrastruktura ......................................................................................... 19
I.6 Zasady postępowania z pacjentami w ramach współpracy pomiędzy
Narodowym Instytutem Onkologii im. Marii Skłodowskiej-Curie – Państwowym
Instytutem Badawczym a partnerami projektu e-zdrowie „Nowoczesny szpital,
Nowoczesny ZOZ” .............................................................................................................. 22
I.6.1 Pacjenci bez rozpoznania nowotworu dotychczas nieleczeni onkologicznie ....... 22
I.6.2 Pacjenci w trakcie leczenia onkologicznego w Narodowym Instytucie Onkologii
im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym pozostający pod
opieką partnerów projektu w ramach podstawowej opieki zdrowotnej. .......................... 23
I.6.3 Pacjenci w trakcie leczenia onkologicznego w Narodowym Instytucie Onkologii
im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym pozostający pod
opieką partnerów projektu w ramach podstawowej opieki zdrowotnej, którzy mogą
kontynuować leczenie w trybie ambulatoryjnym pod opieką POZ. .................................. 24
I.6.4 Pacjenci w obserwacji po zakończeniu leczenia onkologicznego w Narodowym
Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym
pozostający pod opieką partnerów projektu w ramach podstawowej opieki zdrowotnej. 25
I.6.5 Pacjenci, którzy wyczerpali możliwości leczenia onkologicznego w Narodowym
Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym
skierowani do dalszego leczenia objawowego, pozostający pod opieką partnerów projektu
w ramach podstawowej opieki zdrowotnej. ...................................................................... 26
I.7 Streszczenie zakresu zamówienia ........................................................................... 27
I.8 Ogólne warunki wdrożenia e-Usług oprogramowania SSI .................................. 30
I.9 Baza danych – Wymagania ogólne ......................................................................... 31
Strona 3 z 106
I.9.1 Dane w systemie HIS ............................................................................................ 31
I.9.2 Interfejsy komunikacyjne ...................................................................................... 32
I.9.3 Opis stanu bieżącego ............................................................................................. 32
I.9.4 Zakres i przedmiot migracji bazy danych ............................................................. 34
I.9.5 Migracja danych .................................................................................................... 35
I.9.6 Przebieg procesu migracji ..................................................................................... 36
I.9.7 Asysta techniczna w procesie migracji produkcyjnej ........................................... 38
I.9.8 Testy ...................................................................................................................... 38
I.9.9 Specyficzna procedura odbioru części związanej z migracją danych ................... 42
I.10 Integracja systemu ................................................................................................... 43
I.11 Instruktaże Personelu Zamawiającego .................................................................. 44
I.12 Infrastruktura Sprzętowa – Wymagania ogólne ................................................... 45
Rozdział II. Wymagania szczegółowe ................................................................................ 46
II.1 Oprogramowanie SSI – Wymagania szczegółowe ................................................ 46
II.1.1 HIS ......................................................................................................................... 46
II.1.2 e-Usługi ................................................................................................................. 46
II.1.2.1 Ogólne wymagania techniczne .............................................................................. 46
II.1.2.2 e-Rejestracja .......................................................................................................... 49
II.1.2.3 e-Dokumentacja ..................................................................................................... 52
II.1.2.4 e-Obchód ............................................................................................................... 53
II.1.2.5 e-Powiadomienia ................................................................................................... 55
II.1.2.6 e-Wywiad .............................................................................................................. 56
II.1.2.7 e-Konsultacje ......................................................................................................... 57
II.1.2.8 e-Partner ................................................................................................................ 59
II.1.2.9 e-Informator ........................................................................................................... 61
II.1.2.10. Infokioski .......................................................................................................... 64
II.1.2.10.1 Wymagania systemu ......................................................................................... 64
II.1.2.10.2 Opis techniczny sprzętu .................................................................................... 66
II.1.2.11 Zakres e-usług przewidzianych do wdrożenia u Partnerów projektu ............... 71
II.1.2.12 System wideokonferencji ................................................................................. 71
II.1.3 Repozytorium elektronicznej dokumentacji medycznej (EDM) ........................... 72
II.1.4 Adapter komunikacyjny (konektor) ...................................................................... 74
II.1.5 Szyna Danych - Broker informacyjny ................................................................... 74
II.1.6 Usługi wdrożeniowe i utrzymaniowe .................................................................... 74
II.2 Infrastruktura bazodanowa oraz sprzętowa – Wymagania szczegółowe ........... 75
II.2.1 Baza danych ......................................................................................................... 75
II.2.2 Oprogramowanie do wirtualizacji ..................................................................... 78
II.2.3 Macierz dyskowa ................................................................................................. 79
II.2.4 Długopisy cyfrowe (System Digitalizacji danych z pisma ręcznego) ............. 81
Strona 4 z 106
II.2.5 System operacyjny ............................................................................................... 82
II.2.6 Systemy bezpieczeństwa ...................................................................................... 84
II.2.7 Cloud-computing, koszty utrzymania, w tym zapewnienie dostępu do sieci
Internet dla Cloud-Computing ....................................................................................... 96
III. GWARACJA ........................................................................................................... 100
Strona 5 z 106
Ilekroć w niniejszym dokumencie mowa o: Narodowy Instytut Onkologii należy przez to rozumieć
Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie -Państwowy Instytut Badawczy.
Rozdział I. Założenia początkowe oraz wymagania ogólne.
I.1 Wymogi dotyczące interoperacyjności lub migracji dla oferowanego Szpitalnego Systemu
Informatycznego (SSI).
1) Wykonawca zobowiązuje się dostarczyć Zamawiającemu wymagane funkcjonalności Szpitalnego Systemu
Informatycznego (SSI), poprzez migrację systemu Clininet na bardziej wydajny silnik bazy danych lub
dostawę nowego rozwiązania w taki sposób, aby w jak najszerszym zakresie zostały zaspokojone potrzeby
Zamawiającego. Koniecznym jest zachowanie pełnej wzajemnej interoperacyjności zmigrowanych lub nowo
wdrażanych modułów/grup funkcjonalności, a także w przypadku rozbudowy, pełnej interoperacyjności
z modułami/grupami /systemami funkcjonalności już funkcjonującymi u Zamawiającego.
2) Zarówno w przypadku migracji, jak i dostawy nowego rozwiązania, Wykonawca ma obowiązek zachować
(utrzymać status quo) funkcjonalnie pełną, istniejącą obecnie integrację z systemami i urządzeniami
zewnętrznymi, które nie są przedmiotem wymiany lub rozbudowy w ramach Projektu oraz zapewnić dostęp
do historycznych danych medycznych bezpośrednio za pomocą nowego/zmodernizowanego rozwiązania.
3) W przypadku, gdy Wykonawca dokonuje rozbudowy systemu posiadanego przez Zamawiającego przy
użyciu produktu z innej linii produktowej (rozumianej jako produkt o innej nazwie handlowej lub innym
zarejestrowanym znaku towarowym) Wykonawca zobowiązany jest zaktualizować wszystkie posiadane
przez Zamawiającego moduły systemu do ich najnowszej wersji z linii produktowej wdrażanej jako
rozbudowa. Analogicznie w przypadku wymiany systemu na nowy, Wykonawca zobowiązany jest
dostarczyć wszystkie wymagane i posiadane przez Zamawiającego moduły systemu spełniające
funkcjonalności SSI, w ich jednolitych i najnowszych wersjach z jednej linii produktowej.
4) W przypadku, gdy Wykonawca dokonuje rozbudowy systemu posiadanego przez Zamawiającego przy
użyciu produktu z innej linii produktowej (rozumianej jako produkt o innej nazwie handlowej lub innym
zarejestrowanym znaku towarowym) lub w przypadku wymiany systemu na nowy, Wykonawca
zobowiązany jest do migracji danych z istniejącego systemu klasy HIS (CLININET firmy CGM) oraz
wszystkich innych systemów/modułów/programów, które podlegają wymianie, włącznie z archiwum PACS
5) Szpitalny System Informatyczny, stanowiący źródło Elektronicznej Dokumentacji Medycznej musi mieć
zaimplementowane i uruchomione mechanizmy integracji oraz zapewnić prawidłowe integracje z lokalnym
systemem EDM (firmy CGM), co najmniej poprzez zastosowanie interfejsu zgodnego ze standardem HL7
CDA – Clinical Document Architecture, w wersji v.1 oraz v.2.
6) Stan bieżący posiadanych systemów:
a) Obecnie Zamawiający posiada następujące systemy w ramach Szpitalnego Systemu Informacyjnego:
POSIADANE OPROGRAMOWANIE
LP SYSTEM Zakres Działania
1 CLININET Szpitalny System Informatyczny - część medyczna
2 NETRAAD Szpitalny System Informatyczny - część radiologiczna
3 NETRAAD PACS Szpitalny System Informatyczny - Archiwum Obrazowe
4 STER Ogólnoszpitalny System Rozliczeń z NFZ
5 STER – PSYCHO System Rozliczeń z NFZ - Psychoonkologia
6 CLININET - PSYCHO Szpitalny System Informatyczny - Psychoonkologia
7 SIMPLE.ERP Ogólnoszpitalny System Administracyjny
8 E-SIMPLE Ogólnoszpitalny System Obsługi Grafików Czasu Pracy
9 PROPHIX BI System Klasy Business Inteligence
10 REPORT PORTAL System Raportowania
11 KRN System Obsługi Krajowego Rejestru Nowotworów
12 ESKULAP System Obsługi APTEKI CENTRALNEJ
Strona 6 z 106
13 MARCEL - CENTRUM
System Obsługi MARKERÓW NOWOTWOROWYCH wraz z
udostępnieniem danych przez www (moduł iCentrum). 2 instancje
systemu osobno dla siedziby Ochota i siedziby Ursynów
14 MARCEL - CENTRUM
System Obsługi ZAKŁADU CHEMII KLINICZNEJ wraz z
udostępnieniem danych przez www (moduł iCentrum). 2 instancje
systemu osobno dla siedziby Ochota i siedziby Ursynów
15 MARCEL - CENTRUM
SYSTEM OBSŁUGI SEROLOGII I BANKU KRWI wraz z
udostępnieniem danych przez www (moduł iCentrum)
16 ALTERIS - PACS SYSTEM OBSŁUGI PRACOWNI MAMMOGRAFII
17 SYNEKTIK - PACS SYSTEM PACS ZAKŁADU RADIODIAGNOSTYKI
18 INTRARIS SYSTEM RIS ZAKŁADU MEDYCYNY NUKLEARNEJ
19 ATD SYSTEM OBSŁUGI ZAKŁADU MIKROBIOLOGII KLINICZNEJ
20 NETRAAD PACS SYSTEM OBSŁUGI ZAKŁAD TELERADIOTERAPII
21 GASTRO SYSTEM OBSŁUGI KLINIKA GASTROENTEROLOGII
22 SECTRA PACS SYSTEM OBSŁUGI ZAKŁADU MEDYCYNY NUKLEARNEJ
23 ARIA - VARIAN SYSTEM OBSŁUGI ZAKŁADU TELERADIOTERAPII
24 MOSAIC System Zarządzania i weryfikacji leczenia - Zakład Teleradioterapii
25
ONCENTRA EXTERNAL
BEAM System Planowania Leczenia
26 MONACO System Planowania Leczenia
27 ONCENTRA BRACHY System Planowania Leczenia
28 SIPBP System Informatyczny Programu Badań Przesiewowych
29 PRNK System Rejestru Guzów Gości
30 RKGIST System Rejestru GIST
31 KRPB System Rejestru Przełyku Baretta
32 ENDOBASE System Obsługi Zakładu Brachyterapii
33 PATARCH System Obsługi Zakładu Patologii
34 ONKOSYS – Portal SharePoint 2013
35
ONKOSYS – Sekretariat
Naukowy Repozytorium naukowe danych
36 ONKOSYS – Hurtownia danych Baza danych i hurtownia danych SAS, narzędzia analityczne SAS
37 ONKOSYS – MSD MedStream Designer - Preselekcja Pacjentów
36 SYNGOVIA PACS Zakładu RTG
37 DOSEWATECH System zarządzania dawkami napromieniowania pacjenta
7) Dostawa oprogramowania bazodanowego niezbędnego do użytkowania Oprogramowania SSI:
a) Zamawiający wymaga dostarczenia przez Wykonawcę motoru bazy danych, niezbędnego do pracy
dostarczonego Oprogramowania SSI.
Zamawiający oczekuje migracji danych z użytkowanych dotychczas systemów do nowego SSI.
Systemy podlegające migracji: CliniNet, STER, CliniNet – Psycho, STER-Psycho i NetRAAD. Zamawiający
oczekuje, że wykonawca zmigruje wszystkie dane ze wskazanych systemów.
Zamawiający oczekuje w ramach postępowania podłączenie przez Wykonawcę do SSI obecnie
wykorzystywanych nw. aparatów. Integracja musi być przeprowadzona co najmniej w zakresie przekazywania
zleceń (worklist) i wyników.
Strona 7 z 106
OPIS POSIADANYCH URZĄDZEŃ MEDYCZNYCH
Warszawa, ul. W.K. Roentgena 5
Zakład Radiologii I
WYKAZ APARATÓW REZONANSU MAGNETYCZNEGO
APARATY MR MODEL NR FABRYCZNY ROK PRODUKCJI ROK (data)
MONTAŻU
MR 1 General
Electric
SIGNA
ARCHITECT UA 0922 2018 2018
MR 2 Siemens Magnetom Skyra 46146 2015 2016
MR 3 Siemens Magneton Aera 141830 2018 2018
WYKAZ APARATÓW TOMOGRAFI KOMPUTEROWEJ
APARATY TK MODEL NR FABRYCZNY ROK
PRODUKCJI
ROK (data)
MONTAŻU
CT1 GENERAL
ELECTRIC Revolution EVO CBCGG 1800098HM 2018 2018
CT2 SIEMENS Somatom Definition
AS 95251 2014 2015
CT3 SIEMENS SomatomDefinition
AS 95764 2016 2016
GE System CT Discovery RT CBCIG1700042HM 2017 2017
Simens Somaton Sensation 8872017K1627/49694 2009 2009
GENERAL
ELECTRIC Hispeed DX/I 748109YM6 2001 2001
WYKAZ APARATÓW MAMMOGRAFICZNYCH
APARATY MAMMO. MODEL NR
FABRYCZNY
ROK
PRODUKCJI
ROK (data)
MONTAŻU
General electric aparat
do biopsji
Mammmate
MAMMOTEST
MMT100
mmt 100 0217
022 2017 2018
Strona 8 z 106
Hologic/Lorad SELENIA 28410072345 2007 2008
GENERAL ELECTRIC Senografe PRISTINA
3d 5582323 2017 2018
WYKAZ APARATÓW DO RADIODIAGNOSTYKI OGÓLNEJ
APARATY RTG MODEL NR
FABRYCZNY
ROK
PRODUKCJI
ROK (data)
MONTAŻU
AGFA ( KLP) DR 600 FN 01140 2018 2018
SIEMENS (KOSTNY) Axiom Luminos d RF 4116 2012 2013
SIEMENS
(KONTRASTY)
AXIOM ICONOS
R200 5170 2007 2008
SIEMENS
Przyłóżkowy Mobilet XP Hybrid 2661 2010 2010
Shimadzu przyłóżkowy Mobile Art Evolution 162592704 2010 2010
SIEMENS R-C Siremobil Compact L 3162 2005 2012
WYKAZ APARATÓW DO DIAGNOSTYKI
APARAT USG MODEL NR FABRYCZNY ROK
PRODUKCJI
ROK (data)
MONTAŻU
Samsung WS80A S15GM3HJC00002J 2017 2017
Hitachi H Vision Preirus G3101613A 2017 2017
Hitachi
EUB7500 KE12534801 2007 2008
Hitachi
H Vision Preirus G310010715 2015 2015
Hitachi H Vision Preirus G31002915 2015 2015
AX Plorer Ultimate MS98XT21 2017 2017
Philips HD15 US21420204 2014 2014
Strona 9 z 106
APARAT USG MODEL NR
FABRYCZNY ROK
PRODUKCJI ROK (data)
MONTAŻU
Hitachi Vision Preirus G310042515 2015 2015
Acuson S2000 208644 2013 2013
Hitachi Avius G320001818 2018 2018
8) Dostawa, instalacja i uruchomienie Infrastruktury Sprzętowej i niezbędnej do prawidłowego funkcjonowania
zamawianych licencji Oprogramowania Szpitalnego Systemu Informatycznego (SSI) w zakresie:
Nazwa Ilość
Macierz 1
Serwery wspomagające do
macierzy 2
Infokioski 17
Długopisy cyfrowe(System
digitalizacji danych
z pisma ręcznego)
130
Baza Danych 1x DB SE2 RAC na dwóch Appliance*,
1 - dla e-usług w chmurze
System operacyjny
2x dla wirtualizacji na Appliance do bazy danych. 4x dla serwerów
e-usług w chmurze, 1x dla wirtualizacji na potrzeby obsługi
długopisów cyfrowych/systemu digitalizacji danych z pisma ręcznego
Oprogramowanie do
wirtualizacji
1 - dla klastra Appliance 2 srv x 1CPU)
Szczegółowy opis wymaganych parametrów sprzętu znajduje się w Rozdziale II.
I.2 Akty prawne
Dostarczone rozwiązania teleinformatyczne, ze szczególnym uwzględnieniem dostarczanego i wdrażanego
Oprogramowania, muszą być zgodne z powszechnie obowiązującymi przepisami prawa polskiego
i europejskiego. Musi pozwalać na gromadzenie, przetwarzanie i analizowanie danych i informacji w obszarach
objętych wdrożeniem, na bazie tych danych musi umożliwiać wytwarzanie prawidłowej, kompletnej, ujętej
w obowiązujących przepisach prawa dokumentacji (dokumenty, raporty, wykazy, oświadczenia, zaświadczenia
itp.).
I.3 Przedmiot zamówienia
Przedmiotem zamówienia niniejszego postępowania przetargowego jest przeniesienie funkcjonalności systemu
HIS na nową, wydajniejszą bazę danych wraz z migracją danych oraz dostawa i wdrożenie infrastruktury
sprzętowej oraz e-usług wraz z repozytorium EDM - zgodnie z asortymentem i ilościami oraz warunkami
określonymi w Rozdziale II niniejszego Opisu Przedmiotu Zamówienia w Narodowym Instytucie Onkologii im.
Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym w Warszawie i Partnerów projektu, a w tym:
1) Wdrożenie lokalnych e-usług
a) licencje na e-usługi dla Narodowego Instytutu Onkologii im. Marii Skłodowskiej–Curie –
Państwowego Instytutu Badawczego w Warszawie,
b) repozytorium Elektronicznej Dokumentacji Medycznej,
c) Adapter komunikacyjny (konektor),
d) Szyna Danych - Broker informacyjny,
e) przeglądarka rekordu medycznego EHR,
f) System operacyjny,
Strona 10 z 106
g) Bazy danych,
h) System wideokonferencyjny
2) Zakup usług informatycznych
a) Usługi wdrożeniowe i utrzymaniowe,
b) Usługi programistyczne i migracji bazy danych,
c) Cloud-computing.
3) Zakup infrastruktury sprzętowej IT wraz z oprogramowaniem
a) Długopisy cyfrowe (System digitalizacji danych z pisma ręcznego),
b) Info-kioski „małe” wewnętrzne i „duże” zewnętrzne,
c) Macierz
d) Serwery wspomagające do macierzy,
e) System bezpieczeństwa typ 1 - Firewall Partnerzy Projektu,
f) System bezpieczeństwa typ 2 - Web Application Firewall – Centrum Danych,
g) System bezpieczeństwa typ 3 - Databease Firewall – Centrum Danych,
h) System bezpieczeństwa typ 4 - Firewall – Centrum Danych,
i) System bezpieczeństwa typ 5 - Firewall – Narodowy Instytut Onkologii
4) Utrzymanie projektu
a) Koszty utrzymania, w tym zapewnienie dostępu do sieci internet dla CloudComputing.
5) Przedmiot zamówienia musi być dostarczany i wdrożony w całości do siedziby Zamawiającego lub innych
lokalizacji wskazanych przez Zamawiającego.
6) Wszystkie dostarczane:
- Produkty (rozumiane jako elementarny efekt działań/prac/dostaw objętych całym zakresem Przedmiotu
Zamówienia wykonywanych przez Wykonawcę podczas realizacji Umowy w poszczególnych Etapach)
- Komponenty (rozumiane jako integralna część dostawy i wdrożenia Przedmiotu Zamówienia, składający
się przynajmniej z jednego Produktu lub wielu Produktów powiązanych ze sobą merytorycznie) podlegają
usługom projektowania, dostaw, instalacji, konfiguracji i wdrożenia.
7) Usługi projektowania, instalacji, konfiguracji i wdrożenia Wykonawca przeprowadzi zgodnie z zapisami OPZ
w uzgodnieniu z Zamawiającym zgodnie z obowiązującymi przepisami, zasadami wykonywania projektów
teleinformatycznych oraz najlepszymi praktykami w ich realizacji.
8) Wykonawca jest zobowiązany do realizacji Przedmiotu Zamówienia zgodnie z zasadami i wytycznymi
Zamawiającego, zapisami OPZ oraz Umowy, jak również obowiązującymi normami technicznymi
i przepisami prawa.
9) Ilekroć w niniejszym OPZ Zamawiający użył w opisie oznaczeń norm, aprobat, specyfikacji technicznych
i systemów odniesienia, o których mowa w art. 30 ust. 1-3 PZP należy je rozumieć jako przykładowe.
Zamawiający zgodnie z art. 30 ust. 4 ustawy PZP dopuszcza produkty równoważne opisywanym w treści
SIWZ. Jeżeli zapisy zawarte w Załączniku nr 2 wskazywałyby w odniesieniu do rozwiązań, materiałów lub
urządzeń znaki towarowe lub pochodzenie Zamawiający, zgodnie z art. 29 ust. 3 ustawy PZP, dopuszcza
składanie ofert na „produkty” równoważne. Wszelkie „produkty” pochodzące od konkretnych producentów
określają minimalne parametry jakościowe i cechy użytkowe, jakim musi odpowiadać produkt, aby spełnić
wymagania stawiane przez Zamawiającego i stanowią wyłącznie wzorzec jakościowy przedmiotu zamówienia.
Poprzez zapis dot. minimalnych wymagań parametrów jakościowych Zamawiający rozumie wymagania
materiałów, sprzętu i urządzeń zawarte w ogólnie dostępnych źródłach, katalogach, stronach internetowych
producentów. Operowanie przykładowymi nazwami producenta ma jedynie na celu doprecyzowanie poziomu
oczekiwań Zamawiającego w stosunku do określonego rozwiązania. Tak więc posługiwanie się nazwami
producentów /produktów/ ma wyłącznie charakter przykładowy. Zamawiający, przy opisie przedmiotu
zamówienia, wskazując oznaczenie konkretnego producenta (dostawcy) lub konkretny produkt, dopuszcza
jednocześnie produkty równoważne o parametrach jakościowych i cechach użytkowych, co najmniej na
poziomie parametrów wskazanego produktu, uznając tym samym każdy produkt o wskazanych parametrach
lub lepszych. W takiej sytuacji Zamawiający wymaga złożenia stosownych dokumentów, wykazujących
spełnienie przez produkty równoważne ww. parametrów i cech.
10) Wykonawca musi dostarczyć wszelkie urządzenia, licencje i elementy, które są niezbędne do prawidłowego
funkcjonowania całości. W przypadku, gdy w trakcie realizacji Przedmiotu Zamówienia, okaże się, że brakuje
jakiegokolwiek urządzenia, licencji i/lub elementu, którego brak spowoduje nieprawidłowe funkcjonowanie
całości Przedmiotu Zamówienia, Wykonawca dostarczy je na własny koszt.
11) W przypadku wymiany systemu Wykonawca jest zobowiązany dostarczyć liczbę licencji na poszczególne
moduły nie mniejszą niż Zamawiający posiada obecnie w użytkowanym systemie CliniNet firmy CGM.
12) Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy jest jednostką
badawczo-rozwojową prowadzącą działalność naukową, edukacyjną oraz podyplomową w związku z
powyższymi przysługuje Narodowemu Instytutowi Onkologii im. Marii Skłodowskiej-Curie – Państwowemu
Instytutowi Badawczemu prawo do zakupu licencji edukacyjnych. Wykonawca zobowiązany jest do
weryfikacji liczby i rodzaju dostarczanych licencji.
13) Wykonawca jest zobowiązany zapewnić funkcjonalność systemu zgodnie z obowiązującymi przepisami prawa
ze szczególnym uwzględnieniem:
Strona 11 z 106
Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (t.j. Dz. U. z 2019 r.
poz. 1127 z późn. zm. dalej jako: „u.p.p.” lub „Ustawa o prawach pacjenta”);
Ustawa z dnia 9 października 2015 roku o zmianie ustawy o systemie informacji ochronie zdrowia
i niektórych innych ustaw Dz. U. 2015 poz. 1991 z późn. zm. (dalej jako: „Nowelizacja z dnia
9 października 2015 roku u.s.i.o.z. i niektórych innych ustaw”);
Obwieszczenie Marszałka Sejmu Rzeczypospolitej Polskiej z dnia 22 lutego 2019 r. w sprawie
ogłoszenia jednolitego tekstu ustawy o systemie informacji w ochronie zdrowia (tj. Dz. U. 2015 poz. 408
z późn. zm. dalej jako „u.s.i o.z.)
Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (t.j. Dz. U. 2019 r. poz. 730. dalej jako:
„Ustawa o ochronie danych osobowych” lub „u.o.d.o”);
Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (tj. Dz. U. z 2019 r. poz. 123
z późn. zm., dalej jako: „u.ś.u.d.e.” lub „Ustawa o świadczeniu usług drogą elektroniczną”)
Ustawa z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (tj. Dz. U. 2019 r. poz. 643 z późn. zm., dalej
jako: „Prawo telekomunikacyjne”);
Rozporządzenie Ministra Zdrowia z dnia 9 listopada 2015 r. w sprawie rodzajów, zakresu i wzorów
dokumentacji medycznej oraz sposobu jej przetwarzania (Dz.U. z 2015 r. poz. 2069, dalej jako:
„Rozporządzenie ws. dokumentacji medycznej”);
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie
ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego
przepływu takich danych oraz uchylenia dyrektywy 95/46/WE warunkujące odpowiednie środki
techniczne i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający ryzyku naruszenia,
(dalej jako r.p.e.rodo).
14) Wykonawca jest zobowiązany zapewnić funkcjonalność systemu zgodnie z obowiązującymi
przepisami prawa w tym również w zakresie e-recepty i e-zwolnienia, e-skierowania. 15) Wykonawca jest zobowiązany do integracji funkcjonalnej z centralnym systemem eZdrowie
i obowiązującymi przepisami prawa w tym również w zakresie e-recepty, e-zwolnienia, e-skierowania
(dokumenty na stronie http://csioz.gov.pl. https://ezdrowie.gov.pl/portal/artykul/dokumentacja-integracyjna-
dla-obszaru-zdarzen-medycznych-i-indeksow-edm-czesc-pierwsza):
a) dostarczony system musi zapewnić integrację funkcjonalną z systemem teleinformatycznym, o którym
mowa w art. 7 ust. 1 ustawy o systemie informacji w ochronie zdrowia (tj. Dz. U. z 2019 r. poz. 408
z późn. zm.), co najmniej w zakresie opisanym w dokumentach: „Opis usług biznesowych Systemu P1
wykorzystywanych w systemach usługodawców” oraz „Opis funkcjonalny Systemu P1 z perspektywy
integracji systemów zewnętrznych” opublikowanych przez CSIOZ.
b) zakresie integracji i komplementarności z centralnymi systemami e-zdrowia, na Wykonawcy będzie
spoczywał obowiązek dostosowania zaoferowanego rozwiązania do wymagań ujętych w dokumentach
publikowanych poprzez CSIOZ, w tym w szczególności do:
- Zakresu funkcjonalnego Projektu P1 (system musi posiadać m.in. możliwość wystawiania recept
elektronicznych oraz skierowań elektronicznych),
- Opisu funkcjonalnego Systemu P1 z perspektywy integracji systemów zewnętrznych,
- Minimalne wymagania dla systemów usługodawców oraz dokumentacja integracyjna dla obszaru
Zdarzeń Medycznych i Indeksów EDM.
16) W zakresie integralności zaoferowanego Systemu, Wykonawca powinien uwzględnić i w razie
obowiązującego wymogu wdrożyć poniższe wytyczne i założenia:
a) System P1 dostępny będzie dla odpowiednio zarejestrowanych w CSIOZ systemów usługodawców
i systemów regionalnych wyłącznie poprzez standardowe interfejsy Web Services. Wymagane
jest dwustronne uwierzytelnianie systemów nawiązujących komunikację, a także podpisywanie
komunikatów certyfikatem dostarczanym bądź wskazanym przez CSIOZ.
b) Komunikaty przesyłane do P1 powinny być podpisane elektronicznie przez system komunikujący
się z Systemem P1 certyfikatem wydanym przy zakładaniu konta usługodawcy (rejestrowaniu
systemu). Wymagania w zakresie rodzaju stosowanego certyfikatu mogą ulec zmianie w wyniku
wejścia w życie Rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 910/2014 z dnia 23
lipca 2014r. w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji
elektronicznych na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE (rozporządzenie
eIDAS) oraz/lub wprowadzenia centralnych rozwiązań w zakresie uwierzytelniania
użytkowników w obszarze e-zdrowia.
c) W przypadku informacji o zdarzeniu medycznym – obowiązuje Model Informacji o Zdarzeniu
Medycznym i Indeksie Dokumentacji Medycznej (dalej: EDMiZM) publikowany przez CSIOZ.
d) W przypadku rejestru (indeksu) elektronicznej dokumentacji medycznej – obowiązuje EDMiZM
publikowany przez CSIOZ
e) Zgoda pacjenta na udostępnienie jego dokumentacji medycznej – funkcjonalność ta jest wymagana
i powinna być zgodna z modelem dokumentu zgody oraz modelami interfejsów pozwalających na
wnioskowanie o zgodę, które zostaną opublikowane przez CSIOZ.
Strona 12 z 106
f) Wymiana elektronicznej dokumentacji medycznej (dalej: EDM) – funkcjonalność ta jest wymagana
i powinna być zgodna z modelem wniosku i dokumentu udostępnienia oraz modelami interfejsów,
które zostaną opublikowane przez CSIOZ.
g) Jednocześnie, zaoferowany System powinien spełniać następujące założenia funkcjonalne:
- Prowadzenie i wymianę Elektronicznej Dokumentacji Medycznej (EDM), w tym indywidualnej
dokumentacji medycznej (wewnętrznej, zewnętrznej), uwzględniać musi rozwiązania umożliwiające
zbieranie przez podmiot udzielający świadczeń opieki zdrowotnej jednostkowych danych
medycznych w elektronicznym rekordzie pacjenta oraz tworzenie EDM zgodnej co najmniej ze
standardem HL7 CDA, opracowanym i opublikowanym przez CSIOZ – Polską Implementacją
Krajową HL7 CDA (tzw. IG).
- System powinien uwzględniać funkcjonalności dotyczące prowadzenia repozytorium EDM
(z obsługą przechowywania EDM) oraz uwzględniać rozwiązania zapewniające wymianę EDM
pomiędzy repozytorium Zamawiającego a Platformą P1. Platforma P1 będzie zawierała katalog
EDM, w którym znajdować się będą informacje o EDM, tworzonym i przechowywanym
u Zamawiającego.
- Repozytorium EDM powinno realizować, co najmniej usługę przyjmowania, archiwizacji
i udostępniania EDM zgodnej z HL7 CDA, a w przypadku repozytoriów badań obrazowych,
przyjmowania, archiwizacji i udostępniania obiektów DICOM.
17) Zaoferowany Szpitalny System Informatyczny musi być dostosowany do współpracy z systemem, o którym
mowa w art. 17 Ustawy z dnia 22 sierpnia 1997 r. o publicznej służbie krwi (Dz. U. z 2019 r. poz. 1222).
18) W przypadku istnienia takiego wymogu w stosunku do technologii objętej przedmiotem niniejszego
postępowania (tzw. produkty podwójnego zastosowania), Dostawca winien przedłożyć dokument
pochodzący od importera tej technologii stwierdzający, iż przy jej wprowadzeniu na terytorium Polski,
zostały dochowane wymogi właściwych przepisów prawa, w tym ustawy z dnia 29 listopada 2000 r. o obrocie
z zagranicą towarami, technologiami i usługami o znaczeniu strategicznym dla bezpieczeństwa państwa,
a także dla utrzymania międzynarodowego pokoju i bezpieczeństwa (tj. Dz. U. z 2019 r. poz. 953 z późn.
zm.) oraz dokument potwierdzający, że importer posiada certyfikowany przez właściwą jednostkę system
zarządzania jakością tzw. wewnętrzny system kontroli wymagany dla wspólnotowego systemu kontroli
wywozu, transferu, pośrednictwa i tranzytu w odniesieniu do produktów podwójnego zastosowania.
19) Wykonawca winien przedłożyć oświadczenie producenta lub autoryzowanego dystrybutora producenta na
terenie Polski, iż oferent posiada autoryzację producenta w zakresie sprzedaży oferowanych rozwiązań.
I.4 Organizacja wdrożenia
I.4.1 Założenia podstawowe
1) Przedmiot Zamówienia będzie realizowany w oparciu o zdefiniowany uprzednio przez Wykonawcę
i zaakceptowany Harmonogram wdrożenia dla Zamawiającego, który powinien być uzgodniony
i zaakceptowany przez Zamawiającego oraz odpowiednio utrzymywany w toku realizacji Przedmiotu
Zamówienia.
2) Wykonawca w Harmonogramie wdrożenia musi uwzględnić w szczególności podział na zadania takie jak
projektowanie, dostawy, usługi instalacji/konfiguracji, testowanie, migracja, wdrożenie i odbiory.
3) Zamawiający dopuszcza możliwość zmiany przez Wykonawcę Harmonogramu po jego zatwierdzeniu
w sytuacji, gdy taka zmiana będzie konieczna z uwagi na przebieg realizacji etapów określonych w § 9 umowy
stanowiącej załącznik nr 6 do SIWZ.
4) Każda zmiana Harmonogramu wymaga akceptacji Zamawiającego. Zmiana Harmonogramu nie może
wpłynąć na termin realizacji przedmiotu umowy wskazanego w § 3 ust. 1 umowy stanowiącej załącznik nr 6
do SIWZ.
5) Wykonawca umożliwi Zamawiającemu udział we wszystkich pracach realizowanych przez Wykonawcę
w ramach realizacji Przedmiotu Zamówienia (m.in. w czasie projektowania, dostawach, instalacji/budowie,
konfiguracji, migracji, wdrożeniu i testowaniu).
6) Wykonawca zobowiązany jest przeprowadzić dostawy Przedmiotu Zamówienia w dokładnych terminach
i godzinach uzgodnionych z danym Zamawiającym.
7) Infrastruktura sprzętowa musi być oznakowana w taki sposób, aby możliwa była identyfikacja systemowa
zarówno produktu jak i producenta.
8) Oferowane Produkty muszą pochodzić z oficjalnych kanałów dystrybucji producentów.
9) Nośniki z Oprogramowaniem oraz Infrastruktura sprzętowa muszą być dostarczone Zamawiającemu
w oryginalnych opakowaniach fabrycznych.
10) Wdrożenie należy rozumieć jako szereg uporządkowanych i zorganizowanych działań mających na celu
wykonanie Przedmiotu Zamówienia.
11) Wdrożenie będzie realizowane w ramach powołanych do tego celu struktur organizacyjnych po stronie
Wykonawcy.
12) Wdrożenie, muszą realizować osoby wymienione w ofercie Wykonawcy, przy czym:
a) Osoby Zespołu Zarządzania muszą być dyspozycyjne w trakcie wykonywania prac,
Strona 13 z 106
b) Wykonawca przekaże Zamawiającemu wykaz numerów telefonów kontaktowych do osób biorących
udział w realizacji Przedmiotu Zamówienia po stronie Wykonawcy,
13) Wykonawca zorganizuje prace tak, aby w maksymalnym stopniu nie zakłócać ciągłości funkcjonowania
Podmiotu Leczniczego (Zamawiający, partnerzy).
14) Wykonawca dostarczy i zapewni bieżącą obsługę podczas trwania Umowy poprzez aplikację internetową
będącą Systemem zgłoszeń i obsługi Wad oraz stanowiącą repozytorium Dokumentacji dla potrzeb realizacji
Przedmiotu Zamówienia.
15) Obiekty podlegające inwestycji (obiekty służby zdrowia w których świadczone są usługi medyczne) są
użytkowane w trybie ciągłym w czasie godzin pracy przez cały okres wykonywania Przedmiotu Zamówienia,
co może powodować utrudnienia w miejscu prowadzenia prac. Nie ma możliwości całkowitego wyłączenia
i zamknięcia w/w obiektów lub ich części na czas realizacji Przedmiotu Zamówienia. Poszczególne prace
będą realizowane etapowo, tak aby zachować ciągłość świadczenia usług medycznych.
16) Wykonawca musi uwzględnić, że wszystkie prace wykonywane będą w użytkowanych obiektach przy dużym
ruchu pracowników i chorych, tzn. organizacja prac powinna przede wszystkim zapewniać bezpieczeństwo
przebywających w oddziałach pracowników i chorych oraz zachowanie ciszy nocnej w godzinach właściwych
dla Zamawiającego. Uchybienia w wyżej wymienionym zakresie mogą zostać uznane za nienależyte
wykonywanie Umowy.
I.4.2 Przygotowanie Dokumentacji
1) W ramach procesu wdrożenia Wykonawca opracuje dla Zamawiającego - Dokumentację, która składa się
z dwóch zakresów:
a) Dokumentacja Analizy Przedwdrożeniowej DAP wraz ze szczegółowym Harmonogramem wdrożenia,
b) Dokumentacja Powdrożeniowa.
2) Dokumentacja powyższa będzie stanowić bazowe zapisy opisujące budowany/zbudowany System oraz
sposób organizacji prac i wdrożenia. Na podstawie zapisów w Dokumentacji będą prowadzone i odbierane
poszczególne zadania realizowane przy budowie Systemu. Dokumenty te wraz z SIWZ będę stanowiły
podstawę do weryfikacji funkcjonalnej i jakościowej Systemu w trakcie odbiorów.
3) Dokumentacja podlega uzgadnianiu i akceptacji Zamawiającego. Akceptacja Dokumentacji Analizy
Przedwdrożeniowej DAP warunkuje rozpoczęcie prac Wykonawcy.
I.4.3 Analiza Przedwdrożeniowa
1) Analiza Przedwdrożeniowa zostanie opracowana w oparciu o wymagania określone w OPZ wraz
z załącznikami lub o funkcjonalności będące w standardzie Szpitalnego Systemu Informatycznego (SSI)
określone w Opisie Przedmiotu Zamówienia (jeżeli dotyczy).
2) Dokumentacja Analizy Przedwdrożeniowej (DAP) powinna zawierać w szczególności:
Skład DAP
Szpitalny System Informatyczny (SSI)
wykaz oraz szczegółowy opis i harmonogram budowy Systemu
architekturę Systemu
analizę migracji danych oraz opis sposobu migracji danych na wydajniejszą bazę danych
przygotowanie planu instalacji infrastruktury sprzętowej
przygotowanie planu dostawy i instalacji macierzy dyskowych
jednoznacznie określone założenia integracji z innymi systemami informatycznymi, które posiada Zamawiający
plan pracy na poszczególne etapy Wdrożenia
plan migracji danych z SSI, który posiada Zamawiający
szczegółową specyfikację oprogramowania objętego zakresem umowy
wykaz oraz szczegółowy opis i harmonogram niezbędnych prac konfiguracyjnych
ustawienia konfiguracyjne urządzeń i oprogramowania wchodzących w skład SSI
dokumentacja planowanych testów systemu
harmonogram instruktażu personelu oraz administratorów SSI
Strona 14 z 106
sposób komunikacji i autoryzacji użytkowników HIS w EDM w sposób nie powielający metod uwierzytelniania
stosowanych w szpitalu – SSO
interfejs komunikacyjny API systemu szpitalnego Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego do systemów EDM i e-Usług, który powstanie na podstawie specyfikacji
formatów danych i standardów stosowanych w lokalnych systemach HIS i Repozytorium Elektronicznej
Dokumentacji Medycznej. Interfejs komunikacyjny, zaproponowany przez Wykonawcę musi zostać załączony jako
część analizy przedwdrożeniowej
Baza danych
W zakresie analizy przedwdrożeniowej Wykonawca zobowiązany będzie do:
1. Przeprowadzenia audytu istniejącego rozwiązania celem identyfikacji i inwentaryzacji konfiguracji
elementów niestandardowych systemu HIS użytkowanego przez Zamawiającego w szczególności:
a. Raportów
b. Wydruków
c. Formularzy
d. Integracji z innymi systemami
e. Bieżącej konfiguracji systemu HIS
f. Konfiguracji procedur backupu systemu HIS
g. Udostępniania widoków baz danych
h. Zasilania hurtowni danych ONKO.SYS i systemu MedStream Designer
Wszystkie elementy wynikające z audytu zostaną uwzględnione w planie migracji systemu. Warunkiem
zaakceptowania planu migracji, a następnie jej realizacji jest pełne odtworzenie istniejącej funkcjonalność obecnego
systemu również w zakresie elementów niestandardowych wymienionych w pkt a, b, c i e.
2. Opracowania planu migracji – Plan migracji będzie opisywał proces migracji danych z obecnie użytkowanej
bazy do wydajniejszej bazy danych dostarczanej w ramach tego zamówienia i będzie zawierał minimum
następujące elementy:
a. Wskazanie osób odpowiedzialnych za realizację planu i poszczególnych zadań po stronie
Wykonawcy.
b. Wskazanie zadań leżących po stronie Wykonawcy.
c. Szczegółowy harmonogram planowanych prac ze szczególnym uwzględnieniem sytuacji,
w której obecnie użytkowany system będzie niedostępny. Wykonawca zobowiązany jest do takiego
zaprojektowania prac by zachowana została ciągłość działania systemu HIS po stronie Zamawiającego.
Jeżeli z przyczyn technicznych będą konieczne przerwy działania systemu muszą odbywać się poza
godzinami pracy Poradni – tj. po godzinie 19:00 do 07:00 oraz zaplanowane
w taki sposób by ich wpływ na proces leczenia był jak najmniejszy i każdorazowo akceptowane przez
Kierownika Projektu ze strony Zamawiającego.
d. Opis procesu migracji danych zawierający:
i. Opis metadanych, które będą podlegały procesowi migracji.
ii. Opis procesu „czyszczenia” słowników i rejestrów systemu HIS.
iii. Opis skryptów pobierających dane z obecnego systemu.
iv. Opis procesu eksportu danych z obecnej bazy danych.
v. Opis procesu importu danych do nowej, wydajniejszej bazy danych.
vi. Opis procedury testowania poprawności migracji danych.
vii. Opis procedury testowania poprawności działania funkcji systemu.
viii. Opis procedury testowania elementów dodatkowych: raportów, wydruków, integracji
z innymi systemami.
ix. Wzór raportu z migracji systemu.
e. Opracowanie projektu technicznego migracji systemu HIS zawierającego:
i. Opis docelowej konfiguracji systemu (bazy danych, serwerów aplikacyjnych, sieci itp.).
ii. Plan uzyskania docelowej infrastruktury systemu HIS.
3. Opracowanie planu testów akceptacyjnych migracji systemu zawierającego:
a. Plan testów
b. Scenariusze testowe
Wykonawca po przeprowadzaniu procesu migracji testowej systemu na wydajniejszą bazę danych przedstawia raport
z migracji wg szablonu uzgodnionego na etapie analizy przedwdrożeniowej oraz zgłasza gotowość systemu do testów
funkcjonalnych. Raport z migracji musi dokumentować poprawność przeprowadzenia procesu migracji testowej w
szczególności kompletność przeniesionych danych.
Szczegółowe wymagania w zakresie testów i dokumentów testowych zostały przedstawione w rozdziale „Testy
migracji systemu”.
Pkt I.9.5 OPZ stosuje się tylko w wypadku migracji samej bazy danych, w przypadku migracji systemu HIS razem z
bazą danych jako równoważnik, załącznik ten traci ważność, a Wykonawca ma obowiązek zaproponowania procesu
i zakresu migracji systemu i bazy danych w analizie przedwdrożeniowej. Nie zwalnia to jednak Wykonawcy z pełnej
migracji danych wymienionych w tym punkcie.
Strona 15 z 106
Działania związane z zarządzaniem projektem
plan i sposób komunikacji Stron
plan zarządzania jakością w Projekcie
plan zarządzania zagadnieniami w Projekcie
sposób obsługi zmian projektowych,
plan zarządzania ryzykiem w Projekcie
skład Zespołu Wdrożeniowego wraz z podziałem na role i zadania poszczególnych członków zespołu
Infrastruktura sprzętowa
podział Przedmiotu Zamówienia na Produkty, a następnie ich pogrupowanie w Komponenty
analizę wymagań Przedmiotu Zamówienia zawierającą opis sposobu realizacji wymagań, sposób testowania
i odbioru
karty katalogowe urządzeń potwierdzające spełnienie wymagań
dokumentacje i plan dostaw
plan i opis instalacji i wdrożenia systemów wdrażanych wraz z infrastrukturą sprzętową
plan i opis modernizacji i budowy Infrastruktury sprzętowej
listę Komponentów, które będę podlegały osobnym odbiorom
przygotowanie i zaimplementowanie w systemie do 400 dokumentów wskazanych przez Zamawiającego na etapie
Analizy Przedwdrożeniowej – system digitalizacji pisma ręcznego
szczegółowe uzgodnienia Stron Umowy dotyczące zakresu i sposobu integracji dostarczanych rozwiązań
z Istniejącą infrastrukturą
zakres prac realizowanych przez podwykonawców
szczegółowy zakres i zawartość pozostałej Dokumentacji
plan Instruktaży stanowiskowych u Zamawiającego oraz sposób ich wykonania
Sporządzenie raportu z testów komunikacyjnych mający za zadanie zweryfikować poprawność funkcjonowania
systemu, że generowane z nowej wersji systemu pliki wymiany (pliki XML, dokumenty HL7, widoki na bazie danych)
posiadają identyczną strukturę i zawartość dla takiego samego zakresu danych jak w dotychczas używanym systemie
HIS.
I.4.4 Dokumentacja Powdrożeniowa
Warunkiem dokonania Odbioru Końcowego jest dostarczenie przez Wykonawcę Dokumentacji Powdrożeniowej
obejmującej dokumentację użytkową, techniczną i eksploatacyjną. Dokumentacja Powdrożeniowa musi być
dostarczona w języku polskim, w wersji elektronicznej w formacie edytowalnym oraz w co najmniej jednym
egzemplarzu papierowym.
W dokumentacji muszą być zawarte opisy wszelkich cech, właściwości i funkcjonalności pozwalających na
poprawną z punktu widzenia technicznego eksploatację aplikacji informatycznej.
W szczególności dokumentacja ta powinna zawierać:
1) pełną charakterystykę licencjonowania wszystkich elementów aplikacji i środowiska;
2) opis architektury technicznej:
a) Wyszczególnienie oraz opis powiązań wszystkich komponentów sprzętowych, systemowych
i aplikacyjnych występujących lub wymaganych do poprawnej pracy aplikacji zgodnie z wymaganiami
wydajności, funkcjonalności i bezpieczeństwa (minimalny, maksymalny, rekomendowany),
b) dla komponentów innych dostawców, należy dokładnie określić wykorzystywane i dopuszczalne wersje;
3) Konfiguracja musi obejmować wszystkie urządzenia wdrożone, zainstalowane w ramach budowy systemu
IT.
4) Przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje:
a) Serwery – parametry sprzętowe (procesor, pamięć, dyski, karty sieciowe, zasilanie, itp.);
b) sieć (adresacja IP, itp.),
c) podsystem dyskowy (punkty montowania/litery dysków, wolumeny logiczne, grupy wolumenowe,
zasoby dyskowe, RAID, itp.),
d) system operacyjny (parametry jądra, moduły, usługi, stos TCP/IP, itp.),
e) klaster (węzły fizyczne, paczki klastrowe, kolejność przełączania, itp.),
f) listę zainstalowanego oprogramowania, itp.;
g) Macierze – parametry sprzętowe (cache, półki dyskowe, dyski, karty/porty fibre channel, itp.), grupy
dyskowe, zasoby dyskowe, maskowanie, kopie biznesowe, replikacja, itp.;
h) Infrastrukturę sieciową– parametry sprzętowe (porty fibre channel, aktywne licencje, itp.), fabric,
zonning, aliasy, itp.
Strona 16 z 106
5) Opis aplikacji i konfiguracji aplikacji/systemu.
a) Opis musi obejmować ogół oprogramowania wdrożonego, zainstalowanego w ramach budowy systemu
IT.
b) Opis musi zawierać opis systemu lub systemów informatycznych, zawierający wykaz programów,
procedur lub funkcji, w zależności od struktury oprogramowania, wraz z opisem algorytmów
i parametrów oraz programowych zasad ochrony danych, w tym w szczególności metod zabezpieczania
dostępu do danych i systemu ich przetwarzania, sposobu komunikacji pomiędzy systemami, zakresu
wymienianych danych i sposobu ich szyfrowania.
c) Przykładowy zestaw wymaganych danych konfiguracyjnych obejmuje: wersję oprogramowania,
narzędzia, użytkowników i grupy systemowe, katalog instalacyjny, położenie plików konfiguracyjnych,
pierwotne parametry konfiguracyjne i zmodyfikowane w procesie instalacji, położenie plików logów,
położenie i opis innych kluczowych plików i katalogów, parametry instancji, itp.;
d) Konfiguracja musi obejmować wersję aplikacji, pełen zestaw parametrów konfiguracyjnych aplikacji
wraz z opisem użycia, katalogi instalacyjne, położenie plików konfiguracyjnych, położenie plików
logów, położenie i opis innych kluczowych plików i katalogów, itp.
6) Opis architektury logicznej:
schemat i opis powiązań logicznych poszczególnych komponentów i ich rolę w architekturze.
7) Mapa i opis Interface’ów:
Interfejsy muszą zawierać szczegółowy opis techniczny, w szczególności zawierać informację o:
typie interfejsu, wykorzystywanych protokołach, portach sieciowych, strukturze interfejsu, itp. oraz
o zakresie wymiany danych i sposobu kontroli prawidłowości działania.
8) Opis struktur baz danych:
Opis wykorzystywanych struktur danych musi w szczególności zawierać: listę tabel bazy danych
wraz z opisem pól, formaty danych, itp., kryteria walidacji danych wejściowych, opis zmiennych
konfiguracyjnych.
9) Opis wymagań sprzętowych, systemowych, sieciowych itp.:
Wymagania dla poszczególnych komponentów architektury, odniesienia do oczekiwanych
wymagań wydajnościowych, funkcjonalnych i bezpieczeństwa (minimalny, maksymalny,
rekomendowany).
10) Procedury tworzenia środowisk pomocniczych:
Zasady i procedury tworzenia środowisk (testowych, rozwojowych, raportowych) oraz metod
klonowania i anonimizacji (depersonifikacji) danych przenoszonych pomiędzy środowiskami.
11) Procedury eksploatacji:
a) W szczególności dokumentacja zawiera procedury tworzenia/odtwarzania kopii bezpieczeństwa
operacyjnego i kopii zapasowych oraz odtwarzania/kreowania z kopii wszystkich komponentów aplikacji
i środowiska (bazy danych, komponenty serwera aplikacji, klienta itp.),
b) Odtworzenia systemów i środowiska informatycznego Zamawiającego po katastrofie (Disaster
Recovery):
Procedury muszą opisywać kolejne kroki pozwalające na bezpieczne zatrzymanie/uruchomienie
elementu infrastruktury hardware’owej oraz aplikacji i elementów infrastruktury software’owej, lub
całego środowiska sprzętowo-software’owego.
Dokumenty obejmują również procedury i instrukcje instalacji krok po kroku środowiska
produkcyjnego „od zera” na:
- środowisku fizycznych hostów Zamawiającego rozpoczynając od dostarczonego wirtualizatora
- standardowym zastosowanym Systemie Operacyjnym dla poszczególnych dostarczonych
Systemów Informatycznych.
12) Procedury lub instrukcje instalacji, reinstalacji, deinstalacji oraz aktualizacji:
Szczegółowy opis postępowania w przypadku tworzenia lub zmian w środowisku; jeśli
wykorzystywane są procedury innych dostawców dla standardowych komponentów (np. baz
danych) wystarczy wskazać w dokumentacji szczegółowe odniesienie do procedur standardowych
właściwych dla tych komponentów.
13) Procedury backupowe:
Zalecany tryb backupu aplikacji i elementów infrastruktury software’owej, oraz zakres danych
podlegających backupowi. Procedury odtworzeniowe, muszą w szczególności opisywać sposób
odtworzenia funkcjonalności aplikacji i elementów infrastruktury software’owej w przypadku błędu
lub awarii.
14) Dokumentacja administracyjna związana z poprawną eksploatacją:
a) Opis (w postaci procedur lub instrukcji) wszystkich rutynowych czynności administracyjnych dla
aplikacji i systemu informatycznego (dziennych, tygodniowych, miesięcznych itp.) oraz działań
pozwalających na utrzymanie wymaganej dostępności, wydajności i bezpieczeństwa.
b) Wymagane jest dostarczenie poprawnych inicjalnych sekwencji realizowanych czynności
administracyjnych i utrzymaniowych i zasad ich aktualizacji i budowy; opis zasad pielęgnacji
i utrzymania aplikacji. Procedury administracyjne powinny w szczególności zawierać informacje
Strona 17 z 106
o okresowych zadaniach, które muszą być wykonane przez administratora, np. weryfikacja zajętości
przestrzeni tabel, konieczność wykonywania analizy tabel, czyszczenia logów, itp.
15) Procedury standardowe:
opis możliwości stosowania standardowych procedur poprawnej eksploatacji dla rozwiązań
wspierających (sprzętowych lub aplikacyjnych).
16) Dokumenty z testów:
plan testów, scenariusze testowe i protokoły z testów akceptacyjnych, wydajnościowych, testów
operacji administratora technicznego oraz testów bezpieczeństwa w tym ciągłości działania
(przełączanie, odtwarzanie, weryfikacja poprawności).
17) Dokumentacja:
a) dokumentacja powdrożeniowa: zawiera szczegółowy opis wykonanych czynności instalacyjnych oraz
konfiguracyjnych wszystkich komponentów systemu;
b) dokumentacja parametryzacji: wyszczególnienie wartości wszystkich ustawionych parametrów
użytkowych zarówno samej aplikacji jak i pozostałych komponentów systemu, parametry systemu
operacyjnego oraz parametry sprzętu, w tym konfiguracji środowiska produkcyjnego (serwery baz
danych, serwery aplikacji, inne zastosowane) wraz z opisem ich znaczenia i dopuszczalnych wartości
oraz stosowanych wartości domyślnych;
c) dokumentacja uruchomieniowa: opisuje wszystkie istotne kroki (czynności) wykonane w celu
pierwszego uruchomienia aplikacji/systemu, w tym opis migracji/konwersji danych, testy
uruchomieniowe;
d) dokumentacja pilotażowa: jeśli był stosowany w trakcie wdrożenia pilotaż jako element stabilizacji
i testów.
18) Wersjonowanie:
Opis zasad wersjonowania i sposobu patchowania aplikacji.
19) Zalecenia:
Opis zasad i zaleceń strojenia aplikacji.
20) Instrukcje obsługi i instrukcje użytkowania dla wersji dostarczonego oprogramowania z podziałem na
poszczególne moduły.
21) W zakresie obszarów administratora dokumentacja powinna zawierać dodatkowo co najmniej:
a) opis podstawowych ról użytkowników i zasad ich kreowania;
b) opis zarządzania uprawnieniami użytkownika i tworzenia profili;
c) lista dostępnych uprawnień użytkownika wraz z opisem efektu w zakresie dostępu do danych w SSI.
d) opis zarządzania autoryzacją i autentykacją użytkowników;
22) Wkład do Polityki bezpieczeństwa w zakresie wdrożonego Systemu oraz Instrukcję zarządzania systemem
informatycznym służącym do przetwarzania danych osobowych opracowane zgodnie z wymaganiami
Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie
ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego
przepływu takich danych oraz uchylenia dyrektywy 95/46/WE warunkujące odpowiednie środki techniczne
i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający ryzyku naruszenia. Wkład do Polityki
Bezpieczeństwa będzie zawierać w szczególności:
a) wykaz zbiorów danych osobowych wraz ze wskazaniem programów zastosowanych do przetwarzania
tych danych;
b) opis struktury zbiorów danych wskazującej zawartość poszczególnych pól informacyjnych i powiązań
między nimi;
c) informacje o sposobie przepływu danych pomiędzy poszczególnymi systemami;
d) opis środków technicznych i organizacyjnych niezbędnych dla zapewnienia poufności, integralności
i rozliczalności przetwarzanych danych.
20) Dokumentacja techniczna
W skład dokumentacji technicznej administratora wejdą dokumenty dotyczące następujących zagadnień:
użyte w projekcie oprogramowanie systemowe i narzędziowe, ze wskazaniem wersji, sposobu
konfiguracji oraz sposobu licencjonowania,
lista wykorzystanych bibliotek wraz ze wskazaniem wersji, konfiguracji oraz sposobu licencjonowania;
sposób instalacji i konfiguracji wszystkich składników sprzętu i oprogramowania,
procedury administracyjne i eksploatacyjne,
Dokumentacja struktur baz danych oraz konfiguracji poszczególnych elementów Systemu: infrastruktury
sprzętowej, aplikacji w tym opis struktury danych,
Procedury tworzenia kopii i odtwarzania poszczególnych elementów systemu.
monitorowania pracy systemu (urządzeń i oprogramowania systemowego oraz narzędziowego)
z uwzględnieniem procedur alarmowych o bieżących problemach;
okresowych czynności administracyjnych dotyczących sprzętu i oprogramowania systemowego oraz
narzędziowego.
Strona 18 z 106
21) Procedury serwisowe
Zakres dokumentu zawierać będzie co najmniej:
organizację serwisu, tryb zgłaszania awarii;
procedury techniczne dotyczące naprawy, wymiany podstawowych elementów infrastruktury sprzętowej
i aktualizacji oprogramowania systemowego i narzędziowego;
procedury serwisu prewencyjnego mającego na celu utrzymanie systemu (sprzętu i oprogramowania)
w pełnej sprawności funkcjonalnej i technicznej.
I.4.5 Dostawa i instalacja Oprogramowania standardowego
1) Oprogramowanie standardowe rozumiane jako oprogramowanie dostarczone i zainstalowane na
Infrastrukturze serwerowej oraz sieciowej posiadanej przez Zamawiającego lub dostarczane zgodnie
z Umową stanowiąca załącznik nr 6 do SWIZ oraz w istniejących systemach informatycznych zgodnie
z wymaganiami niniejszego Szczegółowego Opisu Przedmiotu Zamówienia w taki sposób, aby zapewnić
prawidłowe funkcjonowanie Oprogramowania aplikacyjnego, sprzętu oraz istniejących systemów
informatycznych na wszystkich stanowiskach pracy (stanowiska komputerowe) Zamawiającego. Dostęp
musi być realizowany przez przeglądarkę WWW.
2) Dostawa i instalacja zostaną wykonane w lokalizacjach zgodnych z instalacją Sprzętu oraz z Harmonogramem
wdrożenia.
3) Oprogramowanie musi zostać skonfigurowane tak, aby działało poprawnie zgodnie z jego przeznaczeniem
i architekturą Systemu oraz zapewniało prawidłową pracę Oprogramowania Szpitalnego Systemu
Informatycznego.
I.4.6 Dostawa, migracja, instalacja, konfiguracja i wdrożenie
Oprogramowania Szpitalnego Systemu Informatycznego (SSI)
1) Zadanie dostawy, instalacji, konfiguracji i wdrożenia Oprogramowania Szpitalnego Systemu
Informatycznego (SSI) obejmuje:
a) Migrację systemu HIS na nowy wydajny silnik bazy danych
b) e-Usługi
c) Repozytorium EDM
d) Adapter komunikacyjny (konektor)
e) Szyna danych.
2) Dostawa i instalacja mają być wykonane w wyznaczonych lokalizacjach Zamawiającego, tj. w Warszawie
przy ul. W.K. Roentgena i ul. Wawelskiej.
3) Po zakończeniu prac instalacyjnych Oprogramowanie Szpitalnego Systemu Informatycznego (SSI) musi
zostać skonfigurowane i wdrożone w sposób kompleksowy tak, aby realizowało funkcjonalności opisane
w SIWZ oraz działało zgodnie z Dokumentacją analizy przedwdrożeniowej.
4) Oprogramowanie Szpitalnego Systemu Informatycznego (SSI) musi zostać zainstalowane przez Wykonawcę
w szczególności z wykorzystaniem Sprzętu i w środowiskach informatycznych Zamawiającego.
Oprogramowanie Szpitalnego Systemu Informatycznego (SSI) musi zostać zainstalowane i skonfigurowane
w sposób kompleksowy na wszystkich stanowiskach komputerowych Zamawiającego.
5) Oprogramowanie SSI musi zostać zainstalowane w taki sposób, aby zachować w całości dotychczasowe
integracje z oprogramowaniem i urządzeniami posiadanymi przez Zamawiającego w szczególności
obejmujące zakres integracji, interfejsy integracji oraz model wymiany danych.
I.4.7 Dostawa i instalacja Infrastruktury sprzętowej
1) Dostawa i instalacja Infrastruktury sprzętowej jest zadaniem mającym na celu dostarczenie zamawianego
Sprzętu do wskazanych lokalizacji Zamawiającego w porozumieniu z Zamawiającym według Harmonogramu
wdrożenia. Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało
to z bieżącą pracą Zamawiającego.
2) Wykonawca zapewni wniesienie dostarczonego Sprzętu do wskazanych lokalizacji i pomieszczeń.
3) Wykonawca dostarczy Sprzęt sukcesywnie w terminie bezpośrednio poprzedzającym jego instalację
i w sposób dopasowany do możliwości logistycznych Zamawiającego. Zakres i wielkości dostaw należy
każdorazowo uzgodnić z Zamawiającym na dwa dni robocze przed planowaną dostawą.
4) Wykonawca zobowiązany jest przeprowadzić dostawy przedmiotu zamówienia w godzinach uzgodnionych
z Zamawiającym.
5) Wszystkie oferowane urządzenia muszą być nowe, wyprodukowane po 01 stycznia 2019 roku i pochodzić
z autoryzowanego kanału sprzedaży producenta i reprezentować model bieżącej linii produkcyjnej.
6) Nie dopuszcza się urządzeń: odnawianych, demonstracyjnych lub powystawowych.
Strona 19 z 106
7) Nie dopuszcza się urządzeń posiadających wadę prawną w zakresie pochodzenia sprzętu, licencji, wsparcia
technicznego i gwarancji producenta.
8) Sprzęt i komponenty muszą być oznakowane przez producenta w taki sposób, aby możliwa była identyfikacja
zarówno produktu jak i producenta.
9) Sprzęt musi być dostarczony w oryginalnych opakowaniach fabrycznych.
10) Oferowany Sprzęt musi pochodzić z oficjalnego kanału dystrybucji producenta, a gwarancja musi pochodzić
od producenta i być świadczona przez sieć serwisową producenta.
11) Na dokumentach dostawy od producenta powinna znaleźć się informacja o użytkowniku końcowym urządzeń.
12) Do każdego urządzenia musi być dostarczony komplet standardowej dokumentacji dla użytkownika
w języku polskim lub angielskim w formie papierowej lub elektronicznej.
13) Dla całej Infrastruktury sprzętowej, we wszystkich lokalizacjach Wykonawca dostarczy, zamontuje,
skonfiguruje i dostroi Sprzęt, Oprogramowanie (w tym oprogramowanie służące do zarządzania Sprzętem)
i Oprogramowanie Szpitalnego Systemu Informatycznego (jeżeli dotyczy).
14) Jeżeli przy opisach infrastruktury sprzętowej nie są wymienione lub wymieniona jest niewystarczająca ilość
akcesoriów połączeniowych takich jak przewody zasilające, kable sygnałowe, kable światłowodowe
i wszelkie inne przewody a także wkładki sfp, sfp+, itp, a są niezbędne do współdziałania urządzeń -
Wykonawca dostarczy potrzebne akcesoria do zbudowania i wdrożenia całości Przedmiotu Zamówienia na
własny koszt.
15) Urządzenia na etapie dostawy producent - zamawiający nie mogą podlegać modyfikacjom.
16) Wszystkie dostarczane urządzenia podlegają usługom dostaw, instalacji, konfiguracji i uruchomienia.
17) Usługi instalacji, konfiguracji i uruchomienia Wykonawca przeprowadzi zgodnie z zapisami niniejszego OPZ
oraz Umowy w uzgodnieniu z Zamawiającym, zgodnie z obowiązującymi przepisami oraz najlepszymi
praktykami w ich realizacji.
I.4.8 Godziny RFC (Godziny rozwojowe)
Zamawiający w ramach wdrożenia wymaga puli nie więcej niż 400 godzin RFC, przez co rozumie pulę godzin
wykonawczych do dyspozycji Zamawiającego na prace / modyfikacje, których nie dało się przewidzieć na etapie
budowy niniejszego dokumentu.
I.4.9 Dodatkowe zobowiązania Wykonawcy
1) Wykonanie Przedmiotu Zamówienia z efektywnością oraz zgodnie z praktyką i wiedzą zawodową.
2) Wykonanie w całości Przedmiotu Zamówienia w zakresie określonym w Umowie i SIWZ.
3) Dokonanie z Zamawiającym wszelkich koniecznych ustaleń mogących wpływać na zakres i sposób realizacji
Przedmiotu Zamówienia oraz ciągła współpraca z Zamawiającym na każdym etapie realizacji.
4) Stosowanie się do wytycznych i polityk bezpieczeństwa informacji obowiązujących u Zamawiającego.
5) Udzielanie na każde żądanie Zamawiającego pełnej informacji na temat stanu realizacji Przedmiotu
Zamówienia.
6) Współdziałanie z osobami wskazanymi przez Zamawiającego.
I.5 Istniejąca infrastruktura
Zaplecze informatyczne Zamawiającego dzieli się na infrastrukturę sieciową, serwerowa, oprogramowanie,
systemy medyczne i administracyjne, dwa centra przetwarzania danych zlokalizowane w dwóch lokalizacjach
Zamawiającego oraz wiele systemów informatycznych, z którymi systemy wewnętrzne są zintegrowane.
Strona 20 z 106
Na poniższym rysunku przedstawiono aktualny stan w zakresie istniejącej infrastruktury:
Opracowanie: Studium Wykonalności
Serwerownia
Obecna Serwerownia Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego jest obiektem powstałym w 2010 roku, posiada bezpośrednie zasilenie z rozdzielnicy prądowej,
system niezależnych redundantnych klimatyzatorów, system alarmowy oraz system monitoringu. Serwerownia
jest wyposażona w urządzenia UPS. Posiada rozbudowaną infrastrukturę światłowodową łącząca budynki
Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego (wraz z
drugą lokalizacją przy ulicy Wawelskiej) oraz dwa niezależne łącza internetowe. Obecnie w serwerowni pracuje
24 serwerów blade tworzący klaster obsługujący systemy medyczne i administracyjne, na których zainstalowane
jest 75 serwerów wirtualnych (w tym 10 maszyn obsługujących system medyczny CliniNet) oraz 16 serwerów
pełniących funkcje pomocnicze lub udostępniających usługi sieciowe. W roku 2015 została uruchomiona druga
serwerownia
– w odrębnej lokalizacji (siedziby Warszawa Ursynów), która pełni rolę centrum zapasowego. Przetrzymywane
są w niej backupy i obrazy maszyn wirtualnych systemów produkcyjnych (medycznych i administracyjnych) oraz
wykonywane są repliki on-line bazy danych systemów medycznych dla potrzeb Disaster Recovery i zasilania
hurtowni danych. Dane z systemów produkcyjnych przechowywane są na 4 macierzach o łącznej pojemności
ponad 200 TB.
Sieci
Obecnie na terenie Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego w Warszawie funkcjonują dwie sieci lokalne: w lokalizacjach przy ul. W.K. Roentgena i ul.
Wawelskiej. Sieci są wykonane zgodnie z obowiązującymi normami i umożliwiają dołączenie specjalistycznego
sprzętu, stacji roboczych, drukarek i urządzeń sieciowych. Sieci są obsługiwane przez 76 urządzeń aktywnych
rozlokowanych w 24 punktach dystrybucyjnych połączonych ze sobą światłowodami. Obydwie lokalizacje są
połączone ze sobą stałym łączem światłowodowym. Obecnie w sieci komputerowej Narodowego Instytutu
Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego pracuje ponad 2000 urządzeń
sieciowych (komputerów i drukarek sieciowych, itd.)
Oprogramowanie
W ramach posiadanej infrastruktury w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie –
Państwowym Instytucie Badawczym funkcjonuje system CliniNet – system medycznej obsługi pacjenta. Baza
systemu CliniNet zawiera obecnie dane prawie 860.000 pacjentów, informacje z blisko 1.600.000 pobytów
szpitalnych i 7.000.000 wizyt ambulatoryjnych. System zawiera ponad 46.000.000 wyników badań. Baza
codziennie jest uzupełniana przez 600 aktywnych użytkowników. W systemie zbierane są wszystkie dane służące
procesowi leczenia pacjentów. Zakres funkcjonalny systemu obejmuje cały szpital
i poradnie/ambulatorium wraz z działalnością diagnostyczną w dwóch lokalizacjach w Warszawie - Roentgena
Strona 21 z 106
i Wawelska. System nie posiada odpowiednich narzędzi do świadczenia e-usług w zakresie obsługi pacjentów
oraz personelu zarówno medycznego jak również administracyjnego (tzw. back office). Obecne narzędzia są
niewystarczające i nie wykorzystują potencjału tak dużej ilości informacji.
Krajowy Rejestr Nowotworów
Należy również wspomnieć, iż w strukturach Zakładu Epidemiologii uruchomiona została nowoczesna
informatyczna platforma naukowa. Zakład odpowiedzialny jest za prowadzenie Krajowego Rejestru Nowotworów
opartego na 16 Wojewódzkich Rejestrach Nowotworowych, obejmujących populacje poszczególnych
województw (jeden rejestr w każdym województwie). Zakład Epidemiologii został wyposażony w nowoczesne
narzędzia informatyczne i statystyczne do zbierania i analizowania danych o zachorowaniach na nowotwory
w całym kraju. Wyposażony jest w niezbędny sprzęt informatyczny w postaci:
- serwerów aplikacji (2 szt.)
- serwerów baz danych (2 szt.) - macierzy dyskowej, - backup
Krajowy Rejestr Nowotworów posiada wystarczające zasoby techniczne do samodzielnego funkcjonowania, przy
czym stanowić będzie ważny element całej infrastruktury informatycznej Narodowego Instytutu Onkologii im.
Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego.
ONKO.SYS
Kolejnym ważnym elementem wyposażenia informatycznego Narodowego Instytutu Onkologii im. Marii
Skłodowskiej-Curie – Państwowego Instytutu Badawczego są zasoby, które zostały zakupione w ramach Projektu
pn. „ONKO.SYS – Kompleksowa infrastruktura informatyczna dla badań nad nowotworami” (projekt
realizowany do końca 2015 roku). System ONKO.SYS został zbudowany z klastra komputerowego o wysokiej
dostępności złożonego z dwunastu fizycznych serwerów oraz pamięci masowych. Na dostarczonej infrastrukturze
pracują maszyny wirtualne obsługujące serwery domenowe, aplikacyjne, repozytorium, bazodanowe. Serwery
zarządzane są z poziomu posiadanego przez Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie –
Państwowy Instytut Badawczy serwera vCenter. Obrazy maszyn wirtualnych przechowywane są na przestrzeni
dyskowej pamięci masowej. Na tej przestrzeni udostępniona jest również wspólna oraz indywidualna przestrzeń
dyskowa użytkowników. Dla podniesienia bezpieczeństwa przechowywanych informacji zbudowane zostało
centrum backupowe, w którym uruchomiono macierz z pełną replikacją danych.
Poniższy rysunek przedstawia architekturę logiczną systemu ONKO.SYS
Źródło: Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy
* Centrum Onkologii / COI – aktualna nazwa to Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy
Instytut Badawczy
Strona 22 z 106
I.6 Zasady postępowania z pacjentami w ramach współpracy pomiędzy
Narodowym Instytutem Onkologii im. Marii Skłodowskiej-Curie –
Państwowym Instytutem Badawczym a partnerami projektu e-zdrowie
„Nowoczesny szpital, Nowoczesny ZOZ”
I.6.1 Pacjenci bez rozpoznania nowotworu dotychczas nieleczeni
onkologicznie
Projekt stwarza możliwość e-konsultacji w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie –
Państwowym Instytucie Badawczym dla pacjentów bez rozpoznania nowotworu, będących pod opieką partnerów
projektu w ramach Podstawowej Opieki Zdrowotnej. Decyzję o potrzebie konsultacji podejmuje lekarz POZ na
podstawie wywiadu, badania przedmiotowego i badań dodatkowych. Informacje te wraz z celem konsultacji
i wynikami badań są przesyłane do koordynatora projektu w Narodowym Instytucie Onkologii im. Marii
Skłodowskiej-Curie – Państwowym Instytucie Badawczym w formie elektronicznej. Koordynator podejmuje
decyzję o dalszym postępowaniu tj. przekazaniu danych klinicznych do odpowiedniego zespołu
multidyscyplinarnego lub konieczności uzupełnienia danych medycznych przez partnera projektu. W sytuacjach
tego wymagających możliwe jest przeprowadzenie wideokonferencji pomiędzy lekarzem POZ,
a koordynatorem/zespołem lekarskim Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie
– Państwowego Instytutu Badawczego. Skład i tryb odbywania wideokonferencji może być różny w zależności
od sytuacji klinicznej pacjenta. Zalecenia dotyczące dalszego postępowania są przekazywane do partnerów
projektu w formie elektronicznej. Mogą one obejmować:
a) decyzję o braku wskazań do rozszerzania diagnostyki i zalecenie dalszej opieki lekarza POZ,
b) dalszą diagnostykę w ramach POZ,
c) zgłoszenie się pacjenta do Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego na konsultację i ewentualną dalszą diagnostykę
i leczenie,
d) zalecenie konsultacji u lekarza innej specjalności.
Dalsza wymiana informacji i konsultacje następują bezpośrednio między lekarzem POZ a lekarzem/zespołem
lekarskim Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego
przeprowadzającym pierwszą konsultację, z pominięciem koordynatora. Wyniki dodatkowych badań
diagnostycznych są każdorazowo przesyłane pomiędzy partnerami projektu w formie elektronicznej. Istnieje
również możliwość zorganizowania wideokonferencji w celu ich omówienia i podjęcia decyzji o dalszym
postepowaniu.
* COI – aktualna nazwa to Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy
Strona 23 z 106
I.6.2 Pacjenci w trakcie leczenia onkologicznego w Narodowym
Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym
Instytucie Badawczym pozostający pod opieką partnerów projektu
w ramach podstawowej opieki zdrowotnej.
Projekt stwarza możliwość e-konsultacji w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie
– Państwowym Instytucie Badawczym pacjentów będących w trakcie leczenia onkologicznego pozostających pod
opieką partnerów projektu w ramach Podstawowej Opieki Zdrowotnej. Decyzję o potrzebie konsultacji podejmuje
lekarz POZ. Cel konsultacji wraz z ewentualnymi wynikami badań są przesyłane do koordynatora projektu
w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym
w formie elektronicznej. Koordynator przekazuje informację o potrzebie konsultacji do zespołu leczącego
odpowiedniej kliniki Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego. W sytuacjach tego wymagających możliwe jest przeprowadzenie wideokonferencji pomiędzy
lekarzem POZ, a zespołem lekarskim kliniki. Zalecenia dotyczące dalszego postępowania są przekazywane do
partnerów projektu w formie elektronicznej.
Mogą one obejmować:
a) decyzję o skierowaniu chorego do Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego,
b) proponowane dalsze postępowanie w ramach POZ,
c) zalecenie konsultacji u lekarza innej specjalności,
d) zalecenie skierowania chorego do odpowiedniego oddziału szpitalnego poza Narodowym Instytutem
Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym.
Nie przewiduje się konsultacji pacjentów będących pod opieką ośrodków onkologicznych innych niż
Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy w Warszawie.
* COI – aktualna nazwa to Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy
Strona 24 z 106
I.6.3 Pacjenci w trakcie leczenia onkologicznego w Narodowym
Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym
Instytucie Badawczym pozostający pod opieką partnerów projektu
w ramach podstawowej opieki zdrowotnej, którzy mogą
kontynuować leczenie w trybie ambulatoryjnym pod opieką POZ.
Projekt stwarza możliwość kierowania pacjentów leczonych w Narodowym Instytucie Onkologii im. Marii
Skłodowskiej-Curie – Państwowym Instytucie Badawczym i objętych Podstawową Opieką Zdrowotną przez
partnerów projektu, którzy mogą kontynuować leczenie onkologiczne w trybie ambulatoryjnym pod opieką POZ.
Zalecenia dotyczące dalszego postępowania są przekazywane partnerom przez lekarza odpowiedniej kliniki
Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego w formie
elektronicznej. Lekarz POZ na podstawie wywiadu, badania przedmiotowego i badań dodatkowych może podjąć
decyzję o potrzebie konsultacji pacjenta w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie
– Państwowym Instytucie Badawczym. Informacje te wraz z celem konsultacji i wynikami badań są przesyłane
elektronicznie przez lekarza POZ bezpośrednio do lekarza/zespołu lekarskiego kliniki Narodowego Instytutu
Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego, pod opieką której znajduje się
pacjent, z pominięciem koordynatora. Istnieje również możliwość zorganizowania wideokonferencji. Zalecenia
dotyczące dalszego postępowania są przekazywane do partnerów projektu w formie elektronicznej. Mogą one
obejmować:
a) decyzję o skierowaniu chorego do Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego,
b) proponowane dalsze postępowanie w ramach POZ,
c) zalecenie konsultacji u lekarza innej specjalności,
d) zalecenie skierowania chorego do odpowiedniego oddziału szpitalnego poza Narodowym Instytutem
Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym.
Nie przewiduje się konsultacji pacjentów leczonych w ośrodkach onkologicznych innych niż w Narodowym
Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym.
* COI – aktualna nazwa to Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy
Strona 25 z 106
I.6.4 Pacjenci w obserwacji po zakończeniu leczenia onkologicznego
w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie –
Państwowym Instytucie Badawczym pozostający pod opieką
partnerów projektu w ramach podstawowej opieki zdrowotnej.
Projekt stwarza możliwość kierowania pacjentów objętych Podstawową Opieką Zdrowotną przez partnerów
projektu, którzy zakończyli leczenie onkologiczne w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-
Curie – Państwowym Instytucie Badawczym do dalszej obserwacji w POZ. Zalecenia dotyczące dalszego
postępowania są przekazywane partnerom przez lekarza odpowiedniej kliniki Narodowego Instytutu Onkologii
im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego w formie elektronicznej. Lekarz POZ na
podstawie wywiadu, badania przedmiotowego i badań dodatkowych może podjąć decyzję o potrzebie konsultacji
pacjenta w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie
Badawczym. Informacje te wraz z celem konsultacji i wynikami badań są przesyłane elektronicznie przez lekarza
POZ bezpośrednio do lekarza/zespołu lekarskiego kliniki Narodowego Instytutu Onkologii im. Marii
Skłodowskiej-Curie – Państwowego Instytutu Badawczego, w której chory był leczony, z pominięciem
koordynatora. Istnieje również możliwość zorganizowania wideokonferencji. Zalecenia dotyczące dalszego
postępowania są przekazywane do partnerów projektu w formie elektronicznej. Mogą one obejmować:
a) decyzję o skierowaniu chorego do Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego,
b) proponowane dalsze postępowanie w ramach POZ,
c) zalecenie konsultacji u lekarza innej specjalności,
d) zalecenie skierowania chorego do odpowiedniego oddziału szpitalnego poza Narodowym Instytutem
Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym.
Nie przewiduje się konsultacji pacjentów będących w obserwacji po leczeniu w ośrodkach onkologicznych innych
niż w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym.
* COI – aktualna nazwa to Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy
Strona 26 z 106
I.6.5 Pacjenci, którzy wyczerpali możliwości leczenia onkologicznego
w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie –
Państwowym Instytucie Badawczym skierowani do dalszego leczenia
objawowego, pozostający pod opieką partnerów projektu w ramach
podstawowej opieki zdrowotnej.
Projekt stwarza możliwość kierowania pacjentów objętych Podstawową Opieką Zdrowotną przez partnerów
projektu, którzy wyczerpali możliwości leczenia onkologicznego w Narodowym Instytucie Onkologii im. Marii
Skłodowskiej-Curie – Państwowym Instytucie Badawczym i zostali skierowani do dalszego leczenia objawowego
w POZ. Zalecenia dotyczące dalszego postępowania są przekazywane partnerom przez lekarza odpowiedniej
kliniki Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego
w formie elektronicznej. Lekarz POZ na podstawie wywiadu, badania przedmiotowego i badań dodatkowych
może podjąć decyzję o potrzebie konsultacji pacjenta w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-
Curie – Państwowym Instytucie Badawczym. Informacje te wraz z celem konsultacji i wynikami badań są
przesyłane elektronicznie przez lekarza POZ bezpośrednio do lekarza/zespołu lekarskiego kliniki Narodowego
Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego, w której chory był
leczony, z pominięciem koordynatora. Istnieje również możliwość zorganizowania wideokonferencji. Zalecenia
dotyczące dalszego postępowania są przekazywane do partnerów projektu w formie elektronicznej. Mogą one
obejmować:
a) decyzję o skierowaniu chorego do Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego
b) proponowane dalsze postępowanie w ramach POZ
c) skierowanie chorego do leczenia w ramach hospicjum domowego lub stacjonarnego
d) zalecenie konsultacji u lekarza innej specjalności
e) zalecenie skierowania chorego do odpowiedniego oddziału szpitalnego poza Narodowym Instytutem
Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym.
Nie przewiduje się konsultacji pacjentów, którzy zakończyli leczenie w ośrodkach onkologicznych innych niż
w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym.
* COI – aktualna nazwa to Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy
Strona 27 z 106
I.7 Streszczenie zakresu zamówienia
Projekt polega na wdrożeniu systemów prowadzenia Elektronicznej Dokumentacji Medycznej zgodnie z ustawą
z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (t.j. Dz. U. z 2019 r. poz. 408 z późn. zm.),
e-usług oraz stworzeniu zewnętrznego repozytorium przechowywania i wymiany elektronicznej dokumentacji
medycznej wraz ze stworzeniem adaptera komunikacyjnego oraz szyny danych ESB umożliwiających podłączenia
systemów generujących dokumenty medyczne do repozytorium dokumentów źródłowych, aby było to możliwe,
to wszystkie funkcjonalności starego systemu HIS Zamawiającego, którym jest obecnie system CompuGroup
Medical Polska CLININET w wersji 2019.MS.3.11, który działa w oparciu o system bazodanowy Sybase, muszą
zostać zainstalowane na nowej, szybkiej i wydajniejszej bazie danych, która jest przedmiotem niniejszego
zamówienia, wraz z zabezpieczeniem nowego rozwiązania przez systemy bezpieczeństwa. Po uruchomieniu
wszystkich funkcjonalności nowego systemu funkcjonującego na nowej bazie danych, zostanie uruchomiony
bezpieczny interfejs komunikacyjny API do komunikacji dwustronnej pomiędzy bazą danych, systemem HIS,
a systemami EDMi e-Usług. Wykonawca jest zobowiązany zaproponować „Interfejs komunikacyjny API systemu
szpitalnego Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego do systemów EDM i e-Usług”, który powstanie na podstawie specyfikacji formatów danych
i standardów stosowanych w lokalnych systemach HIS i Repozytorium Elektronicznej Dokumentacji Medycznej.
Infrastruktura serwerowa dla Projektu ma zostać oparta częściowo na outsourcingu mocy obliczeniowych, czyli
tzw. „chmury obliczeniowej”. Dla potrzeb Projektu wynajęta zostanie moc obliczeniowa w centrum danych oraz
zestawione zostaną bezpieczne szyfrowane połączenia za pomocą VPN na urządzeniach bezpieczeństwa
dostarczonych także dla każdego z Partnerów w ramach Projektu. Dodatkowo Repozytorium Elektronicznej
Dokumentacji Medycznej będzie składowane na macierzy dyskowej umieszczonej w Narodowym Instytucie
Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym. Dla każdego z Parterów
zostanie zainstalowana odrębna instancja bazy danych, w ramach której zainstalowane zostaną systemy
udostępniające e-usługi. Dodatkowo odrębna instancja bazy danych obsługiwać będzie repozytorium
elektronicznej dokumentacji medycznej. Zabezpieczenie dostępu do systemów i baz danych realizowane będzie
za pomocą dedykowanych urządzeń.
W ramach Projektu zostanie także przeprowadzona migracja systemu zarządzania bazą danych systemu
medycznego Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego do bardziej wydajnego środowiska. Pozwoli to na pełne wdrożenie Elektronicznej Dokumentacji
Medycznej w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie
Badawczym. Obecnie Narodowy Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut
Badawczy posiada wszystkie niezbędne licencje programowe i infrastrukturę serwerową umożliwiającą
prowadzenie Elektronicznej Dokumentacji Medycznej (w tym obsługę podpisu elektronicznego, uruchomiony
moduł dokumentacji elektronicznej, lokalne repozytorium EDM), jednakże wielkość liczby rekordów w bazie
danych i skala nie pozwala na efektywne wdrożenie rozwiązania. Obecnie w bazie danych systemu medycznego
znajduje się:
Diagnozy 5 956 025
Leki 2 009 196
Hospitalizacje 1 535 955
Notatki 31 242 983
Pacjenci 858 752
Procedury 14 545 946
Wyniki opisowe razem
19 373 810 Wyniki laboratoryjne
Wizyty 7 026 443
Recepty 602 503
SUMA 83 151 613
Stan na dzień: 22.06.2019
Strona 28 z 106
Szczegółowa informacja o badaniach zgromadzonych w głównym szpitalnym oprogramowaniu CliniNet:
Typ Badania Ilość
Inne 576
Radioterapia 1672
Procedura medyczna 94
Diagnostyka Ultrasonograficzna 56304
Diagnostyka Rezonansu Magnetycznego 32607
Diagnostyka Tomografii Komputerowej 128698
Mammografia 150344
Hematologia 1226701
Biochemia 10667416
Koaglulogia 997385
Badania Markerów Nowotworowych 671504
Badanie analityczne 217787
Diagnostyka Tomografii Komputerowej BRT 43
Endoskopia 67626
Serologia 95618
Patomorfologia 472724
Rentgenodiagnostyka standardowa 281315
Procedury (usługi) zaimportowane z systemu CareSys 3371209
Białka 182183
Blok Operacyjny 78027
Operacje/Zabiegi K3 3
Operacje/Zabiegi K5 1
Operacje/Zabiegi K6 6
Patomorfologia - usługi kosztowe 289
Zakład Medycyny Nuklearnej 18258
Wawelska Tomografia 13968
Wawelska Radiodiagnostyka 34587
Wawelska Mammografia 18371
Wawelska USG 22190
Badania Genetyczne 19384
Biochemia - wirusy WZW i HIV 128527
Badania Kardiograficzne 50891
USG Kliniki K8 43004
Pomiary 71638
Mikrobiologia 96805
Patomorfologia - pracownia wewnętrzne 153730
Badania genetyczne (ZOMT) 914
RTG K8 1397
Mikrobiologia2 14
Dane z dnia 02.08.2019 Razem 19373810
Oprogramowanie NetRaad: 178 816 pacjentów.
Dodatkowo system obsługi medycznej (HIS) jest obecnie zintegrowany ze wszystkimi systemami dziedzinowymi
(takimi jak Laboratorium, Mikrobiologia, Markery Nowotworowe, Apteka, systemy obrazowe PACS i systemy
obsług Radiologii RIS) – komunikacja odbywa się za pomocą protokołu HL7. System CliniNet zasila również
hurtownię danych w ramach projektu ONKO.SYS – komunikacja odbywa się za pomocą widoków z bazy danych.
Strona 29 z 106
Obecnie w głównym systemie CliniNet w trakcie doby pracuje średnio 543 osób, a w najbardziej obciążonych
godzinach ponad 630 jednocześnie (przy liczbie aktywnych użytkowników 1730 osób).
Tabela. Lista systemów informatycznych Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie
– Państwowego Instytutu Badawczego
LP SYSTEM ZAKRES DZIAŁANIA
1 CLININET Szpitalny System Informatyczny - część medyczna
2 NETRAAD Szpitalny System Informatyczny - część radiologiczna
3 NETRAAD PACS Szpitalny System Informatyczny - Archiwum Obrazowe
4 STER Ogólnoszpitalny System Rozliczeń z NFZ
5 CLININET - PSYCHO Szpitalny System Informatyczny - Psychoonkologia
6 SIMPLE.ERP Ogólnoszpitalny System Administracyjny
7 E-SIMPLE Ogólnoszpitalny System Obsługi Grafików Czasu Pracy
8 PROPHIX BI System Klasy Business Inteligence
9 REPORT PORTAL System Raportowania
10 KRN System Obsługi Krajowego Rejestru Nowotworów
11 ESKULAP System Obsługi Apteki Centralnej
12 PSM - ROCHE System Obsługi Markerów Nowotworowych
13 MARCEL - ICENTRUM System Obsługi Zakładu Chemii Klinicznej
14 MARCEL - ICENTRUM System Obsługi Serologii I Banku Krwi
15 ALTERIS - PACS System Obsługi Pracowni Mammografii
16 SYNEKTIK - PACS System Pacs Zakładu Radiodiagnostyki
17 INTRARIS System Ris Zakładu Medycyny Nuklearnej
18 MIKROBIONET System Obsługi Zakładu Mikrobiologii Klinicznej
19 NETRAAD PACS System Obsługi Zakład Teleradioterapii
20 GASTRO System Obsługi Klinika Gastroenterologii
21 SECTRA PACS System Obsługi Zakładu Medycyny Nuklearnej
22 ARIA - VARIAN System Obsługi Zakładu Teleradioterapii
23 MOSAIC System Zarządzania i weryfikacji leczenia - Zakład Teleradioterapii
24 ONCENTRA EXTERNAL BEAM System Planowania Leczenia
25 MONACO System Planowania Leczenia
26 ONCENTRA BRACHY System Planowania Leczenia
27 SIPBP System Informatyczny Programu Badań Przesiewowych
28 PRNK System Rejestru Guzów Gości
29 RKGIST System Rejestru GIST
30 KRPB System Rejestru Przełyku Baretta
31 ENDOBASE System Obsługi Zakładu Brachyterapii
W trakcie użytkowania systemu wprowadzono ponad 400 ustrukturyzowanych formularzy elektronicznych, które
zbierają dane dla potrzeb Elektronicznej Dokumentacji Medycznej. Dodatkowo Narodowy Instytut Onkologii im.
Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy posiada umowę na dostawę zestawów podpisu
elektronicznego dla personelu medycznego.
Dla potrzeb uruchomienia pełnej obsługi elektronicznej dokumentacji medycznej konieczna jest migracja systemu
zarządzania bazą danych na bardziej wydajną platformę. Obecny system zarządzania bazą danych przestał być
wydajny, pomimo migracji bazy danych na nowe macierze SSD i na nowe serwery o większej mocy obliczeniowej.
Ograniczenia licencyjne liczby procesorów obsługujących dotychczasową bazę danych powodują zbyt wolne
działanie systemu szpitalnego, a koszty zakupu licencji dotychczasowej bazy w wersji Enterprise w konfiguracji
Strona 30 z 106
z repliką on-line są zbyt duże w porównaniu do migracji systemu do nowego, wydajniejszego systemu zarządzania
bazą danych.
Ponadto zostaną zakupiony system digitalizacji pisma ręcznego, dzięki któremu pacjenci będą podpisywali
dokumenty, które wymagają własnoręcznego podpisu. Obecnie w Narodowym Instytucie Onkologii im. Marii
Skłodowskiej-Curie – Państwowym Instytucie Badawczym wymaganych jest ponad 400 różnego rodzaju
dokumentów (zgód pacjenta, ankiet itp.), które wymagają takiego podpisu. Poprzez wdrożenie systemu
digitalizacji pisma ręcznego i integracji go z systemem HIS dokumenty takie będą automatycznie przenoszone do
formy elektronicznej, dostępne będą z poziomu rekordu medycznego pacjenta i archiwizowane będą
w repozytorium elektronicznej dokumentacji medycznej. Dodatkowo dla w/w potrzeb (w innym postępowaniu)
zostaną zakupione skanery dokumentów, które po zintegrowaniu z systemem HIS będą skanowały dokumenty
dostarczone przez Pacjentów i umieszczały je w rekordzie medycznym pacjenta.
Dla potrzeb obsługi procesu rejestracji pacjentów dostarczone infokioski zostaną zintegrowane z systemem HIS
Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego i dzięki
wbudowanym skanerom będą umożliwiały potwierdzenie przybycia do Poradni poprzez zeskanowanie kodu
z Karty Pacjenta.
Metody uwierzytelniania
Przewiduje się następujące metody uwierzytelniania:
ePUAP - dla pacjentów korzystających z e-Usług wdrażanych w ramach projektu,
ePUAP z możliwością dodatkowej autoryzacji tokenem SMS - dla pacjentów korzystających z e- Usług
A2C,
login+hasło lub certyfikat+PIN - dla lekarzy działających na systemie medycznym w placówce
medycznej,
ePUAP + token SMS lub specjalnie założone konto przez administratora systemu dla użytkownika na
podstawie wniosku podmiotu współpracującego, uwierzytelnianie hasłem i nazwą użytkownika - dla
współpracujących podmiotów wykorzystujących e-Usługi typu A2B.
Węzeł Krajowy identyfikacji elektronicznej (login.gov.pl), o którym mowa w Ustawie o zmianie ustawy
o usługach zaufania oraz identyfikacji elektronicznej oraz niektórych innych ustaw (Dz.U. z 2018 r. poz.
1544, Dz.U. z 2018 r. poz. 650)
I.8 Ogólne warunki wdrożenia e-Usług oprogramowania SSI
W ramach zamówienia przewiduje się wdrożenie następujących e-usług, które będą świadczone u Zamawiającego
z chmury lokalnej:
a) - e-rejestracja,
b) - e-konsultacje,
c) - e-wywiad,
d) - e-dokumentacja,
e) - e-powiadomienia,
f) - e-partner,
g) - e-obchód,
h) - e-informator.
Wdrażany system teleinformatyczny spełniać będzie wymagania WCAG - Web Content Accessibility Guidelines
(WCAG 2.0), z uwzględnieniem co najmniej poziomu AA, określonych w załączniku nr 4 do rozporządzenia.
Licencje na e-usługi dla Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego
Instytutu Badawczego
Przedmiotem zamówienia jest dostawa licencji na e-usługi dla Zamawiającego. Przedmiotem zamówienia jest
również wdrożenie tych e-usług, w chmurze obliczeniowej lokalnej, na udostępnionych zasobach serwerowych
dla Projektu. Poniżej zawarto opis parametrów minimalnych, funkcjonalności i procesów logicznych usług.
Wykonawca ma obowiązek zaprojektowania wdrażanych e-usług w oparciu o poniższe struktury logiczne i opisy
systemu. E-usługi muszą zostać zintegrowane z systemem Zamawiającego. Korzystanie przez usługobiorcę
z elektronicznych usług publicznych musi być możliwe różnymi kanałami dostępu, niezależnie od miejsca
przebywania i wykorzystywanej technologii. Dostęp do usług ma zostać zapewniony z komputerów niezależnie
od systemu operacyjnego (Windows, MacOX, Linux), telefonów komórkowych – smartphone, tabletów, laptopów
oraz z e-kiosków zainstalowanych w wybranych lokalizacjach.
Strona 31 z 106
I.9 Baza danych – Wymagania ogólne
Wykonawca wykona wszystkie prace programistyczne i migracyjne w celu przeniesienia wszystkich
funkcjonalności starego i obecnie funkcjonującego systemu HIS Zamawiającego, którym jest obecnie system
CompuGroup Medical Polska CLININET Sybase, na nowy wydajniejszy silnik bazodanowy w szybkim
środowisku bazodanowym, który Wykonawca dostarczy i zainstaluje zgodnie z rozdziałem II niniejszego
zamówienia. Lista funkcjonalności systemu CLININET opartego o bazę danych Sybase stanowi Załącznik nr 1.1
do niniejszego OPZ. Wykonawca musi odtworzyć wszystkie funkcjonalności zawarte w tym załączniku na nowym
środowisku bazodanowym, instalując system HIS w nowym środowisku bazodanowym. Wszystkie odtwarzane
funkcjonalności systemu na nowej bazie danych muszą zostać szczegółowo odwzorowane zgodnie z załącznikiem
dotyczącym funkcjonalności i formularzy: Załącznik nr 1.1 do OPZ - Lista funkcjonalności i zależności obecnie
użytkowanego systemu HIS podlagającego przeniesieniu na nową bazę danych oraz Załącznikiem nr 1.3 do OPZ
– Inwentaryzacja systemu informatycznego CGM CliniNET i Załącznik nr 1.5 - Inwentaryzacja systemu
informatycznego CGM CliniNet Psychoonkologia.
Dodatkowo Zamawiający wymaga aby wszystkie dane zawarte w systemie HIS obecnie funkcjonującym, były
zmigrowane do nowej bazy danych systemu HIS na zasadach określonych w I.9.5. do OPZ – migracja danych.
Zamawiający wymaga dostarczenia nowej, bardziej wydajnej bazy danych, które umożliwi również przeniesienie
na dostarczone w niniejszym postępowaniu macierz i serwery wspomagające.
I.9.1 Dane w systemie HIS
Zamawiający oświadcza, że posiada oprogramowanie dedykowane do pracy w środowisku Szpitala - CGM
CLININET i CGM NETRAAD. Zamawiający nabył oprogramowanie, które użytkuje na podstawie innych
postępowań publicznych i nie posiada do niego odmiennych praw licencyjnych związanych z prawami autorskimi
zgodnie z art. 52 ust 1 Ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (tj. Dz. U. z 2019
r. poz. 1231.) zwaną dalej Papp. Zamawiający na podstawie swojej licencji do posiadanego oprogramowania, ma
prawo do m.in. zwielokrotniania kodu lub tłumaczenie jego formy w rozumieniu art. 74 ust. 4 pkt 1 i 2 Papp, jeżeli
jest to niezbędne do uzyskania informacji koniecznych do osiągnięcia współdziałania niezależnie stworzonego
programu komputerowego z innymi programami komputerowymi, o ile zostaną spełnione następujące warunki:
a) czynności te dokonywane są przez licencjobiorcę lub inną osobę uprawnioną do korzystania
z egzemplarza programu komputerowego bądź przez inną osobę działającą na ich rzecz,
b) informacje niezbędne do osiągnięcia współdziałania nie były uprzednio łatwo dostępne dla osób,
o których mowa pod lit. a,
c) czynności te odnoszą się do tych części oryginalnego programu.
Ponadto, oprogramowanie, które Zamawiający używa, korzysta z bazy danych, która nosi znamiona i cechy
utworu zgodnie z art. 1 Papp oraz podlega ochronie sui generis zgodnie z definicją bazy danych zawartą w ustawie
z dnia 27 lipca 2001 roku o ochronie baz danych (tj. Dz. U. 2018 r. poz. 2339.), dalej Obd.
Dane zawarte w tej bazie danych są danymi Zamawiającego, jednak w momencie tworzenia bazy danych systemu
użytkowanego przez Zamawiającego, dane te w momencie migracji i wprowadzania danych do systemu, zostały
usystematyzowane, uporządkowane według określonych paramentów, narzuconych przez uprzedniego
wykonawcę, a przez to stały się częścią składową tej bazy danych, w zgodzie z art. 2 ust. 1 pkt. 1 Obd. Wykonawca,
może pobrać dane z bazy danych tylko i wyłącznie na podstawie przepisów ustawy, w szczególności art. 2 ust. 1,
art. 7 oraz art. 8 ust. 2 Obd. Zamawiający może pobrać jedynie dane określone poniżej i przekazać je Wykonawcy
w postaci uporządkowanych plików xls lub txt.
Wykonawca jest zobowiązany do dostarczenia w nowym środowisku wszystkich funkcjonalności systemu
posiadanego przez Zamawiającego w następujących obszarach:
1. System po przeprowadzonym procesie migracji musi zachować pełną funkcjonalność użytkowaną obecnie
przez Zamawiającego. Szczegółowy wykaz funkcji systemu, który użytkuje Zamawiający zawiera Załącznik
nr 1.1. Oferent wraz z ofertą załączy wykaz funkcji wraz z deklaracją działania tych funkcji na wydajnej
platformie bazy danych zgodnie ze wzorem stanowiącym Załącznik nr 1. W ramach procesu oceny oferty
Zamawiający dokona weryfikacji posiadania funkcjonalności na podstawie próbki Szpitalnego Systemu
Informatycznego działającego w oparciu o wydajną bazę danych dostarczoną wraz z ofertą. Stwierdzenie
niezgodności z deklaracją przedstawioną w ofercie w zakresie wymagań i parametrów wymaganych
i ocenianych dla co najmniej 1 (jednej) funkcjonalności ze scenariusza prezentacji próbki skutkować będzie
odrzuceniem oferty.).
Przebieg prezentacji decyzją zamawiającego może zostać utrwalony poprzez urządzenie/urządzenia
rejestrujące dźwięk i wizję na potrzeby dokumentacji przetargowej i do wiadomości komisji przetargowej oraz
jako pomoc w sporządzeniu pisemnego protokołu z przeprowadzonej weryfikacji. Prezentacja może być
zarejestrowana wyłącznie przez Zamawiającego. Na każdym etapie prezentacji Komisja Zamawiającego może
zadawać pytania i prosić o zrzuty ekranów prezentujących dane funkcjonalności. Materiał ten (zrzutu ekranów)
Strona 32 z 106
zostanie po prezentacji przekazany Komisji przez Prezentujących na przygotowanym wcześniej nośniku
pamięci masowej USB.
2. System po migracji na wydajną bazę danych ma zachować możliwość użytkowania wszystkich raportów,
wydruków oraz formularzy używanych obecnie przez Zamawiającego. Wykonawca w ramach etapu analizy
przedwdrożeniowej wykona inwentaryzację tych elementów. Wykonawca ma obowiązek przeniesienia
wszystkich tych elementów w ramach procesu migracji.
3. System musi być uruchomiony i wdrożony we wszystkich komórkach organizacyjnych wymienionych
w rozdziale „Opis stanu bieżącego” tego dokumentu z odrębnymi instancjami systemu.
4. System musi mieć możliwość zachowania ciągłości pracy wszystkich użytkowników. Jeżeli elementy
interfejsu graficznego systemu i/lub przebiegu procesu ulegną zmianie w wyniku migracji Wykonawca jest
zobowiązany w tych obszarach przeprowadzić instruktaż dla wszystkich użytkowników systemu. Wymagania
dla procesu instruktarzy przedstawione są w akapicie „Instruktaże Personelu Zamawiającego”.
5. Wykonawca jest zobowiązany do uruchomienia pełnego zakresu integracji z systemami opisanymi w rozdziale
„Opis stanu bieżącego”. Koszt ewentualnej modyfikacji integrowanych systemów stanowi koszt Wykonawcy
i jest on w pełni odpowiedzialny za uruchomienie pełnych funkcjonalności integracji po wykonaniu migracji
w momencie startu produkcyjnego systemu po migracji.
6. Wykonawca jest zobowiązany do skonfigurowania procedur backupu systemu z wykorzystaniem narzędzi
używanych przez Zamawiającego.
I.9.2 Interfejsy komunikacyjne
Zamawiający wymaga aby w zakresie nowo wdrażanych systemów objętym niniejszym zamówieniem,
Wykonawca przedstawił stosowny dokument, opisujący „Interfejs komunikacyjny API systemu szpitalnego
Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego do
systemów EDM i e-Usług” z systemami programowymi Wykonawcy, pozwalający na integrację bazy danych
systemu z innymi systemami, będącymi w przyszłości instalowanymi w infrastrukturze Zamawiającego, oraz opis
struktury bazy danych systemu, tak aby w przyszłości w trakcie jego wymiany, można było bezproblemowo
migrować dane zamawiającego, które w momencie wdrożenia systemu zostały ustandaryzowane.
Zamawiający do przeprowadzenia migracji bazy danych udostępni interfejs administracyjny serwerów baz danych
w trybie odczytu. Wykonawca nie może ingerować w dane ani strukturę danych jak i samych baz danych w celu
przeprowadzenia procesu migracji danych.
I.9.3 Opis stanu bieżącego
Zamawiający użytkuje obecnie system klasy HIS (Hospital Information System) CliniNet, którego producentem
jest CompuGroup Medical Polska sp. z.o.o. (CGM) Zamawiający posiada następującą konfigurację systemu:
Licencje systemu CliniNet na użytkownika – licencja OPEN – bez limitu użytkowników
Licencje na bazę danych Sybase – 4 licencje 15.5 (serwer bazodanowy 1, serwer bazodanowy 2, serwer raportowy,
serwer na potrzeby Disaster REcovery)
Sybese Replication Serwer
Serwery aplikacyjne i bazodanowe -
System CliniNet (obecna nazwa to CGM CLININET) zainstalowany i wdrożony jest na trzech niezależnych
instancjach bazy danych.
1. Clininet PRD
2. Clininet TRN (treningowa)
3. Clininet Psychoonkologia:
4 serwery aplikacyjne w postaci maszyn wirtualnych (dostęp pracowników poprzez www do aplikacji
Clininet)
5 serwerów bazy danych Sybase w postaci maszyn wirtualnych
1 serwer replikacji danych
4. Apteka szpitalna – oprogramowanie Eskulap (firma MedHub):
1 serwer z bazą danych Oracle wersja 9
Lista modułów posiadanych przez Zamawiającego oraz opis ich funkcjonalności znajduje się w załączniku nr 1.1
Strona 33 z 106
System jest zintegrowany z następującymi systemami użytkowanymi przez Zamawiającego:
Nazwa Systemu Krótki opis integracji
ONKOSYS System jest zintegrowany z systemem HIS w zakresie udostępniania danych
medycznych do badań naukowych za pomocą widoków z bazy danych.
System laboratorium Marcel - 2
pracownie/2 lokalizacje (siedziby
Zamawiającego)
Pełna integracja z systemem Marcel, obejmująca zakłady Chemii Klinicznej
oraz Serologii w dwóch lokalizacjach. Elektroniczne przesyłanie zleceń na
wykonanie badania (dane pacjenta, zlecone badania, materiał na jakim
badanie jest wykonywane, numer próbki, dane jednostki zlecającej, dane
lekarza zlecającego) oraz elektroniczny odbiór wyników. Integracja
odbywa się w standardzie HL7 v 2.3
KRN System HIS przekazuje dane niezbędne do wypełnienia karty zgłoszenia
nowotworu złośliwego za pomocą pliku XML z wykorzystaniem standardu
SOA.
Roche / Marcel Pełna integracja z systemem Roche, obejmująca zakład Markerów
Nowotworowych. Elektroniczne przesyłanie zleceń na wykonanie badania
(dane pacjenta, zlecone badania, materiał na jakim badanie jest
wykonywane, numer próbki, dane jednostki zlecającej, dane lekarza
zlecającego) oraz elektroniczny odbiór wyników wraz z podpisanymi
elektronicznie dokumentami “pdf”. Integracja odbywa się w standardzie
HL7 v 2.3
ATD Pełna integracja z systemem ATD, obejmująca Zakład Mikrobiologii.
Elektroniczne przesyłanie zleceń na wykonanie badania (dane pacjenta,
zlecone badania, materiał na jakim badanie jest wykonywane, numer
próbki, dane jednostki zlecającej, dane lekarza zlecającego) oraz
elektroniczny odbiór wyników (w tym antybiogramów). Integracja odbywa
się w standardzie HL7 v 2.3
PatArch Pełna integracja z systemem PatArch, obejmująca Zakład Patomorfologii.
Elektroniczne przesyłanie zleceń na wykonanie badania (dane pacjenta,
zlecone badania, materiał na jakim badanie jest wykonywane, numer
próbki, dane jednostki zlecającej, dane lekarza zlecającego) oraz
elektroniczny odbiór wyników wraz z podpisanymi elektronicznie
dokumentami „pdf”. Integracja odbywa się w standardzie HL7 v 2.3
WelchAllyn Obecnie trwają prace integracyjne nad uruchomieniem interface przesyłania
danych z wózkami pomiarów parametrów życiowych firmy WelchAllyn.
Wymagana pełna integracja
RIS/PACS Pełna integracja z systemem RIS/PACS firmy CGM. Elektroniczne
przesyłanie zleceń na wykonanie badania (dane pacjenta, zlecone badania,
dane jednostki zlecającej, dane lekarza zlecającego) oraz elektroniczny
odbiór wyników wraz z możliwością wywołania przeglądarki plików
DICOM z poziomu systemu HIS. Integracja odbywa się w standardzie
DICOM.
Rozmiary baz Produkcyjnych:
=================================
CliniNET_PRD: 697402 MB
CliniNET_PSY_PRD: 9080 MB
NetRAAD (IMAGE / CTNControl): 166997 MB
STER (uhc_contracts): 89342 MB
Liczba tabel:
=================================
CliniNET_PRD: 5268
CliniNET_PSY_PRD: 4245
NetRAAD (IMAGE / CTNControl): 143
STER (uhc_contracts): 234
Stan na dzień 22.06.2019
Strona 34 z 106
Bazy Treningowe stanowią kopię 1:1 baz Produkcyjnych, więc rozmiar / liczba tabel (razem z TRN) będzie x2
(dwukrotnie większa).
L.P. ZAKRES DANYCH ŚRODOWISKO
BAZODANOWE
CZY ISTNIEJE
MOŻLIWOŚĆ
WYEKSPORTOWANIA
WSKAZANEGO ZAKRESU
DANYCH DO FORMATU
ZEWNĘTRZNEGO ?
(TAK / NIE)
JEŚLI ISTNIEJE
MOŻLIWOŚĆ
WYEKSPORTOWANIA
WSKAZANEGO
ZAKRESU DANYCH,
JAKI JEST TO FORMAT
EKSPORTU?
1 dane o pacjentach i ich
opiekunach,
Sybase TAK XML, CSV
2 Słownik personelu Sybase TAK XML, CSV
3 Słownik jednostek
kierujących,
Sybase TAK XML, CSV
4 Słownik lekarzy
kierujących
Sybase TAK XML, CSV
5 dane o płatnikach i
umowach,
Sybase TAK XML, CSV
6 dane statystyczne
rozliczonych
pacjentów do NFZ,
dane wykonanych
usług medycznych
Sybase TAK XML, CSV, format
eksportu NFZ
7 dane opisowe Sybase TAK XML, CSV
8 wyniki badań Sybase TAK XML, CSV
9 Kolejki oczekujących Sybase TAK XML, CSV
I.9.4 Zakres i przedmiot migracji bazy danych
Przedmiotem zamówienia jest migracja funkcjonalności użytkowanego systemu CGM CLININET firmy CGM na
wydajniejszy silnik bazy danych, celem podniesienia całkowitej wydajności i skalowalności systemu. Proces
migracji musi odbywać się ze szczególnym uwzględnieniem zachowania ciągłości pracy Zamawiającego
i w ramach tego procesu wszelkie przestoje systemu muszą być zaplanowane i uzgodnione z Zamawiającym.
W ramach procesu migracji Wykonawca jest zobowiązany do przeniesienia danych z użytkowanych instancji
(produkcyjnych i treningowych) systemu na nowy dostarczany w ramach zamówienia silnik bazy danych
i uruchomienia w takiej konfiguracji wszystkich funkcjonalności systemu opisanych w Załączniku nr 1.1 do OPZ
oraz uruchomienia systemu we wszystkich użytkowanych obecnie przez Zamawiającego aspektach to jest:
1. System musi być uruchomiony we wszystkich komórkach organizacyjnych wymienionych wyżej. Musi
zostać zachowany podział pomiędzy część systemu dostępną dla Narodowego Instytutu Onkologii im.
Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego oraz wyodrębnioną (odseparowaną
logicznie) część w obszarze psychoonkologii.
2. Musi mieć możliwość zachowania ciągłości pracy wszystkich użytkowników. Jeżeli elementy interfejsu
graficznego systemu i/lub przebiegu procesu ulegną zmianie w wyniku migracji Wykonawca jest
zobowiązany w tych obszarach przeprowadzić instruktaż dla wszystkich użytkowników systemu.
3. Wykonawca jest zobowiązany do uruchomienia pełnego zakresu integracji z systemami opisanymi
w części „Opis stanu bieżącego”. Koszt ewentualnej modyfikacji integrowanych systemów stanowi koszt
Wykonawcy i jest on w pełni odpowiedzialny za uruchomienie pełnych funkcjonalności integracji po
wykonaniu migracji.
Strona 35 z 106
W ramach procesu migracji Wykonawca jest zobowiązany do wykonania następujących zadań:
1. Dostarczenia wydajnego silnika bazy danych przeznaczonego dla systemów HIS, wraz z umową
utrzymania i wsparcia zgodnie z Umową, którego wymagania opisane są w tym dokumencie we
wskazanej liczbie licencji.
2. Dostarczenia niezbędnych licencji systemów operacyjnych dla serwerów, których wymagania opisane są
w niniejszym Opisie Przedmiotu Zamówienia
3. Wykonania audytu bieżącej instalacji systemu – wszystkich elementów systemu, celem określenia
szczegółowej listy elementów niestandardowych, które będą podlegały odtworzeniu na nowym
środowisku bazy danych w szczególności formularzy, raportów i wydruków używanych przez
Zamawiającego.
4. Przedstawienia planu migracji i projektu technicznego migracji do akceptacji Zamawiającego.
5. Wykonania zaakceptowanego planu migracji w szczególności zainstalowania, uruchomienia i wdrożenia
systemu na nowej wydajnej bazie danych wraz ze wszystkimi elementami niezbędnymi do jego
poprawnego funkcjonowania takimi jak: systemy operacyjne, serwery aplikacyjne, konfiguracja bazy
danych, itd.
6. Przeniesienia wszystkich danych z użytkowanego systemu CGM CLININET na nowy, wydajniejszy
system zarządzania bazą danych (SZBD).
7. Wykonania wcześniej przygotowanych na podstawie metodyki, testów potwierdzających poprawne
funkcjonowanie aplikacji wraz ze wszystkimi funkcjami wymienionymi w ramach Załącznika nr 1.1 do
OPZ oraz potwierdzającymi prawidłowość działania formularzy, raportów, wydruków i integracji
z innymi systemami.
8. Przeprowadzenia instruktaży dla użytkowników w zakresie w jakim modyfikacji uległ interfejs graficzny
użytkownika i/lub przebieg procesów w systemie.
9. Przedstawienie raportu z migracji zawierającego raporty z testów oraz potwierdzenie przeniesienia
danych pomiędzy systemami.
10. Uruchomienia i wdrożenia systemu na nowej wydajniejszej bazie danych wraz z asystą uruchomieniową
w zakresie w jakim modyfikacji uległ interfejs graficzny użytkownika i/lub przebieg procesów
w systemie.
11. Przeprowadzenia instruktaży dla administratorów Zamawiającego z nowej konfiguracji systemu.
12. Świadczenia usług serwisowych dla prac migracyjnych zgodnie z Umową.
13. Wykonawca ponosi odpowiedzialność za ewentualne szkody, wyrządzone przez jego pracowników,
powstałe w wyniku działań prowadzonych przez Wykonawcę na bazach danych posiadanych przez
Zamawiającego systemów.
14. Świadczenia usług serwisowych dla wszystkich nowo dostarczanych modułów, licencji związanych
z wdrożeniem zgodnie z Umową.
I.9.5 Migracja danych
Wykonawca jest odpowiedzialny za przeprowadzenie pełnego procesu migracji danych pomiędzy obecnie
użytkowaną bazą SYBASE ASE systemu HIS na nową wydajniejszy system zarządzania bazą danych.
Zamawiający na etapie realizacji umowy zapewni Wykonawcy dostęp do bazy danych obecnie użytkowanego
systemu. Zamawiający do przeprowadzenia migracji bazy danych udostępni interfejs administracyjny serwerów
baz danych w trybie odczytu. Wykonawca nie może ingerować w dane ani strukturę danych jak i samych baz
danych obecnie użytkowanego systemu HIS CGM CLININET w celu przeprowadzenia procesu migracji danych.
Wykonawca w ramach procesu migracji systemu CGM CLININET do wydajniejszej bazy danych dostarczy,
zainstaluje, skonfiguruje oraz dokona strojenia do wydajnej pracy systemu środowisko Systemu HIS aby uzyskać
następującą konfigurację systemu, zgodnie z częścią II.1
Szczegółową konfigurację uwzględniającą również powiązanie z istniejącą infrastrukturą Zamawiającego
Wykonawca zaprojektuje i przedstawi do akceptacji Zamawiającego w procesie analizy przedwdrożeniowej
w projekcie technicznym migracji.
W ramach konfiguracji środowiska systemu Zamawiający będzie odpowiedzialny za konfigurację, urządzeń
sieciowych zgodnie z uzgodnionym projektem technicznym migracji. Za pozostałe prace w tym instalację
i konfigurację serwerów, systemów operacyjnych, baz danych i aplikacji odpowiada Wykonawca.
Strona 36 z 106
Tabela: struktura baz danych wymagających migracji
L.P. OPIS SZCZEGÓŁY
1. Ilość baz danych 4
2. Rodzaj baz danych złożona relacyjna
3. Struktura poszczególnych baz
danych
relacyjna
4. Rodzaje i ilość tabel tabele zgodne z bazą danych Sybase - 9890 tabel
5. Zakres danych w tabelach dane medyczne z lat 1999 - 2019
6. Opis danych w tabelach pacjenci, słowniki, dane rozliczeniowe, dane statystyczne,
kolejki oczekujących
7. Relacje pomiędzy danymi w podmiocie medycznym przyjęto taką relację między
danymi, że nigdy jedna informacja, nie jest zapisywana
w bazie dwa razy
8. Zainstalowane procedury po
stronie serwera bazy danych
procedura bezpieczeństwa, procedura kontroli spójności
danych
9. Logiczne powiązania pomiędzy
tabelami w bazie danych
brak
10. Rozmiar baz danych Są 4 instancje – CliniNet – 700GB, CliniNet-Psycho – 9GB,
NetRAAD – 167GB, STER – 90GB,
11. Sposób migracji Do decyzji wykonawcy. Możliwość udostępnienia pliku csv,
xls.
12. Informacje na temat spójności
danych
dane są spójne
I.9.6 Przebieg procesu migracji
W procesie planowania i realizowania migracji danych wymagane jest planowanie i przeprowadzenie procesu
migracji danych przez Wykonawcę przy uwzględnieniu minimum następujących faz/kroków, po
przeprowadzonym procesie instalacji systemów i aplliance systemów:
1. Przygotowanie planu migracji danych ‐ ustalenie zakresu danych do migracji, sposoby i zakres danych
do poprawienia, struktury pośrednich, sposobu przekazania danych, sposobów weryfikacji i innych
szczegółów potrzebnych do prawidłowej migracji wszystkich danych wymaganych przez
Zamawiającego. Szczegółowy opis wymagań dla planu migracji zawarto w części „Analiza
przedwdrożeniowa”
2. Pobranie danych do struktur pośrednich – czynność dotyczy przygotowania i wykonania
uzgodnionych w planie migracji skryptów pobierających dane do struktur pośrednich (np. testowa baza
danych, pliki XML) i eksportu danych do tych struktur. W ramach tego kroku Wykonawca zobowiązany
jest do wykonania procesu podniesienia jakości danych słownikowych.
3. Weryfikacja poprawności danych w strukturach pośrednich – weryfikacja poprawności procesu
exportu danych z systemu źródłowego i importu do struktur pośrednich. W przypadku wystąpienia
błędów przy weryfikacji danych w strukturach pośrednich, ustalana jest przyczyna błędu. Jeżeli
przyczyna leży w złym pobraniu danych z systemu źródłowego proces wraca do kroku „Pobranie danych
do struktur pośrednich”. Jeżeli problem dotyczy błędu w procedurach importu danych należy poprawić te
procedury i ponownie dokonać importu i weryfikacji danych.
4. Migracja testowa - w celu realizacji migracji testowej Wykonawca zobowiązany jest do wykonania
kopii docelowego środowiska wydajnej bazy danych na infrastrukturze Zamawiającego
i przeprowadzenia kompletnego zasilania danymi tego środowiska za pomocą skryptów i algorytmów,
które będą wykorzystywane przy docelowej migracji. Celem migracji testowej jest przetestowanie
Strona 37 z 106
procedur eksportu/importu danych, procedur czyszczenia, uzupełniania, agregacji danych, procedur
weryfikacji danych. Migracja testowa co do zasady powinna być wykonywana na pełnych danych.
Dopuszcza się w niektórych szczególnie wymagających obszarach (ze względu na ilość danych)
realizację migracji testowej na reprezentatywnej próbce danych, po wcześniejszym ustaleniu i zgodzie
Zamawiającego.
5. Weryfikacja migracji testowej – w ramach procesu weryfikacji procesu migracji testowej przewiduje
się wykorzystanie następujących metod sprawdzania poprawności jej wykonania:
a) Szczegółowa weryfikacja zapis po zapisie - jest możliwa tylko jeżeli zbór migrowanych danych nie jest
liczny i polega na porównaniu danych w starym rozwiązaniu oraz w nowym Systemie zapis po zapisie.
Dla ułatwienia tego porównania Dostawca Systemu może w niektórych przypadkach przygotować
zestawienia tabelaryczne danych z nowego systemu eksportowanie do arkusza kalkulacyjnego lub
wydrukowane. Wtedy porównanie polega na zaznaczeniu każdego poprawnego zapisu na wydruku lub
w arkuszu.
b) Porównanie skryptami - weryfikacja polegająca na uruchomieniu napisanych wcześniej skryptów
porównujących dane znajdujące się w nowym Systemie z danymi źródłowymi zapisanymi w tabelach
systemu testowego i źródłowego. W takim przypadku raport zgodności/różnic powinien
być automatycznie wygenerowany.
c) Wyrywkowa kontrola danych przez użytkowników - weryfikacja przeprowadzana przez
użytkowników docelowych Systemu, mających dostęp do nowego środowiska testowego Systemu oraz
Systemu źródłowego. Polega na wyszukaniu wybranych danych w jednym i drugim systemie oraz ich
porównaniu. Wykonawca wykona na środowisku testowym uzgodniony na etapie analizy
przedwdrożeniowej zestaw testów funkcjonalnych systemu i przedstawi Zamawiającemu raport z ich
realizacji. Dodatkowo Wykonawca udostępni wskazanym pracownikom Zamawiającego środowisko
testowe na okres min. 2 tygodni tak by mogli oni sprawdzić poprawność działania systemu po migracji
wyżej opisaną metodą.
d) Porównanie raportów i wydruków z Systemu źródłowego oraz Systemu testowego - ma polegać na
uruchomieniu i porównaniu raportów/wydruków wygenerowanych z Systemu testowego oraz Systemu
źródłowego.
e) Porównanie formularzy dokumentacji medycznej z Systemu źródłowego oraz Systemu testowego
- ma polegać na uruchomieniu i porównaniu formularzy wygenerowanych z Systemu testowego oraz
Systemu źródłowego.
f) Weryfikacja statystyczna – ma polega na stworzeniu kryteriów poprawności dla migrowanych danych
np. liczby rekordów w obydwu systemach dla konkretnych tabel w bazie danych, wartość i liczby
świadczeń przekazanych do NFZ itp. Wykonaniu przez dostawcę zestawień porównawczych z obydwu
systemów, które umożliwią stwierdzenie poprawności migracji.
W ramach testowania poprawności migracji zostaną zrealizowane minimum następujące testy:
Testy funkcjonalne
Testy integracji
Zgodnie z metodyką opracowaną na odrębnym etapie i części zamówienia.
6. Migracja docelowa produkcyjna – właściwa migracja, po której rozpoczyna się produkcyjną pracę
w nowym Systemie. W przypadku braku stwierdzonych istotnych problemów w trakcie wcześniejszych
kroków procesu migracji Zamawiający podejmuje decyzję o przeprowadzeniu procesu migracji do
nowego, docelowego Systemu opartego o wydajniejszą bazę danych. Wykonawca po procesie migracji
jest zobowiązanych do weryfikacji poprawności przeniesionych danych – końcowa weryfikacja danych
poprzez wykonanie testów poprawności migracji (walidacji danych po migracji) oraz testów wydajności.
Pozytywny wynik kończy proces migracji danych.
Wykonawca zobowiązany jest zabezpieczyć trwale dane z systemu źródłowego z momentu migracji danych
w postaci kopii bezpieczeństwa danych systemu źródłowego i w przypadku niepowodzenia procesu migracji
w założonym harmonogramie przywrócić działanie poprzedniego systemu. Kopie danych oraz systemu w wersji
użytkowanej przez Zamawiającego w liczbie sztuk 2 zostaną przekazane Zamawiającemu.
Wykonawca przeprowadzać będzie migracje w siedzibie Zamawiającego. W przypadku, gdy nie będzie to
możliwe, Wykonawca zobowiązany będzie do zabezpieczenia pozyskanych od Zamawiającego migrowanych
danych w sposób uniemożliwiający wejście w ich posiadanie przez osoby nieupoważnione do ich przetwarzania.
Po wykonaniu migracji, wszelkie dane pozyskane w toku migracji przez Wykonawcę zamówienia muszą zostać
usunięte ze wszystkich nośników Wykonawcy w sposób uniemożliwiający ich odzyskanie. Jeżeli wystąpi
konieczność przekazania Wykonawcy danych do migracji poza siedzibę Zamawiającego, przekazanie będzie się
odbywać protokolarnie upoważnionemu przedstawicielowi Wykonawcy, a prace związane z obróbką
Strona 38 z 106
pozyskanych danych odbywać się będą jedynie w siedzibie Wykonawcy. Wykonawca nie jest upoważniony do
przekazywania danych z migracji innym podmiotom.
Dodatkowe wymagania dla procesu migracji zawiera poniższa tabela:
Nr
wymagania
Opis
1 W ramach procesu migracji Wykonawca zobowiązany jest do zachowania ciągłości procedur
i procesów realizowanych przez Zamawiającego w szczególności musi zachować ciągłość i format
wszystkich numeracji stosowanych w procesach leczenia (nr księgi głównej, ksiąg zabiegowych,
nr kartotek pacjentów itp.)
2 W procesie migracji zostaną przeniesione wszystkie dane historyczne zgromadzone i przetwarzane
obecnie przez Zamawiającego w systemie HIS CGM CLININET
3 Proces migracji musi zapewnić ciągłość rozliczeń z NFZ zarówno w zakresie nowych danych
wprowadzanych do zmigrowanego Systemu jak i korekty danych wcześniej przekazanych do
płatników (NFZ i inni).
4 Wykonawca wykona migrację danych do nowej wydajniejszej bazy danych zgodnie
z zaakceptowanym planem migracji danych. Wykonawca jest odpowiedzialny za wykonanie migracji
wszystkich danych potrzebnych do prawidłowego działania Systemu.
5 Proces migracji nie może zaburzyć wzajemnych powiązań logicznych danych. Wzajemne relacje
pomiędzy danymi w systemie muszą być zachowane (integralność danych).
6 Migracja musi być przeprowadzona w dwóch etapach:
migracja testowa
migracja produkcyjna.
7 Warunkiem możliwości wykonania migracji produkcyjnej jest akceptacja przez Zamawiającego
wyników migracji testowej na podstawie raportu z testów migracji przedstawionego przez
Wykonawcę.
8 Wykonawca ponosi odpowiedzialność za poprawność danych migrowanych do nowego Systemu i
jest zobowiązany bez zbędnej zwłoki usunąć wszelkie skutki wynikające z błędów migracji i dokonać
naprawy danych i działania Systemu nawet w przypadku jeżeli nieprawidłowości wystąpią w procesie
eksploatacji systemu po odbiorze procedury migracji. Zobowiązanie to dotyczy całości trwania okresu
umowy oraz okresu gwarancji/rękojmi.
I.9.7 Asysta techniczna w procesie migracji produkcyjnej
W ramach procesu migracji produkcyjnej Wykonawca przez okres 10 dni od jej wykonania zobowiązany jest
prowadzić asystę techniczną u Zamawiającego. W ramach tej asysty zobowiązany jest zapewnić obecność
u Zamawiającego począwszy od 1 dnia roboczego (co najmniej 8h) po wykonaniu startu produkcyjnego systemu
na nowej bazie danych następujących specjalistów:
1. Administrator bazy danych - 1 osoba 2 dni po starcie produkcyjnym
2. Administrator systemów operacyjnych – 1 osoba 2 dni po starcie produkcyjnym
3. Wdrożeniowiec systemu HIS – 2 osoby 5 dni po starcie produkcyjnym
4. Programista – projektant formularzy – 1 osoba 5 dni po starcie produkcyjnym
Osoby te zobowiązane są na bieżąco wspierać pracowników Zamawiającego w identyfikacji i usuwaniu usterek,
które mogą powstać po procesie migracji. Zamawiający zastrzega sobie prawo skrócenia tego okresu, jeżeli uzna,
że stabilność systemu po migracji jest wystarczająca.
I.9.8 Testy
Wykonawca ma obowiązek wykonać testy całości projektu, ale również, odrębnie testy samej migracji bazy
danych razem z walidacją tych danych. Testy zostaną przeprowadzone w sposób opisany poniżej, a metodologia
prowadzenia testów ma zostać oparta o metodologię testów całości wdrożenia projektu.
W ramach realizacji przedmiotu umowy Wykonawca zobowiązany jest przeprowadzić zestaw testów
potwierdzających poprawność wykonania migracji. Testy będą przeprowadzane przez Wykonawcę przy
Strona 39 z 106
współudziale Zamawiającego jak i wskazanych przez Zamawiającego osób i podmiotów zewnętrznych W skład
testów realizowanych w ramach procesu migracji systemu HIS powinny zostać zrealizowane minimum
następujące testy:
1. Testy funkcjonalne – zestaw testów potwierdzających możliwość realizacji kluczowych procesów na
środowisku systemu po migracji na nowy silnik bazy danych.
2. Testy wydajnościowe – testy mające na celu potwierdzenie, że założone w procesie migracji wskaźniki
zwiększenia wydajności systemu poprzez migrację na nowy, wydajniejszy silnik bazy danych zostały
osiągnięte.
3. Testy integracji – testy potwierdzające zdolność systemu po migracji do współpracy z innymi systemami
dla których konieczność integracji została opisana w SIWZ.
4. Testy integralności i poprawności zmigrowanych danych w nowym, wydajniejszym SZBD
5. Testy bezpieczeństwa - testy obejmować będą swym zakresem:
a. Testy penetracyjne wskazanych zasobów wykonywane metodą white, black lub grey -box
b. Testy bezpieczeństwa aplikacji wytworzonych i dostarczonych w ramach projektu wskazanych przez
Zamawiającego na etapie Analizy przedwdrożeniowej
c. Testy poprawności konfiguracji i parametryzacji sprzętu serwerowego oraz sprzętu sieciowego
aktywnego na styku komunikacji z zewnętrzną siecią.
Testy te będą prowadzone w środowisku produkcyjnym systemu teleinformatycznego w co najmniej 2 iteracjach.
W przypadku zidentyfikowania Błędów lub Wad Wykonawca jest zobowiązany do ich poprawy przed odbiorem
Przedmiotu Zamówienia.
Dokumentacja z przeprowadzonych testów
Dokumentacja będąca podstawą przeprowadzenia testów zostanie opracowana przez Wykonawcę na etapie
analizy przedwdrożeniowej. Dokumentacja testowa będzie obejmowała następujące rodzaje dokumentów:
1. Plan testów
2. Scenariusz testowe
3. Przypadki testowe
4. Dane do testów.
Plan i scenariusze będą zgodne z powszechnie stosowanymi zasadami i praktykami.
Plan testów określać będzie w szczególności:
1. ogólne zasady przeprowadzania testów,
2. opis środowiska testowego;
3. kolejność wykonywania scenariuszy testowych;
4. klasyfikację wykrytych problemów testowych;
5. kryteria sukcesu dla poszczególnych kategorii testów.
Scenariusze będą zapewniać pokrycie wszystkich procesów systemu HIS kluczowych dla działalności
Zamawiającego. Listę kluczowych procesów zawiera Załącznik nr 1.1. Każdy scenariusz określać będzie:
dane, które muszą być wprowadzone do systemu przed uruchomieniem scenariusza;
kolejność czynności, wykonywanych w czasie testu oraz dane, wprowadzane do systemu w czasie testu;
Strona 40 z 106
oczekiwaną reakcję systemu na wykonane czynności i wprowadzone dane.
Przypadki testowe i dane testowe, w tym wszelkie materiały eksploatacyjne dostarczone będą przez Wykonawcę.
Zamawiający zobowiązany jest do współpracy z Wykonawcą przy przygotowywaniu scenariuszy testowych
i danych testowych, przeprowadzaniu testów oraz przygotowaniu wyników testów. Zamawiający zastrzega sobie
prawo zmiany scenariusza testu akceptacyjnego.
Zamawiający dopuszcza przeprowadzenie testów automatycznych, o ile w planie testów zostanie
wyspecyfikowany zakres tych testów i uzyska on akceptację Zamawiającego.
Testy będą przeprowadzone w terminie przewidzianym w harmonogramie, zgodnie z zaakceptowanym planem
testów.
Testy zostaną wykonane z użyciem środowiska testowego migracji chyba, że plan testów będzie przewidywał
inaczej, na bazie reprezentatywnej próbki danych eksploatacyjnych. Zakres testów nie może wykraczać poza
merytoryczny zakres projektu. Test może zostać przerwany, jeżeli z jakiejkolwiek przyczyny nie może być
kontynuowany (np. poważny błąd w oprogramowaniu lub awaria systemu). Test taki powinien zostać powtórzony
lub kontynuowany w innym terminie po obustronnym uzgodnieniu.
Po zakończeniu testowania każdego z obszarów, wyznaczona ze strony Zamawiającego osoba odpowiedzialna za
przebieg testowania podpisuje i przekazuje Kierownikowi Projektu ze strony Wykonawcy protokół z testów.
W ramach procesu testowania określa się następujące kategorię błędów
Poziom istotności Opis
A/Krytyczny Zatrzymanie działania Produktu lub błąd uniemożliwiający realizację
kluczowego procesu wymienionego w Załączniku nr 1.1 w tym takie
obniżenie wydajności, które w praktyce uniemożliwia jego realizację i nie
jest możliwe wskazanie obejścia błędu.
B /Wysoki Zatrzymanie działania Produktu lub realizację kluczowego procesu
wymienionego w Załączniku nr 1.1 w tym takie obniżenie wydajności, które
w praktyce uniemożliwia jego realizację, ale jest możliwe wskazanie
obejścia błędu. Obejście umożliwia weryfikację funkcjonalności
występujących „za” błędem.
C /Średni Zakłócenie pracy Produktu wpływające na weryfikację poprawności
przebiegu kluczowego procesu.
D/Niski Zakłócenie pracy Produktu niewpływające na poprawności przebiegu
kluczowego procesu, w tym błędy kosmetyczne interfejsu.
Kryteria Akceptacji Testów
Kryteria akceptacji dla scenariuszy i przypadków testowych
Wynik testu dla Scenariusza Testowego uznaje się za pozytywny, gdy wyniki testów dla wszystkich Przypadków
Testowych zawartych w Scenariuszu Testowym są pozytywne. Wynik testu dla Scenariusza Testowego uznaje
się za negatywny, gdy wynik testu dla któregokolwiek Przypadku Testowego zawartego w Scenariuszu testowym
jest negatywny.
Wynik testu dla Przypadku Testowego uznaje się za pozytywny, gdy opis oczekiwanego rezultatu zamieszczony
w polu „Oczekiwany wynik" jest ‘zgodny’ z faktycznie uzyskanym wynikiem po zakończeniu Przypadku
Testowego.
Wynik testu dla Przypadku Testowego uznaje się za negatywny, gdy opis oczekiwanego rezultatu zamieszczony
w polu „Oczekiwany wynik" jest ‘nie zgodny’ z faktycznie uzyskanym wynikiem po zakończeniu Przypadku
Testowego. W przypadku, gdy występująca niezgodność jest wynikiem błędnie opisanego Przypadku Testowego,
wówczas wynik testu może być uznany za prawidłowy, a błędny opis Przypadku Testowego musi zostać
Strona 41 z 106
poprawiony przez Wykonawcę. Sytuacja taka musi znaleźć odzwierciedlenie w raporcie z Testów
Akceptacyjnych.
Kryteria zakończenia testów sukcesem
Testy są wykonane na podstawie Scenariuszy Testowych zaakceptowanych przez Zamawiającego.
Testy uznaje się za zakończone z sukcesem, gdy:
przeprowadzono testy z wykorzystaniem 100% zaplanowanych Scenariuszy Testowych,
brak niezakończonych Scenariuszy Testowych z powodu wystąpienia Incydentu/ów z klasą istotności:
B/Wysoki, C/Średni i D/Niski, których liczba wykracza poza dopuszczalny limit określony w tabeli
poniżej
na moment zakończenia Testów Akceptacyjnych brak jest Incydentów z klasą istotności A/Krytyczny.
W przypadku wystąpienia Incydentu, który uniemożliwia wykonanie wszystkich zaplanowanych przypadków
Testowych i/lub Scenariuszy Testowych, a który nie wynika z winy Wykonawcy, wówczas zakres testów może
zostać zmieniony (wyłączenie przypadków i/lub scenariuszy) na podstawie decyzji podjętej przez Zamawiającego.
W przypadku Scenariuszy Testowych zakończonych negatywnie, w których wystąpiły Incydenty o klasie
istotności: B/Wysoki, C/Średni lub D/Niski, wynik ich zakończenia może zostać uznany za pozytywny na
podstawie decyzji podjętej przez Kierownika Projektu ze strony Zamawiającego.
Testy uznaje się za zakończone z wynikiem negatywnym, gdy po ich zrealizowaniu otrzymano następujące
wyniki:
istnieje przynajmniej jeden niezakończony Scenariusz Testowy z powodu wystąpienia Incydentu/ów
z klasą istotności A/Krytyczny,
istnieją niezakończone Scenariusze Testowe z powodu wystąpienia Incydentu/ów z klasą istotności:
B/Wysoki i C/Średni, których liczba wykracza poza dopuszczalny limit określony w tabeli poniżej,
w takim przypadku Scenariusze te nie mogą zostać uznane za zakończone pozytywnie.
W przypadku zakończenia Testów z wynikiem negatywnym, zostanie ustalony plan powtórzenia testów. Wybór
scenariuszy do II tury testów zostanie przeprowadzony według następujących zasad:
Scenariusze Testowe, które otrzymały wynik negatywny z powodu wystąpienie Incydentu/ów.
Scenariusze Testowe dla funkcjonalności powiązanych z funkcjonalnością Scenariusza Testowego,
w którym wystąpiły Incydenty.
Zamawiający zastrzega sobie prawo przeprowadzenia jednej iteracji testów regresji dla scenariuszy z wynikiem
pozytywnym.
Kryteria akceptacji testów funkcjonalnych
Dopuszczalna liczba otwartych Incydentów na zakończenie Testów Funkcjonalnych migracji
Kategoria błędu Dopuszczalna liczba przypadków testowych
z błędem
A/Krytyczny 0
B/Wysoki 2
C/Średni 5
D/Niski 10
Strona 42 z 106
Po migracji średni czas reakcji systemu będzie krótszy niż 0,7 sekundy.
Generowane z nowej wersji systemu pliki wymiany (pliki XML, dokumenty HL7, widoki na bazie danych)
posiadają identyczną strukturę i zawartość dla takiego samego zakresu danych jak w dotychczas używanym
systemie HIS, co zostanie również uwzględnione opisie raportu z testów.
Zamawiający zastrzega sobie prawo wykonania dodatkowych testów akceptacyjnych przez niezależny podmiot
trzeci w celu weryfikacji poprawności przeprowadzonych testów przez Wykonawcę. Koszty przeprowadzenia
testów ponosi Zamawiający. W wypadku uzyskania negatywnych wyników testów Wykonawca zobowiązany jest
do usunięcia wskazanych w testach nieprawidłowości i ponownego przekazania do akceptacji Zamawiającemu
przedmiotu testów. Zamawiający ma prawo do ponownej weryfikacji wyników testów, ale w wypadku ponownego
stwierdzenia nieprawidłowości koszty związane z wykonaniem testów ponosi Wykonawca.
Przed odbiorem końcowym Wykonawca jest zobowiązany do usunięcia wszystkich zgłoszonych przez
Zamawiającego wad, w tym wynikających z luk bezpieczeństwa, w wyniku przeprowadzonego przez
Zamawiającego lub zleconego stronie trzeciej testu bezpieczeństwa
I.9.9 Specyficzna procedura odbioru części związanej z migracją danych
W ramach części związanej z migracją baz danych dostarczany produkt typu System (system po migracji).
Odbiór produktu typu migracja systemu
Proces odbioru produktu migracja systemu będzie przebiegał następująco:
1. Wykonawca po przeprowadzaniu procesu migracji testowej systemu na wydajniejszą bazę danych
przedstawia raport z migracji wg szablonu uzgodnionego na etapie analizy przedwdrożeniowej oraz
zgłasza gotowość systemu do testów funkcjonalnych. Raport z migracji musi dokumentować poprawność
przeprowadzenia procesu migracji testowej w szczególności kompletność przeniesionych danych.
2. Testy funkcjonalne wykonywane są na podstawie dokumentacji testowej zatwierdzonej na etapie analizy
przedwdrożeniowej z zastrzeżeniem, że dokumentacja ta będzie uwzględniała pełny przebieg
kluczowych dla Zamawiającego procesów biznesowych. Jako pełny przebieg rozumie się testowanie
zarówno ścieżek pozytywnych jak i negatywnych dla procesów.
3. Testy funkcjonalne wykonywane są na dokumentacji testowej opracowanej w ramach analizy
przedwdrożeniowej.
4. Za realizację testów odpowiada Wykonawca przy współudziale Zamawiającego. Zamawiający zastrzega
sobie prawo samodzielnej realizacji testów przy lub bez obecności Wykonawcy. W przypadku realizacji
testów bez obecności wykonawcy, Zamawiający zobowiązuje się do opisu wykrytych błędów w sposób
umożliwiający odtworzenie błędu Wykonawcy (opis powtarzalnej ścieżki dojścia do błędu wraz
z zestawem danych testowych). Informacje takie będę przekazane w dokumencie będącym protokołem
z sesji odbytych testów systemu przez Zamawiającego.
5. Jeżeli w procesie testowania uwidocznione zostały błędy uniemożliwiające odbiór systemu w ramach
raportu z testów są one uwidaczniane w tym raporcie wraz z ustaleniem terminu przeprowadzanie II tury
testów. Kryteria odbiorowe dla poszczególnych rodzajów testów określone są w rozdziale „Testy”.
6. Wykonawca w uzgodnionym terminie przedstawia system do II tury testów. W ramach II tury testów
weryfikowane są scenariusze, dla których stwierdzono występowanie błędów w ramach I tury.
Zamawiający zastrzega sobie prawo wykonania testów regresji dla scenariuszy testowych które
przebiegły poprawnie w II turze.
7. Każda tura testów kończy się raportem z testów.
8. W przypadku spełniania warunków odbioru testów funkcjonalnych migracji systemu Zamawiający
i Wykonawca podpisują protokół odbioru testów funkcjonalnych migracji.
9. W przypadku pozytywnej weryfikacji raportu z migracji i testów funkcjonalnych migracji Zamawiający
podejmuje decyzję o realizacji migracji produkcyjnej.
10. Po przeprowadzaniu uruchomienia produkcyjnego systemu po migracji w terminie nie wcześniej niż 5
dni po, Wykonawca przedstawi raport z migracji produkcyjnej systemu wg szablonu uzgodnionego na
etapie analizy przedwdrożeniowej. Raport będzie zawierał raporty z wydajności systemu sprzed i po
migracji systemu. Raporty te powinny umożliwiać porównanie:
a. Czasu zapisu do bazy danych systemu dla tych samych lub porównywalnych danych
Strona 43 z 106
b. Czasu odpowiedzi bazy danych na zapytania systemu dla tych samych lub porównywalnych
zapytań
c. Czasu wykonania raportów, które w systemie przed migracją trwały bardzo długo np. raportów
sumarycznych o liczbie wykonanych procedur medycznych w długim okresie czasu.
11. Na podstawie raportu z migracji produkcyjnej systemu Zamawiający dokona odbioru migracji systemu
poprzez podpisanie protokołu odbioru.
12. Zamawiający zastrzega sobie prawo odmowy podpisania protokołu odbioru, jeżeli w dniu odbioru będzie
występował błąd blokujący lub 5 awarii systemu zgłoszonych przez Zamawiającego po dacie startu
produkcyjnego systemu po migracji w okresie 2 tygodni. Przy czym wystąpienie błędu związane będzie
z procesem migracji i błąd nie będzie odtwarzalny na obecnej (przed migracją) u zamawiającego instalacji
systemu HIS.
13. Odbiór migracji systemu zostanie potwierdzony protokołem odbioru podpisanym przez obie strony.
Zamawiający zastrzega sobie prawo odbioru warunkowego migracji systemu, w którym stwierdzono wady, ale
nie są one na tyle istotne by wstrzymywać przebieg prac projektowych. W takim przypadku w protokole odbioru
migracji zawierane są klauzule wskazujące listę wad do usunięcia wraz ze wskazaniem terminu dostarczenia
produktu bez wad.
I.10 Integracja systemu
Wykonawca zobowiązany jest do połączenia swojego systemu z wszystkimi systemami funkcjonującymi
u zamawiającego, wymienionymi w tabeli I.9.3
Warunki organizacyjne przeprowadzenia integracji:
1. Zamawiający oświadcza, iż zgodnie z wiążącą go umową licencyjną z twórcami posiadanych systemów
informatycznych, nie jest w posiadaniu kodów źródłowych modułów tych systemów.
2. Uzyskanie opisów interfejsów lub innych sposobów wymiany danych do integracji z wymienionymi w SIWZ
systemami oraz określenie wykonawcy lub wykonawców tych integracji jest obowiązkiem Wykonawcy.
3. Ustalenie kosztów integracji z systemami posiadanymi przez Zamawiającego jest obowiązkiem Wykonawcy.
4. Koszty integracji są częścią ceny, składanej przez Wykonawcę. Wykonawca zobowiązany jest uwzględnić
w ofercie pełny koszt wykonania integracji uwzględniający również, o ile będzie to konieczne, wykonanie
modyfikacji interfejsów wymiany danych posiadanych systemów oraz zakup niezbędnych do integracji
licencji.
5. Zamawiający dopuszcza na podstawie art.75 ust.2 pkt 3 ustawy o prawie autorskim i prawach pokrewnych
(tj. Dz.U. z 2019 r. poz. 1231) - konieczność dokonania przez Wykonawcę dekompilacji modułów systemów,
dotychczas wykorzystywanych przez Zamawiającego, poprzez zwielokrotnienie kodu lub tłumaczenie jego
formy w rozumieniu art.74 ust.4 pkt 1 i 2 ustawy (tj. Dz.U. z 2019 r. poz. 1231), jeżeli będzie to niezbędne
do uzyskania informacji koniecznych do osiągnięcia współdziałania modułów tych systemów z ZSI
dostarczonym w ramach realizacji zamówienia. Wykonawca będzie zobowiązany wykonać czynności
dekompilacyjne na własny koszt i ryzyko, w pełnym koniecznym zakresie z zastrzeżeniem, że czynności te
będą odnosiły się tylko do tych części modułów tych systemów, które będą niezbędne do osiągnięcia
współdziałania tych modułów z ZSI dostarczonymi przez Wykonawcę, a uzyskane informacje nie będą:
5.1. wykorzystane do innych celów niż osiągnięcie współdziałania niezależnie stworzonego programu
komputerowego;
5.2. przekazane innym osobom, chyba że jest to niezbędne do osiągnięcia współdziałania niezależnie
stworzonego programu komputerowego;
5.3. wykorzystane do rozwijania, wytwarzania lub wprowadzania do obrotu programu komputerowego
o istotnie podobnej formie wyrażenia lub do innych czynności naruszających prawa autorskie.
6. Informacje uzyskane przez Wykonawcę w toku wykonania czynności, o których mowa w art.75 ust.2 pkt 3
ustawy o prawie autorskim i prawach pokrewnych (tj. Dz.U. z 2019 r. poz. 1231) stanowią tajemnicę
przedsiębiorstwa Zamawiającego, w rozumieniu Ustawy o zwalczaniu nieuczciwej konkurencji z dnia
16 kwietnia 1993 r. (t.j. Dz. U. z 2019 r. poz. 1010) i podlegają ochronie w niej przewidzianej.
7. W przypadku braku możliwości integracji z systemami ERP, RIS/PACS i LIS lub jeżeli taka integracja była
by niekorzystna z punktu widzenia finansowego dla Zamawiającego, Wykonawca ma prawo do wymiany
ww. systemów, oraz przeniesienia danych w zakresie umożliwiającym normalne funkcjonowanie tych
systemów tylko i wyłącznie za zgodą Zamawiającego. W takim wypadku Wykonawca musi uwzględnić to
w analizie przedwdrożeniowej. Przełączenie systemów na nowe, musi nastąpić od nowego roku
rozliczeniowego, po zmigrowaniu niezbędnych danych służących do rozpoczęcia nowego okresu
rozliczeniowego. Wymagane jest wówczas przeprowadzić instruktaż dla pracowników i administratorów
Zamawiającego z obsługi i administracji nowymi systemami.
Strona 44 z 106
8. Wypadku wymiany systemów, o których mowa w pkt 7 Wykonawca zapewni gwarancję na każdy z system,
który ulegnie wymianie na warunkach analogicznych jak dla SSI.
Zamawiający informuje, że oczekuje możliwości integracji w projektowanym systemie w zakresie danych
wymaganych i opisanych na stronach Centrum Systemów Informacyjnych Ochrony Zdrowia w ramach integracji
z systemami P1, P2 oraz P4: https://www.csioz.gov.pl/edm/
I.11 Instruktaże Personelu Zamawiającego
Wykonawca jest zobowiązany do przeprowadzenia instruktażu wszystkich użytkowników systemu HIS w pełnym
zakresie obsługi i administracji, które wynikły w procesie migracji ze zmian interfejsu użytkownika lub
administratora. Lista zmian powstałych w trakcie odtworzenia funkcjonalności starego systemu w nowym
środowisku infrastruktury baz danych zostanie ujęta w dokumentacji projektowej przekazanej przez Wykonawcę
na etapie usług przygotowawczych.
Podczas instruktażu użytkowników musi zostać przekazana niezbędna wiedza w zakresie poprawnego
użytkowania wdrażanych systemów w obrębie poszczególnych modułów w zakresie funkcjonowania,
obsługi, administrowania i utrzymania systemów.
Zakres instruktaży musi obejmować praktyczną obsługę wszystkich funkcjonalności systemów.
Instruktaże muszą być prowadzone przez wykwalifikowanych specjalistów Wykonawcy, posiadających
niezbędną wiedzę fachową w zakresie tematyki instruktaży.
Instruktaże będą musiały być przeprowadzane w siedzibie Zamawiającego, na dokumentach i danych
Zamawiającego. Instruktarz musi być przeprowadzony na sprzęcie komputerowym Wykonawcy. Wykonawca powinien zapewnić 11 komputerów na każdą grupę: 10 komputerów dla uczestników, 1
komputer dla prowadzącego.
Wykonawca zapewni realizację instruktaży użytkowników w wymiarze określonej poniższą tabelą.
Wykonawca zapewni minimum 240h instruktaży z zakresu baz danych i infrastruktury baz danych dla
max 5 administratorów systemu. Instruktaże muszą zostać wykonane w siedzibie lub autoryzowanym
centrum treningowym producenta baz danych.
Wykonawca pokryje wszelkie koszty związane z przeprowadzeniem instruktaży.
Instruktaże dla użytkowników i instruktorów muszą odbywać się w grupach nie większych niż 10 osób.
Instruktaże dla administratorów i help desk muszą odbywać się w grupach nie większych niż 3 osoby.
Instruktaże dla Działu Rozliczeń Świadczeń Zdrowotnych muszą odbywać się w grupach nie większych
niż 5 osób.
Każda z osób biorących udział w instruktażu musi mieć dostęp do stacji roboczej.
Jednorazowe instruktaże dla użytkowników nie mogą trwać dłużej niż 2 godziny.
Jednorazowe instruktaże dla Administratorów, Instruktorów, help-desk, Działu Rozliczeń Świadczeń
Zdrowotnych nie mogą trwać dłużej niż 6 godzin.
Wykonawca zapewni stały dostęp do bazy treningowej zawierającej pełną funkcjonalność systemu
produkcyjnego. Dostęp do bazy treningowej w żaden sposób nie może zaburzać pracy systemu
produkcyjnego (np. pod względem wydajności). Zamawiający zapewni dostęp do internetu.
Poniższa tabela prezentuje ilość osobogodzin niezbędnych instruktaży stanowiskowych w przypadku wymiany
systemu i modułów wymienionych w Załączniku nr 1.1 do OPZ: Łączna liczba instruktaży w przypadku wymiany
interfejsu dla poszczególnych grup pracowniczych:
Personel Liczba
osób
Obsługa funkcjonalności
dedykowanych dla danego
stanowiska wraz z
prowadzeniem
dokumentacji medycznej
Kodowanie
świadczeń
zdrowotnych /
Kodowanie usług
Instruktaże
dedykowane
Liczba osobogodzin dla każdego użytkownika
Lekarze (w tym rezydenci i na
kontraktach) 580 6 4
Pielęgniarki 813 6 2
Sekretarki Ambulatorium 82 12 12
Rejestracje 23 12
Ruch Chorych 12 12
Technicy Pracowni Diagnostycznych 83 6 2
Administratorzy 9 60
Strona 45 z 106
Help-desk 9 60
Dział Rozliczeń Świadczeń
Zdrowotnych 15 60
Instruktorzy 20 60
Rejestracja Telefoniczna (Poznań) 10 12
Pozostali użytkownicy 400 6
Harmonogramy instruktaży muszą umożliwiać informatykom Zamawiającego obecność na zajęciach z danego
tematu przeznaczonych dla innych grup zawodowych, z zastrzeżeniem, że na jednych zajęciach z danego tematu
może być obecna co najwyżej połowa informatyków. tj. nie mniej niż 4 osoby.
I.12 Infrastruktura Sprzętowa – Wymagania ogólne
W ramach postępowania wymagane jest wykonanie następujących usług:
1) Instalacja fizyczna dostarczonego sprzętu:
a) Przygotowanie planu instalacji:
Zestawienie dostarczanych urządzeń
Propozycja rozmieszczenia elementów w istniejących szafach rackowych
b) Instalacja, montaż i uruchomienie macierzy dyskowych:
Montaż macierzy w szafie rackowej
Podłączenie macierzy do sieci LAN i/lub SAN
Inicjalna uruchomienie macierzy wraz z kontrolerami
2) Konfiguracja macierzy dyskowych:
a) Przygotowanie planu rozbudowy:
Zestawienie stosowanej nomenklatury
Zestawienie serwerów, które będą korzystać z wystawianych zasobów
Weryfikacja poziomów mikrokodów
Zestawienie wymaganych wersji oprogramowania/łat systemowych po stronie serwerów
Przygotowanie szczegółowej koncepcji konfiguracji dysków macierzy odzwierciedlającej potrzeby
biznesowe
Zestawienie zakupionego oprogramowania
b) Implementacja zgodna z projektem:
Instalacja sprzętowa
Aktywacja zakupionego oprogramowania
Konfiguracja replikacji synchronicznej
Implementacja zaakceptowanej konfiguracji logicznej macierzy
c) Przygotowanie dokumentacji powdrożeniowej:
Zestawienie stosowanej nomenklatury
Zestawienie serwerów korzystających z wystawianych zasobów
Zestawienie poziomów mikrokodów
Zestawienie wymaganych wersji oprogramowania/łat systemowych po stronie serwerów
Zestawienie konfiguracji dysków macierzy
Zestawienie mapowania udostępnionych zasobów
Zestawienie zakupionego i aktywowanego oprogramowania
Definicje testów odbiorczych.
3) Wymagania dodatkowe:
a) Wraz z dostawą urządzeń wchodzących w skład infrastruktury sprzętowej, Wykonawca dostarczy
oświadczenia producentów tych urządzeń zawierające następujące informacje:
P/N dostarczonych urządzeń
numery seryjne dostarczonych urządzeń
informację jaka firma jest producentem dostarczanych urządzeń.
Strona 46 z 106
Rozdział II. Wymagania szczegółowe
II.1 Oprogramowanie SSI – Wymagania szczegółowe
Zamawiający określił wymagania posegregowane wg grup funkcjonalnych (modułów) odnoszących się do HIS
i e-Usług
II.1.1 HIS
W przypadku wymiany systemu opis modułów znajduje się w Załączniku nr 1.1 do OPZ.
II.1.2 e-Usługi
II.1.2.1 Ogólne wymagania techniczne
E-USŁUGI
L.p. OGÓLNE WYMAGANIA
1. e-Usługi dostępne w ramach systemu to zestaw funkcji, które umożliwiają interakcję z użytkownikiem
(szczególnie pacjentem i lekarzem) metodą zdalną, między innymi za pośrednictwem Internetu, w tym niektóre
mogą być zabezpieczone dodatkowymi kanałami szyfrowanej komunikacji jak VPN i/lub HTTPS. Moduły są
ściśle zintegrowane z częścią białą systemu, tj. HIS/RIS/PACS/WEB/LIS Moduły te mają korzystać z tego
samego zbioru danych co część biała.
2. Moduły e-Usług dla pacjentów (tj. e-Usługi e-Portalu Pacjenta, część dynamiczna portalu) opublikowane w
Internecie mają korzystać z tej samej bazy danych (w rozumieniu zbioru danych i modelu danych (SZBD)) co
moduły systemu medycznego HIS i RIS, ale nie mogą łączyć się bezpośrednio do tej bazy, a jedynie poprzez
dodatkowy zabezpieczony interfejs komunikacji (np. WebServices) w celu podniesienia bezpieczeństwa bazy
danych osobowych i wrażliwych danych medycznych przetwarzanych w systemie HIS/RIS/PACS/LIS.
3. Z racji na podniesienie bezpieczeństwa przetwarzanych danych medycznych w publicznej sieci Internet, nie
akceptowalna jest realizacja wymagań udostępniania pacjentom danych medycznych za pomocą dodatkowej,
pośredniej bazy danych bezpośrednio dostępnej z poziomu aplikacji publikowanych w Internecie, do której
byłyby kopiowane, a następnie przetwarzane dane osobowe i medyczne, co mogłoby znacząco obniżyć poziom
bezpieczeństwa tych danych.
4. e-Usługi dostępne w Internecie dla pacjentów do komunikacji z częścią systemu w intranecie placówki (system
HIS/RIS/PACS) mają wykorzystywać zabezpieczony kanał komunikacji (podniesienie bezpieczeństwa
Systemu).
5. Wszystkie e-Usługi związane są bezpośrednią komunikacją z pozostałymi modułami systemu medycznego
(w szczególności związane z ruchem chorych, dokumentacją medyczną) oraz są zarządzane spójnie przez jeden
moduł administracyjny dla całego systemu medycznego przynajmniej w zakresie ruchu chorych, zarządzania
lekami, dokumentacją medyczną opisową i obrazową, zleceniami medycznymi, grafikami dostępności.
E-PORTAL PACJENTA
1. E-usługi dedykowane dla pacjentów, do których pacjent ma dostęp z dowolnego miejsca za pośrednictw
Internetu mają być udostępniane za pośrednictwem dedykowanego E-portalu pacjenta.
2. E-Portal Pacjenta korzysta z tej samej bazy danych (w rozumieniu zbioru danych i modelu danych (SZBD)) co
system medyczny w Intranecie. Nie może jednak łączyć się bezpośrednio do tej bazy (podniesienie
bezpieczeństwa systemu), tylko za pomocą zabezpieczonego interfejsu, np. WebServices.
3. System prowadzi dziennik aktywności użytkowników w e-Portalu Pacjenta. Dziennik umożliwia przegląd co
najmniej akcji: anulowania wizyty przez Pacjenta; blokady konta przez Pacjenta; edycji danych konta Pacjenta;
logowania do e-Portalu Pacjenta; nieudanego logowania do e-Portalu Pacjenta; rejestracji wizyty w e-Portalu
Pacjenta; wylogowania z e-Portalu Pacjenta; założenia konta Pacjenta.
4. System umożliwia założenie konta w e-Portalu Pacjenta poprzez udostępniony na stronie głównej formularz
rejestracyjny.
5. Formularz rejestracyjny zawiera dane, które jednoznacznie identyfikują nowego użytkownika. Nowy
użytkownik musi obligatoryjnie uzupełnić co najmniej: imię, nazwisko, datę urodzenia, / PESEL (dla pacjentów
posiadających Polskie obywatelstwo), nr dokumentu tożsamości, numer telefonu oraz adres e-mail.
Wymaganie opcjonalne - dodatkowo punktowane
6. System weryfikuje dane wprowadzone przez nowego użytkownika pod kątem zawartości i zgodności w systemie
medycznym.
Strona 47 z 106
7. System umożliwia założenia konta w e-Portalu Pacjenta dla opiekuna pacjenta.
8. System umożliwia konfigurację, w której konto użytkownika e-Portalu Pacjenta będzie zakładane automatycznie
po uzupełnieniu danych lub wymagana będzie weryfikacja danych przez użytkownika systemu medycznego.
9. System umożliwia upoważnionym użytkownikom systemu medycznego dostęp do listy złożonych wniosków
o założenie konta w e-Portalu Pacjenta. Upoważniony użytkownik może zaakceptować lub odrzucić wniosek.
10. System umożliwia wygenerowanie unikalnego identyfikatora dla nowego użytkownika e-Portalu Pacjenta -
przez użytkownika systemu medycznego. Tak założone konto zostaje automatycznie powiązane z numerem
Pacjenta w systemie medycznym.
11. System umożliwia założenie nowego konta w e-Portalu Pacjenta za pomocą autoryzacji profilem zaufanym
ePUAP.
12. System umożliwia dostęp do funkcji e-Portalu Pacjenta po wprowadzeniu unikalnego identyfikatora w systemie
(tzw. loginu) oraz hasła.
13. E-Portal Pacjenta umożliwia zmianę hasła oraz nazwy użytkownika.
14. System umożliwia nadanie automatycznych uprawnień dostępu do korzystaniu z e-Portalu w imieniu danego
pacjenta dla innego użytkownika e-Portalu, który jest wskazany w systemie ruchu chorych i wykazie pacjentów
systemu medycznego jako osoba upoważniona lub opiekun tego pacjenta.
15. Użytkownik modułu ma możliwość udostępnienia swoich danych medycznych takich jak: wyniki badań, historie
choroby, obrazy diagnostyczne osobom trzecim w trybie tylko do odczytu.
16. W przypadku braku danych kontaktowych (e-mail, telefon), system informuje o tym tuż po zalogowaniu do e-
Portalu Pacjenta.
17. System umożliwia pacjentowi przesłanie wiadomości dotyczącej działania serwisu; sugestii modyfikacji serwisu
lub opinii na temat poziomu świadczonych usług.
18. System prezentuje listę jednostek organizacyjnych wraz z danymi teleadresowymi, godzinami przyjęć,
informacjami dodatkowymi i lokalizacją na mapie.
19. System prezentuje listę kolejek oczekujących wraz z przybliżonym czasem oczekiwania na przyjęcie,
wyliczonym na podstawie danych z poprzedniego miesiąca.
20. Użytkownik ma możliwość zmiany języka dla e-Portalu Pacjenta. Dostępne są co najmniej: język polski, język
angielski, język rosyjski. Możliwość dodania kolejnych języków za pomocą pliku z tłumaczeniem.
21. E-Portal Pacjenta spełnia wymagania dostępności serwisu www dla osób zagrożonych wykluczeniem cyfrowym.
Wymagany poziom zgodności ze standardem WCAG 2.0 na poziomie co najmniej AA.
22. E-Portal Pacjenta musi oferować funkcjonalności zmiany wielkości czcionki za pomocą linku widocznego na
stronie głównej portalu. Niedopuszczalne jest przyjęcie zmiany wielkości czcionki za pomocą powiększenia
zawartości okna przeglądarki internetowej.
23. E-Portal Pacjenta musi oferować funkcjonalność zmiany kontrastu za pomocą ikony widocznej na stronie
głównej portalu.
24. Co najmniej dla funkcjonalności e-Rejestracji - e-Portal Pacjenta musi współpracować z czytnikami transkrypcji
mowy umożliwiając osobie niedowidzącej skorzystanie z e-Usługi i przejście procesu rejestracji na wizytę.
25. Moduł e-Portal Pacjenta zaprojektowany jest w technice RWD (Responsive Web Design).
ADMINISTRACJA FUNKCJAMI E-PORTAL PACJENTA
1. Wspólny moduł administracyjny dla e-Portalu Pacjenta oraz systemu HIS umożliwia administrację funkcjami e-
Portal Pacjenta oraz wspólnymi słownikami.
2. Minimalny zakres funkcjonalności administracyjnych to:
a) w nagłówku portalu może zostać umieszczone logo jednostki medycznej.
b) moduł administracyjny umożliwia administratorowi na definiowanie przynajmniej następujących parametrów
e-usług e-Portalu Pacjenta:
- umożliwia konfigurację szablonu wiadomości, jakie system będzie automatycznie wysyłał do pacjentów:
przypomnienia o wizycie, przypomnienie o potwierdzeniu wizyty, anulowanie niepotwierdzonej wizyty.
- umożliwia wskazanie E-mail: adres serwera i parametry SMTP (serwer poczty wychodzącej).
3. Czas generowania wiadomości: w momencie wykonania akcji w Systemie
Strona 48 z 106
4. Aplikacja umożliwia zawężenie listy poradni, w których pacjent może zarezerwować wizytę on-line. Listę
wybranych poradni definiuje się w module administracyjnym. Nieustawienie tej opcji skutkuje tym, że pacjent
ma możliwość rezerwacji wizyty w dowolnej poradni szpitala, o ile istnieją na niej grafiki lekarzy.
5. Aplikacja umożliwia oznaczenie lekarza, jako „niewidocznego z poziomu e-Rejestracji”. W tym celu będzie
można wybrać lekarza ze słownika i ewentualnie kolejną osobę, tworząc listę
6. Maksymalna liczba otwartych rezerwacji - Określa maksymalną liczbę otwartych rezerwacji na pacjenta.
7. Możliwość rezerwacji pacjentów pierwszorazowych - W przypadku włączenia opcji pacjent będzie mógł
zarezerwować wizytę w dowolnej poradni.
8. Potwierdzanie wizyty - Opcja pozwala na zdefiniowanie czasu przeznaczonego na potwierdzenie wizyty przez
pacjenta - (np. pomiędzy 10 do 3 dni przed wizytą), a w tym:
• Początek okresu potwierdzenia- liczba dni przed wizytą. Wtedy wysyłany jest komunikat z prośbą o
potwierdzenie wizyty.
• Liczba dni na potwierdzenie wizyty: Dzień przed końcem okresu potwierdzania wysyłana jest kolejna
wiadomość o konieczności potwierdzenia wizyty. Jeśli wizyta nie zostanie potwierdzona w określonym czasie,
system anuluje ją automatycznie.
9. Przypomnienie o wizycie - Opcja określa na ile dni przed wizytą ma zostać wysłane pacjentowi przypomnienie
o wizycie.
10. Procentowa pula wizyt dla e-rejestracji - Opcja umożliwia zdefiniowanie procentowej puli rezerwacji wizyt na
dany dzień, na danego lekarza w danym gabinecie. Za każdym razem, gdy pacjent wyszukuje wizytę,
sprawdzane ma być czy danego dnia, dla danej poradni i lekarza przekroczony został procentowo podany limit
wizyt przewidzianych dla rezerwacji internetowych. Przykładowo jeśli dla parametru 20% mechanizm grafików
wspólny dla systemu HIS i e-Rejestracji obliczy, że danego dnia jest zarezerwowanych internetowo 21% wizyt,
to na ekranie wyszukiwania w e-Rejestracji, pacjent nie będzie mógł zarezerwować wizyty danego dnia przez
Internet.
11. Maksymalna ilość prób logowania - Po wprowadzeniu liczby prób, włączone zostanie ograniczenie na liczbę
nieudanych prób logowania. Po wykorzystaniu wszystkich prób, dostęp do konta zostanie zablokowany na czas
określony w opcji „Czas blokady konta”.
12. Czas blokady konta - Opcja pozwala na określenie czasu (w minutach), na jaki konto pacjenta zostanie
zablokowane, po tym jak wykorzysta limit nieudanych prób logowania.
13. Adres internetowy do powiadomień - Opcja określa widziany adres e-mail w powiadomieniach wysyłanych
pacjentowi.
14. Liczba minimalnych dni przed rezerwacją wizyty - Opcja określa liczbę dni przed terminem wizyty, kiedy
pacjent nie może zarezerwować wizyty. Np.
- Wartość 0 oznacza, że pacjent może zarezerwować wizytę w dniu, kiedy ów wizyta ma się odbyć.
- Wartość 1 oznacza, że pacjent wizytę na dzień np. 3 maja może zarezerwować najpóźniej w dniu 2 maja.
- Wartość 2 oznacza, że pacjent wizytę na dzień np. 3 maja może zarezerwować najpóźniej w dniu 1 maja, itd.
15. Położenie poradni w Google Maps - Opcja określająca czy będzie możliwość podejrzenia położenia jednostek
organizacyjnych w Google Maps.
16. Ilość nieobecności, po której następuje blokada użytkownika - Opcja określa maksymalną liczbę kolejnych
nieobecności pacjenta na wizytach, po których blokowana jest możliwość rezerwacji
17. Limit e-rezerwacji na poradnię - Opcja określa maksymalną ilość oczekujących rezerwacji pacjenta na poradnię.
Pacjent nie może zarezerwować na daną poradnię więcej niż X terminów. Brak ustawienia skutkuje brakiem
limitów.
18. Mail do opiekuna e-Rejestracji - Adres e-mail do administratora systemu po stronie szpitala, odpowiedzialnego
za kontakt mailowy z pacjentami
19. Dostępność (dni) wyników badań - Opcja określa okres (w dniach), przez jaki wyniki badania będą dostępne do
podglądu przez pacjenta poprzez e-Portal Pacjenta. Po dokonaniu pierwszego wydruku badania obowiązuje czas
określony w opcji „Dostępność (dni) wyników badań po dokonaniu pierwszego wydruku wyników przez
pacjenta”.
20. Dostępność (dni) wyników badań po dokonaniu pierwszego wydruku wyników przez pacjenta - Opcja określa
okres (w dniach), przez jaki wyniki badania będą dostępne do podglądu przez pacjenta poprzez e-Portal Pacjenta,
po dokonaniu pierwszego wydruku wyników
21. Rezerwacje kolejkowe - Opcja określa czy użytkownik będzie miał możliwość przeglądania swoich danych
odnośnie rezerwacji kolejkowych (np. przyczyny przesunięcia wizyty).
22. Login rzecznika praw pacjenta/pełnomocnika ds. praw pacjenta i komunikacji społecznej
E-mail rzecznika praw pacjenta
E-mail do pytań od pacjentów
Login osoby odpowiedzialnej za odpowiedzi na pytania pacjentów
Strona 49 z 106
23. informacje marketingowe – włączanie lub wyłączanie funkcji wysyłki informacji marketingowych do
użytkowników e-Portalu pacjenta
BEZPIECZEŃSTWO I KONFIGURACJA E-PORTALU PACJENTA
1. Serwer WWW powinien być udostępniony (chroniony) za dodatkowym serwerem proxy.
2. e-Portal Pacjenta będzie wyposażony w certyfikat SSL. Będzie posiadał odpowiednią nazwę domenową.
3. Kluczowym elementem w infrastrukturze obsługującej e-Portal Pacjenta jest certyfikat SSL. Umieszczony jest
on na serwerze dostępowym do aplikacji. Zapewnia on bezpieczną, zaszyfrowaną komunikację przez sieć
między stacją kliencką a serwerem.
Infrastruktura klucza publicznego przewiduje, iż certyfikat taki jest wystawiany przez zaufany urząd
certyfikacji (CA). Zamawiający zapewni Wykonawcy do instalacji wymagany certyfikat.
4. Drugim ważnym aspektem jest odpowiednia nazwa domenowa. Jest ona umieszczona w certyfikacie (pole
Common Name) i tylko zgodność tej nazwy z adresem wpisywanym w przeglądarce nie spowoduje komunikatu
ostrzegającego w przeglądarce. Nazwa domenowa portalu - *pib-nio.pl
5. Dostarczony certyfikat będzie pochodził od uzgodnionych z Wykonawcą dostawców, minimum: GeoTrust (min.
QuickSSL Premium) lub Thawte (min. SSL 123) Będzie posiadał okres ważności certyfikatu minimum 5 lata
6. Pole certyfikatu Common Name będzie taka sama jak nazwa subdomeny np. e-rejestracja.pib-nio.pl
7. Zamawiający utworzy adres poczty elektronicznej (e-mail) do powiadomień przekazywanych z usługi
e-Rejestracja.
8. Zamawiający przeznaczy minimalne łącze internetowe z co najmniej jednym, statycznym adresem publicznym
o przepustowości co najmniej 2Mbps dla e-Portalu pacjenta.
9. e-Portal pacjenta będzie zainstalowany na dedykowanej do tego celu maszynie, na który przeznaczone zostanie
przynajmniej 1GB pamięci, 40GB przestrzeni dyskowej, 2 rdzenie CPU
II.1.2.2 e-Rejestracja
Usługa umożliwi wybór i zarezerwowanie terminu wizyty w poradni metodą zdalną za pośrednictwem Internetu
(na podstawie elektronicznego grafiku zintegrowanego z systemem szpitalnym) oraz udostępni informacje on-line
o kolejkach oczekujących wraz z przybliżonym czasem oczekiwania na przyjęcie. System umożliwi Pacjentowi
wyszukanie wolnych terminów wizyt wg kryteriów: lekarza, poradni lub usługi medycznej, daty wizyty oraz czasu
jej trwania (od do). Po wybraniu jednego z głównych kryteriów (lekarza, poradni lub usługi medycznej) lista
wyboru dla pozostałych kryteriów zawęzi się (np. po wybraniu konkretnej poradni w polu lekarz będziemy mieli
do wyboru jedynie lekarzy z tej tylko poradni). Po wprowadzeniu kryteriów zdefiniowanych przez Pacjenta
wyświetla listę wszystkich wolnych wizyt spełniających kryteria. Dodatkowo, w ramach usługi będzie istniała
interaktywna mapa dla pacjentów prezentująca lokalizację miejsca wykonania usług. Cały proces rejestracji
i potwierdzenia rejestracji będzie odbywał się elektronicznie. E-Rejestracja utworzona zdalnie przez Pacjenta
zostanie natychmiast zapisana w centralnej bazie danych systemu. Należy dodatkowo podkreślić, że proces
rejestracji zostanie wsparty systemem e-Powiadomień indywidualnych dla Pacjentów (SMS/email/e-Portal) –
poziom dojrzałości usługi 5. Moduł automatycznych powiadomień pacjenta o zbliżających się terminach wizyt
oraz innych zdarzeń medycznych (np. termin badania, ale także informacje związane z profilaktyką) będzie
powiadamiał Pacjenta o terminie wizyt lub badań za pomocą 3 kanałów komunikacji: SMS, e-mail, wiadomości
systemowe e-Portalu pacjenta dostępne po zalogowaniu do portalu. Proces elektronicznej rejestracji nie będzie
wymagał żadnych dodatkowych kontaktów ani potwierdzeń ze strony Pacjenta czy Szpitala. Cały proces będzie
odbywał się automatycznie przez przeglądarkę internetową.
Usługa musi być zintegrowana z systemem informatycznym Narodowego Instytutu Onkologii im. Marii
Skłodowskiej-Curie – Państwowego Instytutu Badawczego. Informacja o dokonanej rezerwacji trafi do systemu
informatycznego, gdzie wizyty z e-Rejestracji będzie można odróżnić od pozostałych. Dodatkowo
w ramach e-rejestracji uruchomiona zostanie usługa eMapa, gdzie pacjent otrzyma dokładną informację
o lokalizacji wykonywania danej porady (w przypadku Narodowego Instytutu Onkologii im. Marii Skłodowskiej-
Curie – Państwowego Instytutu Badawczego będą to dwie lokalizacje – ul. W.K. Roentgena i Wawelska,
w przypadku Partnerów – lokalizacje konkretnych Przychodni). W ramach usługi e-Rejestracja uruchomiona
zostanie także usługa e- Kolejka, która będzie udostępniała informację o statusie pacjenta w kolejce oczekujących.
Informacja będzie dotyczyła zarówno statusu kolejek w Poradniach (w przypadku Partnerów) jak i w Szpitalu
(w przypadku pacjentów Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego
Instytutu Badawczego). Dostęp do usługi będzie możliwy z komputerów, urządzeń mobilnych (tabletów,
telefonów) oraz z dedykowanych infokiosków, które zlokalizowane zostaną w wybranych punktach Narodowego
Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego oraz u Partnerów.
Strona 50 z 106
Lokalizacje Partnerów projektu:
1. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Cegłowie – Przychodnia Opieki Zdrowotnej plac Anny
Jagiellonki 17
2. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Kałuszynie–Przychodnia Opieki Zdrowotnej ul. Wojska
Polskiego 24
3. Filie Samodzielnego Publicznego Zakładu Opieki Zdrowotnej w Sokołowie Podlaskim ul. Księdza Bosco 5
W przypadku filii Samodzielnego Publicznego Zakładu Opieki Zdrowotnej w Sokołowie - Parter na etapie
dostawy wskaże 2 miejsca dostarczenia 2 szt. infokiosków.
Zamawiający dopuszcza możliwość przeprowadzenia wizji lokalnej u Partnerów projektu w celu określenia
zakresu niezbędnych do wykonania prac związanych z miejscem instalacji infokiosków.
Osobami wskazanymi do kontaktu po stronie Parterów projektu są:
1. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Cegłowie - Informatyka – Radosław Krążała
tel. 503 829 183, mail: [email protected]
2. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Kałuszynie - Informatyka – Tomasz Woźniak
tel. 608 204 681, mail: [email protected]
3. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Sokołowie – Informatyka Andrzej Odrobiński, tel. 25 7817328, mail: [email protected]
Model kluczowych kroków procesu:
1. Pacjent loguje się do e-Portalu.
2. Pacjent wybiera jedną z opcji: rezerwację wizyty, poradnie on-line (w celu sprawdzenia lokalizacji na
mapie) lub rezerwacje kolejkowe.
3. Po wybraniu rezerwacji wizyty:
a. Pacjent wprowadza kryteria wyszukiwania dostępnych terminów wizyt i uruchamia
wyszukiwanie.
b. Pacjent wybiera dogodny dla siebie termin i rezerwuje wizytę.
c. Pacjent załącza skierowanie i uzupełnia dane kontaktowe (telefon, email).
d. Opcjonalnie:
i. Pacjent uruchamia wydruk potwierdzenia rezerwacji wizyty.
ii. Pacjent sprawdza na mapie lokalizację poradni.
iii. Pacjent potwierdza rezerwację wizyty.
4. Po wybraniu opcji „poradnie on-line”:
a. Pacjent wyszukuje i wybiera poradnię
b. System wyświetla dane kontaktowe poradni oraz jej lokalizację na mapie.
5. Po wybraniu opcji „Rezerwacje kolejkowe”:
a. System pobiera z bazy danych informacje o wpisach pacjenta na listy oczekujących.
b. System wyświetla informacje o znalezionych wpisach na listach oczekujących.
Strona 51 z 106
Mapa procesu:
Rysunek - Mapa procesu – e-rejestracja
Źródło: Opracowanie własne
Cel: usprawnienie procesu rejestracji poprzez udostępnienie e-usługi on-line 24 godziny na dobę 7 dni w tygodniu
dla Pacjentów chcących zarejestrować się na wizytę, sprawdzić swój status w kolejce itp. Dostęp dla pacjenta
będzie realizowany zgodnie z potrzebami za pośrednictwem urządzeń mobilnych, wraz z systemem powiadomień
elektronicznych.
E-REJESTRACJA
L.p. Moduł umożliwia rezerwację wizyt przez Pacjenta metodą zdalną, za pośrednictwem internetu.
1. Moduł umożliwia pacjentowi uzupełnienie danych skierowania lub załączenie skanu/zdjęcia skierowania
podczas rezerwacji wizyty. Uzupełnione dane lub załączony skan/zdjęcie skierowania widoczne są
w systemie HIS na ekranie rejestracji wizyty.
2. Moduł jest zintegrowany z system HIS, w tym modułem grafików i kolejek oczekujących. Informacja
o dokonanej rezerwacji trafia do systemu HIS, gdzie wizyty z e-Rejestracji można odróżnić od pozostałych.
Jednocześnie moduł korzysta z definicji tych samych grafików co system HIS.
3. Rejestracja przez Internet ma taki sam charakter i status jak rejestracja dokonana bezpośrednio w placówce
medycznej.
4. Moduł umożliwia Pacjentowi wyszukanie wolnych terminów wizyt co najmniej wg kryteriów: lekarz,
poradnia, usługa medyczna, data wizyty oraz czasu jej trwania (od do). Do wyszukania najbliższego wolnego
terminu, niezbędne jest podanie co najmniej nazwy usługi medycznej.
5. Po wybraniu jednego z kryteriów (lekarza, poradni lub usługi medycznej) lista wyboru dla pozostałych
kryteriów zawęża się.
6. Moduł po wprowadzeniu kryteriów wyświetla listę wszystkich wolnych terminów spełniających kryteria.
7. Moduł prezentuje Pacjentowi możliwych płatników za wizytę, wynikających z jego uprawnień (np. NFZ,
Komercja, Abonament). Pacjent ma możliwość wyboru płatnika.
Wymaganie opcjonalne - dodatkowo punktowane
8. Po wybraniu terminu z listy moduł udostępnia ekran, na którym pacjent ostatecznie potwierdza wszystkie
dane.
9. Moduł umożliwia udostępnienie w e-Rejestracji tylko wybranych poradni.
10. Moduł umożliwia ograniczenie liczby jednocześnie wprowadzanych przez pacjenta rezerwacji.
11. Moduł umożliwia zablokowanie możliwości rejestracji on-line dla pacjenta pierwszorazowego w danej
poradni.
12. Możliwość określenia procentowej puli grafika do wykorzystania przez e-Rejestrację.
13. Wszyscy pacjenci mogą korzystać z tej samej puli dostępnych terminów z uwzględnieniem definiowanego
przez administratora procentowego podziału puli grafika na rejestracje przez internet oraz tradycyjne.
Strona 52 z 106
14. Moduł umożliwia zablokowanie możliwości elektronicznej rejestracji wizyt w przypadku nie zjawienia się
przez pacjenta na określonej liczbie potwierdzonych wizyt. Ilość wizyt może zostać skonfigurowana przez
administratora.
15. Moduł umożliwia wskazanie lokalizacji poradni i prezentację jej na mapie. Możliwość wskazania przez
administratora współrzędnych poradni.
16. Moduł ma korzystać z tej samej bazy danych (w rozumieniu zbioru danych i modelu danych SZBD)) co
system ruchu chorych, ale nie może łączyć się bezpośrednio do tej bazy (podniesienie bezpieczeństwa
systemu).
17. Moduł do komunikacji z systemem i bazą danych w intranecie placówki ma wykorzystywać zabezpieczony
kanał komunikacji (podniesienie bezpieczeństwa systemu).
18. Wspólny moduł administracyjny z systemem poradni / szpitala.
19. Możliwość śledzenia statusu pacjenta na kolejce oczekujących zdefiniowanej w oddziale, poradni, pracowni.
20. Dla pacjentów przewlekle chorych system umożliwia przesłanie „zamówienia” na wystawienie recepty na
lek związany z terapią choroby przewlekłej w ramach rezerwacji wizyty recepturowej.
II.1.2.3 e-Dokumentacja
Dzięki wprowadzeniu elektronicznej dokumentacji medycznej oraz integracji e-Portalu z Elektronicznym
Rekordem Medycznym Pacjenta systemu szpitalnego, e-usługa umożliwi dostęp (odbiór) dokumentacji medycznej
przez pacjenta tj. wyników badań, obrazów, itp. metodą zdalną za pośrednictwem Internetu. Wyniki badań
udostępniane online pacjentom będą dotyczyć zarówno elementów dokumentacji jak i wyników obrazowych
z systemu PACS, który będzie zintegrowany z systemem Zarządzania Elektroniczną Dokumentacją Medyczną.
Pacjent korzystając z funkcjonalności e-Portalu może się zalogować, wybrać na podstawie różnych kryteriów
(jednostka wykonująca, nazwa badania, status) interesujące go wyniki odczytać, pobrać lub wydrukować. Należy
dodatkowo podkreślić, że proces zostanie wsparty systemem powiadomień indywidualnych dla Pacjentów
(SMS/email) o dostępności wyników do odbioru – usługa o poziomie dojrzałości 5.
Model kluczowych kroków procesu:
1. W pracowni szpitala zostaje wykonane badanie. System zarządzania dokumentacją medyczną generuje
informację dla e-Portalu o dostępnym wyniku badania.
2. E-Portal wysyła dostępnymi kanałami powiadomienie dla pacjenta o możliwości pobrania wyniku
badania; informacja może być przekazana bezpośrednio w e-Portalu, za pośrednictwem maila lub SMS.
3. Pacjent loguje się do portalu.
4. Pacjent wyszukuje badanie, którego wynik został udostępniony.
5. Pacjent uruchamia drukowanie wyniku lub pobranie go w postaci pliku.
6. E-Portal pobiera dane wyniku z bazy danych systemu i zależnie od wyboru użytkownika: generuje
wydruk lub startuje pobieranie pliku z wynikiem.
7. Pacjent kończy pracę z systemem.
Mapa procesu:
Rysunek - Mapa procesu – Odbiór e-wyników wraz z dostępem do elektronicznej dokumentacji Pacjenta
Źródło: Opracowanie własne
Strona 53 z 106
Cel: usprawnienie procesu odbioru wyników i dostępu do wyników badań poprzez udostępnienie e-usługi on-line
24 godziny na dobę 7 dni w tygodniu dla Pacjentów, wraz z systemem powiadomień elektronicznych
L.p. E-WYNIKI
1. Aplikacja umożliwia przeglądanie wyników badań i obrazów diagnostycznych w formacie DICOM/JPG
przez pacjenta metodą zdalną za pośrednictwem internetu.
Wymaganie opcjonalne - dodatkowo punktowane
2. Pacjent korzystając z przygotowanej witryny internetowej może się zalogować, wybrać na podstawie
różnych kryteriów (jednostka wykonująca, nazwa badania, status) interesujące go wyniki odczytać, pobrać
lub wydrukować.
3. Wyniki mogą być prezentowane jako lista lub hierarchicznie z podziałem na jednostki zlecające.
4. Możliwość prezentowania wyników badań tylko i wyłącznie skonsultowanych podczas porady pacjenta.
Wymaganie opcjonalne - dodatkowo punktowane
5. Możliwość konfiguracji okresu widoczności danego wyniku na liście wyników pacjenta.
6. Pełna integracja z Elektronicznym Rekordem Medycznym Pacjenta systemu HIS, korzystanie z tego
samego źródła danych, wspólnego modułu administracyjnego oraz słowników.
7. E-DOKUMENTACJA
8. Moduł umożliwia pacjentowi przeglądanie dokumentacji medycznej zapisanej systemie HIS.
9. Moduł udostępnia dokumentację zapisaną w repozytorium dokumentacji medycznej w systemie HIS.
Wymaganie opcjonalne - dodatkowo punktowane
10. Pacjent ma możliwość przejrzenia lub w razie potrzeby wydruku dokumentacji medycznej.
11. Moduł prezentuje datę utworzenia dokumentacji medycznej.
12. Moduł umożliwia filtrowanie dokumentacji medycznej co najmniej według: nazwy dokumentacji, daty
utworzenia od, daty utworzenia do.
13. Pacjent ma możliwość załączenia zeskanowanych załączników. Lekarz po stronie systemu HIS może
zdecydować, które z załączników dołączyć do dokumentacji medycznej wizyty lub pobytu.
14. Moduł umożliwia załączanie przez pacjenta zewnętrznej dokumentacji medycznej.
15. Moduł umożliwia załączanie dokumentów formatu: .pdf, .jpg, .png, .doc, .docx.
16. Podczas załączania dokumentu, pacjent ma możliwość dodania opisu dokumentu.
17. Załączone przez pacjenta dokumenty widoczne są zakładce Moje dokumenty w module.
18. Załączone przez pacjenta dokumenty widoczne są w Rekordzie Medycznym Pacjenta w systemie HIS.
19. Pacjent ma możliwość usuwania załączonych przez siebie dokumentów.
II.1.2.4 e-Obchód
E-OBCHÓD
1 System wyposażony jest w Moduł dedykowany do pracy na urządzeniach mobilnych wyposażonych wyłącznie
w ekran dotykowy.
2 Moduł jest zrealizowany w architekturze trójwarstwowej oraz ma możliwość pracy z wykorzystaniem
przeglądarki internetowej bez konieczności instalacji dodatkowej aplikacji.
3 Moduł jest w pełni zintegrowany z systemem szpitalnym i działa na tym samym motorze bazy danych co system
szpitalny. Dane zapisane w Module są dostępne natychmiast także w systemie szpitalnym. Dane zapisane
równolegle przez innych użytkowników w systemie szpitalnym są także natychmiast dostępne w Module.
4 Moduł działa na urządzeniach typu tablet opartych na systemach operacyjnych Windows, iOS, Android.
5 Użyte w interfejsie graficznym Modułu komponenty wprowadzania danych i nawigacji dostosowane są do
pracy z wykorzystaniem ekranu dotykowego (m.in. większe przyciski, pola edycyjne, zakładki, itp.).
Wykorzystanie klawiatury ekranowej jest ograniczone do niezbędnego minimum.
6 Moduł współpracuje z Systemem Identyfikacji Pacjenta systemu HIS. W szczególności możliwe jest
zidentyfikowanie pacjenta z opaski ze znakiem identyfikacyjnym, w którą został zaopatrzony pacjent w
szpitalu.
7 Program na urządzeniu klienckim nie może trwale gromadzić przetwarzanych danych osobowych i
medycznych. Musi być możliwość poprawnej pracy rozwiązania bez konieczności korzystania z lokalnej bazy
danych na urządzeniu.
Strona 54 z 106
8 Do uruchomienia wystarczająca jest przeglądarka stron WWW (przynajmniej Chrome, Safari).
9 Identyfikacja pacjenta wg znaku identyfikacyjnego pacjenta i wyszukiwanie w systemie.
10 Możliwość podglądu danych pacjentów znajdujących się w szpitalu, na poszczególnych oddziałach w zakresie:
11 - data rozpoczęcia pobytu,
12 - historia pobytu,
13 - sala/oddział/izba przyjęć,
14 - diagnoza,
15 - lekarz prowadzący,
16 - status pobytu,
17 - zlecone badania i wyniki,
18 - zlecone leki,
19 - zdjęcia radiologiczne z PACS dla badań wraz z opisami,
20 - opisowe dane dokumentacji medycznej,
21 - podgląd graficzny karty gorączkowej.
22 Możliwość sprawdzenia wyników badań pacjenta w ramach pobytu.
23 Możliwość wprowadzania danych:
24 - składanie zleceń nowych podań leków,
25 - składanie zleceń badań,
26 - składanie zleceń badań z panelów zleceń o wspólnej konfiguracji z modułem oddział,
27 - składanie zleceń badań przez wyszukiwanie badań ze słownika,
28 - odnotowanie podań zleconych leków,
29 - odnotowanie czynności pielęgniarskich,
30 - odnotowywanie parametrów życiowych i karty gorączkowej.
31 Prezentacja podręcznych informacji lekarskich/wbudowanych zestawień danych, z których można wybrać
pacjenta i rozpocząć pracę na wybranym rekordzie z listy (co najmniej):
32 - ‘moi pacjenci’,
33 - ‘moje dokumenty w trybie szkic’,
34 - ‘moje zadania na dziś’
35 - ‘wyniki badań pacjentów’
36 Możliwość wyszukiwania pacjentów.
37 - wg struktury organizacyjnej oddziałów i sal
38 - wg wybranych danych pacjenta (przynajmniej nazwisko, identyfikator pacjenta, identyfikator Systemu
Identyfikacji Pacjenta)
39 Możliwość uruchomiania podglądu obrazów diagnostycznych w postaci referencyjnej:
- system prezentuje dane pacjenta, opis oraz miniaturkę obrazu (tzw. thumbnails) z możliwością podglądu
obrazu w jakości referencyjnej.
- w przypadku wyniku serii obrazów DICOM (np. tomografia) moduł udostępnia odrębny JPG dla każdego
obrazu serii, a następnie umożliwia jego płynne odtworzenie w jakości referencyjnej.
40 Jednolity sposób logowania do Modułu na urządzenia mobilne typu tablet oraz do dostarczanego systemu
szpitalnego - za pomocą tego samego loginu i hasła.
41 System szpitalny wraz z Modułem korzystają ze wspólnej definicji wykorzystywanych w systemie słowników
(badania, użytkownicy, uprawnienia, lekarze zlecający, lekarze opisujący, inne wykorzystywane w systemie
HIS oraz niezbędne w dostarczanym rozwiązaniu). Zmiana w jednym systemie powoduje automatyczną zmianę
pozycji słownikowej w drugim systemie.
42 System szpitalny i Moduł są zintegrowane w sposób umożliwiający ograniczenie wielokrotnego wpisywania
tych samych danych. Dane wprowadzone w systemie tabletowym są natychmiast widoczne w systemie HIS.
43 Moduł oraz system szpitalny korzystają z tego samego rejestru pacjentów.
44 Moduł oraz system szpitalny zarządzane są przez jeden moduł administracyjny.
45 Moduł prezentuje ustrukturyzowane formularze dokumentacji medycznej systemu szpitalnego korzystając z tej
samej definicji formularzy co system szpitalny i moduł administracyjny systemu szpitalnego - formularz
podzielony jest na te same atrybuty.
46 Moduł pozwala na identyfikację pacjenta na podstawie opaski z kodem identyfikującym pacjenta.
Strona 55 z 106
II.1.2.5 e-Powiadomienia
W przypadku wystąpienia konieczności zmiany terminu wizyty lub badania (ze strony szpitala np. na skutek
nieobecności lekarza) lub wskutek zmiany terminu z inicjatywy Pacjenta, proces zmiany terminu wizyty będzie
odbywać się w pełni elektronicznie. W przypadku zmiany terminu przez pacjenta, zmiana ta zostanie
wprowadzona do elektronicznej rejestracji na e-Portalu (anulowanie zarezerwowanej wizyty/badania
i przeniesienie jej na inny termin). W Przypadku konieczności zmiany terminu wizyty/badania przez szpital,
zostanie uruchomiona funkcja e-potwierdzeń. Pacjent otrzyma elektroniczne powiadomienie (SMS/e-
mail/informacja na e-Portalu po zalogowaniu) o zmianie terminu wizyty i propozycji nowego terminu.
Potwierdzenie Pacjenta będzie mogło być wprowadzone z poziomu e-Portalu jak również poprzez wysłanie
zwrotnej informacji kanałem SMS, e-mail, na otrzymany komunikat, np. SMS z odpowiedzią NIE na pytanie czy
pacjent akceptuje zmianę terminu, gdzie w przypadku braku akceptacji, system anuluję wizytę i zwolni termin dla
innych pacjentów.
Model kluczowych kroków procesu:
1. Na skutek określonego zdarzenia, np. nieobecności lekarza, personel zmienia termin wizyty pacjenta.
2. System wysyła dostępnymi kanałami (e-Portal, email, SMS) powiadomienie dla pacjenta o zmianie
terminu wizyty/badania i prosi o potwierdzenie proponowanego nowego terminu; następnie oczekuje na
odpowiedź pacjenta.
3. Pacjent wysyła zwrotną informację o potwierdzeniu lub odrzuceniu proponowanego terminu za pomocą
SMS, email lub bezpośrednio w e-Portalu (w tym przypadku wcześniej się do niego loguje).
4. System analizuje otrzymaną informację zwrotną – jeśli pacjent nie potwierdza nowego terminu
rezerwacji, system anuluje wizytę/badanie.
Mapa procesu:
Rysunek - Mapa procesu – Obsługa zmiany terminów wizyt u lekarza e-Powiadomienia
Źródło: Opracowanie własne
Cel: usprawnienie procesu zmiany terminu wizyt on-line, wraz z systemem powiadamiania i potwierdzania
elektronicznego
E-POWIADOMIENIA
1. Moduł automatycznych powiadomień pacjenta o zbliżających się terminach wizyt oraz innych zdarzeń
medycznych (np. termin badania, wizyty, informacje o badaniach profilaktycznych) za pomocą 3 kanałów
komunikacji: e-mail, wiadomości systemowe portalu pacjenta dostępne po zalogowaniu do portalu e-Usług,
opcjonalnie SMS za pomocą bramki SMS udostępnionej przez Zamawiającego.
2. Generowanie wiadomości przypominających pacjentom o wizytach i badaniach.
3. Wiadomości generowane są w pakietach.
Strona 56 z 106
4. Możliwość konfiguracji formatu treści wiadomości do wysyłki, a w tym użycie parametrów:
- imię pacjenta,
- nazwisko pacjenta,
- numer pacjenta,
- data wizyty (dd-mm-yyyy),
- dzień wizyty (dd),
- miesiąc wizyty (numer w formacie mm lub słownie),
- rok wizyty (yyyy),
- godzina wizyty (HH:mm),
- nazwa krótka usługi.
5. Możliwość definicji szablonów wiadomości niezależnych dla każdego typu usług/porad.
6. Możliwość definicji domyślnego szablonu wiadomości dla usług/porad/wizyt.
7. Obsługa formatu co najmniej CSV dla pakietu dostarczanego dostawcy bramki SMS.
8. Możliwość generowania wiadomości tylko dla pacjentów, którzy wyrazili zgodę na otrzymywanie
komunikatów SMS.
9. Wszystkie wysłane wiadomości są gromadzone w bazie danych systemu wraz z datą wygenerowania i są
powiązane z wizytą, usługą, pacjentem, wykorzystanym szablonem wiadomości.
10. Zabezpieczenie przed ponowną wysyłką tego samego komunikatu.
11. Możliwość konfiguracji godziny oraz cykli w dniach, w jakich pakiety wiadomości będą generowane do
wysyłki.
12. Moduł komunikacji SMS jest zintegrowany z rejestrem wizyt i pacjentów systemu Ruchu Chorych.
13. Możliwość konfiguracji maksymalnej długości wiadomości SMS.
14. Automatyczna weryfikacja i generowanie wiadomości tylko do pacjentów posiadających uzupełniony
w systemie numer telefonu komórkowego.
15. Pacjent może wskazać jakie kanały komunikacji preferuje w przypadku powiadomień o wizytach, badaniach,
zbliżającym się terminie przyjęcia do szpitala wg kolejki oczekujących, informacjach o badaniach
profilaktycznych.
II.1.2.6 e-Wywiad
Usługa umożliwi elektroniczne wprowadzenie przez pacjenta informacji dotyczących zdrowia jego i rodziny przed
wizytą w celu skrócenia czasu wizyty. Usługa e-Wywiadu jest szczególnie istotna w celu zebrania wszelkich
niezbędnych informacji od pacjenta i wprowadzeniu ich do Elektronicznego Rekordu Medycznego. Dane
wprowadzone na formularzach natychmiast będą dostępne w systemie medycznym; ściśle zintegrowane
z systemem informatycznym oraz formularzami Dokumentacji Medycznej. Dzięki e-usłudze Pacjent będzie miał
możliwość w dowolnym czasie, w dowolnym miejscu i za pomocą dowolnego urządzenia mobilnego mającego
dostęp do sieci Internet, do uzupełniania informacji, celem przekazania ich do lekarza specjalisty. Moduł będzie
zdalnie prowadził Pacjenta przez pytania pomocnicze, które będą pomocne w procesie wyboru sposobu leczenia.
W odpowiedzi na umieszczony przez pacjenta opis, lekarz prowadzący może dopytać pacjenta o jego dolegliwości
w odniesieniu do umieszczonego wpisu. Pacjent będzie miał możliwość dołączania zdjęć do swojego opisu.
Model kluczowych kroków procesu:
1. Pacjent loguje się do e-Portalu.
2. Pacjent wyszukuje i wybiera wizytę, do której uzupełni dane wywiadu lekarskiego.
3. Pacjent uruchamia funkcję „Wywiad lekarski” i uzupełnia informacje, o które prosi system;
wprowadzone dane stają się dostępne w systemie szpitala.
4. Pacjent kończy pracę z systemem.
5. Lekarz prowadzący weryfikuje informacje wprowadzone przez pacjenta; jeśli uzna to za stosowne, zadaje
dodatkowe pytania pacjentowi.
6. E-Portal wysyła do pacjenta powiadomienie o pytaniach zadanych przez lekarza.
7. Pacjent ponownie loguje się do e-Portalu i uzupełnia informacje w wywiadzie.
8. Pacjent kończy pracę z systemem.
Strona 57 z 106
Mapa procesu:
Rysunek - Mapa procesu – e-wywiad
Źródło: Opracowanie własne
Cel: usprawnienie procesu zbierania wywiadu od Pacjenta i zapisanie informacji od Pacjenta w Elektronicznym
Medycznym Rekordzie Pacjenta dostępnym dla pozostałych modułów systemu teleinformatycznego.
Optymalizacja obejmuje możliwość wprowadzenia danych przez pacjenta oraz przejście przez ustrukturyzowany
formularz z pytaniami celem przygotowania pacjenta do wizyty i zebrania niezbędnych informacji on-line
ważnych z punktu widzenia procesu leczenia. Raz wprowadzone dane są dostępne w zintegrowanym systemie
szpitalnym.
E-WYWIAD
1 Moduł umożliwia przekazanie przez pacjenta istotnych informacji dotyczących stanu zdrowia przed wizytą.
2 Moduł umożliwia skorzystanie ze zdefiniowanych formularzy strukturyzowanych stworzonych w module
Generator Formularzy.
3 Moduł umożliwia stworzenie różnych formularzy e-wywiadu dla poszczególnych jednostek organizacyjnych.
Formularze mogą różnić się zawartością poszczególnych pól.
Wymaganie opcjonalne - dodatkowo punktowane
4 Wprowadzony przez pacjenta e-wywiad widoczny jest w dokumentacji formularzowej w module gabinet
systemu HIS. Wymaganie opcjonalne - dodatkowo punktowane
5 Lekarz ma możliwość zapoznania się z e-wywiadem przed wizytą. System umożliwia poinformowanie lekarza
o uzupełnieniu przez pacjenta e-wywiadu. Lekarz ma możliwość zadania dodatkowego pytania pacjentowi.
Wymaganie opcjonalne - dodatkowo punktowane
II.1.2.7 e-Konsultacje
E-Usługa, której zadaniem będzie pozyskanie przez pacjenta specjalistycznej porady lekarskiej na żądany temat,
bez konieczności wychodzenia z domu, w sposób zdalny przez Internet. Usługa umożliwiać będzie konsultacje
pisemne lub video-konsultacje według ustalonego terminarza. Dzięki wprowadzeniu elektronicznego rekordu
pacjenta (elektroniczna dokumentacja medyczna) zarówno pacjent jak i lekarz będą mieli dostęp do wyników
pacjenta i historii leczenia. Moduł e-Konsultacji umożliwia zadawanie pytań / zgłaszanie uwag przez pacjentów
poprzez wewnętrzny system komunikacji. Należy dodatkowo podkreślić, że proces e-Konsultacji zostanie wsparty
systemem powiadomień indywidualnych dla Pacjentów (SMS/email) o dostępności odpowiedzi na zadane przez
Pacjenta pytanie – usługa o poziomie dojrzałości 5. Oprócz e-Konsultacji pisemnych, elektroniczna usługa
umożliwi także przeprowadzenie wideokonferencji z lekarzem w celu wykonania konsultacji medycznej on-line.
W trakcie wideo konsultacji, lekarz będzie miał dostęp do udostępnionej na portalu dokumentacji medycznej
(wyników badań, karty informacyjnej, obrazów diagnostycznych). Konsultacje on-line obrazu i dźwięku mogą
odbywać się w jakości HD oraz niższej, w zależności od podłączonej stacji nadawczej i możliwości sieci pacjenta.
Wideo konsultacje realizowane będą zdalnie i będą mogły obsługiwać do kilkunastu jednoczesnych połączeń (np.
konsultacja 4-ech lekarzy jednocześnie) i mogą być realizowane z dedykowanych terminali, telefonów, tabletów,
komputerów PC, pozwalając na udostępnienie np. obrazu z pulpitu roboczego. Usługa będzie zapewniała
bezpieczną transmisję danych zgodną z obecnie panującymi standardami i wymogami prawnymi. Usługa ta jest
Strona 58 z 106
szczególnie ważna dla osób niepełnosprawnych oraz osób przewlekle chorych, gdyż umożliwia bieżący kontakt
z personelem medycznym w sposób całkowicie zdalny, bez wychodzenia z domu.
Model kluczowych kroków procesu:
1. Pacjent loguje się do e-Portalu.
2. Pacjent wybiera typ konsultacji: pisemna lub wideokonferencja.
3. Po wybraniu konsultacji pisemnych:
a. pacjent zadaje pytanie i kończy pracę z systemem
b. lekarza analizuje pytanie i wpisuje odpowiedź
c. e-Portal wysyła powiadomienie do pacjenta o dostępnej odpowiedzi
d. pacjent ponownie loguje się do e-Portalu i czyta odpowiedź; następnie kontynuuje konsultacje
lub kończy pracę z systemem.
4. Po wybraniu wideokonferencji:
a. Pacjent wyszukuje i wybiera właściwego lekarza, który ma możliwość udzielania konsultacji
w trybie telekonferencji
b. System uruchamia komunikator i łączy z wybranym lekarzem
c. Lekarz udziela konsultacji
d. Lekarz i pacjent kończą pracę z systemem.
Mapa procesu:
Rysunek - Mapa procesu – e-konsultacje
Źródło: Opracowanie własne
Cel: usprawnienie procesu konsultacji medycznych on-line poprzez możliwość zadania pytań do lekarza on-line
lub przeprowadzenie wideo konsultacji.
E-KONSULTACJE
1. Moduł umożliwia konsultacje pisemne, gromadzone w powiązaniu z rekordem medycznym pacjenta między
lekarzem a pacjentem. Umożliwia zadawanie pytań / zgłaszanie uwag przez pacjentów poprzez wewnętrzny
system komunikacji. Wymaganie opcjonalne - dodatkowo punktowane
2. W części szpitalnej i poradni użytkownicy korzystają z wbudowanego w system modułu do komunikacji
z pacjentem.
3. Pacjent może zawęzić konsultacje do wybranej poradni i lekarza na podstawie odbytych wizyt.
4. Wiadomość wysłana z portalu przez zalogowanego pacjenta będzie dostępna w systemie HIS dla osoby
podanej w konfiguracji funkcjonalności.
5. Do wiadomości wysłanej przez pacjenta możliwa będzie generacja jednej odpowiedzi (dostępnej następnie
do podglądu przez pacjenta na portalu).
6. Pacjent zostanie poinformowany za pomocą maila o odpowiedzi na pytanie.
Strona 59 z 106
7. Pacjent będzie miał dostęp do historii konsultacji pisemnych.
8. AUDIO/WIDEO
9. Elektroniczna usługa skierowana do lekarzy, która ułatwi dostępność do specjalistów, którzy są nieobecni
w miejscu świadczenia e-Usługi. Jest to usługa elektroniczna uruchomiona on-line na skierowana do lekarzy
i współpracujących podmiotów medycznych wspomagająca proces leczenia. Wspiera proces komunikacji
z innymi placówkami oraz lekarzami za pomocą funkcjonalności udostępnionej w komunikatorze.
10. Elektroniczna usługa skierowana do pacjentów, która umożliwi przeprowadzenie wideokonferencji
z lekarzem w celu wykonania konsultacji medycznej. Za pomocą funkcjonalności udostępniania
dokumentacji medycznej przez pacjenta w trakcie wideo konsultacji, lekarz będzie miał dostęp do
udostępnionej na portalu dokumentacji medycznej (wyników badań, karty informacyjnej, obrazów
diagnostycznych).
11. Usługa zapewnia bezpieczną transmisję danych zgodną z obecnie panującymi standardami i wymogami
prawnymi.
12. Konsultacje on-line obrazu i dźwięku mogą odbywać się w jakości HD oraz niższej, w zależności od
podłączonej stacji nadawczej i możliwości sieci. Wideo konsultacje realizowane są zdalnie, mogą obsługiwać
do kilkunastu jednoczesnych połączeń (np. konsultacja 4-ech lekarzy jednocześnie) i zapewniają jakość
wideo i audio umożliwiającą prowadzenie zdalnych konsultacji, mogą być realizowane z dedykowanych
terminali, telefonów, tabletów, komputerów PC, pozwalając na udostępnienie np. obrazu z pulpitu roboczego.
II.1.2.8 e-Partner
Proces zintegrowanego leczenia pacjenta polegać będzie na wprowadzeniu elektronicznej usługi zdalnych
konsultacji medycznych pomiędzy specjalistami Wnioskodawcy a jego Partnerami, w tym placówkami
medycznymi zlokalizowanymi na terenach wiejskich w woj. mazowieckim. Celem e-usługi jest zapewnienie
pełnego, rzetelnego i zintegrowanego procesu leczenia. Dzięki zastosowaniu modułu e-Partner Partner będzie miał
do dyspozycji narzędzie udostępnione zdalnie (poprzez sieć Internet) przez Wnioskodawcę. W celu realizacji
e-usług zintegrowanego leczenia pacjenta, Partner otrzyma od Narodowego Instytutu Onkologii im. Marii
Skłodowskiej-Curie – Państwowego Instytutu Badawczego login i hasło, dzięki którym, po wejściu na
odpowiednią stronę internetową, może korzystać z funkcjonalności tworzenia i udostępniania elektronicznych
kartotek pacjentów, wystawiania e-skierowań na badania specjalistyczne, czy e-Konsultacji medycznych ze
specjalistami z Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego (wideo konsultacje i konsultacje pisemne). Wprowadzenie takiej usługi zapewni kompleksowość
i ciągłość procesu leczenia, z wglądem w elektroniczny rekord pacjenta. Wprowadzenie usługi zintegrowanego
leczenia, usprawni proces wymiany informacji pomiędzy lekarzami prowadzącymi po stronie Partnera
i Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego, co
wpłynie na jakość i szybkość leczenia Pacjenta. Dzięki modułowi e-Partner możliwe będzie zdalne konsultowanie
danego przypadku medycznego przez konsylium kilku lekarzy różnych specjalizacji ze strony Partnera jak
i Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego.
Model kluczowych kroków procesu:
Partner posiada konto w systemie e-Partner.
1. Podczas wizyty pacjenta w placówce Partnera, użytkownik loguje się do aplikacji e-Partner.
2. Następuje wyszukanie kartoteki lub utworzenie kartoteki pacjenta w systemie.
3. Wybór/zaplanowanie usług do wykonania przez Szpital.
4. Oznaczenie, czy badanie/usługa będzie wymagała Konsylium
5. Wysłanie do pacjenta potwierdzenia rezerwacji usług.
6. Pacjent stawia się w placówce Szpitalnej, w wyznaczonym terminie, na wykonanie zaplanowanych
usług.
7. Szpital wyszukuje w systemie usługi zaplanowane przez Partnera
8. Szpital wykonuje zaplanowane usługi.
9. W przypadku konieczności przeprowadzenia Konsylium, do wykonanej usługi personel szpitala oraz
personel Partnera można wymienić uwagi.
10. Partner w systemie e-Partner wyświetla wyniki i omawia je z pacjentem.
11. Partner wyświetla raport wykonanych przez Szpital usług, na zlecenie partnera. Zgodnie
z wygenerowanym raportem, Szpital rozliczy partnera za wykonane usługi.
Strona 60 z 106
Mapa procesu:
Rysunek - Mapa procesu – e- usługa zintegrowanego procesu leczenia e-Partner
Źródło: Opracowanie własne
Cel: usprawnienie i optymalizacja procesu leczenia pacjenta, poprawa wymiany informacji między partnerami,
poprawa jakości i skrócenie procesu diagnostyczno-terapeutycznego.
E-PARTNER
1 Moduł umożliwia dwustronną wymianę zleceń badań i konsultacji pomiędzy placówką i jej partnerami (np.
innymi jednostkami medycznymi). Moduł również umożliwia partnerom rezerwowanie terminów wizyt dla
pacjentów w placówce medycznej. Zlecenia badań i konsultacji oraz rezerwacje terminów wizyt odbywają się
za pośrednictwem internetu. Partnerzy korzystają ze specjalnie przygotowanej witryny internetowej.
2 Moduł e-Partner posiada wspólny moduł administracyjny z systemem medycznym.
3 System prowadzi dziennik logowań do modułu.
4 Moduł korzysta z tej samej bazy danych (w rozumieniu zbioru danych i modelu danych (SZBD)) co system
medyczny w intranecie, ale nie może łączyć się bezpośrednio do tej bazy (podniesienie bezpieczeństwa
systemu).
5 Do komunikacji z systemem medycznym w intranecie placówki, moduł wykorzystuje zabezpieczony kanał
komunikacji (podniesienie bezpieczeństwa systemu).
6 Moduł umożliwia określenie zakresu usług możliwych do rezerwacji i zlecania przez danego partnera.
7 Moduł umożliwia partnerom rezerwacje terminów wizyt, zlecanie badań i konsultacji zarówno dla pacjentów
przypisanych do danego partnera jak również dla innych pacjentów zapisanych w bazie systemu medycznego.
8 Moduł umożliwia prowadzenie wideokonferencji w celu umożliwienia kontaktu lekarza z ośrodka Partnera z
personelem Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego
9 W przypadku wyszukiwania wśród pacjentów przypisanych do danego partnera, istnieje możliwość
wyszukiwania co najmniej według następujących kryteriów: pesel (dla pacjentów posiadających polskie
obywatelstwo) /data urodzenia, nr dokumentu tożsamości, imię, nazwisko, miasto, ulica, kod pocztowy.
10 W przypadku wyszukiwania wśród wszystkich pacjentów zapisanych w systemie medycznym - partner musi
wprowadzić poprawne: pesel (dla pacjentów posiadających Polskie obywatelstwo) /datę urodzenia, imię,
nazwisko. Wyszukanie pacjenta możliwe jest dopiero po wprowadzeniu poprawnie łącznie tych trzech danych
pacjenta.
11 Partner ma możliwość dodania nowego pacjenta do bazy systemu medycznego wprowadzając co najmniej:
imię, nazwisko, pesel, płeć, datę urodzenia. Możliwe jest również wprowadzenie: telefonu, adresu e-mail oraz
pełnego adresu.
12 Moduł umożliwia partnerom rezerwacje terminów wizyt dla swoich pacjentów.
13 Partner ma możliwość wyszukiwania wolnych terminów dla wizyt co najmniej według: nazwy usługi, typu
wizyty, lekarza, specjalności, jednostki organizacyjnej, daty i godziny.
Strona 61 z 106
14 Moduł e-Partner korzysta z tej samej definicji grafików przychodni co system medyczny oraz moduł
e-Rejestracja, dzięki czemu prezentowane są w nim tylko wolne terminy wizyt.
Wymaganie opcjonalne - dodatkowo punktowane
15 Podczas rezerwacji wizyty, partner ma możliwość uzupełnienia danych skierowania co najmniej w zakresie:
rodzaju skierowania, daty skierowania, lekarza kierującego, jednostki kierującej, rozpoznania. W celu
usprawnienia wprowadzania danych skierowania, moduł powinien automatycznie podpowiadać datę
skierowania jako bieżącą, lekarza kierującego jako zalogowanego użytkownika oraz jednostkę kierującą jako
jednostkę, w której zatrudniony jest zalogowany użytkownik.
16 Moduł umożliwia wydruk potwierdzenia rezerwacji wizyty.
17 Moduł umożliwia przegląd zaplanowanych wizyt dla pacjentów partnera wraz z informacją o statusie wizyty.
18 Moduł umożliwia partnerom zlecenie badań i konsultacji, które zostają przesłane do systemu medycznego.
19 Podczas zlecenia badania lub konsultacji, partner ma możliwość wskazania co najmniej: nazwy usługi,
priorytetu zlecenia, preferowanej daty wykonania, jednostki wykonującej, lekarza kierującego.
20 Moduł umożliwia załączenie do zlecenia, obrazów w formie plików DICOM i przesłanie ich do konsultacji
w systemie medycznym.
21 Zlecone przez partnera badanie lub konsultacja trafia do systemu medycznego, gdzie może zostać wykonana.
Po wykonaniu w systemie medycznym, wynik badania lub konsultacji wraca na listę zleceń wychodzących
w module e-Partner, gdzie możliwy jest przegląd wyniku.
22 Lista zleceń wychodzących w module e-Partner prezentuje co najmniej: datę zlecenia, nr zlecenia, nazwę
usługi, priorytet, datę wykonania, status, pacjenta, pesel (dla pacjentów posiadających polskie obywatelstwo),
datę urodzenia.
23 Partner ma możliwość wyszukiwania zleceń na liście zleceń wychodzących co najmniej według: daty zlecenia
od, daty zlecenia do, pacjenta (nazwisko, imię, pesel), statusu zlecenia, priorytetu, nazwy badania, nr zlecenia.
24 Moduł umożliwia partnerom przyjmowanie zleceń badań i konsultacji wychodzących z systemu medycznego.
25 Użytkownik po stronie systemu medycznego, do zlecania badań lub konsultacji partnerom używa tego samego
modułu zleceń, za pomocą którego zlecane są badania wewnątrz placówki.
26 Użytkownik zlecający badanie w systemie medycznym ma możliwość zadecydowania czy badanie lub
konsultacja powinna być wykonana przez partnera. Użytkownik ma możliwość wyboru konkretnego partnera,
do którego zlecenie zostanie przesłane.
27 Użytkownik zlecający badanie lub konsultacje w systemie medycznym ma możliwość załączenia poprzednich
wyników badań pacjenta do tworzonego zlecenia. Mogą to być również badania posiadające obrazy w formie
plików DICOM. Wymaganie opcjonalne - dodatkowo punktowane
28 Użytkownik zlecający badanie lub konsultacje w systemie medycznym ma możliwość zanonimizowania
danych pacjenta. W takiej sytuacji w module e-Partner nie będą widoczne: imię, nazwisko i pesel pacjenta.
Wymaganie opcjonalne - dodatkowo punktowane
29 Zlecenie badanie lub konsultacji przekazywane jest do moduł e-Partner, gdzie pojawia się na liście zleceń
przychodzących.
30 Moduł e-Partner weryfikuje uprawnienia użytkownika. Zalogowany użytkownik widzi na liście zleceń
przychodzących tylko zlecenia kierowane do partnera, gdzie jest zatrudniony.
Wymaganie opcjonalne - dodatkowo punktowane
31 Lista zleceń przychodzących w module e-Partner prezentuje co najmniej: datę zlecenia, nr zlecenia, nazwę
usługi, priorytet, datę wykonania, status, imię i nazwisko pacjenta, pesel, datę urodzenia.
32 Partner ma możliwość wyszukiwania zleceń na liście zleceń przychodzących co najmniej według: daty
zlecenia od, daty zlecenia do, statusu zlecenia, priorytetu, nazwy badania, nr zlecenia, danych pacjenta.
33 Partner ma możliwość podejrzenia danych zlecenia - a więc informacji uzupełnionych podczas zlecania
badania w systemie medycznym placówki.
34 Partner ma możliwość podglądu załączonych do zlecenia plików DICOM, za pomocą przeglądarki
diagnostycznej dostępnej z poziomu modułu e-Partner. Wymaganie opcjonalne - dodatkowo punktowane
35 Partner ma możliwość wprowadzenia wyniku badania lub konsultacji, który zostaje przesłany do systemu
medycznego. Wynik wprowadzony przez partnera, jest prezentowany w systemie medyczny w taki sam
sposób jak wyniki pochodzące z systemów wewnętrznych placówki.
II.1.2.9 e-Informator
E-informator (Infokiosk) jest to usługa udostępnienia wybranych e-Usług w wybranych lokalizacjach –
tj. w jednostkach Partnerskich i w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie –
Państwowym Instytucie Badawczym. Infokioski będą urządzeniami, które:
- udostępnią e-usługi typu e-rejestracja (zarówno do Poradni Partnerów jak i do Narodowego Instytutu
Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego),
Strona 62 z 106
- będą posiadały zainstalowaną wirtualną mapę Narodowego Instytutu Onkologii im. Marii Skłodowskiej-
Curie – Państwowego Instytutu Badawczego (dot. dużych Infokiosków 55” zlokalizowanych
w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie
Badawczym, która pozwoli za pomocą ekranu dotykowego na zlokalizowanie konkretnego miejsca
(gabinetu, pracowni, kliniku, punktu pobrań krwi itp.) w Narodowym Instytucie Onkologii im. Marii
Skłodowskiej-Curie – Państwowym Instytucie Badawczym,
- poprzez zintegrowanie z systemem informatycznym Narodowego Instytutu Onkologii im. Marii
Skłodowskiej-Curie – Państwowego Instytutu Badawczego pozwolą na potwierdzenie przybycia do
poradni Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego poprzez zeskanowanie kodu kreskowego na „Karcie Pacjenta”. Będzie miało to znaczenie
w przypadku pacjentów, którzy dokonają rezerwacji wizyty w usłudze e- rejestracja – dzięki temu lekarz
w gabinecie dostanie informację, że pacjent, który ma zarezerwowaną wizytę poprzez e-Rejestrację jest
już na terenie Poradni i oczekuje na wizytę.
W ramach Projektu planowane jest dostarczenie infokiosków wewnętrznych na terenie Poradni oraz dwóch
dużych infokiosków zewnętrznych pełniących rolę informacyjną.
Dla potrzeb obsługi procesu rejestracji pacjentów dostarczone infokioski zostaną zintegrowane z systemem HIS,
Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego,
połączone z systemem kolejowym i dzięki wbudowanym skanerom będą umożliwiały potwierdzenie przybycia
do Poradni poprzez zeskanowanie kodu z Karty Pacjenta,
E-INFORMATOR
1 Infokiosk może być obsługiwany za pomocą ekranu dotykowego (klawiatura ekranowa)
2 Integracja z modułem Poradnia w zakresie niezbędnym do realizacji funkcji kiosku.
3 Prezentacja danych dotyczących pacjenta:
4 - Sprawdzenie terminów najbliższych wizyt;
5 - Przegląd i wydruk listy wizyt pacjenta
6 - Przegląd listy rezerwacji na usługę
7 - Przegląd danych związanych z poszczególnymi wizytami;
8 Dostęp do dokumentów mogących interesować pacjenta (karta praw pacjenta, sposób przygotowania się do
badań).
9 Informacje związane z jednostką (kontaktowe numery telefonów, adresy, grafik pracy lekarzy)
10 Portal umożliwia wskazanie lokalizacji poradni, np.: Zumi, Google i prezentacji lokalizacji poradni
pacjentowi.
11 Możliwość podłączenia strony internetowej przygotowanej przez klienta.
12 Interakcja pacjenta z systemem obsługującym poradnię:
13 - Rezerwacja wizyty (wyznaczenie terminu przyszłej wizyty);
14 Możliwość pracy jako system informacyjny – bez integracji z systemem informatycznym poradni.
15 Możliwość śledzenia statusu pacjenta na kolejce oczekujących zdefiniowanej w oddziale, poradni, pracowni
16 Możliwość zamieszczenia informacji dodatkowych. np. o dotacji z projektu UE
17 Przeglądanie informacji handlowych o: planowanych badaniach, oferowanych badaniach i zabiegach
medycznych
SYSTEM KOLEJKOWY - OBSŁUGA KOLEJKI PACJENTÓW
1 Moduł umożliwia generowanie numerów do obsługi kolejki i pobranie numeru z infokiosku przez pacjenta.
2 Integracja modułu z systemem HIS w zakresie weryfikacji danych pacjenta umówionego na wizytę, terminu
wizyty, weryfikacji czy umówiona wizyta posiada uzupełnione skierowanie oraz weryfikacji uprawnień
pacjenta (czy pacjent posiada uzupełnione aktualne ubezpieczenie).
3 Moduł umożliwia potwierdzenie wizyty w umówionym dniu przez aktywację usługi na infokiosku.
Potwierdzenie może nastąpić po wpisaniu numeru PESEL, numeru ID pacjenta w systemie HIS lub numeru
telefonu pacjenta uzupełnionego w systemie HIS. Wymaganie opcjonalne - dodatkowo punktowane
4 Drukarka infokiosku powinna wydrukować numer identyfikacyjny dla zarejestrowanej wizyty oraz
dodatkowe informacje na papierze (imię i nazwisko lekarza, nazwa poradni, numer gabinetu).
5 Moduł umożliwia potwierdzenie wizyty pacjenta przez personel przychodni bezpośrednio z systemu HIS.
Wprowadzenie pacjenta do kolejki po weryfikacji lub uzupełnieniu brakujących danych w systemie HIS (dane
skierowania, informacje o ubezpieczeniu). Personel przychodni może wygenerować numer identyfikacyjny
dla wizyty. Numer identyfikacyjny wizyty może być umieszczony na wydruku generowanym w systemu HIS.
Wymaganie opcjonalne - dodatkowo punktowane
Strona 63 z 106
6 System powinien powiadamiać o kolejce pacjentów oczekujących, na monitorach w poczekalni lub innych
wskazanych miejscach instalacji monitorów objętych systemem kolejkowym. Prezentacja listy numerów
oczekujących. Prezentacja numerów aktualnie przebywających w poszczególnych gabinetach.
7 Możliwość wyświetlania kolejki pacjentów oczekujących na wyświetlaczach zbiorczych w poczekalni
(zgodnie z przepisami – ukrywając dane osobowe, np. numer generowany z infokiosku).
MODUŁ OBSŁUGI KOLEJKI - INFOKIOSK
1 Moduł umożliwia generowanie numerów do obsługi kolejki i pobranie numeru z infokiosku przez pacjenta.
2 Moduł umożliwia weryfikację zapisanych w systemie medycznym danych pacjenta umówionego na wizytę:
terminu wizyty; weryfikacji czy umówiona wizyta posiada uzupełnione skierowanie oraz weryfikacji
uprawnień pacjenta (czy pacjent posiada uzupełnione aktualne ubezpieczenie).
3
Moduł umożliwia potwierdzenie wizyty w umówionym dniu poprzez aktywację usługi na infokiosku.
Potwierdzenie może nastąpić po wpisaniu danych pacjenta uzupełnionych w systemie medycznym: numeru
PESEL, kodu z karty Pacjenta Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego, numeru ID lub numeru telefonu pacjenta.
4 Moduł umożliwia pacjentowi pobranie numeru do punktu rejestracji wizyt (numer nie powiązany z danymi
pacjenta).
5 Drukarka infokiosku powinna wydrukować numer identyfikacyjny dla zarejestrowanej wizyty oraz
dodatkowe informacje na papierze (imię i nazwisko lekarza, numer gabinetu).
6
Moduł umożliwia potwierdzenie wizyty pacjenta przez personel przychodni bezpośrednio w module
rejestracji wizyt. Wprowadzenie pacjenta do kolejki po weryfikacji lub uzupełnieniu brakujących danych w
systemie medycznym (dane skierowania, informacje o ubezpieczeniu). Personel przychodni może
wygenerować numer identyfikacyjny dla wizyty. Numer identyfikacyjny wizyty może być umieszczony na
wydruku generowanym z systemu medycznego.
7 Możliwość wyświetlania kolejki pacjentów oczekujących na wyświetlaczach zbiorczych w poczekalni
(zgodnie z przepisami – ukrywając dane osobowe, np. numer generowany z infokiosku).
MODUŁ OBSŁUGI KOLEJEK - ADMINISTRACJA
1 Uwierzytelnienie i autoryzacja dostępu do modułu.
2 Zarządzanie użytkownikami modułu wspólne z zarządzaniem użytkownikami systemu medycznego.
3 Możliwość konfiguracji kolejek - przypisanie kodu, opisu i jednostki organizacyjnej w systemie medycznym
(dodawanie, usuwanie).
4 Możliwość definiowania kolejek związanych z punktem rejestracji wizyt.
5
Możliwość konfiguracji widoku danych na monitorach LCD - wybór kolejek wyświetlanych na
poszczególnych monitorach, możliwość konfiguracji widoku kolejki (układ tabelaryczny / pojedyncza
kolejka).
6 Interfejs systemu w języku polskim
7 Moduł obsługi kolejek działa w oparciu o architekturę klient – serwer i jest uruchamiany automatycznie
podczas włączania serwera.
MODUŁ OBSŁUGI KOLEJKI - PRZYWOŁANIE PACJENTA DO GABINETU LEKARSKIEGO
1 Moduł dostępny jest dla użytkowników w module gabinetowym.
2 Moduł umożliwia użytkownikowi wybór zdefiniowanej wcześniej kolejki, z którą będzie pracował.
3 Moduł umożliwia przywołanie do gabinetu lekarskiego pacjenta, który potwierdził swoje przybycie na wizytę
w infokiosku lub rejestracji.
4 Użytkownik moduł gabinetowego ma dostęp do listy pacjentów, którzy potwierdzili przybycie na wizytę.
5 Przywołanie pacjenta do gabinetu lekarskiego - automatycznie otwiera ekran wizyty pacjenta w module
gabinetowym. Wymaganie opcjonalne - dodatkowo punktowane
6 Przywołanie pacjenta do gabinetu lekarskiego przez użytkownika w gabinecie powoduje wyświetlenie
informacji na monitorze w poczekalni. Wymaganie opcjonalne - dodatkowo punktowane
7 Moduł prezentuje liczbę osób aktualnie oczekujących na wizytę.
8 Moduł prezentuje użytkownikowi systemu medycznego imię i nazwisko osoby aktualnie wezwanej do
gabinetu.
9 Moduł umożliwia ponowne przywołanie pacjenta do gabinetu.
10 Moduł umożliwia ponowne wstawienie pacjenta do kolejki przez użytkownika.
Wymaganie opcjonalne - dodatkowo punktowane
11 Moduł umożliwia dodanie pacjenta do kolejki przez użytkownika modułu w rejestracji.
Strona 64 z 106
12 Moduł w dowolnym momencie umożliwia użytkownikowi modułu gabinetowego przywołanie pacjenta poza
kolejnością.
13 Moduł umożliwia generowanie komunikatów dźwiękowych na wskazanych monitorach w poczekalni w
momencie kiedy kolejny pacjent jest przywoływany do gabinetu.
14 Moduł umożliwia wprowadzenie przez użytkownika w gabinecie informacji o rozpoczęciu /zakończeniu
przerw - informacja o przerwie prezentowana jest na monitorach w poczekalni.
15
Moduł powiadamiać o kolejce pacjentów oczekujących, na monitorach w poczekalni lub innych wskazanych
miejscach instalacji monitorów objętych systemem kolejkowym. Prezentacja listy numerów oczekujących.
Prezentacja numerów aktualnie przebywających w poszczególnych gabinetach.
MODUŁ OBSŁUGI KOLEJKI - PRZYWOŁANIE PACJENTA DO REJESTRACJI
1 Moduł dostępny jest dla użytkownika w module rejestracji wizyt pacjentów.
2 Moduł umożliwia użytkownikowi wybór zdefiniowanej wcześniej kolejki, z którą będzie pracował.
3 Moduł umożliwia przywołanie pacjenta do rejestracji.
4
Moduł umożliwia połączenie numeru pobranego przez pacjenta w infokiosku z zarejestrowaną wizytą - tak aby
nie było konieczności nadawania kolejnego numeru dla pacjenta.
Wymaganie opcjonalne - dodatkowo punktowane
5 Przywołanie pacjenta do punktu rejestracji wizyt powoduje wyświetlenie informacji na monitorze w
poczekalni.
6 Moduł umożliwia ponowne przywołanie pacjenta do punktu rejestracji.
OBSŁUGA POTWIERDZEŃ
1 Integracja Systemu z systemem szpitalnym HIS w zakresie pobrania danych pacjenta umówionego na wizytę.
2
Potwierdzenie wizyty w umówionym terminie przez aktywację usługi na Infokiosku. Potwierdzenie może
nastąpić po wpisaniu numeru PESEL lub zeskanowaniu kodu kreskowego z dokumentu potwierdzenia
rejestracji lub karty pacjenta Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego
Instytutu Badawczego. W przypadku konieczności uzupełnienia dokumentacji medycznej (brak skierowania,
brak ubezpieczenia) pacjent dostaje informację o konieczności zgłoszenia się do Rejestracji Poradni.
3
Po wprowadzeniu numeru PESEL lub zeskanowaniu kodu kreskowego i uzyskaniu informacji o potwierdzeniu
drukarka Infokiosku powinna wydrukować informacje (w tym nazwę kolejki/poradni, numer gabinetu) oraz
wskazać na mapie drogę dojścia do celu wizyty.
4
System powinien mieć funkcję potwierdzenia wizyty pacjenta przez personel przychodni (opcjonalnie — jeżeli
nie chcemy by Pacjent sam potwierdzał swoje przybycie). Wprowadzenie pacjenta do kolejki oczekujących
przez weryfikacje danych (np. numer PESEL).
5 System musi prezentować użytkownikom systemu listę pacjentów z potwierdzoną wizytą do właściwych
kolejek. Listy pacjentów są widoczne dla uprawnionych użytkowników
Wzór karty Pacjenta Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego
Instytutu Badawczego
II.1.2.10. Infokioski
Wymagane dostarczenie 17 szt. Infokiosków spełniających poniżej opisane minimalne parametry funkcjonalne.
II.1.2.10.1 Wymagania systemu
Celem zainstalowania kiosków multimedialnych (zwanych infokioskami) na terenie Narodowego Instytutu
Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego i stworzenia systemu informacji
Strona 65 z 106
elektronicznej jest pełnienie roli informacyjnej dla pacjentów, w tym w szczególności w zakresie dotyczącym
lokalizacji oraz poruszania się po obiektach szpitala (nawigacja). Dodatkowo kioski multimedialne powinny
prezentować informacje umożliwiające nawigację po obiekcie prezentując np. trasę dojścia do danego miejsca.
Infokioski korzystają z okablowania szpitala. Jednak miejsce położenia Infokiosku musi zostać ustalone na etapie
wdrażania z Zamawiającym. Zamawiający zapewni niezbędną instalację i sieć w miejscu jego lokalizacji
Infokiosku.
Uwaga: Szczegółowa mapa odwzoruje budynek główny, pozostałe są tylko zaznaczone jako bryła. Infokioski
korzystają z okablowania szpitala. Tylko doprowadzany jest kabel od gniazda do infokiosku.
I WYMAGANIA OGÓLNE SYSTEMU INFORMACYJNEGO (MAPOWEGO)
1 Aplikacja na komputerach użytkowników dostępna przez przeglądarkę, instalowana na Infokiosku
i serwerze
2 Aplikacja udostępniona na komputerach użytkowników musi działać prawidłowo na systemach
operacyjnych od Windows 7 i wyżej lub równoważnym.
3 Uwierzytelnianie i autoryzacja dostępu do Systemu
4 Zarządzanie użytkownikami systemu oraz ich uprawnieniami
5 Zarządzanie pomieszczeniami
6 System powinien działać w oparciu o architekturę klient-serwer i być uruchamiany automatycznie podczas
włączania serwera
7 System musi być zintegrowany z bramką GSM w celu wysyłania wskazówek dojścia z modułu mapowego
na wskazany numer telefonu. Konto do usługi bramki GSM przekaże Zamawiający.
8
System obejmuje wizualizację (mapa) w rzucie izometrycznym kompleksu szpitalnego Narodowego
Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego w Warszawie
(główny budynek plus parking)
9 System musi mieć możliwość zaznaczenia budynku w przestrzeni 3D niezależnie od położenia widoku.
Po zaznaczeniu przedstawiony zostanie krótki opis budynku (nazwa, dodatkowy opis, zdjęcie)
10
Budynek Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego w Warszawie musi posiadać trójwymiarowe odwzorowanie planów budynku w podziale na
piętra z możliwością przełączania się pomiędzy nimi oraz nawigacją tzn. obracanie oraz
przybliżanie/oddalanie widoku
11 Z poziomu mapy pacjent ma możliwość przejścia do wnętrza budynku i wybranego piętra
prezentującego układ pomieszczeń
12
System musi udostępniać możliwość szybkiego i łatwego wyszukania drogi z punktu A do punktu B
(np. pomieszczenia, przychodni, laboratorium, etc.) znajdującego się na dowolnym piętrze w budynku
szpitala i prezentować użytkownikowi sposób dojścia do niego.
13
Sposób prezentacji ścieżki uwzględnia animację drogi na mapie poprzez stopniową odsłonę punktów
pośrednich (węzłów) z jednoczesnym płynnym przesuwaniem widoku kamery. Dodatkowo prezentacja
musi zawierać słowny opis przejścia przez poszczególne odcinki (jak np. potrzeba wejścia do windy /
na schody / wyjścia z budynku itp.). Przy prezentacji ścieżki do celu użytkownik ma dodatkowo
możliwość podglądu zdjęcia docelowego miejsca
14
Miejsce docelowe, które znajduje się poza budynkiem Narodowego Instytutu Onkologii im. Marii
Skłodowskiej-Curie – Państwowego Instytutu Badawczego w Warszawie obejmuje wyłącznie prezentację
lokalizacji budynku na mapie kompleksu szpitala
15
Widok piętra Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu
Badawczego w Warszawie umożliwia wybranie konkretnego pomieszczenia i uzyskanie na jego temat
informacji: dodatkowego opisu i zdjęcia wnętrza. Możliwe jest wybranie opcji umożliwiającej
wyznaczenie drogi do pomieszczenia
16
System posiada wbudowaną wyszukiwarkę dla treści znajdujących się w bazie danych systemu
i przeznaczonych do wyszukiwania dla użytkowników.
Wyniki wyszukiwania na liście są interaktywne, czyli jest możliwość ich dotknięcia, tym samym
wyświetlenia informacji szczegółowej na temat danego elementu i wytyczenia trasy nawigacji do niego,
w przypadku jego powiązania z planem budynku
Strona 66 z 106
17
Treści obiektów interaktywnych prezentowanych w systemie są w pełni edytowalne z poziomu panelu
administracyjnego:
a. Opis budynku zawierający nazwę. zdjęcie (opcjonalne) oraz informacje dodatkowe;
b. Ciągi komunikacyjne - system musi umożliwiać tworzenie ścieżki punkt po punkcie będącej
podstawą wytyczania drogi wraz z opcjonalnym słownym nanoszeniem wskazówek do danego
punktu (jak np. skręt przy charakterystycznym obiekcie, wejście do windy itp.);
c. Tworzenie i edycja punktów zainteresowania (POI), możliwość oznaczenia punktu ikoną z
dostępnej listy ikon i/lub słowną nazwą. Punkty POI powinny mieć możliwość określenia
poziomu zbliżenia dla którego mają być wyświetlane aby móc zapobiegać się ich nakładaniu;
d. Tworzenie i edycja danych pomieszczeń, panel musi umożliwiać wprowadzenie nazwy
pomieszczenia, jego opisu, dołączenia opcjonalnego zdjęcia oraz zmianę oznaczenia
kolorystycznego na mapie;
e. Opis obiektu typu osoba. obejmujący przypisanie jej do pomieszczeń i inne informacje
umożliwiające odpowiednie indeksowanie informacji o osobie;
f. Wszystkie elementy (budynki, pomieszczenia, osoby) powinny zawierać możliwość oznaczenia
jej tagami w celu łatwiejszego odnalezienia wybranych rekordów.
18
Panel zarządzania musi posiadać moduł umożliwiający podgląd stanu kiosków wchodzących w skład
systemu. Prezentowane informacje muszą zawierać co najmniej: nazwę i opis urządzenia, jego adres
sieciowy, aktualny zrzut ekranu, status (włączony / wyłączony). Moduł powinien pozwalać na zdalny
restart aplikacji, włączenie / wyłączenie ekranu. Powinien również posiadać możliwość zdefiniowania
harmonogramu pracy kiosku w oparciu o wybrane dni tygodnia.
19
Dostęp do panelu zarządzania musi być chroniony loginem i hasłem. Panel musi umożliwiać zarządzanie
użytkownikami uprawnionymi do dostępu do zarządzania danymi mapowymi i podglądu stanu kiosków.
II.1.2.10.2 Opis techniczny sprzętu
Na System składają się Infokioski, za pomocą których pacjenci będą pobierali bilety z numerkami kolejkowymi
(system kolejkowy), z wbudowanymi drukarkami termicznymi i skanerami umożliwiającymi potwierdzenie
przybycia pacjenta na wizytę.
Musi istnieć możliwość rozbudowy systemu kolejkowego w przyszłości o kolejne urządzenia.
W ramach realizacji prac należy dostarczyć i zamontować następujący sprzęt:
Lp. Element Ilość sztuk
2.1 Infokiosk mały 15
2.2 Infokiosk duży 2
Infokiosk mały
Infokioski muszą zostać zainstalowane przy wejściu w ciągach komunikacyjnych, aby zapewnić wszystkim
pacjentom poradni możliwość uzyskania Informacji i potwierdzenia przybycia na wizytę. Za pomocą dotykowego
ekranu pacjent potwierdza wizytę. Na podstawie wprowadzonych danych zostanie wydrukowany bilet kolejkowy.
Infokiosk mały bez drukarki i skanera– 5 sztuk do usytuowania u Partnerów projektu
INFOKIOSK NAŚCIENNY Z BILETEREM I CZYTNIKIEM KODÓW QR – Minimalne wymagania
Obudowa:
Wykonana z blachy stalowej malowanej proszkowo. Kolor uzgodniony z Zamawiającym
Naścienna z przeznaczeniem do użytkowania wewnątrz budynków odporna na akty wandalizmu,
uniemożliwiająca dostęp z zewnątrz do podzespołów wewnętrznych i jakichkolwiek połączeń
Mocowanie umożliwiające trwałe mocowanie do ściany
Szerokość max 600mm, wysokość max 600mm, Głębokość max 280mm
Monitor:
Monitor o wielkości min. 21,5”
Panel LED LCD IPS
Strona 67 z 106
Jasność min. 300 cd/m2
Kąty widzenia 178/178
Rozdzielczość FHD (1920x1080)
Kontroler dotyku Projected Capacitive Technology (PCT), Liczba punktów dotyku 10
Przystosowany do pracy 24/7
Powłoka antybakteryjna
Jednostka komputerowa:
Procesor 4 rdzeniowy o taktowaniu min 1.6 GHz
Pamięć RAM 4 GB
Dysk: min 32 GB SSD lub 120 HDD
Karta sieciowa 10/100/1000 Mbit/s
Zintegrowana karta graficzna
Infokiosk do zainstalowania w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie –
Państwowym Instytucie Badawczym - 10 sztuk
INFOKIOSK NAŚCIENNY Z BILETEREM I CZYTNIKIEM KODÓW QR – Wymagania minimalne
Obudowa:
Wykonana z blachy stalowej malowanej proszkowo. Kolor uzgodniony z Zamawiającym
Naścienna z przeznaczeniem do użytkowania wewnątrz budynków odporna na akty wandalizmu,
uniemożliwiająca dostęp z zewnątrz do podzespołów wewnętrznych i jakichkolwiek połączeń
Mocowanie umożliwiające trwałe mocowanie do ściany.
Szerokość max 600mm, wysokość max 600mm, Głębokość max 280mm
Monitor:
Monitor o wielkości min. 21,5”
Panel LED LCD IPS
Jasność min. 300 cd/m2
Kąty widzenia 178/178
Rozdzielczość FHD (1920x1080)
Kontroler dotyku Projected Capacitive Technology (PCT), Liczba punktów dotyku 10
Przystosowany do pracy 24/7
Powłoka antybakteryjna
Jednostka komputerowa:
Procesor: czterordzeniowy o taktowaniu min 1,6 GHz,
Pamięć RAM 4 GB
Dysk: min 32 GB SSD lub 120 HDD
Karta sieciowa 10/100/1000 Mbit/s
Zintegrowana karta graficzna
System operacyjny Windows 10 lub równoważny
Wyposażenie:
Drukarka termiczna
Metoda druku: druk termiczny liniowy
Rozdzielczość 203 DPI
Szerokość papieru 58/60/80 mm
Maksymalna szybkość druku 200 mm/s
Grubość papieru termoczułego: 65 do 150 um
Automatyczne ucinanie: pełne i częściowe
Czytnik kodów kreskowych/QR
Area manager 1D/2D
Rozdzielczość 1280×800
Odczyt z ekranów LCD
Celownik laserowy lub ledowy
Strona 68 z 106
Infokiosk duży Infokiosk 55” – sztuk 2
Infokioski muszą zostać zainstalowane przy wejściu w ciągach komunikacyjnych, aby zapewnić wszystkim
pacjentom poradni i szpitala możliwość uzyskania informacji. Za pomocą dotykowego ekranu pacjent wyszukuje
swój cel na mapie. Na podstawie wprowadzonych danych zostanie wydrukowany bilet kolejkowy.
Lokalizacja - ul. Roentgena 5:
budynek główny – wejście A
budynek Poradni – wejście D
ELEMMET WYMAGANIA MINIMALNE - OPIS PARAMETRÓW
Obudowa
konstrukcja zewnętrzna powinna być wykonana z blachy stalowej o konstrukcji
samonośnej zapewniającej sztywność obudowy
monitor zabudowany w poszyciu obudowy, odchylony w kierunku od użytkownika
do maksymalnie 45°
wolnostojąca, uniemożliwiająca dostęp z zewnątrz do podzespołów wewnętrznych
i jakichkolwiek połączeń, dostęp serwisowy poprzez drzwiczki rewizyjne
z zamkiem patentowym
na froncie obudowy logo lub grafika zgodna z wymaganiami Zamawiającego.
Kolorystyka dopasowana do wymagań Zamawiającego
Monitor przekątna monitora min .: 55"
rodzaj wyświetlacza: LED
naturalna rozdzielczość pracy min: 1920 x 1080
technologia rozpoznawania dotyku: pojemnościowa lub IR lub SAW co
najmniej 4 punktów dotyku
Jednostka sterująca procesor min. czterordzeniowy o taktowaniu min . 2 GHz
pamięć RAM min. 4 GB
karta graficzna z pamięcią RAM min . 1 GB
dysk twardy min. 128 GB
interfejs sieciowy: 10/100/1000 Mbit
min 3x port USB
Szczegółowy opis lokalizacji infokiosków ze wskazaniem ich liczby i rodzaju stanowi załącznik nr 1.6.
Opis równoważności dla systemu Windows 10
System operacyjny komputerów
Nazwa komponentu
Wymagane minimalne parametry techniczne
System operacyjny
komputerów
System operacyjny Windows 10 Professional PL wraz z kluczem licencyjnym Windows 10
Professional lub równoważny
Zamawiający dopuszcza licencję typu OEM lub DOEM.
Opis równoważności:
Zainstalowany system operacyjny spełniający poniższe wymagania:
• Możliwość dokonywania aktualizacji i poprawek systemu przez Internet z możliwością
wyboru instalowanych poprawek.
• Możliwość dokonywania uaktualnień sterowników urządzeń przez Internet.
• Darmowe aktualizacje w ramach wersji systemu operacyjnego przez Internet (niezbędne
aktualizacje, poprawki, biuletyny bezpieczeństwa muszą być dostarczane bez dodatkowych
opłat) – wymagane podanie nazwy strony serwera WWW.
• Internetowa aktualizacja zapewniona w języku polskim.
• Wbudowana zapora internetowa (firewall) dla ochrony połączeń internetowych; zintegrowana
z systemem konsola do zarządzania ustawieniami zapory i regułami IP v4 i v6.
• Zlokalizowane w języku polskim, co najmniej następujące elementy: menu, odtwarzacz
multimediów, pomoc, komunikaty systemowe.
• Wsparcie dla większości powszechnie używanych urządzeń peryferyjnych (drukarek,
urządzeń sieciowych, standardów USB, Plug &Play, Wi-Fi).
Strona 69 z 106
• Funkcjonalność automatycznej zmiany domyślnej drukarki w zależności od sieci, do której
podłączony jest komputer.
• Interfejs użytkownika działający w trybie graficznym z elementami 3D, zintegrowana z
interfejsem użytkownika interaktywna część pulpitu służącą do uruchamiania aplikacji, które
użytkownik może dowolnie wymieniać i pobrać ze strony producenta.
• Możliwość zdalnej automatycznej instalacji, konfiguracji, administrowania oraz
aktualizowania systemu.
• Zabezpieczony hasłem hierarchiczny dostęp do systemu, konta i profile użytkowników
zarządzane zdalnie; praca systemu w trybie ochrony kont użytkowników.
• Zintegrowany z systemem moduł wyszukiwania informacji (plików różnego typu) dostępny z
kilku poziomów: poziom menu, poziom otwartego okna systemu operacyjnego; system
wyszukiwania oparty na konfigurowalnym przez użytkownika module indeksacji zasobów
lokalnych.
• Zintegrowany z systemem operacyjnym moduł synchronizacji komputera z urządzeniami
zewnętrznymi.
• Wbudowany system pomocy w języku polskim.
• Możliwość przystosowania stanowiska dla osób niepełnosprawnych (np. słabo widzących).
• Możliwość zarządzania stacją roboczą poprzez polityki – przez politykę rozumiemy zestaw
reguł definiujących lub ograniczających funkcjonalność systemu lub aplikacji.
• Wdrażanie IPSEC oparte na politykach – wdrażanie IPSEC oparte na zestawach reguł
definiujących ustawienia zarządzanych w sposób centralny.
• Automatyczne występowanie i używanie (wystawianie) certyfikatów PKI X.509.
• Rozbudowane polityki bezpieczeństwa – polityki dla systemu operacyjnego i dla wskazanych
aplikacji.
• System posiada narzędzia służące do administracji, do wykonywania kopii zapasowych
polityk i ich odtwarzania oraz generowania raportów z ustawień polityk.
• Wsparcie dla Sun Java i .NET Framework 1.1 i 2.0 i 3.0 lub programów równoważnych, tj. –
umożliwiających uruchomienie aplikacji działających we wskazanych
środowiskach.
• Wsparcie dla JScript i VBScript lub równoważnych – możliwość uruchamiania interpretera
poleceń.
• Zdalna pomoc i współdzielenie aplikacji – możliwość zdalnego przejęcia sesji zalogowanego
użytkownika celem rozwiązania problemu z komputerem.
• Rozwiązanie służące do automatycznego zbudowania obrazu systemu wraz z aplikacjami.
Obraz systemu służyć ma do automatycznego upowszechnienia systemu operacyjnego
inicjowanego i wykonywanego w całości poprzez sieć komputerową.
• Rozwiązanie umożliwiające wdrożenie nowego obrazu poprzez zdalną instalację.
• Graficzne środowisko instalacji i konfiguracji.
• Transakcyjny system plików pozwalający na stosowanie przydziałów (ang. quota) na dysku
dla użytkowników oraz zapewniający większą niezawodność i pozwalający tworzyć kopie
zapasowe.
• Zarządzanie kontami użytkowników sieci oraz urządzeniami sieciowymi
tj. drukarki, modemy, woluminy dyskowe, usługi katalogowe.
• Udostępnianie modemu.
• Oprogramowanie dla tworzenia kopii zapasowych (Backup); automatyczne wykonywanie
kopii plików z możliwością automatycznego przywrócenia wersji wcześniejszej.
• Możliwość przywracania plików systemowych.
• System operacyjny musi posiadać funkcjonalność pozwalającą na identyfikację sieci
komputerowych, do których jest podłączony, zapamiętywanie ustawień
i przypisywanie do min. 3 kategorii bezpieczeństwa (z predefiniowanymi odpowiednio do
kategorii ustawieniami zapory sieciowej, udostępniania plików itp.
• Możliwość blokowania lub dopuszczania dowolnych urządzeń peryferyjnych za pomocą
polityk grupowych (np. przy użyciu numerów identyfikacyjnych sprzętu).
• Zamawiający wymaga dostarczenia systemu operacyjnego w wersji 64-bit.
• Licencja i oprogramowanie musi być nowe, nieużywane.
Strona 70 z 106
DOSTAWA, GWARANCJA
A. Dostawa, instalacja, montaż, instruktaż
Element
montaż infokiosków w miejscu wskazanym przez Zamawiającego
instalacja urządzenia
zainstalowane i skonfigurowane oprogramowanie systemowe i oprogramowanie zarządzająco
- sterujące
instruktaż w zakresie obsługi urządzenia i zainstalowanego oprogramowania dla
administratorów
instrukcja obsługi dotycząca eksploatacji kiosku i postępowania w przypadku awarii, wydana
w języku polskim
instrukcja dotycząca konfiguracji oprogramowania, wydana w języku polskim
możliwość dokonywania zmian konfiguracji przez Zamawiającego
B. Gwarancja
Element
Gwarancja gwarancja min. 24 m-ce
naprawa w ciągu max. 24 godzin od zgłoszenia awarii poprzez serwis producenta
wsparcie 12-miesięczne – w ramach wsparcia kwartalna aktualizacja
oprogramowania o ile taką dostawca oprogramowania udostępni
C. Serwis
Zintegrowany System Serwisowy
Opis Zamawiający wymaga aby Wykonawca posiadał wdrożony Zintegrowany
System Serwisowy, który w sprawny sposób umożliwia zgłoszenie awarii
urządzeń oraz śledzenie statusów naprawy.
Internetowy system przyjmowania sprzętu do serwisu
Funkcjonalność uzyskanie danych o dostarczonych produktach w szczególności
o terminie ważności gwarancji
uzyskanie informacji o elementach składowych produktu, jeżeli jest
wytworzony przez oferenta
uzyskanie historii awarii produktu oraz podjętych interwencji
powiadamianie Zamawiającego drogą elektroniczną (np. e-mail)
o podjętych czynnościach w ramach zarejestrowanego zgłoszenia (np.
określenie terminu usunięcia usterki, określenie terminu planowanej
wizyty serwisowej wraz z opisem planowanych czynności, zamknięcie
zgłoszenia serwisowego)
możliwość zgłaszania propozycji dotyczących funkcjonalności
oprogramowania
możliwość zgłaszania błędów w oprogramowaniu
zarejestrowanie zgłoszenia reklamacyjnego
śledzenie stanu obsługi zgłoszenia reklamacyjnego od momentu
zarejestrowania do jego zamknięcia
Działanie Zamawiający wymaga, aby zgłoszenia problemów technicznych były
dokonywane drogą elektroniczną przez osobę odpowiedzialną i upoważnioną po
stronie Zamawiającego, mającą dostęp do portalu poprzez login i hasło.
Certyfikaty i dokumenty Do oferty należy dołączyć karty katalogowe proponowanych urządzeń,
wizualizacje graficzne
Strona 71 z 106
II.1.2.11 Zakres e-usług przewidzianych do wdrożenia u Partnerów
projektu
Wykonawca musi wziąć pod uwagę fakt, iż projekt zakłada wprowadzenie świadczenia usług on-line w zakresie
obsługi opieki zdrowotnej, takich jak rejestracja wizyt przez internet, elektroniczny dostęp do dokumentacji
medycznej, elektroniczne konsultacje zarówno w Narodowym Instytucie Onkologii im. Marii Skłodowskiej-
Curie – Państwowym Instytucie Badawczym jak i w jednostkach Partnerskich. Poprzez korzystanie e-usług
pacjenci zdobędą możliwość korzystania z usług oferowanych zarówno przez Przychodnie położone na terenach
wiejskich jak i przez Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut
Badawczy. Dodatkowo wybrane e-usługi mają być skierowane do lekarzy z jednostek Partnerskich i mają
umożliwić między innymi konsultacje medyczne.
Pacjenci z obszarów wiejskich będą mieli możliwość rejestracji w swojej poradni oraz możliwość rejestracji
w poradni Narodowym Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie
Badawczym.
W ramach projektu „Nowoczesny Szpital, Nowoczesny ZOZ” przewiduje się wdrożenie u Partnerów projektu
następujących e-usług, które zostaną zrealizowane w ramach odrębnego postępowania przetargowego:
- e-rejestracja,
- e-konsultacje,
- e-wywiad,
- e-dokumentacja,
- e-powiadomienia,
- e-partner,
- e-obchód,
- e-informator.
U Partnerów projektu zakłada się wdrożenie wskazanych poniżej e-usług:
1. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Cegłowie
- e-rejestracja,
- e-konsultacje,
- e-dokumentacja,
- e-powiadomienia,
- e-partner,
- e-informator.
Używany jest u Partnera system SOMED firmy KamSoft
2. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Kałuszynie
- e-rejestracja,
- e-konsultacje,
- e-wywiad,
- e-dokumentacja,
- e-powiadomienia,
- e-partner,
- e-informator.
Używany jest u Partnera system SOMED firmy KamSoft
3. Filie Samodzielnego Publicznego Zakładu Opieki Zdrowotnej w Sokołowie Podlaskim
- e-rejestracja,
- e-konsultacje,
- e-partner,
- e-informator.
Używany jest u Partnera system firmy NEXUS.
II.1.2.12 System wideokonferencji
Wykonawca zobowiązany jest dostarczyć system umożliwiający przeprowadzenie konsultacji stanu zdrowia
pacjenta przez lekarza w ramach e-usługi e-Konsultacja i e-Partner za pośrednictwem videokonferencji.
System do wideokonferencji – 7 licencji (dla Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie
– Państwowego Instytutu Badawczego i Partnerów projektu).
Strona 72 z 106
Usługa w zakresie konsultacji w trybie wideokonferencji realizowana będzie dla partnerów projektu na serwerach
posiadanych przez Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy.
W powiązaniu z usługą e-Partner lekarz w trakcie e-Konsultacji wideokonferencyjnej będzie mógł uzyskać dostęp
do danych medycznych i wyników badań pacjenta, usługa umożliwi również lekarzowi branie udziału
w konsylium. Lekarz po wysłaniu wyników badań i innych informacji zostanie powiadomiony przez system
o planowanej dacie konsylium / wideokonferencji.
Do obsługi konsyliów i wideokonferencji zostaną wykorzystane systemy będące w posiadaniu i użytkowane przez
Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy. Dodatkowo
w przypadku podmiotów, z którymi Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy
Instytut Badawczy ma zawartą umowę na wykonywanie usług e-usługa umożliwi poza wyżej wymienionymi
funkcjami możliwość rezerwacji i zlecenia określonych badań pacjentowi skierowanemu do Narodowego
Instytutu Onkologii im. Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego.
II.1.3 Repozytorium elektronicznej dokumentacji medycznej
(EDM)
Repozytorium elektronicznej dokumentacji medycznej
1 Możliwość bezpiecznego gromadzenia i udostępnianie dokumentacji medycznej w postaci elektronicznej
2 System EDM posiada możliwość współpracy z systemem HIS, co umożliwia utrwalanie i przechowywanie
elektronicznej dokumentacji medycznej zgodnie z aktualnie obowiązującymi przepisami prawa i wytycznymi
MZ, NFZ, CSIOZ, MSWiA oraz pozostałymi instytucjami państwowymi.
3 Możliwość pewnego zabezpieczenia elektronicznej dokumentacji medycznej przed uszkodzeniem lub utratą
4 Możliwość zagwarantowania pełnej integralności i zachowania wiarygodności przechowywanej dokumentacji
generowanej przez systemy medyczne
5 W systemie istnieje możliwość trwałego archiwizowania dokumentów bez opcji usunięcia lub modyfikacji.
6 Repozytorium gwarantuje przechowywanie każdego dokumentu w postaci zaszyfrowanej
7 System pozwala na wymianę dokumentacji z innymi podmiotami zgodnie z profilami IHE: XDS.b, XCA
8 Możliwość uzyskania dostępu do systemu z poziomu podstawowych przeglądarek internetowych Mozilla
Firefox, Opera, Google Chrome, Microsoft Edge, Internet Explorer
9 System jest zgodny z technologią RWD (Responsive Web Design)
10 Obsługa interfejsu co najmniej w języku polskim i angielskim.
11 Możliwość optymalizacji ilość danych przesyłanych pomiędzy przeglądarką a serwerem aplikacyjnym
z wykorzystaniem możliwości technologii HTML5 i architektury SPA lub analogicznego mechanizmu
12 Możliwość obsługi i wymiany dokumentacji w formacie HL7 CDA, PIK HL7 CDA
13 Repozytorium EDM musi współdzielić z HIS m.in.: słownik jednostek organizacyjnych, rejestr użytkowników,
rejestr pacjentów
14 Dostęp do systemu jest możliwy po podaniu unikatowego loginu lub hasła
15 Po zalogowaniu użytkownik ma dostęp tylko do uprawnionego obszaru (np. administrator -> panel
administratora)
16 Możliwość digitalizacji dokumentów przechowywanych w wersji papierowej
17 System przypisuje unikatowy identyfikator dla każdego dokumentu.
18 Możliwość eksportu dokumentacji medycznej z Repozytorium EDM w formatach PDF, XML, a w przypadku
większej liczby dokumentów w pliku o rozszerzeniu .zip
19 Możliwość wyboru celu eksportu dokumentu
20 Możliwość dodatkowego zabezpieczenia eksportowanych danych hasłem.
21 Możliwość dodawania komentarzy do dokumentów z poziomu widoku dokumentu
22 System współpracuje z narzędziem umożliwiającym nagrywanie płyt CD/DVD z dokumentacją medyczną.
23 Możliwe jest utworzenie rekordu pacjenta będącego wyciągiem z dokumentów medycznych, zawierających
najważniejsze dane o pacjencie (m. in. rozpoznania, lista hospitalizacji, przepisane leki)
24 Zakładki w rekordzie pacjenta mogą być swobodnie dostosowywane do potrzeb użytkownika. Użytkownik za
pomocą kilku kliknięć (bez znajomości HTML) może wstawiać obszary, które chce widzieć w Rekordzie Pacjenta
w odpowiednich zakładkach.
25 Rekord pacjenta jest dostosowywany indywidualnie dla każdego lekarza
26 Prawidłowo uzupełnione dokumenty pozwalają na automatyczne zaciąganie danych do rekordu Pacjenta
27 Możliwe jest bezpośrednie przejście z konkretnego wpisu w rekordzie pacjenta do dokumentu źródłowego
Strona 73 z 106
28 System posiada mechanizmy umożliwiające wyszukiwanie według określonych parametrów (metadanych)
dokumentu oraz pełno-tekstowe przeszukiwanie treści dokumentów oraz załączników
29 System umożliwia grupowanie dokumentów względem jednostek medycznych, w których pacjent był leczony,
oraz przedstawiania dokumentów w grupach w porządku chronologicznym
30 Dokumenty pogrupowane względem jednostek medycznych mogą być filtrowane według lekarza
wystawiającego dokument, rodzaju dokumentu, zakresu czasu, w którym dokument był wystawiony oraz pełno-
tekstowego przeszukiwania treści dokumentów
31 W systemie istnieje możliwość konfiguracji filtrów wyszukiwania dokumentacji w postaci „ulubionych” i ich
zapis
32 W systemie, w przypadku badań laboratoryjnych, istnieje możliwość przedstawiania historii wyników w formie
tabel oraz w postaci wykresów z zaznaczonymi wartościami referencyjnymi
33 Dane przedstawione w formie tabeli oraz w postaci wykresu pozwalają na bezpośrednią nawigację do dokumentu
źródłowego
34 Zmiany w dokumentach są wersjonowane, co oznacza, że przechowywana w systemie jest każda wersja tego
samego dokumentu. Repozytorium implementuje mechanizm aktualizacji dokumentów.
35 Możliwość dostosowania, która wersja dokumentu ma być wyświetlana bezpośrednio po wyborze dokumentu
(najnowsza/najstarsza)
36 System pozwala na porównywanie różnych wersji tego samego dokumentu i zaznaczenie elementów różniących
te dokumenty
37 Możliwość rejestracji załączników dołączanych do dokumentacji medycznej generowanej w systemach
medycznych.
38 Możliwość podglądu załączników dołączanych do dokumentacji medycznej
39 W systemie zdefiniowane są poziomy dostępów do dokumentacji medycznej, które pozwalają na definiowanie
obszarów i dokumentacji dostępnych dla lekarza.
40 W przypadku, kiedy lekarz uzyskuje uprawnienia do dokumentacji w trakcie wizyty, system generuje zgodę dla
pacjenta, którą można wydrukować bezpośrednio z systemu. Uzyskiwanie uprawnień może być ograniczone
czasowo (bezterminowo, dzień, tydzień, rok, do daty wybranej przez użytkownika z widoku kalendarza)
41 Repozytorium posiada możliwość gromadzenia informacji o zgodach pacjentów o obszarach i dokumentacji
dostępnych dla odpowiednich lekarzy
42 Użytkownik nie może uzyskać dostępu do danego obszaru bez wcześniejszego uzyskania zgody pacjenta
43 Możliwość realizacji dostępu do dokumentacji medycznej pacjenta w trybie krytycznym, wymagającym podania
konkretnego powodu uzyskania dostępu
44 Możliwość drukowania pojedynczych dokumentów medycznych, zbiorów dokumentów medycznych. Wydruk
dokumentu, jeżeli to konieczne, wymaga określenia odpowiedniego celu wydruku.
45 Możliwość zdefiniowania zbioru dokumentów medycznych do druku z listy wszystkich dokumentów
46 Możliwość szybkiego usunięcia dokumentu ze zbioru dokumentów medycznych przygotowanego do druku
47 Wszystkie operacje dotyczące dokumentu są zapisywane w systemie w postaci logów w sposób umożliwiający
określenie kolejności działań i wykonawców czynności.
48 Logowanie operacji związanych z m. in.: wglądem w dokumentację, wydrukiem dokumentacji, udostępnieniem
dokumentacji, uzyskiwaniem dostępu do dokumentacji.
49 Możliwość rejestrowania informacji o udostępnieniach elektronicznej dokumentacji medycznej poza systemem z
uwzględnieniem informacji o dacie i godzinie udostępnienia, danych wnioskodawcy, zakresie udostępnienia,
dacie i formie przekazywanej dokumentacji wnioskodawcy
50 Repozytorium przechowuje dokumenty zgody na przetwarzanie danych osobowych oraz zgody na dostęp do
dokumentacji medycznej.
51 Możliwość wykonywania podpisu cyfrowego podczas eksportowania pojedynczego dokumentu lub paczki
dokumentów.
52 Możliwość wyszukiwania pacjenta za pomocą imienia, nazwiska, numeru PESEL, daty urodzenia
53 Możliwość wyszukiwania przez lekarza wszystkich pacjentów w systemie spełniających odpowiednie kryteria
wyszukiwania
54 Możliwość weryfikacji podpisu cyfrowego
55 Możliwość wyboru domyślnej transformaty zgodnie, z którą mają być wyświetlane dokumenty
56 Możliwość powiązywania dokumentów oraz ich odpowiedniego wyświetlania.
57 Możliwość łatwego przejścia z dokumentu do dokumentu powiązanego.
58 System posiada dedykowany panel administratora
59 Administrator z panelu administratora ma możliwość nadawania ról użytkownikom oraz uprawnień do wglądu
w odpowiednie obszary oraz dokumentację pacjentów
Strona 74 z 106
60 Administrator ma dostęp do logów przechowujących informacje o próbach dostępów do odpowiednich obszarów
i dokumentacji pacjenta, próbach udostępnień dokumentacji pacjenta, operacjach wykonywanych na
elektronicznej dokumentacji medycznej
II.1.4 Adapter komunikacyjny (konektor)
Adapter komunikacyjny zostanie wykonany na zasadzie łączności z systemem HIS Zamawiającego, zgodnie z
protokołem komunikacji, wykonanym w systemie HIS wg parametrów zgodnych z Załącznikiem nr 1.2 do OPZ:
Specyfikacja formatów danych i standardów stosowanych w lokalnych systemach HIS i Repozytorium
Elektronicznej Dokumentacji Medycznej.
II.1.5 Szyna Danych - Broker informacyjny
Wykonawca jest zobowiązany w terminie 2 tygodni od daty podpisania umowy, przekazać dokument „Interfejs
komunikacyjny API systemu szpitalnego Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego do systemów EDM i e-Usług”, który powstanie na podstawie specyfikacji
formatów danych i standardów stosowanych w lokalnych systemach HIS i Repozytorium Elektronicznej
Dokumentacji Medycznej, stanowiący Załącznik nr 1.2 do OPZ.
II.1.6 Usługi wdrożeniowe i utrzymaniowe
Wykonawca zobowiązuje się do świadczenia usług gwarancyjnych zgodnie z zapisami Umowy i pkt III OPZ.
ASYSTA PRZEDWDROŻENIOWA:
Asysta świadczona przez 5 dni przed produkcyjnym uruchomieniem systemu w wymiarze co najmniej 8 godzin
dziennie w przypadku wymiany systemu oraz danego modułu wymienionego w Załączniku nr 1.1 do OPZ. Asysta
świadczona przez minimum 2 dedykowane osoby do każdego modułu, w którym zaszła zmiana interfejsu.
L.p. Liczba osób asysty przedwdrożeniowej
Liczba oddziałów szpitalnych 34 34
Liczba gabinetów poradni / ambulatorium 69 23
Liczba Rejestracji 9 9
Zakłady RTG 2 6
Zakłady Radioterapii 2 6
Zakład Rehabilitacji 1 1
Pracownie Diagnostyczne 6 6
Pozostałe jednostki 10 10
ASYSTA WDROŻENIOWA:
Asysta świadczona przez 15 dni po produkcyjnym uruchomieniem systemu w wymiarze co najmniej 8 godzin
dziennie w przypadku wymiany interfejsu do danego modułu: Asysta świadczona przez minimum 2 dedykowane
osoby do każdego modułu, w którym zaszła zmiana interfejsu.
ASYSTA POWDROŻENIOWA:
Asysta powdrożeniowa będzie wykonywana w wymiarze co najmniej 8 godzin dziennie przez minimum 2 osoby
u Zamawiającego przez okres 30 dni roboczych na osobę.
Strona 75 z 106
II.2 Infrastruktura bazodanowa oraz sprzętowa – Wymagania szczegółowe
II.2.1 Baza danych
Wykonawca dostarczy systemy baz danych dla systemu migrowanego składające się z następujących elementów
i parametrów minimalnych (systemy EDM i e-usług mogą zostać oparte o inna bazę danych w tzw. chmurze
obliczeniowej):
Element
systemu
Lista parametrów minimalnych Ilość sztuk.
Appliance
systemu
infrastruktury
baz danych
Architektura platformy bazodanowej dla HIS
Elementy sprzętowe Appliance
1. Klaster – dwa fizyczne węzły serwerowe, możliwość zainstalowania
w dwóch datacenter odległych od siebie na odległość ok. 350 m.
2. Klaster dwuwęzłowy skonfigurowany przez producenta systemu (ang.
Appliance).
3. Możliwość instalacji w standardowych szafach Rack 19”
4. Dostarczony wraz z szynami do montażu w szafie rack.
5. Zainstalowany jeden procesor posiadający nie mniej niż 8 rdzeni oraz
posiadający taktowanie minimum 3,5GHz w każdym węźle klastra
6. Zainstalowane 786 GB pamięci operacyjnej RAM DDR4.
7. Interconnect klastra realizowany w oparciu o technologię umożliwiającą
przepustowość 2 x 10 GB/s lub równoważną.
8. Kontroler RAID obsługujący dyski lokalne musi posiadać 2GB pamięci
cache zabezpieczonej przed utratą danych w przypadku utraty zasilania.
9. Zintegrowane co najmniej cztery interfejsy 1GbE Base-T w każdym
z węzłów. Karta LAN 2x 10Gbit MMF LC; możliwość wymiany
zainstalowanych interfejsów LAN na interfejsy 2/4x 10Gbit Base-T lub 2x
25Gbit SFP+.
10. Zainstalowane dyski (w każdym z węzłów): min. dwa dyski SSD w RAID-
1 na system operacyjny Appliance oraz min. pięć dysków 1,92TB SSD Mixed-
Use na przestrzeń dla systemu bazy danych.
11. Przestrzeń dla systemu bazy danych musi obsługiwać deduplikację
i kompresję danych.
12. Wymienne na gorąco: zasilacze, dyski; redundantne zasilanie każdego z
węzłów.
13. Możliwość wymiany węzła serwerowego bez wyłączania całego klastra.
14. Redundantne w modelu 1+1, Hot-Plug, AC, 800W
15. Niezależna od zainstalowanego na serwerze systemu operacyjnego karta
zarządzająca posiadająca dedykowany port RJ-45 100/1000 Mb Ethernet
umożliwiająca:
a. Monitoring stanu serwera, pełne zarządzanie, zdalny restart
serwera;
b. Połączenie przez dedykowane złącze RJ-45 do komunikacji
wyłącznie z kontrolerem zdalnego zarządzania z możliwością
przeniesienia tej komunikacji na inną kartę sieciową
współdzieloną z systemem operacyjnym;
c. Dostęp poprzez przeglądarkę Web, SSL, SSH;
d. Zarządzanie mocą i jej zużyciem oraz monitoring zużycia energii;
e. Zarządzanie alarmami (zdarzenia poprzez SNMP)
f. Możliwość przejęcia konsoli tekstowej
g. Integracja z Active Directory
h. Przekierowanie konsoli graficznej na poziomie sprzętowym oraz
możliwość montowania zdalnych napędów i ich obrazów na
poziomie sprzętowym (cyfrowy KVM)
i. Możliwość konfiguracji i wykonania aktualizacji BIOS,
Firmware, sterowników serwera bezpośrednio z GUI (graficzny
interfejs) karty zarządzającej bez pośrednictwa innych nośników
zewnętrznych i wewnętrznych poza obrębem karty zarządzającej.
16. Możliwość instalacji poprawek dla Systemu Operacyjnego oraz Bazy
danych.
17. Proponowane rozwiązanie umożliwia tworzenie kopii zapasowych systemu
bazy danych bez wpływu na wydajność Appliance. Kopie zapasowe są objęte
deduplikacją i kompresją.
1 kpl.
Strona 76 z 106
18. Możliwość automatycznej rejestracji zgłoszeń uszkodzonego sprzętu
w węźle klastra.
19. Gwarancja producenta na elementy sprzętowe Appliance minimum 36
miesięcy w trybie proaktywnym 24/7. W przypadku gwarancyjnej wymiany
dysków, uszkodzone nośniki pozostają u Zamawiającego.
20. Zamawiający wymaga dokumentacji w języku polskim lub angielskim.
21. Możliwość sprawdzenia konfiguracji sprzętowej serwera oraz warunków
gwarancji po podaniu numeru seryjnego bezpośrednio u producenta lub jego
przedstawiciela.
22. Nieograniczony w czasie dostęp do sterowników platformy serwerowej.
Elementy programowe Appliance
---------------------------
Licencje na system operacyjny typu open-source certyfikowany z oferowanym (opis
poniżej) motorem bazy danych posiadający prawo do najnowszej wersji przez okres
5 lat oraz wsparcie producenta systemu operacyjnego.
---------------------------
Licencje na motor bazy danych umożliwiające uruchomienie na 2 fizycznych
procesorach klasy x86 (po 1 szt. w 2 serwerach spiętych w klaster). Licencja musi
być dożywotnia. Wraz z licencją należy dostarczyć usługę asysty technicznej
i konserwacji producenta na okres minimum 60 miesięcy.
Funkcjonalność:
- Dostępność oprogramowania na współczesne 64-bitowe platformy Unix (HP-UX
dla Itanium, Solaris dla procesorów SPARC/x86-64, IBM AIX), Intel Linux 64-bit,
MS Windows 64-bit. Identyczna funkcjonalność serwera bazy danych na ww.
platformach.
- Niezależność platformy systemowej dla oprogramowania klienckiego / serwera
aplikacyjnego od platformy systemowej bazy danych.
- Możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy ww.
platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska
aplikacyjnego.
- Przetwarzanie transakcyjne wg reguł ACID (Atomicity, Consistency,
Independency, Durability) z zachowaniem spójności i maksymalnego możliwego
stopnia współbieżności. Mechanizm izolowania transakcji powinien pozwalać na
spójny odczyt modyfikowanego obszaru danych bez wprowadzania blokad, z kolei
spójny odczyt nie powinien blokować możliwości wykonywania zmian.
Oznacza to, że modyfikowanie wierszy nie może blokować ich odczytu, z kolei
odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie spójność
odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan
danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru
danych.
- Wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie
z Unicode).
- Możliwość migracji 8-bitowego zestawu znaków bazy danych (np MS Windows
CP 1252, ISO 8859-2) do Unicode.
- Skalowanie rozwiązań opartych o architekturę trójwarstwową: możliwość
uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia
z serwera aplikacyjnego do serwera bazy danych.
- Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich
rozmiar (liczbę wierszy).
- Wsparcie dla procedur i funkcji składowanych w bazie danych. Język
programowania powinien być językiem proceduralnym, blokowym
(umożliwiającym deklarowanie zmiennych wewnątrz bloku), oraz wspierającym
obsługę wyjątków. W przypadku, gdy wyjątek nie ma zadeklarowanej obsługi
wewnątrz bloku, w razie jego wystąpienia wyjątek powinien być automatycznie
propagowany do bloku nadrzędnego bądź wywołującej go jednostki programu.
- Możliwość kompilacji procedur składowanych w bazie danych do postaci kodu
binarnego.
- Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML
(INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza
modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np.
próba wykonania instrukcji DDL, start serwera, stop serwera, próba zalogowania
użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto mechanizm
wyzwalaczy powinien umożliwiać oprogramowanie obsługi instrukcji DML
Strona 77 z 106
(INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych
widokach (views).
- W przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd
zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza,
wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy
danych, zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed
rozpoczęciem instrukcji, w której wystąpił ww. błąd lub wyjątek.
- Baza danych powinna umożliwiać: wymuszanie złożoności hasła użytkownika,
czasu życia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora
bądź w przypadku przekroczenia limitu nieudanych logowań.
- Przywileje użytkowników bazy danych powinny być określane za pomocą
przywilejów systemowych (np. prawo do podłączenia się do bazy danych - czyli
utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów dostępu do
obiektów aplikacyjnych (np. odczytu / modyfikacji tabeli, wykonania procedury).
Baza danych powinna umożliwiać nadawanie ww. przywilejów za pośrednictwem
mechanizmu grup użytkowników / ról bazodanowych. W danej chwili użytkownik
może mieć aktywny dowolny podzbiór nadanych ról bazodanowych.
- Możliwość wykonywania i katalogowania kopii bezpieczeństwa bezpośrednio
przez serwer bazy danych. Możliwość zautomatyzowanego usuwania zbędnych
kopii bezpieczeństwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych -
stosownie do założonej polityki nadmiarowości backup'ów. Możliwość integracji
z powszechnie stosowanymi systemami backupu (Legato, Veritas, Tivoli, Data
Protector, Bacula itd). Wykonywanie kopii bezpieczeństwa powinno być możliwe
w trybie offline oraz w trybie online.
- Możliwość wykonywania kopii bezpieczeństwa w trybie online (hot backup).
- Odtwarzanie powinno umożliwiać odzyskanie stanu danych z chwili wystąpienia
awarii bądź cofnąć stan bazy danych do punktu w czasie. W przypadku odtwarzania
do stanu z chwili wystąpienia awarii odtwarzaniu może podlegać cała baza danych
bądź pojedyncze pliki danych.
- W przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe
pliki baz danych mogą być dostępne dla użytkowników.
- Wsparcie dla typu danych DICOM obsługiwanego wewnętrznie przez serwer bazy
danych.
- Możliwość zakładania w tabelach kolumn typu obsługującego standard DICOM.
- Możliwość przeszukiwania zakładania indeksów na grupie atrybutów metadanych
składowanych w kolumnach przechowujących dane w formacie DICOM.
- Możliwość przeszukiwania metadanych:
* wszystkich bądź niektórych atrybutów,
* możliwość zakładania indeksów na wybranych atrybutach,
* możliwość wyszukiwania pełnotekstowego,
* możliwość nawigacji zgodnej z hierarchią atrybutów.
- Składowanie metadanych DICOM i treści DICOM odbywa się wewnątrz bazy
danych.
- Operowanie na danych DICOM za pomocą konstrukcji języka SQL, procedur
składowanych, dostęp za pomocą Java API.
- Wbudowane mechanizmy konwersji treści DICOM do formatów JPEG, GIF,
MPEG, AVI.
- możliwość budowy klastra typu active-active opartego o maksymalnie 2 węzły
(maksymalnie 2 x 1 CPU)
- Możliwość zwiększenia przepustowości bazy danych poprzez uruchomienie
dodatkowych serwerów obsługujących tą samą bazę danych (w klastrze).
- 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).
- Unieruchomienie jednego z serwerów bazy danych nie może powodować braku
dostępu do jakiejkolwiek części danych – baza danych musi być nadal dostępna za
pośrednictwem funkcjonujących dalej serwerów
- Możliwość kontynuacji pracy użytkowników podłączonych do serwera klastrowej
bazy danych, który uległ awarii. Powinna istnieć możliwość przeniesienia sesji na
inny serwer oraz automatycznego powiadomienia aplikacji o wykonaniu
przełączenia.
- Obraz bazy danych (metadane, obiekty bazy danych, stan danych) w klastrowej
bazie danych musi być niezależny od serwera do którego zostało nawiązane
połączenie.
Strona 78 z 106
Pozostałe
1. Sprzęt powinien być nowy i pochodzić z oficjalnego i legalnego kanału
dystrybucyjnego producenta na rejon Polski
2. System musi mieć możliwość instalacji poprawek dla firmware, systemu
operacyjnego oraz bazy danych za pomocą zintegrowanego narzędzia dostarczanego
przez producenta urządzenia.
3. System musi uwzględniać możliwość uruchomienia dwóch klastrów baz danych
w trybie active-active oraz baz danych chmury hybrydowej dedykowanych do
e-usług i EDM.
II.2.2 Oprogramowanie do wirtualizacji
Należy dostarczyć licencje dla węzłów wyspecyfikowanych w Rozdziałach II.2.1
Nr Wymagane minimalne parametry techniczne
1. Warstwa wirtualizacji musi być rozwiązaniem systemowym tzn. musi być zainstalowana bezpośrednio na
sprzęcie fizycznym.
2. Rozwiązanie musi zapewnić możliwość obsługi wielu instancji systemów operacyjnych na jednym
serwerze fizycznym i powinno się charakteryzować maksymalnym możliwym stopniem konsolidacji
sprzętowej.
3. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych z
możliwością dostępu do 6TB pamięci operacyjnej.
4. Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych do
128 procesorów wirtualnych każda z krokiem co jeden wirtualny procesor.
5. Rozwiązanie musi umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe usługi bez spadku
wydajności i dostępności pozostałych wybranych usług.
6. Rozwiązanie powinno w możliwie największym stopniu być niezależne od producenta platformy
sprzętowej.
7. Rozwiązanie powinno wspierać następujące systemy operacyjne: Windows XP, Windows Vista,
Windows 7, Windows 8, Windows Server 2003R2, Windows Server 2008, Windows Server 2008R2,
SLES 12, SLES11, SLES10, RHEL 7, RHEL 6, RHEL 6, RHEL4, Solaris 11 x86, Solaris 10 x86, Debian,
CentOS, FreeBSD, Asianux, Ubuntu, SCO OpenServer, SCO Unixware.
8. Rozwiązanie musi umożliwiać przydzielenie większej ilości pamięci RAM dla maszyn wirtualnych niż
fizyczne zasoby RAM serwera w celu osiągnięcia maksymalnego współczynnika konsolidacji.
9. Rozwiązanie musi zapewnić możliwość monitorowania wykorzystania zasobów fizycznych
infrastruktury wirtualnej.
10. Oprogramowanie do wirtualizacji musi zapewnić możliwość wykonywania kopii migawkowych instancji
systemów operacyjnych na potrzeby tworzenia kopii zapasowych bez przerywania ich pracy.
11. Oprogramowanie do wirtualizacji musi zapewnić możliwość klonowania systemów operacyjnych wraz
z ich pełną konfiguracją i danymi.
12. Oprogramowanie zarządzające musi posiadać możliwość przydzielania i konfiguracji uprawnień
z możliwością integracji z usługami katalogowymi Microsoft Active Directory stosowanymi
u Zamawiającego.
13. Oprogramowanie do wirtualizacji musi obsługiwać przełączenie ścieżek SAN (bez utraty komunikacji)
w przypadku awarii jednej z dwóch ścieżek.
14. Rozwiązanie musi umożliwiać udostępnienie maszynie wirtualnej większej ilości zasobów dyskowych
aniżeli fizycznie zarezerwowane.
15. System powinien posiadać funkcjonalność wirtualnego przełącznika (switch) umożliwiającego tworzenie
sieci wirtualnej w obszarze hosta i pozwalającego połączyć maszyny wirtualne w obszarze jednego hosta.
16. Rozwiązanie musi zapewniać przenoszenie maszyn wirtualnych w czasie ich pracy pomiędzy serwerami
fizycznymi.
17. Rozwiązanie musi zapewniać wysoką dostępność maszyn wirtualnych rozumianą jako automatyczne
uruchomienie tych maszyn na innych serwerach fizycznych w razie awarii serwera fizycznego.
18. Rozwiązanie powinno umożliwiać łatwe i szybkie ponowne uruchomienie systemów/usług w przypadku
awarii poszczególnych elementów infrastruktury.
19. Rozwiązanie musi zapewniać mechanizm bezpiecznego uaktualniania warstwy wirtualizacyjnej,
hostowanych systemów operacyjnych (np. wgrywania patch-y) i aplikacji tak aby zminimalizować ryzyko
awarii systemu na skutek wprowadzenia zamiany.
20. Rozwiązanie musi zapewnić możliwość szybkiego wykonywania kopii zapasowych oraz odtwarzania
maszyn wirtualnych. Proces ten nie powinien mieć wpływu na utylizację zasobów fizycznych
infrastruktury wirtualnej.
Strona 79 z 106
II.2.3 Macierz dyskowa
Przedmiotem zamówienia jest wdrożenie systemu dyskowego 100TB dostępnego dla systemów umieszczonych
lokalnie w siedzibie Zamawiającego Dopuszcza się rozwiązania dedykowane do działania w chmurze danych
opisanej w OPZ jak i również rozwiązania chmury hybrydowej, gdzie system pamięci masowej jest umieszczony
w serwerowni Zamawiającego, ale udostępniony poprzez tunel VPN Centrum Danych do chmury obliczeniowej.
W takim wypadku chmura hybrydowa zostanie podzielona na obszar chmury obliczeniowej i warstwy danych.
Komponent dyskowy macierzy – 1 komplet
Element Parametry minimalne
Typ obudowy Macierz musi być przystosowana do montażu w szafie rack 19”.
Przestrzeń dyskowa
Macierz musi być wyposażona w minimum 7 dysków NL SAS 12G o pojemności
minimum 14TB oraz 5 dysków SSD 12G o pojemności minimum 1,92TB.
Możliwość rozbudowy Macierz musi umożliwiać rozbudowę (bez wymiany kontrolerów macierzy), do co
najmniej 190 dysków twardych.
Obsługa dysków Macierz musi obsługiwać dyski SSD, SAS i NL SAS. Macierz musi umożliwiać
mieszanie napędów dyskowych SSD, SAS i NL SAS w obrębie pojedynczej półki
dyskowej. Macierz musi obsługiwać dyski 2,5” jak również 3,5”.
Sposób zabezpieczenia
danych
Macierz musi obsługiwać mechanizmy RAID zgodne z RAID1, RAID10, RAID5 lub
RAID50 oraz RAID6 realizowane sprzętowo za pomocą dedykowanego układu,
z możliwością dowolnej ich kombinacji w obrębie oferowanej macierzy
i z wykorzystaniem wszystkich dysków twardych (tzw. wide-striping).
Macierz musi umożliwiać definiowanie globalnych dysków spare oraz dedykowanie
dysków spare do konkretnych grup RAID.
Tryb pracy kontrolerów
macierzowych
Macierz musi posiadać minimum 2 kontrolery macierzowe pracujące w trybie active-
active i udostępniające jednocześnie dane blokowe w sieci FC i iSCSI. Kontrolery muszą
komunikować się między sobą bez stosowania dodatkowych przełączników lub
koncentratorów FC i LAN.
Pamięć cache Każdy kontroler macierzowy musi być wyposażony w minimum 6 GB pamięci cache,
12 GB sumarycznie w macierzy. Pamięć cache musi być zbudowana w oparciu
o wydajną pamięć typu RAM.
Pamięć zapisu musi być mirrorowana (kopie lustrzane) pomiędzy kontrolerami
dyskowymi.
Dane niezapisane na dyskach (np. zawartość pamięci kontrolera) muszą zostać
zabezpieczone w przypadku awarii zasilania za pomocą podtrzymania bateryjnego lub z
zastosowaniem innej technologii przez okres minimum 5 lat.
Rozbudowa pamięci
cache
Macierz musi umożliwiać zwiększenie pojemności pamięci cache dla odczytów do
minimum 8 TB z wykorzystaniem dysków SSD lub kart pamięci flash.
Interfejsy Macierz musi posiadać co najmniej 4 porty FC 16Gb obsadzone wkładkami SFP+ SW
16 Gb/s oraz 4 porty iSCSI 10GbE obsadzone wkładkami SFP+ SR 10Gb/s. Macierz
powinna umożliwiać zamianę wkładek iSCSI na FC i odwrotnie, bez konieczności
wymiany całych kontrolerów.
Zarządzanie Zarządzanie macierzą musi być możliwe z poziomu interfejsu graficznego i interfejsu
znakowego. Zarządzanie macierzą musi odbywać się bezpośrednio na kontrolerach
macierzy z poziomu przeglądarki internetowej.
Zarządzanie grupami
dyskowymi oraz
dyskami logicznymi
Macierz musi umożliwiać zdefiniowanie, co najmniej 500 wolumenów logicznych
w ramach oferowanej macierzy dyskowej.
Musi istnieć możliwość rozłożenia pojedynczego wolumenu logicznego na wszystkie
dyski fizyczne macierzy (tzw. wide-striping), bez konieczności łączenia wielu różnych
dysków logicznych w jeden większy.
21. Rozwiązanie musi zapewniać pracę bez przestojów dla wybranych maszyn wirtualnych, niezależnie od
systemu operacyjnego oraz aplikacji, podczas awarii serwerów fizycznych, bez utraty danych i
dostępności danych podczas awarii serwerów fizycznych.
22. Rozwiązanie musi umożliwiać dodawanie i rozszerzanie dysków wirtualnych, procesorów i pamięci RAM
podczas pracy wybranych maszyn wirtualnych.
23. Rozwiązanie powinno zapewnić możliwość szybkiego tworzenia i uruchamiania nowych maszyn
wirtualnych wraz z ich pełną konfiguracją i preinstalowanymi narzędziami systemowymi w celu
efektywnej obsługi wymagań biznesowych.
Strona 80 z 106
Thin Provisioning Macierz musi umożliwiać udostępnianie zasobów dyskowych do serwerów w trybie
tradycyjnym, jak i w trybie typu Thin Provisioning.
Macierz musi umożliwiać odzyskiwanie przestrzeni dyskowych po usuniętych danych
w ramach wolumenów typu Thin. Proces odzyskiwania danych musi być automatyczny
bez konieczności uruchamiania dodatkowych procesów na kontrolerach macierzowych
(wymagana obsługa standardu T10 SCSI UNMAP).
Jeżeli do obsługi powyższych funkcjonalności wymagane są dodatkowe licencje, należy
je dostarczyć dla całej pojemności urządzenia.
Wewnętrzne kopie
migawkowe
Macierz musi umożliwiać dokonywania na żądanie tzw. migawkowej kopii danych
(snapshot, point-in-time) w ramach macierzy za pomocą wewnętrznych kontrolerów
macierzowych. Kopia migawkowa wykonuje się bez alokowania dodatkowej przestrzeni
dyskowej na potrzeby kopii. Zajmowanie dodatkowej przestrzeni dyskowej następuje
w momencie zmiany danych na dysku źródłowym lub na jego kopii.
Macierz musi wspierać minimum 512 kopii migawkowych.
Jeżeli do obsługi powyższych funkcjonalności wymagane są dodatkowe licencje, należy
je dostarczyć dla całej pojemności urządzenia.
Wewnętrzne kopie
pełne
Macierz musi umożliwiać dokonywanie na żądanie pełnej fizycznej kopii danych (clone)
w ramach macierzy za pomocą wewnętrznych kontrolerów macierzowych.
Jeżeli do obsługi powyższych funkcjonalności wymagane są dodatkowe licencje, należy
je dostarczyć dla całej pojemności urządzenia.
Migracja danych w
obrębie macierzy
Macierz dyskowa musi umożliwiać migrację danych bez przerywania do nich dostępu
pomiędzy różnymi warstwami technologii dyskowych na poziomie części wolumenów
logicznych (ang. Sub-LUN). Zmiany te muszą się odbywać wewnętrznymi
mechanizmami macierzy. Funkcjonalność musi umożliwiać zdefiniowanie zasobu LUN,
który fizycznie będzie znajdował się na min. 2 typach dysków obsługiwanych przez
macierz, a jego części będą realokowane na podstawie analizy ruchu w sposób
automatyczny i transparentny (bez przerywania dostępu do danych) dla korzystających
z tego wolumenu hostów. Zmiany te muszą się odbywać wewnętrznymi mechanizmami
macierzy. Jeżeli do obsługi powyższych funkcjonalności wymagane są dodatkowe
licencje, należy je dostarczyć dla całej pojemności urządzenia.
Zdalna replikacja
danych
Macierz musi umożliwiać asynchroniczną replikację danych do innej macierzy z tej
samej rodziny. Replikacja musi być wykonywana na poziomie kontrolerów, bez użycia
dodatkowych serwerów lub innych urządzeń i bez obciążania serwerów podłączonych
do macierzy.
Jeżeli do obsługi powyższych funkcjonalności wymagane są dodatkowe licencje, należy
je dostarczyć dla całej pojemności urządzenia.
Podłączanie
zewnętrznych
systemów
operacyjnych
Macierz musi umożliwiać jednoczesne podłączenie wielu serwerów w trybie wysokiej
dostępności (co najmniej dwoma ścieżkami).
Macierz musi wspierać podłączenie następujących systemów operacyjnych: Windows,
Linux, VMware.
Dla wymienionych systemów operacyjnych należy dostarczyć oprogramowanie do
przełączania ścieżek i równoważenia obciążenia poszczególnych ścieżek. Wymagane
jest oprogramowanie dla nielimitowanej liczby serwerów. Dopuszcza się rozwiązania
bazujące na natywnych możliwościach systemów operacyjnych.
Jeżeli do obsługi powyższych funkcjonalności wymagane są dodatkowe licencje, należy
je dostarczyć dla maksymalnej liczby serwerów obsługiwanych przez oferowane
urządzenie.
Redundancja
Macierz nie może posiadać pojedynczego punktu awarii, który powodowałby brak
dostępu do danych. Musi być zapewniona pełna redundancja komponentów,
w szczególności zdublowanie: kontrolerów, zasilaczy i wentylatorów.
Macierz musi umożliwiać wymianę elementów systemu w trybie „hot-swap”,
a w szczególności takich, jak: dyski, kontrolery, zasilacze, wentylatory.
Macierz musi mieć możliwość zasilania z dwu niezależnych źródeł zasilania –
odporność na zanik zasilania jednej fazy lub awarię jednego z zasilaczy macierzy.
Dodatkowe wymagania Oferowany system dyskowy musi się składać z pojedynczej macierzy dyskowej.
Niedopuszczalna jest realizacja zamówienia poprzez dostarczenie wielu macierzy
dyskowych. Za pojedynczą macierz nie uznaje się rozwiązania opartego o wiele
macierzy dyskowych (par kontrolerów macierzowych) połączonych przełącznikami
SAN lub tzw. wirtualizatorem sieci SAN czy wirtualizatorem macierzy dyskowych.
Gwarancja Gwarancja producenta minimum 36 miesiące w trybie proaktywnym 24/7. W przypadku
gwarancyjnej wymiany dysków, uszkodzone nośniki pozostają u Zamawiającego.
Serwis realizowany przez polski oddział serwisu producenta.
W okresie gwarancji Zamawiający ma prawo do otrzymywania poprawek oraz
aktualizacji wersji oprogramowania dostarczonego wraz z macierzą oraz
Strona 81 z 106
oprogramowania wewnętrznego macierzy. Wymagany jest nieodpłatny dostęp do
aktualizacji po ustaniu gwarancji.
II.2.4 Długopisy cyfrowe (System Digitalizacji danych
z pisma ręcznego)
Wymagane dostarczenie i skonfigurowanie do pracy z SSI 130 szt. urządzeń przetwarzających pismo odręczne
pacjentów do formularzy SSI, spełniających minimum wymagania dla systemu je obsługującego:
Lp. Wymaganie
1. Rozwiązanie powinno być systemem digitalizacji danych, który umożliwia utrwalenie w formie elektronicznej
tekstu pisanego na papierze.
2. Tworzenie znaczników czasu oraz umożliwiających określenie identyfikatora długopisu lub osoby, która się nim
posługiwała.
3. System umożliwia przechowywanie i automatyczne katalogowanie sporządzanych dokumentów.
4. System pozwala wyszukać konkretny dokument na podstawie czasu jego sporządzenia, danych osobowych
Klienta, osoby, która była za dokument odpowiedzialna lub za pomocą hasłowych danych z dokumentu
5. Możliwość naniesienia w systemie wymaganych zmian w dokumencie już istniejącym.
6. Licencja bezterminowa.
7. Przygotowanie i zaimplementowanie w systemie 400 dokumentów wskazanych przez Zamawiającego na etapie
Analizy Przedwdrożeniowej.
8. System umożliwia automatyczne powiązanie z rodzajem formularza, który został z jego pomocą wypełniony.
9. System umożliwia stworzenie dowolnego formularza bazując na dowolnym dokumencie w formacie PDF.
10. System umożliwia w importowanej ankiecie zaznaczenie regionów aktywnych, pól tekstowych oraz nadanie im
unikalnych nazw.
11. System umożliwia wydruk formularza w ten sposób, aby każdy wydrukowany formularz był unikalny (na
zasadzie druku ścisłego zarachowania). Oznacza to, że wypełnienie papierowego formularza długopisem
cyfrowym tworzy wzajemnie jednoznacznie przyporządkowaną do niego wersje elektroniczną dokumentu.
Formularzy nie można kserować (skserowane formularz nie działają, a długopis sygnalizuje to). Funkcjonalność
ta powinna być zrealizowana poprzez zapewnienie na każdym dokumencie unikalnego mikrodruku.
12. System umożliwia pobranie danych z długopisów cyfrowych za pomocą stacji dokującej USB bądź też
komunikacji bezprzewodowej bluetooth. Dane są jednoznacznie przyporządkowywane do formularzy.
13. System umożliwia przeglądanie oraz eksport nieprzetworzonych danych z wypełnionych formularzy do formatu
PDF będącego wizualizacją „skanów” wypełnionych dokumentów.
14. System umożliwia automatyczne rozpoznawanie zawartości pól tekstowych i pól numerycznych zarówno
w obszarze pisma blokowego jak i pisma ciągłego (oprogramowanie typu ICR).
15. System umożliwia edycję i walidację przetworzonych danych zwizualizowanych na formularzu z pól tekstowych
i pól numerycznych przy jednoczesnym podglądzie danych pochodzących bezpośrednio z urządzeń.
16. System umożliwia eksport rozpoznanych danych (tj. pól tekstowych liczb i pól wyboru) do formatów MS Excel
oraz plików CSV lub XML.
17. System umożliwia wypełnianie formularzy stworzonych w Systemie w trybie on-line, tj. korzystając z urządzeń
przenośnych typu tablet.
18. Aplikacja końcowa umożliwia podgląd stanu podłączonych do komputera długopisów cyfrowych oraz tabletów.
19. System umożliwia nadawanie długopisom i tabletom unikalnych nazw i przypisywania ich do użytkowników i
stanowisk.
20. System umożliwia odtwarzanie całej historii powstałego dokumentu z podziałem na czas w jakim dane elementy
powstały oraz autorów poszczególnych wpisów.
21. System umożliwia odwzorowanie (tak jakby został zeskanowany) formularza papierowego w wersji
elektronicznej lub formularza wypełnionego na tablecie.
22. System umożliwia automatyczne powiązanie z rodzajem formularza, który został z jego pomocą wypełniony.
23. System umożliwia stworzenie dowolnego formularza bazując na dowolnym dokumencie w formacie PDF.
24. System umożliwia w importowanej ankiecie zaznaczenie regionów aktywnych, pól tekstowych oraz nadanie im
unikalnych nazw.
Strona 82 z 106
25. System umożliwia wyświetlenie formularza do wypełnienia lub podpisu na urządzeniu typu tablet.
26. System umożliwia przeglądanie oraz eksport nieprzetworzonych danych z wypełnionych formularzy do formatu
PDF będącego wizualizacją „skanów” wypełnionych dokumentów.
27. System umożliwia automatyczne rozpoznawanie zawartości pól tekstowych i pól numerycznych zarówno
w obszarze pisma blokowego jak i pisma ciągłego (oprogramowanie typu ICR).
28. System umożliwia edycję i walidację przetworzonych danych zwizualizowanych na formularzu z pól tekstowych
i pól numerycznych przy jednoczesnym podglądzie danych pochodzących bezpośrednio z urządzeń.
29. System umożliwia eksport rozpoznanych danych (tj. pól tekstowych liczb i pól wyboru) do formatów MS Excel
oraz plików CSV lub XML.
Parametry techniczno-eksploatacyjne urządzeń:
30. Technologia druku: laserowa, rozdzielczość od 600 dpi, monochromatyczny lub kolorowy, formaty od A6 do
A0
31. Zasilanie - wbudowana bateria litowo-polimerowa, ładowanie przez złącze USB
32. Czas działania pomiędzy ładowaniami – co najmniej 9h
33. Możliwość działania w zakresie temperatur od 0-40 stopni Celsjusza
34. Pamięć na co najmniej 1000 wypełnionych dokumentów
35. Wbudowany zegar wewnętrzny synchronizowany automatycznie
36. Możliwość transmisji danych: złącze USB, Bluetooth LE
37. Obsługiwane systemy operacyjne: Windows 7/8/10
38. Dołączony program instalacyjny ze sterownikami umożliwiający zgrywanie danych i wysyłanie do centralnego
repozytorium danych
39. Długopis powinien umożliwiać wykorzystanie wkładu zgodnego z normami ISO. Do zestawu powinny być
dostarczone co najmniej 3 wkłady.
40. Wytrzymałość na upadek na dowolną powierzchnię z wysokości 1,5 m
41. Wymiary (szer. x gł. x wys.) max. 170 x 17 x 17 mm
42. Gwarancja: 24 miesięcy (z możliwością wydłużenia do 5 lat)
43. Serwis zgodny z wymaganiami normy ISO 9001
44. Certyfikat CE
45. Zabezpieczenie antykradzieżowe (linka mocująca)
Urządzenia muszą zostać zintegrowane i podłączone do infrastruktury Zamawiającego oraz systemu HIS.
Wykonawca ma dostarczyć wszystkie niezbędne elementy, podzespoły, licencje by rozwiązanie digitalizacyjne
stabilnie i wydajnie pracowało w infrastrukturze Zamawiającego. Wymagane jest dostarczenie licencji
umożliwiających nieograniczone w czasie użytkowanie w/w rozwiązania do digitalizacji.
Wykonawca przed wdrożeniem jest zobowiązany przeprowadzić audyt i analizę niezbędnych formularzy
rozpoznawanych przez system długopisów cyfrowych przed ich wdrożeniem w tym systemie. Liczba i zakres
formularzy musi zostać zaakceptowana przez Zamawiającego. Wzory formularzy będą przedstawione na etapie
analizy przedwdrożeniowej.
II.2.5 System operacyjny
Wykonawca jest zobowiązany na dostarczenie licencji dla systemów operacyjnych, na których zostaną
zainstalowane systemy chmurowe oraz systemy zwirtualizowane (min. AD), o parametrach minimalnych:
Wymagane minimalne parametry techniczne
Serwerowy system operacyjny (dalej: SSO) posiada następujące, wbudowane cechy.
1 Posiada możliwość wykorzystania 320 logicznych procesorów oraz min. 24 TB pamięci RAM w środowisku
fizycznym
2 Posiada możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB pamięci RAM i dysku o pojemności
64TB przez każdy wirtualny serwerowy system operacyjny.
Strona 83 z 106
3 Posiada możliwość budowania klastrów składających się z 64 węzłów, z możliwością uruchamiania do 8000
maszyn wirtualnych.
4 Posiada możliwość migracji maszyn wirtualnych bez zatrzymywania ich pracy między fizycznymi serwerami
z uruchomionym mechanizmem wirtualizacji (hypervisor) przez sieć Ethernet, bez konieczności stosowania
dodatkowych mechanizmów współdzielenia pamięci.
5 Posiada wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany pamięci RAM bez przerywania pracy.
6 Posiada wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany procesorów bez przerywania pracy.
7 Posiada automatyczną weryfikację cyfrowych sygnatur sterowników w celu sprawdzenia, czy sterownik przeszedł
testy jakości przeprowadzone przez producenta systemu operacyjnego.
8 Posiada możliwość dynamicznego obniżania poboru energii przez rdzenie procesorów niewykorzystywane
w bieżącej pracy. Mechanizm ten uwzględnia specyfikę procesorów wyposażonych w mechanizmy
Hyper-Threading.
9 Wbudowane wsparcie instalacji i pracy na wolumenach, które:
pozwalają na zmianę rozmiaru w czasie pracy systemu,
umożliwiają tworzenie w czasie pracy systemu migawek, dających użytkownikom końcowym (lokalnym
i sieciowym) prosty wgląd w poprzednie wersje plików i folderów,
umożliwiają kompresję "w locie" dla wybranych plików i/lub folderów,
umożliwiają zdefiniowanie list kontroli dostępu (ACL).
10 Posiada wbudowany mechanizm klasyfikowania i indeksowania plików (dokumentów) w oparciu o ich
zawartość.
11 Posiada wbudowane szyfrowanie dysków przy pomocy mechanizmów posiadających certyfikat FIPS 140-2 lub
równoważny wydany przez NIST lub inną agendę rządową zajmującą się bezpieczeństwem informacji.
12 Posiada możliwość uruchamianie aplikacji internetowych wykorzystujących technologię ASP.NET
13 Posiada możliwość dystrybucji ruchu sieciowego HTTP pomiędzy kilka serwerów.
14 Posiada wbudowaną zaporę internetowa (firewall) z obsługą definiowanych reguł dla ochrony połączeń
internetowych i intranetowych.
15 Graficzny interfejs użytkownika.
16 Zlokalizowane w języku polskim, następujące elementy: menu, przeglądarka internetowa, pomoc, komunikaty
systemowe,
17 Posiada wsparcie dla większości powszechnie używanych urządzeń peryferyjnych (drukarek, urządzeń
sieciowych, standardów USB, Plug&Play).
18 Posiada możliwość zdalnej konfiguracji, administrowania oraz aktualizowania systemu.
19 Dostępność bezpłatnych narzędzi producenta systemu umożliwiających badanie i wdrażanie zdefiniowanego
zestawu polityk bezpieczeństwa.
20 Pochodzący od producenta systemu serwis zarządzania polityką konsumpcji informacji w dokumentach (Digital
Rights Management).
21 Posiada możliwość implementacji następujących funkcjonalności bez potrzeby instalowania dodatkowych
produktów (oprogramowania) innych producentów wymagających dodatkowych licencji:
22 Podstawowe usługi sieciowe: DHCP oraz DNS wspierający DNSSEC,
23 Usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie użytkowników stacji roboczych, bez
konieczności instalowania dodatkowego oprogramowania na tych stacjach, pozwalające na zarządzanie zasobami
w sieci (użytkownicy, komputery, drukarki, udziały sieciowe), z możliwością wykorzystania następujących
funkcji:
Podłączenie SSO do domeny w trybie offline – bez dostępnego połączenia sieciowego z domeną,
Ustanawianie praw dostępu do zasobów domeny na bazie sposobu logowania użytkownika – na przykład
typu certyfikatu użytego do logowania,
Odzyskiwanie przypadkowo skasowanych obiektów usługi katalogowej z mechanizmu kosza.
Zdalna dystrybucja oprogramowania na stacje robocze.
Praca zdalna na serwerze z wykorzystaniem terminala (cienkiego klienta) lub odpowiednio
skonfigurowanej stacji roboczej
Centrum Certyfikatów (CA), obsługa klucza publicznego i prywatnego) umożliwiające:
Dystrybucję certyfikatów poprzez http
Konsolidację CA dla wielu lasów domeny,
Automatyczne rejestrowania certyfikatów pomiędzy różnymi lasami domen.
Szyfrowanie plików i folderów.
Szyfrowanie połączeń sieciowych pomiędzy serwerami oraz serwerami i stacjami roboczymi (IPSec).
Posiada możliwość tworzenia systemów wysokiej dostępności (klastry typu failover) oraz rozłożenia
obciążenia serwerów.
Serwis udostępniania stron WWW.
Wsparcie dla protokołu IP w wersji 6 (IPv6),
Strona 84 z 106
Wbudowane usługi VPN pozwalające na zestawienie nielimitowanej liczby równoczesnych połączeń
i niewymagające instalacji dodatkowego oprogramowania na komputerach z systemem Windows,
Wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na uruchamianie 1000 aktywnych
środowisk wirtualnych systemów operacyjnych. Wirtualne maszyny w trakcie pracy i bez zauważalnego
zmniejszenia ich dostępności mogą być przenoszone pomiędzy serwerami klastra typu failoverz
jednoczesnym zachowaniem pozostałej funkcjonalności. Mechanizmy wirtualizacji zapewniają wsparcie
dla:
Dynamicznego podłączania zasobów dyskowych typu hot-plug do maszyn wirtualnych,
Obsługi ramek typu jumbo frames dla maszyn wirtualnych.
Obsługi 4-KB sektorów dysków
Nielimitowanej liczby jednocześnie przenoszonych maszyn wirtualnych pomiędzy węzłami klastra.
Posiada możliwości wirtualizacji sieci z zastosowaniem przełącznika, którego funkcjonalność może być
rozszerzana jednocześnie poprzez oprogramowanie kilku innych dostawców poprzez otwarty interfejs
API.
Posiada możliwości kierowania ruchu sieciowego z wielu sieci VLAN bezpośrednio do pojedynczej
karty sieciowej maszyny wirtualnej (tzw. trunk model)
Posiada możliwość automatycznej aktualizacji w oparciu o poprawki publikowane przez producenta wraz
z dostępnością bezpłatnego rozwiązania producenta SSO umożliwiającego lokalną dystrybucję poprawek
zatwierdzonych przez administratora, bez połączenia z siecią Internet.
24 Wsparcie dostępu do zasobu dyskowego SSO poprzez wiele ścieżek (Multipath).
25 Posiada możliwość instalacji poprawek poprzez wgranie ich do obrazu instalacyjnego.
26 Posiada mechanizmy zdalnej administracji oraz mechanizmy (również działające zdalnie) administracji przez
skrypty.
27 Posiada możliwość zarządzania przez wbudowane mechanizmy zgodne ze standardami WBEM oraz WS-
Management organizacji DMTF.
Należy zainstalować wersję bazodanową tego systemu operacyjnego zgodną dla nowych (oferowanych) baz
danych.
II.2.6 Systemy bezpieczeństwa
1. System bezpieczeństwa typ 1 - Firewall Partnerzy Projektu – 6 sztuk
Dostarczenie po 1 szt. urządzenia do wskazanych lokalizacji wraz z instalacją:
1. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Cegłowie – Przychodnia Opieki Zdrowotnej
2. Samodzielny Publiczny Zakład Opieki Zdrowotnej w Kałuszynie–Przychodnia Opieki Zdrowotnej
3. Wiejski Ośrodek Zdrowia w Wyrozębach- Filia Przychodni Rejonowej w Sokołowie Podlaskim
4. Wiejski Ośrodek Zdrowia w Czerwonce – Filia Przychodni Rejonowej w Sokołowie Podlaskim
5. Wiejski Ośrodek Zdrowia w Skibniewie – Filia Przychodni Rejonowej w Sokołowie Podlaskim
6. Gminny Ośrodek Zdrowia w Repkach – Filia Przychodni Rejonowej w Sokołowie Podlaskim
Firewall - Partnerzy Projektu – 6 sztuk
Wymagane minimalne parametry techniczne
Dostarczony system bezpieczeństwa musi zapewniać wszystkie wymienione poniżej funkcje bezpieczeństwa oraz
funkcjonalności dodatkowe. Dopuszcza się, aby elementy wchodzące w skład systemu ochrony były zrealizowane w
postaci zamkniętej platformy sprzętowej lub w postaci komercyjnej aplikacji instalowanej na platformie ogólnego
przeznaczenia. W przypadku implementacji programowej dostawca musi zapewnić niezbędne platformy sprzętowe
wraz z odpowiednio zabezpieczonym systemem operacyjnym.
Dla elementów systemu bezpieczeństwa wykonawca musi zapewnić wszystkie poniższe funkcjonalności:
Elementy systemu przenoszące ruch użytkowników muszą dawać możliwość pracy w jednym z dwóch
trybów: Router/NAT lub transparent.
System musi dysponować minimum 8 interfejsami miedzianymi Ethernet 10/100/1000.
Możliwość tworzenia minimum 64 interfejsów wirtualnych definiowanych jako VLANy w oparciu
o standard 802.1Q.
Obsługa nie mniej niż 200 tys. jednoczesnych połączeń oraz 15 tys. nowych połączeń na sekundę.
System musi posiadać wbudowany w interfejs administracyjny system raportowania i przeglądania logów
zebranych na urządzeniu.
Strona 85 z 106
System powinien być wyposażony w lokalny dysk o pojemności minimum 64 GB lub pozwalać na zbieranie
logów na zewnętrznym dysku, pendrive lub karcie SD o pojemności co najmniej 64 GB do celów logowania
i raportowania.
W ramach dostarczonego systemu ochrony muszą być realizowane wszystkie z poniższych funkcjonalności:
o Kontrola dostępu - zapora ogniowa klasy Stateful Inspection
o Ochrona przed wirusami – antywirus [AV] (dla protokołów SMTP, POP3, HTTP, FTP, HTTPS).
System AV musi umożliwiać skanowanie AV dla plików typu: rar, zip.
o Poufność danych - IPSec VPN oraz SSL VPN
o Ochrona przed atakami - Intrusion Prevention System [IPS/IDS]
o Kontrola stron Internetowych – Web Filter [WF]
o Kontrola zawartości poczty – antyspam [AS] (dla protokołów SMTP, POP3)
o Kontrola pasma oraz ruchu [QoS i Traffic shaping]
o Kontrola aplikacji oraz rozpoznawanie ruchu P2P
o Analiza ruchu szyfrowanego protokołem SSL
Wydajność systemu minimum 3 Gbps
Wydajność skanowania strumienia danych przy włączonych funkcjach: Stateful Firewall, Antivirus minimum
200 Mbps
Wydajność ochrony przed atakami (IPS) minimum 2 Gbps
Wydajność VPN IPSec, nie mniej niż 450 Mbps
W zakresie realizowanych funkcjonalności VPN, wymagane jest nie mniej niż:
o Tworzenie połączeń w topologii Site-to-site oraz możliwość definiowania połączeń Client-to-site
o Producent oferowanego rozwiązania VPN powinien dostarczać klienta VPN współpracującego
z proponowanym rozwiązaniem
o Monitorowanie stanu tuneli VPN i stałego utrzymywania ich aktywności
o Praca w topologii Hub and Spoke oraz Mesh
o Obsługa mechanizmów: IPSec NAT Traversal, DPD, Xauth
o Obsługa ssl vpn w trybach portal oraz tunel
Rozwiązanie musi zapewniać: obsługę Policy Routingu, routing statyczny i dynamiczny w oparciu
o protokoły: RIPv2, OSPF, BGP.
Translacja adresów NAT adresu źródłowego i NAT adresu docelowego.
Polityka bezpieczeństwa systemu zabezpieczeń musi uwzględniać adresy IP, interfejsy, protokoły, usługi
sieciowe, użytkowników, reakcje zabezpieczeń, rejestrowanie zdarzeń oraz zarządzanie pasmem sieci (m.in.
pasmo gwarantowane i maksymalne, priorytety).
Możliwość tworzenia wydzielonych stref bezpieczeństwa Firewall np. DMZ.
Silnik antywirusowy musi umożliwiać skanowanie ruchu w obu kierunkach komunikacji dla protokołów
działających na niestandardowych portach (np. FTP na porcie 2021).
Ochrona IPS musi opierać się co najmniej na analizie protokołów i sygnatur. Baza wykrywanych ataków musi
zawierać co najmniej 1000 wpisów. Dodatkowo musi być możliwość wykrywania anomalii protokołów i
ruchu stanowiących podstawową ochronę przed atakami typu DoS oraz DDos.
Funkcja kontroli aplikacji musi umożliwiać kontrolę ruchu na podstawie głębokiej analizy pakietów, nie
bazując jedynie na wartościach portów TCP/UDP.
Baza filtra WWW pogrupowana w minimum 65 kategorii tematycznych. Administrator musi mieć możliwość
nadpisywania kategorii oraz tworzenia wyjątków i reguł omijania filtra WWW.
Automatyczne ściąganie sygnatur ataków, aplikacji, szczepionek antywirusowych oraz ciągły dostęp do
globalnej bazy zasilającej filtr URL.
System bezpieczeństwa musi posiadać moduł wykrywania typu oprogramowania sieciowego, które jest
uruchomione na stacjach roboczych w obrębie chronionej sieci i komunikuje się z siecią internet.
W przypadku kiedy system nie posiada wbudowanego modułu wykrywania typu oprogramowania sieciowego
musi być dostarczony zewnętrzny system w postaci dedykowanej, odpowiednio zabezpieczonej platformy
sprzętowej lub programowej.
o Moduł ma nie tylko wykrywać uruchomione oprogramowanie sieciowe, ale również wykrywać
i informować o lukach i podatnościach występujących w wykrytym oprogramowaniu przykładowo
poprzez opis wskazanej podatności lub oznaczenie ryzyka związanego z działaniem aplikacji za
pomocą skali lub kolorów
System zabezpieczeń musi umożliwiać wykonywanie uwierzytelniania tożsamości użytkowników za pomocą
nie mniej niż:
o Haseł statycznych i definicji użytkowników przechowywanych w lokalnej bazie systemu
o Haseł statycznych i definicji użytkowników przechowywanych w bazach zgodnych z LDAP
o Haseł dynamicznych (RADIUS) w oparciu o zewnętrzne bazy danych
o Rozwiązanie musi umożliwiać budowę architektury uwierzytelniania typu Single Sign On
w środowisku Active Directory bez konieczności instalowania jakiegokolwiek oprogramowania na
kontrolerze domeny
Strona 86 z 106
W zakresie realizowanych funkcjonalności systemu raportowania i przeglądania logów, wymagane jest nie
mniej niż:
o Posiadanie predefiniowanych raportów dla ruchu WWW, modułu IPS, skanera antywirusowego i
antyspamowego
o Generowanie co najmniej 25 różnych typów raportów
Element oferowanego systemu bezpieczeństwa realizujący zadanie Firewall musi posiadać certyfikat ICSA
lub EAL4+ dla rozwiązań kategorii Network Firewall.
Elementy systemu muszą mieć możliwość zarządzania lokalnego (HTTPS, SSH) jak i współpracować
z dedykowanymi platformami do centralnego zarządzania i monitorowania. Komunikacja systemów
zabezpieczeń z platformami zarządzania musi być realizowana z wykorzystaniem szyfrowanych protokołów.
Wymaga się, aby dostawa obejmowała również:
o Minimum 60-miesięczną gwarancję producentów na dostarczone elementy systemu liczoną od dnia
zakończenia wdrożenia całego systemu
o Licencje dla wszystkich funkcji bezpieczeństwa producentów na okres minimum 60 miesięcy
liczoną od dnia zakończenia wdrożenia całego systemu.
o Serwis producenta obejmujący wymianę wadliwego produktu na nowy (wysyłka nowego urządzenia
tego samego dnia roboczego, jeśli awaria urządzenia zostanie potwierdzona przed godziną 15:00)
2. System bezpieczeństwa typ 2 - Web Application Firewall - Centrum Danych – 1 sztuka
2. Web Application Firewall - Centrum Danych – 1 sztuka
Wymagane minimalne parametry techniczne
Funkcje systemu
1. Rozwiązanie ma obsługiwać ruch IPv4 oraz IPv6.
2. Rozwiązanie ma wspierać protokół HTTP/S 0.9/1.0/1.1
3. Rozwiązanie ma chronić przed listą 10 najbardziej krytycznych zagrożeń bezpieczeństwa opisanych
w OWASP top 10.
4. Rozwiązanie ma zapewniać ochronę przed:
a. SQL injection,
b. Cross-site scripting,
c. OS Command Injection,
d. Remote File Inclusion.
5. Rozwiązanie ma zapewniać ochronę przeciwko DDoS minimum w oparciu o mechanizmy takie jak:
a. autorska baza reputacji IP,
b. Geo IP,
c. blokowanie połączeń z Anonymous Proxy,
d. blokowanie połączeń z łączy satelitarnych,
e. blokowanie połączeń z sieci TOR,
f. CAPTCHA,
g. Slow client attack prevention
- max request timeout
- incremental request timeout
- max response timeout
- incremential response timeout
- data transfer ratek kB/s.
6. Rozwiązanie ma w pełni obsługiwać reverse Proxy, tak, aby cały ruch był przekierowywany na to
rozwiązanie.
7. Rozwiązanie ma w pełni obsługiwać tryb Bridge.
8. Rozwiązanie ma wspierać następujące możliwości blokowania – resetowanie połączenia, wysyłanie
przygotowanego komunikatu błędu, przekierowania żądania lub blokowania klientów IP przez określony
czas.
9. Rozwiązanie ma zapewniać funkcjonalność przepisania HTML. Ma zapewniać możliwość dodania, usunięcia
oraz edycji żądań oraz nagłówków odpowiedzi, tłumaczenia przestrzeni URL, nadpisania lub przekierowania
URL w żądaniu oraz nadpisania zawartości odpowiedzi.
10. Rozwiązanie ma pozwolić administratorowi na ograniczanie dostępu do używania różnych metod HTTP
wliczając w to HEAD, CONNECT, TRACE, itp.
11. Rozwiązanie ma umożliwiać stosowanie różnych polis restrykcji dla różnych części żądania. Restrykcje te
mają być możliwe do zastosowania na następujących poziomach - aplikacji, URL, parametrów
zapytań/FORM, nagłówków, ciasteczek oraz wskaźników żądań.
Strona 87 z 106
12. Rozwiązanie ma wspierać następujące metody normalizacji: dekodowanie URL (np. %XX, Null bytes string
termination, self-referring paths(/./), path back-references(/../) oraz dekodować jednostki HTML (np. c,
&quo;, ª)).
13. Rozwiązanie ma wspierać negatywny model bezpieczeństwa gdzie ataki są wykrywane poprzez wyrażenia
regularne pasujące do przychodzących żądań URL.
a. Rozwiązanie ma zapewniać możliwość definiowania wyrażeń regularnych dla wszystkich części
żądania – URL, parametrów, nagłówków, ciasteczek do wybierania przestrzeni URL, dla których
reguła ma być zastosowana. Np.: stosując regułę tylko dla tych żądań, dla których parametr user jest
obecny w URL lub parametr xyz=xxx lub Host Header = login.example.com lub User Agent zawiera
Mozilla itp.
b. Rozwiązanie ma pozwalać na konfigurowanie reguł ze złożoną logiką zawierającą operatory
logicznego AND, logicznego OR, exist, contains, equal itp. Np.: reguły Headers User-Agent contains
Mozilla OR URL contains /abc*html OR http-Version = 1.0 && Klient-IP is in 192.168.1.0/24.
14. Rozwiązanie ma wspierać pozytywny model bezpieczeństwa, który pozwala na dodanie określonych wartości
do białej listy w różnych elementach polityki bezpieczeństwa, podczas gdy wszystkie inne wartości są
zabronione. Przykładowo:
a. lista dozwolonych wartości dla parametrów FORM/zapytania (dozwolone typy danych, list, itp.),
b. lista dozwolonych metaznaków/słów kluczowych w URL, parametrach,
c. poprawny profil aplikacji – dozwolone URL oraz parametry dla każdego URL, z odrębnymi
profilami bezpieczeństwa dla obu,
d. dozwolone metody http dla każdego URL,
e. dozwolony typ zawartości dla URL,
f. dozwolone rozszerzenie wysyłanych plików.
15. Rozwiązanie ma umożliwić tworzenie polityk bezpieczeństwa w oparciu o profil uczenia.
16. Rozwiązanie ma posiadać wbudowaną funkcjonalność load balancing, która ma wspierać warstwę 7.
17. Rozwiązanie ma mieć możliwość routowania żądań zawartości różnych aplikacji do różnych serwerów
aplikacji. Na przykład ma istnieć możliwość routowania wszystkich żądań obrazów do jednego serwera oraz
wszystkich żądań przetwarzania skryptów do innego serwera.
18. Rozwiązanie ma umożliwiać dodanie wielu serwerów do obsługi konkretnego typu zawartości oraz load
balancing wewnętrznie pomiędzy nimi, niezależnie od nadrzędnej polityki load balancing.
19. Rozwiązanie ma umożliwiać cache’owania wybranych wychodzących odpowiedzi, tak aby kolejne żądanie
dla tej samej zawartości było bezpośrednio przekazywane od urządzenia zamiast być przesyłane do serwera.
20. Rozwiązanie ma umożliwić uruchomienie skanera AV dla pobieranych plików
21. Moduł uwierzytelniania ma mieć możliwość integracji z zewnętrzną usługą katalogowa taka jak LDAP,
Radius.
22. Rozwiązanie ma zapewniać mechanizm dwuskładnikowego uwierzytelniania.
23. Rozwiązanie ma umożliwiać ukrywanie „cloak” błędów odpowiedzi, aby ukryć wrażliwe informacje o
serwerze w zawartości i nagłówku odpowiedzi.
24. Rozwiązanie ma umożliwiać analizę zawartości odpowiedzi, niezależnie od kodu odpowiedzi, aby całkowicie
blokować odpowiedz lub wrażliwe wzorce danych cloak, jeśli takowe zostały znalezione. Wzorce kart
kredytowych mają być wyszukiwane domyślnie. Inne wzorce mają być określane w formacie wyrażeń
regularnych, najlepiej za pomocą odpowiedniego narzędzia.
25. Rozwiązanie ma posiadać możliwość definiowania różnych polityk dla różnych aplikacji oraz zapewniać
predefiniowane polityki dla popularnych aplikacji takich jak Outlook Web Access, SharePoint oraz Oracle
Financials.
26. Rozwiązanie ma pozwalać na wymuszanie następujących restrykcji protokołu dla żądań, oraz ma umożliwiać
określenie ich dla indywidualnych URL:
a. Max Request Length,
b. Max Request Line Length,
c. Max URL Length,
d. Max Number od Cookie,
e. Max Cookie Name Length,
f. Max Cookie Value,
g. Max Number of Headers,
h. Max Header name Length,
i. Max Header Value Length.
27. Rozwiązanie ma umożliwiać ochronę przeciwko clickjacking.
28. Rozwiązanie ma umożliwiać śledzenie sesji w oparciu o poniższe mechanizmy:
- ASP-DOT-NET-session,
- ColdFusion-session,
- J2EE-session,
- J2EE-JSESSIONID-Cookie-session,
- J2EE-JSESSIONID-URL-session,
- JWS-ID-session,
Strona 88 z 106
- PHPSESSID-session,
- PHPSESSIONID-session,
- PHP-BB-MYSQL-session,
- ASPSESSIONID-session,
- SAP-session.
29. Rozwiązanie ma chronić tokeny sesji, np. ciasteczka:
a. podpisuje ciasteczka, aby zapobiec ich zmianie przez klienta,
b. szyfruje ciasteczka, aby ukryć ich zawartość,
c. zapobiega atakom Cookie Replay,
d. zezwala na wyłączenie wybranych ciasteczek z sprawdzania ich pod kątem bezpieczeństwa.
30. Produkt ma zapewniać możliwość określania zaufanych hostów (identyfikowanych na podstawie adresu IP
lub ich zakresu), dla których będzie możliwe wykonanie czynności normalnie zabronionych.
31. Rozwiązanie ma umożliwiać zakończenie oraz odciążenie ruchu SSL (SSL Offloading).
32. Rozwiązanie ma mieć wbudowany skaner AV dla przesyłanych plików.
33. Rozwiązanie ma wspierać ochronę web serwisów XML z popularnymi aplikacjami web jak również ochronę
przed wyrafinowanymi atakami XML.
34. Rozwiązanie ma pozwalać na pracę w klastrze Active-Active.
35. Rozwiązanie ma zapewniać możliwość zarządzania wszystkimi urządzeniami za pomocą tego samego
interfejsu.
36. Rozwiązanie ma zapewnić monitoring ruch w oparciu o:
a. Logi WebFirewall,
b. Logi dostępu,
c. Logi audytu,
d. Logi systemowe.
37. Rozwiązanie ma mieć możliwość generowania wielopoziomowych raportów w ramach podstawowej licencji.
38. Raporty mogą być generowane na żądanie lub zgodnie z harmonogramem.
39. Rozwiązanie ma zapewniać wsparcie dla syslog i snmp.
40. Obudowa typu RACK o wysokości 2U
41. Minimalna liczba interfejsów sieciowych urządzenia to co najmniej 2 interfejsy 1 gigabit.
42. Przepustowość nie mniej niż: 1 Gbps.
43. Minimalna ilość transakcji http/s nie mniejsza niż 90000
44. Minimalna ilość transakcji https/s nie mniejsza niż 30000.
Serwis
1. Oferowane rozwiązanie musi być objęte minimum roczną licencją producenta uprawniającą do aktualizacji
mechanizmów bezpieczeństwa, wraz z możliwością odpłatnego przedłużenia licencji po jej wygaśnięciu na
kolejny okres minimum jednego roku.
2. Oferowane rozwiązanie musi być objęte roczną gwarancją producenta obejmującą naprawę sprzętu przez
producenta w terminie 14 dni, licząc od dnia dostarczenia sprzętu do magazynu producenta.
3. W czasie obowiązywania licencji Zamawiający ma prawo do wykonywania aktualizacji oprogramowania
(ang. firmware upgrade) na posiadanej przez siebie platformie sprzętowej.
4. W czasie obowiązywania licencji Zamawiający ma dostęp do wsparcia technicznego świadczonego zdalnie
w dni robocze, od poniedziałku do piątku w godzinach 8:00-18:00. Wsparcie techniczne świadczone jest w
języku polskim.
5. Zamawiający może zgłaszać sprawy z zakresu pomocy technicznej Dystrybutorowi kontaktując się poprzez
dedykowany adres email lub dedykowany numer infolinii.
6. W czasie obowiązywania licencji Zamawiający ma dostęp do wsparcia technicznego producenta,
świadczonego w języku angielskim w dni robocze od poniedziałku do piątku w godzinach 9:00-17:00.
Wsparcie techniczne producenta świadczone jest przez inżynierów wsparcia technicznego zatrudnionych w
oddziałach producenta w Europie.
7. Zamawiający może zgłaszać sprawy z zakresu pomocy technicznej Producentowi kontaktując się poprzez
dedykowany adres email lub dedykowany numer infolinii.
3. System bezpieczeństwa typ 3 - Database Firewall - Centrum Danych – 1 sztuka
3. Database Firewall - Centrum Danych – 1 sztuka
Wymagane minimalne parametry techniczne
1. System zapewnia narzędzia do tworzenia elektronicznej, interaktywnej dokumentacji systemu
teleinformatycznego, w tym schematów architektury zabezpieczeń sieci (tzn. mapy pokazującej urządzenia
zabezpieczeń, strefy bezpieczeństwa, zasoby IT, połączenia i topologię sieci), prezentującej informacje nt.
bezpieczeństwa w ujęciu technicznym oraz w odniesieniu do procesów działania organizacji.
Strona 89 z 106
2. System zapewnia narzędzia umożliwiające dokonanie oceny wpływu incydentu bezpieczeństwa IT na
działalność organizacji, m.in. po wpisaniu adresu IP zasobu IT związanego z incydentem bezpieczeństwa
system wyszukuje i prezentuje informacje nt. procesów organizacji i klasyfikowanych informacji (m.in.
danych osobowych), które mogły zostać naruszone w wyniku incydentu oraz wyświetla przewidywane istotne
dla organizacji konsekwencje naruszenia bezpieczeństwa.
3. System zapewnia narzędzia prezentujące techniczne informacje nt. bezpieczeństwa IT z perspektywy
działalności organizacji. Umożliwia zapisywanie, wyszukiwanie i prezentowanie co najmniej następujących
informacji: procesy działania organizacji, klasyfikacja zbiorów informacji, ważność zasobu IT dla
organizacji, właściciel zasobu IT oraz zespół obsługi.
4. System zapewnia narzędzia służące do ustalania wrażliwych zbiorów informacji, jakie są narażone
w razie incydentu bezpieczeństwa. Umożliwia definiowanie własnego schematu klasyfikacji danych
w organizacji (np. własność intelektualna, dane osobowe, dane finansowe) oraz umożliwia wyszukiwanie
lokalizacji zasobów IT, gdzie znajdują się dane określonej kategorii oraz wskazywać je na graficznej mapie
systemu teleinformatycznego.
5. System zapewnia narzędzia do modelowania zagrożeń umożliwiające symulowanie różnych potencjalnych
scenariuszy incydentów bezpieczeństwa IT. Dostępne są narzędzia działające na graficznej mapie systemu
teleinformatycznego służące do m.in.:
a. wyznaczania źródła zagrożenia zasobu IT wraz z wynikiem analizy ryzyka dla tego zagrożenia
wyliczanym w sposób automatyczny,
b. wyświetlania zabezpieczeń zasobu IT przed potencjalnymi źródłami zagrożenia,
c. wyświetlania zabezpieczeń chroniących zasoby IT przed określonym źródłem zagrożenia,
d. wyświetlania lokalizacji zasobów określonego rodzaju,
e. wyświetlania najbardziej narażonych zasobów IT,
f. wyświetlania ważnych zasobów IT narażonych na awarie.
6. System zapewnia graficzne narzędzia do definiowania wymagań bezpieczeństwa organizacji (m.in. środków
ochrony wymaganych dla określonych elementów i obszarów systemu teleinformatycznego) oraz narzędzia
do audytowania bezpieczeństwa względem tych wymagań. Narzędzia systemu umożliwiają m.in.:
a. zweryfikowanie, czy stan bezpieczeństwa systemu teleinformatycznego odpowiada specyficznym
wymaganiom organizacji,
b. wyznaczanie zasobów IT o wysokim poziomie ryzyka, które nie posiadają wymaganych
zabezpieczeń,
c. wskazywanie zasobów IT o krytycznym znaczeniu dla organizacji, które nie posiadają odpowiednich
zabezpieczeń
7. System zawiera narzędzia graficzne do tworzenia i przeszukiwania elektronicznej dokumentacji prezentujące
wyniki na schemacie mapy logicznej oraz fizycznej. Umożliwia rozbudowę elektronicznej dokumentacji o
nowe parametry oraz dołączane dokumenty, odnoszące się m.in. do stref bezpieczeństwa, systemów
zabezpieczeń, urządzeń fizycznych oraz zasobów informacyjno-usługowych.
8. System posiada możliwość wykrywania topologii sieci fizycznej oraz jej wizualizacji na podstawie
następujących protokołów sieciowych: SNMP v2 i v3, LLDP, CDP.
9. System posiada mechanizmy umożliwiające rozpoznanie systemów IT (Asset Discovery) oraz zapisuje
wyniki w module elektronicznej dokumentacji, zapewniając:
a. możliwość wykrywania zasobów oraz ich parametrów na podstawie wyników przynajmniej jednego
skanera podatności,
b. możliwość wykrywania zasobów oraz ich parametrów na podstawie wyników przynajmniej jednego
skanera sieciowego,
c. możliwość wykrywania zasobów oraz ich parametrów przy wykorzystaniu protokołu WMI,
d. możliwość wykrywania zasobów oraz ich parametrów przy wykorzystaniu skryptów SSH oraz
PowerShell,
e. możliwość wykrywania zasobów oraz ich parametrów na podstawie interpretacji zdarzeń,
10. System posiada bazę wiedzy eksperckiej zawierającej wiedzę pozwalającą ocenić poprawność projektu
zabezpieczeń identyfikując efektywność zastosowanych mechanizmów sieciowych oraz lokalnych
w stosunku do potencjalnych wektorów ataków oraz w przypadku ich nie zastosowania zidentyfikować
ryzyka, które się z tym wiążą.
11. System zapewnia możliwość definiowania procesów organizacji oraz zależności od innych procesów,
a także zapewnić możliwość definiowania czasów ich aktywności (np. proces praca biurowa
w organizacji jest aktywny od poniedziałku do piątku od 7:30 do 15:05). Zależności są prezentowane w
postaci graficznej.
12. System posiada mechanizm definiowania dozwolonej komunikacji sieciowej dla każdego zasobu IT
zdefiniowanego w elektronicznej dokumentacji oraz prezentacji tych informacji w formie graficznej.
13. Elektroniczna dokumentacja zapisana w systemie umożliwia automatyczne wyszukiwanie pojedynczych
punktów awarii sieci i systemów IT (tzn. elementów bez redundancji), których uszkodzenie spowoduje
zablokowanie ważnych procesów organizacji.
Strona 90 z 106
14. System umożliwia automatyczne szacowanie ryzyka dla wszystkich systemów IT zdefiniowanych
w elektronicznej dokumentacji. Szacowanie ryzyka odbywa się względem zagrożeń natury informatycznej,
np. włamane, infekcja złośliwym programem, podsłuch sieciowy, awaria.
15. System w formie graficznej prezentuje podsumowanie aktualnego stanu bezpieczeństwa, m.in. procesy
organizacji zagrożone przez pojedyncze punkty awarii.
16. System zapewnia możliwość monitorowania aktywności stron internetowych, portów TCP, ICMP oraz
mapowanie czasów dostępności / niedostępności bezpośrednio na procesy biznesowe oraz procesy zależne.
W przypadku gdy system wykryje niedostępność monitorowanej usługi generuje alarm powiadamiając
jednoczenie właścicieli procesów biznesowych których procesy zależą w sposób pośredni lub bezpośredni od
tej usługi (np.: e-mail, SMS, komunikator).
17. System zapewnia parsowanie spływających do niego zdarzeń w następujących formatach:
a. SYSLOG;
b. Wiadomości e-mail;
c. Dziennika zdarzeń Windows (WEF – Windows Event Forwarding);
Przez parsowanie zdarzeń rozumie się proces analizy zdarzenia i rozkład na elementy składowe takie jak np.:
adres IP źródłowy, adres IP docelowy, data, czas, użytkownik, treść zdarzenia itp.
18. System posiada predefiniowany zestaw parserów zdarzeń
19. System zapewnia mechanizmy umożliwiające mu na pozyskanie zdarzeń z baz danych oraz plików płaskich;
20. System posiada wbudowany interfejs graficzny do tworzenia własnych parserów umożliwiający następujące
funkcjonalności:
a. Parsowanie warunkowe;
b. Parsowanie hierarchiczne;
c. Wzbogacanie zdarzeń o dodatkowe pola;
d. Mapowanie wartości;
e. Zastosowanie wyrażeń regularnych;
f. Wsparcie dla formatów JSON oraz XML;
g. Wykorzystanie gotowych praserów przy tworzeniu nowych;
h. Mechanizmy wyszukiwania w polach zdarzeń;
21. System zapewnia możliwość zbierania i przetwarzania informacji dotyczących przepływów sieciowych [ang.
Netflow].
22. System umożliwia analizę anomalii bazując na informacjach zbieranych z przepływów sieciowych (ang.
NetFlow), gdzie w zależności od zdefiniowanych reguł buduje dynamiczne linię trendów wykrywając
odchylenia związane z procentową zmianą poziomu transmisji.
23. System umożliwia zastosowanie filtrów pozwalających na analizę anomalii względem parametrów
zdefiniowanych w elektronicznej dokumentacji, takich jak rodzaj zasobu, strefa bezpieczeństwa, proces
biznesowy;
24. System odczytuje alarmy wysyłane z innych systemów w tym systemów zabezpieczeń, dla których na
podstawie informacji zawartych w elektronicznej dokumentacji automatycznie oszacowuje konsekwencje
incydentów bezpieczeństwa, m.in. jakie procesy organizacji mogą zostać zakłócone, jakie informacje
klasyfikowane mogą zostać skradzione przez przestępców.
25. System posiada mechanizm definiowania reguł analizy incydentów dla każdego odbieranego zdarzenia.
Reguły umożliwiają korelację informacji technicznych wyciągniętych ze zdarzenia przekazanego
z innych systemów (m.in. adres IP, kategoria, severity) z parametrami zdefiniowanymi w elektronicznej
dokumentacji (m.in. ważność zasobu, klasyfikowane informacje, procesy organizacji) oraz aktualnymi
incydentami bezpieczeństwa.
26. System umożliwia detekcję anomalii poprzez osiągnięcie określonej liczby punktów na danym zasobie
wyliczonych z sumy punktów wszystkich zdarzeń na nim występujących w określonym przedziale czasu. W
tym celu wynik działania reguł korelacyjnych jest oceniany w skali punktowej w odniesieniu do rodzaju
zasobu oraz jego parametrów. Przykładowo to samo zdarzenie będzie inaczej oceniane jeżeli będzie dotyczyło
komputera a inaczej jeżeli będzie miało miejsce na serwerze usług.
27. System pozwala na budowanie profili aktywności użytkowników oraz zasobów poprzez wielowartościowe
listy referencyjne przykładowo: nazwa użytkownika, aplikacja i adres docelowy oraz umożliwia
wykorzystywanie ich w regułach korelacyjnych.
28. Wykryte incydenty są priorytetyzowane w odniesieniu do ważności dla organizacji zasobów których
dotyczą (tzn. wspomaganych procesów, przetwarzanych informacji klasyfikowanych). System udostępnia
graficzny edytor pozwalający na dostosowanie reguł wyznaczania priorytetów obsługi względem
dowolnych parametrów zawartych w elektronicznej dokumentacji;
29. Dla zarejestrowanych incydentów system automatycznie wyznacza ścieżkę ataku i prezentuje ją
w formie graficznej na schemacie sieci. Ścieżka ataku pokazuje wszystkie urządzenia zabezpieczeń na
drodze pomiędzy sprawcą i ofiarą ataku.
30. System w razie wykrycia incydentów o poważnych konsekwencjach dla organizacji umożliwia
automatyczne powiadamianie o zdarzeniu wskazanych pracowników, m.in. za pomocą email i SMS.
31. System w formie graficznej prezentuje podsumowanie aktualnego stanu bezpieczeństwa, m.in. procesy
organizacji zagrożone przez incydenty bezpieczeństwa.
Strona 91 z 106
32. System udostępnia możliwość prezentacji danych w postaci tzw. „Dashboard” czyli dostosowuje zakres i
prezentacje danych do potrzeb administratora czy też zalogowanego użytkownika
33. Dla systemu zapewniony jest serwis gwarancyjny producenta przez okres 60 miesięcy, polegającym na
naprawie lub wymianie urządzenia w przypadku jego wadliwości (dotyczy platformy uruchomieniowej). W
ramach tego serwisu producent musi zapewniać również dostęp do aktualizacji oprogramowania oraz
wsparcie techniczne w trybie 8x5.
34. W ramach wdrożenie dostarczona zostanie licencja zapewniająca zbieranie informacji z co najmniej 250
urządzań lub systemów.
35. Oprogramowanie musi być dostarczone w modelu „na własność” tj. niewykupienie licencji wsparcia
technicznego dla rozwiązania nie spowoduje zablokowania funkcjonowania urządzenia a jedynie pozbawi
możliwości pobierania aktualizacji systemu.
36. W ramach wdrożenia dostarczona zostanie platforma uruchomieniowa spełniająca minimum poniższe
wymagania:
Moc obliczeniowa 20 rdzeni procesorowych platformy x86
Pamięc RAM: 96GB
Zasób dyskowy zabezpieczony RAID: 2TB
Redundantne zasilacze.
4 interfejsy 1Gbps RJ-45
2 interfejsy 10Gbps SFP+
Gwarancja producenta platformy na 5 lat.
System operacyjny umożliwiający instalacje 4 wirtualnych serwerów na platformie uruchomieniowej.
Licencja obejmująca wszystkie rdzenie platformy.
Licencja bazy danych na minimum 4 rdzenie nie wymagająca dodatkowych elementów licencyjnych do
działania.
Usługa powiadomień:
a) Konto pocztowe na serwerze SMTP do rozsyłania powiadomień e-mail
b) Modem GSM do rozsyłania powiadomień SMS lub
c) Konto w usłudze SMSApi (www.smsapi.pl).
4. System bezpieczeństwa typ 4 - Firewall - Centrum Danych – 1 sztuka
4. Firewall - Centrum Danych – 1 sztuka
Wymagane minimalne parametry techniczne
Dostarczony system bezpieczeństwa musi zapewniać wszystkie wymienione poniżej funkcje bezpieczeństwa oraz
funkcjonalności dodatkowe. Dla elementów systemu bezpieczeństwa wykonawca musi zapewnić wszystkie poniższe
funkcjonalności:
Możliwość budowania klastrów wysokiej dostępności HA przynajmniej w konfiguracji Active-Passive
Elementy systemu przenoszące ruch użytkowników muszą dawać możliwość pracy w jednym z dwóch
trybów: Router/NAT lub transparent.
System musi dysponować minimum 10 interfejsami miedzianymi Ethernet 1Gbps
System musi dysponować minimum 4 interfejsami optycznymi 10GbE (SFP+)
System musi umożliwiać rozszerzenie dostępnych interfejsów o minimum 2 interfejsy optyczne 40GbE
(QSFP+)
W zakresie Firewall’a obsługa nie mniej niż 5 000 000 jednoczesnych połączeń oraz 115 000 nowych
połączeń na sekundę.
System powinien być wyposażony w lokalny dysk SSD o pojemności minimum 240 GB do celów logowania
i raportowania.
System musi posiadać wbudowany w interfejs administracyjny system raportowania i przeglądania logów
zebranych na urządzeniu.
W ramach dostarczonego systemu ochrony muszą być realizowane wszystkie z poniższych funkcjonalności.
Poszczególne funkcjonalności systemu bezpieczeństwa mogą być realizowane w postaci osobnych platform
sprzętowych lub programowych:
o Kontrola dostępu - zapora ogniowa klasy Stateful Inspection
o Ochrona przed wirusami – antywirus [AV] (dla protokołów SMTP, POP3, HTTP, FTP, HTTPS).
System AV musi umożliwiać skanowanie AV dla plików typu: rar, zip.
o Poufność danych - IPSec VPN oraz SSL VPN
o Ochrona przed atakami - Intrusion Prevention System [IPS/IDS]
Strona 92 z 106
o Kontrola stron Internetowych – Web Filter [WF]
o Kontrola zawartości poczty – antyspam [AS] (dla protokołów SMTP, POP3)
o Kontrola pasma oraz ruchu [QoS i Traffic shaping]
o Kontrola aplikacji oraz rozpoznawanie ruchu P2P
o Analiza ruchu szyfrowanego protokołem SSL
Wydajność systemu Firewall minimum 55 Gbps
Wydajność skanowania strumienia danych przy włączonych funkcjach: Stateful Firewall, Antivirus minimum
4 Gbps
Wydajność ochrony przed atakami (IPS) minimum 25 Gbps
Wydajność VPN IPSec, nie mniej niż 8 Gbps
W zakresie realizowanych funkcjonalności VPN, wymagane jest nie mniej niż:
o Tworzenie połączeń w topologii Site-to-site oraz możliwość definiowania połączeń Client-to-site
o Producent oferowanego rozwiązania VPN powinien dostarczać klienta VPN współpracującego
z proponowanym rozwiązaniem
o Monitorowanie stanu tuneli VPN i stałego utrzymywania ich aktywności
o Praca w topologii Hub and Spoke oraz Mesh
o Obsługa mechanizmów: IPSec NAT Traversal, DPD, Xauth
o Obsługa ssl vpn w trybach portal oraz tunel
Rozwiązanie musi zapewniać: obsługę Policy Routingu, routing statyczny i dynamiczny w oparciu
o protokoły: RIPv2, OSPF, BGP.
Translacja adresów NAT adresu źródłowego i NAT adresu docelowego.
Polityka bezpieczeństwa systemu zabezpieczeń musi uwzględniać adresy IP, interfejsy, protokoły, usługi
sieciowe, użytkowników, reakcje zabezpieczeń, rejestrowanie zdarzeń oraz zarządzanie pasmem sieci (m.in.
pasmo gwarantowane i maksymalne, priorytety).
Możliwość tworzenia wydzielonych stref bezpieczeństwa Firewall np. DMZ.
Ochrona IPS musi opierać się co najmniej na analizie protokołów i sygnatur. Baza wykrywanych ataków musi
zawierać co najmniej 1000 wpisów. Dodatkowo musi być możliwość wykrywania anomalii protokołów i
ruchu stanowiących podstawową ochronę przed atakami typu DoS oraz DDos.
Funkcja kontroli aplikacji musi umożliwiać kontrolę ruchu na podstawie głębokiej analizy pakietów, nie
bazując jedynie na wartościach portów TCP/UDP.
Baza filtra WWW pogrupowana w minimum 65 kategorii tematycznych. Administrator musi mieć możliwość
nadpisywania kategorii oraz tworzenia wyjątków i reguł omijania filtra WWW.
Automatyczne ściąganie sygnatur ataków, aplikacji, szczepionek antywirusowych oraz ciągły dostęp do
globalnej bazy zasilającej filtr URL.
System bezpieczeństwa musi posiadać moduł wykrywania typu oprogramowania sieciowego, które jest
uruchomione na stacjach roboczych w obrębie chronionej sieci i komunikuje się z siecią internet.
W przypadku kiedy system nie posiada wbudowanego modułu wykrywania typu oprogramowania sieciowego
musi być dostarczony zewnętrzny system w postaci dedykowanej, odpowiednio zabezpieczonej platformy
sprzętowej lub programowej.
o Moduł ma nie tylko wykrywać uruchomione oprogramowanie sieciowe, ale również wykrywać
i informować o lukach i podatnościach występujących w wykrytym oprogramowaniu przykładowo
poprzez opis wskazanej podatności lub oznaczenie ryzyka związanego z działaniem aplikacji za
pomocą skali lub kolorów
System zabezpieczeń musi umożliwiać wykonywanie uwierzytelniania tożsamości użytkowników za pomocą
nie mniej niż:
o Haseł statycznych i definicji użytkowników przechowywanych w lokalnej bazie systemu
o Haseł statycznych i definicji użytkowników przechowywanych w bazach zgodnych z LDAP
o Haseł dynamicznych (RADIUS) w oparciu o zewnętrzne bazy danych
o Rozwiązanie musi umożliwiać budowę architektury uwierzytelniania typu Single Sign On
w środowisku Active Directory bez konieczności instalowania jakiegokolwiek oprogramowania na
kontrolerze domeny
W zakresie realizowanych funkcjonalności systemu raportowania i przeglądania logów, wymagane jest nie
mniej niż:
o Posiadanie predefiniowanych raportów dla ruchu WWW, modułu IPS, skanera antywirusowego
i antyspamowego
o Generowanie co najmniej 25 różnych typów raportów.
Element oferowanego systemu bezpieczeństwa realizujący zadanie Firewall musi posiadać certyfikat ICSA
lub EAL4+ dla rozwiązań kategorii Network Firewall.
Elementy systemu muszą mieć możliwość zarządzania lokalnego (HTTPS, SSH) jak i współpracować
z dedykowanymi platformami/oprogramowaniem do centralnego zarządzania i monitorowania. Komunikacja
systemów zabezpieczeń z platformami/oprogramowaniem zarządzania musi być realizowana z
wykorzystaniem szyfrowanych protokołów.
Wymaga się, aby dostawa obejmowała również:
Strona 93 z 106
o Minimum 60-miesięczną gwarancję producentów na dostarczone elementy systemu liczoną od dnia
zakończenia wdrożenia całego systemu. Licencje dla wszystkich funkcji bezpieczeństwa
producentów na okres minimum 60 miesięcy liczoną od dnia zakończenia wdrożenia całego systemu.
o Serwis producenta obejmujący wymianę wadliwego produktu na nowy (wysyłka nowego urządzenia
tego samego dnia roboczego jeśli awaria urządzenia zostanie potwierdzona przed godziną 15:00).
5. System bezpieczeństwa typ 5 - Firewall - Narodowy Instytut Onkologii – 1 sztuka
5. Firewall - Narodowy Instytut Onkologii – 1 sztuka
Wymagane minimalne parametry techniczne
Dostarczony system bezpieczeństwa musi zapewniać wszystkie wymienione poniżej funkcje bezpieczeństwa oraz
funkcjonalności dodatkowe. Dla elementów systemu bezpieczeństwa wykonawca musi zapewnić wszystkie poniższe
funkcjonalności:
Możliwość budowania klastrów wysokiej dostępności HA przynajmniej w konfiguracji Active-Passive
Elementy systemu przenoszące ruch użytkowników muszą dawać możliwość pracy w jednym z dwóch
trybów: Router/NAT lub transparent.
System musi dysponować minimum 10 interfejsami miedzianymi Ethernet 1Gbps
System musi dysponować minimum 4 interfejsami optycznymi 10GbE (SFP+)
System musi umożliwiać rozszerzenie dostępnych interfejsów o minimum 2 interfejsy optyczne 40GbE
(QSFP+)
W zakresie Firewall’a obsługa nie mniej niż 5 000 000 jednoczesnych połączeń oraz 115 000 nowych
połączeń na sekundę.
System powinien być wyposażony w lokalny dysk SSD o pojemności minimum 240 GB do celów logowania
i raportowania.
System musi posiadać wbudowany w interfejs administracyjny system raportowania i przeglądania logów
zebranych na urządzeniu.
W ramach dostarczonego systemu ochrony muszą być realizowane wszystkie z poniższych funkcjonalności.
Poszczególne funkcjonalności systemu bezpieczeństwa mogą być realizowane w postaci osobnych platform
sprzętowych lub programowych:
o Kontrola dostępu - zapora ogniowa klasy Stateful Inspection
o Ochrona przed wirusami – antywirus [AV] (dla protokołów SMTP, POP3, HTTP, FTP, HTTPS).
System AV musi umożliwiać skanowanie AV dla plików typu: rar, zip.
o Poufność danych - IPSec VPN oraz SSL VPN
o Ochrona przed atakami - Intrusion Prevention System [IPS/IDS]
o Kontrola stron Internetowych – Web Filter [WF]
o Kontrola zawartości poczty – antyspam [AS] (dla protokołów SMTP, POP3)
o Kontrola pasma oraz ruchu [QoS i Traffic shaping]
o Kontrola aplikacji oraz rozpoznawanie ruchu P2P
o Analiza ruchu szyfrowanego protokołem SSL
Wydajność systemu Firewall minimum 55 Gbps
Wydajność skanowania strumienia danych przy włączonych funkcjach: Stateful Firewall, Antivirus minimum
4 Gbps
Wydajność ochrony przed atakami (IPS) minimum 25 Gbps
Wydajność VPN IPSec, nie mniej niż 8 Gbps
W zakresie realizowanych funkcjonalności VPN, wymagane jest nie mniej niż:
o Tworzenie połączeń w topologii Site-to-site oraz możliwość definiowania połączeń Client-to-site
o Producent oferowanego rozwiązania VPN powinien dostarczać klienta VPN współpracującego
z proponowanym rozwiązaniem
o Monitorowanie stanu tuneli VPN i stałego utrzymywania ich aktywności
o Praca w topologii Hub and Spoke oraz Mesh
o Obsługa mechanizmów: IPSec NAT Traversal, DPD, Xauth
o Obsługa ssl vpn w trybach portal oraz tunel
Rozwiązanie musi zapewniać: obsługę Policy Routingu, routing statyczny i dynamiczny w oparciu
o protokoły: RIPv2, OSPF, BGP.
Translacja adresów NAT adresu źródłowego i NAT adresu docelowego.
Polityka bezpieczeństwa systemu zabezpieczeń musi uwzględniać: adresy IP, interfejsy, protokoły, usługi
sieciowe, użytkowników, reakcje zabezpieczeń, rejestrowanie zdarzeń oraz zarządzanie pasmem sieci (m.in.
pasmo gwarantowane i maksymalne, priorytety).
Możliwość tworzenia wydzielonych stref bezpieczeństwa Firewall np. DMZ.
Strona 94 z 106
Ochrona IPS musi opierać się co najmniej na analizie protokołów i sygnatur. Baza wykrywanych ataków musi
zawierać co najmniej 1000 wpisów. Dodatkowo musi być możliwość wykrywania anomalii protokołów i
ruchu stanowiących podstawową ochronę przed atakami typu DoS oraz DDos.
Funkcja kontroli aplikacji musi umożliwiać kontrolę ruchu na podstawie głębokiej analizy pakietów, nie
bazując jedynie na wartościach portów TCP/UDP.
Baza filtra WWW pogrupowana w minimum 65 kategorii tematycznych. Administrator musi mieć możliwość
nadpisywania kategorii oraz tworzenia wyjątków i reguł omijania filtra WWW.
Automatyczne ściąganie sygnatur ataków, aplikacji, szczepionek antywirusowych oraz ciągły dostęp do
globalnej bazy zasilającej filtr URL.
System bezpieczeństwa musi posiadać moduł wykrywania typu oprogramowania sieciowego, które jest
uruchomione na stacjach roboczych w obrębie chronionej sieci i komunikuje się z siecią internet.
W przypadku kiedy system nie posiada wbudowanego modułu wykrywania typu oprogramowania sieciowego
musi być dostarczony zewnętrzny system w postaci dedykowanej, odpowiednio zabezpieczonej platformy
sprzętowej lub programowej.
o Moduł ma nie tylko wykrywać uruchomione oprogramowanie sieciowe, ale również wykrywać
i informować o lukach i podatnościach występujących w wykrytym oprogramowaniu przykładowo
poprzez opis wskazanej podatności lub oznaczenie ryzyka związanego z działaniem aplikacji za
pomocą skali lub kolorów.
System zabezpieczeń musi umożliwiać wykonywanie uwierzytelniania tożsamości użytkowników za pomocą
nie mniej niż:
o Haseł statycznych i definicji użytkowników przechowywanych w lokalnej bazie systemu
o Haseł statycznych i definicji użytkowników przechowywanych w bazach zgodnych z LDAP
o Haseł dynamicznych (RADIUS) w oparciu o zewnętrzne bazy danych
o Rozwiązanie musi umożliwiać budowę architektury uwierzytelniania typu Single Sign On
w środowisku Active Directory bez konieczności instalowania jakiegokolwiek oprogramowania na
kontrolerze domeny.
W zakresie realizowanych funkcjonalności systemu raportowania i przeglądania logów, wymagane jest nie
mniej niż:
o Posiadanie predefiniowanych raportów dla ruchu WWW, modułu IPS, skanera antywirusowego
i antyspamowego
o Generowanie co najmniej 25 różnych typów raportów
Element oferowanego systemu bezpieczeństwa realizujący zadanie Firewall musi posiadać certyfikat ICSA
lub EAL4+ dla rozwiązań kategorii Network Firewall.
Elementy systemu muszą mieć możliwość zarządzania lokalnego (HTTPS, SSH) jak i współpracować
z dedykowanymi platformami/oprogramowaniem do centralnego zarządzania i monitorowania. Komunikacja
systemów zabezpieczeń z platformami/oprogramowaniem zarządzania musi być realizowana z
wykorzystaniem szyfrowanych protokołów.
Wymaga się, aby dostawa obejmowała również:
o Minimum 60-miesięczną gwarancję producentów na dostarczone elementy systemu liczoną od dnia
zakończenia wdrożenia całego systemu. Licencje dla wszystkich funkcji bezpieczeństwa
producentów na okres minimum 60 miesięcy liczoną od dnia zakończenia wdrożenia całego systemu.
o Serwis producenta obejmujący wymianę wadliwego produktu na nowy (wysyłka nowego
urządzenia tego samego dnia roboczego jeśli awaria urządzenia zostanie potwierdzona przed godziną
15:00).
4.9.1. Opis wymagań dotyczących usług dla urządzeń bezpieczeństwa.
System bezpieczeństwa typ 1:
W ramach realizacji projektu uczestniczyć będzie 6 zakładów opieki zdrowotnej świadczące usługi na obszarach
wiejskich w ramach publicznego systemu ochrony zdrowia.
Każdy z Partnerów posiada określoną liczbę komputerów stacjonarnych oraz dostęp do sieci Internet:
Samodzielny Publiczny Zakład Opieki Zdrowotnej w Cegłowie – 7 obecnie +10 w postępowaniu na zakup sprzętu -
łącznie 17.
Samodzielny Publiczny Zakład Opieki Zdrowotnej w Kałuszynie- 12 obecnie + 17 w postępowaniu na zakup sprzętu
– łącznie 21.
Samodzielny Publiczny Zakład Opieki Zdrowotnej w Sokołowie Podlaskim – 40 obecnie + w postępowaniu na zakup
sprzętu 13 - łącznie 53.
. Należy wykonać prekonfigurację rozwiązania w oparciu o informację dotyczącą konfiguracji interfejsów
WAN/LAN.
Jeżeli jest taka potrzeba to należy wskazać jakie ustawienia zastosować dla Partnera sieci LAN aby móc zestawić
połączenie IPSEC VPN z Chmurą na potrzeby świadczenia wdrażanych w ramach projektu e-usług.
Strona 95 z 106
W ramach prekonfiguracji rozwiązania u Partnerów należy ustawić:
filtrowanie ruchu sieciowego pod kątem antywirusowym,
ochrona przed włamaniami do sieci wewnętrznej (IPS),
przygotowanie konfiguracji dla bezpiecznych szyfrowanych połączeń za pomocą IPSEC VPN na
urządzeniach bezpieczeństwa dostarczonych dla każdego z Partnerów w ramach projektu z wynajętym
centrum danych - VPN z Chmurą
przygotowanie tunelu IPSEC VPN z Narodowego Instytutu Onkologii im. Marii Skłodowskiej-Curie –
Państwowego Instytutu Badawczego w Warszawie.
System bezpieczeństwa typ 2
1) Weryfikacja i konfiguracja obiektów sieci web podlegających ochronie systemu.
2) Weryfikacja ruchu sieciowego pomiędzy urządzeniami systemu (load balancing, proxy).
3) Wybór trybu pracy urządzenia
4) Podstawowa konfiguracja i zarządzanie: Rejestracja urządzenia, konto suportowe, ustawienia systemowe.
5) Konfiguracja interfejsów sieciowych
6) Konfiguracja routingu
7) Tworzenie polityk bezpieczeństwa
8) Konfiguracja polityk dla ochrony ruchu do aplikacji Web’owych.
9) Konfiguracja i przypisywanie sygnatur dla ochrony stron Web’owych.
10) Modyfikacja sygnatur (włączanie/wyłączanie).
11) Konfiguracja i przypisywanie polityk dla ochrony stron Web’owych.
12) Konfiguracja ochrony DDOS
13) Konfiguracja serwisu reputacyjnego
14) Tworzenie reguł ograniczających dostęp na podstawie geolokacji adresacji IP.
15) Przegląd poprawności wyświetlania zdarzeń i monitoringu,
16) Eliminacji wyświetlania nadmiarowych zdarzeń i fałszywych alarmów.
17) Sprawdzenie poziomu ruchu, obciążenia procesora, zdarzeń.
System bezpieczeństwa typ 3
1. Zestawienie i konfigurację reguł korelacji SIEM i analizy behawioralnej użytkowników i systemów
2. Zestawienie i konfigurację reguł korelacji zdarzeń automatycznie dostosowujących się do zmian sieci
i systemów wykrywanych za pomocą funkcji Auto-Discovery
3. Zestawienie i konfigurację analizy logów w SIEM w kontekście wystąpienia ryzyka dla procesów organizacji
i wrażliwych informacji
4. Zestawienie i konfigurację analizy zdarzeń bezpieczeństwa (logi), aktualnych podatności, informacji Threat
Intelligence oraz oszacowane wielkości ryzyka
5. Konfigurację bazy plikowej do długoterminowego składowania i szybkiego wyszukiwania zdarzeń
bezpieczeństwa Zestawienie i konfigurację
6. Zestawienie i konfigurację przesyłania informacji z wykorzystaniem Syslog, e-mail, Windows Event
Forwarding, a także umożliwienie odczytu logów z baz danych oraz plików płaskich.
System bezpieczeństwa typ 4 i 5
1) Wdrożenie w Narodowym Instytucie Onkologiit im. Marii Skłodowskiej – Curie – Państwowym Instytucie
Badawczym w Warszawie oraz u Partnerów przeprowadzone przez certyfikowanego inżyniera oferowanego
rozwiązania.
2) Urządzenie na brzegu sieci wewnętrznej będzie pełnił funkcję pierwszej linii ochrony systemu danych przed
niepowołanym dostępem z zewnątrz.
3) Wykonawca dokona instalacji fizycznej. Wykonawca skonsultuje koncepcję wdrożenia nowego rozwiązania,
zakładając, że jest już istniejące urządzenie.
4) Należy zapoznać się z konfiguracją interfejsów LAN/WAN/DMZ/VLAN, a także z istniejącymi politykami
bezpieczeństwa i zaproponować konfigurację tak, aby nowe urządzenie firewall realizowało kluczowe
funkcje bezpieczeństwa takie jak:
filtrowanie ruchu sieciowego pod kątem antywirusowym,
ochrona przed włamaniami do sieci wewnętrznej (IPS),
ochrona przed oprogramowaniem szpiegującym,
kontrola aplikacji uruchamianych przez użytkowników, które wykorzystują połączenia z siecią Internet,
filtrowanie odwiedzanych stron www, wykluczających zawierające zagrożenia oraz wybrane przez
administratora na podstawie przygotowanych przez producenta kategorii,
Strona 96 z 106
zestawienie tunelu IPSEC VPN z Chmurą, oraz przekazanie informacji dotyczącej konfiguracji dla tunelu
IPSEC VPN dla Partnerów.
5) Wdrożenie przeprowadzone przez certyfikowanego inżyniera oferowanego firewalla E-usługi, który
docelowo znajdzie się w chmurze obliczeniowej.
6) Firewall na brzegu sieci będzie pełnił funkcję pierwszej linii ochrony systemu danych przed niepowołanym
dostępem z zewnątrz. Urządzenie będzie realizowało kluczowe funkcje bezpieczeństwa takie jak:
ochrona przed włamaniami do sieci wewnętrznej (IPS),
kontrola urządzeń podłączonych do sieci wewnętrznej, przydzielanie odpowiednich uprawnień
i dostępów na podstawie założonych reguł,
zestawienie tunelu IPSEC VPN, oraz przygotowanie konfiguracji dla tunelu IPSEC VPN dla Partnerów.
Instruktaże
Należy przeprowadzić dwudniowe instruktaże dla administratora bezpieczeństwa Narodowego Instytutu Onkologii im.
Marii Skłodowskiej-Curie – Państwowego Instytutu Badawczego w Warszawie i Partnerów projektu przeprowadzone
przez certyfikowanego inżyniera producenta dostarczonego rozwiązania.
II.2.7 Cloud-computing, koszty utrzymania, w tym
zapewnienie dostępu do sieci Internet dla Cloud-
Computing
Wykonawca jest zobowiązany skonfigurować i zapewnić w okresie 27 miesięcy dostęp do zasobów chmurowych
poprzez sieć Internet oraz wykupić transfer danych minimum 100TB.
Wykonawca w ramach postępowania musi zapewnić możliwość skorzystania z usług przez okres 5 lat po
zakończeniu projektu.
Wykonawca musi dostarczyć usługę wynajmu mocy obliczeniowej dla wdrażanych systemów spełniającą
następujące wymagania:
Lp. Wymagania dotyczące bezpieczeństwa
1. Cloud-computing musi spełniać następujące normy bezpieczeństwa:
PN-ISO/IEC 27001
PN-ISO/IEC 27018
Wymagania ogólne
1. standardowe SLA: 99,5%
2. zasilanie: 99,999%
3. dostęp do sieci Internet: 99,98%
4. obsługa i wsparcie techniczne: 24/7
5. serwerownia minimum Tier 3
6. bezpośrednie styki do 2-ch operatorów tier 1
7. peering do największych dostawców internetu
Styki mogą być realizowane za pomocą innych usług peeringu.
Wymagania funkcjonalne
2. Cloud-computing musi być realizowany w oparciu o powszechnie dostępną przez Internet platformę
polegającą na udostępnieniu skalowalnej platformy pozwalającej wykorzystać w formie usługi serwerowe
systemy operacyjne, silniki baz danych relacyjnych oraz inne aplikacje w środowiskach
zwirtualizowanych.
Usługa ta powinna się cechować następującymi parametrami:
1. Gwarantowana umownie dostępność usługi,
2. Możliwość skalowania usługi z przewidywalnymi kosztami takiego skalowania,
3. Automatyczna, nie wpływająca na ciągłość pracy systemu instalacja poprawek dla składników
usługi,
4. Dostępność na żądanie wyników aktualnych audytów, w tym audytów bezpieczeństwa, dla usług
i centrów przetwarzania danych oferujących te usługi,
5. Zobowiązanie umowne o pozostawieniu całkowitej własności przetwarzanych/składowanych
w usłudze danych po stronie Zamawiającego,
6. Dostępność mechanizmów monitorowania zachowań użytkowników usługi oraz prób dostępu
do przetwarzanych/składowanych w usłudze danych Zamawiającego,
Strona 97 z 106
7. Zawarcie w umowie na wykorzystanie zamawianej usługi tzw. Klauzul Umownych
opublikowanych przez Komisję Europejską w zakresie ochrony danych osobowych,
8. Możliwość zastrzeżenia miejsca przetwarzania/składowania danych w usłudze do terytorium
krajów Unii Europejskiej.
9. Dynamiczne zwiększanie i zmniejszanie zasobów sprzętowych bez przestoju w pracy
dotychczasowego środowiska.
10. Wdrożenie nowej wersji aplikacji bez przestoju w pracy dotychczasowego środowiska.
11. Automatyczna, niewpływająca na ciągłość pracy systemu instalacja poprawek udostępnianych
przez dostawcę systemu operacyjnego.
12. Możliwość zestawienia bezpiecznego (szyfrowanego) połączenia z lokalną infrastrukturą
sprzętową, pozwalającego na zachowanie jednolitej adresacji IP
13. Możliwość uruchomienia aplikacji internetowych wykorzystujących technologię ASP.NET
z automatyczną dystrybucją ruchu sieciowego HTTP pomiędzy kilka pracujących serwerów.
14. Zarządzanie za pomocą graficznego interfejsu użytkownika oraz skryptów z możliwością
zdalnego dostępu.
15. Możliwość przechowywania danych spełniająca następujące wymagania (opcjonalnie
dostępnych w ramach usługi):
a. Wysoka skalowalność, auto-partycjonowanie, load-balancing
b. Obsługa przechowywania danych udostępnianych jako blob, tablica, dysk, plik, kolejka
c. Wsparcie dla systemów klienckich Windows i Linux
d. Skalowalność pojedynczego zasobu pamięci 500TB
e. Replikacja danych - min. 3 kopie w ramach pojedynczej lokalizacji
f. Replikacja do innej lokalizacji oddalonej o min 25km od lokalizacji podstawowej
g. Udostępnienie zasobów pamięci poprzez REST API
Serwery w ramach usługi cloud-computing
W ramach postępowania należy dostarczyć serwery wirtualne na okres 27 miesięcy o parametrach podanych
poniżej:
Parametry minimalne serwerów dla potrzeb repozytorium elektronicznej dokumentacji medycznej:
2 serwery pracujące w klastrze HA, A-A lub A-P
1. Procesor v4Core 2 GHz
2. 16 GB RAM
3. 1 TB HDD
4. Konfiguracja high availability.
Parametry minimalne serwerów dla potrzeb e-usług:
2 serwery pracujące w klastrze HA A-A lub A-P:
1. Procesor v8Core 2 GHz
2. 32 GB RAM
3. 1 TB HDD
4. Konfiguracja high availability.
Zapewnienie ciągłości pracy systemów musi zostać oparte o wirtualizacje systemów operacyjnych dla serwerów
usługi cloud computing. W tym celu Wykonawca jest zobowiązany do zapewnienia na wynajętych serwerach
oprogramowania wirtualizacyjnego i operacyjnego o następujących minimalnych wymaganiach technicznych:
Nazwa komponentu Wymagane minimalne parametry techniczne
Oprogramowanie do
wirtualizacji
Wymaga się by użyte licencje umożliwiały uruchamianie wirtualizacji na użytych serwerach
oraz by była możliwość użycia konsoli do zarządzania całym środowiskiem.
Wszystkie użyte licencje powinny posiadać wsparcie producenta w okresie trwania
projektu, świadczonym przez producenta będącego licencjodawcą oprogramowania na
pierwszym, drugim i trzecim poziomie, które powinno umożliwiać zgłaszanie problemów 5
dni w tygodniu przez 8h na dobę.
Konsolidacja 1. Warstwa wirtualizacji musi być rozwiązaniem systemowym tzn. musi być
zainstalowana bezpośrednio na sprzęcie fizycznym.
2. Rozwiązanie musi zapewnić możliwość obsługi wielu instancji systemów
operacyjnych na jednym serwerze fizycznym.
3. Oprogramowanie do wirtualizacji musi zapewnić możliwość przydzielenia
maszynom wirtualnym do 96 procesorów wirtualnych.
4. Rozwiązanie musi umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe
usługi bez spadku wydajności i dostępności pozostałych wybranych usług.
Strona 98 z 106
5. Rozwiązanie musi w możliwie największym stopniu być niezależne od
producenta platformy sprzętowej.
6. Rozwiązanie musi wspierać następujące systemy operacyjne: Windows Server
2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012,
Windows Server 2012R2, SLES 11, SLES 10, SLES9, SLES8, Ubuntu 7.04,
RHEL 5, RHEL 4, RHEL3, RHEL 2.1, Solaris wersja 10 dla platformy x86,
NetWare 6.5, NetWare 6.0, NetWare 6.1, Debian, CentOS, FreeBSD, Asianux,
Ubuntu 7.04, SCO OpenServer, SCO Unixware, Mac OS X.
7. Rozwiązanie musi posiadać centralną konsolę graficzną do zarządzania
środowiskiem serwerów wirtualnych. Konsola graficzna musi być dostępna
poprzez dedykowanego klienta i za pomocą przeglądarek, minimum IE
i Firefox.
8. Dostęp przez przeglądarkę do konsoli graficznej musi być skalowalny
tj. powinien umożliwiać rozdzielenie komponentów na wiele instancji
w przypadku zapotrzebowania na dużą liczbę jednoczesnych dostępów
administracyjnych do środowiska.
9. Rozwiązanie musi zapewniać zdalny i lokalny dostęp administracyjny do
wszystkich serwerów fizycznych poprzez protokół SSH, z możliwością
nadawania uprawnień do takiego dostępu nazwanym użytkownikom bez
konieczności wykorzystania konta root.
10. Rozwiązanie musi umożliwiać składowanie logów ze wszystkich serwerów
fizycznych i konsoli zarządzającej na serwerze Syslog. Serwer Syslog
w dowolnej implementacji musi stanowić integralną część rozwiązania.
11. Rozwiązanie musi zapewnić możliwość monitorowania wykorzystania zasobów
fizycznych infrastruktury wirtualnej i zdefiniowania alertów informujących o
przekroczeniu wartości progowych.
12. Rozwiązanie musi umożliwiać integrację z rozwiązaniami antywirusowymi firm
trzecich w zakresie skanowania maszyn wirtualnych z poziomu warstwy
wirtualizacji.
13. Rozwiązanie musi zapewniać możliwość konfigurowania polityk separacji sieci
w warstwie trzeciej, tak aby zapewnić oddzielne grupy wzajemnej komunikacji
pomiędzy maszynami wirtualnymi.
14. Oprogramowanie do wirtualizacji musi zapewnić możliwość wykonywania
kopii zapasowych instancji systemów operacyjnych oraz ich odtworzenia w
możliwie najkrótszym czasie.
15. Kopie zapasowe muszą być składowane z wykorzystaniem technik de-duplikacji
danych.
16. Musi istnieć możliwość odtworzenia pojedynczych plików z kopii zapasowej
maszyny wirtualnej przez osoby do tego upoważnione bez konieczności
nadawania takim osobom bezpośredniego dostępu do głównej konsoli
zarządzającej całym środowiskiem.
17. Mechanizm zapewniający kopie zapasowe musi być wyposażony w system
cyklicznej kontroli integralności danych. Ponadto musi istnieć możliwość
przywrócenia stanu repozytorium kopii zapasowych do punktu w czasie, kiedy
wszystkie dane były integralne w przypadku jego awarii.
18. Oprogramowanie do wirtualizacji musi zapewnić możliwość wykonywania
kopii migawkowych instancji systemów operacyjnych na potrzeby tworzenia
kopii zapasowych bez przerywania ich pracy z możliwością wskazania
konieczności zachowania stanu pamięci pracującej maszyny wirtualnej.
19. Oprogramowanie do wirtualizacji musi zapewnić możliwość klonowania
systemów operacyjnych wraz z ich pełną konfiguracją i danymi.
20. Oprogramowanie zarządzające musi posiadać możliwość przydzielania
i konfiguracji uprawnień z możliwością integracji z usługami katalogowymi,
w szczególności: Microsoft Active Directory.
21. Rozwiązanie musi umożliwiać tworzenie jednorodnych wolumenów logicznych
o wielkości do 62TB.
22. Rozwiązanie musi zapewniać możliwość dodawania zasobów w czasie pracy
maszyny wirtualnej, w szczególności w zakresie przestrzeni dyskowej.
23. Rozwiązanie musi posiadać wbudowany interfejs programistyczny (API)
zapewniający pełną integrację zewnętrznych rozwiązań wykonywania kopii
zapasowych z istniejącymi mechanizmami warstwy wirtualizacyjnej.
24. Rozwiązanie musi umożliwiać wykorzystanie technologii 10GbE w tym
agregację połączeń fizycznych do minimalizacji czasu przenoszenia maszyny
wirtualnej pomiędzy serwerami fizycznymi.
Strona 99 z 106
25. Rozwiązanie musi zapewniać możliwość replikacji maszyn wirtualnych
z dowolnej pamięci masowej w tym z dysków wewnętrznych serwerów
fizycznych na dowolną pamięć masową w tym samym lub oddalonym ośrodku
przetwarzania.
26. Rozwiązanie musi gwarantować współczynnik RPO na poziomie minimum
5 minut.
27. Oprogramowanie do wirtualizacji musi obsługiwać przełączenie ścieżek SAN
(bez utraty komunikacji) w przypadku awarii jednej ze ścieżek.
28. Oprogramowanie do wirtualizacji musi obsługiwać przełączenie ścieżek LAN
(bez utraty komunikacji) w przypadku awarii jednej ze ścieżek.
Wysoka dostępność 29. Rozwiązanie musi mieć możliwość przenoszenia maszyn wirtualnych w czasie
ich pracy pomiędzy serwerami fizycznymi, niezależnie od dostępności
współdzielonej przestrzeni dyskowej, różnymi rodzajami wirtualnych
przełączników sieciowych.
30. Musi zostać zapewniona odpowiednia redundancja i nadmiarowość zasobów tak
by w przypadku awarii np. serwera fizycznego usługi na nim świadczone zostały
automatycznie przełączone na inne serwery infrastruktury.
31. Rozwiązanie musi umożliwiać łatwe i szybkie ponowne uruchomienie
systemów/usług w przypadku awarii poszczególnych elementów infrastruktury.
32. Rozwiązanie musi zapewnić bezpieczeństwo danych mimo poważnego
uszkodzenia lub utraty sprzętu lub oprogramowania.
33. Rozwiązanie musi zapewniać mechanizm bezpiecznego, bezprzerwowego
i automatycznego uaktualniania warstwy wirtualizacyjnej wliczając w to
zarówno poprawki bezpieczeństwa jaki zmianę jej wersji.
34. Rozwiązanie musi posiadać co najmniej 2 niezależne mechanizmy wzajemnej
komunikacji między serwerami oraz z serwerem zarządzającym, gwarantujące
właściwe działanie mechanizmów wysokiej dostępności na wypadek izolacji
sieciowej serwerów fizycznych lub partycjonowania sieci.
35. Decyzja o próbie przywrócenia funkcjonalności maszyny wirtualnej
w przypadku awarii lub niedostępności serwera fizycznego powinna być
podejmowana automatycznie, jednak musi istnieć możliwość określenia przez
administratora czasu po jakim taka decyzja jest wykonywana.
Równoważenie
obciążenia i przestoje
serwisowe
36. Czas planowanego przestoju usług związany z koniecznością prac serwisowych
(np. rekonfiguracja serwerów, macierzy, switchy) musi być ograniczony do
minimum. Konieczna jest możliwość przenoszenia usług pomiędzy serwerami
fizycznymi, bez przerywania pracy usług.
37. System musi mieć wbudowany mechanizm kontrolowania i monitorowania
ruchu do pamięci masowych.
Minimalne wymagania dla serwerowych systemów operacyjnych w usłudze Cloud-computing
Nazwa
komponentu
Wymagane minimalne parametry techniczne
W zależności od proponowanego rozwiązania Wykonawca dostarczy odpowiednią liczbę licencji systemów
operacyjnych potrzebnych do uruchomienia aplikacji na serwerach. Dostarczone licencje muszą być zgodne
w sposobie licencjonowania ze środowiskiem, na którym będą instalowane w tym również licencji edukacyjnych. Rolą
Wykonawcy jest zapewnienie odpowiedniej ilości i zgodności licencje z postanowieniami umów użytkowania w
środowisku zwirtualizowanym.
W ramach postępowania należy dostarczyć odpowiednią liczbę licencji dostępowych (jeśli jest to wymagane do
działania systemu).
Narodowy Instytut Onkologii im. Marii Skłodowskiej-Curie – Państwowy Instytut Badawczy w Warszawie jest
jednostką badawczo-rozwojową prowadzącą działalność naukową, edukacyjną oraz podyplomową w związku z
powyższymi przysługuje Instytutowi prawo do zakupu licencji edukacyjnych.
Użytkownicy systemu będą uwierzytelniani w systemie za pomocą systemów SSO opartych o katalog
użytkowników LDAP opartych o struktury domeny. Użytkownicy zewnętrzni zostaną uwierzytelniani za pomocą
odrębnej bazy danych użytkowników e-Usług.
Backup w ramach usługi cloud-computing
Dla w/w serwerów uruchomiona zostanie usługa backupu danych w ramach umowy o dzierżawę mocy
obliczeniowej.
Strona 100 z 106
Dostęp do chmury obliczeniowej będzie odbywał się za pomocą tuneli VPN o przepustowości nie mniejszej niż
1000Mbit/s. Systemy umieszczone w clound-computing, muszą być podłączone z siecią Internet łączem
o przepustowości nie mniejszej niż 1Gbit/s.
W ramach postępowania Wykonawca zapewni wykonanie backup macierzy produkcyjnej do środowiska cloud-
computingu. System backup ma zapewnić możliwość odtworzenia danych w przypadku awarii macierzy
produkcyjnej oraz spełniać poniższe wymagania:
1. Rozwiązanie musi zapewnić zabezpieczenie danych w postaci kopii zapasowej
2. Kopia zapasowa musi zawierać dane oraz co najmniej kopie migawkowe środowisk wirtualnych
3. Kopia zapasowa musi zagwarantować przechowywanie danych w postaci zaszyfrowanej
4. Rozwiązanie kopii zapasowej musi umożliwiać szyfrowanie danych za pomocą klucza prywatnego
klienta
5. Parametryzacja kopii zapasowej musi być możliwa w zakresie kreowania polityki kopii zapasowej oraz
czasu przechowywania kopii zapasowej
6. Rozwiązanie kopii zapasowej musi posiadać interfejs, który umożliwi parametryzacje procesu
wykonywania kopii zapasowej, możliwość kontroli i monitorowania stanu kopii zapasowej oraz
możliwość odtwarzania całości kopii zapasowej jak i pojedynczych plików
7. Rozwiązanie kopii zapasowej musi umożliwiać tworzenie kopii zapasowych plików w wielu
lokalizacjach w celu utworzenia nadmiarowości danych w przypadku utraty danej wersji danych.
8. Rozwiązanie musi wspierać dobre praktyki np. regułę 3-2-1: uzyskanie co najmniej 3 kopii danych
przechowywanych na 2 różnych nośnikach, z 1 kopią poza siedzibą podstawową.
9. Kopia zapasowa mus być replikowana do drugiego ośrodka i/lub zapasowego ośrodka przetwarzania
danych dostawcy.
10. Dane w środowisku chmurowym mają być zabezpieczone przeciw atakom typu ransomware.
III. GWARACJA
Wykonawca w ramach realizacji Przedmiotu Zamówienia udzieli Zamawiającemu gwarancji jakości (dalej zwanej
gwarancją) w następujące okresy:
1) Przeniesienie funkcjonalności systemu HIS na nową bazę danych wraz z migracją
danych i integracją ze Szpitalnym Systemem Informatycznym:
Poz. OPZ Opis
Okres gwarancji
i nadzoru autorskiego
(minimalny)
II.1.2 System HIS – część medyczna 60 miesięcy (w przypadku
wymiany systemu na nowy)
e-Usługi 60 miesięcy
I.9.5 Usługa migracji danych na nową bazę danych 60 miesięcy
2) Infrastruktura sprzętowa i systemy bezpieczeństwa
Poz. OPZ Opis Okres gwarancji
(minimalny)
II.2.6 System bezpieczeństwa typ 1, 3, 4 i 5 60 miesięcy
System bezpieczeństwa typ 2 12 miesięcy
II.2.1 Elementy sprzętowe Appliance 36 miesięcy
II.2.3 Komponent dyskowy macierzy 36 miesięcy
II.2.4 Długopisy cyfrowe 24 miesiące
II.1.2 Infokioski 24 miesiące
2. Bieg terminów gwarancji określonych w ust. 1 będą rozpoczynać się z dniem podpisania Protokołu Odbioru
Etapu lub Końcowego bez uwag przez Zamawiającego.
Strona 101 z 106
3. W okresie gwarancji Wykonawca będzie zobowiązany do nieodpłatnego usuwania Wad Przedmiotu
Zamówienia rozumianych jako Awaria lub Błąd lub Usterka lub Wadę budowlaną zgodnie z definicjami jak
poniżej:
1) Awaria - Kategoria Wady w Oprogramowaniu lub Oprogramowaniu SSI lub Infrastrukturze Sprzętowej
powodująca brak działania lub niepoprawne działanie Przedmiotu Zamówienia u Zamawiającego,
uniemożliwiające jego użytkowanie. Sytuacja, w której Oprogramowanie w ogóle nie funkcjonuje lub
nie jest możliwe realizowanie istotnych funkcjonalności Komponentów/Produktów Przedmiotu
Zamówienia
2) Błąd - Należy przez to rozumieć Wadę Oprogramowania lub Oprogramowania SSI oznaczającą jego
funkcjonowanie niezgodne z opisem w Dokumentacji oraz OPZ, powodujące błędne zapisy w bazie
danych lub uniemożliwiające działanie mniej istotnej funkcjonalności w Systemie.
3) Usterka - Należy przez to rozumieć kategorię Wady w Oprogramowaniu lub Oprogramowaniu SSI lub
Infrastrukturze Sprzętowej oznaczającą funkcjonowanie niezgodne z opisem Dokumentacji oraz OPZ,
nie wpływającą istotnie na funkcjonowanie dostarczanego rozwiązania u Zamawiającego, utrudniającą
pracę Użytkownikowi Zamawiającego.
4. Przyjęcie zgłoszenia Wady przez Wykonawcę, odbywać się będzie poprzez dostępny on-line System
Zgłaszania i przyjmowania uwag oraz Wad (dalej zwany SZ) przy czym:
1) System Zgłoszeń dostarczy Wykonawca (będzie on utrzymywany i administrowany przez Wykonawcę),
wpis zgłoszenia do SZ będzie dokonywał Zamawiający,
2) za skuteczne przyjęcie zgłoszenia Wady uważa się będzie wprowadzenie przez Zamawiającego wpisu
do SZ zawierającego opis zgłaszanej Wady i termin jej zgłoszenia; w razie trudności z dostępem on-line
do SZ, zgłoszenia Wady mogą odbywać się także telefonicznie pod ustalonym numerem telefonu lub
pisemnie na formularzu przesyłanym na ustalony adres e-mail, opcjonalnie faksem, których numery i
adresy zostaną podane przez Wykonawcę w terminie 15 dni roboczych od dnia podpisania Umowy wraz
ze wzorem formularza zgłoszenia Wady.
5. W przypadku, w którym wykonanie Umowy związane będzie z modernizacją lub rozbudową istniejącego
oprogramowania, gwarancja obejmuje całość oprogramowania modernizowanego lub rozbudowywanego.
6. Gwarancja musi zapewniać wymianę uszkodzonego sprzętu, kabli i elementów oraz zapewniać dostęp do
aktualizacji oprogramowania, bez wiedzy i wsparcia technicznego producenta.
7. W ramach gwarancji Wykonawca będzie świadczył usługi wskazane w tabelach poniżej.
8. Usuwanie wad w dostarczonym Przedmiocie Zamówienia w przypadku stwierdzenia przez Zamawiającego
wady w jego działaniu, w terminach określonych poniżej:
1) Dostawa i wdrożenie infrastruktury sprzętowej i oprogramowania
narzędziowego oraz bezpieczeństwa:
a) Infokioski:
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS REAKCJI
WYKONAWCY
CZAS
NAPRAWY
AWARIA
24/7/365
niezwłocznie, nie
później niż 24 godziny
od czasu przyjęcia
zgłoszenia
niezwłocznie, nie później
niż 24 godziny od czasu
przyjęcia zgłoszenia
niezwłocznie, nie
później
niż 24 godziny od
czasu przyjęcia
zgłoszenia
USTERKA nie dotyczy
niezwłocznie nie później
niż 5 dni roboczych od dnia
przyjęcia zgłoszenia
niezwłocznie nie
później niż 14 dni od
dnia przyjęcia
zgłoszenia
Strona 102 z 106
b) Macierz i serwery wspomagające do macierzy:
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS REAKCJI
WYKONAWCY
CZAS
NAPRAWY
AWARIA W dni robocze
pomiędzy 7.30 a
15.05. Zgłoszenie
przesłane po 15.05,
traktowane jest jak
zgłoszenie przyjęte w
następnym dniu
roboczym o 7.30
niezwłocznie, nie później
niż 4 godziny od czasu
przyjęcia zgłoszenia
niezwłocznie, nie
później niż 4 godziny
od czasu przyjęcia
zgłoszenia
niezwłocznie, nie
później
niż 24 godzin od
czasu przyjęcia
zgłoszenia
USTERKA nie dotyczy
niezwłocznie nie
później niż 5 dni
roboczych od dnia
przyjęcia zgłoszenia
niezwłocznie nie
później niż 14 dni od
dnia przyjęcia
zgłoszenia
c) Długopisy cyfrowe (System digitalizacji danych z pisma ręcznego):
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS REAKCJI
WYKONAWCY
CZAS
NAPRAWY
AWARIA W dni robocze
pomiędzy 7.30 a
15.05. Zgłoszenie
przesłane po 15.05,
traktowane jest jak
zgłoszenie przyjęte w
następnym dniu
roboczym o 7.30
niezwłocznie, nie później
niż 48 godziny od czasu
przyjęcia zgłoszenia
niezwłocznie, nie
później niż 24 godziny
od czasu przyjęcia
zgłoszenia
niezwłocznie, nie
później
niż 72 godzin od
czasu przyjęcia
zgłoszenia
USTERKA nie dotyczy
niezwłocznie nie
później niż 5 dni
roboczych od dnia
przyjęcia zgłoszenia
niezwłocznie nie
później niż 14 dni od
dnia przyjęcia
zgłoszenia
d) oprogramowanie systemowe i narzędziowe:
KWALIFIKACJA
ZGŁOSZENIA WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS
REAKCJI
WYKONAWCY
CZAS NAPRAWY
AWARIA
W dni robocze
pomiędzy 7.30 a
15.05. Zgłoszenie
przesłane po 15.05,
traktowane jest jak
zgłoszenie przyjęte w
następnym dniu
roboczym o 7.30
niezwłocznie, nie
później niż 24 godzin
od czasu przyjęcia
zgłoszenia
niezwłocznie, nie
później niż 24
godzin od czasu
przyjęcia
zgłoszenia
niezwłocznie, nie
później
niż 96 godzin
od czasu przyjęcia
zgłoszenia
BŁĄD nie dotyczy
niezwłocznie nie
później niż 2 dni
robocze od dnia
przyjęcia
zgłoszenia
niezwłocznie nie później
niż 14 dni od dnia
przyjęcia zgłoszenia
USTERKA nie dotyczy
niezwłocznie nie
później niż 5 dni
roboczych od dnia
przyjęcia
zgłoszenia
niezwłocznie nie później
niż 30 dni od dnia
przyjęcia zgłoszenia
e) System bezpieczeństwa typ 1
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS REAKCJI
WYKONAWCY
CZAS
NAPRAWY
AWARIA
W dni robocze
pomiędzy 7.30 a
15.05. Zgłoszenie
niezwłocznie, nie później
niż 8 godzin od czasu
przyjęcia zgłoszenia
niezwłocznie, nie
później niż 8 godzin od
niezwłocznie, nie
później
niż 24 godzin od
Strona 103 z 106
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS REAKCJI
WYKONAWCY
CZAS
NAPRAWY
przesłane po 15.05,
traktowane jest jak
zgłoszenie przyjęte w
następnym dniu
roboczym o 7.30
czasu przyjęcia
zgłoszenia
czasu przyjęcia
zgłoszenia.
Serwis producenta
obejmujący
wymianę wadliwego
produktu na nowy
(wysyłka nowego
urządzenia tego
samego dnia
roboczego, jeśli
awaria urządzenia
zostanie
potwierdzona przed
godziną 15:00)
USTERKA nie dotyczy
niezwłocznie nie
później niż 5 dni
roboczych od dnia
przyjęcia zgłoszenia
niezwłocznie nie
później niż 14 dni od
dnia przyjęcia
zgłoszenia
f) System bezpieczeństwa typ 2
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS REAKCJI
WYKONAWCY
CZAS
NAPRAWY
AWARIA W dni robocze
pomiędzy 7.30 a
15.05. Zgłoszenie
przesłane po 15.05,
traktowane jest jak
zgłoszenie przyjęte w
następnym dniu
roboczym o 7.30
niezwłocznie, nie później
niż 48 godzin od czasu
przyjęcia zgłoszenia
niezwłocznie, nie
później niż 48 godzin
od czasu przyjęcia
zgłoszenia
niezwłocznie, nie
później
niż 14 dni od czasu
przyjęcia zgłoszenia
USTERKA nie dotyczy
niezwłocznie nie
później niż 5 dni
roboczych od dnia
przyjęcia zgłoszenia
niezwłocznie nie
później niż 30 dni od
dnia przyjęcia
zgłoszenia
g) System bezpieczeństwa typ 3, 4, 5
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS REAKCJI
WYKONAWCY
CZAS
NAPRAWY
AWARIA W dni robocze
pomiędzy 7.30 a
15.05. Zgłoszenie
przesłane po 15.05,
traktowane jest jak
zgłoszenie przyjęte w
następnym dniu
roboczym o 7.30
niezwłocznie, nie później
niż 24 godziny od czasu
przyjęcia zgłoszenia
niezwłocznie, nie
później niż 24 godziny
od czasu przyjęcia
zgłoszenia
niezwłocznie, nie
później
niż 96 godzin od
czasu przyjęcia
zgłoszenia
USTERKA nie dotyczy
niezwłocznie nie
później niż 5 dni
roboczych od dnia
przyjęcia zgłoszenia
niezwłocznie nie
później niż 30 dni od
dnia przyjęcia
zgłoszenia
Strona 104 z 106
3) Przeniesienie funkcjonalności systemu HIS na nową bazę danych wraz z migracją
danych i integracją ze Szpitalnym Systemem Informatycznym:
a) Szpitalny System Informatyczny
KWALIFIKACJA
ZGŁOSZENIA
WADY
OKRES
DOSTĘPNOŚCI
WYKONAWCY
ROZWIĄZANIE
ZASTĘPCZE
CZAS REAKCJI
WYKONAWCY
CZAS
NAPRAWY
AWARIA
W dni robocze
pomiędzy 7.30 a
15.05. Zgłoszenie
przesłane po 15.05,
traktowane jest jak
zgłoszenie przyjęte
w następnym dniu
roboczym o 7.30
niezwłocznie, nie
później niż 12
godzin od czasu
przyjęcia zgłoszenia
niezwłocznie, nie
później niż 12
godzin od czasu
przyjęcia
zgłoszenia
niezwłocznie, nie
później
niż 24 godziny
od czasu przyjęcia
zgłoszenia
BŁĄD nie dotyczy
niezwłocznie nie
później niż 2 dni
robocze od dnia
przyjęcia
zgłoszenia
niezwłocznie nie
później niż 5 dni
roboczych od dnia
przyjęcia
zgłoszenia
USTERKA nie dotyczy
niezwłocznie nie
później niż 5 dni
roboczych od dnia
przyjęcia
zgłoszenia
niezwłocznie nie
później niż 10 dni
roboczych od dnia
przyjęcia
zgłoszenia
8.1. dopuszcza się zmianę kwalifikacji zgłoszenia Wady, po uprzedniej zgodzie Zamawiającego. Do czasu
potwierdzenia zmiany kwalifikacji, uznaje się za obowiązującą kwalifikację pierwotną,
8.2. czasy naprawy mogą być inne niż wskazane w powyższych tabelach, jeżeli Zamawiający zaakceptuje
zmianę kwalifikacji zgłoszenia, o której mowa w punkcie 9.2,
8.3. w przypadku braku możliwości usunięcia Wady lub przedstawienia rozwiązania zastępczego zdalnie,
Wykonawca zobowiązany jest do świadczenia gwarancji bezpośrednio w lokalizacji Zamawiającego,
8.4. usunięcie Wady Oprogramowania, nastąpi poprzez przekazanie poprawki lub nowej wersji. Każda nowa
poprawka lub nowa wersja musi posiadać unikalny numer.
8.5. 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ę usunięcia Wady, czas naprawy,
8.6. wykonywania Serwisu - Oprogramowania na poniższych zasadach:
1) wykonywania modyfikacji bez wezwania lub na pisemne zgłoszenie Zamawiającego w celu
dostosowania wszystkich elementów Oprogramowania do obowiązujących przepisów prawnych,
2) przekazania Zamawiającemu informacji o nowych wersjach Oprogramowania drogą elektroniczną
na wskazany adres e-mail Zamawiającego,
3) udostępniania nowych wersji Oprogramowania poprzez ustaloną witrynę internetową lub serwer ftp,
w szczególności związanych z wejściem w życie nowych przepisów prawa lub zawierających nowe
funkcjonalności; w przypadku w którym udostępnianie następować będzie w związku ze zmianą
przepisów prawa, Wykonawca zobowiązany będzie do jej dokonania na nie mniej niż 14 dni przed
dniem wejścia w życie tych przepisów. W uzasadnionych przypadkach, Zamawiający dopuści aby
Wykonawca udostępnił odpowiednie zmiany w terminach umożliwiających Zamawiającemu
wywiązanie się ze zmienionych przepisów prawa.
4) każda nowa wersja musi posiadać unikalny numer;
5) wraz z nową wersją Wykonawca zobowiązany jest do przekazania nowej wersji Dokumentacji
Powykonawczej wraz z procedurą instalacji oraz informacją o parametryzacji i konfiguracji.
6) świadczenia usług w postaci konsultacji, porad, wsparcia technicznego w zakresie wdrożenia oraz
użytkowania Oprogramowania, przy czym:
a) usługi będą świadczone w dni robocze w godzinach od 7.30 do 15.05 w języku polskim,
b) tryb zgłaszania: telefonicznie, e-mail, faxem lub poprzez System Zgłoszeń,
c) konsultacje i porady będą udzielane na bieżąco podczas rozmowy telefonicznej lub w postaci
elektronicznej, jeżeli wynika to z przedmiotu usługi, jednak nie później niż w ciągu 3 dni
roboczych od skierowania zapytania. Jeżeli nie jest możliwe wykonanie usługi w ciągu 3 dni
roboczych, Wykonawca uzgodni z Zamawiającym inny termin konsultacji lub porady.
9. Pozostałe ustalenia:
1) System Zgłoszeń, który zostanie udostępniony przez Wykonawcę, ma dodatkowo pozwalać na
prowadzenie rejestru kontaktów z Zamawiającym obejmującego w szczególności wykonane czynności
Strona 105 z 106
gwarancyjne, ewidencję wszystkich zgłoszeń gwarancyjnych, opis zmian w konfiguracji
Oprogramowania; prowadzenie rejestru zgłoszeń jest obowiązkiem Wykonawcy.
2) Zamawiający przekaże Wykonawcy, zgodnie ze stanem swojej wiedzy, informacje o aktach prawa
wewnętrznego obowiązującego w Podmiocie leczniczym, które mają zastosowanie w realizacji niniejszej
Umowy.
10. Zamawiający ustala procedurę zdalnego dostępu Wykonawcy do Oprogramowania:
1) Wykonawca drogą elektroniczną poprzez e-mail, prześle Zamawiającemu wniosek o uzyskanie zdalnego
dostępu do Oprogramowania, wskazując co najmniej:
a) imię i nazwisko pracownika Wykonawcy, któremu zostanie przyznany dostęp,
b) nazwa i adres IP zasobu (bazy danych/oprogramowania), który zostanie udostępniony,
c) usługi sieciowe, które zostaną udostępnione,
d) okres czasu, na który będzie aktywowany dostęp,
e) numer zgłoszenia gwarancyjnego,
f) przyczyna złożenia wniosku,
g) opis czynności, które zostaną wykonane,
h) imię i nazwisko pracownika Wykonawcy uprawnionego do złożenia wniosku.
2) osoba wyznaczona przez Zamawiającego zaopiniuje wniosek i w formie elektronicznej poprzez e-mail
odpowie, podając informację o zgodzie lub jej braku.
3) po zakończeniu prac Wykonawca ma obowiązek przesłać Zamawiającemu raport
z wykonanych prac z wykorzystaniem zdalnego dostępu, podając czas ich trwania i zakres.
4) każdy zdalny dostęp do Oprogramowania musi być przez Wykonawcę odnotowany w Systemie Zgłoszeń,
5) dostęp do zasobów Zamawiającego musi być zgodny z obowiązującą u niego polityką bezpieczeństwa.
Zamawiający udostępni procedury bezpieczeństwa Wykonawcy, którego oferta zostanie wybrana jako
najkorzystniejsza, po podpisaniu umowy.
11. W przypadku dostarczenia nowej lub zmodyfikowanej wersji Oprogramowania wymagającego aktualizacji
lub wymiany Oprogramowania dostarczonego w ramach niniejszej Umowy, Wykonawca w ramach gwarancji
ma obowiązek wymiany lub aktualizacji także tego Oprogramowania.
12. Okres gwarancji dla Oprogramowania SSI jest równy okresowi nadzoru autorskiego, w ramach którego
Wykonawca zobowiązuje się do:
a) wykonywania modyfikacji bez wezwania lub na pisemne zgłoszenie Zamawiającego w celu
dostosowania wszystkich elementów Oprogramowania SSI do obowiązujących przepisów prawnych,
b) przekazania Zamawiającemu informacji o nowych wersjach oprogramowania drogą elektroniczną na
wskazany adres e-mail Zamawiającego,
c) udostępniania nowych wersji oprogramowania poprzez ustaloną witrynę internetową,
w szczególności związanych z wejściem w życie nowych przepisów prawa lub zawierających nowe
funkcjonalności, w szczególności związane z rozliczeniami z NFZ; w przypadku w którym
udostępnianie następować będzie w związku ze zmianą przepisów prawa, Wykonawca zobowiązany
będzie do udostępnienia nowej wersji oprogramowania na nie mniej niż 14 dni przed dniem wejścia w
życie tych przepisów; udostępniania nowych wersji oprogramowania poprzez ustaloną witrynę
internetową, w szczególności związanych z wejściem w życie nowych przepisów prawa lub
zawierających nowe funkcjonalności, w szczególności związane z rozliczeniami z NFZ; w przypadku
w którym udostępnianie następować będzie w związku ze zmianą przepisów prawa, Wykonawca
zobowiązany będzie do jej dokonania na nie mniej niż 14 dni przed dniem wejścia w życie tych
przepisów, a w przypadku, gdy przepisy te będą wchodziły w życie w terminie krótszym niż 14 dni od
daty ich publikacji, w terminie nie później jak 14 dni od ich publikacji;
d) wysłania na adres korespondencyjny Zamawiającego nośnika CD/DVD zawierającego nową wersję
oprogramowania, na pisemne żądanie wniesione przez Zamawiającego - każda nowa wersja musi
posiadać unikalny numer;
e) wraz z nową wersją oprogramowania Wykonawca zobowiązany jest do przekazania nowej wersji
Dokumentacji wraz z procedurą instalacji oprogramowania oraz informacją o parametryzacji
i konfiguracji.
f) świadczenia usług w postaci konsultacji, porad, wsparcia technicznego w zakresie wdrożenia oraz
użytkowania oprogramowania SSI w wymiarze do 2000 roboczogodzin, przy czym:
- usługi będą świadczone w dni robocze w godzinach od 8.00 do 16.00 w języku polskim,
w siedzibie Zamawiającego lub za uzgodnieniem Stron, jako prace świadczone zdalnie
- tryb zgłaszania: telefonicznie, e-mail, faxem lub poprzez Elektroniczny System Zgłoszeń,
konsultacje i porady będą udzielane na bieżąco podczas rozmowy telefonicznej lub w postaci
elektronicznej, jednak nie później niż w ciągu 3 dni roboczych od skierowania zapytania. Jeżeli
nie jest możliwe wykonanie usługi w ciągu 3 dni roboczych, Wykonawca uzgodni
z Zamawiającym inny termin konsultacji lub porady, jeżeli Zamawiający wyrazi na to zgodę.
Strona 106 z 106
Uwaga:
W przypadku zapisu terminu jako:
- Dzień Roboczy należy rozumieć każdy dzień od poniedziałku do piątku z wyłączeniem dni ustawowo
wolnych od pracy.
- Godziny Robocze należy rozumieć godziny od 8.00 do 16.00 w każdym Dniu Roboczym.
W innych przypadkach należy rozumieć jako dzień kalendarzowy.
Załączniki do OPZ:
1. Załącznik nr 1.1 - Lista funkcjonalności obecnie używanych modułów systemu CliniNET w Narodowym
Instytucie Onkologii im. Marii Skłodowskiej-Curie – Państwowym Instytucie Badawczym
2. Załącznik nr 1.2 - Specyfikacja formatów danych i standardów stosowanych w lokalnych systemach HIS
i Repozytorium Elektronicznej Dokumentacji Medycznej
3. Załącznik nr 1.3 - Inwentaryzacja systemu informatycznego CGM CliniNET
4. Załącznik nr 1.3a – CGM CliniNET – architektura SOA
5. Załącznik nr 1.4 – Interfejs HL7 pomiędzy szpitalnym systemem informatycznym (HIS)
a specjalizowanym modułem diagnostycznym ver. 1.4
6. Załącznik nr 1.5 - Inwentaryzacja systemu informatycznego CGM CliniNET Psychoonkologia
7. Załącznik nr 1.6 - Szczegółowy opis lokalizacji infokiosków ze wskazaniem ich liczby i rodzaju