Servisní služby pro zajištění provozu systému eHealth

Dokumentace k systému – na vyžádání po podpisu smlouvy (je předmětem obchodního tajemství stávajícího poskytovatele služeb, lze využít jen v omezeném režimu).

Seznam zkratek a pojmů

Zkratka/pojem	Význam
24x7 24x7x365	Provoz systému nebo poskytování služeb 365 dní v roce, 24 hodiny denně, 7 dnů v týdnu
8x5	Poskytování služeb v pracovní dny, v pracovní době
API	Application Programming Interface
AZD	Archiv zdravotnické dokumentace
CA	Certifikační autorita
CN	Communication Node
CRL	Certificate Revocation List
ČR	Česká republika
DASTA	Datový standard pro předávání dat mezi IS zdravotnických zařízení
DB	Databáze
DC	Datové centrum
EKP	Elektronická karta pacienta
EU	Evropská unie
GB	Gigabyte
GDPR	Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob
GW	Gateway
HW	Hardware
IOP	Integrovaný operační program
IS	Informační systém
ISAC	Integration Share and Communication (System)
IZS	Integrovaný záchranný systém
KHK	Královéhradecky kraj
KIS	Klinický informační systém
KKC	Krajské komunikační centrum
ks	Počet kusů
KU	Komunikační uzel
MS	Microsoft
MZD	Mobilní zadávání dat
NCPeH	National Contact Point for eHealth
NIS	Národní informační systém IZS
OS	Operační systém
PC	Stolní počítač
PDF/A	Archivační verze formátu PDF (Portable Document Format)
PNP	Přednemocniční neodkladná péče
POV	Protokol o výjezdu (ZZS)
RLP	Posádka rychlé lékařské pomoci (s lékařem)
RP	Rozšířená podpora
RV	Systém rendezvous (setkávání posádek)
RZ	Registrační značka vozidla
RZP	Posádka rychlé záchranné pomoci (bez lékaře)
SaP	Síly a prostředky
SIEM	Security Information and Event Management
SLA	Úroveň a podmínky poskytování služeb technické a technologické podpory
SNMP	Simple Network Management Protocol
SSL	Secure Sockets Layer
SW	Software
TLS	Transport Layer Security
VPN	Virtual private network
VZ	Veřejná zakázka
WAN	Wide Area Network
ZOP	Záznam o výjezdu (ZZS)
ZP	Zadávací podmínky
ZZ	Zdravotnické zařízení
ZZS	Zdravotnická záchranná služba (ve všeobecném významu)
ZZS KHK	Zdravotnická záchranná služba Královéhradeckého kraje

1Předmět plnění

Předmětem plnění veřejné zakázky je poskytování servisních služeb k souboru informačních systémů, aplikačního software a souvisejících technologií využívaných ze strany Zdravotnické záchranné služby Královéhradeckého kraje (ZZS KHK) pro provoz služeb eHealth – zpřístupnění zdravotnické dokumentace a souvisejících informací mezi zdravotnickými zařízeními na území Královéhradeckého kraje. Poskytování služeb bude na dobu neurčitou pro dále uvedené infomační systémy, aplikační software, související technologie, vybavení posádek a vozidel.

Zdravotnická záchranná služba Královéhradeckého kraje je základní složkou IZS a v souladu s legislativou poskytuje přednemocniční neodkladnou péči (PNP). V rámci poskytování PNP využívá dále uvedené infomační systémy, aplikační software, související technologie, vybavení posádek a vozidel. Soubor těchto infomačních systémů, aplikačního software, souvisejících technologií, vybavení posádek a vozidel je nadále označováno jako IS ZZS KHK nebo „Systém“ a je popsán ve výchozím stavu uvedeném dále v tomto dokumentu.

IS ZZS KHK byl pořízen v rámci projektu podpořeném z EU, z Integrovaného operačního programu (IOP), výzvy č. 23, v rámci projektu „Technologické vybaveni Zdravotnické záchranné služby Královéhradeckého kraje, p.o.“, který byl realizován v roce 2015. Dále byl Systém doplněn o řadu dílčích funkcionalit vyplývajících z provozních potřeb ZZS od doby realizace pořízení IS ZZS KHK. Rozsah IS ZZS KHK je uveden v kap. 4 – Výchozí stav.

Stávající stav IS ZZS KHK je výchozím stavem pro požadovaný předmět plnění veřejné zakázky (popis výchozího stavu je uveden dále v tomto dokumentu), tj. pro poskytování servisních služeb pro IS ZZS KHK.

Servisní služby se vztahují i na budoucí úpravy IS ZZS KHK realizovaných v rámci dále uvedených poskytnutých služeb.

V současné době je IS ZZS KHK v provozu a poskytování servisních služeb bylo v souladu s uzavřenou smlouvou ukončeno k 10.12.2020, záměrem Objednatele je co nejdříve navázat na ukončení smlouvy a zajistit servisní služby na další období.

Primárním požadavkem a cílem je zajištění provozu IS ZZS KHK a souvisejících služeb a tím kontinuity ZZS KHK v oblasti poskytování PNP na území Královéhradeckého kraje na dobu neurčitou.

Objednatel nepředpokládá výměnu ani obměnu stávajícího systému IS ZZS KHK nebo jeho částí v rámci této veřejné zakázky.

Požadavky na služby jsou uvedeny v následujících kapitolách.

2Požadavky na předmět plnění

2.1Maintenance

2.1.1Rozsah plnění

Služby základní podpory Systému v režimu 24x7x365, včetně stávajících integrací na další části Systému pro celky:

Krajské komunikační centrum
- Zdravotnická záchranná služba - 1 ks
Krajská komunikační brána pro Portál občana
- Zdravotnická záchranná služba - 1 ks
Archivy zdravotnické dokumentace
- Zdravotnická záchranná služba - 2 ks
- Oblastní nemocnice Náchod - 2 ks
- Fakultní nemocnice Hradec Králové - 2 ks (není předmětem požadavků, zde jen pro úplnost)
Komunikační uzly
- Zdravotnická záchranná služba - 2 ks
- Oblastní nemocnice Náchod - 2 ks
- Oblastní nemocnice Trutnov - 2 ks
- Oblastní nemocnice Jičín - 2 ks
- Městská nemocnice Dvůr Králové n/L - 2 ks
- Nemocnice Rychnov nad Kněžnou – 2 ks
- Nemocnice Vrchlabí – 1 ks
- Fakultní nemocnice Hradec Králové - 2 ks (není předmětem požadavků, zde jen pro úplnost)
Specifické úpravy MZD/EKP
- Zdravotnická záchranná služba - 1 soubor

2.1.2Požadované služby

Poskytování služby Hotline včetně základní servisní technické podpory Systému při odstraňování závad Systému. Hotline bude k dispozici v režimu 24x7, nicméně služby budou poskytovány dle úrovně uvedené u příslušných částí Systému.
Poskytování pravidelné profylaxe Systému vč. indikace a předcházení možných problémů při užívání Systému min. 1x čtvrtletně.
Zajištění souladu funkčnosti a vlastností systému s aktuální legislativou vč. bezplatného provádění nezbytných úprav systémů pro splnění tohoto požadavku.
Poskytování aktualizací Softwarových produktů a technologií a opravných patchů.
Dokumentace k aktualizacím Softwarových produktů a technologií, aktualizace provozní dokumentace Systému tak, aby odpovídala aktuálnímu stavu provozovaného Systému.
Aplikace service packů a hotfixů nutných pro bezchybný chod systému, které byly identifikovány na základě profylaxe a jejich aplikace byla dohodnuta s Objednatelem.
Aktualizace systémových součástí (OS, DB,…) pro zajištění kybernetické bezpečnosti min. 1x ročně a to včetně zajištění podporovaných verzí ze strany výrobců. Případné pořízení/nákup nových verzí bude předem dohodnuto s Objednatelem.
Poradenské a konzultační služby k Systému a případně při řešení vzniklých incidentů. Tuto službu je možné poskytovat jak přes helpdesk Poskytovatele, tak případně telefonicky nebo mailem.

2.1.3Podmínky poskytování služeb

Porucha/incident/požadavek kategorie A:

Situace, kdy nelze využívat klíčové funkcionality systému (předávání dokumentace do zdravotnických zařízení, čerpání životních údajů pacienta, zobrazení dokumentace v NIS jednotlivých zdravotnických zařízeních), tj. IS nebo jeho část IS není zcela funkční, neumožňuje práci uživatelů se systémem a nelze ho používat pro podporu procesů. Vztahuje se na případy, kdy je systém zcela nefunkční z důvodů na straně IS nebo jeho části.
Závažné porušení bezpečnosti – přístup k systému a datům bez autentifikace, či autorizace (obejití přístupových práv); neoprávněný přístup k technickým prostředkům; neoprávněné zacházení s daty (přístup neodpovídající přiřazené roli v systému); přihlášení do systému pomocí neplatných certifikátů, či hesel; přístup k systému (jiným systémem, nebo fyzickou osobou) pomocí jiných služeb než definovaných; a jiné, které ohrožují integritu, důvěryhodnost, či neodvolatelnost uložených a poskytovaných dat.

Porucha/incident/požadavek kategorie B:

Situace, kdy IS nebo část IS je částečně funkční, umožňuje částečné poskytování služeb po přechodnou dobu se sníženým komfortem uživatelů, případně provizorním způsobem z důvodů na straně IS nebo jeho části.

Porucha/incident/požadavek kategorie C:

Nedostatky a vady drobného rozsahu, které nebrání užívání IS nebo jeho části, nicméně nejsou v souladu s předaným a dokumentovaným stavem IS nebo jeho části.

Porucha/incident/požadavek kategorie REQ:

Požadavek na služby, které nejsou chápány jako vada IS nebo jeho části. Specifický postup řešení je popsán níže s kapitole Rozšířená podpora.

Řešení poruch:

V případě, že se jedná o poruchu na Systému dle této specifikace, vztahují se na ni SLA dle této Smlouvy.
V případě, že se jedná o poruchu integrovaného systému nebo HW a SW infrastruktury mimo tuto Smlouvu s dopadem na Systém uvedený v této Smlouvě, nevztahují se na tuto poruchu SLA dle této Smlouvy do doby odstranění poruchy integrovaného systému nebo infrastruktury.
V případě, že bude snížena závažnost poruchy, snižují se poměrně k tomuto SLA i lhůty ve vztahu k nové závažnosti poruchy. Snížená SLA se uplatní na poruchu od jejího počátku, tedy od nahlášení oprávněnou osobou.
Poskytovatel je oprávněn navrhnout nebo poskytnout náhradní řešení poruchy tak, aby došlo k eliminaci dopadů této poruchy na provoz ZZS (snížení závažnosti nebo omezení poruchy) do konečného systémového řešení.
Dohodnou-li se obě strany na provedení zásahu v termínu po lhůtě na odstranění poruchy, nebude toto považováno za nedodržení lhůty na odstranění poruchy ze strany Poskytovatele. Taková dohoda musí být dokumentována v rámci popisu řešení dané poruchy a oprávněnost jejího použití vzniká po jejím schválení odpovědným zástupcem Objednatele (žadatel, případně vedoucí projektu).

Způsob ohlašování poruch:

Poruchy Objednatel (oprávněné osoby Objednatele) hlásí na kontaktní místo Poskytovatele (Hot-line) přednostně prostřednictvím elektronického systému pro správu požadavků (helpdesk), případně telefonicky a/nebo elektronickou poštou. Pro potřeby poskytování servisních služeb bude jediný helpdesk pro všechny části plnění, distribuci v rámci týmu Poskytovatele zajistí Poskytovatel.

Poruchy budou do systému zadávány jednotlivě – samostatné hlášení pro každou závadu.

Reakce Poskytovatele:

Služba Hot-line Poskytovatele dle sjednané reakční doby potvrdí Objednateli elektronickou poštou, že obdržela výzvu Objednatele k odstranění poruchy. V potvrzení uvede označení evidované poruchy a termín zahájení prací na odstraňování poruchy. Tyto informace doručí osobě, která problém za Objednatele nahlásila (dále jen Žadatel) a pracovišti Helpdesku Objednatele.

Lhůta na odstranění poruchy:

Konečná lhůta na odstranění poruchy je dána okamžikem ohlášení poruchy Objednatelem (oprávněnou osobou Objednatele) do doby vyřešení poruchy.

Lhůta na odstranění poruchy je čas od nahlášení závady, do kterého se Poskytovatel bude zavazovat odstranit nahlášenou závadu nebo vytvořit pracovní postup „workaround“, který povede ke snížení priority nahlášené závady. V případě „workaround“ bude tato závada následně řešena ve lhůtě na odstranění poruchy dle priority, na kterou byla snížena. Závada bude ve lhůtě na odstranění poruchy odstraněna za předpokladu, že Objednatel zpřístupní Poskytovateli zařízení, kterého se nahlášená závada týká, v termínu stanoveném dle níže uvedených pravidel. Dohodnou-li se obě strany na provedení zásahu v termínu po lhůtě na odstranění poruchy, nebude toto považováno za nedodržení lhůty na odstranění poruchy ze strany Poskytovatele.

V případě, kdy nepůjde o závadu kategorie A a odstranění závady vyžaduje provedení softwarové opravy, prodlouží se lhůta na odstranění poruchy o 4 pracovní dny, potřebné pro otestování opravené verze dílčí části Systému v testovacím prostředí, před nasazením do produkčního prostředí. Pro vyhodnocení splnění lhůty na odstranění poruchy se nahlášená závada považuje za odstraněnou okamžikem nasazení opravené verze dílčí části Systému do prostředí Objednatele. Odstranění nahlášené závady musí být navíc dodatečně potvrzeno po nasazení otestované verze dílčí části Systému do produkčního prostředí Objednatele.

Objednatel se zavazuje poskytovat veškerou potřebnou součinnost při nasazování nové verze dílčí části Systému a podílet se na jeho testování. Pro každé nasazení nové verze dílčí části Systému do produkčního prostředí bude Poskytovatelem předložen a Objednatelem odsouhlasen detailní harmonogram nasazení, obsahující popis jednotlivých kroků vč. jejich časové náročnosti, případných omezení provozu, definice zodpovědností za provedení jednotlivých kroků a specifikace požadované součinnosti. Harmonogram bude obsahovat též postup návratu k předchozí verzi dílčí části Systému pro případ, že by v průběhu nasazení nebo bezprostředně po jeho dokončení došlo k výskytu kritických chyb.

Režimy:

24x7x365 – poskytování služeb non-stop, tj. 24 hodin denně, 7 dní v týdnu, 365 dní v roce.
8x5 – poskytování služeb v pracovní dny, v pracovní době (pracovní dny: pondělí – pátek, vyjma státních svátků, pracovní doba v pracovních dnech od 8:00 do 16:00 h).

Lhůty:

Kategorie požadavku	Dostupnost služby (servisní doba)	Řešení zahájeno (response time)	Výsledku dosaženo (fix time)
A	24x7	6 hodin	24 hodin
B	8x5	Následující pracovní den	4 pracovní dny
C	8x5	2 pracovní dny	Po dohodě
REQ	8x5	bez SLA	bez SLA

Porucha, která již pominula:

V případě poruchy, která pominula a není možné identifikovat při prvotním výskytu její příčinu (neexistují logy, nejsou podklady od Objednatele) a je třeba monitoring v delším časovém úseku, bude zadaná porucha na helpdesku po vzájemné dohodě mezi Poskytovatelem a Objednatelem nebo po souhlasu nebo na žádost Objednatele převedena do specifické kategorie pro tento účel – kategorie „Odloženo“ či „Pozastaveno“ (nebo ekvivalentní stavy dle možností helpdesku). V případě opakovaného výskytu bude porucha znovu otevřena (k datu nahlášení) a řešena v souladu s dohodnutými SLA. Poskytovatel je povinen vyvinout aktivitu k identifikaci příčiny chyby již po prvním výskytu. Při jejím opakovaném výskytu platí v plném rozsahu dohodnutá SLA, lhůta k odstranění počíná běžet okamžikem ohlášení druhého výskytu.

2.2Rozšířená podpora

V rozsahu 100 hodin / čtvrtletí.

Jedná se o služby pro řešení dodatečných požadavků na provoz a využívání Systému nad rámec ostatních uvedených služeb. Služby jsou poskytovány na vyžádání, čerpané a účtované dle skutečně využitých hodin (nejedná se o paušální plnění).

2.2.1Požadované služby

Školení pracovníků Objednatele k Systému.
Analytické a konzultační služby k Systému.
Reporting a analýza dat Systému.
Programové úpravy pro zajištění funkcionality pro částečné procesní změny nebo nové moduly a funkce v rámci Systému, při kterých nevzniká úplně nový Systém (dílo).
Součinnost při řešení systémových problémů a při implementaci systémů třetích stran.
Další Objednatelem požadované Služby ve vazbě na Systém – datové práce v systému, kontrola běhu systému, zakládání uživatelů, ostatní servisní činnosti nad rámec základní technické podpory.
Aktualizace stávající dokumentace Systému o nově dodané či změněné funkce Systému vzniklé v rámci rozšířené podpory.

2.2.2Rozsah poskytovaných služeb

Služby budou zpravidla čerpány ve čtvrtletním (3 měsíčním) cyklu. Tímto není omezena možnost čerpat služby dle potřeby v rámci disponibilních hodin a dle provozních potřeb Objednatele.
Nevyčerpané hodiny v rámci jednotlivých čtvrtletí jsou kumulativně převoditelné a využitelné po celou dobu platnosti smlouvy, po ukončení smlouvy nárok na nevyčerpané služby zaniká.

2.2.3Podmínky poskytování služeb

Objednatel (kontaktní osoba) předloží výzvu na Poskytovatele (kontaktní osobu) obsahující specifikaci požadovaných služeb rozšířené podpory, včetně požadovaného termínu plnění.
Poskytovatel předloží Objednateli nabídku na poskytnutí požadovaných služeb.
1. Termín předložení nabídky Objednateli je do 15-ti kalendářních dnů. Lhůta je závazná a její nesplnění bude pokutováno v souladu se Smlouvou.
2. Nabídka bude oceněna počtem hodin a sazbou dle položkového rozpočtu, který je samostatnou přílohou Smlouvy.
3. V nabídce bude potvrzen termín pro dokončení nebo navržen nový podle možností Dodavatele v kontextu nabízeného rozsahu prací.
4. Pokud požadované služby budou vyžadovat jakékoliv související náklady nad rámec služeb rozšířené podpory (rozšíření licencovaného SW apod.) bude toto nabídka obsahovat včetně nacenění a zdůvodnění.
5. Platnost nabídky bude min. 30 kalendářních dnů.
6. Poskytovatel je povinen analyzovat všechny Objednatelem zadané požadavky, avšak vyhrazuje si právo po provedené analýze odmítnout jejich realizaci. V takovém případě, je povinen Objednateli sdělit důvody odmítnutí realizace zadaného požadavku.
Pokud se Objednatel rozhodne, že přijme nabídku Poskytovatele, zašle Poskytovateli výzvu k poskytnutí služeb dle nabídky („Dílčí objednávku“).
Poskytovatel do 3 pracovních dnů potvrdí přijetí Dílčí objednávky k poskytnutí služeb a zahájí poskytování v souladu se svou nabídkou a Dílčí objednávkou. Poskytovatel není oprávněn nepřijmout Dílčí objednávku, pokud nedošlo ke změně rozsahu poskytovaných služeb nebo neuplynula doba platnosti nabídky Poskytovatele.
Přijetím Dílčí objednávky se termíny dle nabídky Poskytovatele stávají závaznými a jejich nesplnění bude pokutováno v souladu se Smlouvou.
Tyto služby budou odsouhlaseny v rámci výkazu služeb po dokončení a akceptaci plnění (rozšířené podpory).

2.3Vyloučení z předmětu plnění

Infrastruktura, HW a související služby zajišťované Objednatelem uvedené ve výchozím stavu a neuvedený v předmětu plnění a požadavcích v tomto dokumentu.
Součástí služeb není zajištění samotné opravy nebo výměny hardwarových komponent v případě jejich poruchy, havárie nebo ztráty funkčnosti, ani prodloužení záruky a podpory výrobců infrastruktury/zařízení a související služby. Za zajištění záruky a maintenance/podpory výrobce na infrastrukturu/zařízení odpovídá Objednatel včetně nezbytné součinnosti poskytovatele záruky a maintenance/podpory výrobce.
SW adaptéry NIS / KIS pořízené jednotlivými ZZ nezávisle, ale nezbytné pro zajištění standardní funkčnosti Systému. Potřebné zásahy bude řešit Objednatel se ZZ přímo, Poskytovatel však zajistí potřebnou součinnost.
Kvalifikované certifikáty pro zaměstnance ZZS pro potřeby elektronického podpisu.
Kvalifikovaná časová razítka pro ověřování dokumentů v archivech zdravotnické dokumentace v ZZS a v nemocnici Náchod po celou potřebnou dobu archivace.
Přímé služby (včetně zajištění kvalifikovaných časových razítek) související s vybavením umístěným ve Fakultní nemocnici Hradec Králové, které je zajištěno jiným způsobem, mimo nutných koordinací pro zajištění souladu mezi jednotlivými lokalitami tak, aby zásah na jedné straně nemohl ovlivnit funkčnost na straně druhé, případně celého Systému.
Zajištění v rámci požadavků neuvedené komunikační infrastruktury (sítě apod.) mezi jednotlivými prvky systému. ZZS zajistí nezbytná síťová propojení pro realizaci předmětu plnění a provoz řešení.
Zajišťování funkčnosti integrací na další informační systémy Objednatele, které nejsou explicitně uvedeny v rámci výchozího stavu dílčích částí Systému.
Spotřební materiál využívaný v následném provozu informačního systému neuvedený v rámci požadavků na předmět plnění.

2.4Společná definice služeb

2.4.1Ostatní podmínky

Servisní výjezdy (cestovní náklady) do míst plnění na území města Hradec Králové nebudou Poskytovatelem Objednateli účtovány. Ostatní servisní výjezdy na území kraje mohou být Poskytovatelem účtovány dle sazby uvedené v samostatné příloze.
Legislativní úpravy systému v návaznosti na změny legislativy, vyhlášek a nařízení ČR a EU – v rámci paušální platby.
Úpravy nastavení zabezpečení Systému na všech serverech tak, aby bylo v souladu s Best Practices výrobce Systému, jak na úrovni šifrování (pouze bezpečné šifrovací algoritmy a protokoly) na úrovni komunikace, tak i síťového provozu ve vztahu k provozu Systému.
Poskytování součinnosti dalším poskytovatelům služeb zabezpečení provozu integrovaných systémů v rámci poskytování maintenance nebo základní podpory v rámci zabezpečení provozu.
V rámci provozu Systému bude v součinnosti Objednatele a Poskytovatele docházet k instalacím nových verzí SW, bezpečnostních a opravných balíčků systémového SW (OS, DB apod.) a obměna HW a komunikační infrastruktury („modernizované provozní prostředí“). Služby budou na Systém poskytovány i na modernizované provozní prostředí, pokud bude zajištěno ve vzájemné součinnosti s Poskytovatelem nebo nebude v rozporu se standardními požadavky na chod Systému a tento stav může být v rámci výběrového řízení nebo provozu modernizován (změněn/rozšířen/povýšen).

2.4.2Kvalita a záruky

Kvalita služeb bude zcela odpovídat požadavkům kladeným na SW ve shodě s touto Zadávací dokumentací.
Poskytovatel se zavazuje provádět služby v kvalitě odpovídající účelu uvedeným v této specifikaci, obecně závazným předpisům a platným technickým normám.
Poskytovatel nebude odpovídat za jakékoli škody vzniklé Objednateli, ani za neplnění nebo zpožděné plnění svých povinností vyplývajících ze Smlouvy, dojde-li k nim v důsledku působení vyšší moci. Působením vyšší moci se rozumí okolnosti vylučující odpovědnost podle Zákona č. 89/2012 Sb., občanského zákoníku, zejména pak negativní vliv takové škody v době platnosti Smlouvy, nepředvídatelné události (živelná pohroma, průmyslová katastrofa, ozbrojený konflikt, revoluce nebo obdobná změna státního režimu), jejichž výskyt a vliv podstatně působí na plnění Smlouvy, aniž by tomuto vlivu Objednatel a/nebo Poskytovatel mohli s použitím veškerých jim právně dostupných a rozumně požadovatelných prostředků účinně zabránit.

2.4.3Obnova dat, bezpečnost a pravidla pro update aplikace

Poskytovatel nebude odpovědný za ztrátu nebo změnu dat při provozu počítačového systému Objednatele způsobenou používáním systému v rozporu s projektovou dokumentací. Případnou obnovu dat bude provádět Poskytovatel ze záloh vytvářených jím v souladu s požadavky zadávací dokumentace a legislativním rámcem.
Poskytovatel se zaváže zachovat před provedením update serverové části systému nebo jeho části předchozí funkční konfiguraci systému nebo jeho části pro případ její opětovné potřeby.
Poskytovatel v plném rozsahu odpovídá za provádění patch-managementu Systému v rámci serverů a mobilních zařízení a částí provozní a komunikační infrastruktury, kde jsou části Systému provozovány a na které se vztahují servisní služby dle této specifikace.
Nové verze systému a aplikací budou Poskytovatelem předány Objednateli k ověření deklarované funkčnosti. Vlastní implementace nebo instalace bude provedena Poskytovatelem po odsouhlasení Objednatelem. Toto se netýká odstranění závad v rámci plnění základní podpory.

2.4.4Servis vybavení prováděný pracovníky Objednatele

Pracovníkům Objednatele bude umožněno provádět drobné opravy závad vybavení vlastními silami při dodržení všech závazných podmínek a ustanovení jakož i veškerých pracovních postupů a doporučení stanovených Poskytovatelem.
Pracovník Objednatele bude povinen vyžádat si souhlas Poskytovatele v každém případě, kdy nebude zcela jisté, zda bude oprávněn provést danou opravu vlastními silami a současně si vyžádat doporučení vhodného postupu provedení opravy. Souhlas Poskytovatele i jím doporučený pracovní postup musí být zaevidován v helpdesku, provozovaném Poskytovatelem.
Stejně tak veškeré informace o zjištěných závadách a provedených opravách bude Objednatel povinen řádně evidovat prostřednictvím helpdesku, provozovaného Poskytovatelem.
Za opravy provedené pracovníky Objednatele neponese Poskytovatel žádnou zodpovědnost a na tyto opravy nebude poskytovat žádné záruky. Poskytovatel dále neponese žádnou zodpovědnost za jakékoli závady nebo škody, způsobené pracovníky Objednatele při provádění oprav vybavení. Tyto závady nebude možné považovat za chyby informačního systému a případné odstranění těchto závad Poskytovatelem bude placenou službou.

2.5Obecné požadavky

2.5.1Architektura, kompatibilita a perspektiva

Systém splňuje a nadále musí svojí architekturou splňovat obecné zásady informační bezpečnosti v míře, odpovídající charakteru užití a kategorii zpracovávaných dat.
Zachování veškerých stávajících funkcionalit a integrací Systému uvedených ve výchozím stavu v tomto dokumentu dále.
Veškeré provozované SW i HW prvky musí být plně kompatibilní se stávajícími systémy.
Součástí služeb musí být i veškeré potřebné licence Systému a služby nezbytné pro provoz Systému a technologií, které jsou součástí Systému.
Zaručená perspektiva provozu, rozvoje a podpory je minimálně po dobu dalších 10 let od zahájení poskytování služeb.

2.5.2Legislativa a další normy

Xxxxxx s Nařízením Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob (GDPR – General data protection regulation) v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů.
Soulad se Zákonem č. 101/2000 Sb., o ochraně osobních údajů a o změně některých dalších zákonů v aktuálním znění.
Soulad se Zákonem č. 181/2014 Sb., o kybernetické bezpečnosti v aktuálním znění a vyhláškou Vyhláška č. 316/2014 Sb., o kybernetické bezpečnosti v aktuálním znění.
Soulad se Zákonem č. 239/2000 Sb. o integrovaném záchranném systému a o změně některých zákonů v aktuálním znění.
Soulad se Zákonem č. 374/2011 Sb., o zdravotnické záchranné službě v aktuálním znění.
Soulad se Zákonem č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) v aktuálním znění.
Soulad se Zákonem č. 373/2011 Sb., o specifických zdravotních službách v aktuálním znění.
Xxxxxx s Vyhláškou č. 98/2012 Sb., o zdravotnické dokumentaci v aktuálním znění.
Dokumentace bude v souladu se zákonem č. 365/2000 Sb. o informačních systémech veřejné správy a prováděcích právních předpisů, v platném znění.

2.5.3Ostatní obecné požadavky

Zajištění jednotného času na všech pracovištích/zařízeních ve vazbě na NIS IZS (synchronizace klientů a systému s Objednatelem určeným time serverem).
Základní profylaktika v rozsahu: kontrola integrity DB, analýza aplikačních logů, případný návrh opatření pro bezproblémový chod aplikace, atd. min. 1x čtvrtletně.
Po celou dobu plnění smlouvy poskytovatel zajistí sdílenou projektovou knihovnu se všemi aktivy (dokumentace evidence apod.). Veškerá aktiva budou předávána přes tuto sdílenou knihovnu, budou udržovány platné a předané verze, bude zajištěn přístup pro všechny určené zástupce smluvních stran.

2.6Doplňující požadavky

2.6.1Provozní a komunikační infrastruktura (HW) a systémový SW

Objednatel poskytne/zajistí provozní a komunikační infrastrukturu (HW) a systémový SW pro provoz Systému ve stávajícím rozsahu.

Další požadavky na provozní a komunikační infrastrukturu (HW) a systémový SW pro provoz Systému:

Pro systém a jeho provoz objednatel nepředepisuje technologii, jen principy a požadavky na řešení, technologie je navržena a popsána poskytovatelem. Případně nově dodávaný HW a systémový SW musí být plně kompatibilní se stávajícími systémy uvedenými dále v tomto dokumentu.
Infrastruktura pro provoz Systému zůstane beze změny nebo se bude jednat o změny v souladu s předchozím požadavkem. Poskytování služeb Systému bude na stávající infrastruktuře nebo na infrastruktuře dodané Poskytovatelem v rámci předchozího požadavku.
V případě změny provozní a komunikační infrastruktury v průběhu trvání smlouvy budou služby k Systému poskytovány i na této nové provozní a komunikační infrastruktuře za podmínky, že změna bude provedena v součinnosti s Poskytovatelem a odsouhlasena Poskytovatelem. Migrace/instalace Systému na novou provozní a komunikační infrastrukturu není součástí maintenance a základní podpory.
V rámci provozu bude udržováno nastavení zabezpečení Systému na všech serverech tak, aby bylo v souladu s Best Practices výrobce Systému, jak na úrovni šifrování (pouze bezpečné šifrovací algoritmy a protokoly), na úrovni komunikace, tak i síťového provozu ve vztahu k provozu Systému.
V případě zjištěné poruchy na provozní a komunikační infrastruktuře nebo systémovém SW Systému mimo předmět plnění Poskytovatele Poskytovatel provede identifikaci problému a poskytne součinnost při řešení takové poruchy tak, aby v maximální možné míře byla infrastruktura funkční pro provoz Systému.
Předmětem plnění jsou provozní služby pro provozní a komunikační infrastrukturu, tj. pro virtualizaci, DB a operační systémy a síťové prvky serverových částí Systému dle rozsahu a specifikace uvedené dále v tomto dokumentu.

Podpora při detekci, analýze a odstraňování závad a konfiguraci a aktualizaci provozní a komunikační infrastruktury a systémového SW.

V případě obměny / výměny prvků při zachování účelu se služby vztahují na nové zařízení s tím, že na původní zařízení se již nadále nebude poskytovat.

2.6.2Auditní služby

Poskytovatel poskytne součinnost Objednateli pro přístup k záznamu aktivit, spojených s přístupem k osobním údajům v Systému. Přístup k aktivitám bude považován za dostatečný na úrovni přístupu k logu, přístupného určené roli.
Součinnost při poskytování logů/reportů o přístupech uživatelů (kdo, kdy, období, kam) na základě parametrizace prováděné pověřeným uživatelem.
Přístup do auditního (logovacího) aparátu je dostupný pouze určeným rolím což Poskytovatel zajistí i na své straně. Auditní systém není manipulovatelný uživateli, administrátory ani správci. Poskytovatel bude auditní systém využívat v souladu s podmínkami poskytování služeb.
Poskytovatel musí poskytnout součinnost pro automatizované nebo manuální vystoupení logových záznamů do externích systémů pro správu logů (log management, SIEM) a do tabulek MS Excel (.csv, .xlsx).
Poskytovatel bude přistupovat k auditnímu systému nebo pracovat s tímto systémem v souladu s nařízení EU o ochraně osobních dat (GDPR).

2.6.3Bezpečnostní požadavky

Poskytnutí přístupu autentizovaného uživatele k aktivu systému (data, aplikace), na základě požadavku nebo schválení Objednatele odpovídající pracovnímu zařazení uživatele nebo správce a přidělené roli (rolím) v systému. Přístup jednotlivých subjektů jen k údajům, ke kterým mají a mohou mít přístup na základě požadavku nebo schválení Objednatele.
Zabránění vstupu neautorizovaného subjektu do systému – zamezení možnosti přístupu neoprávněného subjektu ze strany Poskytovatele.
Zajištění konfiguračního managementu a správy systému s eliminací rizika ovlivnění chodu systému změnou aplikací 3. stran (unifikace konfigurací Systému, řízený patch management Systému).
Zajištění dostupnosti jednotlivých částí systému podle požadavků uvedených v této dokumentaci/smlouvě.
Využívání dostupné šifrované komunikace mezi všemi součástmi Systému a pracovišti uživatelů/správců, případně zajištění komunikace v odděleném síťovém prostředí. Výjimkou jsou jen vnitřní komunikace v rámci uzavřené části systému, integrace, kde šifrovanou komunikaci neumožňuje integrovaný systém nebo je explicitně vyžadováno Objednatelem.
Poskytovatel musí zajistit součinnost pro přístup a vyhodnocení k evidence přístupů všech uživatelů/správců do Systému (logování) včetně časových údajů.
Poskytovatel musí využívat stávající prostředky pro zabezpečení dat – zabezpečení pomocí řízení přístupu k datům, použití šifrování a ostatních kryptografických prostředků, audit logových záznamů.
Každý dodavatel/subdodavatel bude mít k dispozici jeden doménový účet pro potřeby administrace systému či jeho součástí. V případě využití lokálních účtů bude postupováno obdobně.

2.6.4Požadavky na činnosti při zahájení poskytování služeb a provozní požadavky

Poskytovatel musí být připraven na provoz Systému 24x7x365 (non-stop) a zajistit poskytování služeb k provozovanému Systému dle podmínek v tomto dokumentu uvedených bezprostředně ke dni zahájení plnění.
Revize stavu Systému a technologií při zahájení poskytování služeb, úpravy nastavení, optimalizace běhu a předložení dalších doporučení Objednateli pro optimální poskytování služeb do 30 dnů od zahájení poskytování služeb a dále potom vždy 1x ročně.
Poskytovatel ke dni zahájení poskytování služeb zpracuje provozní podmínky a požadavky na součinnost objednatele. Jedná se především o požadavky na maintenance, kapacity a výkon HW a komunikační infrastruktury a systémový SW, který není předmětem plnění této smlouvy.
Předmětem zakázky jsou i veškeré související služby – doprava, instalace, implementace do stávající infrastruktury, konfigurace a zprovoznění komunikace, nastavení datových toků, seznámení s obsluhou a správou systému pro správce v případě nových verzí, testování nových verzí v prostředí Objednatele, bezplatné preventivní prohlídky v rámci poskytování servisních služeb. Veškeré seznámení s obsluhou bude probíhat v prostorách objednatele a v českém jazyce. Součástí nabídkové ceny musí být i veškeré práce či činnosti, které v této zadávací dokumentaci nejsou explicitně uvedeny, ale které musí poskytovatel s ohledem na jím nabízený předmět veřejné zakázky a jeho řádnou a úplnou realizaci provést k dosažení objednatelem požadovaného cílového stavu.
V případě upgrade Systému nebo jeho části je součástí plnění také instalace upgrade Systému nebo jeho části do prostředí objednatele a na provozní infrastrukturu.
V případě upgrade Systému nebo jeho části a uvedení upgradovaného Systému nebo jeho části do provozu musí poskytovatel zajistit plnohodnotný provoz upgradovaného řešení současně s provozem stávajících systémů, to vše bez jakéhokoliv omezení provozu. V takovémto případě Poskytovatel do nabídky popíše postup přechodu systémů. Poskytovatel je povinen přizpůsobit realizaci předmětu zakázky podmínkám Objednatele.
Využití administrátorských aplikací/konzolí Systému pro všechny součásti systému pro zajištění konfiguračního managementu systému anebo jeho součástí, zajišťování konfigurace Systému.
Dohled – součinnost při napojování Systému do dohledového systému Objednatele, minimálně na úrovni protokolu SNMP. Poskytovatel poskytne součinnost při definici parametrů a podmínek pro potřeby dohledu a součinnost při nastavení dohledu dodaného řešení.
Synchronizace času všech zařízení s Objednatelem určeným time serverem nebo zprostředkovaně přes centrální systém.
Aktualizace nebo vytvoření provozní dokumentace Systému a její udržování aktuální po celou dobu poskytování služeb.
Zaškolování správců systému se změnami v konfiguraci a obsluhy (v případě změn). V případě upgrade systému nebo jeho části je součástí zaškolení i koncových uživatelů.
Pokud dojde k upgrade Systému nebo jeho části, je součástí zpracování Implementační analýzy včetně návrhu řešení (konkretizace implementačního postupu, přesné konfigurace a instalačního a montážního návrhu řešení z nabídky), která bude zahrnovat informace pro všechny aktivity potřebné pro řádné zajištění implementace upgrade Systému a uvedení do provozu. Implementační analýza včetně návrhu řešení musí být před zahájením prací schválena objednatelem. Implementační analýza včetně návrhu řešení musí zohlednit podmínky stávajícího stavu, požadavky cílového stavu a uvedení do provozu bez negativních dopadů na provoz Objednatele a nesmí pro Objednatele znamenat další náklady nad rámec plnění této smlouvy.
Zajištění kontinuity provozu ZZS KHK. Po stránce nepřetržitého provozu ZZS KHK předpokládá případné odstávky pouze na minimální nezbytnou dobu, neohrožující poskytování PNP významným snížením informační podpory dispečerů a pracovníků výjezdových skupin.
Požaduje se kontinuita (převzetí či využití) nastavených parametrů, všech číselníků, definic a jiných aspektů provozu. Nepředpokládá se investice do opětovného zadávání a pořizování těchto údajů v případě upgrade Systému nebo jeho části.
Současné funkcionality systémů, technologií a pracovišť stávajícího systému IS ZZS KHK zůstanou zachovány, nebudou žádným způsobem pro uživatele upravovány a nebudou negativně dotčeny zahájením poskytování služeb.
V případě upgrade Systému nebo jeho části jsou součástí i následující služby (platí jen pro upgrade Systému nebo jeho část):

Projektové řízení dodávky řešení.
Zpracování Analýzy a návrhu řešení – konkretizace implementačního postupu, přesné konfigurace a instalačního a montážního návrhu řešení z nabídky, související konzultace k dodávanému Systému nebo jeho části.
Dodávka, implementace, instalace, konfigurace dodávané HW a SW infrastruktury (pokud je stávající infrastruktura nedostatečná a vyžaduje náhradu/doplnění).
Vývoj/rozvoj systému a jeho součástí.
Implementace informačního systému a jeho součástí.
U částí, kde dojde k upgrade části systému nebo technologie provedení výchozího importu datových zdrojů a metadat do systému ze stávajícího systému do systému po upgrade (initial load, bude-li třeba dle výstupu implementační analýzy).
Ověření funkčnosti dodaného systému a jeho částí.
Dodávka dokumentace dodaného systému a jeho částí (min. uživatelská dokumentace, dokumentace skutečného provedení, systémová dokumentace, projektová dokumentace).
Zaškolení uživatelů a administrátorů – seznámení s funkcionalitami, obsluhou dodávaného systému a jeho budoucím provozem.
Zařazení do provozního prostředí žadatele (dohled, zálohování apod.).
Provedení zkušebního provozu.
Poskytnutí záruky 3 roky na informační systém a 3 roky na provozní infrastrukturu a systémový SW.

3Místa plnění

Realizace předmětu plnění bude probíhat v následujících místech plnění:

Místo

Adresa

Předmět realizace

Zdravotnická záchranná služba Královéhradeckého kraje (ředitelství)

Hradecká 1690/2a, Hradec Králové

PSČ: 500 12

Záložní datové centrum ZZS KHK

V této lokalitě budou probíhat případné servisní zásahy vyžadující osobní přítomnost zástupce Poskytovatele bez nutnosti fyzického přístupu k technologiím primárního DC.

Sídlo ZZS KHK – místo předávání poskytovaných služeb.

Zdravotnická záchranná služba Královéhradeckého kraje (dispečink)

Pražská 230/153z, Hradec Králové

PSČ: 500 04

Primární datové centrum ZZS KHK – umístění Systému a klíčových technologií, návaznost na technologie umístěné v tomto DC a případná dodávka částí technologie.

Poskytování servisních služeb pro Systém a technologie umístěné v této lokalitě.

Také označováno jako „Bláhovka“.

Fakultní nemocnice Hradec Králové

Sokolská 581

500 05 Hradec Králové

Poskytování součinnosti při servisních pracích na SW či technologiích umístěným ve zdravotnickém zařízení, které jsou zajišťovány samostatně, tj. mimo rozsah popsaný v tomto dokumentu.

Oblastní nemocnice

Náchod

Purkyňova 446

547 01 Náchod

Poskytování servisních služeb k SW a technologiím umístěným ve zdravotnickém zařízení.

Oblastní nemocnice

Trutnov

Xxxxxx Xxxxxxx 77, Kryblice

541 01 Trutnov

Poskytování servisních služeb k SW a technologiím umístěným ve zdravotnickém zařízení.

Nemocnice

Jičín

Bolzanova 512

506 01 Jičín

Poskytování servisních služeb k SW a technologiím umístěným ve zdravotnickém zařízení.

Městská nemocnice

Dvůr Králové n/L

Vrchlického 1504

544 01 Dvůr Králové nad Labem

Poskytování servisních služeb k SW a technologiím umístěným ve zdravotnickém zařízení.

Nemocnice

Rychnov nad Kněžnou

Xxxxxxxxx 506

516 23 Rychnov nad Kněžnou

Poskytování servisních služeb k SW a technologiím umístěným ve zdravotnickém zařízení.

Nemocnice

Vrchlabí

Fügnerova 50,

543 01 Vrchlabí

Poskytování servisních služeb k SW a technologiím umístěným ve zdravotnickém zařízení.

4Výchozí stav

4.1Zdravotnická záchranná služba Královéhradeckého kraje (Objednatel/Zadavatel)

Pojmy Zadavatel a Objednatel jsou ekvivalentní. V rámci VZ je význam pojmu Objednatele totožný s pojmem Zadavatel, v rámci plnění smlouvy je význam pojmu Zadavatel totožný s pojmem Objednatel.

Kontext ZZS KHK v rámci řešení projektu je následující:

ZZS KHK plní úkoly k zajištění zvláštní zdravotní péče fyzickým osobám, které se náhle nebo nečekaně ocitly v ohrožení zdraví či života, tedy nepřetržitě zabezpečuje odbornou přednemocniční neodkladnou péči včetně přednemocniční péče o dárce a příjemce orgánů v souladu s příslušnými právními předpisy a pokyny zřizovatele a za plnění těchto úkolů odpovídá.
V rámci svých činností ZZS KHK mimo jiné zajišťuje také předání zdravotnické dokumentace elektronickou cestou jako součást transportu pacienta do zdravotnického zařízení, kde je tato dále zprostředkována kvalifikovanému zdravotnickému personálu prostředky NIS / KIS. Pro vlastní potřebu k tomu využívá historických informací poskytovaných jednotlivými ZZ.
Poskytování služeb ZZS KHK je zajišťováno s využitím Systému (eHealth) a souvisejících technologií. Systém a související technologie a jejich garantovaný provoz jsou podmínkou nutnou pro poskytování služeb ZZS KHK. Popis Systému a technologií je uveden dále v tomto dokumentu.

4.2Popis řešení

Systém eHealth KHK je informační systém pro zpřístupnění zdravotnické dokumentace mezi zdravotnickými zařízeními s působností na území Královéhradeckého kraje a Zdravotnickou záchrannou službou Královéhradeckého kraje.

Řešení eHealth KHK se logicky skládá z následujících částí:

Krajského komunikačního centra
Krajské komunikační brány pro NCPeH ČR pro účely Portálu občana
Archivů zdravotnické dokumentace (včetně zaručených certifikátů a časových razítek)
Komunikačních uzlů
Specifických úprav software EKP/MZD

Uvedené části jsou instalovány na příslušné hardwarové a síťové infrastruktuře.

Řešení pokrývá následující zdravotnická zařízení:

Zdravotnická záchranná služba Královéhradeckého kraje
Oblastní nemocnice Náchod

Nemocnice Jaroměř
Poliklinika Opočno
Nemocnice Nové Město nad Metují
Nemocnice Broumov
Nemocnice Rychnov nad Kněžnou

Oblastní nemocnice Trutnov
Oblastní nemocnice Jičín

Nemocnice Nový Bydžov

Městská nemocnice Dvůr Králové n/L
Nemocnice Vrchlabí
Fakultní nemocnice Hradec Králové

Řešení je otevřené pro napojení dalších zdravotnických zařízení s působností na území Královéhradeckého kraje.

Řešení je prostřednictvím komunikační brány ISAC GateWay připojeno k NCPeH České republiky pro účely komunikace s Portálem občana.

4.2.1Základní koncept řešení eHealth KHK

Řešení eHealth KHK je reprezentováno informačním systémem pro výměnu citlivých osobních údajů pacienta mezi zdravotnickými zařízeními působícími na území Královéhradeckého kraje.

Komunikační informační systém vychází z konceptu distribuovaného systému. Předávané informace nejsou centrálně uchovávány ani kopírovány.

Informace jsou vždy předávány na základě žádosti oprávněného uživatele. Informace jsou vyhledávány v primárních produkčních systémech provozovaných ve zdravotnických zařízeních (klinické informační systémy) a jsou předávány přímo žadateli.

Události o realizovaných případech výměny informací jsou vždy důsledně logovány do auditních databází, ke kterým mají následně přístup pověření bezpečnostní manažeři pro kontrolu funkčnosti systému a kontrolu oprávněnosti přístupu k informacím.

4.2.2Krajské komunikační centrum

Základním stavebním kamenem informačního systému pro zpřístupnění zdravotnické dokumentace je Krajské komunikační centrum (dále také KKC). Jeho hlavním úkolem je zajistit bezpečnou a důvěryhodnou výměnu datových zpráv mezi zapojenými zdravotnickými zařízeními.

Zdravotnická zařízení se připojují ke Krajskému komunikačnímu centru prostřednictvím komunikačního uzlu (viz. text dále).

Krajské komunikační centrum je provozováno v rámci Datového centra Zdravotnické záchranné služby Královéhradeckého kraje na hardwarové a síťové infrastruktuře (není předmětem požadavků).

Centrum je tvořeno software ISAC Centre s následujícími komponentami:

Centrum výměny zpráv
Centrální auditní databáze událostí

Centrum výměny zpráv udržuje fronty zpráv pro každé zapojené zdravotnické zařízení. Čtení zpráv z fronty je povoleno pouze pro vlastníka fronty, zápis zpráv je pak povolen všem zapojeným komunikačním uzlům.

Systém zpráv se využívá jak pro asynchronní předávání zpráv mezi zdravotnickými zařízeními, tak také pro případy vyhledávání informací a jejich zpřístupnění žadateli.

Centrum výměny zpráv umožňuje dočasné uchování zprávy v případě, že příjemce zprávy není krátkodobě dostupný. V případě překročení stanoveného časového limitu nedostupnosti příjemce je zpráva trvale smazána a je informován dohled systému.

Komunikační uzly se připojují k centru výměny zpráv s využitím zabezpečeného kanálu SSL/TLS se serverovým certifikátem centra.

Pro ověření identity komunikačního uzlu při komunikaci s Krajským komunikačním centrem se používá přihlášení jménem a heslem, které jsou přiděleny výlučně každému zapojenému komunikačnímu uzlu.

Centrální auditní databáze událostí přijímá, uchovává a zpřístupňuje základní údaje o všech žádaných a realizovaných přenosech informací mezi subjekty zapojenými do informačního systému zpřístupnění zdravotnické dokumentace. Ukládané údaje se týkají všech podporovaných klinických událostí i administrativní záznamy.

Centrální auditní databáze obsahuje anonymizované údaje, ze kterých není možné zjistit osobní údaje pacienta, kterého se daná klinická událost týkala. Nicméně zahrnuje jednoznačné identifikátory událostí, které umožňují dohledání informací o klinickém případu údajů v odpovídajících klinických systémech pro oprávněné osoby.

K centrální auditní databázi má přístup Zadavatelem pověřený pracovník.

4.2.3Krajská komunikační brána pro NCPeH ČR pro účely Portálu občana

Součástí eHealth KHK je komunikační brána ISAC GW, která zajišťuje komunikaci s NCPeH prostřednictvím příslušného API NCPeH pro Patient Summary (pacientský souhrn) za účelem komunikace s Portálem občana.

Vlastnosti ISAC GW:

Slouží jako rozhraní pro napojení na Centrum výměny zpráv projektu eHealth KHK.
Jako základní nástroj zpracování zpráv používá Apache Camel.
Zajišťuje napojení na NCPeH prostřednictvím API národního konektoru (NC) pro získávání Patient summary (pacientský souhrn, dále PS) (viz. projekt NIXZD – xxx.xxxxx.xx).
Podporované služby/dokumenty jsou - zasílání požadavků/odpovědí na dotaz o existenci PS ve ZZ zapojeném do projektu eHealth KHK, předání vyžádaného PS na základě informací z předchozí služby.

4.2.4Archivy zdravotnické dokumentace

Součástí eHealth KHK jsou archivy zdravotnické dokumentace (dále jen AZD), které slouží k archivaci výjezdových zpráv pouze v elektronické podobě v souladu s legislativními podmínkami vedení zdravotnické dokumentace pouze v elektronické podobě.

Přejímací lékař ZZ v IS MZD podepisuje biometrickým podpisem výjezdovou zprávu. Vedoucí výjezdové skupiny podepisuje zprávu svým osobním certifikátem. Před podpisem je zpráva zobrazena podepisujícímu pracovníkovi, aby byla splněna legislativní podmínka – náhled na podepisovanou zprávu. Takto vytvořená zpráva se převede ještě na tabletu do formátu PDF/A. K tomuto souboru je vygenerován navíc soubor s metadaty popisující dokument, pacienta a daný případ. Tyto dva soubory jsou pak předány komunikačním uzlům. Všechny tyto zprávy jsou dále ukládány jak do archivu daného zdravotnického zařízení (v případě nemocnic ZH KHK pak do společného AZD – viz. dále) jako součást pacientské dokumentace, tak v AZD ZZS. Zákon umožňuje vedení zdravotnické dokumentace pouze v elektronické podobě za splnění legislativních podmínek. Instalované archivy umožní vedení těchto výjezdových zpráv pouze v elektronické podobě, a především jejich archivaci bez nutnosti tyto zprávy tisknout, to vše dle legislativních podmínek pro vedení zdravotnické dokumentace pouze v elektronické podobě. Tyto výjezdové zprávy jsou označovány jako ZOV (Zpráva o výjezdu). Vedle toho jsou do AZD ukládány též tzv. POV (protokoly o výjezdu), které obsahují další informace doplněné pracovníky ZZS po vlastním výjezdu v IS EKP/MZD. Tyto POV již nejsou zdravotnickou dokumentací, a proto na ně nejsou kladeny příslušné nároky na archivaci a slouží pouze pro interní potřeby ZZS.

Součástí eHealth KHK jsou 4 AZD, které jsou reprezentovány software AZD a jsou umístěny v:

ZZS Královéhradeckého kraje,
Oblastní nemocnici Náchod (pro všechna ZZ ZH KHK),
Nemocnici Vrchlabí,
Fakultní nemocnici Hradec Králové.

V archivech nemocnic jsou ukládány pouze zprávy týkající se pacientů, kteří byli do těchto zdravotnických zařízení převezeni. V AZD ZZS jsou uloženy všechny výjezdové zprávy.

AZD se skládá ze dvou komponent - AZD Archivu a AZD adaptéru.

XXX adaptér má na starosti příjem předávaných výjezdových zpráv ve formátu PDF/A s podpisy lékařů/zdravotníků (biometrický a podpis certifikátem) s příslušnými metadaty. Adaptér umožní oražení dané zprávy časovým razítkem a uložení do archivu. Pro správné uložení (identifikace pacienta, výjezdu, atd.) se využívají metadata uložená současně se zprávou. AZD Archiv dokument přijme, ověří platnost podpisu, posbírá CRL listy a certifikáty až k autoritě a orazí časovým razítkem. Proto se tento dokument, ještě za platnosti systémového certifikátu, znovu přerazítkuje (včetně CRL a celé cesty k autoritě). Tímto je zaručena informace do budoucna, že dokument s podpisem je stále platný a může se v případě potřeby zkonvertovat autorizovanou konverzí do papírové podoby.

Časová razítka:

Součástí řešení eHealth KHK jsou také časová razítka, pomocí kterých jsou ukládané zprávy oraženy a poté uloženy v archivu. V archivu pak funguje automatický mechanismus přerážení uložených dokumentů tak, aby byl řetězec certifikátu a razítek stále platný a mohlo se tak kdykoliv ověřit původní podpis.

Součástí řešení je také komunikace s CA za účelem ověření elektronického podpisu a získání časového razítka.

Předávání dat z AZD ZZS KHK do Portálu občanu:

Součástí řešení eHealth KHK je předávání informace o existenci a následně také vlastního dokumentu časově nejnovější výjezdové zprávy na Portál občana. Řešení podporuje případ užití, kdy se občan regulérně identifikuje/autentizuje na Portálu občana (prostřednictvím NIA) a prostřednictvím infrastruktury (řetězce) eGonServiceBusu - NCPeH – ISAC GW KHK – ISAC ZZS KHK – AZD ZZS KHK získá k náhledu svou poslední výjezdovou zprávu, uloženou v AZD v ZZS KHK.

Seznam software AZD uzlů s jejich umístěním:

Software	Umístění	Počet	Záložní řešení	Specifické adaptéry
ISAC AZD	ZZS Královéhradeckého kraje	2	ano	pro Portál občana
ISAC AZD	Oblastní nemocnice Náchod (pro ZH KHK)	2	ano	mpa, Stapro H, Stapro FONS Akord, Stapro Medea
ISAC AZD	Nemocnice Vrchlabí	vlastní		Stapro FONS Akord
ISAC AZD	Fakultní nemocnice Hradec Králové	2	ano	AMIS*H

4.2.5Komunikační uzly

Jednotlivá zdravotnická zařízení se připojují ke Krajskému komunikačnímu centru prostřednictvím komunikačních uzlů ISAC CN (dále také KU). Software komunikačních uzlů je instalován v rámci interní sítě daného zdravotnického zařízení na jeho vlastní hardwarové infrastruktuře (není tedy součástí požadavků).

Komunikační uzly zajišťují následující oblasti služeb:

Vytvoření bezpečného a důvěryhodného síťového propojení mezi daným zdravotnickým zařízením a komunikačním centrem:

KU vytváří s centrem TCP spojení zabezpečené SSL/TLS s využitím serverových certifikátů vydaných komunikačním centrem.
KU se vůči centru identifikuje jemu přiděleným jménem a heslem.

Oboustranná výměna zpráv s komunikačním centrem:

Vyměňované zprávy se týkají všech klinických případů užití (viz. dále).
Pro výměnu zpráv mezi komunikačním uzlem a centrem výměny zpráv se využívá protokol OpenWire.
V případě krátkodobé nedostupnosti příjemce zprávy je zpráva uložena ve frontě, po připojení příjemce k frontě jsou mu předány všechny dostupné zprávy z jeho fronty. Příjemcem se v tomto případě rozumí komunikační uzel zdravotnického zařízení, kterému je zpráva určena.

Technicky to je realizováno tak, že zpráva je zapsána do fronty přidělené danému zdravotnickému zařízení. V případě, že se komunikační uzel připojí k centru, napojuje se na svou frontu zpráv, ze které vyčte všechny čekající zprávy.

Na tomto místě je potřeba ještě dodat, že každá zpráva (dle svého typu) má stanoveno tzv. TTL (dobu životnosti zprávy obvykle v jednotkách sekund). Pokud není zpráva z fronty přečtena do vypršení TTL, je automaticky z fronty odstraněna a zničena.

Napojení na datové adaptéry:

Komunikační uzel pro zajištění jednotlivých klinických případů komunikuje s datovým adaptérem, který poskytuje a přijímá data pro daný klinický informační systém (datové adaptéry nejsou součástí požadavků).

Webové rozhraní pro poskytování uživatelských a administrátorských služeb:

Autentizace a autorizace uživatele ZZ prostřednictvím účtu a hesla.
Ověření přístupových údajů je možné proti lokální databázi nebo proti centrálně udržované správě identit uživatelů ZZ v AD/LDAP.
Webové uživatelské rozhraní je připraveno tak, aby se jeho vzhled přizpůsobil velikosti a typu zařízení, které uživatel využívá. Komunikační uzly zahrnují také licenci na instalovaný software, který se vztahuje na neomezenou dobu a neomezené užití všech níže uvedených klinických případů pro veškerý zdravotnický personál zdravotnického zařízení, ve kterém je komunikační uzel instalován/provozován.

Licence ISAC CommunicationNode se v rámci eHealth KHK vztahují na tyto klinické případy užití, resp. služby:

tzv. Emergency Card – emergency údaje pacienta,
náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS,
výjezdová zpráva – elektronické předání výjezdové zprávy do NIS cílového ZZ (a to, jak prostřednictvím předání DASTA zpráv do cílového NIS přes příslušný datový adaptér, tak prostřednictvím archivu zdravotnické dokumentace),
informace o dostupném lůžkovém fondu.

Pro ISAC CommunicationNode v ZZS KHK je dále poskytována služba „předávání informace o výjezdové zprávě pro Portál občana“.

Pro ISAC CommunicationNode v Nemocnici Jičín je dále poskytována služba „předávání informace o poslední hospitalizační zprávě pro Portál občana“.

Seznam software ISAC CN komunikačních uzlů s jejich umístěním:

Software	Umístění	Počet	Záložní řešení	NIS/MZD
ISAC CN	ZZS Královéhradeckého kraje	2	ano	MZD
ISAC CN	Oblastní nemocnice Náchod	2	ano	Stapro Medea
ISAC CN	Nemocnice Rychnov nad Kněžnou	2	ano	Stapro Medea
ISAC CN	Oblastní nemocnice Trutnov	2	ano	Stapro H
ISAC CN	Oblastní nemocnice Jičín	2	ano	mpa
ISAC CN	Městská nemocnice Dvůr Králové n/L	2	ano	Stapro FONS Akord
ISAC CN	Nemocnice Vrchlabí	1	ne	Stapro FONS Akord
ISAC CN	Fakultní nemocnice Hradec Králové	2	ano	AMIS*H

4.2.6Specifické úpravy software EKP/MZD

Rozsah (vymezení části) SW EKP/MZD:

Elektronické podepisování výjezdových zpráv konkrétní osobou z posádky ZZS (pomocí zaručeného elektronického podpisu založeném na kvalifikovaném certifikátu) a také přijímajícím zaměstnancem ZZ s využitím biometrického podpisu na tabletu posádky ZZS.
Management kvalifikovaných certifikátů.
Předávání výjezdových zpráv ZOV a POV mezi MZD a ISAC.

4.2.7Klinické případy užití

Řešení plně pokrývá všechny nezbytné technologické služby spojené s následujícími případy klinického užití systému pro zpřístupnění zdravotních informací:

Životní údaje pacienta.
Předání výjezdové zprávy do klinického systému.
Tvorba výjezdové zprávy ZZS a příprava na archivaci.
Náhled na propouštěcí a ambulantní zprávy.
Informace o dostupném lůžkovém fondu.
Komunikace s Portálem občana.

Všechny výše uvedené služby i jejich řešení je detailně specifikováno v následujících kapitolách.

4.2.7.1Životní údaje pacienta

Tato služba poskytne zasahujícímu vedoucímu výjezdové skupiny základní zdravotní informace o pacientovi, které jsou vedeny v rámci klinických informačních systémů zapojených nemocnic (tzv. zdravotní profil pacienta).

Do zdravotního profilu pacienta patří identifikační údaje pacienta a informace o jeho trvalém bydlišti, dále pak urgentní informace, alergie, rizikové faktory, trvalé diagnózy a trvalé medikace, souhrnná anamnéza, přehled návštěv jednotlivých zdravotnických zařízení (ambulantní a hospitalizační).

Vedoucí výjezdové skupiny si může o zdravotní profil pacienta požádat prostřednictvím svého mobilního zásahového zařízení (tablet), kde je tato služba integrována do software mobilního zařízení, případně prostřednictvím správcovského webového rozhraní komunikačního uzlu instalovaného v rámci ZZS.

Vedoucí výjezdové skupiny se k aplikaci přihlašuje prostřednictvím svého vyhrazeného osobního účtu a hesla z databáze uživatelů ISAC komunikačního uzlu.

Dotaz na zdravotní profil pacienta je z komunikačního uzlu žadatele distribuován na komunikační uzly všech připojených zdravotnických zařízení, a to opět prostřednictvím Centra výměny zpráv.

Komunikační uzly zdravotnických zařízení přijmou žádost o zdravotní profil pacienta. Provedou ověření oprávněnosti žádosti dle svých pravidel řízení přístupu k poskytovaným službám. V případě splnění všech správcem komunikačního uzlu zadaných nezbytných předpokladů poskytnutí odpovědi, požádají o vyhledání žádaných informací datový adaptér klinického systému a odpověď předají zpět žadateli.

Komunikační uzel žadatele provede spojení všech došlých odpovědí do jednoho výsledného přehledu, který je pak předán žádajícímu vedoucímu výjezdové skupiny k nahlédnutí. Každá služba poskytuje svůj výstup přes webový server komunikačního uzlu.

Výstup je možné požadovat v následujícím tvaru:

Webová stránka v HTML5 + JavaScript
Webová služba – data ve formátu XML nebo JSON

První tvar je vhodný pro náhled člověka/uživatele, druhý je možné použít pro integraci s jiným systémem a zobrazení výsledku v tomto systému.

Takto jsou podporovány následující typy služeb:

Vytvoření požadavku na životní údaje pacienta,

požadavek na životní údaje se realizuje voláním webového uživatelského rozhraní,
požadavek obsahuje parametry pro vyhledání záznamu pacienta (rodné číslo),
komunikační uzel žadatele připojuje k žádosti identifikační údaje žádajícího vedoucího výjezdové skupiny a žádajícího zdravotnického zařízení,
jsou identifikována všechna zdravotnická zařízení, kam se žádost odešle.

Příjem požadavku na životní údaje pacienta.
Ověření přístupových oprávnění na základě identifikace žádajícího zdravotnického zařízení.
Vytvoření odpovědi životních údajů pacienta,

jsou vyhledány životní údaje pacienta v KIS,
je vytvořena odpověď, do které jsou doplněny identifikační údaje odesílajícího zdravotnického zařízení,
je vytvořen auditní záznam.

Příjem a zobrazení odpovědi životních údajů pacienta,

očekávají se odpovědi od všech oslovených zdravotnických zařízení,
provádí se sloučení všech odpovědí do výsledného přehledu,
výsledek se předává žadateli jako výstup webového dotazu v požadovaném formátu (HTML, XML nebo JSON),
je proveden auditní záznam.

4.2.7.2Předání výjezdové zprávy do klinického systému

Zasahující vedoucí výjezdové skupiny v průběhu zásahu a při předání pacienta na příjmovém místě nemocnice pořizuje zprávu o výjezdu ZZS. Zprávu pořizuje elektronicky na svém mobilním zařízení.

Po dokončení zprávy komunikační systém umožňuje tuto zprávu v elektronické podobě předat do přijímající nemocnice a zařadit jí do dokumentace pacienta vedené v nemocničním systému.

Po dokončení (editaci a podpisech) zprávy vedoucí výjezdové skupiny zadá její odeslání na svém mobilním zařízení. Zpráva je ze systému MZD ZZS předána do komunikačního uzlu instalovaného v rámci ZZS. Zde je zpráva převedena do standardizovaného formátu DASTA ver.3 a předána prostřednictvím Centra výměny zpráv do komunikačního uzlu přijímající nemocnice.

Odtud je zpráva předána datovému adaptéru klinického systému, který ji zařadí do pacientské dokumentace.

Takto jsou podporovány následující typy služeb:

odeslání výjezdové zprávy ZZS,
příjem výjezdové zprávy ZZS.

Výjezdovou zprávu ZZS ve fázi rozpracovanosti je možné do KIS odeslat opakovaně. V případě opakovaného odeslání se každá následující zpráva ukládá jako další zpráva pro pacienta v KIS. Finální uzavřená výjezdová zpráva, stvrzená podpisovým vzorem, není žádný způsobem editovatelná.

4.2.7.3Tvorba výjezdové zprávy ZZS a příprava na archivaci

Výjezdová zpráva je vytvořena standardním způsobem v aplikaci Mobilního zadávání dat. Po vyplnění zprávy má uživatel možnost v náhledu aplikace zprávu vytisknout na tiskárně a/nebo elektronicky podepsat a odeslat do ZZ. Výjezdová zpráva je elektronicky podepsána jak konkrétní osobou z posádky ZZS (pomocí zaručeného elektronického podpisu založeném na kvalifikovaném certifikátu) tak také přijímajícím zaměstnancem ZZ s využitím biometrického podpisu na tabletu posádky (pomocí elektronického pera na displeji tabletu). Výjezdová zpráva za stranu ZZS je elektronicky podepisována vedoucím výjezdové skupiny, kterým je u výjezdové skupiny RLP a RV lékař a u skupiny RZP záchranář. Zpráva v podobě PDF/A je následně elektronicky přenesena do centra ZZS, kde je dlouhodobě archivována v odpovídajícím archivu zdravotnické dokumentace. V případě, že je pacient směřován do FN HK, nemocnice Vrchlabí či nemocnice Náchod a jejich podřízených ZZ, je stejná zpráva elektronicky přenesena též do archivu tohoto zdravotnického zařízení. Detailní popis AZD je v kapitole Archivy zdravotnické dokumentace výše v tomto dokumentu.

Kvalifikované certifikáty uživatelů jsou uloženy v centrální databázi systému a jejich distribuce na jednotlivá zařízení probíhá prostřednictvím aplikace MZD. Po úspěšném přihlášení uživatele do aplikace je na tablet stažen certifikát, který je lokálně uložen a umožňuje tak vytvořit a podepsat dokument i bez dostupného datového spojení. Po odhlášení z aplikace je certifikát opět smazán.

V případě nedostupnosti datového spojení v době podpisu dokumentu je tento dokument zařazen do fronty, která je odeslána s obnovením komunikace. Elektronický podpis dokumentu je možný i bez aktuálně dostupného spojení pouze v případě, že v době od přihlášení uživatele do aplikace MZD bylo datové spojení se serverem alespoň jednou navázáno a mohl tak být lokálně stažen odpovídající kvalifikovaný certifikát.

Ukládání certifikátů do centrální databáze systému MZD je prováděno s pomocí vybraných administrátorů ZZS, kteří mohou pomocí aplikačního klienta certifikáty pro jednotlivé uživatele vkládat.

Časovým razítkem je dokument opatřen teprve ve chvíli uložení do archivu.

4.2.7.4Náhled na propouštěcí a ambulantní zprávy

Služba úzce navazuje na službu zobrazení životních údajů pacienta.

V části zobrazující seznam návštěv pacienta v jednotlivých zdravotnických zařízeních (jedná se o ambulantní návštěvy a hospitalizace) je možné stiskem tlačítka vyžádat náhled na dokument vztahující se k danému klinickému případu.

Žádost o náhled je jednoznačně specifikována identifikačním číslem klinického případu z daného KIS. Žádost je z komunikačního uzlu žadatele předána komunikačnímu uzlu v tom zdravotnickém zařízení, kde byla návštěva pacienta uskutečněna.

Příjemce žádosti provede ověření oprávnění tak, že je žádost vždy porovnávána s přístupovými pravidly ke službám nastavenými správcem komunikačního uzlu. V kladném případě požádá datové rozhraní KIS o odpovídající zprávu. Ta je převedena do formy odpovědi a odeslána žadateli.

Výsledek je zobrazen zasahujícímu vedoucímu výjezdové skupiny k nahlédnutí v rámci webového uživatelského rozhraní. Každá služba poskytuje svůj výstup přes webový server komunikačního uzlu.

Výstup je možné požadovat stejným způsobem jako u životních údajů pacienta (v kapitole výše).

Takto jsou podporovány následující typy služeb:

Vytvoření požadavku na náhled dokumentu,

požadavek na náhled dokumentu se realizuje voláním webového uživatelského rozhraní,
požadavek obsahuje parametry pro vyhledání záznamu klinického případu (ID klinického případu),
komunikační uzel žadatele připojuje k žádosti identifikační údaje žádajícího vedoucího výjezdové skupiny a žádajícího zdravotnického zařízení,
je identifikováno zdravotnické zařízení, kam se žádost odešle (kde je klinická událost vedena).

Příjem požadavku na náhled dokumentu,

provádí se ověření přístupových oprávnění na základě identifikace žádajícího zdravotnického zařízení.

Vytvoření odpovědi na náhled dokumentu,

je vyhledán záznam klinického případu v KIS,
je vytvořena odpověď, do které jsou doplněny identifikační údaje odesílajícího zdravotnického zařízení,
je vytvořen auditní záznam.

Příjem a zobrazení odpovědi na náhled dokumentu,

očekává se odpověď od osloveného zdravotnického zařízení,
výsledek se předává žadateli jako výstup webového dotazu v požadovaném formátu (HTML, XML nebo JSON),
je proveden auditní záznam.

4.2.7.5Informace o dostupném lůžkovém fondu

Systém podporuje získávání informací o disponibilní lůžkové kapacitě v rámci jednotlivých nemocnic zapojených do systému.

Službu obvykle využívá pověřený pracovník dispečinku ZZS, který v případě hromadných mimořádných událostí nebo v případě specializovaných požadavků na urgentní péči o pacienta, zjišťuje volnou lůžkovou kapacitu v nemocnicích a podle výsledků směruje záchranné vozy.

Dotaz na volnou lůžkovou kapacitu je odesílán do všech zapojených nemocnic, kde jsou všechny potřebné informace vyhledávány v produkčním systému (nemocniční informační systém).

Výsledky jsou agregovány do jednoho přehledu, který je zobrazen žadateli.

Vyhledávané informace zahrnují:

název nemocnice,
název a odbornost oddělení,
stav oddělení,
počty volných lůžek, doplněno o informace o podpoře ventilace,
dodatečně uvolnitelná lůžka,
datum a čas aktualizace informace.

Výsledný přehled umožňuje filtrace informací podle odbornosti pracoviště, stavu oddělení apod.

4.2.7.6Komunikace s Portálem občana

Součástí řešení eHealth KHK je předávání informace o existenci a následně také vlastního dokumentu časově nejnovější výjezdové zprávy na Portál občana. Řešení podporuje případ užití, kdy se občan regulérně identifikuje/autentizuje na Portálu občana (prostřednictvím NIA) a prostřednictvím infrastruktury eGonServiceBusu - NCPeH – ISAC GW KHK – ISAC ZZS KHK –AZD ZZS KHK získá k náhledu svou poslední výjezdovou zprávu, uloženou v AZD v ZZS KHK.

4.3Uživatelé a vybavení

V následující tabulce jsou uvedeny orientační počty současných uživatelů:

Pozn.: Jedná se o počet registrovaných, nikoliv současně připojených uživatelů.

Skupina	Počet	Doplňující informace
Členové výjezdových skupin	500	Jedná se o maximální počet členů posádek v rámci směnného provozu.
Vozidel	100 / 70	Maximální počet vozidel současně provozovaných je 70.
Správci	10	Správci technologie a informačních systémů.

4.4Počty a množství zpracovávaných dat

Oblast

Množství

Počet výjezdů:

Cca 200 / den (průměrně)

Cca 60.000 / rok

Roční nárůst cca 5 %

4.5Současný stav informačních a komunikačních technologií

Infrastruktura popsaná v kapitolách dále v tomto dokumentu je k dispozici pro další provoz Systému. Detailní parametry jsou součástí systémové dokumentace, která bude poskytnuta při zahájení plnění.

Objednatel nepředpokládá žádné dodatečné náklady na změny této infrastruktury, tj. buď bude pro poskytovatele služeb dostatečná, nebo musí zajistit rozšíření v rámci své nabídky.

4.5.1Krajské komunikační centrum

ZZS Královéhradeckého kraje:

HW (1ks - Dell PowerEdge R320):
1. 4 jádrový CPU, Intel Xeon E5-2407 v2 2.40GHz, 10M Cache, 6.4GT/s QPI, No Turbo, 4C, 80W, Max Mem 1333MHz,
2. 4 GB RAM,
3. 2x 300GB, SAS 6Gbps, 2.5-in, 15K RPM Hybrid Hard Drive, RAID 1,
4. LAN 10/100/1000 Ethernet kata,
5. zdroj 230V.
SW:
1. CentOS Linux release 6.7 (Final),
2. vlastní organizace dat bez komerční DB.

4.5.2Krajská komunikační brána

ZZS Královéhradeckého kraje:

HW (1 ks - virtualizace VMware 6.0.0):

1 jádrový CPU,
2 GB RAM,
1x 80GB,
LAN 10/100/1000.

SW:

CentOS Linux release 7(Core),
vlastní organizace dat bez komerční DB.

4.5.3Archivy zdravotnické dokumentace

ZZS Královéhradeckého kraje, nemocnice Náchod pro Zdravotnický holding (a Fakultní nemocnice Hradec Králové):

HW (3x 2ks - Dell PowerEdge R415):

6 jádrový CPU, AMD Opteron 4334, 3.1GHz, 6C, 6M L2/8M L3 Cache, Turbo CORE, 95W TDP
8 GB RAM,
2 x 1TB, Near-Line SAS 6Gbps, 3.5-in, 7.2K RPM, RAID 1,
LAN 10/100/1000 Ethernetová karta,
zdroj 230V.

SW:

CentOS Linux release 6.7 (Final),
DB Postgres verze 9.5.6.

Nemocnice Vrchlabí:

HW (1ks):

vlastní řešení

SW:

vlastní řešení

4.5.4Komunikační uzly

ZZS Královéhradeckého kraje, nemocnice Zdravotnického holdingu (a Fakultní nemocnice Hradec Králové):

HW (6x 2ks - TWITTER System):

4 jádrový CPU, Intel(R) Celeron(R) CPU J1900 @ 1.99GHz,
2 GB RAM,
1x 60GB SATA bez RAID,
LAN 10/100/1000 Ethernetová karta,
zdroj 230V.

SW:

CentOS Linux release 6.7 (Final),
vlastní organizace dat bez komerční DB.

Nemocnice Vrchlabí:

HW (1ks):

vlastní virtualizace.

SW:

CentOS Linux release 6.7 (Final),
vlastní organizace dat bez komerční DB.

4.5.5Datové sítě

Systém je připojen do existující LAN infrastruktury lokality Bláhovka prostřednictvím centrálního L3 switche (Cisco Catalyst 3850), který je tvořen redundantním stackem switchů (2 switche v jednom stacku). Redundance je jak v celkovém switchi, tak v napájení.

Dále je Systém integrován prostřednictvím VPN tunelů do existující WAN sítě Zdravotnického holdingu pro účely výměny dat mezi ZZS a ostatními ZZ (nemocnice).

Připojení k internetu je řešeno prostřednictvím jediného provozovatele a to CESNET. Připojení je realizováno stejným připojením jako napojení na WAN síť mezi lokalitami ZZS i WAN Zdravotnického holdingu. Fyzické zakončení připojení je v serverovně lokality Bláhovka. Toto připojení se využívá pro komunikaci s tablety posádek ZZS a případně také jako záložní komunikační trasa mezi ZZS a ZZ.

Dále je také připojení využíváno pro VPN routery vytvářející vlastní WAN síť ZZS.

Jako FireWall je využit redundantní (2x) FireWall FortiNet 200D, který je pod správou ZZS.

4.6Ostatní relevantní technologie

Oblast	Technologie	Doplňující informace
Pracovní a klientské stanice uživatelů / správců	MS Windows 7, 8.1 a 10 Google Chrome MS Internet Explorer MS Edge	Aplikace dílčích částí Systému musí být pro uživatele funkční na těchto technologiích.
Tablety posádek	MS Windows 8.1 a 10 Panasonic FZ-G1 10,1“ Dell Latitude 7210	Aplikace MZD musí být pro uživatele funkční na těchto technologiích.
Virtualizace	VMware vSphere 6 Essentials Plus	Systém a technologie musí být funkční na těchto technologiích. Nákup maintenance či prodlužování licencí je součinností ZZS KHK.
Servery	Virtualizační servery – DELL PowerEdge R720.	Systém a technologie musí být funkční na těchto technologiích. Záruka případně pozáruční servis je součinností ZZS KHK.
Serverové operační systémy	CentOS Linux (dle textu výše)	Systém a technologie musí být funkční na těchto technologiích.
Zálohování	NAS QNAP	Systém a technologie musí být funkční na těchto technologiích. Nákup maintenance či prodlužování licencí je součinností ZZS KHK.
Vzdálený přístup	Centrální FW Fortigate	Objednatel zajistí vzdálený přístup k Systému a technologiím.
UPS – záložní zdroj	Datové centrum má zajištěno zálohování napájení.	Provozováno v datovém centru ZZS KHK, profylaxe a opravy si řeší ZZS KHK samostatně.

Strana: 38 z 38

Document Metadata

Table of Contents

Servisní služby pro zajištění provozu systému eHealth

Document Metadata