ZAŁĄCZNIK NR 1 DO SIWZ NARODOWY I O M S -C ......27 ONCENTRA BRACHY System Planowania Leczenia 28...

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


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.

https://ezdrowie.gov.pl/portal/artykul/dokumentacja-integracyjna-dla-obszaru-zdarzen-medycznych-i-indeksow-edm-czesc-pierwsza

https://ezdrowie.gov.pl/portal/artykul/dokumentacja-integracyjna-dla-obszaru-zdarzen-medycznych-i-indeksow-edm-czesc-pierwsza

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.


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







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.


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







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.


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


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


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.


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



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.

http://login.gov.pl/

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.


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.


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


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.


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.


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.


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.


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


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.



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.


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.


Strona 57 z 106

Mapa procesu:

Rysunek - Mapa procesu – e-wywiad


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.


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.


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.



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


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.


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


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.


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.


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.


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.


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.


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.


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.



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.



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.



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


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


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


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;, &#xAA)).

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


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



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



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.



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:






http://www.smsapi.pl/

Strona 92 z 106






Wydajność systemu Firewall minimum 55 Gbps


4 Gbps


Wydajność VPN IPSec, nie mniej niż 8 Gbps












Polityka bezpieczeństwa systemu zabezpieczeń musi uwzględniać adresy IP, interfejsy, protokoły, usługi





















pomocą skali lub kolorów


nie mniej niż:






kontrolerze domeny


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.




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.


Strona 93 z 106


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



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



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.



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:











Wydajność systemu Firewall minimum 55 Gbps


4 Gbps


Wydajność VPN IPSec, nie mniej niż 8 Gbps












Polityka bezpieczeństwa systemu zabezpieczeń musi uwzględniać: adresy IP, interfejsy, protokoły, usługi




Strona 94 z 106


















pomocą skali lub kolorów.


nie mniej niż:






kontrolerze domeny.


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




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.



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


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


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


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


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


niezwłocznie nie


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


pomiędzy 7.30 a

15.05. Zgłoszenie


traktowane jest jak


następnym dniu

roboczym o 7.30




niezwłocznie, nie


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


roboczych od dnia


niezwłocznie nie


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


traktowane jest jak


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


robocze od dnia

przyjęcia

zgłoszenia


niż 14 dni od dnia


USTERKA nie dotyczy

niezwłocznie nie


roboczych od dnia

przyjęcia

zgłoszenia


niż 30 dni od dnia


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


niż 8 godzin od czasu


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


traktowane jest jak


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


roboczych od dnia


niezwłocznie nie


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


pomiędzy 7.30 a

15.05. Zgłoszenie


traktowane jest jak


następnym dniu

roboczym o 7.30


niż 48 godzin od czasu


niezwłocznie, nie

później niż 48 godzin

od czasu przyjęcia

zgłoszenia

niezwłocznie, nie

później

niż 14 dni od czasu


USTERKA nie dotyczy

niezwłocznie nie


roboczych od dnia


niezwłocznie nie


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


pomiędzy 7.30 a

15.05. Zgłoszenie


traktowane jest jak


następnym dniu

roboczym o 7.30




niezwłocznie, nie


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


roboczych od dnia


niezwłocznie nie


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


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


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


robocze od dnia

przyjęcia

zgłoszenia

niezwłocznie nie


roboczych od dnia

przyjęcia

zgłoszenia

USTERKA nie dotyczy

niezwłocznie nie


roboczych od dnia

przyjęcia

zgłoszenia

niezwłocznie nie


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


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

ZAŁĄCZNIK NR 1 DO SIWZ NARODOWY I O M S -C ......27 ONCENTRA BRACHY System Planowania Leczenia 28...

Documents

Transcript of ZAŁĄCZNIK NR 1 DO SIWZ NARODOWY I O M S -C ......27 ONCENTRA BRACHY System Planowania Leczenia 28...