Příloha č. 1: Specifikace Díla

Zkratka/pojem	Význam
365x7x24 7x24x365	Poskytování služeb 365 dní v roce, 24 hodiny denně, 7 dnů v týdnu
AIS	Agendový informační systém
BnO	Brandýs nad Orlicí
CD / CD-ROM / DVD / USB	Datový nosič
ČR	Česká republika
DB	Databáze
DC	Datové centrum
EC	Emergency Card
eH NCP	Národní kontaktní místo pro eHealth
eHealth PAK	Zkrácené označení projektu „eHealth - Výměna a sdílení informací o zdravotní péči mezi poskytovateli ZS“.
EKP	Elektronická karta pacienta
EU	Evropská unie
GDPR	Nařízení 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ů.
GUI	Grafické uživatelské rozhraní
HW	Hardware
ICT	Informační a komunikační technologie
IOP	Integrovaný operační program
IROP	Integrovaný regionální operační program
IS	Informační systém
KC	Komunikační centrum

Zkratka/pojem	Význam
KIS	Klinický informační systém
KKC	Krajské komunikační centrum
ks	Počet kusů
KU	Komunikační uzel
KV	Kraj Vysočina
LDN	Léčebna dlouhodobě nemocných
KÚ	Krajský úřad
MZD	Mobilní zadávání dat
NIA	Národní bod pro identifikaci a autentizaci nebo též Národní identitní autorita zajišťující identifikační a autentizační služby garantované státem.
NIS	Nemocniční informační systém
NNP	Nemocnice následné péče Moravská Třebová
NPK / PKN	Nemocnice Pardubického kraje, a.s. PKN je označení z předchozího projektu.
NVM	Vysokomýtská nemocnice
OLÚ	Odborný léčebný ústav
OP	Operační program
OŘ	Operační řízení
OS	Operační systém
OVM	Orgán veřejné moci
PAK	Pardubický kraj
PD	Projektová dokumentace
PNP	Přednemocniční neodkladná péče
RČ	Rodné číslo
RDS	Regionální datová síť
ROB	Registr obyvatel
RÚ	Rehabilitační ústav
SLA	Úroveň a podmínky poskytování služeb technické a technologické podpory
SP	Studie proveditelnosti
SQL	Oznčení DB nebo strukturovaný dotazovací jazyk pro práci v relačních databázích

Zkratka/pojem	Význam
SW	Software
VŘ	Výběrové řízení
VS	Veřejná správa
VZ	Veřejná zakázka
VZP	Všeobecná zdravotní pojišťovna
XML	Výměnný formát a formát struktury dat
ZD	Zadávací dokumentace nebo Zdravotnická dokumentace, dle kontextu
ZR	Základní registry
ZS	Zdravotní služby
ZVZ	Zákon o zadávání veřejných zakázek
ZZ	Zdravotnická zařízení
ZZS	Zdravotnická záchranná služba

Tabulka 1: Seznam zkratek a pojmů

1 Předmět plnění

Předmětem projektu je Dodávka informačních a komunikačních technologií pro eHealth - Sdílení zdravotnické dokumentace mezi poskytovateli ZS, tj. rozšíření existujícího eHealth systému Pardubického kraje o nové funkcionality a rozšíření okruhu zapojených poskytovatelů zdravotních služeb.

Pardubický kraj hodlá do stávajícího systému eHealth PAK, jehož základy byly vybudované v rámci IOP,

v. č. 23 v roce 2015 připojit nové poskytovatele ZS a přidat nové funkcionality IS pro výměnu zdravotních dat (dokumentace) a pro poskytování zdravotních informací občanům o jim poskytnuté zdravotní péči (Portál pacienta).

Rozšíření funkcionalit slouží pro zajištění efektivní výměny zdravotních dat a dokumentace mezi všemi poskytovateli ZS na území PAK (zajištění celoplošného pokrytí území PAK) a pro zvýšení efektivity poskytování zdravotní péče na území PAK.

Dále je součástí projektu i nezbytná HW infrastruktura a systémový SW pro provoz modernizovaného

IS.

Součástí VZ je zajištění provozní podpory na 5 let s potřebnými SLA na všech vrstvách systému, která je řešena samostatnou smlouvou.

Detailní popis předmětu a rozsahu dodávky, souvisejících služeb a výchozího stavu jsou uvedeny

v následujícím textu tohoto dokumentu.

2 Členění dokumentu

Tento dokument obsahuje jen a pouze požadavky na dodávku a související služby (Dílo) a je členěn následovně:

• Kapitola 3 – Požadavky na dodávky a související služby – kapitola obsahuje požadavky na dodávky a služby (Dílo), které musí zhotovitel splnit ve svém řešení a ve své nabídce. Kapitola obsahuje základní koncept řešení, legislativní požadavky, konkrétní funkční a technické požadavky na řešení předmětu plnění v rámci VZ.

• Kapitola 4 - Harmonogram – kapitola obsahuje harmonogram realizace předmětu plnění VZ.

• Kapitola 5 – Místa plnění – kapitola obsahuje místa plnění v rámci realizace předmětu plnění

VZ.

• Kapitola 6 – Výchozí stav – kapitola obsahuje popis výchozího stavu pro realizaci předmětu VZ, tj. uvedení seznamu dotčených subjektů, jejich vztah k předmětu VZ, informační a komunikační technologie a vybavení, kterými subjekty disponují nebo které budou k dispozici pro realizaci VZ, případně další organizační a technické podmínky, které jsou důležité pro realizaci VZ.

Uvedené kapitoly a jejich obsah jsou uvedeny dále v tomto dokumentu.

Požadavky na servisní služby k tomuto Dílu jsou definovány v samostatném dokumentu, který v rámci

VZ je přílohou ZD a současně se stane přílohou Servisní smlouvy.

3 Požadavky na dodávky a související služby

V této kapitole jsou uvedeny požadavky na dodávky a související služby v rámci této VZ.

3.1 Předmět a rozsah dodávky

Předmětem projektu je Dodávka informačních a komunikačních technologií pro eHealth - Sdílení zdravotnické dokumentace mezi poskytovateli ZS, tj. modernizace a rozšíření existujícího eHealth systému o nové funkcionality a rozšíření okruhu zapojených poskytovatelů zdravotních služeb.

3.1.1 Rozsah dodávky

Konkrétně se jedná o následující dodávky:

Ozn.	Položka rozpočtu	Stručný popis položky	Jednotka	Počet jednotek
1	Rozvoj funkcionalit KC eHealth - rozšíření rozsahu dat sdílených a vyměňovaných prostřednictvím komunikačního centra eHealth mezi poskytovateli ZS.	Existující komunikační centrum eHealth bude rozšířeno o nové funkcionality sloužící ke sdílení a vyměňování dat mezi poskytovateli ZS. Konkrétně se jedná o: a. Sdílení informací o dostupnosti volných lůžek pro urgentní příjem b. Avízo o převozu pacienta c. Výměna dat mezi zdravotnickými zařízeními včetně dokumentů zdravotnické dokumentace vedené v elektronické formě d. Sdílení dat o zdravotní péči mezi zdravotnickými zařízeními e. Vyhodnocení výjezdů ZZS f. Dodatečné zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ g. Zjišťování registrujícího lékaře pacienta v registru VZP	soubor	1
2	Rozšíření počtu poskytovatelů ZS připojených ke komunikačnímu centru eHealth a využívajících funkcionality KC eHealth.	Rozšíření počtu poskytovatelů ZS nebo jejich pracovišť připojených ke komunikačnímu centru eHealth o následující poskytovatele ZS. V rámci připojení budou poskytovatelům ZS k dispozici všechny sdílené a poskytované informace vyměňované v rámci komunikačního centra eHealth. Součástí je i rozšíření funkcionalit u stávajících poskytovatelů ZS mimo ZZS PAK.	ks	11
3	Úpravy NIS zapojených nebo zapojovaných poskytovatelů ZS	Úpravy NIS zapojených nebo zapojovaných poskytovatelů ZS tak, aby bylo možné napojení NIS na komunikační centrum eHealth. Do tohoto seznamu je uvedeno i napojení PKN (Pardubická nemocnice), protože se jedná o rozšíření rozsahu vyměňovaných dat.	ks	11
4	Nezbytné úpravy IS ZZS PAK	Nezbytné úpravy KU ZZS PAK a IS ZZS PAK pro zajištění některých nových funkcionalit (Avízo o převozu pacienta, Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ, Zjišťování registrujícího lékaře pacienta v registru VZP).	ks	1
5	Rozvoj funkcionalit KC eHealth - rozšíření o Portál pacienta.	Existující komunikační centrum eHealth bude rozšířeno o portál pacienta, který bude sloužit pro poskytování informací o zdravotní péči pro pacienty v rámci zapojených poskytovatelů ZS.	soubor	1
6	Dodávka nezbytného	Dodávka nezbytného rozšíření HW infrastruktury pro běh rozšířeného komunikačního centra eHealth. Jedná se o rozšíření	soubor	1

Ozn.

Položka rozpočtu

Stručný popis položky

Jednotka

Počet

jednotek

rozšíření HW

infrastruktury.

stávajícího HW o servery, disková úložiště a poskytnutí

souvisejících služeb (migrace do nového umístění, implementace, nezbytné zaškolení obsluhy, testovací provoz a provozní dokumentace pořízeného HW atd.).

Dodávka nezbytného rozšíření

systémového SW.

Dodávka nezbytného rozšíření systémového SW pro běh rozšířeného komunikačního centra eHealth. Jedná se o rozšíření stávajícího systémového SW (OS, DB, licence, apod.) a poskytnutí souvisejících služeb (implementace, nezbytné zaškolení obsluhy, testovací provoz a provozní dokumentace pořízeného SW atd.).

soubor

Tabulka 2: Rozsah dodávky

3.1.2 Stručný popis dodávek

Bude se jednat o následující dodávky:

1. Rozvoj funkcionalit KC eHealth – rozšíření rozsahu dat sdílených a vyměňovaných prostřednictvím komunikačního centra eHealth mezi poskytovateli ZS. Existující komunikační centrum eHealth bude rozšířeno o nové funkcionality sloužící ke sdílení a vyměňování dat mezi poskytovateli ZS. Konkrétně se jedná o:

a. Sdílení informací o dostupnosti volných lůžek pro urgentní příjem.

b. Avízo o převozu pacienta.

c. Výměna dat mezi zdravotnickými zařízeními včetně dokumentů zdravotnické dokumentace vedené v elektronické formě.

d. Sdílení dat o zdravotní péči mezi zdravotnickými zařízeními.

e. Vyhodnocení výjezdů ZZS.

x. Xxxxxxxxx zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného

ZZ.

x. Xxxxxxxxxx registrujícího lékaře pacienta v registru VZP.

Nové funkcionality budou poskytnuty i stávajícím poskytovatelům ZS připojeným k eHealth PAK, tj. Zdravotnické záchranné službě Pardubického kraje (ZZS PAK) a Nemocnici Pardubického kraje (NPK), pracoviště Pardubická nemocnice.

2. Rozšíření počtu poskytovatelů ZS připojených ke komunikačnímu centru eHealth a využívajících funkcionality KC eHealth. Rozšíření bude o následující poskytovatele ZS:

a. Léčebna dlouhodobě nemocných Rybitví (LDN Rybitví)

b. Odborný léčebný ústav Jevíčko (OLU Jevíčko)

c. Albertinum, odborný léčebný ústav Žamberk (OLÚ Albertinum Žamberk)

d. Nemocnice následné péče Moravská Třebová (NNP Moravská Třebová)

x. Xxxxxxxxxxxx nemocnice (NVM)

f. Rehabilitační ústav Brandýs nad Orlicí (RÚ BnO)

x. Xxxxxxxxxx NPK: Pardubická nemocnice, Chrudimská nemocnice, Orlickoústecká nemocnice, Litomyšlská nemocnice, Svitavská nemocnice.

Součástí jsou komunikační uzly (KU) do datových center poskytovatelů ZS, které budou zprostředkovávat komunikaci mezi NIS poskytovatele ZS a eHealth PAK (KC PAK).

Rozšíření počtu zapojených poskytovatelů ZS bude znamenat, že i již existující funkcionality (viz dále) budou dostupné i pro tyto nově zapojené poskytovatele ZS.

3. Úpravy NIS zapojených nebo zapojovaných poskytovatelů ZS tak, aby bylo možné napojení NIS na komunikační centrum eHealth (KC).

4. Nezbytné úpravy IS ZZS PAK pro zajištění některých nových funkcionalit: Avízo o převozu pacienta, Dodatečné zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ, Zjišťování registrujícího lékaře pacienta v registru VZP.

5. Vytvoření Portálu pacienta, který umožní samotným pacientům vzdálený přístup ke svým vybraným zdravotním záznamům o poskytnuté zdravotní péči, včetně pořizování vlastních záznamů do osobního zdravotního záznamu vedeného na portále, a sdílet je s lékaři nebo osobami blízkými, kterým umožní přístup. Součástí řešení musí být i aplikace pro kontaktní místo pro ověření identity pacienta v rámci jeho registrace. Uživatelské rozhraní bude vždy vyžadovat identifikaci a autentizaci uživatele s možností využití i jiných dostupných a použitelných systémů identitních služeb v souladu s NIA (viz následující bod). Uživatelský přístup k obsahu a funkcím portálu pacienta bude především prostřednictvím webového uživatelského rozhraní, ale bude umožněn také přístup pomocí mobilní aplikace pro „chytré“ mobilní telefony.

6. Napojení na Národní bod pro identifikaci a autentizaci (NIA) zajišťující identitu občana na národní úrovni (identifikační a autentizační služby garantované státem) a využití autentizace a identifikace občana/pacienta z tohoto identititního systému, předávání identity do NIS pro zajištění ZD jen autentizovaného pacienta.

7. Přesun stávajícího krajského komunikačního centra eHealth PAK (KC PAK) z datového centra ZZS PAK do datového centra NPK s cílem využití možností a úrovně služeb (SLA) krajské komunikační infrastruktury místo komunikace přes internet. Hlavním důvodem je také to, že NIS krajských nemocnic Pardubického kraje jsou na této komunikační infrastruktuře, tj. nejvhodnější je propojení na eHealth PAK (KC PAK) přes tuto síť a do DC NPK. Součástí bude i oddělení KKC od KU ZZS PAK v rámci virtuální infrastruktury.

8. Součástí bude také rozšíření HW a SW infrastruktury tak, aby byly zajištěny dostatečné kapacitní a výkonnostní parametry (podmínky) nově dodávané součásti (Portál pacienta), nově dodávané funkcionality/služby a pro následný provoz eHealth PAK a současně byly pokryty všechny nutné licence spojené s navýšením počtu uživatelů (připojených poskytovatelů ZS, rozšíření využití v NPK i na další krajské nemocnice a přístupy uživatelů na portál pacienta).

9. Součástí bude také rozšíření komunikace s ostatními kraji, zejména sousedními, u kterých dochází často k případům poskytování zdravotní péče občanům z jiného kraje. Nová připojení na následující kraje: Královéhradecký, Středočeský, Jihomoravský, Olomoucký.

10. V případě, že v době realizace projektu bude připraven NIX ZD, bude předmětem plnění napojení na tento systém. V případě nepřipravenosti integrovaného systému bude nedodělkem dodávky a bude realizováno po zajištění připravenosti během doby udržitelnosti.

11. V případě, že v době realizace projektu bude připraveno Národní kontaktní místo pro eHealth (eH NCP) pro Českou republiku a zapojení České republiky do celoevropského mechanismu výměny zdravotnické dokumentace pro službu pacientský souhrn (Patient Summary), bude předmětem plnění napojení na tuto národní kontaktní bránu. V případě nepřipravenosti integrovaného systému bude nedodělkem dodávky a bude realizováno po zajištění připravenosti během doby udržitelnosti.

12. Řešení musí pracovat s identifikací pacienta v souladu s legislativou a prováděcími předpisy platnými ke dni dokončení realizace řešení, vč. zajištění připravenosti na postupné opuštění rodných čísel jako jediného a výměnného identifikátoru a zavedení bezvýznamových

identifikátorů během doby udržitelnosti, pokud nebude možné tento přechod realizovat během realizace projektu, bude realizováno během doby udržitelnosti.

13. Systém musí být připraven k napojení na rozhraní centrálních sdílených služeb eGovernmentu

(IS ZR – ROB).

3.1.3 Související služby a náležitosti dodávky

Součástí dodávky jsou dále následující služby a náležitosti:

1. Projektové řízení dodávky řešení.

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

3. Dodávka, implementace, instalace, konfigurace HW a SW infrastruktury.

4. Vývoj informačního systému a jeho součástí.

5. Implementace informačního systému a jeho součástí.

6. Výchozí import datových zdrojů a metadat do systému (initial load, bude-li třeba).

7. Ověření funkčnosti dodaného systému a jeho částí.

8. Dodávka dokumentace dodaného systému a jeho částí (min. uživatelská dokumentace, dokumentace skutečného provedení, systémová dokumentace, projektová dokumentace).

9. Seznámení uživatelů a administrátorů s obsluhou dodaného řešení – seznámení

s funkcionalitami, obsluhou dodávaného systému a jeho budoucím provozem.

10. Asistence pracovníků dodavatele uživatelům při náběhu provozu.

11. Zařazení do provozního prostředí objednatele (dohled, zálohování apod.)

12. Provedení zkušebního provozu.

13. Xxxxxxxxx díla formou písemného stvrzení předávacími, akceptačními protokoly nebo dodacími listy.

14. Poskytnutí záruky min. 5 let na informační systém a min. 3 roky na HW a SW infrastrukturu.

15. Všechny dodávky a převzetí plnění/řešení (i částečného) bude vždy stvrzeno písemně akceptačním/předávacím protokolem nebo dodacím listem.

3.1.4 Dodávkou nedotčené oblasti stávajícího řešení

Dodávkou nebudou dotčeny následující oblasti stávajícího řešení:

1. Stávající funkcionality budou zachovány, jedná se o:

a. Vyhledání životních údajů pacienta (Emergency card – EC) – přístup ZZS PAK do náhledu zdravotnické dokumentace (ZD) ze všech nemocničních informačních systémů (NIS) v kraji s předem definovaným výběrem potřebných informací s využitím platných standardů.

b. Předání výjezdové zprávy ZZS do nemocnic – přenos lékařských zpráv ZZS vytvořených realizovaným systémem mobilní podpory MZD výjezdových posádek do NIS jednotlivých nemocnic.

x. Xxxxxx na propouštěcí a ambulantní zprávy při výjezdu ZZS – přístup ZZS PAK do náhledu ZD ze všech nemocničních informačních systémů (NIS) v kraji s předem definovaným výběrem potřebných informací s využitím platných standardů.

2. V současné době připojení poskytovatelé ZS zůstanou připojeni. Jedná se o Zdravotnickou záchrannou službu Pardubického kraje (ZZS PAK) a jedno z pracovišť Nemocnice Pardubického kraje (NPK) – pracoviště Pardubická nemocnice. Nicméně v rámci dodávky dojde k rozšíření funkčností těchto napojení.

3. Zůstane zachováno připojení na krajské komunikační centrum Kraje Vysočina (eMeDocS) ve stávajícím rozsahu funkcionalit a vyměňované zdravotnické dokumentace. Toto napojení bude znamenat, že nově zapojení poskytovatelé zdravotních služeb v jiných krajích, kteří budou přímo napojeni na eHealth systém Kraje Vysočina (eMeDocS), budou moci čerpat data od poskytovatelů ZS v rámci Pardubického kraje a současně s tím budou moci poskytovat data poskytovatelům ZS v rámci Pardubického kraje. Toto napojení zůstane zachováno i v případě, že eHealth PAK bude napojen na Národní systém výměny ZD. Důvodem je zajištění udržitelnosti původního projektu.

4. Součástí dodávky nejsou koncová pracoviště uživatelů.

3.1.5 Vyloučení z dodávky

Předmětem dodávky není:

1. Zajištění komunikační infrastruktury (sítě apod.) mezi jednotlivými prvky systému, které nejsou explicitně uvedeny jako součást plnění.

2. Infrastruktura, HW a systémový SW poskytovaný Objednatelem uvedený ve výchozím stavu.

3. Spotřební materiál využívaný v následném provozu informačního systému.

Koncept řešení, principy a požadavky na dodávky a služby jsou uvedeny dále v tomto dokumentu.

3.2 Východiska

Zapojení poskytovatelé zdravotnických služeb povedou nezbytnou část zdravotnické dokumentace v elektronické podobě. V elektronické podobě bude zdravotnická dokumentace pořizována, zpracovávána, dlouhodobě uchovávána a zprostředkovávána v digitální formě s využitím pořizovaných informačních technologií.

Tato dokumentace bude předmětem výměny v rámci systému modernizovaného v rámci této VZ.

3.3 Koncept/architektura požadovaného řešení

Na následujícím schématu je uveden koncept řešení eHealth PAK:

Obrázek 1: Koncept řešení eHealth PAK

V následující tabulce je stručný popis konceptu řešení:

Prvek	Popis
Předmět řešení projektu (ohraničeno červeně)
KC PAK (eHealth PAK)	Komunikační centrum systému eHealth PAK. Jedná se o centrální uzel/server celého řešení, který zajišťuje výměnu dat a dokumentů mezi zapojenými subjekty.
DB	Databáze komunikačního centra, kam jsou ukládána provozní data. Nejedná se o osobní data pacientů ani o zdravotnickou dokumentaci, případně jsou uložena jen dočasně do doby doručení cílovému příjemci, následně jsou smazána.
KU <subjekt>	<subjekt> je zástupný symbol pro poskytovatele ZS. Toto platí i pro další popisy. Komunikační uzel systému eHealth PAK je umístěn do DC konkrétního poskytovatele ZS a zajišťuje integraci s NIS tohoto poskytovatele ZS, tj. primární výměnu dat a dokumentů mezi eHealth PAK a NIS poskytovatele ZS.

Prvek	Popis
NIS <subjekt>	Nemocniční informační systém poskytovatele ZS, který je příjemcem nebo poskytovatelem primárních dat o pacientech, která vstupují do výměny dat. V případě NPK se jedná o 5 NIS, jen jeden z nich je nyní připojen a zajišťuje výměnu dat, ostatní je třeba připojit.
DC <subjekt>	Datové centrum poskytovatele ZS, kde je umístěn NIS a je nebo bude umístěn komunikační uzel eHealth PAK (KU <subjekt>) a kde bude zajištěna integrace a výměna dat mezi KU a NIS.
Portál pacienta	Portál pacienta je jednou z částí řešení projektu zajišťující online zdravotnické informace pro pacienty, ale také o pacientech pro praktické lékaře a ošetřující lékaře ze ZZ.
Kontaktní místo	Kontaktní místo jsou obecně organizačně a personálně zajištěná místa výkonu administrativní činnosti spojené s ověřením identity uživatele (pacienta, lékaře) registrovaného v Portálu pacienta v případech, kdy jej nebude možné spolehlivě ověřit elektronicky. V takovýchto případech bude zajištěna jeho registrace do Portálu pacienta a validita jeho osobních údajů pro potřeby nahlížení na data z NIS jednotlivých poskytovatelů ZS. Nemusí jít o zřízení fyzického místa. Tuto činnost můžou vykonávat např. i pracovníci ambulancí, centrálních evidencí apod. Tato místa jsou zajištěna jednotlivými poskytovateli ZS, kteří jsou v kontaktu s pacienty nebo i centrálně. Součástí řešení projektu je aplikace pro „úředníka“, resp. pověřené osoby vykonávající ověření identity pacienta. Součástí řešení projektu není zřízení tohoto pracoviště, zajištění pracovníka ani zajištění provádění této služby.
OŘ/EKP/MZD	IS na straně ZZS PAK: SW pro operační řízení (IS OŘ), mobilní sběr dat o pacientech (MZD/EKP), který poskytuje data pro služby eHealth a čerpá data z eHealth (od poskytovatelů ZS).
Výměna zdravotnické dokumentace v rámci České republiky
eHealth KV (eMeDocS)	Systém eMeDocS zajišťuje výměnu zdravotnické dokumentace mezi zdravotnickými zařízeními připojenými k tomuto systému. Organizátorem a garantem projektu je Kraj Vysočina. Detaily jsou uvedeny v kap. 6.2.2 – eHealth KV (eMeDocS). Současné řešení eHealth PAK je k tomuto systému připojeno a toto připojení zůstane zachováno.
eHealth <kraj>	<kraj> je zástupný symbol pro obdobný systém jiného kraje. Obdobný systém zajišťující výměnu zdravotnické dokumentace mezi zdravotnickými zařízeními připojenými k tomuto systému. Detaily k eHealth systémům okolních krajů jsou uvedeny v kap. 6.2.1.
Národní kontaktní místo pro	Připravované Národní kontaktní místo pro eHealth (eH NCP) pro Českou republiku a zapojení České republiky do celoevropského mechanismu výměny zdravotnické

Prvek	Popis
eHealth (eH NCP, NIX ZD)	dokumentace pro službu pacientský souhrn (Patient Summary). Detaily jsou uvedeny v kap. 6.2.4 . Součástí projektu přípravy je i vybudování NIX ZD – viz kap. 6.2.3. V případě, že oba systémy (NIX ZD i eH NCP) budou připraveny do doby realizace projektu, je předmětem plnění napojení na tyto systémy, v případně nepřipravenosti budou integrace realizovány během doby udržitelnosti po zajištění jejich připravenosti.
Komunikační infrastruktura
Krajská Komunikační Infrastruktura	Primárně bude komunikace mezi zapojenými subjekty probíhat prostřednictvím této infrastruktury. V případech, kdy napojení nebude existovat, Pardubický kraj postupně zajistí připojení těchto subjektů, nicméně ve výchozím stavu bude komunikace probíhat zabezpečeným způsobem přes internet. Detaily jsou uvedeny v kap. 6.1.4 – Krajská komunikační infrastruktura.
Internet	Komunikační infrastruktura využívaná pro pacienty a pro komunikaci v případech, kdy není a nebude k dispozici napojení na krajskou komunikační infrastrukturu.
Ostatní
Přístup pacienta	Přístupové prostředky pacienta (počítače, tablety, telefony) k Portálu pacienta prostřednictvím sítě internet.
NIA	Národní bod pro identifikaci a autentizaci nebo též Národní identitní autorita zajišťující identifikační a autentizační služby garantované státem.

Tabulka 3: Koncept řešení eHealth PAK

Požadavky na funkce požadovaného řešení jsou uvedeny v následujícím textu.

3.4 Rozsah funkcionality sdílení a vyměňování dat mezi poskytovateli ZS

V této kapitole je detailně popsán rozsah funkcionality sdílení a vyměňování dat mezi poskytovateli ZS. Funkcionality eHealth PAK jsou členěny na:

1. Stávající funkcionality – jsou stávající funkcionality, které budou zachovány. Jsou zde uvedeny pro úplnost, protože se budou týkat jak zavádění do nových zdravotnických zařízení v rámci jejich napojení na eHealth PAK, tak nezbytných úprav připojovaných systémů, ale také bude rozšiřován rozsah dat přenášených nebo sdílených současnými funkcemi.

Jedná se o následující funkcionality:

a. Vyhledání životních údajů pacienta

x. Xxxxxx na propouštěcí a ambulantní zprávy

c. Předání výjezdové zprávy ZZS do nemocnic

2. Nové funkcionality – jsou nově požadované funkcionality, které budou zavedeny do IS

příslušných poskytovatelů ZS.

Jedná se o následující funkcionality:

a. Sdílení informací o dostupnosti volných lůžek pro urgentní příjem

b. Avízo o převozu pacienta

c. Vyhodnocení výjezdů ZZS

d. Zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ

e. Zjišťování registrujícího lékaře pacienta v registru VZP

x. Xxxxxx dat mezi poskytovateli ZS včetně dokumentů zdravotnické dokumentace vedené v elektronické formě

x. Xxxxxxx dat o zdravotní péči mezi poskytovateli ZS

h. Portál pacienta

V následujícím textu je uveden popis jednotlivých funkcionalit.

3.4.1 Vyhledání životních údajů pacienta

Tato funkce umožňuje výjezdovým posádkám ZZS, které poskytují pacientům přednemocniční neodkladnou péči, nahlížet na informace o jejich zdravotním stavu a v minulosti poskytnuté zdravotní péči ve zdravotnických zařízeních. Výjezdové posádky mají při výjezdu k dispozici přenosné tablety, na kterých je nainstalován aplikační klient systému mobilního zadávání dat (MZD). Do tohoto aplikačního klienta bylo integrováno vyvolání webové aplikace umožňující náhled na zdravotní údaje pacienta, který byl identifikován na základě rodného čísla, resp. čísla pojištěnce (zatím v současnosti jediného možného identifikačního údaje). Při vyvolání webové aplikace jsou z klienta MZD na tabletu předávány identifikační údaje uživatele přihlášeného do MZD a jméno a heslo opravňující vyvolat webového klienta. Zároveň je z klienta MZD předávána identifikace pacienta ze záznamu o výjezdu. Webová aplikace vytvoří standardizovanou žádost o data ve standardu DASTA v4, která je odeslána na komunikační server KC ZZS PAK. Ten provede automatickou distribuci dotazu na připojené komunikační uzly, které jsou napojeny na datová rozhraní NIS připojených zdravotnických zařízení. Provádí se plošné oslovení všech komunikačních uzlů (KU), které mají tuto službu povolenu. Pokud má pacient v NIS záznamy o léčbě, jsou požadované údaje vyhledány a vráceny ve standardním formátu DASTA v4 zpět na komunikační server a do webové aplikace, kde jsou postupně veškeré odpovědi zpracovány do souhrnného přehledu životních údajů pacienta ze všech zdravotnických zařízení, kde měl pacient záznamy. Jedná se o online zobrazení zdravotních údajů získaných z připojených NIS a nejsou vytvářeny žádné kopie primárních dat do centrální databáze. Oprávněná osoba je může vyžádat pouze při výjezdu k pacientovi a za účelem získání jeho zdravotních informací pro rozhodování o postupu ošetření. Celý proces je monitorován a zaznamenán do auditního logu. Nejsou však zaznamenávána konkrétní data pacienta. Pokud to datové rozhraní NIS podporuje, je pořízen i záznam o přístupu k záznamům v NIS také do NIS.

Zpřístupňované údaje pacienta jsou:

• osobní údaje: rodné číslo, jméno a příjmení, datum narození

• bydliště: adresa, PSČ, město

• alergie

• rizikové faktory

• trvalé medikace

• trvalé diagnózy s rozšířením o diagnózy z klinických záznamů

• souhrnná anamnéza

• přehled dostupných ambulantních a propouštěcích zpráv.

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

Jednou ze součástí přehledu životních údajů pacienta (viz předchozí kapitola) ve webové aplikaci je i seznam ambulantních a propouštěcích zpráv. Výběrem požadovaného záznamu je uživateli zobrazen i

konkrétní obsah lékařské zprávy z příslušného ZZ. Seznam lékařských zpráv obsahuje informaci o zdroji a identifikátor zprávy (klinické události). V případě požadavku na zobrazení obsahu zprávy dojde k odeslání požadavku na komunikační server, který dle identifikátoru zdroje směruje požadavek na komunikační uzel (KU) zdravotnického zařízení, které je zdrojem zprávy. Komunikační uzel předá datovému rozhraní jednoznačný identifikátor požadované zprávy. Vyhledaná zpráva je odeslána zpět ve standardním formátu DASTA v4 a text zprávy je zobrazen na mobilním zařízení zasahujícího lékaře ZZS. Lékař může zprávu přečíst, nicméně nemá možnost ji ukládat ani s ní jiným způsobem manipulovat. Zároveň zpráva není nikdy ukládána mimo primární nemocniční systém zdravotnického zařízení.

3.4.3 Předání výjezdové zprávy ZZS do nemocnic

Zasahující lékař ZZS v průběhu zásahu vypisuje záznam o výjezdu v mobilní aplikaci MZD. Při předávce pacienta je vytištěn protokol o výjezdu, který je předáván zároveň s pacientem. Záznam o výjezdu je zároveň ve formě datové zprávy odeslán elektronicky na aplikační server EKP, kde je vygenerován protokol o výjezdu ve formě datové zprávy formátu DASTA v4. Zpráva putuje přes komunikační uzel KU ZZS na komunikační server KC PAK, kde je směrována na adresovaný komunikační uzel KU příslušného zdravotnického zařízení. Datová zpráva je automaticky importována do NIS, kde může být k dispozici již při přebírání pacienta. Posádka obvykle odesílá konečnou podobu výjezdové zprávy, nicméně ve výjimečných případech může odeslat i rozpracovanou podobu zprávy a následně po dokončení a uzavření zprávy (často až v systému EKP) je do zdravotnického zařízení odeslána finální zpráva.

Rozšíření funkce I.

ZZS bude mít možnost, dle ust. § 45 odst. 2 písm. f) zákona č. 372/2011 Sb., o zdravotních službách, ve znění pozdějších předpisů, předat zprávu o poskytnuté urgentní péči také registrujícímu poskytovateli ZS v oboru všeobecné praktické lékařství nebo v oboru praktické lékařství pro děti a dorost, je-li mu tento poskytovatel znám, a to také elektronickou cestou. Tato funkce souvisí s funkcí popsanou níže v kap. 3.4.8, která umožňuje vyhledávat registrujícího poskytovatele ZS pojištěnců.

V budoucnu bude technologicky možné odesílat Záznam o výjezdu, jako PDF/A dokument, případně elektronicky podepsaný PDF/A dokument, jak je definováno standardem ISO 19005-3.

Rozšíření funkce II.

Rozšíření datové zprávy Záznamu o výjezdu o kompletní strukturovaný datový set sbíraných dat posádkou ZZS v aplikaci MZD. Tyto strukturované údaje pak mohou být využity v informačním systému poskytovatele ZS, který převzal pacienta do péče.

3.4.4 Sdílení informací o dostupnosti volných lůžek pro urgentní příjem

Tato funkce (služba eHealth PAK) umožní sdílet aktuální údaje o počtech volných akutních lůžek mezi zdravotnickými zařízeními a zdravotnickou záchrannou službou. Přístup k údajům o aktuálním stavu budou moci využít i samotná zdravotnická zařízení, zejména kontaktní místa pro ZZS, s omezením na informace jen za jejich zdravotnické zařízení. Informace o volných lůžkách za všechna připojená zdravotnická zařízení, která budou mít povolenu tuto službu (není třeba získávat informace od zdravotnických zařízení, která urgentní pacienty vůbec nepřijímají) se budou zobrazovat v uceleném souhrnném přehledu na webové stránce aplikace s dynamicky generovaným obsahem. Pracovníci operačního řízení nebo výjezdová posádka si bude moct spustit webovou aplikaci a zobrazit aktuální stav volných lůžek. Do aplikace bude vstup povolen na základě identifikace a autentizace a přístup

k informacím bude na základě autorizace k rozsahu zobrazovaných informací. Pracovníci ZZS budou mít informace ze všech nemocnic, které mají zřízen urgentní příjem, kdežto pracovníci nemocnic jen na informace z kmenového zařízení. Z připojených zdravotnických zařízení budou získávány údaje v co nejpodrobnější struktuře, aby mohly být seskupovány dle potřebného detailu pohledu na data.

Webová aplikace odešle požadavek na komunikační server KC PAK, který plošně rozešle požadavek na data na všechny komunikační uzly (KU) těch zařízení, kde je tato služba povolena. Komunikační uzel předá požadavek na datové rozhraní NIS, které zjistí počty volných lůžek a vrátí data zpět. Data jsou předávána ve formátu DASTA v4. Webová aplikace sestaví z došlých dat celkový aktuální přehled o počtu lůžek po jednotlivých zařízeních a umožní postupné zanořování do detailů (např. z celkových počtů se bude dát zobrazit detail až na jednotlivá pracoviště s konkrétní odborností.

Předávaná data budou minimálně v této struktuře:

• zdravotnické zařízení

• příjmové místo

• pracoviště

• odbornost pracoviště

• počet volných lůžek standardních

• počet volných lůžek intenzivních

• počet volných lůžek s ventilací (pokud je údaj zjistitelný)

• datum a čas aktualizace informace.

Bude možné definovat, která pracoviště spadají pod určité příjmové místo a údaje pak sumarizovat k tomuto příjmovému místu.

Získávání těchto údajů bude silně závislé na zdrojových systémech, tj. jak je vedena evidence lůžek, jak jsou evidováni hospitalizovaní pacienti, aby bylo vůbec možné získat potřebné informace o volných lůžkách. Pokud nebude možné automatizované získání údajů, bude dostupná možnost i pro manuální zadávání těchto údajů např. kontaktním místem pro ZZS. Ze zkušeností však plyne, že zjišťování volných lůžek bez počítačové podpory je velmi obtížné. Dále je třeba si uvědomit, že údaje mají pouze orientační vypovídací hodnotu. V případě akutní potřeby mohou zdravotnická zařízení často zajistit volná lůžka přeložením méně závažných pacientů na standardní lůžka nebo dočasně na jiné oddělení.

3.4.5 Avízo o převozu pacienta

Výjezdová posádka ZZS vyplní základní údaje o stavu pacienta do aplikace MZD a odesílá avízo o převozu pacienta do zdravotnického zařízení na urgentní příjem, kam je pacient převážen. Obsluha urgentního příjmu dané nemocnice má k dispozici buď webovou aplikaci, nebo přímo NIS, ve které jsou zobrazována avíza zasílaná ze ZZS. Uživatel urgentního příjmu může příjem avíza jen potvrdit, nebo potvrdit příjem pacienta, nebo příjem pacienta odmítnout. Všechny tyto interakce však nejsou podmínkou a v praxi se avízo převážně používá jen k zobrazení informace o převozu pacienta, nikoliv k potvrzování přijetí pacienta. Záleží to na zavedených pracovních postupech. Obsluha na urgentním příjmu může kontaktovat posádku na tel. čísle uvedeném v avízu. V případě, že dojde ke změně převozu pacienta, je odesláno nové avízo do jiného zdravotnického zařízení.

ZZS dostává zpětnou vazbu, že avízo bylo uživateli urgentního příjmu doručeno/zobrazeno. Stačí, pokud je informace zobrazena na monitoru, uživatel urgentního příjmu nemusí ani manuálně potvrzovat příjem avíza.

Avízo je především notifikační zprávou o převozu pacienta a předpokládaném dojezdu. ZZS ale zároveň sděluje identifikační údaje pacienta a základní informace o zdravotním stavu pacienta, o jeho základních vitálních funkcích, předpokládané diagnóze a poskytnutém ošetření apod.

Datová zpráva je ze ZZS odesílána na KC PAK, kde je zpráva uložena do příslušné fronty zdravotnického zařízení, případně konkrétního místa příjmu. KC PAK může zároveň přeposlat datovou zprávu avíza i na komunikační uzel příslušného zdravotnického zařízení, pokud jeho informační systém bude připraven na příjem datové zprávy avíza a bude schopen zpracovat informace přímo v informačním systému. Podmínkou ale je, aby podporoval odeslání potvrzení o přijetí a zobrazení avíza.

Rozsah údajů avíza může být minimální nebo rozšířený. Kromě údajů totožnosti pacienta, jsou-li známé, mohou být předávány například tyto údaje

• Místo události, Datum a čas události, Typ události

• Předpokládaný čas dojezdu nebo předpokládaný dojezdový čas

• Věk pacienta (i odhadovaný)

• GCS (oči-slova-motorika)

• Informace o chování zornic

• Krevní tlak a srdeční frekvence

• Zevní krvácení a odhad krevní ztráty

• Krvácení z horní GIT

• Podpora oběhu noradrenalinem

• KPCR

• ROSC

• Spontánní dechová frekvence

• Saturace

• Dostatečná spontánní ventilace

• Řízená ventilace

• Neinvazivní ventilace

• Zajištění DC

• Pád z výšky

• Polytrauma

• Zlomeniny pánve

• Střelné poranění

• Bodné poranění

• Policie

• Odběr krve na alkohol.

3.4.6 Vyhodnocení výjezdů ZZS

Zpětná informace o stanovené diagnóze a poskytnuté zdravotní péči po důkladném vyšetření pacienta po jeho předání do péče zdravotnického zařízení akutní lůžkové péče umožní ZZS zlepšovat kvalitu poskytované urgentní péče na základě edukace využívající informace od ZZ a jejich porovnávání s vlastními informacemi o poskytnutých zdravotních službách posádkou ZZS.

ZZS bude mít možnost, dle ust. § 45 odst. 2 písm. f) zákona č. 372/2011 Sb., o zdravotních službách, ve znění pozdějších předpisů, si vyžádat informace o poskytnuté zdravotní péči od zdravotnického zařízení, kam byl pacient předán.

Vyžádání informací i jejich předání (formou náhledu) bude řešeno v rámci KC PAK. Komunikace bude logována. Přístup bude možný jen na základě autorizace a omezen výhradně na konkrétní případy předaných pacientů do péče zdravotnického zařízení.

3.4.7 Zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ

ZZS často poskytuje urgentní péči pacientům, u kterých není zjistitelná totožnost, a předává pacienta do péče zařízení akutní lůžkové péče dříve, než zjistí totožnost pacienta, především jeho číslo pojištěnce. ZZS má v takových případech problém s vykázáním péče zdravotním pojišťovnám. Služba KC PAK umožní dohledání dodatečně zjištěné totožnosti pacienta, především číslo pojištěnce, u zdravotnického zařízení, kam byl pacient převezen. Dohledání osobních údajů, včetně čísla pojištěnce, se bude provádět na základě čísla výjezdu/čísla protokolu, pod kterým je pacient veden v IS ZZS, a které je předáváno také do ZZ jako součást předávacího protokolu.

Dohledávání může být plně automatizované, kdy z IS ZZS jsou u neznámých pacientů automaticky odesílány požadavky na dohledání přes KC PAK (IS ZZS musí být připraven na automatizované odesílání dotazů a automatizované zpracování odpovědí), nebo manuální, kdy uživatelé ZZS budou mít k dispozici webovou aplikaci, do které zadají identifikátory výjezdu, aplikace předá požadavek na KC PAK, který jej doručí do zdravotnického zařízení. Pokud je v nemocničním systému nalezen odpovídající záznam o urgentním příjmu a zároveň uvedena totožnost pacienta, jsou požadované údaje vráceny a zobrazeny na stránce webové aplikace.

3.4.8 Zjišťování registrujícího lékaře pacienta v registru VZP

Prostřednictvím funkce KC PAK bude možné navázat komunikaci s B2B službou portálu VZP, která poskytuje na vyžádání údaje o registrujícím lékaři pacienta na základě čísla pojištěnce. Informace pak bude použita pro adresaci a povinné doručení zprávy registrujícímu lékaři.

Tuto službu budou moct využívat jak zdravotnická zařízení, tak zdravotnická záchranná služba, která má také povinnost doručovat registrujícímu lékaři zprávu o poskytnuté urgentní péči.

3.4.9 Výměna dat mezi poskytovateli ZS včetně dokumentů zdravotnické dokumentace vedené v elektronické formě

Výměna dat a dokumentů mezi poskytovateli ZS bude umožňovat automatizované a zabezpečené doručování elektronických datových zpráv. Jedná se o rozšíření funkce eHealth PAK, která je již v současné době využívána pro doručování elektronického Protokolu o výjezdu ZZS, ve standardu DASTA v4, do informačních systémů poskytovatelů ZS. Tato funkce KC eHealth PAK bude rozšířena i o možnosti doručování dalších dat a dokumentů a to nejen mezi ZZS a poskytovateli ZS, ale i mezi poskytovateli ZS navzájem. Primárně podporovaným standardem pro předávaná data bude DASTA v aktuálně podporované verzi standardu, a to především z důvodu v současnosti nejvíce rozšířeného standardu pro předávání dat mezi poskytovateli ZS v České republice (ČR). Vzhledem k tomu, že se v ČR ve větší míře zavádějí i zahraniční SW, u kterých je nejčastějším výměnným standardem HL7, bude možná výměna dat i v tomto formátu. Aby byla výměna dat mezi poskytovateli ZS transparentní a efektivní, bude KC eHealth PAK poskytovat připojeným poskytovatelům ZS, resp. jejich informačním systémům, informace o tom, jaká data/zprávy je ten který poskytovatel ZS schopen poskytovat/přijímat a v jakém formátu. KC eHealth PAK bude připojeným poskytovatelům ZS, resp. jejich informačním systémům, poskytovat adresní informace o poskytovatelích, se kterými je možné uskutečňovat výměnu dat a dokumentů a jaké typy datových zpráv podporují (např. příjem žádanky, příjem ambulantní zprávy apod.) eHealth PAK tedy bude poskytovat především funkce a komunikační

infrastrukturu pro řízenou, zabezpečenou a garantovanou výměnu dat a zpráv mezi poskytovateli ZS. To, jaké typy zpráv si mezi sebou budou vyměňovat poskytovatelé, je především závislé na možnostech jejich provozních informačních systémů, zejména podporovaných výměnných datových formátů (DASTA, HL7, XML).

Funkce výměny dat a dokumentů bude mít efekt zejména na podporu vyžádané péče, tj. automatizace odesílání žádanek na vyšetření, příjem výsledků a nálezů z vyšetření, automatizované odesílání lékařských zpráv následnému poskytovateli zdravotní péče apod. Výměna údajů podpoří také procesy sdílení zdravotních služeb mezi jejich poskytovateli. Např. mezilaboratorní komunikace, kdy se některé speciální metody provádějí jen v některých laboratořích a primární laboratoř může část metod předat k vyšetření do jiné laboratoře, nebo zajišťování vyhodnocování radiodiagnostických vyšetření provedených ve zdravotnickém zařízení jiným poskytovatelem ZS.

S rozvojem elektronizace vedení zdravotnické dokumentace v elektronické formě poskytovateli ZS nabývá na významu výměna dokumentů elektronické zdravotní dokumentace v čistě elektronické formě. Předávání zdravotní dokumentace se tak zjednodušuje jen na elektronickou formu, což výrazně zefektivní spolupráci mezi poskytovateli ZS. Pokud tedy poskytovatel vede zdravotní dokumentaci v elektronické formě, bude moci buď přímo předávat zdravotní dokumentaci v elektronické formě prostřednictvím služby výměny eHealth PAK nebo předávat odkaz na vzdálený a zabezpečený přístup k záznamům zdravotní dokumentace vedené v elektronické formě. Netýká se to jen zdravotní dokumentace, ale i žádanek na zdravotní službu. Sekundární funkcí pro podporu procesu vyžádané péče je webová žádanka na vyšetření. Tato webová žádanka umožní poskytovatelům ZS, jejichž provozní systém neumožnuje vytvářet a exportovat žádanku do formátu podporovaného standardu, aby vystavili žádanku na vyšetření prostřednictvím webové žádanky.

3.4.10 Sdílení dat o zdravotní péči mezi poskytovateli ZS

Na rozdíl od výměny dat o zdravotní péči, kdy jsou data odesílána ze zdrojového informačního systému jednoho poskytovatele do cílového informačního systému druhého poskytovatele, je funkce sdílení dat o zdravotní péči zaměřena výhradně na vzdálený přístup (nahlížení) k záznamům a údajům o zdravotní péči. Funkce sdílení informací o zdravotní péči bude realizována bez nutnosti vytváření kopií dat mimo zdrojové produkční informační systémy.

Důležitým aspektem této funkce eHealth PAK je oprávněnost nahlížení do záznamů o poskytnuté zdravotní péči. Legislativa tuto oprávněnost upravuje v Zákoně o zdravotních službách a Vyhlášce o zdravotnické dokumentaci. Tak jako má ZZS oprávnění k nahlížení na záznamy o zdravotní péči při urgentním zásahu (a to i bez souhlasu pacienta v zájmu ochrany zdraví a života), má ošetřující lékař poskytující zdravotní péči právo vyžádat si přístup ke zdravotním záznamům jiného poskytovatele a ten je povinen tyto informace poskytnout.

Funkce pro sdílení informací o zdravotní péči pacienta bude součástí funkce Portálu pacienta, protože s ní bezprostředně souvisí. Portál pacienta bude poskytovat integrační rozhraní pro informační systémy poskytovatelů, aby bylo možné přistupovat ke sdíleným informacím přímo z provozního informačního systému a nebylo nutné zadávat a vyhledávat pacienta na portále. Integrace do produkčních systémů musí být provedena tak, aby zaručovala oprávněnost náhledu na zdravotní informace pacienta, tj. přístup k informacím prostřednictvím portálu musí být podmíněn existencí pacienta v provozním systému poskytovatele a musí být veden zdravotní záznam o poskytované zdravotní službě. Jen za těchto podmínek je odůvodněno si vyžádat informace o poskytnuté zdravotní péči jiným poskytovatelem. Samozřejmostí je přístup výhradně osobní (musí být zajištěna autentizace uživatele

v provozním systému), autorizace (oprávněnost uživatele poskytovat zdravotní službu) a auditovatelnost přístupu (logování přístupů identifikovatelného uživatele).

Jiný než popsaný způsob integrovaného sdílení údajů o zdravotní péči pacientů vyžaduje souhlas pacienta. Přístup k údajům pacienta s jeho souhlasem prostřednictvím Portálu je pak popsán v následující kapitole.

3.4.11 Portál pacienta

Portál pacienta je centrálním místem přístupu občana-pacienta k vybraným informacím o zdravotní péči vedeným v provozních informačních systémech poskytovatelů ZS, kde mu byly poskytnuty zdravotní služby.

Vzhledem k tomu, že v současné době není k dispozici prakticky využitelný systém identit, který by byl využitelný pro jednoznačnou a ověřitelnou identifikaci občana-uživatele Portálu a identifikaci občana- pacienta v provozních systémech poskytovatelů zdravotní péče, bude prozatím umožněn přístup k informacím prostřednictvím Portálu pacienta pouze registrovaným a ověřeným uživatelům. V současné době je pro účely identifikace pacienta ve zdravotnickém systému používáno rodné číslo (RČ) a číslo pojištěnce (ČP), které ale má být výhledově nahrazeno jiným, bezvýznamovým identifikátorem (dosud zákonem neupraveno). Protože ale v současné době neexistuje systém, který by umožňoval poskytovatelům ZS ztotožnit a ověřit identitu občana-pacienta, resp. jeho RČ nebo ČP, není ojedinělým případem, kdy je pacientovi v provozním informačním systému poskytovatele ZS zadáno chybné RČ. Ze stejného důvodu není v současnosti možné používat RČ jako jednoznačný identifikátor osoby bez ověření, že identifikovaná a autentizovaná osoba je subjektem tohoto osobního identifikačního údaje. Existují systémy poskytovatelů identit, které ověří, že „já jsem já“, avšak neexistuje federalizace identit mezi poskytovateli služeb správy identit a poskytovateli ZS, resp. vazba na provozní informační systémy poskytovatelů ZS.

Do doby, než bude možné využívat jiných způsobů důvěryhodné identifikace pacientů, budou pro ověřování registrovaného uživatele Portálu zřízena kontaktní místa, což jsou obecně organizačně a personálně zajištěná místa výkonu administrativní činnosti ověření identity registrovaného pacienta, která bude propagována do zdrojových informačních systémů poskytovatelů ZS jako jednoznačný identifikátor pro vyhledání údajů. Nemusí jít o zřízení fyzického místa. Tuto činnost mohou vykonávat např. i pracovníci ambulancí, centrálních evidencí apod. Tato místa mohou být zajištěna jednotlivými poskytovateli ZS, kteří jsou v kontaktu s pacienty nebo i centrálně. Pro tento účel ověřování registrovaných pacientů bude součástí řešení aplikace pro pověřené osoby vykonávat ověření identity pacienta. Součástí řešení projektu není zřízení tohoto pracoviště, zajištění pracovníka ani zajištění provádění této služby.

Portál pacienta bude dostupný přes internet bez ohledu na lokalitu, tj. jak na území Pardubického kraje, tak i mimo toto území. Primární význam bude mít ale pro pacienty z Pardubického kraje, kteří budou hlavními příjemci zdravotních služeb na území Pardubického kraje. Portál pacienta umožní pacientům získat přístup k informacím o poskytnuté zdravotní péči bez nutnosti návštěvy jednotlivých poskytovatelů. Pacienti budou mít jednak přehled o zdravotní péči, která jim byla poskytnuta poskytovateli ZS, ale také tyto informace budou moct zpřístupnit jiným poskytovatelům ZS. Pro zajištění informací o předešlé zdravotní péči pro lékaře, který aktuálně poskytuje pacientovi zdravotní službu, nebude nutná osobní návštěva předchozích poskytovatelů ZS – „nebudou obíhat pacienti, ale informace“. Portál umožní registrovanému pacientovi kdykoliv a odkudkoliv vyžádat informace ze své zdravotnické dokumentace u poskytovatelů ZS zapojených do systému eHealth PAK.

Vzhledem k tomu, že se bude jednat o všechny poskytovatele ZS Pardubického kraje na jeho území, bude mít pacient informace min. od těchto poskytovatelů ZS.

Portál pacienta bude umožňovat také pořizování vlastních záznamů samotnými pacienty do osobního zdravotního záznamu a sdílet jej s lékaři nebo osobami blízkými, kterým umožní přístup. Součástí portálu tedy bude funkcionalita umožňující přístup k informacím pacienta i jiným osobám (lékař, osob blízká) a to selektivním způsobem.

Uživatelské rozhraní Portálu bude vždy vyžadovat identifikaci a autentizaci (minimálně dvoufaktorová autentizace) uživatele, a to s možností využití i jiných dostupných a použitelných systémů identitních služeb v souladu s eIDAS.

Uživatelský přístup k obsahu a funkcím portálu pacienta bude především prostřednictvím webového uživatelského rozhraní, ale bude umožněn také přístup pomocí mobilní aplikace pro „chytré“ mobilní telefony.

Minimální rozsah zpřístupňovaných údajů prostřednictvím portálu, které by měly poskytnout informační systémy poskytovatelů ZS jsou

• osobní údaje: rodné číslo, jméno a příjmení, datum narození

• bydliště: adresa, PSČ, město

• alergie

• rizikové faktory

• trvalé medikace

• trvalé diagnózy s rozšířením o diagnózy z klinických záznamů

• souhrnná anamnéza

• přehled dostupných zpráv z klinických událostí (nálezy z vyšetření, výsledky vyšetření, komentované výsledky vyšetření, ambulantní zprávy, propouštěcí zprávy apod.)

• přehled naplánovaných vyšetření

• apod.

Výhledově bude Portál pacienta směřovat k poskytování informací v rozsahu tzv. pacientského souhrnu, který v současné době není definován českou legislativou, je však definován v rámci celoevropského projektu epSOS.

Portál pacienta bude otevřeným komunikačním prostředkem mezi poskytovateli ZS a pacienty. Portál bude možné rozšiřovat o další aplikace, jako je třeba online objednávání na vyšetření a připomínání plánovaných termínů, upozorňování na došlé výsledky a dostupné zprávy z těchto vyšetření, možnost vystavit žádost o vystavení receptu u dlouhodobě a trvale užívaných léků a zaslání identifikátoru elektronického receptu apod.

3.5 Poskytovatelé ZS vs. funkcionality

V následující tabulce jsou uvedeni poskytovatelé ZS a relevantní funkcionality z předchozí kapitoly ve vztahu k těmto poskytovatelům ZS:

Funkce

NPK –

Pardubice

NPK –

Chrudim

NPK –

Ústí nad Orlicí

NPK –

Litomyšl

NPK –

Svitavy

ZZS PAK

LDN Rybitví

OLU Jevíčko

OLÚ

Albertinum

Žamberk

NNP

Moravská Třebová

NVM

RÚ BnO

Vyhledání

životních údajů

pacienta

Funkční

Nové

Funkční

Nové

Předání výjezdové

zprávy ZZS do

nemocnic

Funkční

Nové

Funkční

Nerelevantní

Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS

Funkční

Nové

Funkční

Nové

Sdílení informací o dostupnosti volných lůžek pro urgentní příjem

Nové

Nerelevantní

Avízo o převozu

pacienta

Nové

Nerelevantní

Funkce

NPK –

Pardubice

NPK –

Chrudim

NPK –

Ústí nad Orlicí

NPK –

Litomyšl

NPK –

Svitavy

ZZS PAK

LDN Rybitví

OLU Jevíčko

OLÚ

Albertinum

Žamberk

NNP

Moravská Třebová

NVM

RÚ BnO

Výměna dat

mezi

zdravotnickými zařízeními

včetně

dokumentů zdravotnické dokumentace vedené v elektronické formě

Nové

Nerelevantní

Nové

Sdílení dat o zdravotní péči mezi

zdravotnickými zařízeními

Nové

Vyhodnocení výjezdů ZZS

Nové

Nerelevantní

Dodatečné zjišťování totožnosti

pacienta (číslo pojištěnce) po jeho předání do jiného ZZ

Nové

Nerelevantní

Zjišťování registrujícího

lékaře pacienta

v registru VZP

Nové

Funkce

NPK –

Pardubice

NPK –

Chrudim

NPK –

Ústí nad Orlicí

NPK –

Litomyšl

NPK –

Svitavy

ZZS PAK

LDN Rybitví

OLU Jevíčko

OLÚ

Albertinum

Žamberk

NNP

Moravská Třebová

NVM

RÚ BnO

Portál pacienta

Nové

Tabulka 4: Poskytovatelé ZS vs. funkce

Detailní požadavky na funkce jsou uvedeny v následujícím textu.

3.6 Požadavky na dodávky

V této kapitole jsou uvedeny požadavky na dodávky.

3.6.1 Obecné požadavky

V této kapitole jsou uvedeny obecné požadavky na požadované řešení:

#	Požadavek
P.1	Dodávaný systém 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.
P.2	Dodávaný systém musí být přehledný, logicky členěný a srozumitelný (user friendly).
P.3	Veškeré nabízené SW i HW prvky musí být plně kompatibilní se stávajícím systémem eHealth PAK (dodavatel MEDORO s.r.o.).
P.4	Součástí implementace musí být i veškeré potřebné licence a služby nezbytné pro dodávku a provoz eHealth PAK.
Moderní dlouhodobě perspektivní komerčně dostupný systém.
P.5	Řešení musí být založené na současných obecně dostupných a moderních technologiích a standardech s perspektivou rozvoje a podpory min. 10 let.
P.6	Řešení musí být založené na komerčně dostupném a procesně orientovaném systému, customizace musí být řešena konfiguračně a proveditelná interními správci aplikace.
P.7	Řešení musí podporovat na straně klienta práci na zařízeních ve standardním prostředí (PC, notebooky, vč. podpory zařízení s dotykovými obrazovkami), v prostředí mobilních zařízení (tablety, mobily) a práci s dotykovými zařízeními v těch částech řešení, která jsou určena pro podporu procesů. Podpora ovládání pomocí dotykových displejů včetně podpory multidotykových gest.
P.8	Řešení musí být v souladu a podporovat mezinárodní a národní standardy jako např. DASTA, HL7.
Uživatelské prostředí (Grafické prostředí)
P.9	Uživatelské prostředí musí být moderní, intuitivní a uživatelsky přívětivé.
P.10	Všechny části systému musí být integrované a modulárně koncipované.
P.11	Administrativní a uživatelská náročnost na obsluhu systému/aplikací a doba reakce systému/aplikací na jednotlivé uživatelské úkony a zpracování dat musí být minimální.

#	Požadavek
P.12	Úpravu systému/aplikací tak, aby odpovídaly uvedeným požadavkům a případným požadavkům objednatele na snížení administrativní zátěže a uživatelské náročnosti (snadná obsluha, přizpůsobení uživatelského prostředí apod.). V případě, že bude dodavatel pro tyto požadavky potřebovat dodávku jiného SW/HW vybavení, než je součástí požadavků objednatele, dodavatel je povinen na své náklady dodat takovéto SW/HW vybavení.
P.13	Aplikace nesmí pro žádnou funkcionalitu vyžadovat doplněk v prohlížeči.
Řízení přístupů k aplikačním službám
P.14	Požadujeme hierarchické nastavování přístupových práv dle rolí, možnost definovat rozsah přístupu.
P.15	Možnost definovat uživatelské role (počet, typ) dle potřeb organizace.
Jazyková mutace
P.16	Uživatelské rozhraní prohlížečů je v českém jazyce.
P.17	Pro práci správců a administrátorů se u definovaných systémových komponent připouští komunikace v jazyce anglickém.
Legislativa a další normy
P.18	Řešení bude v souladu s legislativou uvedenou v kapitole 6.4 – Legislativa.
P.19	Soulad s legislativou uvedenou v kap. 6.4.2 – Legislativa specifická pro zdravotnická zařízení
P.20	Systém musí splňovat ustanovení vyhlášky č. 98/2012 Vyhláška o zdravotnické dokumentaci v aktuálním znění.
P.21	Soxxxx x 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ů.
P.22	Soxxxx xe 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í.
Ostatní obecné požadavky
P.23	Optimalizace datové zátěže komunikačního prostředí.
P.24	Automatické odhlášení nečinného uživatele.

Tabulka 5: Obecné požadavky

Pro konkrétní oblasti jsou uvedeny specifické požadavky samostatně v dílčích podkapitolách.

3.6.2 Rozvoj funkcionalit KC eHealth

Jedná se o rozšíření rozsahu dat sdílených a vyměňovaných prostřednictvím komunikačního centra eHealth mezi poskytovateli ZS.

Požadavky na tuto část dodávky jsou následující:

#	Požadavek
Sdílení informací o dostupnosti volných lůžek pro urgentní příjem
P.25	Doplnění funkcionality Sdílení informací o dostupnosti volných lůžek pro urgentní příjem do KC eHealth dle popisu uvedeného v kap. 3.4.4 – upřesňující požadavky následují.
P.26	Automatizovaný sběr dat o počtu volných akutních lůžek z NIS připojených poskytovatelů akutní lůžkové péče (netýká se poskytovatelů následné péče).
P.27	Z připojených zdravotnických zařízení budou získávány údaje v co nejpodrobnější struktuře (detail až na jednotlivá pracoviště s konkrétní odborností), aby mohly být seskupovány nebo zobrazeny v detailu.
P.28	Vytvoření webové stránky pro prezentaci seznamu připojených poskytovatelů akutní lůžkové péče a počtu volných akutních lůžek. Stránka se aktualizuje při otevření a s možností pravidelného obnovování obsahu (např. každých 60 s) s konfigurovatelným intervalem obnovování obsahu.
P.29	Možnost spuštění webové stránky pro prezentaci na zdravotnickém operačním středisku ZZS (ZOS) v mobilním zařízení posádky ZZS (prostřednictvím zabezpečeného mobilního internetu využívaného posádkami ZZS).
P.30	Pomocí přístupových práv možnost nastavit přehled pro všechny připojení poskytovatele ZS pro ZZS, případně omezit přehled pro poskytovatele ZS s omezením na informace jen za jejich zdravotnické zařízení.
P.31	Pracovníci ZZS budou mít k dispozici informace ze všech nemocnic, které mají zřízen urgentní příjem, kdežto pracovníci nemocnic jen na informace z kmenového zařízení.
P.32	Nastavení povolení služby bude nastaveno u připojeného poskytovatele ZS (není třeba získávat informace od zdravotnických zařízení, která urgentní pacienty vůbec nepřijímají).
P.33	Webová aplikace odešle požadavek na komunikační server KC PAK, který plošně rozešle požadavek na data na všechny komunikační uzly (KU) těch zařízení, kde je tato služba povolena.
P.34	Komunikační uzel předá požadavek na datové rozhraní NIS, které zjistí počty volných lůžek a vrátí data zpět.
P.35	Data jsou předávána ve formátu DASTA v4.
P.36	Webová aplikace sestaví z došlých dat celkový aktuální přehled o počtu lůžek po jednotlivých zařízeních a umožní postupné zanořování do detailů (např. z celkových počtů se bude dát zobrazit detail až na jednotlivá pracoviště s konkrétní odborností).

#	Požadavek
P.37	Předávaná data budou minimálně v této struktuře: • zdravotnické zařízení • příjmové místo • pracoviště • odbornost pracoviště • počet volných lůžek standardních • počet volných lůžek intenzivních • počet volných lůžek s ventilací (pokud je údaj zjistitelný) • datum a čas aktualizace informace.
P.38	Bude možné definovat, která pracoviště spadají pod určité příjmové místo a údaje pak sumarizovat k tomuto příjmovému místu.
P.39	Komunikační uzel poskytne i uživatelské rozhraní pro manuální zadávání těchto údajů např. kontaktním místem pro ZZS.
Avízo o převozu pacienta
P.40	Doplnění funkcionality Avízo o převozu pacienta do KC eHealth dle popisu uvedeného v kap. 3.4.5 – upřesňující požadavky následují.
P.41	Výjezdová posádka ZZS vyplní základní údaje o stavu pacienta do aplikace MZD, která přes KC eHealth odešle avízo o převozu pacienta na urgentní příjem do cílového zdravotnického zařízení.
P.42	Vytvoření webové aplikace pro urgentního příjmu, ve které jsou zobrazována avíza zasílaná ze ZZS, tj. data pacienta a výjezdu, jedná se např. o identifikační údaje pacienta a základní informace o zdravotním stavu pacienta, o jeho základních vitálních funkcích, předpokládané diagnóze a poskytnutém ošetření apod.
P.43	Předávání avíz a údajů o pacientovi a výjezdu do NIS zdravotnického zařízení.
P.44	V případě aktualizace dat z výjezdu v MZD předání jejich aktualizace do NIS a zobrazení v webové aplikaci se seznamem avíz.
P.45	Avíza budou v seznamu avíz barevně rozlišena dle stavu jejich zpracování. Samostatné zvýraznění aktualizace aktualizovaných avíz pro potřeby upozornění personálu na aktualizovaná avíza.
P.46	Akce uživatelů v ZZ nad avízem, případně jeho aktualizací: • Potvrzení přijetí avíza • Potvrzení přijetí pacienta • Odmítnutí avíza Akxx xsou informativní a budou zaznamenány do logu k avízu, stavová informace bude doručena zpět na ZZS.

#	Požadavek
	Pro případné odmítnutí avíza musí být dohodnut proces mezi ZZ a ZZS. Odmítnutí avíza bude vázáno na přístupová oprávnění s tím, že ve výchozím stavu bude zakázáno dokud nebude výslovně povoleno ze strany ZZS (na základě dohody o elektronizaci tohoto procesu).
P.47	Uchovávání zaslaných avíz včetně jejich aktualizací pro případnou zpětnou kontrolu. Možnost náhledu na historii avíz a jejich aktualizací ve webové aplikaci.
P.48	V případě změny cílového zdravotnického zařízení v rámci výjezdu bude: 1. Zasláno storno původního avíza do původního cílového zdravotnického zařízení. 2. Zasláno nové avízo do nového cílového zdravotnického zařízení.
P.49	Záznam informace o odeslání, doručení, případně zpracování v ZZ: odeslání ze ZZS, potvrzení o doručení do ZZ, potvrzení o přečtení personálem ZZ a další dříve uvedené stavy, včetně náhledu na historii těchto stavů. Informace budou obsahovat min. datum, čas, stav a osoba, která akci provedla (pokud se jedná o uživatelskou akci).
P.50	ZZS dostává zpětnou vazbu, že avízo bylo uživateli urgentního příjmu doručeno/zobrazeno. Stačí, pokud je informace zobrazena na monitoru, uživatel urgentního příjmu nemusí ani manuálně potvrzovat příjem avíza.
P.51	Rozsah údajů avíza může být minimální nebo rozšířený. Základními údaji jsou: • identifikační údaje pacienta • základní informace o zdravotním stavu pacienta a jeho základní vitální funkce, • předpokládaná diagnóza • poskytnuté ošetření Mohou být (nepovinně) předávány i další údaje: • Místo události, Datum a čas události, Typ události • Předpokládaný čas dojezdu nebo předpokládaný dojezdový čas • Věk pacienta (i odhadovaný) • GCS (oči-slova-motorika) • Informace o chování zornic • Krevní tlak a srdeční frekvence • Zevní krvácení a odhad krevní ztráty • Krvácení z horní GIT • Podpora oběhu noradrenalinem • KPCR • ROSC • Spontánní dechová frekvence • Saturace • Dostatečná spontánní ventilace

#	Požadavek
	• Řízená ventilace • Neinvazivní ventilace • Zajištění DC • Pád z výšky • Polytrauma • Zlomeniny pánve • Střelné poranění • Bodné poranění • Policie • Odběr krve na alkohol. Systém musí umožnit předávání jak základní, tak rozšiřující sady údajů. Přenášeny budou jen údaje zadané posádkou ZZS v rámci výjezdu.
P.52	Webová aplikace pro ZZS, ve které budou zobrazována všechna zaslaná avíza, stav jejich zpracování na straně zdravotnických zařízení, včetně historie (aktualizace, stavy).
P.53	Všechny změny avíz na straně zdravotnických zařízení budou předávány zpět na ZZS do IS ZZS.
P.54	Prioritní doručování a zvýraznění odmítnutí avíz ve webové aplikaci a do IS ZZS. Možnost explicitního upozornění uživatele na ZOS (v rámci webové aplikace) a v MZD na tuto akci.
Vyhodnocení výjezdů ZZS
P.55	Doplnění funkcionality Vyhodnocení výjezdů ZZS do KC eHealth dle popisu uvedeného v kap. 3.4.6 – upřesňující požadavky následují.
P.56	Webová aplikace pro ZZS, kde bude možné vyžádat a zobrazit informace o stanovené diagnóze a poskytnuté zdravotní péči po důkladném vyšetření pacienta po jeho předání do péče zdravotnického zařízení akutní lůžkové péče.
P.57	Možnost zadání žádosti (dále jen „žádost“) na poskytnutí informací o stanovené diagnóze a poskytnuté zdravotní péči po důkladném vyšetření pacienta po jeho předání do péče zdravotnického zařízení akutní lůžkové péče.
P.58	Doručení žádosti na kontaktní místo pro ZZS zdravotnického zařízení, kam byl převezen pacient. Identifikace bude na základě zadané identifikace výjezdu a pacienta, bez těchto údajů nebudou informace poskytovány (omezeno výhradně na konkrétní případy předaných pacientů do péče zdravotnického zařízení).
P.59	Možnost ručního zadání údajů k žádosti ze strany zdravotnického zařízení.
P.60	Možnost automatizovaného stažení ambulantních a propouštěcích zpráv pacienta z NIS a následně zobrazení ve webové aplikaci u žádosti.
P.61	Přístup k aplikaci jen a pouze pro personál, který je oprávněn nahlížet a zpracovávat zdravotnickou dokumentaci pacienta.

#	Požadavek
P.62	Zobrazení seznamu žádostí a poskytnutých informací: • ZZS – všech žádostí a poskytnutých informací • ZZ – jen žádostí a poskytnutých informací vztahujících se k ZZ.
P.63	Pokud je k danému výjezdu k dispozici avízo (nebo více avíz), jsou zobrazeny společně s informacemi od ZZ pro možnost srovnání.
Zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ
P.64	Doplnění funkcionality Zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ do KC eHealth dle popisu uvedeného v kap. 3.4.7 – upřesňující požadavky následují.
P.65	Webová aplikace pro ZZS, kde bude možné vyžádat, případně ověřit identifikační údaje předaného pacienta po jeho předání do péče zdravotnického zařízení akutní lůžkové péče.
P.66	Možnost zadání žádosti (dále jen „žádost“) na poskytnutí informací o identifikačních údajích pacienta (primárně o číslo pojištěnce) po jeho předání do péče zdravotnického zařízení akutní lůžkové péče.
P.67	Doručení žádosti na kontaktní místo pro ZZS zdravotnického zařízení, kam byl převezen pacient. Identifikace bude na základě zadané identifikace výjezdu a známých (i částečných) identifikačních údajů pacienta. Funkce bude omezena výhradně na konkrétní případy předaných pacientů do péče zdravotnického zařízení. Součástí žádosti bude i důvod ověřování údajů (např. nezjištěno v rámci výjezdu, neověřeno v rámci následné kontroly apod.).
P.68	Možnost kontroly a ručního zadání údajů k žádosti ze strany zdravotnického zařízení: • Potvrzení identifikačních údajů zaslaných ve výjezdu – pro případy, kdy v ZZ nedošlo ke změně údajů. • Zadání upravených identifikačních údajů – pro případy, kdy došlo k aktualizaci/doplnění údajů.
P.69	Možnost automatizované aktualizace dat z NIS a následně zobrazení ve webové aplikaci u žádosti.
P.70	Přístup k aplikaci jen a pouze pro personál, který je oprávněn nahlížet a zpracovávat zdravotnickou dokumentaci pacienta a podílí se na vykazování poskytnuté péče.
P.71	Zobrazení seznamu žádostí a poskytnutých informací: • ZZS – všech žádostí a poskytnutých informací • ZZ – jen žádostí a poskytnutých informací vztahujících se k ZZ.
Zjišťování registrujícího lékaře pacienta v registru VZP
P.72	Doplnění funkcionality Zjišťování registrujícího lékaře pacienta v registru VZP do KC eHealth dle popisu uvedeného v kap. 3.4.8 – upřesňující požadavky následují.

#	Požadavek
P.73	Integrace KC s B2B službou portálu VZP pro zjištění identifikace registrujícího lékaře pacienta na základě čísla pojištěnce.
P.74	Webová aplikace pro ZZS, kde bude možné vyžádat identifikaci registrujícího lékaře pacienta na základě čísla pojištěnce.
P.75	Možnost zadání žádosti (dále jen „žádost“) na zjištění identifikace registrujícího lékaře pacienta na základě čísla pojištěnce ze strany ZZS.
P.76	Online zjištění identifikace registrujícího lékaře pacienta a zobrazení jeho identifikačních údajů z registru VZP.
P.77	Přístup k aplikaci jen a pouze pro personál, který je oprávněn nahlížet a zpracovávat zdravotnickou dokumentaci pacienta a podílí se na vykazování poskytnuté péče.
P.78	K dispozici jak pro ZZS, tak pro zdravotnická zařízení.
P.79	Odesílání zpráv registrujícímu lékaři pacienta se nepožaduje.
Výměna dat mezi poskytovateli ZS včetně dokumentů zdravotnické dokumentace vedené v elektronické formě
P.80	Doplnění funkcionality Výměna dat mezi poskytovateli ZS včetně dokumentů zdravotnické dokumentace vedené v elektronické formě do KC eHealth dle popisu uvedeného v kap. 3.4.9 – upřesňující požadavky následují.
P.81	Vedení (a konfigurace) seznamu zapojených poskytovatelů ZS v KC eHealth a seznamu jimi poskytovaných služeb v rámci výměny dat a zdravotnické dokumentace. Seznam služeb bude konfigurovatelný a bude obsahovat min. následující služby: 1. Vyžádání zdravotnické dokumentace pacienta od jiných poskytovatelů ZS. 2. Zaslání obecné žádost/dokument 3. Zaslání lékařské zprávy 4. Zaslání žádanky na vyšetření 5. Zaslání výsledku vyšetření (bez elektronické žádanky v tomto systému) Další mohou být přidány v rámci přidávaných nových funkčností NIS.
P.82	Výměna vyžádané elektronické zdravotnické dokumentace pacientů mezi registrovanými zdravotnickými zařízeními.
P.83	Výměna bude realizována formou datových zpráv mezi poskytovateli ZS prostřednictvím KC eHealth.
P.84	Výměna dokumentace ve formátech DASTA 4 (primárně), HL7, případně PDF a XML. Podpora i DASTA 3 pro zajištění zpětné kompatibility a napojení na systémy výměny zdravotnické dokumentace se zdravotnickými zařízeními jiných krajů, na úrovni ČR, resp. EU.

#	Požadavek
P.85	Webová aplikace, ve které bude možné zadat požadavek (dále „žádost“) na elektronickou zdravotnickou dokumentaci pacienta nebo jinou akci (žádanka na vyšetření) dle jeho identifikace (čísla pojištěnce).
P.86	Žádost bude možné zadat i v NIS každého poskytovatele ZS. Takto zadaná žádost bude z NIS předána do KC eHealth a následně vyřízena stejným způsobem jako žádost zadaná přes webovou aplikaci.
P.87	Možnost zadat žádost obecně na všechny zapojené poskytovatele ZS nebo adresně vybrat zájmové poskytovatele ZS, od kterých je dokumentace vyžadována. Výběr je ze seznamu registrovaných poskytovatelů ZS.
P.88	Předání žádosti do NIS všech zapojených poskytovatelů ZS, kteří mají konfigurovanou službu a poskytují elektronickou zdravotnickou dokumentaci do tohoto systému.
P.89	Možnost cíleného zaslání dokumentů na vybrané poskytovatele ZS a to jak z webové aplikace, tak z NIS. Jedná se např. o žádanky na vyšetření, odesílání lékařských zpráv, mezilaboratorní komunikace apod.
P.90	Možnost odpovídat na zaslané dokumenty (např. výsledky vyšetření v návaznosti na žádanky na vyšetření) a odeslat zpět původnímu odesílateli tak, aby byla jednoznačně identifikována vzájemná vazba mezi zaslanými dokumenty.
P.91	Vedení a možnost nastavení konfigurace seznamu dokumentů (typu dokumentace), které dané zdravotnické zařízení poskytuje a v jakém je formátu (DASTA, HL7, PDF, XML).
P.92	Webová aplikace bude zobrazovat všechny zadané žádosti, adresáty a jejich výsledky zadané za daného poskytovatele ZS bez ohledu na to, zda byla žádost zadaná z NIS nebo přes webovou aplikaci. Evidence bude jednotná bez ohledu na typy dokumentů a bude evidovat veškerou související komunikaci, poskytovatele ZS, stavy, doručenky, přiložené dokumentace a uživatele, kteří danou akci provedli.
P.93	Součástí je fyzické předávání dokumentace nebo odkazu na dokumentaci v přístupném systému cílovému poskytovateli ZS.
Sdílení dat o zdravotní péči mezi poskytovateli ZS
P.94	Doplnění funkcionality Sdílení dat o zdravotní péči mezi poskytovateli ZS do KC eHealth dle popisu uvedeného v kap. 3.4.10 – upřesňující požadavky následují.
P.95	Sdílení dat o zdravotní péči vzdáleným přístupem (nahlížením) k záznamům a údajům o zdravotní péči. Funkce sdílení informací o zdravotní péči bude realizována bez nutnosti vytváření kopií dat mimo zdrojové produkční informační systémy.
P.96	Webová aplikace, ve které bude možné zadat požadavek (dále „žádost“) sdílení dat o zdravotní péči a údajům o zdravotní péči dle identifikace pacienta (čísla pojištěnce).

#	Požadavek
P.97	Předání požadavku na data do NIS a sběr a konsolidace informací z NIS.
P.98	Zobrazení souhrnu údajů o zdravotní péči k žádosti.
P.99	Nahlížení na záznamy o zdravotní péči při urgentním zásahu ZZS (a to i bez souhlasu pacienta v zájmu ochrany zdraví a života) ze strany lékaře ZZS.
P.100	Nahlížení na záznamy o zdravotní péči ze strany ošetřujícího lékaře na základě žádosti z webové aplikace i z NIS.
P.101	Možnost zadat žádost přes webovou aplikaci i přes NIS. Oprávněnost náhledu na zdravotní informace pacienta z NIS musí být podmíněn existencí pacienta v provozním systému poskytovatele a musí být veden zdravotní záznam o poskytované zdravotní službě.
P.102	Stránka s náhledem umožní zobrazení výsledku v MZD/EKP v rámci výjezdu a v NIS jako emebeded stránka s výsledkem, pokud nebude dodáno přímo jako nativní součást příslušeného NIS.
P.103	Pro potřeby napojení NIS musí být dodáno integrační rozhraní mezi NIS a KC eHealth.
P.104	Záznam jednoznačné identifikace uživatelů a odůvodnění jejich oprávněnosti na sdílení/náhled na zdravotní dokumentaci pacienta.
P.105	Možnost autorizace přístupu ke zdravotnické dokumentaci pacienta přímo pacientem přes portál pacienta.
Integrace
P.106	Integrace KC eHealth na NIX ZD – viz popis v kap. 6.2.3 – NIX ZD.
P.107	Integrace KC eHealth na Národní kontaktní místo pro eHealth (eH NCP) – viz popis v kap. 6.2.4 – Národní kontaktní místo pro eHealth (eH NCP).
P.108	Systém musí být připraven k napojení na rozhraní centrálních sdílených služeb eGovernmentu (IS ZR – ROB).
Ostatní požadavky
P.109	Instalace a konfigurace na rozšířenou a přesunutou infrastrukturu pro KC eHealth (lokalita NPK)

Tabulka 6: Požadavky: Rozvoj funkcionalit KC eHealth

3.6.3 Rozšíření počtu poskytovatelů ZS připojených ke komunikačnímu centru eHealth a využívajících funkcionality KC eHealth

Rozšíření počtu poskytovatelů ZS nebo jejich pracovišť připojených ke komunikačnímu centru eHealth o následující poskytovatele ZS.

V rámci připojení budou poskytovatelům ZS k dispozici všechny sdílené a poskytované informace vyměňované v rámci komunikačního centra eHealth.

Součástí je i rozšíření funkcionalit u stávajících poskytovatelů ZS mimo ZZS PAK.

Požadavky na tuto část dodávky jsou následující:

#	Požadavek
P.110	Rozšíření stávajících funkcionalit KC eHealth na nově zapojované poskytovatele ZS. Jedná se o následující funkcionality: 1. Vyhledání životních údajů pacienta 2. Náhled na propouštěcí a ambulantní zprávy 3. Předání výjezdové zprávy ZZS do nemocnic
P.111	Doplnění nových funkcionalit KC eHealth a jejich implementace pro zapojené poskytovatele ZS. Jedná se o následující funkcionality: 1. Sdílení informací o dostupnosti volných lůžek pro urgentní příjem 2. Avízo o převozu pacienta 3. Vyhodnocení výjezdů ZZS 4. Zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ 5. Zjišťování registrujícího lékaře pacienta v registru VZP 6. Výměna dat mezi poskytovateli ZS včetně dokumentů zdravotnické dokumentace vedené v elektronické formě 7. Sdílení dat o zdravotní péči mezi poskytovateli ZS
P.112	Předchozí požadavky je požadováno realizovat pro následující poskytovatele ZS: 1. Léčebna dlouhodobě nemocných Rybitví (LDN Rybitví) 2. Odborný léčebný ústav Jevíčko (OLU Jevíčko) 3. Albertinum, odborný léčebný ústav Žamberk (OLÚ Albertinum Žamberk) 4. Nemocnice následné péče Moravská Třebová (NNP Moravská Třebová) 5. Vysokomýtská nemocnice (NVM) 6. Rehabilitační ústav Brandýs nad Orlicí (RÚ BnO) 7. Pracoviště NPK: a. Pardubická nemocnice (rozšíření stávajícího napojení/KU) b. Chrudimská nemocnice c. Orlickoústecká nemocnice d. Litomyšlská nemocnice x. Xxxxxxxxx nemocnice
P.113	Dodávka nebo upgrade (Pardubická nemocnice) komunikačních uzlů (KU) do datových center poskytovatelů ZS, které budou zprostředkovávat komunikaci mezi NIS poskytovatele ZS a eHealth PAK (KC PAK).
P.114	KU NPK (specifické požadavky na SW KU NPK): 1. Zachování stávající funkcionality KU NPK, případné rozšíření funkčnosti KU NPK. 2. KU NPK bude pro všechny lokality (5 lokalit) realizován na jednom (existujícím) KU NPK v souladu s výchozím stavem a připravovaným projektem modernizace KIS NPK uvedeným v kap. 6.3.2.1.

Požadavek

3. SW komunikačního uzlu umožní připojení na 5 v současné době provozovaných

KIS/NIS s tím, že připojení a KIS/NIS bude realizováno prostřednictvím komunikační

infrastruktury NPK.

4. SW komunikačního uzlu umožní postupné odpojení stávajících KIS/NIS tak, jak budou nahrazovány modernizovaným KIS NPK a přechod na jediné propojení a to do KIS NPK. Změna musí být konfigurační (beze změny funkčnosti KU).

5. SW v rámci přepojení na jediný KIS NPK umožní čerpat data z KIS NPK jako jediného

zdroje za všechny lokality/nemocnice NPK.

6. SW v rámci přepojení na jediný KIS NPK umožní směřovat avíza a výjezdy ZZS PAK na 5 míst urgentního příjmu v rámci KIS NPK.

7. V rámci přepojení KU NPK na jediný KIS NPK budou převedeny i všechny systémové a uživatelské licence tak, aby pokrytí licencemi před a po přepojení pokrývalo potřeby všech pracovišť/nemocnic NPK.

8. Součástí je případné rozšíření funkcionalit KU NPK vyplývající z potřeb modernizovaného systému, napojení více KIS/NIS, přepojení/rekonfigurace tak, aby bylo napojeno na KC eHealth v novém umístění (DC NPK).

Je přípustné nasazení 5 SW komunikačních uzlů na 1 infrastruktuře pro 5 pracovišť/nemocnic NPK a následná redukce na jeden SW komunikačního uzlu napojený na KIS NPK zajišťující obsluhu pro všechna místa urgentního příjmu v rámci NPK.

Je předmětem návrhu řešení uchazeče, zda zvolí 1 SW KU připojený na 5 pracovišť/nemocnic nebo 5 SW KU pro 5 pracovišť/nemocnic s následným slučováním, pokud budou zajištěny podmínky přechodu z 5 KIS/NIS na 1 KIS a nevzniknou vícenáklady na přechod (změna bude konfigurační).

P.115

Instalace a konfigurace nových i modernizovaných KÚ na infrastrukturu KU dodanou do DC poskytovatelů ZS.

Tabulka 7: Požadavky: Rozšíření počtu poskytovatelů ZS připojených ke komunikačnímu centru eHealth a využívajících

funkcionality KC eHealth

3.6.4 Úpravy NIS zapojených nebo zapojovaných poskytovatelů ZS

Úpravy NIS zapojených nebo zapojovaných poskytovatelů ZS tak, aby bylo možné napojení NIS

na komunikační centrum eHealth.

Do tohoto seznamu je uvedeno i napojení PKN (Pardubická nemocnice), protože se jedná o rozšíření rozsahu vyměňovaných dat.

Požadavky na tuto část dodávky jsou následující:

Požadavek

Společné požadavky

P.116

Zajištění integrace NIS a KU KC eHealth a implementace všech integračních rozhraní

pro jednotlivé funkcionality.

#	Požadavek
P.117	Zabezpečené propojení NIS a KU KC eHealth.
Vyhledání životních údajů pacienta
P.118	Vyhledání životních údajů pacienta dle požadavků uvedených v kap. 3.4.1 – Vyhledání životních údajů pacienta. Jedná se o existující funkčnost KC eHealth, na kterou je třeba se z NIS napojit.
P.119	Vztahuje se na poskytovatele ZS v souladu s kap. 3.5 – Poskytovatelé ZS vs. funkcionality.
Náhled na propouštěcí a ambulantní zprávy
P.120	Náhled na propouštěcí a ambulantní zprávy dle požadavků uvedených v kap. 3.4.2 – Náhled na propouštěcí a ambulantní zprávy. Jedná se o existující funkčnost KC eHealth, na kterou je třeba se z NIS napojit.
P.121	Vztahuje se na poskytovatele ZS v souladu s kap. 3.5 – Poskytovatelé ZS vs. funkcionality.
Předání výjezdové zprávy ZZS do nemocnic
P.122	Předání výjezdové zprávy ZZS do nemocnic dle požadavků uvedených v kap. 3.4.3 – Předání výjezdové zprávy ZZS do nemocnic. Jedná se o existující funkčnost KC eHealth, na kterou je třeba se z NIS napojit.
P.123	Požadované úpravy NIS v souvislosti s tímto požadavkem se nevztahují na poskytovatele ZS, kteří neposkytují urgentní příjem (viz kap. 3.5 – Poskytovatelé ZS vs. funkcionality).
Sdílení informací o dostupnosti volných lůžek pro urgentní příjem
P.124	Na vyžádání automatizované poskytnutí informací o dostupnosti volných lůžek pro urgentní příjem ve struktuře požadované KC eHealth v detailu až na jednotlivá pracoviště s konkrétní odborností. Popis funkčnosti a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth.
P.125	Požadované úpravy NIS v souvislosti s tímto požadavkem se nevztahují na poskytovatele ZS, kteří neposkytují urgentní příjem (viz kap. 3.5 – Poskytovatelé ZS vs. funkcionality)
Avízo o převozu pacienta
P.126	Příjem avíz o převozu pacientů ze ZZS, jejich aktualizací, zobrazování (GUI) v NIS, poskytování informací o doručení, přečtení a akcích (potvrzení o přijetí avíza, pacienta, odmítnutí pacienta, pokud je povoleno), ukládání a archivace avíz. Popis funkčnosti a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth.
P.127	Zajištění evidence avíz a výjezdů ZZS k přijetí pacienta od ZZS v rámci výjezdu pro potřeby dalších funkcionalit (např. vyhodnocení výjezdu).
P.128	Požadované úpravy NIS v souvislosti s tímto požadavkem se nevztahují na poskytovatele ZS, kteří neposkytují urgentní příjem (viz kap. 3.5 – Poskytovatelé ZS vs. funkcionality)

#	Požadavek
Vyhodnocení výjezdů ZZS
P.129	Příjem požadavků na vyhodnocení výjezdů ZZS a automatizované odesílání ambulantních a propouštěních zpráv zpět na ZZS. Popis funkčnosti a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth.
P.130	Požadované úpravy NIS v souvislosti s tímto požadavkem se nevztahují na poskytovatele ZS, kteří neposkytují urgentní příjem (viz kap. 3.5 – Poskytovatelé ZS vs. funkcionality)
Zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ
P.131	Příjem požadavků na zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ a automatizované odesílání platných identifikačních údajů pacienta žádajícímu ZZ. Popis funkčnosti a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth.
P.132	Vztahuje se na poskytovatele ZS v souladu s kap. 3.5 – Poskytovatelé ZS vs. funkcionality.
Zjišťování registrujícího lékaře pacienta v registru VZP
P.133	Popis funkčnosti a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth.
P.134	Odeslání žádosti na zjištění registrujícího lékaře pacienta v registru VZP z NIS na KC eHealth.
P.135	Příjem a zobrazení výsledku (identifikace registrujícího lékaře) v NIS.
P.136	Vztahuje se na poskytovatele ZS v souladu s kap. 3.5 – Poskytovatelé ZS vs. funkcionality.
Výměna dat mezi poskytovateli ZS včetně dokumentů zdravotnické dokumentace vedené v elektronické formě
P.137	Popis funkčnosti a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth.
P.138	Stahování seznamu zapojených poskytovatelů ZS z KC eHealth včetně seznamu poskytovaných služeb
P.139	Doplnění NIS o zadávání požadavků na poskytované služby výměny dat a zdravotnické dokumentace: 1. Výběr požadované služby 2. Výběr poskytovatele s možností využít službu u všech zapojených poskytovatelů ZS. 3. Odeslání požadavku na službu na vybrané/všechny poskytovatele služby Konkrétní příklady služeb jsou uvedeny v požadavcích KC eHealth.
P.140	Zpracování a zobrazení výsledku požadavku na službu KC eHealth v NIS.
P.141	Seznamy příchozích a odchozích dat a zdravotnické dokumentace.
P.142	Možnost odpovídat na příchozí požadavky na služby, přikládat dokumentaci. Odpovědi musí být vždy v kontextu na původní požadavek.
P.143	Vztahuje se na poskytovatele ZS v souladu s kap. 3.5 – Poskytovatelé ZS vs. funkcionality.

#	Požadavek
Sdílení dat o zdravotní péči mezi poskytovateli ZS
P.144	Popis funkčnosti a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth.
P.145	Doplnění NIS o zadávání požadavků na sdílení dat o zdravotní péči vzdáleným přístupem (nahlížením) k záznamům a údajům o zdravotní péči k vybranému pacientovi dle identifikace pacienta (čísla pojištěnce).
P.146	Zobrazení výsledků požadavků na sdílení dat o zdravotní péči v NIS.
P.147	Automatizovaný sběr, konsolidace a odeslání záznamů a údajům o zdravotní péči k vybranému pacientovi do KC eHealth k žádosti jiného poskytovatele ZS.
P.148	Předávání do KC eHealth jednoznačné identifikace uživatelů a odůvodnění jejich oprávněnosti na sdílení/náhled na zdravotní dokumentaci pacienta.
P.149	Vztahuje se na poskytovatele ZS v souladu s kap. 3.5 – Poskytovatelé ZS vs. funkcionality.
Portál pacienta
P.150	Na vyžádání z KC eHealth poskytování informací, dat a dokumentace vztažených k pacientovi dle jeho identifikace (čísla pojištěnce) dle požadavků uvedených v kap. 3.6.6 – Portál pacienta.
Ostatní požadavky
P.151	Instalace, konfigurace modernizovaných NIS jednotlivých poskytovatelů ZS.

Tabulka 8: Požadavky: Úpravy NIS zapojených nebo zapojovaných poskytovatelů ZS

3.6.5 Nezbytné úpravy IS ZZS PAK

Nezbytné úpravy KU ZZS PAK a IS ZZS PAK pro zajištění některých nových funkcionalit (Avízo o převozu pacienta, Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ, Zjišťování registrujícího lékaře pacienta v registru VZP).

Požadavky na tuto část dodávky jsou následující:

#	Požadavek
Avízo o převozu pacienta
P.152	Realizace dle popisu funkčnosti KC eHealth a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth, další požadavky následují.
P.153	Předávání avíz o převozu pacientů ze ZZS, jejich aktualizací do KC eHealth, které předá cílovému poskytovateli ZS.
P.154	Zaslání aktualizací avíz v případě doplnění výjezdové zprávy.
P.155	V případě změny cílového zdravotnického zařízení zaslání storna původního avíza a nového avíza pro nové cílové ZZ.

#	Požadavek
P.156	Příjem aktualizací (změn stavů) ze zdravotnického zařízení (doručení, přečtení, přijetí, odmítnutí atd.).
P.157	Zobrazování seznamu avíz pro aktuální výjezd včetně všech aktualizací a informací ze ZZ.
P.158	Odmítnutí avíza – viditelné a jasné zobrazení/upozornění na odmítnutí avíza.
Vyhodnocení výjezdů ZZS
P.159	Realizace dle popisu funkčnosti KC eHealth a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth, další požadavky následují.
P.160	Příjem žádosti (dále jen „žádost“) na poskytnutí informací o stanovené diagnóze a poskytnuté zdravotní péči po důkladném vyšetření pacienta po jeho předání do péče zdravotnického zařízení akutní lůžkové péče.
P.161	Doručení žádosti na kontaktní místo pro ZZS zdravotnického zařízení, kam byl převezen pacient. Identifikace bude na základě zadané identifikace výjezdu a pacienta, bez těchto údajů nebudou informace poskytovány (omezeno výhradně na konkrétní případy předaných pacientů do péče zdravotnického zařízení).
P.162	Automatizované zaslání ambulantních a propouštěcích zpráv pacienta z NIS do KC eHealth, které zajistí doručení.
P.163	Zobrazování seznamu žádostí a odeslaných údajů/dokumentů k žádosti.
Zjišťování totožnosti pacienta (číslo pojištěnce) po jeho předání do jiného ZZ
P.164	Realizace dle popisu funkčnosti KC eHealth a předávaných dat je uveden v kap. 3.6.2 – Rozvoj funkcionalit KC eHealth, další požadavky následují.
P.165	Příjem žádosti (dále jen „žádost“) na poskytnutí informací o identifikačních údajích pacienta (primárně o číslo pojištěnce).
P.166	Doručení žádosti na kontaktní místo pro ZZS zdravotnického zařízení, kam byl převezen pacient. Identifikace bude na základě zadané identifikace výjezdu a známých (i částečných) identifikačních údajů pacienta. Funkce bude omezena výhradně na konkrétní případy předaných pacientů do péče zdravotnického zařízení.
P.167	Automatizovaná aktualizace dat z NIS a zaslání žadateli cestou KC eHealth.
P.168	Zobrazování seznamu žádostí a odeslaných údajů/dokumentů k žádosti.
Ostatní požadavky
P.169	Instalace a konfigurace modernizovaného KU ZZS PAK.
P.170	Instalace a konfigurace modernizovaného IS ZZS PAK.

Tabulka 9: Požadavky: Nezbytné úpravy IS ZZS PAK

3.6.6 Portál pacienta

Existující komunikační centrum eHealth bude rozšířeno o portál pacienta, který bude sloužit

pro poskytování informací o zdravotní péči pro pacienty v rámci zapojených poskytovatelů ZS. Požadavky na tuto část dodávky jsou následující:

#	Požadavek
Funkční požadavky
P.171	Řešení musí umožnit pacientům vzdálený autorizovaný přístup k vybraným informacím a ze zdravotnické dokumentace o jim poskytnutých zdravotních službách a jejich výsledcích v rámci zapojených poskytovatelů ZS.
P.172	Řešení musí zobrazit souhrnnou kartu, na které bude uveden: přehled zdravotních údajů o pacientovi. Souhrnný elektronický zdravotní záznam pacienta musí obsahovat údaje vedené o pacientovi v rozsahu • osobní, demografické a kontaktní údaje, • emergentní údaje (anamnézy, alergie, rizikové faktory, akutní diagnózy, akutní medikace), • přehled ambulantních a hospitalizačních případů s možností zobrazení výstupních lékařských zpráv z poskytnutých zdravotních služeb (v případě existence dokumentu ve formě EZD také přístup k této formě dokumentu), • pacientský souhrn (v případě, že v době realizace projektu bude vydán metodický pokyn MZd pro vedení tzv. „elektronického pacientského souhrnu“). • přehled naplánovaných vyšetření
P.173	Domovská stránka musí po přihlášení uživatele (pacienta) zobrazovat relevantní údaje o pacientovi, jako např. jeho demografické údaje a odkazy na další sekce s aktuálními informacemi z poskytnutých zdravotních služeb.
P.174	Uživatelské prostředí musí obsahovat hlavní navigační menu, které pacientům poskytne rychlý přístup do hlavních oblastí, jako např.: • přehled poskytnutých zdravotních služeb, • osobní data a nastavení, • souhrnný elektronický zdravotní záznam pacienta vybraných údajů ze zdravotnické dokumentace • seznam osob, na jejichž zdravotní záznamy má uživatel přístup • přístupy ke zdravotním záznamům
P.175	Řešení musí umožnit uživateli zaznamenat a měnit osobní údaje. V případě změny identifikace pacienta nenapojeného na externí identitní systém (NIA) se účet stane neověřeným a do doby jeho opětovného ověření nebude mít přístup ke zdravotnické dokumentaci.
P.176	Umožnit pořizování vlastních záznamů samotnými pacienty do osobního zdravotního záznamu.

#	Požadavek
P.177	Řešení musí zahrnovat jednoduché a dynamické uživatelské rozhraní, které nevyžaduje žádné proškolení uživatelů a je dostupné zabezpečeným způsobem přes internet prostřednictvím běžných webových prohlížečů (Firefox, Internet Explorer, Google Chrome, Safari) ve verzi dostupné v době implementace. Design uživatelského rozhraní bude navržen tak, aby v případě použití dotykového zařízení a prohlížeče podporujícího ovládání pomocí dotykového zařízení bylo ovládání ergonomické (usnadňovalo ovládání dotykem). Uživatelské rozhraní bude umožňovat rozpoznání velikosti obrazovky a přizpůsobí zobrazení velikosti této obrazovky, aby bylo použitelné i pro menší rozlišení.
P.178	Portál pacienta bude dostupný přes internet bez ohledu na lokalitu, tj. jak na území Pardubického kraje, tak i mimo toto území.
P.179	Poskytované údaje budou jen uživatelům, kteří budou mít ověřenu identitu (viz dále). Pro ostatní uživatele bude zobrazeno upozornění na neověřenou identitu, možné metody ověření a upozornění, že do doby ověření nebude možné poskytovat přístup ke zdravotnické dokumentaci.
P.180	Uživatel může poskytnout přístup ke své zdravotnické dokumentaci jen ověřeným uživatelům (rodinným příslušníkům, lékařům). Důvodem je jasná identifikace osoby, která nahlíží do zdravotnické dokumentace. Uživatel může odebrat přístup ke zdravotní dokumentaci jiným uživatelům.
P.181	Přístup ke zdravotním záznamům umožní definovat oblasti, ke kterým je přístup udělen. Budou tedy sdíleny jen a pouze záznamy z explicitně označených oblastí. Záznamy z ostatních (nesdílených) oblastí nebudou ostatním uživatelům k dispozici.
Identifikace, autorizace, autentizace externích uživatelů
P.182	Registrace uživatele bude probírat přes internet na základě zadání svých identifikačních údajů, platného telefonního čísla, emailové adresy a identifikace pacienta (čísla pojištěnce, nyní ročného čísla). V případě tohoto způsobu registrace nebude mít účet do doby ověření identity uživatele přístup k žádné zdravotnické dokumentaci (bude se jednat o neověřený účet).
P.183	Registrace a přihlášení k účtu uživatele (uživatelskému profilu), tzn. proces identifikace a autentizace uživatele, bude podporovat i alternativní metody přihlášení, konkrétně využití služeb NIA, pokud to v době realizace dodávky bude legislativně a technicky možné.
P.184	Možnost registrace a přihlášení pomocí identitních služeb v souladu s eIDAS.
P.185	Emailová adresa a telefonní číslo budou v rámci registrace ověřeny bez ohledu na metodu registrace.

#	Požadavek
P.186	Ověření identity uživatele (čísla pojištěnce) proběhne variantně: 1. Přes systém garantující identitu (např. NIA, identitní služby v souladu s eIDAS) – účet bude považován za ověřený, bude ověřená identita uživatele. 2. Pomocí návštěvy na kontaktním místě Pardubického kraje nebo zapojeného poskytovatele ZS, kde oprávněný pracovník věří identitu uživatele dle dokladu totožnosti. Jedná se o náhradu dosud neexistující infrastruktury důvěryhodné externí identity). Po ověření identity uživatele bude účet označen jako ověřený a umožní přístup k dokumentaci pacienta.
P.187	Po ověření identity uživatele nebude možné změnit identifikační číslo uživatele (číslo pojištěnce).
P.188	Pro zvýšení bezpečnosti přístupu k údajům ze zdravotnické dokumentace je požadována více faktorová autentizace (např. zadáním kódu doručeného v SMS). Poznámka: SMS bránu zajistí Objednatel a SMS budou hrazeny Objednatelem.
P.189	Možnost udělení přístupu k osobní zdravotnické dokumentaci dalším uživatelům portálu, ale jen těm, kteří mají ověřenou identitu. Důvodem je jasná identifikace osoby, která nahlíží do zdravotnické dokumentace.
Auditní služby
P.190	Veškeré přístupy, zejména ke zdravotnickým informacím, musí být logovány a zaznamenány do auditního logu a to včetně jednoznačné identifikace osoby provádějící akci a osoby, kteréí se týká akce/dokumentace.
P.191	Komunikace s NIS bude probíhat přes KC eHealth. Portál nebude perzistentně ukládat kopie dat z NIS.
Administrace objednatele
P.192	Uživatelé v následujících kategoriích: 1. Občan/pacient – externí přístup jen ke své nebo nasdílené dokumentaci. 2. Lékař – externí přístup k dokumentaci pacientů/občanů – jen informativní označení lékaře, pokud není uvedeno jinak, stejná funkčnost jako u občana/pacienta. 3. Správce portálu – správa uživatelů, logů apod. 4. Ověřování identity občanů/pacientů – uživatelé na kontaktních místech oprávnění ověřovat identitu uživatelů dle osobních údajů. Při registraci přes internet je výchozí role Občan/pacient.
P.193	Vytvoření samostatného uživatelského rozhraní pro ověřování identity pacientů pro oprávněné osoby a možnost nastavení uživatele do role Lékař.

#	Požadavek
Data z NIS poskytovatelů ZZ
P.194	Minimální rozsah zpřístupňovaných údajů prostřednictvím portálu, které by měly poskytnout informační systémy poskytovatelů ZS jsou: • osobní údaje: rodné číslo, jméno a příjmení, datum narození • bydliště: adresa, PSČ, město • alergie • rizikové faktory • trvalé medikace • trvalé diagnózy s rozšířením o diagnózy z klinických záznamů • souhrnná anamnéza • přehled dostupných zpráv z klinických událostí (nálezy z vyšetření, výsledky vyšetření, komentované výsledky vyšetření, ambulantní zprávy, propouštěcí zprávy apod.) • přehled naplánovaných vyšetření Údaje budou vyžádány z NIS zapojených poskytovatelů ZS cestou KC eHealth.
Ostatní požadavky
P.195	Instalace, konfigurace portálu pacienta na infrastrukturu KC eHealth.
P.196	Aplikace nesmí pro žádnou funkcionalitu vyžadovat doplněk v prohlížeči.
P.197	Portál musí obsahovat odkazy na stránky/portály zapojených poskytovatelů ZS, Pardubického kraje, případně další relevantní odkazy. Seznam odkazů musí být konfigurovatelný správcem.

Tabulka 10: Požadavky: Portál pacienta

3.6.7 Dodávka nezbytného rozšíření HW infrastruktury a systémového SW

V této kapitole jsou uvedeny požadavky na dodávky nezbytného rozšíření HW infrastruktury pro běh rozšířeného komunikačního centra eHealth. Jedná se o rozšíření stávajícího HW o servery, disková úložiště a poskytnutí souvisejících služeb (migrace do nového umístění, implementace, nezbytné zaškolení obsluhy, testovací provoz a provozní dokumentace pořízeného HW atd.).

Dále je jsou zde uvedeny požadavky na nezbytné rozšíření systémového SW pro běh rozšířeného komunikačního centra eHealth. Jedná se o rozšíření stávajícího systémového SW (OS, DB, licence, apod.) a poskytnutí souvisejících služeb (implementace, nezbytné zaškolení obsluhy, testovací provoz a provozní dokumentace pořízeného SW atd.).

Objednatel předepisuje část technologie a související principy a požadavky na řešení. Technologie bude dle požadavků navržena dodavatelem v nabídce v rámci veřejné zakázky s respektováním limitních podmínek.

HW a komunikační infrastrukturu a systémový SW není možné úplně specifikovat, protože jsou závislé na zvolené technologii v rámci řešení konkrétního dodavatele.

Požadavky na technické vybavení vycházejí z prostředí Objednatele uvedeného v kap. 6.3 – Informace o zapojených subjektech a jejich prostředí a podmínkách. Požadavky slouží pro rozšíření stávajícího prostředí Objednatele.

Konkrétní požadavky na vybrané technologie vyplývají z ochrany investic, kompatibility se současným prostředím Objednatele a z provozních potřeb Objednatele, kdy je nutno zajistit provoz, dohled a správu těchto zařízení pracovníky, kteří jsou k tomu již vyškoleni a disponují potřebnými technickými znalostmi.

Požadavky na tuto část dodávky jsou následující:

#	Požadavek
Komunikační centrum eHealth
P.198	Zachování stávající HW a SW infrastruktury z důvodu zajištění udržitelnosti předchozího projektu. Součástí dodávky je rozšíření/doplnění HW a SW infrastruktury.
P.199	Dodávka 1x server do datového centra NPK v min. konfiguraci: 1. 1U, možnost osazení min. 8x 2,5“ HDD, včetně bezel 2. Procesor: 2x 3. RAM: dle požadavků a potřeb dodávaného IS 4. Zdroj: 2x plně redundantní hot swap zdroje 5. HDD: 2x SSD 120 GB (určen pro běh VMware), RAID 1 6. RAID controller: fyzický, min. 4 GB NV Cash odpovídající výkonnostně PERC H740, např. HP Smart Array P408 7. Chlazení: server musí umožňovat provoz ve studené uličce chlazené na 28 st. Celsia 8. HBA: dual portová FC karta 16 Gbit, včetně 2 ks Gbic multimode 9. LAN: 2x 1Gbit metalické porty 10. LAN 10Gbit: 1x quad portová vyměnitelná onboard karta, SFP+ včetně 4 ks Gbic multimode 11. LAN management: 1x vyhrazený port pro management HW 12. Vzdálený management: možnost vzdáleného ovládání serveru na úrovni HW, odpovídající iDrac Enterpise, iLO Advanced apod. (trvalá licence s plnou funkcionalitou). 13. Optická mechanika: 1x interní DVDROM 14. Montáž do racku: vysouvací ližiny bez kabelového managementu 15. Záruka: 5 let NBD s možností prodloužit na šestý a sedmý rok Pokud uchazeč potřebuje pro své řešení vyšší parametry, dodá řešení s vyššími parametry, aby byly splněny výkonností a kapacitní požadavky uvedené v této specifikaci.
P.200	Případné rozšíření infrastruktury požadované v předchozím požadavku tak, aby byla zajištěna udržitelnost infrastruktury min. po dobu udržitelnosti (5 let). Platí pro všechny nové i rozšiřované komponenty a prvky.
P.201	Montáž a zapojení nově dodané infrastruktury do infrastruktury NPK – racky, napájení, komunikační infrastruktura.

#	Požadavek
P.202	Dodávka SW pro virtualizaci pro nově dodávanou infrastrukturu s licencí na všechna jádra a zapojení do virtuální infrastruktury v NPK. Součástí je dodávka licencí, instalace na dodanou infrastrukturu, zapojení do virtuálního prostředí NPK (včetně failover, disaster recovery procedur, zálohování apod.) a maintenance na 5 let.
P.203	Dodávka SW OS Windows Server 2016 pro nově dodávanou infrastrukturu s licencí na všechna jádra a pro všechny externí uživatele (External Connector) zapojení do infrastruktury operačních systémů v NPK. Součástí je dodávka licencí, instalace na dodanou virtuální infrastrukturu, zapojení do prostředí NPK (včetně failover, disaster recovery procedur, zálohování apod.) a maintenance na 5 let. Poznámka: konkrétní produkt je uveden z důvodu nezbytné kompatibility s prostředím NPK, do něhož má být umístěno. Prostředí je uvedeno v kap. 6.3.2.1. Součástí dodávky bude potvrzení Licencing Solution Partnera (LSP), že dodavatelem zvolený licenční model je pro dodávané řešení zvolen/nastaven správně a nedojde k porušení licenčních ujednání/autorských práv výrobce.
P.204	Přesun stávající virtuální infrastruktury KC eHealth uvedené v kap. 6.1.3 – Stávající technologie, HW a SW infrastruktura z datového centra ZZS PAK do datového centra NPK (lokalita Pardubická nemocnice) na novou fyzickou infrastrukturu.
P.205	Přepojení integrací (např. eHealth KV/eMeDocS) tak, aby byly funkční z KC eHealth v novém umístění.
P.206	Součinnost při zapojení nově dodávané virtuální infrastruktury do zálohování NPK. Vlastní zálohování zajistí NPK pomocí nástroje SW Veeam Availibility Suite Enterprise.
P.207	Před uvedením do provozu ověření failover, disaster recovery procedur, zálohování apod.
Komunikační uzly poskytovatelů ZS
P.208	KU ZZS PAK: Zachování KU ZZS PAK v lokalitě ZZS PAK, přesun na virtuální infrastrukturu ZZS, případné rozšíření vyplývající z potřeb modernizovaného systému, přepojení/rekonfigurace tak, aby bylo napojeno na KC eHealth v novém umístění (DC NPK).
P.209	KU NPK: 1. Zachování KU NPK v lokalitě NPK, případné rozšíření funkčnosti KU NPK. 2. KU NPK bude pro všechny lokality (5 lokalit) realizován na jednom (existujícím) KU NPK v souladu s výchozím stavem a připravovaným projektem modernizace KIS NPK uvedeným v kap. 6.3.2.1. 3. Připojení KU NPK s KIS/NIS jednotlivých nemocnic NPK bude realizováno prostřednictvím komunikační infrastruktury NPK.

#	Požadavek
	4. Součástí je případné rozšíření infrastruktury KU NPK vyplývající z potřeb modernizovaného systému, napojení více KIS/NIS, přepojení/rekonfigurace tak, aby bylo napojeno na KC eHealth v novém umístění (DC NPK).
P.210	KU ostatních poskytovatelů ZS (mimo ZZS a NPK): Dodávka infrastruktury pro každý jednotlivý nově zřizovaný KU pro nově připojované poskytovatele ZS, včetně zapojení, instalace a konfigurace v DC příslušného poskytovatele ZS. Zapojení do infrastruktury poskytovatele ZS. Nové komunikační uzly budou dodány v co nejmenším provedení – rackové max. 1U nebo samostatné odpovídající velikosti (preferovaná je racková varianta, výběr bude dle prověření místních možností v DC poskytovatele ZS při zahájení realizace). Komunikační uzly budou vybaveny konektory min. 1x LAN, min. 1x WAN. Případné další parametry a vybavení musí odpovídat potřebám řešení dodavatele technologie.
P.211	Firewally ostatních poskytovatelů ZS (mimo ZZS a NPK): Připojení KU ostatních poskytovatelů ZS (mimo ZZS a NPK) bez přístupu do krajské komunikační sítě (RDS) do datové sítě NPK ke KC eHealth bude prostřednictvím zabezpečené komunikace přes internet na bázi IPSec. Součástí dodávky je tedy HW Firewall pro vytvoření spojové sítě (IPSec) z DC každého nového poskytovatele ZS bez přístupu do krajské komunikační sítě (RDS) do sítě NPK. NPK využívá HW Firewall Fortigate (viz kap. 6.3.2.1) a je třeba zajistit plnou kompatibilitu nově dodávaných FW s FW NPK. Součástí dodávky FW je maintenance na 5 let. Poznámka: seznam poskytovatelů ZS bez přístupu do RDS je uveden v kap. 6.3.2.
P.212	Dodávka a instalace OS na nově dodávané KU pro nově připojované poskytovatele, včetně licencí, instalace, konfigurace.
Ostatní požadavky
P.213	Pokud řešení dodavatele (včetně navýšení infrastruktury) vyžaduje navýšení licencí systémového SW (virtualizace, OS, DB software) uvedené 6.1.3 – Stávající technologie, HW a SW infrastruktura, je součástí dodávky navýšení licencí, jejich instalace/implementace a registrace na objednatele.
P.214	Pokud stávající systémový SW vyžaduje instalaci patchů od výrobce, je součástí dodávky instalace těchto patchů.
P.215	Nastavení zálohování serverů a dat do místně příslušného zálohovacího systému poskytovatele ZS. V případě KC eHealth, Portálu pacienta a KU NPK se jedná o zálohování NPK, v ostatních případech se jedná o zálohování KU do systému příslušného poskytovatele ZS.

Tabulka 11: Požadavky: Dodávka nezbytného rozšíření HW infrastruktury a systémového SW

3.6.8 Auditní služby

Požadavky na tuto část plnění jsou následující:

#	Požadavek
P.216	Navržená softwarová aplikace umožní provádět audity užití na základě interních logů aplikace, které zaznamenávají a ukládají údaje o změnách či nahlížení do pacientské dokumentace podle identity uživatelů.
P.217	Řešení umožní poskytovat auditní reporty o přístupech uživatelů (kdo, kdy, období, kam) na základě parametrizace prováděné pověřeným auditorem.
P.218	Auditní (logovací) aparát je dostupný pouze určené roli (auditor). Není dostupný a manipulovatelný uživateli, administrátory ani správci.
P.219	Systém musí umožnit automatizované i 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)
P.220	Auditní systém musí být v souladu s nařízení EU o ochraně osobních dat (GDPR).

Tabulka 12: Auditní služby

3.6.9 Bezpečnostní požadavky

V následující tabulce je seznam požadavků na tuto část dodávky:

#	Požadavek
P.221	Řešení bude pracovat s identifikací pacienta v souladu s legislativou a prováděcími předpisy platnými ke dni dokončení realizace řešení, vč. zajištění připravenosti na postupné opuštění rodných čísel jako jediného a výměnného identifikátoru a zavedení bezvýznamových identifikátorů během doby udržitelnosti, pokud nebude možné tento přechod realizovat během realizace projektu.
P.222	Systém bude chránit osobní údaje pacientů a bude v souladu s Nařízením Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob (GDPR) v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů.
P.223	Identifikace a autorizace uživatelů bude probíhat v souladu s požadavky ZKB a návazných norem v aktuálním znění.
P.224	Autorizace: Poskytnutí přístupu autentizovaného uživatele k aktivu systému (data, aplikace), odpovídající pracovnímu zařazení uživatele a přidělené roli (rolím) v systému. Systém umožní řídit přístupová oprávnění jednotlivých subjektů jen k údajům, ke kterým mají a mohou mít přístup.
P.225	Zabránění vstupu neautorizovaného subjektu do systému – zamezení možnosti přístupu neoprávněného subjektu.

#	Požadavek
P.226	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í serverů, řízený patch management).
P.227	Dostupnost: 1. Zajištění dostupnosti systému jako celku (společné služby – servery, databáze, aplikační servery) v režimu 24x7x365 s maximální celkovou dobou neplánovaného výpadku podle požadavků v servisní smlouvě. 2. Odpovídající HW a SW architektura řešení pro zajištění této dostupnosti. 3. Dekompozice SLA na jednotlivá aktiva podle kategorizace jejich důležitosti/dopadu na dostupnost systému
P.228	Zajištění šifrované komunikace (např. SSL): 1. mezi všemi součástmi systému (KC, KU, KIS/NIS ZZ), 2. pracovišť uživatelů (PC, notebooky, tablety, mobilní telefony) v odděleném síťovém prostředí.
P.229	Evidence přístupů všech uživatelů do systému (logování) včetně časových údajů.
P.230	Evidence veškerých datových změn na úrovni DB položky (položky datasetu). Atributy: kdo, kdy, původní hodnota, nová hodnota.
P.231	Veškeré přístupy k datům a aktivita uživatelů budou logovány tak, aby byly zřejmé přístupy k jednotlivým údajům a zpětná kontrola těchto údajů. V systému bude evidována jednoznačná identifikace kdo, kdy provedl zápis do systému nebo provedl náhled do dokumentace. Tyto logy budou zabezpečeny proti změnám.
P.232	Veškerá externí komunikace (mimo LAN) bude zajišťována prostřednictvím zabezpečených (šifrovaných kanálů). V případech, kdy to bude možné, bude komunikace probíhat přes KIVS nebo přes krajskou datovou síť.
P.233	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ů, ochrana použitím anti-X řešení. Standardní ochrana serverů pomocí firewallů/UTM. Přístup do prostor s fyzickými servery bude řízen a umožněn jen oprávněným osobám.
P.234	Veškeré logy budou dostupné pro externí logmanager/SIEM.

Tabulka 13: Bezpečnostní požadavky

3.6.10 Implementační a provozní požadavky

V následující tabulce je seznam požadavků na tuto část dodávky:

Požadavek

P.235

Systém musí být připraven na provoz 24x7x365 (non-stop).

P.236

Předmětem zakázky jsou i veškeré služby související s dodávkou – doprava, instalace,

implementace do stávající infrastruktury, konfigurace a zprovoznění komunikace, nastavení

#	Požadavek
	datových toků, seznámení s obsluhou a správou systému, testování, 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í dodavatel 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.
P.237	Instalace do prostředí objednatele uvedeného v kap. 6.3 – Informace o zapojených subjektech a jejich prostředí a podmínkách.
P.238	V rámci implementace musí dodavatel zajistit plnohodnotný provoz dodávaného řešení současně s provozem stávajících systémů. To vše bez jakéhokoliv omezení provozu. Dodavatel do nabídky popíše postup přechodu systémů. Dodavatel je povinen přizpůsobit realizaci předmětu zakázky podmínkám objednatele.
P.239	Dodávka OS na servery, včetně instalace do prostředí objednatele, vč. potřebných licencí, pokud se jedná o licencovaný OS.
P.240	Všechny součástí systému (OS, DB, IS, klientské aplikace) musí logovat svou činnost do logů s možností nastavit úroveň logování pro potřeby diagnostiky.
P.241	Zálohování – systém (OS) a DB musí být schopny a připraveny na zálohování externím systémem objednatele, tj. pro OS a DB musí existovat agenti umožňující zálohování ze strany objednatele. Informace k zálohovacímu systému objednatele jsou uvedeny v kapitole 6.3 – Informace o zapojených subjektech a jejich prostředí a podmínkách.
P.242	Zajištění administrátorských aplikací, konzolí pro všechny součástí systému (OS, DB, IS, …) pro zajištění konfiguračního managementu systému anebo jeho součástí, zajištění konfigurace na jednom místě s případnou vnitřní distribucí nastavení do jednotlivých částí systému.
P.243	Dohled – systém musí předávat informace o svém stavu (stavu služeb apod.) na žádosti SNMP GET. Zhotovitel poskytne parametry, podmínky a součinnost při nastavení dohledu dodaného řešení.
P.244	Architektura řešení celého systému musí korespondovat s požadavky na jeho dostupnost, uvedenými v servisní smlouvě.
P.245	Synchronizace času všech zařízení s time serverem nebo zprostředkovaně přes centrální systém.

Tabulka 14: Provozní požadavky

3.7 Požadavky na služby

3.7.1 Realizace předmětu plnění

Součástí předmětu plnění je zajištění služeb souvisejících s realizací předmětu plnění minimálně

v následujícím rozsahu:

1) Objednatel požaduje před zahájením implementačních prací 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 předmětu plnění. 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 musí obsahovat minimálně tyto části:

a) Implementační analýza – zjištění týkající se prostředí objednatele, bude obsahovat alespoň následující:

i) Seznam technologií objednatele, které mají vliv/dopad na dodávku

ii) Identifikace zdrojů dat využitých pro dodávku

iii) Evaluace bezpečnosti systému a rizikových faktorů

iv) Implementační upřesnění specifikace požadavků

v) Výstupy z analýzy okolí – sběr a analýza informací vztahujících se k dodávce (např. součinnosti apod.)

b) Detailní popis cílového stavu (instalační a montážní upřesnění návrhu řešení z nabídky) Popis bude obsahovat alespoň:

i) Rozpracování návrhu řešení z nabídky zhotovitele z pohledu instalací a montáže dle informací z implementační analýzy

ii) Upřesnění rozhraní pro integraci na IS a technologie třetích stran (v případě nutnosti)

iii) Způsob zajištění projektového řízení na straně zhotovitele pro realizaci předmětu plnění (harmonogram, projektový tým, koordinační mechanismy apod.)

iv) Detailní návrh a popis postupu implementace, instalace a montáže předmětu plnění

v) Detailní popis zajištění bezpečnosti systému a informací

Detailní harmonogram projektu včetně uvedení kritických milníků. Kritické milníky jsou termíny dosažení určitých fází projektu, které jsou pro naplnění cílů projektu klíčové. Kritické milníky budou obsahovat minimálně aktivity vedené v kapitole 4 - Harmonogram, s uvedením konkrétních termínů, zhotovitel vhodným způsobem může rozšířit kritické milníky o další aktivity, které mohou být pro projekt klíčové.

vi) Detailní popis navrhovaného seznámení s funkcionalitami, obsluhou dodávaného zařízení a budoucím provozem

2) Zajištění projektového vedení realizace předmětu plnění ze strany zhotovitele a jeho případných subdodavatelů.

3) Vývoj, implementace a nastavení informačních a komunikačních technologií odpovídající schválenému návrhu řešení uvedenému v Implementační analýze a příprava pro ověření ze strany objednatele, alespoň v následujícím rozsahu:

a) Vývoj na straně zhotovitele – vývoj jednotlivých systémů, úpravy existujících produktů, jejich parametrizace a nastavení, vývoj a ověřování integračních rozhraní, součinnost se třetími stranami v souvisejících oblastech.

b) Instalace a implementace do prostředí objednatele v testovacím režimu.

c) Interní ověření na straně zhotovitele a příprava podkladů pro ověření na straně objednatele (dokumentace, organizace testování a další).

d) Příprava a naplnění základních dat – z integračních úloh, číselníky, uživatelé a další. Provedením těchto činností bude zajištěna připravenost pro ověření ze strany objednatele.

4) Dodávka předmětu plnění. Součástí dodávky musí být instalace, upgrade a sestavení předmětu zakázky včetně:

a) Instalace, upgrade a zahoření HW na místě,

b) Instalace a nastavení HW a SW budou provedeny kvalifikovanými osobami pro dané typy zařízení

c) Nastavení HW a aplikací

5) Zajištění instalace všech součástí dodávky v určených lokalitách a prostorách objednatele

6) Zajištění instalace a připojení k zařízením a technickým prostředkům zajištěným objednatelem.

7) Realizace pilotního provozu k ověření funkčnosti systému na menším obejmu dat, s menším počtem uživatelů a na menším počtu zařízení.

8) Převedení systémů do zkušebního provozu a plná podpora uživatelů v rámci zkušebního provozu včetně technické podpory. V této etapě budou realizována požadovaná seznámení s funkcionalitami, obsluhou dodávaného zařízení a budoucím provozem.

9) Zpracování dokumentace skutečného provedení, systémové a provozní dokumentace – součástí předmětu plnění je zajištění systémové a provozní dokumentace související s realizací předmětu plnění minimálně v následujícím rozsahu:

Název	Popis
Uživatelská dokumentace	Bude popisovat konkrétní funkčnost z pohledu uživatele tak, aby byl uživatel schopen práce s informačním systémem a pochopil význam jednotlivých částí systému a vazeb mezi nimi. V uživatelské příručce bude popisován způsob práce s jednotlivými částmi systému, vazby mezi nimi včetně popisu součástí jednotlivých částí systému. K usnadnění práce bude sloužit popis jednotlivých obrazovek, ovládacích prvků na obrazovkách a jejich významů, který bude uveden v rámci uživatelské dokumentace.
Dokumentace skutečného provedení a systémová/provozní dokumentace	Obsahuje popis informačního systému (rozhraní a služby) včetně popisu správy informačního systému, definování uživatelů, jejich oprávnění a povinností a detailní popis údržby systému.
Bezpečnostní dokumentace	Účelem bezpečnostní dokumentace je definovat závazná pravidla pro zajištění informační bezpečnosti včetně stanovení

Název	Popis
	bezpečnostních opatření. Součástí této dokumentace bude uveden seznam, který bude obsahovat seznam všech externích zdrojů, ke kterým se jednotlivé servery (součásti systému) připojují, včetně uvedení síťových protokolů, pomocí kterých se s daným externím zdrojem komunikuje. V případě, že na servery (součásti systému) existuje vzdálený přístup, musí být tento přístup jasně specifikován (vzdálené zařízení, síťový protokol) a popsán zdůvodnění takovéhoto přístupu (dohled, správa DB atd.)
Disaster & Recovery Plan	Plán řešení situací v případě výpadků a obnovy funkčnosti systému. Součástí je plán a způsob provádění zálohy a případného způsobu obnovy a obnovy funkčnosti i v případě jiných technických výpadků. Dokument bude vytvářen v součinnosti s objednatelem.
Projektová dokumentace	Smluvní dokumentace, harmonogram realizace projektu, analýzy a prováděcí projekty, zápisy z jednání, protokoly (předávací, akceptační)

Tabulka 15: Dokumentace – požadavky na zpracování

Dokumentace bude dodána v relevantním rozsahu na všechna místa plnění projektu.

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

Dokumenty budou zpracovávány v následujících programech elektronicky a uloženy

v následujících formátech:

• MS Office 2010 (MS Word 2010, MS Excel 2010, MS PowerPoint 2010)

• MS Project 2010

• WinZip (formát .zip)

• Portable Document Format (formát .pdf).

Preferovaná forma předávaných dokumentů, které nebudou vyžadovat podpisy konkrétních osob je elektronicky a to na elektronických nosičích (CD, DVD, flash disk, atp.). K předávání a k archivaci souborů se používají média s možností pouze zápisu, nikoliv přepisovatelná.

Veškerá dokumentace bude podléhat schvalování (akceptaci) při převzetí ze strany objednatele. Veškerá dokumentace musí být zhotovena výhradně v českém jazyce, bude dodána ve 2x kopiích

v elektronické formě ve standartních formátech (MS Office a PDF) používaných objednatelem

na datovém nosiči a 1x kopii v papírové formě.

10) Provedení akceptačních testů. Zhotovitel je povinen kompletně připravit podklady pro akceptaci dodaného řešení. Součástí akceptace bude akceptační protokol a kompletní předávací dokumentace.

11) Uvedení systému do produkčního provozu, zajištění potřebných nastavení a přístupů pro všechny pracovníky objednatele, minimalizace dopadů na provoz objednatele při přechodu a zvýšená podpora bezprostředně po přechodu do produkčního provozu.

12) Xxxxxxxxxx dle svého uvážení doplní v nabídce další služby, které jsou dle jeho názoru nezbytné pro úspěšnou realizaci zakázky.

13) Veškeré náklady na zajištění služeb souvisejících s realizací předmětu plnění musí být zahrnuty

v ceně odpovídající části předmětu dodávky.

3.7.2 Seznámení s funkcionalitami, obsluhou dodávaného systému

V této kapitole jsou uvedeny požadavky na seznámení s funkcionalitami, obsluhou dodávaného zařízení a jeho budoucím provozem:

1) Zhotovitel proškolí pracovníky objednatele se všemi typy dodaných zařízení a aplikací a problematikou jejich užití, provozu a obsluhy. Zhotovitel se zavazuje poskytnout informace minimálně k následujícím tématům v dostatečném detailu pro porozumění činnosti zařízení a způsobu provozu:

a) Základní produktové seznámení s jednotlivými dílčími technologickými celky.

b) Celkové schéma součinnosti jednotlivých zařízení a jejich návaznosti.

c) Obsluha jednotlivých dílčích modulů, aplikací a technologických celků

d) Použitá nastavení zařízení, detailnější rozbor použitých konfigurací.

e) Základní kroky správy, diagnostiky a elementární postupy pro řešení problémů.

2) Poskytnuté informace zajistí seznámení vybraných klíčových pracovníků objednatele se všemi podstatnými částmi dodávky v rozsahu potřebném pro obsluhu, provoz, údržbu a identifikaci nestandartních stavů systému a jejich příčin.

3) Konkrétní požadavky na seznámení jednotlivých skupin uživatelů je následující:

Poskytovatel ZS	Uživatelé	Správci
Léčebna dlouhodobě nemocných Rybitví (LDN Rybitví)	5	2
Odborný léčebný ústav Jevíčko (OLU Jevíčko)	5	2
Albertinum, odborný léčebný ústav Žamberk (OLÚ Albertinum Žamberk)	5	2
Nemocnice následné péče Moravská Třebová (NNP Moravská Třebová)	5	2
Vysokomýtská nemocnice (NVM)	5	2
Rehabilitační ústav Brandýs nad Orlicí (RÚ BnO)	5	2
Pracoviště NPK:	5	2
Pardubická nemocnice	5	2
Chrudimská nemocnice	5	2
Orlickoústecká nemocnice	5	2
Litomyšlská nemocnice	5	2
Svitavská nemocnice	5	2

Poskytovatel ZS	Uživatelé	Správci
Zdravotnická záchranná služba Pardubického kraje (ZZS PAK)	5	2

Tabulka 16: Seznámení s obsluhou – personál

4) Vše uvedené bude probíhat v prostorách objednatele s využitím vybavení dodaného v rámci této veřejné zakázky, případně zajištěné ze strany objednatele.

5) Konkrétní termíny určí objednatel dle postupu v rámci realizace projektu a dostupnosti zainteresovaných osob.

Veškeré náklady na zajištění těchto činností musí být zahrnuty v ceně odpovídající části předmětu dodávky.

3.8 Záruky

V této kapitole jsou uvedeny požadavky na záruky dodávky jako celku, případně specificky dílčích částí dodávky.

Objednatel požaduje záruku na veškeré dodané technologie včetně nezbytných provozních a servisních služeb v délce trvání minimálně:

a) 60 měsíců na informační systém(y), aplikace a služby spojené s realizací projektu,

b) 36 měsíců – u HW infrastruktury a systémového SW, pokud není u jednotlivé položky uvedena vyšší požadovaná záruka.

c) 12 měsíců na spotřební materiál, případně drobné vybavení podléhající rychlému opotřebení. Případný spotřební materiál musí být explicitně označen v nabídce a smlouvě a musí být prokázáno, že splňuje tento charakter.

Záruka začíná běžet od okamžiku předání do ostrého (produkčního) provozu. Veškeré opravy po dobu záruky budou bez dalších nákladů pro provozovatele (objednatele). Veškeré komponenty, náhradní díly a práce budou poskytnuty bezplatně v rámci záruky. Xxxxxxxxxx ve své nabídce výslovně uvede všechny podmínky záruk.

a) Po dobu záruky na části dodávky musí zhotovitel nebo výrobce všech zařízení garantovat běžnou dostupnost náhradních komponentů a dostupnost servisu.

b) Součástí záruky je i shoda dodávaných systémů s platnou legislativou.

c) Zhotovitel uvede provozní a servisní služby požadovaného předmětu plnění veřejné zakázky včetně parametrů, které budou předmětem dodávek v rámci záruky systému a v rámci poskytování servisních služeb.

Poskytovatel zajistí HelpDesk pro hlášení vad.

4 Harmonogram

Následující tabulka obsahuje požadovaný časový harmonogram realizace dodávky (T ~ datum účinnosti smlouvy o dílo):

#	Fáze	Doba trvání od zahájení	Doplňující informace
1	Zahájení realizace	0	Zahájení realizace bude dnem podpisu smlouvy na dodávku.
2	Analýza a návrh řešení	45	Zpracování analýzy a návrhu řešení pro potřeby upřesnění podmínek realizace dodávek.
3	Dodávka, implementace, instalace, konfigurace HW a SW infrastruktury	60	Dodávka a implementace HW, SW a síťové infrastruktury.
4	Vývoj a implementace SW, dodávka dokumentace k SW	120	Vlastní vývoj a implementace IS dle analýzy a návrhu řešení.
5	Ověření funkčnosti dodaného systému a jeho částí	150	Otestování systému a ověření jeho plné funkčnosti.
6	Zaškolení uživatelů a administrátorů.	150	Součástí je i zaškolení v oblasti metodiky pro pracovníky KÚ ZK a zapojených nemocnic.
7	Dodávka dokumentace dodaného systému a jeho částí	150	Min. uživatelská dokumentace, dokumentace skutečného provedení, systémová dokumentace, projektová dokumentace.
8	Převedení do zkušebního provozu	150	Zahájení zkušebního provozu, cílem je ověření funkčnosti v provozu a odstranění všech zbývajících vad a nedodělků.
9	Ukončení zkušebního provozu, ukončení realizace a převedení do provozní fáze	180	Ukončení zkušebního provozu, ukončení realizace a převedení do provozní fáze.

Tabulka 17: Harmonogram

Doplňující informace:

• Pod pojmem „den“ je míněn kalendářní den.

• Zhotovitel má možnost definovat kratší termíny plnění (netýká se doby poskytování servisních služeb).

5 Mí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
Nemocnice Pardubického kraje, a. s. (NPK)	Pardubická nemocnice: Pardubice, Kyjevská 44	Datová centra NPK: přesun komunikačního centra eHealth PAK ze ZZS PAK na nově pořízenou infrastrukturu v těchto DC. Dodávka a umístění nově dodaných funkcionalit komunikačního centra, portálu pacienta a související infrastruktury a technologií.
		Tato datová centra jsou umístěna v rámci uzlu krajské datové sítě (RDS).
		Umístění KKC v těchto datových centrech zajistí dostupnost v rámci krajské datové sítě, napojení na KIVS a tedy i na centrální sdílené služby (NIA), případně v budoucnu IS ZR prostřednictvím AIS OVM)
	Chrudimská nemocnice: Václavská 570, Chrudim	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči.
	Orlickoústecká nemocnice: Čs. Armády 1076, Ústí nad Orlicí	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči.
	Litomyšlská nemocnice: J. E. Purkyně 652, Litomyšl	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči.
	Svitavská nemocnice: Kollárova 7, Svitavy	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči.
Zdravotnická	Průmyslová 450,	V datovém centru ZZS PAK je již nyní umístěna část
záchranná služba	Pardubičky,	technologie KC eHealth PAK, která bude přesunuta do
Pardubického	Pardubice	datového centra NPK. V DC ZZS PAK zůstane komunikační
kraje (ZZS PAK)		uzel eHealth PAK pro zachování integrace s IS ZZS PAK
		(OŘ/EKP/MZD) a zajištění vzájemné výměny dat a
		dokumentů o zdravotní péči.

Místo	Adresa	Předmět realizace
		Technologie stávajícího systému zůstane ve vlastnictví žadatele/příjemce, bude jen umístěna do DC poskytovatele ZS, aby zajistila integraci eHealth PAK a IS ZZS PAK.
Léčebna dlouhodobě nemocných Rybitví (LDN Rybitví)	Činžovních domů 139 – 140, Rybitví	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči. Technologie zůstane ve vlastnictví žadatele/příjemce, bude jen umístěna do DC poskytovatele ZS, aby zajistila integraci eHealth PAK a NIS poskytovatele ZS.
Odborný léčebný ústav Jevíčko (OLU Jevíčko)	TRN-Léčebna 508, PSČ Jevíčko	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči. Technologie zůstane ve vlastnictví žadatele/příjemce, bude jen umístěna do DC poskytovatele ZS, aby zajistila integraci eHealth PAK a NIS poskytovatele ZS.
Albertinum, odborný léčebný ústav Žamberk (OLÚ Albertinum Žamberk)	Za Kopečkem 353, Žamberk	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči. Technologie zůstane ve vlastnictví žadatele/příjemce, bude jen umístěna do DC poskytovatele ZS, aby zajistila integraci eHealth PAK a NIS poskytovatele ZS.
Nemocnice následné péče Moravská Třebová (NNP Moravská Třebová)	Moravská Třebová, Svitavská 25	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči. Technologie zůstane ve vlastnictví žadatele/příjemce, bude jen umístěna do DC poskytovatele ZS, aby zajistila integraci eHealth PAK a NIS poskytovatele ZS.
Vysokomýtská nemocnice (NVM)	Hradecká 167, Pražské Předměstí, Vysoké Mýto	V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči. Technologie zůstane ve vlastnictví žadatele/příjemce, bude jen umístěna do DC poskytovatele ZS, aby zajistila integraci eHealth PAK a NIS poskytovatele ZS.

Místo

Adresa

Předmět realizace

Rehabilitační

ústav Brandýs nad Orlicí (RÚ BnO)

Lázeňská 58,

Brandýs nad Orlicí

V datovém centru poskytovatele ZS bude umístěna část technologie projektu, konkrétně moduly komunikační uzel eHealth PAK pro integraci s NIS poskytovatele ZS a zajištění vzájemné výměny dat a dokumentů o zdravotní péči.

Technologie zůstane ve vlastnictví žadatele/příjemce, bude jen umístěna do DC poskytovatele ZS, aby zajistila integraci eHealth PAK a NIS poskytovatele ZS.

Tabulka 18: Místa plnění

6 Výchozí stav

V této kapitole je uveden výchozí stav a výchozí podmínky pro dodávku předmětu plnění.

6.1 Současné řešení eHealth PAK

Současné řešení bylo realizováno v roce 2015 v projektu „Modernizace a standardizace vybavení Zdravotnické záchranné služby Pardubického kraje“, který byl Zdravotnickou záchrannou službou Pardubického kraje (ZZS PAK) realizován v rámci Integrovaného operačního programu (IOP), výzvy č. 23.

6.1.1 Koncept současného řešení

Na následujícím schématu je uvedeno současné řešení eHealth realizované v roce 2015:

Obrázek 2: Výchozí stav

Ohraničení plnění bylo předmětem předchozího projektu.

V následující tabulce je uveden výčet prvků ze schématu včetně uvedení jejich významu:

Prvek	Popis
Datové centrum ZZS PAK	Datové centrum ZZS PAK - v tomto DC jsou umístěny prvky KC ZZS PAK a KU ZZS PAK a je v něm realizováno propojení s OŘ/EKP/MZD na straně ZZS PAK a KC KKS KV eMeDocS.
KC ZZS PAK	Krajské komunikační centrum eHealth systému Pardubického kraje, které zajišťuje datovou výměnu mezi zapojenými poskytovateli ZS a obdobným centrem Kraje

Prvek	Popis
	Vysočina, prostřednictvím kterého jsou do výměny zapojeni i někteří další poskytovatelé ZS v jiných krajích, které nemají vlastní krajská centra.
KU ZZS PAK	Komunikační uzel KKS na straně ZZS PAK. KU ZZS PAK zajišťuje propojení s provozními systémy ZZS PAK (OŘ/EKP/MZD).
OŘ/EKP/MZD	SW pro operační řízení (IS OŘ) mobilní sběr dat o pacientech (MZD/EKP), který poskytuje data pro služby eHealth a čerpá data z eHealth (od poskytovatelů ZS).
DC PKN	Datové centrum Nemocnice Pardubického kraje, a.s. - v tomto DC je umístěn KU KKS PKN a realizováno propojení s NIS PKN v lokalitě nemocnice v Pardubicích. Poznámka: PKN je zkratka z předchozího projektu a označuje taktéž Nemocnice Pardubického kraje, a.s., v tomto projektu je označuje NPK.
KU PKN	Komunikační uzel KKS na straně Nemocnice Pardubického kraje, a.s., v lokalitě nemocnice v Pardubicích. KU KKS PKN je propojen s NIS PKN.
NIS PKN	Nemocniční informační systém (NIS) Nemocnice Pardubického kraje, a.s., v lokalitě nemocnice v Pardubicích. Tento systém nyní přijímá data od ZZS PAK a poskytuje data pro ZZS PAK prostřednictvím KU PKN.
ZZ PKN <-> ZZS PAK	Komunikační infrastruktura/linka propojující ZZ PKN a ZZS PAK. Komunikace již není přes internet, ale přes krajskou síť, ale řešení je realizováno tak, že je nezávislé na typu sítě.
ZZS PAK <-> KV	Komunikační infrastruktura/linka propojující ZZS PAK a Kraj Vysočina (DC). Komunikace již není přes internet, ale přes propojovací síť AKČR (ITS NGN, CMS 2.0, Krajské konektory), ale řešení je realizováno tak, že je nezávislé na typu sítě.
DC/eMeDocS Kraje Vysočina	Umístění existujícího systému eHealth Kraje Vysočina (eMeDocS), na který je napojeno KKC ZZS PAK.

Tabulka 19: Prvky existujícího řešení

6.1.2 Funkcionality současného řešení

Současné řešení zajišťuje následující funkcionality:

1. Vyhledání životních údajů pacienta

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

3. Předání výjezdové zprávy ZZS do nemocnic

Funkcionality jsou detailně popsány v kap. 3.4 – Rozsah funkcionality sdílení a vyměňování dat mezi

poskytovateli ZS, text není kopírován, aby bylo zamezeno zbytečné duplicitě textu.

Funkcionality zůstanou zachovány i v rámci modernizovaného řešení a v rámci dodávky budou rozšířeny na další poskytovatele ZS.

6.1.3 Stávající technologie, HW a SW infrastruktura

Web server (webová aplikace) & gateway pro KC KKS KV
OP:	4 GB
CPU:	4 x vCPU
HDD:	80 GB SATA
LAN:	Ethernet 1 Gb/s – zapojený do DMZ s řízeným uživatelským přístupem z Internetu
OS:	Windows Server 2012R2 Std. Ed
Hostitel:	ESXi1
Komunikační server KC ZZS PAK
OP:	4 GB
CPU:	4 x vCPU
HDD:	80 GB SATA
LAN:	Ethernet 1 Gb/s – zapojený do interní LAN resp. VLAN pro centrální servery eHealth
OS:	Windows Server 2012R2 Std. Ed
DB:	MS SQL Server 2012 Express
hostitel:	ESXi1

Komunikační uzel KU ZZS
OP:	3 GB
CPU:	2 x vCPU
HDD:	80 GB SATA
LAN:	Ethernet 1 Gb/s – zapojený do interní LAN resp. VLAN pro centrální servery eHealth
OS:	Windows Server 2012R2 Std. Ed
Hostitel:	ESXi2

V následující tabulce je uvedeno současné řešení technologií, HW a SW:

Prvek	HW a SW infrastruktura
KC ZZS PAK	2x virtualizační server DELL PowerEdge R320; 2x Windows Server 2012 R2 Std. Ed.; 2x SQL Server 2012 Std. Runtime Core 2Lic Vlastní centrální servery jsou virtualizované na bázi vSphere ESXi 6.0 na 4 virtuální servery s následujícími parametry:
		Server pro SNMP monitoring a správu
		OP:	4 GB
		CPU:	2 x vCPU
		HDD:	80 GB SATA
		LAN:	Ethernet 1 Gb/s – zapojený do interní LAN resp. VLAN pro centrální servery eHealth
		OS:	Windows Server 2012R2 Std. Ed
		Hostitel:	ESXi2
KU ZZS PAK	Komunikační uzel je vytvořen jako virtuální server na infrastruktuře v DC ZZS PAK uvedené výše.

Prvek

HW a SW infrastruktura

KU PKN

Virtuální server s těmito parametry:

Síťové rozhraní je zapojeno do DMZ NPK PN.

ZZS PAK <-> KV

Integrační rozhraní na eMeDocS – na straně KC ZZS PAK je rozhraní tvořeno komunikačními bránou (gateway), která je umístěna web server KC ZZS PAK, a která komunikuje s komunikační bránou na straně KC KKC KV. Komunikační gateway odpovídá specifikaci „2014-11-12 Povinné API krajského uzlu pro předávání zdravotnické dokumentace_v3.1.docx“

KU PKN
OP:	4 GB
CPU:	2 x vCPU
HDD:	60 GB SATA
LAN:	Ethernet 1 Gb/s – zapojený do interní LAN resp. VLAN pro centrální servery eHealth
OS:	MS Windows Server 2008 R2 Ent.
DB:	MS SQL Server 2014 Express
Hostitel:	Hyper-V klastr

Tabulka 20: Stávající technologie, HW a SW infrastruktura

6.1.4 Krajská komunikační infrastruktura

V rámci Pardubického kraje je provozována krajská síť – v tomto dokumentu označovaná jako krajská komunikační infrastruktura nebo regionální datová síť (RDS), která slouží pro propojení subjektů Pardubického kraje (kraje, organizací zakládaných nebo zřízených krajem apod.) a dále je propojena na národní komunikační infrastrukturu.

Ne všechny subjekty dotčené projektem jsou na tuto infrastrukturu připojeny – konkrétně je uvedeno u jednotlivých poskytovatelů ZS.

Primárně bude komunikace mezi zapojenými subjekty probíhat prostřednictvím této infrastruktury. V případech, kdy napojení nebude existovat, zajistí postupně Pardubický kraj připojení těchto subjektů, nicméně ve výchozím stavu bude komunikace probíhat zabezpečeným způsobem přes internet zabezpečená přes IPSec.

6.1.5 Stav a problémy výchozího stavu

Současné řešení je nyní v realizovaném rozsahu plně funkční, tj. zajišťuje výměnu zdravotnické dokumentace mezi ZZS PAK, NPK (konkrétně jen Pardubickou nemocnicí) a zdravotnickými zařízeními připojenými na eHealth systém Kraje Vysočina (eMeDocS).

Do tohoto řešení nicméně nejsou zapojeni ostatní poskytovatelé zdravotnických služeb (ZS) na území Pardubického kraje, což pro ZZS PAK a NPK znamená, že nemají k dispozici všechny informace o pacientech od poskytovatelů na území Pardubického kraje a ZZS PAK nemůže zasílat výjezdové zprávy jiným poskytovatelům ZS na svém spádovém území (Pardubický kraj), případně na území bezprostředně souvisejících krajů, kdy dochází k poskytování zdravotní péče i mimo region.

Z uvedeného plyne, že není zajištěna celoplošná dostupnost eHealth služeb (výměny zdravotnické dokumentace a dalších služeb) pro poskytovatele ZS na území Pardubického kraje.

Současné řešení bylo orientováno primárně na potřeby ZZS PAK (dáno zaměřením předchozího projektu), nicméně nebylo úplné (chybí informace o dostupnosti lůžkového fondu, vyhodnocení výjezdů ZZS, Avízo o převozu pacienta apod.) a systém není připraven na výměnu dat přímo mezi poskytovateli ZS (Výměna dat mezi zdravotnickými zařízeními).

Dalším problémem je, že KKC ZZS PAK je umístěno v DC ZZS PAK, což znamená, že další poskytovatelé jsou a museli být připojeni prostřednictvím sítě internet nebo nepřímo do krajské sítě (krajská komunikační infrastruktura) a následně teprve ke KKC. Tento problém sice umožňuje připojení nových poskytovatelů ZS, ale neumožňuje efektivně využít existující krajské komunikační infrastruktury, tj. především garantované funkčnosti a vysoké dostupnosti infrastruktury jako základního předpokladu zajištění garantované funkčnosti a vysoké dostupnosti systému eHealth.

Současný systém dále neumožňuje pacientům získat z jednoho místa o nich vedené zdravotní informace ze zdravotnické dokumentace všech poskytovatelů ZS na území Pardubického kraje, případně jiných krajů.

6.2 Další systémy výměny zdravotnické dokumentace

6.2.1 eHealth systémy okolních krajů

V následující tabulce je uveden výčet eHealth systémů okolních krajů a stav jejich připravenosti:

Kraj	Stav a připravenost eHealth systému
Kraj Vysočina	Kraj Vysočina provozuje eHealth systém eMeDocS. Detailní popis tohoto systému a propojení eHealth PAK a tohoto systému je uvedeno v následující kapitole.
Středočeský kraj	Středočeský kraj disponuje vlastním eHealth systémem, který je od stejného výrobce jako eHealth PAK, tj. systémy jsou kompatibilní a propojitelné, nicméně nyní nejsou propojeny a bude třeba propojení zajistit.
Jihomoravský kraj	Jihomoravský kraj (JMK) nedisponuje vlastním eHealth systémem, nicméně připravuje projekt zajištění výměny zdravotnické dokumentace na svém území. Záměrem JMK je využití eMeDocS jako komunikačního centra a poskytovatele ZS připojit na eMeDocS. Z uvedeného plyne, že pokud tak JMK učiní, bude zajištěna výměna zdravotnické dokumentace mezi poskytovateli ZS na území JMK a PAK implicitně v rámci existujícího propojení eHealth PAK a eMeDocS.
Olomoucký kraj	Olomoucký kraj disponuje vlastním eHealth systémem, který je od stejného výrobce jako eHealth PAK, tj. systémy jsou kompatibilní a propojitelné, nicméně nyní nejsou propojeny a bude třeba propojení zajistit.
Královéhradecký kraj	Královéhradecký kraj disponuje vlastním eHealth systémem, který je od jiného výrobce než eHealth PAK, nicméně od stejného výrobce jako

Kraj

Stav a připravenost eHealth systému

eMeDocS, tj. systémy jsou kompatibilní a propojitelné (viz eMeDocS),

nicméně nyní nejsou propojeny a bude třeba propojení zajistit.

Tabulka 21: eHealth systémy okolních krajů

6.2.2 eHealth KV (eMeDocS)

Systém eMeDocS (exchange Medical Documents System) zajišťuje komunikační infrastrukturu pro bezpečnou a důvěryhodnou výměnu zdravotnické dokumentace mezi zdravotnickými zařízeními v rámci zdravotnického systému České republiky. Organizátorem a garantem projektu je Kraj Vysočina.

Současné řešení eHealth PAK je k tomuto systému připojeno pro výměnu zdravotnické dokumentace mezi poskytovateli ZS v rámci Pardubického kraje, Kraje Vysočina a poskytovatelů ZS z jiných krajů připojených na tento systém výměny zdravotnické dokumentace. Připojení bylo realizováno v roce 2015 v projektu „Modernizace a standardizace vybavení Zdravotnické záchranné služby Pardubického kraje“, který byl Zdravotnickou záchrannou službou Pardubického kraje (ZZS PAK) realizován v rámci Integrovaného operačního programu (IOP), výzvy č. 23.

Toto napojení zůstane zachováno z důvodu zajištění udržitelnosti uvedeného projektu a současně zajistí propojení s Krajem Vysočina (sousedícím krajem).

Podrobné informace k eMeDocS jsou k dispozici zde: xxxx://xxx.xxxxxxx.xx

Integrační rozhraní na eMeDocS je k dispozici zde: xxxx://xxx.xxxxxxx.xx/xx-xxxxxxx .

6.2.3 NIX ZD

Již na přelomu let 2014 a 2015 byla na straně Kraje Vysočina zahájena aktivita k vybudování NIX ZD jakožto nadřazeného systému na úrovni České republiky k výměně zdravotnické dokumentace mezi kraji. Nadřazenost neznamená, že má zajišťovat vlastní výměnu ZD, ale má zajistit adresář zapojených poskytovatelů ZS a směrování toků v rámci výměny mezi krajskými eHealth systémy a v nich zapojenými poskytovateli ZS.

Vybudování tohoto systému mělo být realizováno již v roce 2015 a všechny krajské systémy výměny zdravotnické dokumentace (budované v rámci IOP, v. č. 23) měly být na tento systém napojeny. K napojení na NIX ZD nedošlo proto, že NIX ZD nebyl vybudován v termínech realizace projektů v rámci IOP v. č. 23 a nepřipojení na jiný krajský systém výměny zdravotnické dokumentace v termínech uvedených projektů by znamenalo pro žadatele (kraje a ZZS) nesplnění podmínek a ztrátu dotace. Z uvedeného důvodu byly krajské systémy výměny zdravotnické dokumentace napojeny jen na eMeDocS.

Realizace záměru celostátního nadřazeného systému výměny zdravotnické dokumentace (NIX ZD) je řešena v rámci projektu Connecting Europe Facility 2014-2020 společně s národním kontaktním místem eHealth (eH NCP).

Aktuální stav projektu je k dispozici a aktualizován na následující adrese: xxx.xxxxx.xx .

6.2.4 Národní kontaktní místo pro eHealth (eH NCP)

Národní kontaktní místo pro eHealth (eH NCP) pro Českou republiku a zapojení České republiky do celoevropského mechanismu výměny zdravotnické dokumentace (epSOS) pro službu pacientský souhrn (Patient Summary) je řešena v rámci projektu Connecting Europe Facility 2014-2020.

Projektové konsorcium tvoří Kraj Vysočina, Ministerstvo zdravotnictví České republiky, Nemocnice Jihlava a Zdravotnická záchranná služba Kraje Vysočina.

Projekt je nyní v přípravě, do doby realizace budou známy podmínky realizace tohoto projektu a podmínky připojení a budou zapracovány do zadávacích dokumentací.

Aktuální stav projektu je k dispozici a aktualizován na následující adrese: xxx.xxxxx.xx .

6.3 Informace o zapojených subjektech a jejich prostředí a podmínkách

V této kapitole jsou informace o zapojených subjektech a jejich prostředí a podmínkách.

6.3.1 Pardubický kraj

Pardubický kraj je jedním ze 14 územně samosprávných celků České republiky a tvoří jej okresy

Pardubice, Chrudim, Svitavy a Ústí nad Orlicí.

Pardubický kraj na svém území zajišťuje výkon veřejné správy v oblasti zdravotnictví, a to prostřednictvím zakládaných a zřizovaných poskytovatelů zdravotnických služeb v uvedených okresech, tj. zajištuje poskytování veřejné služby v oblasti poskytování zdravotní péče pro občany.

Pardubický kraj je zakladatelem nebo zřizovatelem poskytovatelů zdravotnických služeb, kteří tvoří základnu ambulantní a lůžkové (akutní i následné) zdravotní péče pro celý region. Na svém území Pardubický kraj zajišťuje lékařskou pohotovostní službu. Lidem v přímém ohrožení života zajišťuje pomoc Zdravotnická záchranná služba Pardubického kraje.

6.3.2 Poskytovatelé zdravotních služeb

V této kapitole je uveden přehled poskytovatelů zdravotní péče na území Pardubického kraje a stav jejich připojení k eHealth PAK nebo připravenosti k připojení k eHealth PAK:

Poskytovatel ZS

Stav

Zařízení akutní lůžkové péče

Nemocnice

Pardubického kraje, a.

s. (NPK)

(Pardubická nemocnice, Chrudimská nemocnice, Orlickoústecká nemocnice,

Litomyšlská

Nemocnice Pardubického kraje, a.s. vznikla k 31. prosinci 2014 sloučením pěti nemocnic akutní lůžkové péče, jejichž vlastníkem je Pardubický kraj (seznam nemocnic je uveden v prvním sloupci).

Do současného řešení (viz předchozí kapitola) byla a je zapojena Pardubická nemocnice, kde však v rámci rozšiřování rozsahu poskytovaných informací musí dojít ke změnám.

Ostatní lokality (Ústí nad Orlicí, Litomyšl, Chrudim a Svitavy) zatím nejsou napojeny a musí být napojeny v rámci projektu.

Z uvedeného plyne, že realizací rozvoje existujícího napojení v Pardubicích a doplněním napojení ostatních pracovišť NPK bude zajištěno připojení všech pěti nemocnic akutní lůžkové péče do eHealth PAK.

Poskytovatel ZS	Stav
nemocnice, Svitavská nemocnice)	NPK v současnosti plánuje jednotný NIS pro všech 5 pracovišť, nicméně tento projekt je plánován s realizací do roku 2020, tj. 2 roky po termínu dokončení tohoto projektu. Na základě tohoto není možné zajistit splnění cílů projektu pomocí jednotného NIS a je třeba realizovat samostatná propojení, která mohou být sjednocena v rámci sjednocení NIS NPK v roce 2020. Do doby zajištění jednotného společného NIS NPK bude zajištěno napojení všech nemocnic, resp. jejich NIS, stejným způsobem, jako je v současnosti napojena Pardubická nemocnice, tj. budou dodány do každé nemocnice KU a bude provedena integrace s jejich NIS. Poskytovatel ZS je napojen na krajskou komunikační infrastrukturu.
Zdravotnická záchranná služba
Zdravotnická záchranná služba Pardubického kraje (ZZS PAK)	IS ZZS PAK jsou převážně připraveny – již napojeny na eHealth PAK. Jedinými změnami jsou zajištění nových funkcionalit „Avízo o převozu pacienta“, „Dodatečné zjišťování totožnosti pacienta (číslo pojištěnce) po předání do ZZ“ a „Zjišťování registrujícího lékaře pacienta v registru VZP“, které vyžadují změnu zdrojového IS na straně ZZS PAK. Nové funkcionality relevantní pro ZZS „Sdílení informací o dostupnosti volných lůžek pro urgentní příjem“ a „Vyhodnocení výjezdů ZZS“ by měly být řešeny bez dopadu na IS ZZS. Přidání nových poskytovatelů ZS do eHealth PAK nevyžaduje žádné změny na straně tohoto IS a informace budou k dispozici ze všech zapojených IS. Výjezdové zprávy ZZS se nebudou předávat poskytovatelům následné péče, protože ZZS pacienty v rámci výjezdu nevozí do těchto zařízení, vozí je jen do zařízení poskytující akutní lůžkovou péči. Vzhledem k předpokládanému přesunu komunikačního centra do NPK (lokalita Pardubice) bude třeba provést přenastavení propojení IS ZZS na eHealth PAK a ověřit funkčnost. Poskytovatel ZS je napojen na krajskou komunikační infrastrukturu.
Zařízení následné péče
Léčebna dlouhodobě nemocných Rybitví (LDN Rybitví)	IS provozovaný poskytovatelem ZS v instalované verzi a konfiguraci neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu. Předpokládá se modernizace NIS v letech 2018 a 2019. V rámci modernizace NIS budou zajištěny všechny existující, případně nově požadované funkcionality.

Poskytovatel ZS	Stav
	Připojení do krajské komunikační infrastruktury není zřízeno, komunikace bude probíhat přes internet nebo bude nutné zřídit připojení do krajské komunikační infrastruktury.
Odborný léčebný ústav Jevíčko (OLU Jevíčko)	IS provozovaný poskytovatelem ZS v instalované verzi a konfiguraci neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu. Připojení do krajské komunikační infrastruktury není zřízeno, komunikace bude probíhat přes internet nebo bude nutné zřídit připojení do krajské komunikační infrastruktury.
Albertinum, odborný léčebný ústav Žamberk (OLÚ Albertinum Žamberk)	IS provozovaný poskytovatelem ZS v instalované verzi a konfiguraci neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu. Připojení do krajské komunikační infrastruktury není zřízeno, komunikace bude probíhat přes internet nebo bude nutné zřídit připojení do krajské komunikační infrastruktury.
Nemocnice následné péče Moravská Třebová (NNP Moravská Třebová)	IS provozovaný poskytovatelem ZS v instalované verzi a konfiguraci neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu. Připojení do krajské komunikační infrastruktury není zřízeno, komunikace bude probíhat přes internet nebo bude nutné zřídit připojení do krajské komunikační infrastruktury.
Vysokomýtská nemocnice (NVM)	IS provozovaný poskytovatelem ZS v instalované verzi a konfiguraci neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu. Připojení do krajské komunikační infrastruktury není zřízeno, komunikace bude probíhat přes internet nebo bude nutné zřídit připojení do krajské komunikační infrastruktury.
Rehabilitační ústav Brandýs nad Orlicí (RÚ BnO)	IS provozovaný poskytovatelem ZS v instalované verzi a konfiguraci neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu. Připojení do krajské komunikační infrastruktury není zřízeno, komunikace bude probíhat přes internet nebo bude nutné zřídit připojení do krajské komunikační infrastruktury.

Tabulka 22: Poskytovatelé ZS

Do projektu tedy budou zapojena všechna zdravotnická zařízení Pardubického kraje, tj. tímto bude zajištěno celoplošné pokrytí Pardubického kraje systémem eHealth.

Dále jsou uvedeny nezbytné údaje k výchozímu stavu poskytovatelů ZS, kteří budou nově připojeni

v rámci projektu.

6.3.2.1 Nemocnice Pardubického kraje, a. s. (NPK)

Nemocnice Pardubického kraje, a. s. (NPK) realizuje projekt „Jednotný klinický informační systém NPK“ v rámci IROP, výzvy č. 26. Předmětem projektu NPK je zavedení jednotného klinického informačního systému (KIS) pro všech pět (5) lokalit/nemocnic NPK do roku 2020.

V následujícím textu je uveden současný/výchozí stav pro tento projektu, který se však během udržitelnosti tohoto projektu změní na straně NPK. Z tohoto důvodu jsou požadavky uvedené dříve v tomto dokumentu definovány tak, aby systém byl na tuto změnu připraven a nedošlo k maření investice ani zbytečným nákladům na realizaci projektu.

Současný stav IS v rámci NPK:

Lokalita	IS / dodavatel	Stav
Pardubice	FONS Enterprise, NIS Medea STAPRO s. r. o.	V této lokalitě jsou uvedené IS připojeny k eHealth PAK pro následující funkcionality: 1. Vyhledání životních údajů pacienta. 2. Předání výjezdové zprávy ZZS do nemocnic. 3. Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS. Uvedené funkcionality jsou funkční. IS nejsou nyní připraveny poskytovat následující funkcionality: 4. Sdílení informací o dostupnosti lůžek pro urgentní příjem. 5. Avízo o převozu pacienta. 6. Výměna dat mezi zdravotnickými zařízeními. 7. Vyhodnocení výjezdů ZZS. 8. Dodatečné zjišťování totožnosti pacienta (č. p.) po předání do ZZ. 9. Zjišťování registrujícího lékaře pacienta v registru VZP. 10. Přístup k Portálu pacienta z NIS pro ošetřující lékaře. Uvedené funkcionality je třeba do IS doplnit v rámci projektu.
Chrudim	WinMedicalc Medicalc software s.r.o.	IS provozovaný na tomto pracovišti obsahuje data relevantní pro tento projekt, ale neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu.
Ústí nad Orlicí	NIS Medea STAPRO s. r. o.	IS provozovaný na tomto pracovišti obsahuje data relevantní pro tento projekt, ale neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu.

Lokalita

IS / dodavatel

Stav

Litomyšl

AMIS H ICZ a.s.

IS provozovaný na tomto pracovišti obsahuje data relevantní pro tento projekt, ale neumožňuje realizovat nové funkcionality bez úprav tohoto IS. Úpravy IS poskytovatele ZS jsou nezbytné pro zajištění nových funkcionalit a jsou součástí projektu.

Svitavy

CGM CLINICOM

CompuGroup Medical Česká republika s.r.o.

Tabulka 23: Současný stav IS v rámci NPK

V následující tabulce jsou uvedeny další podmínky k připravenosti tohoto poskytovatele ZS:

Oblast	Stav
Možnost umístění části technologie do DC	Část technologie je již umístěna v datovém centru v lokalitě Pardubice. V případě potřeby lze do datového centra umístit i rozšíření technologie. V případě projektu se jedná o přesun stávajícího komunikačního centra eHealth do lokality Pardubice ze ZZS PAK a rozšíření funkcionalit tohoto centra v této lokalitě. Přesun komunikačního centra nebude mít vliv na stávající funkcionalitu v NPK, dopady budou na straně ZZS PAK. NPK zajistí ve svém datovém centru provoz komunikačního centra eHealth PAK. HW infrastruktura je požadována v rackovém provedení.
Připojení do krajské komunikační infrastruktury	Všechna pracoviště NPK (5 pracovišť) jsou připojena na krajskou komunikační infrastrukturu (RDS), tj. komunikace bude probíhat přes tuto komunikační infrastrukturu.
Možnost připojení k umístěné technologii	Poskytovatel ZS již nyní umožňuje vzdálený přístup k umístěné technologii pro dohled a správu umístěné technologie.
Stabilita IS do konce udržitelnosti	Jako důsledek sloučení 5 nemocnic do NPK budou sloučeny i jednotlivé IS do jednotného NIS (do roku 2020). V rámci sloučení bude zajištěno zachování funkcionalit tohoto projektu. Nad rámec sloučení se nepředpokládá další výměna IS do konce udržitelnosti projektu. V rámci doby udržitelnosti budou probíhat jen rozvojové úlohy a nezbytné legislativní a technické úpravy při zachování existující funkcionality.

Tabulka 24: Stav připravenosti – NPK

Protože provoz modernizovaného řešení bude zajišťovat NPK, jsou důležité technologie využívané

ze strany NPK, s nimiž musí být dodávky kompatibilní, případně se k nim mají propojit. Jedná se

o následující technologie:

Oblast	Stav
Přístup do datové sítě NPK	Připojení ke krajské komunikační síti (RDS) a k internetu je zabezpečeno HW firewally Fortinet. Připojení jiných částí eHealth PAK k technologii v DC NPK je možné jen prostřednictvím technologie IPSec.
Operační systémy	Windows Server 2016 Datacenter
Virtualizace	VMware vSphere Enterprise plus
Zálohování	Veeam Availibility Suite Enteprise

Tabulka 25: Technologie – NPK

6.3.2.2 Zdravotnická záchranná služba Pardubického kraje (ZZS PAK)

ZZS PAK je nositelem stávajícího řešení eHealth PAK. V následující tabulce je uveden stav připravenosti

tohoto poskytovatele ZS pro zapojení do projektu eHealth PAK:

Oblast	Stav
Vyhledání životních údajů pacienta
Relevantní:	Ano
Cílový informační systém (IS)	IS pro mobilní zadávání dat (MZD) YOUR SYSTEM, spol. s r.o.
Připravenost cílového IS	IS MZD je připojen k eHealth PAK a vyhledání životních údajů pacienta je plně funkční. Přidání nových poskytovatelů ZS do eHealth PAK nevyžaduje žádné změny na straně tohoto IS a informace budou k dispozici ze všech zapojených IS. IS je připravený.
Podmínky zajištění připravenosti cílového IS	Vzhledem k předpokládanému přesunu komunikačního centra do NPK (lokalita Pardubice) bude třeba provést přenastavení propojení IS MZD a eHealth PAK a ověřit funkčnost.
Předání výjezdové zprávy ZZS do nemocnic
Relevantní:	Ano
Zdrojový informační systém (IS)	IS pro mobilní zadávání dat (MZD) YOUR SYSTEM, spol. s r.o.

Oblast	Stav
Připravenost zdrojového IS	IS MZD je připojen k eHealth PAK a předává výjezdové zprávy ZZS do nemocnic, poskytovatelům akutní lůžkové péče, prostřednictvím připojení do NPK (lokalita Pardubice), tj. je plně funkční. NPK zajistí zpracování přijatých dat pro všechna pracoviště (5 pracovišť) prostřednictvím předání v lokalitě Pardubice. Z uvedeného plyne, že pro předávání VZ do nemocnic nebudou žádné funkční úpravy a IS je tedy připraven i nadále předávat VZ ZZS do nemocnic. Výjezdové zprávy ZZS se nebudou předávat poskytovatelům následné péče, protože ZZS pacienty v rámci výjezdu nevozí do těchto zařízení, vozí je jen do zařízení poskytující akutní lůžkovou péči. IS je připravený.
Podmínky zajištění připravenosti zdrojového IS	Vzhledem k předpokládanému přesunu komunikačního centra do NPK (lokalita Pardubice) bude třeba provést přenastavení propojení IS MZD a eHealth PAK a ověřit funkčnost.
Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS
Relevantní:	Ano
Cílový informační systém (IS)	IS pro mobilní zadávání dat (MZD) YOUR SYSTEM, spol. s r.o.
Připravenost cílového IS	IS MZD je připojen k eHealth PAK a náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS je plně funkční. Přidání nových poskytovatelů ZS do eHealth PAK nevyžaduje žádné změny na straně tohoto IS a informace budou k dispozici ze všech zapojených IS. IS je připravený.
Podmínky zajištění připravenosti cílového IS	Vzhledem k předpokládanému přesunu komunikačního centra do NPK (lokalita Pardubice) bude třeba provést přenastavení propojení IS MZD a eHealth PAK a ověřit funkčnost.
Sdílení informací o dostupnosti lůžek pro urgentní příjem
Relevantní:	Ano
Cílový informační systém (IS)	Není
Připravenost cílového IS	Netřeba, nebude integrováno do žádného IS, bude poskytováno jako stránka webové aplikace eHealth PAK dostupná na operačním středisku ZZS, prostřednictvím které budou dostupné požadované informace.

Oblast	Stav
Podmínky zajištění připravenosti cílového IS	Zajistit nastavení infrastruktury tak, aby stránka webové aplikace byla funkční na operačním středisku ZZS.
Avízo o převozu pacienta
Relevantní:	Ano
Zdrojový informační systém (IS)	IS pro mobilní zadávání dat (MZD) / YOUR SYSTEM, spol. s r.o.
Připravenost zdrojového IS	Zdrojový IS není připraven pro předávání avíza o převozu pacienta poskytovatelům akutní lůžkové péče. IS vyžaduje úpravy tak, aby byl schopen tyto údaje předávat poskytovatelům akutní lůžkové péče.
Podmínky zajištění připravenosti zdrojového IS	Zajistit nákup úprav zdrojového IS, cenové podmínky jsou uvedeny v rozpočtu projektu.
Výměna dat mezi zdravotnickými zařízeními
Relevantní	Ne (netýká se ZZS)
Vyhodnocení výjezdů ZZS
Relevantní:	Ano
Cílový informační systém (IS)	Není
Připravenost cílového IS	Netřeba, nebude integrováno do žádného IS, bude poskytováno jako stránka webové aplikace eHealth PAK dostupná pro uživatele v rámci sítě ZZS, prostřednictvím které budou dostupné požadované informace.
Podmínky zajištění připravenosti cílového IS	Zajistit nastavení infrastruktury tak, aby stránka webové aplikace byla funkční v síti ZZS.
Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ
Relevantní:	Ano
Cílový informační systém (IS)	Není
Připravenost cílového IS	Netřeba, nebude integrováno do žádného IS, bude poskytováno jako stránka webové aplikace eHealth PAK dostupná na operačním středisku ZZS, prostřednictvím které budou dostupné požadované informace.

Oblast	Stav
Podmínky zajištění připravenosti cílového IS	Zajistit nastavení infrastruktury tak, aby stránka webové aplikace byla funkční na operačním středisku ZZS.
Zjišťování registrujícího lékaře pacienta v registru VZP
Relevantní	Ano
Cílový informační systém (IS)	Není
Připravenost cílového IS	Netřeba, nebude integrováno do žádného IS, bude poskytováno jako stránka webové aplikace eHealth PAK dostupná na operačním středisku ZZS, prostřednictvím které budou dostupné požadované informace.
Podmínky zajištění připravenosti cílového IS	Zajistit nastavení infrastruktury tak, aby stránka webové aplikace byla funkční na operačním středisku ZZS.
Společné
Možnost umístění části technologie do DC	Část technologie je již umístěna v datovém centru ZZS. V případě projektu se jedná o přesun stávajícího komunikační centra eHealth ze ZZS PAK do NPK v lokalitě Pardubice – dochází k uvolnění částí zdrojů v datovém centru, nicméně bude třeba zajistit fyzické oddělení KKC a KU v rámci virtuální infrastruktury. Přesun komunikačního centra nebude mít vliv na stávající funkcionalitu. HW infrastruktura je požadována v rackovém provedení.
Připojení do krajské komunikační infrastruktury	ZZS PAK je připojena na krajskou komunikační infrastrukturu, tj. komunikace bude probíhat přes tuto komunikační infrastrukturu.
Možnost připojení k umístěné technologii	Poskytovatel ZS již nyní umožňuje vzdálený přístup k umístěné technologii pro dohled a správu umístěné technologie.
Stabilita IS do konce udržitelnosti	Nepředpokládá se výměna zdrojových/cílových IS do konce udržitelnosti projektu. V rámci doby udržitelnosti budou probíhat jen rozvojové úlohy a nezbytné legislativní a technické úpravy při zachování existující funkcionality.

Tabulka 26: Stav připravenosti – Zdravotnická záchranná služba Pardubického kraje

6.3.2.3 Léčebna dlouhodobě nemocných Rybitví (LDN Rybitví)

V následující tabulce je uveden stav připravenosti tohoto poskytovatele ZS pro zapojení do projektu

eHealth PAK:

Oblast	Stav
Vyhledání životních údajů pacienta
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Předání výjezdové zprávy ZZS do nemocnic
Relevantní	Ne (jedná se o zařízení následné péče)
Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušní konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.

Oblast	Stav
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Sdílení informací o dostupnosti lůžek pro urgentní příjem
Relevantní	Ne (jedná se o zařízení následné péče)
Avízo o převozu pacienta
Relevantní	Ne (jedná se o zařízení následné péče)
Výměna dat mezi zdravotnickými zařízeními
Relevantní:	Ano
Zdrojový/cílový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového/cílového IS poskytovat/čerpat data.	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového/cílového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Vyhodnocení výjezdů ZZS
Relevantní	Ne (jedná se o zařízení následné péče)
Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ
Relevantní	Ne (jedná se o zařízení následné péče)
Zjišťování registrujícího lékaře pacienta v registru VZP
Relevantní	Ne (jedná se o zařízení následné péče)

Oblast	Stav
Společné
Možnost umístění části technologie do DC	Ano, část technologie projektu lze umístit do datového centra poskytovatele ZS. HW infrastruktura je požadována v rackovém provedení.
Připojení do krajské komunikační infrastruktury	Není zřízeno, komunikace bude probíhat přes internet.
Možnost připojení k umístěné technologii	Poskytovatel ZS umožní vzdálený přístup k umístěné technologii pro dohled a správu umístěné technologie.
Stabilita IS do konce udržitelnosti	Předpokládá se modernizace NIS v letech 2018 a 2019. V rámci modernizace NIS budou zajištěny všechny existující, případně nově požadované funkcionality. Následně budou v rámci doby udržitelnosti probíhat jen rozvojové úlohy a nezbytné legislativní a technické úpravy při zachování existující funkcionality.

Tabulka 27: Stav připravenosti – Léčebna dlouhodobě nemocných Rybitví

6.3.2.4 Odborný léčebný ústav Jevíčko (OLU Jevíčko)

V následující tabulce je uveden stav připravenosti tohoto poskytovatele ZS pro zapojení do projektu

eHealth PAK:

Oblast	Stav
Vyhledání životních údajů pacienta
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Akord Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Akord provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.

Oblast	Stav
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Předání výjezdové zprávy ZZS do nemocnic
Relevantní	Ne (jedná se o zařízení následné péče)
Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Akord Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Akord provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Sdílení informací o dostupnosti lůžek pro urgentní příjem
Relevantní	Ne (jedná se o zařízení následné péče)
Avízo o převozu pacienta
Relevantní	Ne (jedná se o zařízení následné péče)
Výměna dat mezi zdravotnickými zařízeními
Relevantní:	Ano
Zdrojový/cílový informační systém (IS)	FONS Akord Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.

Oblast	Stav
Připravenost zdrojového/cílového IS poskytovat/čerpat data.	IS FONS Akord provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového/cílového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Vyhodnocení výjezdů ZZS
Relevantní	Ne (jedná se o zařízení následné péče)
Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ
Relevantní	Ne (jedná se o zařízení následné péče)
Zjišťování registrujícího lékaře pacienta v registru VZP
Relevantní	Ne (jedná se o zařízení následné péče)
Společné
Možnost umístění části technologie do DC	Ano, část technologie projektu lze umístit do datového centra poskytovatele ZS. HW infrastruktura je požadována v rackovém provedení.
Připojení do krajské komunikační infrastruktury	Není zřízeno, komunikace bude probíhat přes internet.
Možnost připojení k umístěné technologii	Poskytovatel ZS umožní vzdálený přístup k umístěné technologii pro dohled a správu umístěné technologie.
Stabilita IS do konce udržitelnosti	Nepředpokládá se výměna zdrojových/cílových IS do konce udržitelnosti projektu. V rámci doby udržitelnosti budou probíhat jen rozvojové úlohy a nezbytné legislativní a technické úpravy při zachování existující funkcionality.

Tabulka 28: Stav připravenosti – Odborný léčebný ústav Jevíčko

6.3.2.5 Albertinum, odborný léčebný ústav Žamberk (OLÚ Albertinum Žamberk)

V následující tabulce je uveden stav připravenosti tohoto poskytovatele ZS pro zapojení do projektu

eHealth PAK:

Oblast	Stav
Vyhledání životních údajů pacienta
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Předání výjezdové zprávy ZZS do nemocnic
Relevantní	Ne (jedná se o zařízení následné péče)
Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.

Oblast	Stav
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Sdílení informací o dostupnosti lůžek pro urgentní příjem
Relevantní	Ne (jedná se o zařízení následné péče)
Avízo o převozu pacienta
Relevantní	Ne (jedná se o zařízení následné péče)
Výměna dat mezi zdravotnickými zařízeními
Relevantní:	Ano
Zdrojový/cílový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového/cílového IS poskytovat/čerpat data.	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového/cílového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Vyhodnocení výjezdů ZZS
Relevantní	Ne (jedná se o zařízení následné péče)
Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ
Relevantní	Ne (jedná se o zařízení následné péče)
Zjišťování registrujícího lékaře pacienta v registru VZP
Relevantní	Ne (jedná se o zařízení následné péče)

Oblast	Stav
Společné
Možnost umístění části technologie do DC	Ano, část technologie projektu lze umístit do datového centra poskytovatele ZS. HW infrastruktura je požadována v rackovém provedení.
Připojení do krajské komunikační infrastruktury	Není zřízeno, komunikace bude probíhat přes internet.
Možnost připojení k umístěné technologii	Poskytovatel ZS umožní vzdálený přístup k umístěné technologii pro dohled a správu umístěné technologie.
Stabilita IS do konce udržitelnosti	Systém byl modernizován v nedávné době, tj. předpokládá se, že bude stabilní na delší časové období. Nepředpokládá se výměna zdrojových/cílových IS do konce udržitelnosti projektu. V rámci doby udržitelnosti budou probíhat jen rozvojové úlohy a nezbytné legislativní a technické úpravy při zachování existující funkcionality.

Tabulka 29: Stav připravenosti – Albertinum, odborný léčebný ústav Žamberk

6.3.2.6 Nemocnice následné péče Moravská Třebová (NNP Moravská Třebová)

V následující tabulce je uveden stav připravenosti tohoto poskytovatele ZS pro zapojení do projektu

eHealth PAK:

Oblast	Stav
Vyhledání životních údajů pacienta
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.

Oblast	Stav
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Předání výjezdové zprávy ZZS do nemocnic
Relevantní	Ne (jedná se o zařízení následné péče)
Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Sdílení informací o dostupnosti lůžek pro urgentní příjem
Relevantní	Ne (jedná se o zařízení následné péče)
Avízo o převozu pacienta
Relevantní	Ne (jedná se o zařízení následné péče)
Výměna dat mezi zdravotnickými zařízeními
Relevantní:	Ano
Zdrojový/cílový informační systém (IS)	FONS Enterprise Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.

Oblast	Stav
Připravenost zdrojového/cílového IS poskytovat/čerpat data.	IS FONS Enterprise provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového/cílového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Vyhodnocení výjezdů ZZS
Relevantní	Ne (jedná se o zařízení následné péče)
Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ
Relevantní	Ne (jedná se o zařízení následné péče)
Zjišťování registrujícího lékaře pacienta v registru VZP
Relevantní	Ne (jedná se o zařízení následné péče)
Společné
Možnost umístění části technologie do DC	Ano, část technologie projektu lze umístit do datového centra poskytovatele ZS. HW infrastruktura je požadována v rackovém provedení.
Připojení do krajské komunikační infrastruktury	Není zřízeno, komunikace bude probíhat přes internet.
Možnost připojení k umístěné technologii	Poskytovatel ZS umožní vzdálený přístup k umístěné technologii pro dohled a správu umístěné technologie.
Stabilita IS do konce udržitelnosti	Nepředpokládá se výměna zdrojových/cílových IS do konce udržitelnosti projektu. V rámci doby udržitelnosti budou probíhat jen rozvojové úlohy a nezbytné legislativní a technické úpravy při zachování existující funkcionality.

Tabulka 30: Stav připravenosti – Nemocnice následné péče Moravská Třebová

6.3.2.7 Vysokomýtská nemocnice (NVM)

V následující tabulce je uveden stav připravenosti tohoto poskytovatele ZS pro zapojení do projektu

eHealth PAK:

Oblast	Stav
Vyhledání životních údajů pacienta
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Akord Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Akord provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Předání výjezdové zprávy ZZS do nemocnic
Relevantní	Ne (jedná se o zařízení následné péče)
Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS
Relevantní:	Ano
Zdrojový informační systém (IS)	FONS Akord Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového IS	IS FONS Akord provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.

Oblast	Stav
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Sdílení informací o dostupnosti lůžek pro urgentní příjem
Relevantní	Ne (jedná se o zařízení následné péče)
Avízo o převozu pacienta
Relevantní	Ne (jedná se o zařízení následné péče)
Výměna dat mezi zdravotnickými zařízeními
Relevantní:	Ano
Zdrojový/cílový informační systém (IS)	FONS Akord Výrobcem a dodavatelem IS je společnost STAPRO s. r. o.
Připravenost zdrojového/cílového IS poskytovat/čerpat data.	IS FONS Akord provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nabízí dodání modulu/funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale tento modul/funkcionalita nejsou nyní dodány a provozovány v instalované verzi IS u tohoto poskytovatele ZS.
Podmínky zajištění připravenosti zdrojového/cílového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit modul/funkcionalitu pro výměnu elektronické zdravotnické dokumentace do IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Vyhodnocení výjezdů ZZS
Relevantní	Ne (jedná se o zařízení následné péče)
Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ
Relevantní	Ne (jedná se o zařízení následné péče)
Zjišťování registrujícího lékaře pacienta v registru VZP
Relevantní	Ne (jedná se o zařízení následné péče)

Oblast	Stav
Společné
Možnost umístění části technologie do DC	Ano, část technologie projektu lze umístit do datového centra poskytovatele ZS. HW infrastruktura je požadována v rackovém provedení.
Připojení do krajské komunikační infrastruktury	Není zřízeno, komunikace bude probíhat přes internet.
Možnost připojení k umístěné technologii	Poskytovatel ZS umožní vzdálený přístup k umístěné technologii pro dohled a správu umístěné technologie.
Stabilita IS do konce udržitelnosti	Nepředpokládá se výměna zdrojových/cílových IS do konce udržitelnosti projektu. V rámci doby udržitelnosti budou probíhat jen rozvojové úlohy a nezbytné legislativní a technické úpravy při zachování existující funkcionality.

Tabulka 31: Stav připravenosti – Vysokomýtská nemocnice

6.3.2.8 Rehabilitační ústav Brandýs nad Orlicí (RÚ BnO)

V následující tabulce je uveden stav připravenosti tohoto poskytovatele ZS pro zapojení do projektu

eHealth PAK:

Oblast	Stav
Vyhledání životních údajů pacienta
Relevantní:	Ano
Zdrojový informační systém (IS)	IS L-BIS Výrobcem a dodavatelem IS ke společnost LAURYN v.o.s.
Připravenost zdrojového IS	IS provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nenabízí funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale je připraven do IS tuto integraci doplnit na míru, dle konkrétních požadavků. Dodavatel doporučuje pro výměnu využít existující standardy, konkrétně mezinárodní standard HL7.
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit funkcionalitu pro výměnu elektronické zdravotnické dokumentace do provozovaného IS.

Oblast	Stav
	Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Předání výjezdové zprávy ZZS do nemocnic
Relevantní	Ne (jedná se o zařízení následné péče)
Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS
Relevantní:	Ano
Zdrojový informační systém (IS)	IS L-BIS Výrobcem a dodavatelem IS ke společnost LAURYN v.o.s.
Připravenost zdrojového IS	IS provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nenabízí funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale je připraven do IS tuto integraci doplnit na míru, dle konkrétních požadavků. Dodavatel doporučuje pro výměnu využít existující standardy, konkrétně mezinárodní standard HL7.
Podmínky zajištění připravenosti zdrojového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit funkcionalitu pro výměnu elektronické zdravotnické dokumentace do provozovaného IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Sdílení informací o dostupnosti lůžek pro urgentní příjem
Relevantní	Ne (jedná se o zařízení následné péče)
Avízo o převozu pacienta
Relevantní	Ne (jedná se o zařízení následné péče)
Výměna dat mezi zdravotnickými zařízeními
Relevantní:	Ano
Zdrojový/cílový informační systém (IS)	IS L-BIS Výrobcem a dodavatelem IS ke společnost LAURYN v.o.s.
Připravenost zdrojového/cílového IS	IS provozovaný poskytovatelem ZS v instalované verzi obsahuje všechna relevantní data, nicméně stávající konfigurace systému neumožňuje

Oblast	Stav
poskytovat/čerpat data.	externí vyhledávání životních údajů pacienta a poskytování do systému eHealth, protože nejsou zakoupeny příslušné konektory. Dodavatel tohoto IS nenabízí funkcionality pro výměnu elektronické zdravotnické dokumentace s jinými poskytovateli ZS, ale je připraven do IS tuto integraci doplnit na míru, dle konkrétních požadavků. Dodavatel doporučuje pro výměnu využít existující standardy, konkrétně mezinárodní standard HL7.
Podmínky zajištění připravenosti zdrojového/cílového IS	Pro zajištění této funkcionality IS je nezbytné zakoupit funkcionalitu pro výměnu elektronické zdravotnické dokumentace do provozovaného IS. Součástí rozpočtu projektu jsou i náklady na rozšíření IS pro zajištění výměny elektronické zdravotnické dokumentace nezbytné pro dosažení cílů projektu.
Vyhodnocení výjezdů ZZS
Relevantní	Ne (jedná se o zařízení následné péče)
Dodatečné zjišťování totožnosti pacienta (čísla pojištěnce) po předání do ZZ
Relevantní	Ne (jedná se o zařízení následné péče)
Zjišťování registrujícího lékaře pacienta v registru VZP
Relevantní	Ne (jedná se o zařízení následné péče)
Společné
Možnost umístění části technologie do DC	Ano, část technologie projektu lze umístit do datového centra poskytovatele ZS. HW infrastruktura je požadována v rackovém provedení.
Připojení do krajské komunikační infrastruktury	Není zřízeno, komunikace bude probíhat přes internet.
Možnost připojení k umístěné technologii	Poskytovatel ZS umožní vzdálený přístup k umístěné technologii pro dohled a správu umístěné technologie.
Stabilita IS do konce udržitelnosti	Nepředpokládá se výměna zdrojových/cílových IS do konce udržitelnosti projektu. Bude proveden upgrade IS L-BIS, v rámci kterého budou zajištěny požadované funkce. Dále budou v rámci doby udržitelnosti probíhat jen rozvojové úlohy a nezbytné legislativní a technické úpravy při zachování existující funkcionality.

Tabulka 32: Stav připravenosti – Rehabilitační ústav Brandýs nad Orlicí

6.4 Legislativa

Na požadované řešení a provoz objednatele a poskytovatelů ZS se vztahuje legislativa uvedená v této

kapitole.

Řešení musí být v souladu s platnou legislativou ke dni uvedení modernizovaného IS do provozu.

6.4.1 Ochrana osobních údajů

1. Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých dalších zákonů, ve znění pozdějších předpisů

2. Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů)

6.4.2 Legislativa specifická pro zdravotnická zařízení

3. Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, ve znění pozdějších předpisů

4. Vyhláška č. 62/2015 Sb., o provedení některých ustanovení zákona o zdravotnických prostředcích, v platném znění

5. Zákon č. 48/1997 Sb., o veřejném zdravotním pojištění, v platném znění

6. Vyhláška č. 98/2012 Sb., o zdravotnické dokumentaci, v platném znění

7. Zákon č. 268/2014 Sb., o zdravotnických prostředcích, v platném znění

6.4.3 Bezpečnost informací

8. Zákon č. 181/2014 Sb., o kybernetické bezpečnosti, v platném znění

9. Vyhláška č. 316/2014 SB., o kybernetické bezpečnosti, v platném znění

6.4.4 Ostatní

10. Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce

11. Zákon č. 499/2008Sb., o archivnictví a spisové službě, v platném znění

6.4.5 Připravovaná legislativa (pouze informativně)

1. Legislativa specifická pro zdravotnická zařízení

a. Návrh zákona, kterým se mění zákon č. 96/2004 Sb., o podmínkách získávání a uznávání způsobilosti k výkonu nelékařských zdravotnických povolání a k výkonu činností souvisejících s poskytováním zdravotní péče a o změně některých souvisejících zákonů (zákon o nelékařských zdravotnických povoláních, ve znění pozdějších předpisů

b. Návrh zákona, kterým se mění zákon č. 373/2011 Sb., o specifických zdravotních službách, ve znění pozdějších předpisů

c. Návrh zákona, kterým se mění zákon č. 592/1992 Sb., o pojistném na veřejné zdravotní pojištění, ve znění pozdějších předpisů (valorizace platby státu za státní pojištěnce)

d. Návrh vyhlášky, kterou se mění vyhláška č. 102/2012 Sb., o hodnocení kvality a bezpečí lůžkové zdravotní péče, ve znění pozdějších předpisů

Poskytovatel ZS	Informace o provozu poskytovatele ZS
Léčebna dlouhodobě nemocných Rybitví (LDN Rybitví)	Výroční zpráva za rok 2013, xxx.xxx-xxxxxxx.xx.
Odborný léčebný ústav Jevíčko (OLU Jevíčko)	Výroční zpráva za rok 2017, xxx.xxxxxxxxxx.xx
Albertinum, odborný léčebný ústav Žamberk (OLÚ Albertinum Žamberk)	Výroční zpráva za rok 2017, www.albertinum- xxx.xx
Nemocnice následné péče Moravská Třebová (NNP Moravská Třebová)	Výroční zpráva za rok 2016, xxx.xxxxxxxxxxxx.xx
Vysokomýtská nemocnice (NVM)	Výroční zpráva 2015, xxx.xxxxxxxxxxx.xx
Rehabilitační ústav Brandýs nad Orlicí (RÚ BnO)	Celková výroční zpráva 2017, xxx.xxxxxxxxxxxxxxxxxx.xx
Pracoviště NPK:	Nemocnice Pardubického kraje, a.s., výroční zpráva za rok 2016 xxx.xxxxx.xx Od 2. pololetí 2014 je vydávána Výroční zpráva za celou společnost Nemocnice Pardubického kraje, a.s.
Pardubická nemocnice
Chrudimská nemocnice
Orlickoústecká nemocnice
Litomyšlská nemocnice
Svitavská nemocnice
Zdravotnická záchranná služba Pardubického kraje (ZZS PAK)	Výroční zpráva 2017, xxx.xxxxxx.xx

Tabulka 33: Množství zpracovávaných dat

Roční nárůst výkonů (ošetřených pacientů, ošetřovacích dnů) apod. je cca v rozsahu 3%-5%.

6.5.2 Uživatelé

Systém musí umožnit využívání následujícími minimální objemy uživatelů:

Poznámka: Jedná se o současně připojené uživatele, nikoliv o registrované.

Poskytovatel ZS	Uživatelé	Správci
Léčebna dlouhodobě nemocných Rybitví (LDN Rybitví)	5	2

Poskytovatel ZS	Uživatelé	Správci
Odborný léčebný ústav Jevíčko (OLU Jevíčko)	5	2
Albertinum, odborný léčebný ústav Žamberk (OLÚ Albertinum Žamberk)	5	2
Nemocnice následné péče Moravská Třebová (NNP Moravská Třebová)	5	2
Vysokomýtská nemocnice (NVM)	5	2
Rehabilitační ústav Brandýs nad Orlicí (RÚ BnO)	5	2
Pracoviště NPK:	5	2
Pardubická nemocnice	10	2
Chrudimská nemocnice	10	2
Orlickoústecká nemocnice	10	2
Litomyšlská nemocnice	10	2
Svitavská nemocnice	10	2
Zdravotnická záchranná služba Pardubického kraje (ZZS PAK)	5	2

Tabulka 34: Uživatelé

V případě rostoucí provozní potřeby musí být možno počet uživatelů navýšit i za cenu rozšíření HW a SW

infrastruktury.

Konec základní části dokumentu

Document Metadata

Table of Contents

Příloha č. 1: Specifikace Díla

Document Metadata