Textová podoba smlouvy - Hlídač státu.

Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud

SERVISNÍ SMLOUVA .SO-
ÚDRŽBA A PODPORA PROVOZU IS

Fakultní nemocnice Hradec Králové

se sídlem Sokolská 5Ř1, Hradec Králové - Nový Hradec Králové, PSČ 500 05
Zastoupená prof. MUDr. Vladimír Palička, CSc., dr. h. c., editel
IČ 00179906
DIČ CZ00179906
bankovní spojení Česká národní banka, č. ú.: 40002-24639511/0710,
(dále jen Objednatel),
na straně jedné,

STAPRO s. r. o.

společnost zapsaná v obchodním rejst íku vedeném Krajským soudem v Hradci Králové, oddíl C vložka 14Ř,

se sídlem Pernštýnské náměstí 51, Staré Město, Pardubice, PSČ 530 02,

zastoupená

IČ 13583531,

DIČ CZ13583531,

DIČ DPH CZ699004728,

bankovní spojení ČSOB Pardubice č.ú.: 271Ř107ř3/0300,

adresa elektronické pošty: stapro@stapro.cz,

(dále jen Dodavatel),

na straně druhé,

dále též Smluvní strana nebo společně Smluvní strany,

uzavírají mezi sebou v souladu s ustanoveními § 25Ř6 a násl. zákona číslo Řř/2012 Sb., občanského zákoníku
(dále jen ObčZ), obchodní smlouvu o dílo (dále jen Smlouva).

lánek I - Prohlášení Smluvních stran

1. Smluvní strany prohlašují, že skutečnosti uvedené v záhlaví této Smlouvy (dále jen Identifikační údaje)
odpovídají aktuálnímu stavu zápisu do obchodního rejst íku a zároveň též aktuálnímu stavu každé Smluvní
strany a zavazují se bez zbytečného odkladu informovat druhou Smluvní stranu o jakékoliv změně
Identifikačního údaje, v opačném p ípadě odpovídají za újmu způsobenou druhé Smluvní straně
neoznámením změny ve sjednané lhůtě. Smluvní strany prohlašují, že osoby jednající za Smluvní strany
jsou osoby oprávněné k jednání bez jakéhokoliv omezení daného nap . i vnit ním p edpisem Smluvní strany.

2. Objednatel bere na vědomí a souhlasí s tím, že adresa elektronické pošty uvedená v Identifikačních údajích
Objednatele anebo firemní adresa elektronické pošty zaměstnanců Objednatele sdělená Objednatelem
Dodavateli bude Dodavatelem užívána za účelem zasílání oznámení a informací o školeních a setkáních
uživatelů a správců informačních systémů Dodavatele a souvisejících informačních technologiích, zejména
spravovaných podle Smlouvy, o jejich změnách, o změnách v legislativě, o nabídkách produktů atp. (dále
jen Obchodní sdělení). Objednatel dává souhlas k zasílání Obchodních sdělení. Tento souhlas může
Objednatel kdykoliv odvolat zprávou zaslanou na adresu elektronické pošty Dodavatele uvedenou v
Identifikačních údajích. Pokud bude povinnost doručit Objednateli jakékoli oznámení anebo informaci
součástí závazku Dodavatele podle této Smlouvy, zavazuje se Objednatel v p ípadě odvolání souhlasu s
používáním elektronické pošty zaplatit náhradu nákladů vynaložených Dodavatelem na zajištění doručení
oznámení anebo informace listovní zásilkou.

3. Dodavatel prohlašuje, že není ve stavu úpadku ve smyslu ustanovení § 3 zákona č. 1Ř2/2006 Sb., tzv.
insolvenčního zákona, v platném znění. Současně Dodavatel prohlašuje, že ke dni uzav ení této smlouvy
není veden v registru nespolehlivých plátců daně z p idané hodnoty a ani mu nejsou známy žádné
skutečnosti, na základě kterých by s ním správce daně mohl zahájit ízení o prohlášení za nespolehlivého
plátce daně dle § 106a zákona č. 235/2004 Sb., o dani z p idané hodnoty, v platném znění.

Servisní smlouva strana 1 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
4. Objednatel prohlašuje, že má dostatečné finanční prost edky nebo p íslib či finanční plán dostatečných
finančních prost edků na úhradu ceny sjednané touto Smlouvou.

5. Smluvní strany mají zájem uzav ít platnou Smlouvu a žádné Smluvní straně není známa žádná skutečnost
bránící jí uzav ít platnou smlouvu a poskytnout sjednaná plnění.

6. Objednatel je ve ejným zadavatelem (dále Zadavatel) ve smyslu ustanovení § 4 zákona č. 134/2016 Sb. o
zadávání ve ejných zakázek, v platném znění (dále jen ZVZ).

7. K uzav ení Smlouvy dochází v důsledku výsledku soutěže o plnění ve ejné zakázky zadáním ve ejné
zakázky ve smyslu ustanovení § 2 ZVZ, a to ve ejné zakázky evidované pod č. Z2019-022009 a vyhlášené
pod názvem: „Modernizace IT FN HK v návaznosti na eHealth“ (dále jen Ve ejná zakázka). Dodavatelova
nabídka byla v zadávacím ízení na plnění Ve ejné zakázky Zadavatelem vyhodnocena jako ekonomicky
nejvýhodnější.

lánek II - Ú el Smlouvy a cíle Smluvních stran

1. Účelem Smlouvy je poskytnutí plnění sjednaných servisních služeb dle zadání ve ejné zakázky a podrobná
úprava a právní vymezení poměru Smluvních stran p i poskytování činností Dodavatele Objednateli pro
vybrané informační technologie a uživatele informačního systému Objednatele. Smluvní strany
p edpokládají dlouhodobost smluvního poměru založeného touto Smlouvou.

2. Společným cílem Smluvních stran je poskytnutí plnění na Ve ejnou zakázku a zajištění níže sjednaných
servisních služeb podpory provozu, funkčnosti a dostupnosti informačních systémů vyjmenovaných v této
Smlouvě.

lánek III - Předmět Smlouvy

1. Dodavatel se zavazuje prost ednictvím svých zaměstnanců a / nebo smluvních partnerů (dále jen
Subdodavatelů) poskytovat Objednateli činnosti (dále jen Služby) spočívající v zajištění a podpo e provozu
informačních systémů Objednatele, resp. v zajištění a podpo e provozu vybraných informačních technologií.

2. Rozsah podpory a popis poskytovaných Služeb je uveden v P íloze č. 1 a č. 2 Smlouvy, nabídce č.
1222_1024 učiněné Dodavatelem Objednateli v soutěži o Ve ejnou zakázku (dále jen Nabídka) a v
zadávacích podmínkách Objednatele jako Zadavatele (dále jen Zadávací dokumentace).

3. Objednatel se zavazuje poskytovat součinnost k plnění podle této Smlouvy, poskytované Služby p ijímat a
platit Dodavateli dále sjednanou cenu ve sjednaných termínech.

4. Smluvní strany sjednávají, že podmínky a parametry poskytování servisní podpory a servisních služeb jsou
definovány zejména v Zadávací dokumentaci Ve ejné zakázky pod názvem „Modernizace IT FN HK v
návaznosti na eHealth“. V p ípadě, že bude jakékoliv ujednání Smlouvy shledáno jako rozdílné, odlišné nebo
v rozporu se Zadávací dokumentací, sjednávají Smluvní strany, že v takovém p ípadě mají podmínky a
parametry definované v Zadávací dokumentaci p ednost p ed ujednáním Smlouvy a současně jsou tyto
podmínky a parametry v Zadávací dokumentaci pro Smluvní strany platné a závazné.

lánek IV - Práva a povinnosti Smluvních stran

1. Dodavatel se zavazuje poskytovat Služby s náležitou odbornou péčí kvalifikovanými a vyškolenými
pracovníky tak, aby dosáhl výsledku sjednaného Smlouvou, v souladu s jemu známými zájmy Objednatele.

2. Dodavatel se zavazuje provádět Služby ve shodě s bezpečnostními požadavky Objednatele, které budou
písemně Dodavateli sděleny a Dodavatelem písemně potvrzeny.

3. Dodavatel i Objednatel se zavazují stanovit za účelem ízení vztahu mezi Objednatelem a Dodavatelem v
oblasti působnosti podle Smlouvy osobu odpovědnou za tento vztah. Jména pracovníků jsou uvedena v
P íloze č. 3 Smlouvy.

4. Dodavatel se zavazuje stanovit osoby odpovědné za plnění závazků dle Smlouvy. Jména těchto osob a jsou
uvedena v P íloze č. 3 Smlouvy. Změna oprávněných osob, p íp. rozsahu jejich oprávnění vyžaduje pouze
jednostranné písemné oznámení zaslané druhé Smluvní straně v souladu s touto Smlouvou, p ičemž tato
změna se stává účinnou okamžikem doručení takového oznámení.

5. Objednatel se zavazuje stanovit odpovědné pracovníky a poskytnout Dodavateli veškerou součinnost,
nezbytné údaje a informace pot ebné k ádnému plnění Smlouvy a umožnit ádné plnění Smlouvy v plném
rozsahu. V době provádění Služeb bude na vyžádání Dodavatele p ítomen na pracovišti Objednatele
odpovědný pracovník Objednatele, v odůvodněných p ípadech i mimo rámec běžné pracovní doby, u
plánovaných akcí po p edchozí dohodě.

6. Objednatel se zavazuje umožnit provádět Službu dle této Smlouvy i mimo běžnou pracovní dobu.

7. Objednatel se zavazuje zajistit pracovníkům Dodavatele:

Servisní smlouva strana 2 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
bezplatný vjezd a parkování v p íslušných objektech Objednatele,

p ístup na p íslušná pracoviště v místech instalace technologií dotčených Smlouvou,

bezpečné, nezávadné a zdraví neohrožující pracovní prost edí.

8. Objednatel se zavazuje p ijmout sjednané plnění Dodavatele, ve sjednaném rozsahu a způsobilé sloužit
svému účelu. Pokud Objednatel ani na základě písemného oznámení termínu p edání plnění toto plnění bez
jakéhokoli odůvodnění nep evezme, má se za to, že plnění bylo p edáno a p evzato dnem, kdy se tak podle
písemného oznámení mělo stát nejpozději dnem, kdy bylo plnění dokončeno a Dodavatel umožnil
Objednateli jeho užití. Písemné oznámení musí být adresováno p íslušné odpovědné osobě, resp. osobě,
která ji v době nep ítomnosti zastupuje, a musí jí být prokazatelně doručeno.

9. Objednatel se zavazuje po dohodě s Dodavatelem zajistit technické prost edky, komponenty (hardwarové,
softwarové) nebo služby, které nejsou p edmětem Smlouvy a jsou nutné pro zajištění provozu a služeb
p edmětu plnění Smlouvy ze strany Objednatele podle této Smlouvy, a to dle svých možností a na základě
zdůvodněných požadavků Dodavatele. Pokud nebudou tyto prost edky zajištěny, neodpovídá Dodavatel za
p ípadné neplnění či omezené plnění poskytovaných služeb a činností.

10. Objednatel se zavazuje dodržovat ustanovení zákona č. 121/2000 Sb., autorského zákona v platném znění.
Objednatel bere na vědomí, že Dodavatel provádí implementaci a poskytuje Služby dle této Smlouvy pouze
v prost edí legálního software, a že za užívání nelegálního software Objednatelem nenese Dodavatel
žádnou odpovědnost.

11. Objednatel se zavazuje, že do aplikačního softwarového vybavení dodaného Dodavatelem nebude provádět
žádné zásahy narušující struktury databáze nebo jeho funkce, včetně napojení jiných systémů na databázi
bez p edchozího písemného souhlasu Dodavatele. V p ípadě porušení takového závazku Dodavatel
negarantuje bezchybný chod aplikace a je oprávněn odstoupit od této Smlouvy.

12. Objednatel je oprávněn provádět datové a konfigurační změny v informačním systému. Pokud tyto změny
budou mít negativní dopad na služby a činnosti zajišťované Dodavatelem, pak Dodavatel neodpovídá za
p ípadné neplnění či omezené plnění poskytovaných služeb a činností. Objednatel se v takovémto p ípadě
zavazuje vyvolat jednání s Dodavatelem k zajištění nápravy.

13. Objednatel se zavazuje umožnit Dodavateli technicky a organizačně vzdálený p ístup k dotčeným
prost edkům informačního systému Objednatele za účelem plnění činností a závazků Dodavatele dle
Smlouvy.

14. Objednatel je povinen oznámit a konzultovat s Dodavatelem z pohledu zajištění plnění Služeb dle Smlouvy
plánované změny v technologickém prost edí Objednatele včetně síťové infrastruktury a jednotlivých serverů
nejpozději 24 hodin p ed provedením těchto změn.

15. Objednatel je povinen zajistit bezproblémový chod síťové infrastruktury, dalších dotčených serverových
technologií včetně procesu zálohování a bezproblémový chod koncových za ízení, zejména pracovních
stanic a tiskáren.

16. Objednatel je povinen v odůvodněných p ípadech umožnit fyzický p ístup pově eným pracovníkům
Dodavatele do prostor, ve kterých Objednatel provozuje technologické za ízení s Produktem a p ípadně i do
dalších prostor, které s provozem technologického za ízení souvisí. Současně je Objednatel povinen
umožnit pracovníkům Dodavatele p ístup do vnit ní sítě Objednatele za účelem kontroly a testování
funkčnosti poskytovaných Služeb. Tuto povinnost musí Objednatel zajistit tak, aby nebránil Dodavateli v
plnění sjednaných lhůt poskytování Služeb dle Smlouvy.

lánek V - Místo, termíny a prokazování plnění

1. Místem plnění Služeb sjednaných dle Smlouvy jsou pracoviště Objednatele.

2. Místem plnění Služeb, které nejsou vázány na pracoviště Objednatele (nap . konzultace, školení, vzdálený
servis), jsou pracoviště Dodavatele, dle výběru Dodavatele, pokud není sjednáno jinak.

3. Dodavatel se zavazuje provádět pro Objednatele sjednané Služby ve sjednaných termínech. Termíny plnění
jsou prodlouženy p i zpožděních způsobených Objednatelem o čas zdržení.

4. Dodavatel se neocitá v prodlení s poskytnutím plnění v p ípadech neposkytnutí pot ebné součinnosti
Objednatelem, ke které se Objednatel v této Smlouvě zavázal, pokud v důsledku porušení této povinnosti
Objednatele nebylo možné službu provést. Za zdržení způsobené Objednatelem je považován i stav, kdy se
bude Objednatel nacházet současně v prodlení s úhradou minimálně t í dluhů (daňových dokladů - faktur).
Objednatel a Dodavatel sjednali, že za tyto včasně neuhrazené dluhy (faktury) nebudou považovány ty
dluhy, jejichž výše, důvod či opodstatněnost se stanou p edmětem jednání mezi Objednatelem a
Dodavatelem (tzn., že se bude jednat o sporné dluhy), pop . ty faktury, které budou z důvodu jejich
nedostatků (formálních či obsahových) Objednatelem Dodavateli vráceny.

5. Termíny plnění a způsoby prokazování plnění jsou sjednány v P íloze č. 1 a 3 Smlouvy.

Servisní smlouva strana 3 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
lánek VI - Cena plnění a platební podmínky

1. Objednatel se zavazuje za poskytnuté Služby dle Smlouvy platit Dodavateli sjednanou roční cenu bez DPH
(Daň z p idané hodnoty) sjednanou v P íloze č. 1 Smlouvy. Takto sjednaná cena je cenou pevnou a
maximální a jsou v ní zahrnuty veškeré náklady Dodavatele na poskytování Služby dle této Smlouvy.

2. Objednatel bere na vědomí, že ke sjednané roční ceně uhradí také DPH ve výši stanovené právním
p edpisem platným k datu uskutečnění zdanitelného plnění, jež je daňovým dokladem účtováno.

3. Cena bude hrazena Objednatelem v měsíčních platbách ve výši jedné dvanáctiny sjednané roční ceny, a to
vždy na základě daňového dokladu Dodavatele. Dodavatel je oprávněn vystavovat daňové doklady vždy k
poslednímu dni kalendá ního měsíce, v němž je Služba poskytnuta.

4. Splatnost každého daňového dokladu vystaveného Dodavatelem za provedené Služby a jiná plnění nebo
náhrady sjednaných nákladů je sjednána 30 dnů ode dne jeho vystavení. Dodavatel se zavazuje odeslat
každý daňový doklad nejpozději následující pracovní den po dni vystavení.

5. Daňové doklady budou zasílány elektronickou poštou na e-mailovou adresu Objednatele helpdesk@fnhk.cz.
Objednatel se zavazuje zajistit, že e-mailová adresa nebude vázána na konkrétní osobu a bude na ní
zajištěna pro zpracování p íchozích e-mailů zastupitelnost zodpovědných pracovníků Objednatele. Daňové
doklady budou zasílány formou p ílohy e-mailu ve formátu ISDOCX pro import do ekonomického sw a dále
formátu PDF pro náhled a p ípadný tisk. Dodavatel se zavazuje zajistit, že zasílané daňové doklady budou
podepsány a opat eny elektronickým podpisem ve smyslu zákona č. 297/2016 Sb., o službách vytvá ejících
důvěru pro elektronické transakce, v platném znění, prokazujícím jednoznačný původ a autenticitu
zaslaného daňového dokladu.

6. Platby budou prováděny Objednatelem bezhotovostně na účet Dodavatele, který bude vždy uveden na
p íslušném daňovém dokladu. Za den úhrady se považuje den p ipsání p íslušné částky na účet Dodavatele.

7. Náklady na cestovné a p ípadné ubytování pracovníků Dodavatele spojené s plněním této Smlouvy jsou
zahrnuty v celkové roční ceně plnění a nebudou u Objednatele nárokovány k náhradě.

8. Cena za servisní podporu může být, po uplynutí 4Ř měsíců platnosti smlouvy, upravena. Tato úprava může
být provedena maximálně 1x v kalendá ním roce s platností min. 12 měsíců. P ípustná změna ceny je
následující: v p ípadě, že oficiální průměrná roční míra inflace zve ejněná Českým statistickým ú adem za
p edchozí kalendá ní rok dosáhla více než 2%, může být smluvní cena bez DPH navýšena až o částku
odpovídající 50% stanovené oficiální průměrné roční míry inflace, maximálně však o 3%. Tato úprava může
být provedena jednostranným písemným právním jednáním.

lánek VII - Ochrana osobních a citlivých údajů

1. Vzhledem ke skutečnosti, že v rámci smluvního vztahu založeného Smlouvou umožňuje Objednatel
Dodavateli p ístup k osobním a citlivým údajům subjektů údajů, svých klientů a pacientů (dále jen Klienti),
ve smyslu zákona č. 110/201ř Sb., o zpracování osobních údajů (dále jen Zákon o zpracování osobních
údajů) a na ízení Evropského parlamentu a Rady (EU) 2016/67ř 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 ř5/46/ES, obecné
na ízení o ochraně osobních údajů (dále jen Na ízení), zp esňují Smluvní strany svá práva a povinnosti p i
zpracování osobních a citlivých údajů Klientů Objednatele v souladu s uvedenými právními p edpisy
následovně.

2. Dodavatel se zavazuje zachovávat mlčenlivost o všech skutečnostech, o nichž se dozví u Objednatele p i
plnění závazků dle Smlouvy nebo v souvislosti s nimi. To platí zejména o skutečnostech, na něž se vztahuje
povinnost mlčenlivosti zdravotnických pracovníků, zejména podle ustanovení § 51 zákona č. 372/2011 Sb.,
o zdravotních službách a podmínkách jejich poskytování (Zákon o zdravotních službách), jakož i o
osobních údajích, citlivých údajích (dále jen Osobní údaje) a o bezpečnostních opat eních, jejichž
zve ejnění by ohrozilo zabezpečení Osobních údajů ve smyslu zejména ustanovení § 32 a 47 Zákona o
zpracování osobních údajů. Dodavatel se zavazuje nakládat s Osobními údaji v souladu s Na ízením,
Zákonem o zpracování osobních údajů a prováděcími právními p edpisy p ijatými k ochraně a zpracování
osobních údajů.

3. Pokud Dodavatel p ijde p i plnění Smlouvy do styku s Osobním údajem a bude v postavení zpracovatele
(dále jen Zpracovatel) ve smyslu Na ízení a Zákona o zpracování osobních údajů, zavazuje se nakládat
s Osobními údaji pouze za účelem splnění závazků z této Smlouvy a žádným jiným způsobem, a to
v souladu s Na ízením a Zákonem o zpracování osobních údajů a Zákonem o zdravotních službách a
prováděcími p edpisy.

4. Zpracovávání Osobních údajů v rozsahu údajů poskytnutých anebo zp ístupněných Objednatelem a
týkajících se zdravotnické dokumentace Klientů, jimž jsou Objednatelem poskytovány zdravotní služby, a
dále v rozsahu Osobních údajů zaměstnanců Objednatele, kte í jsou zdravotnickými pracovníky,
Dodavatelem, může zahrnovat zejména provedení analýzy požadavku Objednatele, jeho vy ešení, zajištění

Servisní smlouva strana 4 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
záznamu o ešení požadavku Objednatele a důkazu pro p ípad pozdějších reklamací nebo jiných nároků
vznesených Objednatelem v souvislosti s Dodavatelem poskytovanou Službou, implementace dat,
odstranění Objednatelem ohlášených potíží p i užívání informačního systému (dále jen IS), zabránění,
vyhledávání a opravy problémů zjištěných p i poskytování Služby, testování funkcí IS za účelem ově ení
nebo zvýšení kvality IS, zlepšování funkcí IS, vyhledávání hrozeb uživatelům a ochrany uživatelů IS,
ukládání kopií databáze (datových záloh) Objednatele na určený server, provádění automatického výmazu
databáze po uplynutí doby jejího uložení (dále jen Sjednané činnosti).

5. Osobní údaje nebudou použity k jinému účelu, než Sjednaným činnostem, ani z nich nebudou odvozovány
informace pro žádné reklamní či jiné komerční účely.

6. Zpracování Osobních údajů je vedlejším závazkem Dodavatele p i plnění této Smlouvy, úplata za
zpracování je proto zahrnuta do ceny Služby dle této Smlouvy.

7. Dodavatel bere na vědomí, že p i Sjednaných činnostech může p ijít do styku s následujícími Osobními
údaji:

a) Osobní údaje zaměstnanců Objednatele – jméno, p íjmení, titul, datum a místo narození, rodné číslo,
bydliště, zdravotní pojišťovna, doklad o dosaženém vzdělání, potvrzení léka e o schopnosti vykonávat
povolání, telefon, e-mail, bankovní účet zaměstnance, p íp. další osobní údaje, které je Objednatel,
jakožto zaměstnavatel, povinen na základě zákona zpracovávat za účelem vedení personální a mzdové
agendy svých zaměstnanců,

b) Osobní údaje Klientů – jméno, p íjmení, titul, rodné číslo, resp. číslo pojištěnce nebo datum narození,
číslo pojišťovny, anamnestická data související se zdravotním stavem a péčí o Klienta, diagnosy, adresa
bydliště anebo pobytu, telefonní číslo, e-mailová adresa, identifikační údaje zaměstnavatele, profese,
informace o rodinných p íslušnících, pohlaví, rodinný stav, občanství, identifikační údaje praktických
léka ů Klienta, druh a výše sociální dávky.

8. Jakékoliv nakládání s Osobními údaji je nutné považovat za zpracování Osobních údajů.

9. Za porušení ochrany Osobních údajů v průběhu Sjednaných činností je odpovědný Dodavatel.

10. Dodavatel je oprávněn zpracovávat Osobní údaje pouze po dobu účinnosti Smlouvy anebo po dobu
nezbytnou k plnění archivačních povinností podle platných právních p edpisů, nejdéle však 10 let od jejího
ukončení.

11. Po ukončení Smlouvy se Dodavatel zavazuje veškeré Osobní údaje, které má p ípadně ve své k dispozici
nap . za účelem provádění testování anebo jiných operací za účelem zvýšení anebo ově ení kvality systému
prokazatelně smazat nebo vrátit Objednateli a vymazat existující kopie, neukládá-li zákon Dodavateli
povinnost Osobní údaje zpracovávat i po ukončení Smlouvy.

12. Dodavatel za účelem ochrany Osobních údajů Objednatele a jeho Klientů p ed neoprávněným p ístupem,
použitím, zve ejněním nebo zničením, resp. p ed jejich náhodnou ztrátou či změnou uplatňuje technická a
organizační bezpečnostní opat ení, interní kontroly a rutiny zabezpečení Osobních údajů zajišťující splnění
všech povinností dle Na ízení a Zákona o ochraně osobních údajů, zejména zajišťuje, aby veškeré p ístupy
byly možné pouze p es p ístupová hesla pouze výslovně oprávněných pracovníků Dodavatele, ze
záznamem historie o p ístupu do IS Objednatele, a dále aby data obsažená ve zdravotnické dokumentaci
Objednatele byla šifrována způsobem, který znemožní nahlížení do zdravotnické dokumentace
neoprávněným osobám. Dodavatel se zavazuje zajistit informovanost svých pracovníků o povinnostech
vyplývajících z této Smlouvy. Dodavatel se zavazuje zajistit, aby jeho pracovníci, kte í budou p icházet do
styku s Osobními údaji, byli smluvně vázáni povinností mlčenlivosti ve smyslu Na ízení a Zákona o ochraně
osobních údajů a poučeni o možných následcích porušení těchto povinností s tím, že povinnost důvěrnosti
bude jimi dodržována i po skončení jejich smluvního vztahu k Dodavateli. Dodavatel prohlašuje, že jeho
zaměstnanci a/nebo subdodavatelé p icházející p i výkonu své práce do styku s Osobními údaji pacientů a
klientů Objednatele, byli náležitě poučeni o povoleném způsobu nakládání s Osobními údaji a byli
seznámeni s následky jednání, které by bylo v rozporu se zákonnou úpravou a bezpečnostními směrnicemi
Objednatele, s nimiž byli prokazatelně seznámeni.

13. Dodavatel zajišťuje bezpečné zpracování Osobních údajů Klientů Objednatele zejména následujícími
organizačními a technickými opat eními Dodavatele:

a) Aplikací Integrovaného systému ízení politiky bezpečnosti informací dle standardu normy ČSN
ISO/IEC 27001:2006,

b) ízením jednoznačně identifikovatelného a zabezpečeného p ístupu uživatelů NIS Dodavatele,
c) Aplikací kryptografických opat ení na ochranu Osobních údajů Objednatele, v rámci ukládání dat

Objednatele včetně elektronické komunikace a výměny dat s datovým centrem v rámci ve ejné sítě
internet,
d) Aplikací systému zaznamenávání a vytvá ení záznamů událostí a změn formou logů.

14. Osobní údaje nebudou poskytnuty ani jakkoliv zp ístupněny t etím osobám ze zemí mimo EU a EHP.

Servisní smlouva strana 5 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
15. Dodavatel je oprávněn bez p edchozího písemného souhlasu Objednatele do zpracování Osobních údajů
zapojit i jiného Dalšího zpracovatele, a to společnost, na jejichž za ízení Dodavatel provozuje své Služby dle
této Smlouvy, je však povinen, aby každý Další zpracovatel dodržoval podmínky zpracování dané touto
Smlouvou, zejména pokud se týká technických a organizačních opat ení a dále je povinen p edem
informovat Objednatele o Dalším zpracovateli a sdělit jeho identifikační údaje, a to tak, aby měl Objednatel
možnost vyslovit vůči této změně své oprávněné námitky.

16. Dodavatel tímto prohlašuje, že v rámci své činnosti implementoval požadavky Na ízení a zpracování
Osobních údajů bude probíhat v souladu s pravidly Na ízení. Dodavatel se zejména zavazuje:

a) zpracovávat Osobní údaje pouze na základě doložených pokynů Objednatele činěného prost ednictvím
oprávněných osob podle ujednání a způsobem dle této Smlouvy, tedy výhradně pokynem v písemné
podobě ve formátu PDF prost ednictvím e-mailu zaslaného na adresu helpdesk@stapro.cz anebo
prost ednictvím záznamu v aplikaci HelpDesk na adrese https://helpdesk.stapro.cz, doloženého pokynu
Objednatele je t eba i tehdy, mají-li být Osobní údaje p edávány do t etí země nebo mezinárodní
organizaci; Dodavatel je povinen archivovat veškeré pokyny Objednatele,

b) zachovávat mlčenlivost o povaze a nakládání s Osobními údaji,

c) provést vhodná technická a organizační zabezpečení, aby zajistil úroveň zabezpečení odpovídající
danému riziku, p i posuzování vhodné úrovně zabezpečení Dodavatel zohlední zejména rizika, která
p edstavuje zpracování, zejména náhodné nebo protiprávní zničení, ztráta, pozměňování, neoprávněné
zp ístupnění p edávaných, uložených nebo jinak zpracovávaných Osobních údajů, nebo neoprávněný
p ístup k nim,

d) nep edat ani nezp ístupnit Osobní údaje žádné t etí osobě, s výjimkami sjednanými výše (viz Další
zpracovatel) bez p edchozího písemného souhlasu Objednatele, tedy nezapojit do zpracování žádného
dalšího zpracovatele bez p edchozího písemného povolení Objednatele, udělí-li Objednatel povolení
k zapojení Dalšího zpracovatele, musí být tomuto Dalšímu zpracovateli uloženy stejné povinnosti na
ochranu Osobních údajů, jaké jsou uvedeny v tomto článku Smlouvy,

e) zohlednit povahu zpracování a být Objednateli nápomocen prost ednictvím vhodných technických a
organizačních opat ení p i plnění Objednatelovi povinnosti reagovat na žádosti o výkon práv subjektů
údajů stanovených v kapitole III. Na ízení (Práva subjektu údajů),

f) být Objednateli nápomocen p i zajišťování souladu s povinnostmi podle článků 32 až 36 Na ízení,
zejména být nápomocen v p ípadech porušení zabezpečení Osobních údajů k tomu, aby Objednatel
mohl vyhodnotit, zda porušení mělo za následek riziko pro práva a svobody Klientů, p ípadně být
nápomocen k tomu, aby Objednatel mohl ádně a včas ohlásit porušení zabezpečení Osobních údajů
dozorovému ú adu (včetně údajů dle čl. 33 odst. 3 Na ízení) a ohlásit to Klientům, p i výkonu této
povinnosti je Dodavatel povinen reagovat bez zbytečného odkladu na pokyny a požadavky Objednatele,
a to p i zohlednění povahy zpracování a informací, jež má Dodavatel k dispozici,

g) bez zbytečného odkladu ohlásit Objednateli p ípady porušení zabezpečení Osobních údajů,

h) poskytnout Objednateli veškeré informace pot ebné k doložení toho, že byly splněny povinnosti
stanovené v tomto článku Smlouvy a umožnit audity, včetně inspekcí, prováděné Objednatelem nebo
jiným auditorem, kterého Objednatel pově il, a poskytovat součinnost k těmto auditům,

i) neprodleně informovat Objednatele v p ípadě, že podle názoru Dodavatele určitý pokyn Objednatele
porušuje ustanovení Na ízení nebo jiné p edpisy týkající se ochrany Osobních údajů.

17. Zpracovatel může ve výjimečných a odůvodněných p ípadech a vždy na základě p edchozího požadavku
Správce na poskytnutí služby servisní podpory, zpravidla opravy chyby ASW, požádat Správce o poskytnutí
části nebo celé databáze Správce, obsahující Osobní údaje pacientů Správce, Klientů nebo zaměstnanců,
v elektronické podobě do působnosti a prost edí Zpracovatele.

Poskytnutí Osobních údajů lze zrealizovat výhradně dle níže sjednaného postupu:

a) Na základě výslovného požadavku Správce na poskytnutí servisních služeb požádá Zpracovatel
v konkrétním záznamu aplikace HelpDesk Objednatele výhradně písemnou formou Správce o
poskytnutí Osobních údajů.

b) V záznamu HelpDesk je Zpracovatel povinen uvést zdůvodnění poskytnutí dat obsahující Osobní údaje,
dobu nezbytně nutnou pro zpracování dat, způsob p edání dat Zpracovateli, rozsah zpracování dat a
způsob zpětného p edání dat Správci nebo způsob likvidace dat Zpracovatelem.

c) Žádost Zpracovatele na poskytnutí dat může odsouhlasit pouze písemnou formou výhradně pracovník
Objednatele zodpovědný za ochranu a zpracování dat Správce (DPO) nebo statutární zástupce
Objednatele. K datu uzav ení Smlouvy je pracovníkem zodpovědným za ochranu a zpracování dat na
straně Správce:

e-mail:

Servisní smlouva strana 6 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
d) Na základě souhlasu DPO Správce s poskytnutím dat potvrdí za stranu Zpracovatele výhradně DPO
Zpracovatele písemnou formou do záznamu aplikace HelpDesk p evzetí zodpovědnosti a kontrolu nad
p evzetím a zpracováním dat Správce. Současně DPO Zpracovatele vydá pokyn pově enému
pracovníkovi Zpracovatele k p evzetí dat a zahájení ešení požadavku s využitím poskytnutých dat
Správce. K datu uzav ení Smlouvy je pracovníkem zodpovědným za ochranu a zpracování dat na straně
Zpracovatele:

, e-mail

e) Po ukončení ešení požadavku potvrdí do záznamu aplikace HelpDesk pově ený pracovník Objednateli
ukončení používání poskytnutých dat Správce. Současně tuto informaci p edá DPO Zpracovatele.

f) DPO Zpracovatele zajistí kontrolu likvidace poskytnutých dat na straně Zpracovatele, p íp. kontrolu
p edání dat zpět Objednateli a uvede o provedené kontrole likvidace anebo p edání dat Objednateli
písemný zápis do záznamu HelpDesk.

g) Následně DPO Správce potvrdí p evzetí zpracovaných dat zpět do působnosti Správce písemným
zápisem do záznamu aplikace HelpDesk.

lánek VIII - Duševní vlastnictví a obchodní tajemství

1. Všechny materiály, informace a data Dodavatele p edané Objednateli p i plnění této Smlouvy v jakékoliv
formě, a dále koncepty, know-how, techniky, postupy atp. vztahující se k plnění Smlouvy, zůstávají ve
vlastnictví Dodavatele a jsou obchodním tajemstvím Dodavatele ve smyslu ustanovení § 504 zákona č.
89/2012 Sb., občanského zákoníku, v platném znění, pokud nejsou t etím osobám běžně dostupné, a
Dodavatel má zájem na jejich utajení a ochraně. Dodavatel bere na vědomí, že obsah Servisní smlouvy, vč.
jejich dodatků a p íloh, podléhá povinnosti uve ejnění dle zákona č. 340/2015 Sb., o registru smluv, v
platném znění. Dodavatel prohlašuje, že P ílohy Smlouvy obsahují obchodní tajemství Dodavatele a
Dodavatel má zájem na jejich utajení a ochraně. Smlouva bude Objednatelem uve ejněna bez obchodního
tajemství obsaženého v P ílohách Smlouvy s výjimkou ujednání o ceně plnění Smlouvy.

2. Objednatel je oprávněn k nevýhradnímu užívání materiálů, konceptů, know-how nebo technik Dodavatele
pro svou vlastní interní pot ebu, pokud neporuší podmínky užívání sjednané v tomto článku Smlouvy.

3. Objednatel není oprávněn umožnit jakékoliv další využití materiálů, konceptů, know-how nebo technik t etí
osobě bez p edchozího písemného souhlasu Dodavatele.

4. Objednatel není oprávněn rozkódovávat nebo p ekládat jakékoliv postupy a/nebo techniky Dodavatele,
pokud by takový postup nesloužil pouze jeho interní pot ebě a nebyl činěn v souvislosti se zkvalitněním
funkčnosti plnění dle této Smlouvy. Objednatel není oprávněn informace takto získané využít ke své
obchodní činnosti nebo obchodní činnosti t etí osoby.

5. Žádná ze Smluvních stran nebude bez p edchozího písemného souhlasu druhé Smluvní strany zve ejňovat
či jiným způsobem zp ístupňovat podmínky Smlouvy jiným t etím osobám s výjimkou odborných poradců
vázaných povinností mlčenlivosti a s výjimkou povinností zve ejnění stanovených zákonem (zejména ZVZ).
Dodavatel prohlašuje, že P ílohy Smlouvy obsahují obchodní tajemství Dodavatele a Dodavatel má zájem
na jejich utajení a ochraně.

6. Povinnost mlčenlivosti může být prolomena pouze zákonem.

7. Smluvní strany se zavazují dodržovat povinnosti dle tohoto článku Smlouvy i po ukončení účinnosti
Smlouvy.

lánek IX - Odpovědnost za škodu

1. Dodavatel odpovídá Objednateli za újmu na jmění, kterou mu způsobí p i plnění Smlouvy, dle platné právní
úpravy. Dodavatel neodpovídá za újmu na jmění, které Objednatel mohl zabránit, pokud Dodavatel oznámí
Objednateli, že porušil nebo poruší smluvně sjednanou povinnost, včetně důvodů porušení a upozorní ho na
možné následky.

2. Dodavatel nese odpovědnost za jednání osob, které použil v souvislosti s plněním Smlouvy, bez ohledu na
to, zda se jedná o jeho vlastní zaměstnance nebo Subdodavatele.

3. Dodavatel se odpovědnosti zprostí zcela nebo zčásti, prokáže-li, že se na vzniku újmy podílel nepovolený,
nesprávný či nekvalifikovaný zásah pracovníků Objednatele či t etích osob (povolenost, správnost a/nebo
kvalifikovanost je dána zejména touto Smlouvou, jejími p ílohami, jakož i listinami, na které Smlouva
odkazuje, manuály, p íručkami, zvyklostmi a obecnými postupy užívání) a/nebo že mu ve splnění povinnosti
ze Smlouvy dočasně nebo trvale zabránila mimo ádná nebo nep edvídatelná událost nebo nep ekonatelná
p ekážka vzniklá bez jeho zavinění mimo jeho osobní poměry.

4. Dodavatel se zavazuje, že po celou dobu platnosti a účinnosti Smlouvy bude mít sjednánu pojistnou

smlouvu s vinkulovaným pojistným plněním ve prospěch objednatele pro p ípad, že svou činností v

souvislosti s plněním p edmětu této Smlouvy způsobí škodu t etí osobě (nap . Objednateli) s limitním

Servisní smlouva strana 7 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
pojistným plněním na jednu škodnou událost minimálně 20 000 000 Kč (slovy dvacet milionů korun českých)
a že tuto pojistnou smlouvu bude udržovat po celou dobu plnění p edmětu této Smlouvy v platnosti a
účinnosti tak, aby výše uvedené limitní pojistné plnění nebylo sníženo či jinak ovlivněno v neprospěch
Objednatele. Dodavatel se zavazuje p edkládat Objednateli v průběhu plnění p edmětu této Smlouvy kopie
pojistných certifikátů či jiných obdobných dokladů prokazujících pojištění ve sjednaných limitech, a to vždy
nejpozději do 1 měsíce po jejich obdržení.

lánek X - Sank ní ujednání

1. Je-li Objednatel v prodlení s úhradou jakéhokoliv peněžitého plnění, je Dodavatel oprávněn požadovat na
Objednateli zaplacení úroku z prodlení ve výši 0,025 % z dlužné částky za každý den prodlení. Obě Smluvní
strany sjednávají, že takto upravený úrok z prodlení je p imě ený.

2. Objednatel je oprávněn kontrolovat plnění Smlouvy. P i p ípadném zjištění i dílčího neplnění Smlouvy je
Objednatel oprávněn nárokovat u Dodavatele i za dílčí neplnění termínu smluvní pokuty. Smluvní pokuty
jsou sjednány za porušení povinností a ve výši dle zadání Objednatele v zadávací dokumentaci, která je
p ílohou Smlouvy.

3. Objednatel nemá nárok na smluvní pokutu tehdy, kdy se bude Objednatel nacházet současně v prodlení s
úhradou minimálně t í dluhů (daňových dokladů - faktur). Objednatel a Dodavatel sjednali, že za tyto včasně
neuhrazené dluhy (faktury) nebudou považovány ty dluhy, jejichž výše, důvod či opodstatněnost se stanou
p edmětem jednání mezi Objednatelem a Dodavatelem (tzn., že se bude jednat o sporné dluhy), pop . ty
faktury, které budou z důvodu jejich nedostatků (formálních či obsahových) Objednatelem Dodavateli
vráceny.

lánek XI - Doba platnosti a ú innosti Smlouvy

1. Tato Smlouva se uzavírá na dobu neurčitou.

2. Tato Smlouva nabývá platnosti dnem jejího podpisu oběma Smluvními stranami.

3. Tato Smlouva nabývá účinnosti prvního dne následujícího po dni p edání díla dle uzav ené smlouvy o dílo
vzešlé z ve ejné zakázky s názvem „Modernizace IT FN HK v návaznosti na eHealth“, která byla uve ejněna
ve Věstníku ve ejných zakázek pod evidenčním číslem Z201ř-022009. Objednatel se zavazuje Smlouvu
zve ejnit v souladu s p íslušnými ustanoveními zákona č. 340/2015 Sb., o registru smluv, a to nejpozději do
pěti pracovních dní od uzav ení Smlouvy.

4. Tato Smlouva pozbývá účinnosti v p ípadech a za podmínek uvedených v zadávací dokumentaci, která je
p ílohou této smlouvy.

lánek XII - Ustanovení spole ná a závěre ná

1. Změna Smlouvy – Jakékoliv změny Smlouvy musí být sepsány formou písemných, písemných dodatků ke
Smlouvě a musí být podepsány Smluvními stranami, osobami oprávněnými k takovému jednání.

2. Rozhodné právo – Vztahy mezi Smluvními stranami výslovně neupravené touto Smlouvou se ídí režimem
občanského zákoníku (zákon číslo č. 89/2012 Sb., v platném znění) a autorského zákona (zákon číslo
121/2000 Sb., v platném znění).

3. Úplná dohoda – Tato Smlouva, včetně jejích dále uvedených p íloh a listin, na které je ve Smlouvě činěn
výslovný odkaz, p edstavuje úplnou dohodu mezi Smluvními stranami. Tato Smlouva byla vyhotovena ve
dvou stejnopisech, z nichž po jednom stejnopisu obdrží po jejím podpisu každá Smluvní strana. Pro p ípad
rozporu některého ujednání obsaženého zároveň ve Smlouvě i v P íloze, Smluvní strany sjednávají p ednost
ujednání obsaženého ve Smlouvě, a to s výjimkou p ílohy č. 4 (zadávací dokumentace), která má v souladu
s čl. III odst. 4 této Smlouvy aplikační p ednost p ed ustanoveními této Smlouvy.

Součástí Smlouvy jsou P ílohy číslo 1, 2, 3 a 4:

P íloha č. 1 - Rozsah služeb a cena plnění

P íloha č. 2 - Popis služeb

P íloha č. 3 - Zodpovědné osoby a pravidla součinnosti

P íloha č. 4 - Zadávací dokumentace

4. Salvatorní klauzule – Pokud bude jakékoliv ujednání Smlouvy shledáno jako neplatné či neúčinné,
nedotýká se neplatnost a neúčinnost ostatních ujednání Smlouvy. Smluvní strany se pro tento p ípad
zavazují neplatná či neúčinná ujednání nahradit dohodou platnými a účinnými ustanoveními, která nejlépe
odpovídají smyslu a mají nejblíže k neplatnému či neúčinnému ujednání, aniž by požadovaly výhody nebo
plnění, která původně nebyla sjednána. Do doby uzav ení dohody platí obchodní zvyklosti Smluvních stran,
obecně závazná právní úprava a princip analogie.

Servisní smlouva strana 8 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
5. Postoupení práv ze Smlouvy – Žádná Smluvní strana není oprávněna postoupit právo nebo závazek nebo
zatížit pohledávku vyplývající z této Smlouvy nebo žádnou jejich část bez p edchozího písemného souhlasu
druhé Smluvní strany. Zápočet vzájemných pohledávek je možný pouze na základě dohody Smluvních
stran.

6. Doručování písemností – Smluvní strany se dohodly, že doručeno je i v p ípadě, že písemnost je zaslána
na adresu sídla Smluvní strany zapsanou v den odeslání zásilky v p íslušném obchodním rejst íku, pokud si
adresát zásilky tuto nevyzvedl, ač byl o uložení zásilky poštovním p epravcem ádně uvědomen, a to
desátým dnem od prvního doručení. Smluvní strany se dohodly, že doručeno je i v p ípadě, že písemnost je
zaslána na adresu elektronické pošty pro doručování společnosti uvedenou v záhlaví Smlouvy, bez ohledu
na skutečnost, zda se adresát s obsahem sdělení seznámil, neboť odesláním na uvedenou adresu se
písemnost dostala do sféry adresáta, který se s jejím obsahem mohl seznámit.

7. Rozhodování sporů – Veškeré spory z této Smlouvy se Smluvní strany zavazují ešit smírem a teprve
pokud se spor nepoda í smírem vy ešit, bude spor rozhodovat obecný soud strany žalované.

8. Určitost projevu vůle - Smluvní strany tímto prohlašují a stvrzují podpisy osob oprávněných k jednání
Smluvních stran, že si Smlouvu ádně p ečetly, je jim znám význam jednotlivých ujednání Smlouvy a jejich
p íloh, že Smlouvu uzavírají na základě své pravé a svobodné vůle a dále prohlašují, že jim k datu podpisu
Smlouvy nejsou známy žádné skutečnosti ani okolnosti, které by jim mohly bránit v plnění závazků dle této
Smlouvy, tuto Smlouvu učinit neplatnou nebo neúčinnou, nebo zma it její účel a cíl tak, jak jej v této Smlouvě
společně deklarovaly.

V Pardubicích dne 2Ř.1.2020 V Hradci Králové dne 30.1.2020

Dodavatel: ………..……….…. Objednatel: ….………….…………….
STAPRO s. r. o. Fakultní nemocnice Hradec Králové

Servisní smlouva strana 9 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Příloha . 1 - Rozsah služeb a cena plnění

lánek I -Vymezení předmětu dodávky Služeb

Dodavatel se zavazuje poskytovat sjednané Služby na dále vyjmenované informační technologie informačního
systému Objednatele.

1. Aplika ní software FONS Enterprise

Servisní smlouva strana 1 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Servisní smlouva strana 2 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
2. Technické prostředky

Dodavatel se zavazuje dodávat sjednané Služby na tyto technické prost edky:

Servisní smlouva strana 3 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
3. Definice pojmů

lánek II - Podpora aplika ních software

1. Aplika ní sw FONS Enterprise

Servisní smlouva strana 4 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
í

lánek III - Podpora technických prostředků IS

Servisní podporu technických prost edků sjednávají Smluvní strany na dobu 5-ti let od data účinnosti
Smlouvy.

1. Technické prostředky pro ASW FONS Enterprise

Servisní smlouva strana 5 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
lánek IV - Definice programu servisní podpory

Servisní smlouva strana 6 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
lánek V - Cena plnění

označení služby roční cena plnění

Klinický informační systém FONS Enterprise - Servisní podpora ASW 6 06Ř 735,00 Kč
Integrační platforma - Servisní podpora 505 727,ř2 Kč
Portál pacienta - Servisní podpora
Technické prost edky HW - Servisní podpora
celková roční cena podpory bez DPH
sjednaná měsíční úhrada bez DPH

lánek VI - Cena podpory nad rámec Smlouvy

Konec přílohy č. 1

Servisní smlouva strana 7 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Příloha . 2 - Popis služeb
lánek I - Podpora aplika ního software

1. Aplika ní sw FONS Enterprise

Servisní smlouva strana 1 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Servisní smlouva strana 2 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Servisní smlouva strana 3 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
lánek II - Podpora technických prostředků

Servisní podporu technických prost edků sjednávají Smluvní strany na dobu 5-ti let od data účinnosti
Smlouvy.

1. Technické prostředky pro ASW FONS Enterprise

Dodavatel se zavazuje zajišťovat podporu provozu technických prost edků a systémových software (operačního
systému a databázového prost edí) uvedených v p íloze č. 1 a dle programu „Nep etržitá servisní podpora
provozu ASW“.

Servisní smlouva strana 4 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
lánek III - Kategorie incidentů a podpora prostředků IS

Pro stanovení pot ebného rozsahu a dostupnosti služby vzhledem k typu incidentu je zavedena kategorizace
typu incidentů a služba programu podpory k danému typu incidentu.

Servisní smlouva strana 5 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Konec přílohy č. 2

Servisní smlouva strana 6 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Příloha . 3 - Zodpovědné osoby a pravidla sou innosti

lánek I - Osoby odpovědné za řízení vztahů v rámci Smlouvy

1. Pracovníci odpovědni za řízení vztahů Smlouvy

Dodavatel jméno pracovní za azení telefon, e-mail
odpovědnost tel.

statutární zástupce s právem I
podpisu smluvních ujednání

osoba oprávněná k jednání
o smluvních podmínkách

Objednatel

statutární zástupce tel.

s právem podpisu prof. MUDr. Vladimír Palička, CSc., dr. h. c. editel

smluvních ujednání

osoba oprávněná k tel.

jednání o smluvních prof. MUDr. Vladimír Palička, CSc., dr. h. c. editel

podmínkách

2. Pracovník Dodavatele odpovědný za vlastní plnění a spolupráci s Objednatelem

Dodavatel

osoba odpovědná za plnění tel.

Smlouvy

3. Pracovníci Objednatele odpovědní za spolupráci s Dodavatelem

Objednatel

osoba odpovědná za tel.

spolupráci a plnění Smlouvy

4. Organiza ní podpora Objednatele

Odpovědné osoby Objednatele, včetně stanovení jejich dostupnosti, pro spolupráci p i plnění sjednaných
servisních služeb a koordinaci p ípadného servisního zásahu nebo servisního výjezdu Dodavatele.

Objednatel - organizační podpora Objednatele pro servisní zásah nebo servisní výjezd
tl
v

lánek II - Sou innost a komunikace

1. Centrum podpory zákazníka - HelpDesk

Servisní smlouva strana 1 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
2.

Servisní smlouva strana 2 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Servisní smlouva strana 3 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
-

Servisní smlouva strana 4 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
lánek III - Bezpe nost a ochrana

Konec přílohy č. 3

Servisní smlouva strana 5 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Příloha . 4 – Zadávací dokumentace

Servisní smlouva strana 6 Fakultní nemocnice Hradec Králové

STAPRO s. r. o. | Pernštýnské nám. 51 | 530 02 Pardubice | www.stapro.cz
Zadávací dokumentace k nadlimitní ve ejné zakázce na dodávku

Název ve ejné zakázky:

„Modernizace IT FN HK v návaznosti na eHealth“

(CZ.06.3.05/ 0.0/ 0.0/ 16_034/ 0006163) FINANCOVANÝ Z INTEGROVANÉHO OPERAČNÍHO

PROGRAM U.

Kód CPV: 48814000-7 Zdravotnické informační systémy
Evidenční číslo VZ p id lené ve V stníku ve ejných zakázek: Z2019-022009

Druh zadávacího ízení:
Otev ené ízení dle § 56 zákona č. 134/2016 Sb., o zadávání ve ejných zakázek, v platném

zn ní (dále jen „Zákon“)

FAKUTLNÍ NEMOCNICE HRADEC KRÁLOVÉ

Sokolská 581, 500 05 Hradec Králové – Nový Hradec Králové, Česká republika
tel.: +420 495 831 111, fax +420 495 832 100, www.fnhk.cz
IČ: 00179906, DIČ: CZ00179906 1

Bankovní spojení: Česká národní banka, č. účtu 24639511/0710
Zkratka Vysvětlení zkratky

AZV ČR Agentura pro zdravotnický výzkum České republiky
AMIS_H
AMIS_HD Název SW pro KIS
B2B Název SW pro KIS
CBA Zabezpečená komunikace s infomačním systémem VZP.
CF Analýza nákladů a výnosů
ČR Cash-flow
ČSSZ Česká republika
DASTA Česká správa sociálního zabezpečení
Datový standard Ministerstva zdravotnictví ČR
DICOM Digital Imaging and Communications in Medicine - standard pro zobrazování,
DMS distribuci, skladování a tisk medicínských dat po ízených snímacími metodami
DRG Document Management Systém – správa elektronických dokumentů
DU Diagnosis-related group – systém klasifikace klinických p ípadů.
DT standard Datové uložiště
EA Diagnostický a terapeutický standard léčebné péče
eH NCP Enterprise architektura, koncept modelování organizací
Národní kontaktní místo pro eHealth
EHR EHR - Elektronické zdravotní záznamy. Obsah a forma EHR jsou definovány
Standardy elektronického zdravotnictví.
EIS Ekonomický informační systém
exchange Medical Documents System, projekt buduje, rozši uje a udržuje komunikační
eMeDOcS infrastrukturu pro bezpečnou a důvěryhodnou výměnu zdravotnické dokumentace mezi
poskytovateli zdravotních služeb zdravotnickými za ízeními v rámci zdravotnického
EN 13606 systému České republiky
Evropská technická norma zdravotnické informatiky
epSOS
Smart Open Services for European Patients, evropský projekt s cílem navrhnout a
EU postavit servisní infrastrukturu, která zajistí p eshraniční interoperabilitu mezi systémy
EZD elektronických zdravotních záznamů v Evropě. Ukončen 2014.
FN HK European Union, Evropská unie
GAČR Elektronická zdravotní dokumentace
GDPR Fakultní nemocnice Hradec Králové
HW Grantová agentura České republiky
HL7
ICT (IKT) General Data Protection Regulation

IČP Hardware
IČZ Datový standard Health Level Seven
IDRR informační a komunikační technologie
Index EHR Identifikační číslo pracoviště v rámci Zdravotnického za ízení v rámci Poskytovatele
Index PHR zdravotních služeb
Index ZD Identifikační číslo zdravotnického za ízení
Integrované datové resortní rozhraní
Jednoznačný identifikátor záznamu EHR
Jednoznačný identifikátor záznamu PHR
Jednoznačný identifikátor záznamu ZD

2
Zkratka Vysvětlení zkratky

Index Centrální systém umožňující získání p ehledu všech evidovaných indexů ZD, EHR,
ZD/EHR/PH PHR osoby
R
INSPIRE směrnice Evropské komise a Rady si klade za cíl vytvo it evropský legislativní rámec
pot ebný k vybudování evropské infrastruktury prostorových informací
IROP Integrovaný regionální operační program
IS Informační systém
IZS Integrovaný záchranný systém
Soubor podporující datové rozhraní mezi smluvním za ízením poskytujícím zdravotní
KDAVKA péči a ZP pro p ípad p edávání individuálních dokladů v datové formě.

KIS Klinický informační systém

KZS Klient zdravotních služeb – zobecňující pracovní pojem pro role pacienta, pojištěnce,
občana
LIS Laboratorní informační systém
MIS Manažerský informační systém
MKN Mezinárodní klasifikace nemocí
MPI
MZ ČR Master Patient Index
NAP VS ČR Ministerstvo zdravotnictví ČR
NCPeH Národní architektonický plán ve ejné správy ČR
NIA Národní kontaktní místo elektronického zdravotnictví
NIS Národní identitní autorita
NIX-ZD Nemocniční informační systém
NRP Národní systém pro výměnu zdravotnické dokumentace
NZIS Národní registr pojištěnců
OPLZZ Národní zdravotnický IS

OPVK Operační program lidské zdroje a zaměstnanost

Operační program vzdělávání pro konkurenceschopnost

OVM Orgány ve ejné moci

PACS Picture archiving and communication system

PC Osobní počítač
PHR osoby P idané záznamy osoby samotné nebo od provozovatele EHR/PHR nebo z jiného
PIO zdroje
Pavilon interních oborů

Provozovatel
EHR/PHR Provozovatel služby (zejména uložení a zp ístupnění) datového úložiště EHR/PHR
(PEHR)

PZS Poskytovatel zdravotních služeb dle zákona č. 372/2011 Sb.

O ídicí orgán

SC Specifický cíl

SNOMED CT Mezinárodní Systematizovaná nomenklatura medicíny – Klinická terminologie

SR Státní rozpočet

SW Software

3
Zkratka Vysvětlení zkratky

SÚKL Státní ústav pro kontrolu léčiv
SZM Spot ební zdravotnický materiál
SZÚ Státní zdravotní ústav
TCM Tradiční čínská medicína
TF04, TF05 Projekty MZČR 2008 – Technická asistence, čtvrtý a pátý oddíl
ÚZIS Ústav zdravotnických informací a statistiky ČR
V Výběrové ízení
VS Ve ejná správa
Národní systém výměny a sdílení elektronické zdravotní dokumentace (ZD/EHR/PHR),
VSEZD umožňující výměnu a sdílení elektronické zdravotní dokumentace (ZD, EHR, PHR)
záznamů mezi oprávněnými osobami elektronickým způsobem
VZP Všeobecná zdravotní pojišťovna
v.z.p. Ve ejné zdravotní pojištění
Ucelený zápis do zdravotnické dokumentace o osobě, opat ený podpisem a časem
Záznam ZD (datum, čas) ošet ujícího zdravotnického pracovníka
Zdravotnická dokumentace dle zákona č. 372/2011 Sb. a vyhlášky č. 98/2012 Sb.
ZD Zabezpečený dlouhodobý důvěryhodný archiv
ZDDA
Zdravotní Služba popsaná zákonem č. 372/2011 Sb.
služba
ZP Zdravotní pojišťovna (pojišťovny)

4
Obsah

1 Základní údaje........................................................................................................... 7

2 Popis předmětu plnění veřejné zakázky a předpokládaná hodnota ............................. 8

3 Popis současného stavu ........................................................................................... 11

4 Požadavky na řešení část 1 ...................................................................................... 11

4.1 Funkční požadavky ..................................................................................................... 11

4.2 Realizační podmínky................................................................................................... 12

4.3 Požadavky na vlastnosti systému v oblasti bezpečnosti ............................................... 14

4.4 Dodávka nezbytné HW a SW infrastruktury................................................................. 14

4.5 Integrační požadavky.................................................................................................. 16

4.6 Požadavky na migraci dat ........................................................................................... 17

4.7 Servisní podmínky ...................................................................................................... 17

4.8 Licenční požadavky..................................................................................................... 28

4.9 Ostatní požadavky...................................................................................................... 28

5 Požadavky na řešení část 2 ...................................................................................... 29

5.1 M inimální požadavky na zabezpečený dlouhodobý důvěryhodný archiv ...................... 29

5.2 Realizační podmínky................................................................................................... 35

5.3 Požadavky na vlastnosti systému v oblasti bezpečnosti ............................................... 35

5.4 Dodávka nezbytné HW a SW infrastruktury................................................................. 36

5.5 Integrační požadavky.................................................................................................. 37

5.6 Požadavky na migraci dat ........................................................................................... 37

5.7 Servisní podmínky ...................................................................................................... 37

5.8 Licenční požadavky..................................................................................................... 39

5.9 Ostatní požadavky...................................................................................................... 39

6 Požadavky zadavatele na způsob zpracování nabídkové ceny: ................................. 40
7 Doba a místo plnění................................................................................................. 40

8 Obsah nabídky ........................................................................................................ 41

9 Další podmínky a požadavky zadavatele.................................................................. 42

10 Hodnocení nabídek.................................................................................................. 43
10.1 Kritérium č. 1 – Náklady životního cyklu...................................................................... 44
10.2 Kritérium č. 2 – Kvalita řešení „Povinné požadavky“ .................................................... 44
10.3 Kritérium č. 3 – Kvalita řešení „Ergonomie“................................................................. 45
10.4 Kritérium č. 4 – Kvalita řešení „Nice to Have“ .............................................................. 50

11 Výběr dodavatele .................................................................................................... 50

12 Požadavek zadavatele na poskytnutí jistoty............................................................. 54

5
13 Rozsah požadavků zadavatele na kvalifikaci ............................................................ 55
13.1 Základní způsobilost dle § 74 zákona........................................................................... 55
13.2 Profesní způsobilost dle § 77 zákona ........................................................................... 56

13.3 Ekonomická kvalifikace dle § 78 zákona ...................................................................... 56
13.4 Technická kvalifikace dle § 79 zákona ......................................................................... 57

13.5 Výpis ze seznamu kvalifikovaných účastníků ............................................................... 59
13.6 Forma splnění kvalifikace ........................................................................................... 59
14 Způsob a doba pro podávání nabídek ...................................................................... 60
15 Lhůta, po kterou jsou účastníci nabídkami vázáni .................................................... 61
16 Otevírání nabídek.................................................................................................... 61
17 Komunikace mezi zadavatelem a dodavatelem ........................................................ 62

6
1 Základní údaje

Zadávací dokumentace obsahuje up esňující informace k údajům, které byly uve ejn ny
v Oznámení o zahájení zadávacího ízení, a je pro účastníky závazná. Obsahuje zadávací
podmínky, které bude zadavatel posuzovat a jejichž nespln ní vede k vyloučení účastníka
z další účasti v zadávacím ízení.
Účastník je vázán všemi body zadávací dokumentace zadavatele.

Základní identifikační údaje zadavatele

Zadavatel Název Fakultní nemocnice Hradec Králové

Zastoupený Sídlo Sokolská 581, 500 05 Hradec
Kontaktní osoba pro
vysv tlení zadávací Králové – Nový Hradec Králové
dokumentace
Adresa profilu zadavatele IČO 00179906

Bankovní spojení 40002-24639511/0710

ID datové schránky: v7zqi84

prof. MUDr. Vladimírem Paličkou, CSc., dr. h. c., editelem
Kontaktní údaje

Telefon

E-mail

https://www.egordion.cz/nabidkaGORDION/profilFNHK

P i komunikaci p es datovou schránku vyplňte obálku datové zprávy minimáln v sekci
„K rukám: Ing. Vladimír Duchoň“.

Žádosti o vysv tlení zadávací dokumentace musí být doručeny zadavateli v písemné form
dle ustanovení § 98 Zákona. P ípadné další informace k textu zadávací dokumentace a
odpov di na dotazy k zadávací dokumentaci budou uve ejňovány na profilu zadavatele
https://www.egordion.cz/nabidkaGORDION/profilFNHK.

UPOZORN NÍ

Nov jsou avíza o uve ejn ní nových dokumentů k p íslušnému zadávacímu ízení na profilu
zadavatele zájemcům automaticky zasílána pouze v p ípad , že si zájemce stáhne z profilu
zadavatele alespoň jeden dokument (v rámci p edm tné ve ejné zakázky) jako registrovaný a
současn p ihlášený zájemce. V p ípad zájmu o účast v daném zadávacím ízení doporučuje
zadavatel stáhnout dokumentaci k ve ejné zakázce až po p ihlášení zájemce do systému.

Zadavatel má primárn v úmyslu financovat realizaci p edm tu ve ejné zakázky (vyjma
servisní podpory) z dotačních zdrojů, a to v plném rozsahu, včetn spolufinancování z fondů
Evropské unie prost ednictvím Integrovaného regionálního operačního programu (dále jen
„IROP“) v rámci specifického cíle 3.2 „Zvyšování efektivity a transparentnosti ve ejné správy
prost ednictvím rozvoje využití a kvality systémů IKT“, výzvy č. 26 eGovernment I., a to na
základ projektu s názvem "Modernizace IT FN HK v návaznosti na eHealth" s registračním
číslem CZ.06.3.05/0.0/0.0/16_034/0006163. Tím však není dotčeno zadavatelovo právo
financovat realizaci p edm tu ve ejné zakázky i z jiných zdrojů nebo prost ednictvím jejich
kombinací.

7
Zadavatel primárn p edpokládá skončení pln ní p edm tu ve ejné zakázky (vyjma servisní
podpory) ve lhůt pro realizaci akce (konečný termín stanovený poskytovatelem dotace v
rozhodnutí o poskytnutí dotace), p ičemž tato lhůta bude zkrácena o dobu jednoho m síce
(pro provedení nezbytných administrativních úkonů zadavatele). Lhůta pro pln ní p edm tu
ve ejné zakázky (vyjma servisní podpory) nebude zadavatelem stanovena delší, než:

• pro část 1: činí maximální lhůta vymezená v zadávací dokumentaci pro skončení čtvrté

etapy,

• pro část 2: 4 m síce od doručení výzvy ze strany zadavatele.

Konec lhůty pro pln ní p edm tu ve ejné zakázky (bez servisní podpory) - termín pro
akceptaci díla jako celku - bude zadavatelem stanoven p ed uzav ením smlouvy o dílo.
Zadavatel nebude v části č. 1 uplatňovat právo na pln ní z jistoty dle § 41 odst. 8 zákona,
pokud bude zadavatelem stanovená lhůta pro pln ní p edm tu ve ejné zakázky (bez servisní
podpory) v návaznosti na dotační podmínky kratší než zadavatelem (v zadávací dokumentaci)
vymezená maximální lhůta pro skončení čtvrté etapy pln ní a zadavatel z tohoto důvodu
podle § 124 odst. 2 zákona vyloučí vybraného dodavatele ze zadávacího ízení.

Zadavatel si vyhrazuje právo zrušit zadávací ízení v p ípad , že realizaci p edm tu ve ejné
zakázky (vyjma servisní podpory) nebude možné financovat z dotačních prost edků, anebo v
p ípad , kdy by i p es potencionální realizaci p edm tu ve ejné zakázky v souladu s dotačními
podmínkami nemohlo (a to s ohledem na ostatní skutečnosti) dojít k napln ní všech podmínek
vyplývajících z rozhodnutí o poskytnutí dotace (zadavatel může uplatnit vyhrazené právo
zrušit zadávací ízení nap . v situaci, kdy realizace p edm tu ve ejné zakázky v rámci části č.
2 by byla v souladu s dotačními podmínkami možná, avšak v rámci části č. 1 nikoli. V
takovém p ípad může zadavatel zrušit zadávací ízení i na část č. 2, neboť samotnou realizací
p edm tu ve ejné zakázky v rámci části č. 2 by nemohlo dojít k napln ní všech podmínek
vyplývajících z rozhodnutí o poskytnutí dotace).

Ve ejná zakázka je rozd lena na 2 části v souladu s § 35 zákona.
2 Popis p edm tu pln ní ve ejné zakázky a p edpokládaná hodnota

Popis předmětu plnění veřejné zakázky
P edm tem pln ní části 1 této ve ejné zakázky je vytvo ení moderního IS, který umožní
efektivní komunikaci a p enos informací v rámci nemocnice a mimo ní, čímž dojde ke
značnému zefektivn ní sdílení a zpracování dat. V rámci této ve ejné zakázky budou
vytvo eny technické prost edky pro zabezpečenou komunikaci s dalšími zdravotnickými
za ízeními, léka i a pacienty. Významným p ínosem projektu tak je mimo jiné podstatné
zvýšení bezpečnosti a spolehlivosti veškerých dat vznikajících v heterogenním prost edí
informačních systémů implementovaných v za ízení zadavatele p i zvýšené možnosti
komunikace s jinými specializovanými pracovišti. Zadavatel požaduje takový systém, který
bude dodavatel dále rozvíjet po dobu trvání smluvního vztahu.

P edm t ve ejné zakázky v části 1 bude zahrnovat p edevším po ízení:

1. Portálu pacienta
2. Integrační platformy včetn zhotovení komunikačních vazeb s vyjmenovanými

systémy
3. Klinického informačního systému disponujícího požadovanými vlastnostmi
4. Hardware pro provoz t chto komponentů

8
UPOZORN NÍ
V souladu s § 105 odst. 2 Zákona jsou stanoveny zadavatelem určené významné činnosti,
které mohou být pln ny pouze p ímo vybraným dodavatelem:

- vývoj, customizace a implementace dodávaného klinického informačního systému.

Dále je p edm tem části 1 p edm tné ve ejné zakázky zajišt ní servisní podpory po dobu
neurčitou od nabytí účinnosti servisní smlouvy, minimáln v rozsahu:

· 10 let pro dodaný SW, a

zajišt ní servisní podpory po dobu určitou od nabytí účinnosti servisní smlouvy, v rozsahu:
· 5 let u dodaného HW a SW dle kapitoly 4.4 pro provoz integrační platformy,
klinického informačního systému a portálu pacienta

P edm t ve ejné zakázky v části 2 bude zahrnovat p edevším po ízení zabezpečeného
dlouhodobého dův ryhodného archivu sestávajícího se z aplikační vrstvy a navazujícího
garantovaného úložišt . Realizace této části p edm tu pln ní ve ejné zakázky musí být
akceptována nejpozd ji do 4 m síců ode dne doručení výzvy k zahájení pln ní ze strany
zadavatele. Nejpozd ji do 3 m síců ode dne doručení výzvy k zahájení pln ní ze strany
zadavatele musí být zahájen zkušební provoz v reálných podmínkách v délce 1 m síce.
Zkušebním provozem se rozumí rutinní provoz systému v plném provozu, který slouží k
ov ení, že implementace prob hla zcela dle požadavků zadavatele. O p echodu do
zkušebního provozu musí být podepsán protokol o p echodu do zkušebního provozu. Na
záv r zkušebního provozu prob hne akceptace, jejímž výsledkem bude akceptační protokol.
Dále je p edm tem této části ve ejné zakázky zajišt ní servisní podpory po dobu neurčitou od
nabytí účinnosti servisní smlouvy, minimáln v rozsahu 10 let pro dodaný SW i HW pro
provoz zabezpečeného dlouhodobého dův ryhodného archivu.

Účastník bude pro obě části této zakázky povinen garantovat uložení a p ípadné zpracování
dat dle na ízení Evropského parlamentu a Rady (EU) 2016/679 , p ičemž bude povinen
zajistit, aby data neopustila území České republiky. Daty jsou mín ny osobní údaje pacientů
zadavatele a dalších osob, daty jsou dále mín ny i veškeré informace, které se účastník
v průb hu pln ní p edm tu ve ejné zakázky dozví o činnosti, struktu e a IT prost edí
zadavatele. Tato garance musí být v rámci podané nabídky uvedena formou čestného
prohlášení.

Podrobn jší specifikace p edm tu pln ní je uvedena zejména v p íloze č. 3 „Funkční
požadavky“ a v kapitole 3 této zadávací dokumentace.

Předpokládaná hodnota

Část 1
P edpokládaná hodnota za dodávku IS činí 71 553 719,01 Kč bez DPH, tj. p i sazb DPH ve
výši 21% 86 580 000,00 Kč vč. DPH. Tato hodnota je zároveň stanovena jako cena
maximáln p ípustná.

Maximáln p ípustné ceny pro jednotlivé položky (etapy) dodávaného IS jsou uvedeny
v p íslušném listu p ílohy č. 7 „Cenová tabulka“.

9
P edpokládaná hodnota za 4 roky servisní podpory činí 47 933 884,30 Kč bez DPH.
Pozn.
Servisní podpora není spolufinancována z dotačních prost edků a bude pln hrazena z
vlastních prost edků zadavatele.
P edpokládaná hodnota celé části 1 ve ejné zakázky činí 119 487 603,31 Kč bez DPH.
Upozorn ní:
Součástí hodnocení je (mimo jiné) poskytnutí servisní podpory po dobu 5 resp. 10 let (viz
blíže uvedený způsob hodnocení v rámci p íslušného listu p ílohy č. 7) s maximáln
p ípustnou cenou 111 570 247,93 Kč bez DPH.
P ekročení kterékoliv maximáln p ípustné ceny je důvodem k vyloučení účastníka z další
účasti v zadávacím ízení.
Část 2
P edpokládaná hodnota za dodávku zabezpečeného dlouhodobého dův ryhodného archivu
činí 3 719 008,26 Kč bez DPH, tj. p i sazb DPH ve výši 21% 4 500 000,00 Kč vč. DPH.
Tato hodnota je zároveň stanovena jako cena maximáln p ípustná.

P edpokládaná hodnota za 4 roky servisní podpory činí 3 305 785,12 Kč bez DPH.
Pozn.
Servisní podpora není spolufinancována z dotačních prost edků a bude pln hrazena z
vlastních prost edků zadavatele.
P edpokládaná hodnota celé části 2 ve ejné zakázky činí 7 024 793,39 Kč bez DPH.
Upozorn ní:
Součástí hodnocení je (mimo jiné) poskytnutí servisní podpory po dobu 10 let (viz blíže
uvedený způsob hodnocení v rámci p íslušného listu p ílohy č. 7) s maximáln p ípustnou
cenou 8 264 462,81 Kč bez DPH.
P ekročení kterékoliv maximáln p ípustné ceny je důvodem k vyloučení účastníka z další
účasti v zadávacím ízení.

Předpokládaná hodnota celé veřejné zakázky (obou částí) veřejné zakázky činí
126 512 396,69 Kč bez DPH.

S vít zným účastníkem bude v každé části uzav ena smlouva o dílo ve zn ní p íloh č. 4a pro
část 1, 4b pro část 2 a servisní smlouva. Požadavky na podmínky servisní smlouvy pro část 1
jsou uvedeny v kapitole 4.7 této zadávací dokumentace. Požadavky na podmínky servisní
smlouvy pro část 2 jsou uvedeny v kapitole 5.7 této zadávací dokumentace.

10
3 Popis současného stavu

Viz P íloha č. 2 - Popis současného stavu pro projekt „Modernizace IT FN HK v návaznosti
na eHealth“.

4 Požadavky na ešení část 1

Účastník ve své nabídce p edloží podrobný popis nabízeného ešení. Názvy a po adí kapitol
takto p edloženého dokumentu zadavatel požaduje ve struktu e dle této kapitoly.

4.1 Funkční požadavky

Zadavatel požaduje pokrytí funkčních požadavků uvedených v P íloze č. 3: Funkční
požadavky pro projekt „Modernizace IT FN HK v návaznosti na eHealth“.
Účastníci jsou povinni pravdiv vyplnit všechny položky uvedeného dokumentu (relevantní
pro tu část ve ejné zakázky, pro kterou podává nabídku), který musí být nedílnou součástí
p edložené nabídky.

Informace v p íloze č. 3 ve sloupci Z definuje, zda se jedná o povinný, povinný
doprogramovatelný či nepovinný požadavek dle následujícího klíče:

P – Povinný požadavek k datu podání nabídky. Jeho nespln ní znamená vyloučení
účastníka z další účasti v zadávacím ízení.

D_II – Povinný doprogramovatelný požadavek. Požadavek nemusí být spln n ke dni
podání nabídky. Zadavatel požaduje jeho spln ní k datu zahájení testovacího
provozu druhé etapy (viz kap. 4.2 ), pro jejíž funkčnost je daný požadavek
pot ebný. (Nap . funkčnost eRecept pro etapu Pilotní projekt.)

D_III – Povinný doprogramovatelný požadavek. Požadavek nemusí být spln n ke dni
podání nabídky. Zadavatel požaduje jeho spln ní k datu zahájení testovacího
provozu t etí etapy (viz kap. 4.2 ), pro jejíž funkčnost je daný požadavek
pot ebný.

D_IV – Povinný doprogramovatelný požadavek. Požadavek nemusí být spln n ke dni
podání nabídky. Zadavatel požaduje jeho spln ní k datu zahájení testovacího
provozu čtvrté etapy (viz kap. 4.2 ), pro jejíž funkčnost je daný požadavek
pot ebný.

N – Nepovinný požadavek.

Účastník vyplní u všech požadavků sloupec U p ílohy č. 3 následujícím způsobem:

· Povinné požadavky vyznačené ve sloupci Z písmenem P nabývají hodnot:
o S – Systém splňuje požadavek k datu podání nabídky
o N – Systém nesplňuje požadavek. Účastník bude vyloučen z další účasti
v zadávacím ízení!

· Povinné doprogramovatelné požadavky vyznačené ve sloupci Z počátečním písmenem
D nabývají hodnot:
o S – Systém splňuje požadavek k datu podání nabídky
o D – Systém nesplňuje požadavek k datu podaní nabídky, ale účastník se
zavazuje, že daný požadavek dodá. Zadavatel požaduje jeho spln ní k datu

11
zahájení testovacího provozu té etapy, pro jejíž funkčnost je daný požadavek
pot ebný. (nap . funkčnost eRecept pro etapu pilotní projekt). Podrobný
harmonogram realizace povinných doprogramovatelných položek bude
p edm tem Provád cího projektu.
o N – Systém nesplňuje požadavek a účastník jej ani do zahájení testovacího
provozu té etapy, pro jejíž funkčnost je daný požadavek pot ebný,
nedoprogramuje. Účastník bude vyloučen z další účasti v zadávacím ízení!
· Nepovinné požadavky (Nice to have) vyznačené ve sloupci Z písmenem N nabývají
hodnot:
o S – Systém splňuje požadavek k datu podání nabídky.
o D – Doprogramuje. Termín dodání bude určen Provád cím projektem.
o N – Systém nesplňuje požadavek. Účastník danou funkcionalitu nemá a nemá
v úmyslu ji splnit.

4.2 Realizační podmínky

Účastník v nabídce navrhne postup implementace systému vč. harmonogramu. Harmonogram
bude obsahovat minimáln p ehled hlavních aktivit definovaných v rozsahu níže
vyjmenovaných etap implementace a jejich časovou náročnost v počtu dní a časovou
chronologii.

Zadavatel požaduje dílo realizovat ve čty ech etapách:

1. První etapa – Provád cí projekt, jejíž dokončení zadavatel požaduje nejpozd ji do 6
m síců od data nabytí účinnosti smlouvy o dílo. Tato etapa bude zahrnovat minimáln
následující aktivity:

a) Zhotovení Provád cího projektu obsahujícího minimáln části v nované
projektové p íprav (projektový plán včetn definice vstupů a výstupů,
harmonogramu a položkového rozpočtu, plán kvality, plán testů, specifikace
testovacích scéná ů, plán školení apod.), analýze prost edí (analýza a vyhodnocení
uživatelských požadavků, analýza pracovních postupů a procesů apod.) a návrhu
ešení (celkový návrh ešení, logická architektura, technologická architektura,
funkční specifikace, dodávky a služby, rozhraní, implementační postupy,
bezpečnostní dokumentace – analýza a ízení rizik, zálohování, autentizace a
autorizace, bezpečnostní mechanismy apod.). Provád cí projekt tedy detailn
popíše jednotlivé projektové aktivity, které logicky povedou k cílům projektu, tedy
realizaci p edm tu pln ní jako celku. V rámci zpracování analýzy a popisu
způsobu ízení rizik v Provád cím projektu použije účastník jím navrženou
metodiku a navrhne způsob p edávání identifikovaných rizik zadavateli.

b) Oponentury zadavatele. Zadavatel p edpokládá min. dv kola oponentur návrhu
provád cího projektu, které začnou od 5. m síce po nabytí účinnosti smlouvy o
dílo. Na každou oponenturu si zadavatel vyhrazuje min. 14 dnů.

c) Akceptaci první etapy. Výstupem akceptace bude akceptační protokol podepsaný
zadavatelem, který bude zároveň podkladem pro fakturaci ceny této etapy.

2. Druhá etapa - Implementace integrační platformy včetn vybudování pot ebných
vazeb a implementace KISu – vše v rozsahu pilotního projektu. Zadavatel požaduje,
aby pilotní projekt prob hl na 3 klinikách, které určí zadavatel v rámci Provád cího

12
projektu. Tato etapa pln ní začne akceptací první etapy a skončí nejpozd ji do konce
15. m síce od data nabytí účinnosti smlouvy o dílo.
Tato etapa bude obsahovat minimáln :

a) Dodávku HW pot ebného pro b h KISu a integrační platformy, instalaci
základního systémového SW (virtualizační platforma, operační systémy všech
serverů, databáze) včetn implementace.

b) Instalaci integrační platformy, instalaci KIS. Vše v rozsahu pot ebném pro pilotní
projekt

c) Vývoj, customizaci, implementaci
d) Vybudování pot ebných integrací s využitím integrační platformy
e) Migraci dat pro testovací provoz pracovišť zadavatele za azených do pilotního

projektu
f) Školení uživatelů klinik za azených do pilotního projektu
g) Testovací provoz
h) Migraci dat pro zkušební provoz klinik za azených do pilotního projektu
i) Zkušební provoz klinik za azených do pilotního projektu
j) Technickou podporu od zahájení zkušebního provozu do akceptace díla jako celku.

(Technická podpora bude poskytována na všechny části díla, které budou v rámci
všech budoucích etap dodány.)
k) Akceptaci druhé etapy. Výstupem bude akceptační protokol podepsaný
zadavatelem, který bude zároveň podkladem pro fakturaci ceny této etapy.

3. T etí etapa – Rollout. Rollout prob hne jako opakující se proces, a to postupn po
skupinách pracovišť zadavatele. Způsob provád ní rolloutu určí Provád cí projekt.
Tato etapa pln ní začne nejd íve po akceptaci druhé etapy pln ní a skončí nejpozd ji
do konce 22. m síce od data nabytí účinnosti smlouvy o dílo.
Tato etapa bude obsahovat minimáln :

a) P ípadnou dodávku dalšího HW a SW pro serverovny
b) Vývoj, customizaci, implementaci
c) Rollout KISu
a) Dobudování integrací s využitím integrační platformy
b) Školení uživatelů
c) Testovací provoz pro jednotlivé skupiny
d) Migraci dat pro zkušební provoz pro jednotlivé skupiny
e) Zkušební provoz pro jednotlivé skupiny
f) Dílčí akceptace pro jednotlivé skupiny
g) Akceptaci t etí etapy. Výstupem akceptace bude akceptační protokol podepsaný

zadavatelem, který bude zároveň podkladem pro fakturaci ceny této etapy pln ní.

4. Čtvrtá etapa – Dodávka a implementace portálu pacienta včetn integrací. Tato etapa
pln ní začne nejd íve po akceptaci druhé etapy pln ní a skončí nejpozd ji do konce
22. m síce od data nabytí účinnosti smlouvy o dílo.
Tato etapa bude obsahovat minimáln :

a) Dodávku a implementaci HW a SW portálu pacienta včetn integrací
b) Školení používání portálu pacienta, včetn jeho administrace,

13
c) Testovací provoz
d) Dobudování všech chyb jících funkcionalit
e) Zkušební provoz
f) Akceptaci čtvrté etapy. Výstupem akceptace bude akceptační protokol podepsaný

zadavatelem, který bude zároveň podkladem pro fakturaci ceny této etapy pln ní.

Po ukončení všech čty etap prob hne akceptace části 1 zakázky. Výstupem bude akceptační
protokol podepsaný zadavatelem, který bude zároveň podkladem pro fakturaci cílové
odm ny.
4.3 Požadavky na vlastnosti systému v oblasti bezpečnosti

Účastník v nabídce popíše způsob zajišt ní bezpečnosti a doporučený způsob kontroly.
Národní ú ad pro kybernetickou a informační bezpečnost podle § 22a odst. 1 zákona č.
181/2014 Sb., o kybernetické bezpečnosti a o zm n souvisejících zákonů (zákon o
kybernetické bezpečnosti), ve zn ní pozd jších p edpisů, v ízení ve v ci určení Fakultní
nemocnice Hradec Králové rozhodl, že Fakultní nemocnice Hradec Králové je
provozovatelem základní služby: Poskytování zdravotních služeb. Informační systém, na
kterém je tato služba závislá, je informačním systémem základní služby.
Dodávka IS, jeho nasazení, migrace dat a zabezpečení p i provozu i údržb musí být v
souladu se zákonem č. 181/2014 Sb. (zákon o kybernetické bezpečnosti) v aktuálním zn ní a
vyhlášky č. 82/2018 Sb. (vyhláška o kybernetické bezpečnosti) v aktuální zn ní a
navazujícími právními p edpisy.
Dodavatel systému bude z hlediska kybernetické bezpečnosti za azen jako významný
dodavatel zadavatele.
Detailní požadavky na bezpečnost jednotlivých komponent systémů jsou uvedeny
v p íloze č. 3.

4.4 Dodávka nezbytné HW a SW infrastruktury

Zadavatel požaduje, aby technologie nezbytné pro realizaci p edm tu pln ní ve ejné zakázky
(dle účastníkem navrženého způsobu ešení) byly nedílnou součástí dodávky systému včetn
detailní specifikace a popisu jejich začlen ní do stávajícího ICT prost edí zadavatele.
Účastník ve své nabídce specifikuje, na jakém optimálním hardware bude u zadavatele jeho
systém provozován. Uvede tedy sizing navrhovaných serverů a navrhne konkrétní technickou
specifikaci. Součásti p edm tu pln ní je i dodávka provozní infrastruktury včetn p ípadných
komponent zajišťujících kompatibilitu s IT infrastrukturou zadavatele.
Všechny dodávané komponenty budou nové, nerepasované.

· Účastník musí specifikovat v nabídce název výrobce, označení nabízeného HW a SW,
u kterého uvede verzi a typ licence.

· Účastník musí specifikovat v nabídce technologické prost edí pro provoz nabízeného
systému (hardware, systémový software, nároky na síťovou komunikaci, bezpečnostní
a provozní opat ení).

14
· Účastník je povinen ve své nabídce uvést sizing serveru(ů) pro jím navrhovaný
systém. Navržený sizing bude obsahovat počet a typ doporučených procesorů, velikost
RAM a interní diskový prostor serveru(ů) a bude dostatečný pro provoz po dobu 5 let
provozu. Účastník dále navrhne typ a verzi operačního systému a databáze.

· Zadavatel požaduje dodat redundantní ešení nezávislé na výpadku jednoho fyzického
serveru, jednoho provozního úložišt , jedné instance databáze, vše s recovery time
objective (dále RTO) max. 5 min (stanovená mez RTO se vztahuje na obnovu funkce
dodaného SW vybavení a serverových HW technologií).

· Zadavatel požaduje, aby navrhovaný systém byl provozován na infrastruktu e
automaticky odolné proti výpadku jedné serverovny. Navrhovaný systém musí
umožnit realizaci vysoké dostupnosti minimáln formou Active/Passive clusteru.

· Zadavatel neposkytne pro poptávaný projekt žádné licence pro virtualizaci, systémový
SW, databázové licence, hardware mimo stávajících pracovních stanic a úložné
kapacity definované v následujícím bod apod. Součástí požadované dodávky je tedy
kompletní provozní infrastruktura pro nasazované ešení. Zadavatel požaduje
vybudovat samostatnou farmu včetn pot ebného licenčního pokrytí pro celé
navrhované ešení. Zadavatel provozuje virtuální infrastrukturu VMware ESX 6
(stávající licence jsou 2 x vCenter Standard) s HA a diskové úložišt HP 3PAR.
Zadavatel preferuje provoz v tomto prost edí. Zadavatel p ipouští dodání jakýchkoliv
licencí, které splňují všechny licenční podmínky definované firmou VMware pro FN
HK. Zadavatel za účelem realizace p edm tu pln ní umožní užití licencí Microsoft
Win Svr CAL DvcCAL a Win Svr CAL UsrCAL již zadavatelem vlastn ných.

· Aktivní síťové prvky a SAN nejsou p edm tem dodávky, konektivitu poskytne
zadavatel.

· Zadavatel poskytne pro pot eby nového IS maximáln tuto konektivitu:
o v serverovn v budov č. 24 10x port v 16Gb Fabricu a 10x port v 8Gb Fabricu
o v serverovn v budov č. 12 10x port v 16Gb Fabricu a 10x port v 8Gb Fabricu
o v serverovn v budov č.24 je k dispozici 10 + 10 portů 1000/10000 Ethernet
10GBASE-T, tedy je k dispozici 10 p ipojení ke každému ze dvou switchů
CISCO Nexus.
o v serverovn v budov č.12 je k dispozici 10 + 10 portů 1000/10000 Ethernet
10GBASE-T, tedy je k dispozici 10 p ipojení ke každému ze dvou switchů
CISCO Nexus. "
Účastník nebude mít administrátorský p ístup do SAN infrastruktury. P ípadné
požadavky na konfigurace (nap . zónování) p edá účastník zadavateli a ten je po
dohod provede. Za provoz SAN jako celku zodpovídá zadavatel. Účastník
zodpovídá pouze za funkčnost jím dodaných SAN komponent.

· Zadavatel poskytne úložnou kapacitu na polích HP 3PAR ve výši max. 3TB pro
uložení dat dodaných systémů na 5 let provozu od akceptace t etí etapy
s garantovaným výkonem 3k IOPS v SAS vrstv pro random R/W mix 60/40, 64 KB.
Data uložená v tomto prostoru budou replikována mezi ob ma serverovnami
zadavatele. Pokud účastníkovi (v rámci jím nabízeného ešení) tento prostor nebude
stačit, p ipouští zadavatel rozší ení stávající konfigurace polí zadavatele ze strany
tohoto účastníka. Zadavatel sd luje, že nemá žádné volné diskové sloty. V
rozvad čích HP 3PAR je volný prostor 16U v každé z obou serveroven. Do tohoto
prostoru lze umístit další police s disky. Takovéto rozší ení musí být zahrnuto do
celkové nabídkové ceny účastníka. Od 6. roku hradí rozší ení diskového prostoru
zadavatel. Účastník uvede velikost požadovaných diskových prostor pro 2 roky
provozu; dále musí být uveden p edpokládaný p írůstek dat pro 3. až 5. rok provozu

15
od akceptace t etí etapy.

Pro zálohování má zadavatel p ipravenou následující volnou kapacitu:

o Maximáln 10TB prostoru pro D2D zálohování na diskových polích

zadavatele.

o Maximáln 20 pásek LTO6 pro D2D2T zálohování.

Pokud účastník navrhne rozší ení stávajícího za ízení HP 3PAR, je provozuschopnost
celého za ízení v odpov dnosti zadavatele a účastník ručí jen za jím dodané
komponenty.

· Pokud budou součástí nabídky licence na produkty firmy Microsoft, zadavatel sd luje,
že je v této oblasti smluvn vázán Microsoft Select - cenová kategorie D.

Kontakt:

Ministerstvo vnitra

editel odboru kybernetické bezpečnosti a koordinace informačních a komunikačních
technologií

fax: +420 974 816 209

ID datové schránky: 6bnaawp

· Pokud budou součástí nabídky licence na produkty firmy VMware, zadavatel sd luje,
že je v této oblasti smluvn vázán kontraktem s Ministerstvem vnitra.

Kontakt:

Ministerstvo vnitra

editel odboru kybernetické bezpečnosti a koordinace informačních a komunikačních
technologií

fax: +420 974 816 209

ID datové schránky: 6bnaawp

· Pokud budou součástí nabídky licence na produkty firmy IBM, zadavatel sd luje, že je
v této oblasti smluvn vázán kontraktem s Ministerstvem vnitra.

Kontakt:

Ministerstvo vnitra

editel odboru kybernetické bezpečnosti a koordinace informačních a komunikačních
technologií

fax: +420 974 816 209

· Zadavatel požaduje dodat takový systém, který je pln provozuschopný na jeho

stávajících pracovních stanicích a monitorech popsaných v p íloze č. 2. Systém musí
být pln provozuschopný i na monitorech 23,8“ s pom rem stran 16:9 a rozlišením

1920x1080 bodů p i frekvenci minimáln 60Hz.

· P edm tem dodávky není dodávka bezpečnostních p edm tů (čipových karet resp.
tokenů), kvalifikovaných certifikátů ani kvalifikovaných časových razítek.
.

4.5 Integrační požadavky

Účastník musí vytvo it integrační vrstvy včetn konektorů (aplikačních protokolů) na vybrané
systémy požadované zadavatelem. Minimální požadavky na integrační platformu včetn
popisu minimáln požadovaných vazeb jsou uvedeny v P íloze č. 3: Funkční požadavky pro
projekt „Modernizace IT FN HK v návaznosti na eHealth“.
Účastník do nabídky vyplní p íslušnou kapitolu v p íloze č.3 a popíše nabízenou technologii.

16
4.6 Požadavky na migraci dat

Účastník musí v rámci pln ní p edm tu ve ejné zakázky zajistit pln na vlastní náklady
migraci dat ze stávajícího systému AMIS*H. Zadavatel poskytne vybranému dodavateli
nezbytnou součinnost, a to v rozsahu odpovídajícím pro napln ní povinností zadavatele, jež
jsou stanoveny v P íloze č. 3 „Podmínky migrace dat“ Smlouvy o dílo.
Účastník do nabídky navrhne způsob migrace formou plánu migrace, z kterého musí být
zadavatel schopen posoudit způsob provedení migrace dat včetn časové posloupnosti
jednotlivých činností, p ičemž plán migrace bude obsahovat minimáln :

a) Harmonogram konkrétních činností, které budou v rámci migrace dat provedeny, s
uvedením jejich časové posloupnosti.

b) Popis struktury pracovního týmu, který se za zhotovitele bude podílet na migraci
dat, a to včetn uvedení odpov dnosti jednotlivých členů tohoto pracovního týmu
za konkrétní části migrace dat.

Účastník provede migraci dat jako součást implementace.
Účastník poskytne podporu pro zajišt ní kontinuity provozu p i p echodu ze stávajícího
systému do nového systému (nap . automatizovaný export obložnosti lůžek, statistických
výkazů).
Podrobnosti viz p íloha č. 3, kap. 5.

4.7 Servisní podmínky

Součástí nabídky účastníka pro část 1 musí být návrh servisní smlouvy na poskytování
servisní podpory po akceptaci díla jako celku (a to tak, že servisní podpora dle servisní
smlouvy bezprost edn naváže na technickou podporu poskytovanou v rámci pln ní
p edm tu smlouvy o dílo do okamžiku akceptace díla jako celku. Návrh servisní smlouvy
bude respektovat minimáln požadavky zadavatele stanovené v bodech 4.7 a 7 této
zadávací dokumentace.

Vzhledem k významu poptávaného IS pro chod zadavatele považuje zadavatel za
minimální akceptovatelnou úroveň servisního zabezpečení následující požadavky.
Všechny níže uvedené požadavky musí být zapracovány do návrhu servisní smlouvy.

4.7.1 Obecné servisní podmínky

Definice pojmů

1. Pojmem „update“ se v servisní smlouv rozumí taková verze servisovaného p edm tu
pln ní či jeho části, u které se oproti p edcházející verzi tohoto servisovaného p edm tu či
jeho části m ní jeho funkčnost, a to na základ zm ny jakékoliv skutečnosti, podle které
byla celá funkčnost tohoto servisovaného p edm tu či jeho části vytvo ena. Update zaručí
p edevším funkčnost systému, jeho bezpečnost a včasnou reakci na zm ny právních
p edpisů publikovaných nebo oznámených ve Sbírce zákonu a Sbírce mezinárodních
smluv České republiky (včetn Metodiky pro po izování a p edávání dokladů VZP a
jiných obdobných p edpisů), dále pak ve ejn dostupné zm ny platné pro provoz
zadavatele. V p ípad , že zm na funkčnosti tohoto servisovaného p edm tu byla
17
provedena pouze na základ legislativních zm n, je nová verze tohoto servisovaného
p edm tu jeho “legislativním updatem”. Implementace/instalace t chto zm n do IT
prost edí zadavatele, včetn zaškolení p íslušných zam stnanců zadavatele na vyžádání
zadavatele, je součástí p edm tu servisní smlouvy.
2. Pojmem „upgrade“ se v servisní smlouv rozumí taková verze servisovaného p edm tu, u
které se oproti p edcházející verzi tohoto servisovaného p edm tu či jeho části m ní její
funkčnost, a to na základ zm ny jakékoliv skutečnosti, podle které byla celá funkčnost
tohoto servisovaného p edm tu či jeho části vytvo ena a dochází ke zm n verze. Upgrade
zaručí p edevším funkčnost systému, jeho bezpečnost a včasnou reakci na zm ny právních
p edpisů publikovaných nebo oznámených ve Sbírce zákonu a Sbírce mezinárodních
smluv České republiky (včetn Metodiky pro po izování a p edávání dokladů VZP a
jiných obdobných p edpisů), dále pak ve ejn dostupné zm ny platné pro provoz
zadavatele. V p ípad , že zm na funkčnosti tohoto servisovaného p edm tu či jeho části
byla provedena pouze na základ legislativních zm n, je nová verze tohoto servisovaného
p edm tu či jeho části jeho “legislativním upgradem”. Implementace/instalace t chto
zm n do IT prost edí zadavatele, včetn zaškolení p íslušných zam stnanců zadavatele na
vyžádání zadavatele, je součástí p edm tu servisní smlouvy.
3. Pojmem „Helpdesk“ se rozumí kontaktní místo, které musí být schopno p ijímat
požadavky na odstran ní vad, nedod lků a rozvojových požadavků.
4. Pojmem „Hotline“ se rozumí telefonní linka pro bezprost ední poskytnutí odborného
poradenství k dodanému servisovanému p edm tu pln ní či jeho části, uživatelům a
správcům zadavatele.

Obecné požadavky Helpdesk

1. Helpdesk musí být dostupný v českém jazyce.

2. Účastník garantuje uložení dat dle na ízení Evropského parlamentu a Rady (EU) 2016/679
a dále garantuje, že data neopustí území ČR. Daty jsou mín ny osobní údaje pacientů
zadavatele a dalších osob, daty jsou dále mín ny i veškeré informace, které se účastník
v průb hu pln ní p edm tu ve ejné zakázky dozví o činnosti, struktu e a IT prost edí
zadavatele. Zadavatel má právo 1x ročn po dobu trvání servisní smlouvy a následn 5 let
po jejím zániku požadovat informaci o míst uložení dat HelpDesku.

3. V Helpdesku musí být možno zaznamenat termín ešení a aktuální stav ešení požadavku.

4. Helpdesk musí umožnit filtrovat požadavky dle zadaných parametrů (nap . dle aktuálního
stavu, dle termínu ešení, ešitele, atd.).

5. Helpdesk účastníka musí být schopen p ijímat rozvojové požadavky a požadavky na
odstran ní vad, a to minimáln v rozsahu kategorií vad a priorit rozvojových požadavků
uvedených níže.

6. Helpdesk musí umožnovat p íjem požadavků minimáln t mito způsoby:
a) na telefonním čísle: ___________ v režimu 24x7x365 musí být zajišt na lidskou
obsluhou
b) na webové adrese: ___________ v režimu 24x7x365
c) na e-mailové adrese: ___________ v režimu 24x7x365

7. Zadavatel požaduje potvrzení p ijetí požadavku v rámci Helpdesku do 15 minut.

18
Kategorie Helpdesk požadavků

1. Proces odstraňování vad p edm tu pln ní či částí p edm tu pln ní díla bude probíhat v
t chto kategoriích:

Porucha
Jedná se o stav, kdy je servisovaný p edm t pln ní či jeho část zcela nefunkční, tzn. že
se vyskytnou vady zabraňující provozu servisovaného p edm tu pln ní či jeho části; v
důsledku t chto vad není servisovaný p edm t pln ní či jeho část použitelný ve svých
základních funkcích nebo se vyskytuje funkční závada znemožňující činnost
servisovaného p edm tu pln ní či jeho části. Za poruchu se považuje i taková
nefunkčnost servisovaného p edm tu pln ní či jeho části, která zásadním způsobem
omezí b žný provoz zadavatele.

Závada
Jedná se o stav, kdy nefunguje n která část servisovaného p edm tu pln ní či jeho
části, ale servisovaný p edm t pln ní či jeho část/i je omezen použitelný, tzn. že tyto
vady omezují provoz servisovaného p edm tu pln ní či jeho části do té míry, že
funkčnost servisovaného p edm tu pln ní či jeho části je ve svých funkcích
degradována tak, že tento stav omezuje v daném čase b žný provoz dodaného díla,
p ičemž servisovaný p edm t pln ní či jeho část je použitelný ve svých základních
funkcích.

Ostatní vady
Jedná se o stav, kdy nefunguje n která část servisovaného p edm tu pln ní či jeho
části, p ičemž tyto vady neomezují b žný provoz servisovaného p edm tu pln ní či
jeho části.

Za azení vady p edm tu pln ní do konkrétní kategorie bude závazn určovat zadavatel
a účastník je povinen jej pln respektovat.

2. Helpdesk účastníka musí být schopen p ijímat rozvojové požadavky zadavatele dle priorit
minimáln v rozsahu (vysoká, st ední, malá) a umožnit u nich zapsat požadovaný termín
ešení.

3. Rozvojové požadavky budou realizovány na základ samostatných objednávek
zadavatele. Objednávky budou vystaveny po odsouhlasení návrhu realizace, který bude
obsahovat rozpočet a harmonogram.

Hotline

1. Účastník je v rámci servisní podpory povinen zajistit funkci hotline v českém jazyce pro
poradenství v pracovní dny vždy od 8.00 do 16.30 hod.

Ostatní servisní podmínky
1. Účastník uvede cenu za servisní podporu za jeden rok, a to včetn rozkladu na položky,

typicky jednotlivé servisní služby.

19
2. Účastník je povinen provád t práce a činnosti pln kvalifikovanými pracovníky
s dostatkem odborných zkušeností. Za jejich práci nese odpov dnost dle ustanovení
zákona č. 89/2012 Sb., občanského zákoníku, v platném zn ní.

3. Účastník je povinen provád t servisní činnost v souladu s ustanovením § 64 a násl. zákona
č. 268/2014 Sb. o zdravotnických prost edcích, v platném zn ní.

4. Nástup na ešení poruchy nebo závady je vyžadován max. do 4 hodin u zadavatele nebo
vzdáleným p ístupem do 1 hodiny od nahlášení závady nebo poruchy.

5. Zadavatel požaduje do smlouvy zahrnout smluvní ujednání o podmínkách a způsobu
podpory implementovaného systému nad rámec sjednané servisní podpory. Účastník
uvede cenu za hodinu práce (konzultant, senior konzultant, analytik, programátor) nad
rámec výše definovaných paušálů, a to v pracovní den v obvyklou pracovní dobu, v
nočních hodinách, o víkendu a o svátcích. Cena pro každou kategorii pracovníků bude
v max. výši 2000 Kč bez DPH za hodinu v b žnou pracovní dobu. V cen musí být
zahrnuty všechny související náklady, zejména cestovné, ztráta času na cest apod.

6. Pro vzdálený p ístup zadavatel požaduje využít stávající infrastrukturu zadavatele,
založenou na p ístupech p es VPN koncentrátory, které jsou vlastn ny zadavatelem.
P ístup z důvodu správy na server(y) bude realizován standartními prost edky a postupy
(RDP, SSH apod.).
· Požadavek na konkrétní otev ení brány bude účastník sm rovat na HelpDesk
zadavatele, a to buď telefonicky (495 834 443) nebo e-mailem
(helpdesk@fnhk.cz).
· P ipojení bude používáno pouze k účelům definovaným v žádosti a pouze na dobu
nezbytn nutnou k provedení p íslušných prací.
· P ipojení pro plánované akce musí být dohodnuto v dostatečném p edstihu
(minimáln 2 pracovní dny p edem, pokud se odpov dná osoba účastníka a
odpov dná osoba zadavatele nedohodnou jinak), a to s p ihlédnutím k
minimalizaci vlivu p ipojení na provoz zadavatele. Odpov dná osoba zadavatele
má právo odmítnout nebo odložit vzdálené p ipojení.
· P ipojení v rámci neplánované urgentní akce (porucha, provozní problém,
konzultace) bude umožn no po dohod účastníka a odpov dné osoby zadavatele
nebo osoby sloužící pohotovostní službu zadavatele.
· Skutečnost, že vzdálené p ipojení již nebude používáno a je možné ho ukončit
(tedy typicky že pot ebné práce již byly dokončeny), účastník neprodlen nahlásí
tomu odpov dnému zam stnanci zadavatele, se kterým daný p ípad komunikuje.
· O chystaných pracích (nap . nasazení nových verzí, zm nách nastavení,
importu/exportu dat apod.) je účastník povinen informovat zam stnance
odpov dného za pln ní smlouvy za zhotovitele (forma emailu je dostatečná).
Stejn tak účastník informuje o výsledku a ukončení t chto prací.
· Každý vstup p es vzdálené p ipojení bude logován a logy následn archivovány.

7. Nebude-li Helpdesk dostupný v režimu 24x7x365, bude zadavatel oprávn n uplatnit vůči
účastníkovi smluvní pokutu 5.000 Kč za každý jednotlivý p ípad nedostupnosti zvlášť. Za
nedostupný nebude Helpdesk považován v p ípad , bude-li účastníkem provád na
odstávka webových stránek, které tvo í součást Helpdesku (zejména za účelem pravidelné

20
údržby t chto webových stránek), a to za podmínky, že tyto odstávky budou provád ny
nanejvýš 4krát ročn , každá z t chto odstávek nebude trvat déle než 4 hodiny, zadavatel
bude účastníkem informován prost ednictvím t chto webových stránek o plánované
odstávce vždy nejmén 2 pracovní dny p edem, a to konkrétn o termínu a časech začátku
a ukončení odstávky. V p ípad telefonického kanálu Helpdesk je tolerovaná krátkodobá
nedostupnost 5 minut z důvodu nezvednutí, nebo obsazení telefonního čísla.

8. Smluvní pokuty uplatňované zadavatelem vůči účastníkovi nesmí být jakkoli snižovány či
limitovány.

9. Dostane-li se zadavatel do prodlení s úhradou ceny poskytovaných služeb, bude účastník
oprávn n mu účtovat úrok z prodlení maximáln ve výši 0,025 % z dlužné částky za
každý den prodlení. Účastník nebude oprávn n uplatňovat vůči zadavateli jakékoli jiné
smluvní pokuty, penále či jiné sankce.

10. Smluvní cena za servis bude zadavatelem hrazena měsíčně, a to vždy po uplynutí daného
kalendářního měsíce.

11. Účastník je povinen poskytnout v rámci servisní podpory bezplatn zadavateli update či
upgrade všech dodaných SW, který je p edm tem dodávky systému dle požadavků této
zadávací dokumentace. Tímto způsobem se zaručí p edevším funkčnost systému, jeho
bezpečnost a včasná reakce na zm ny právních p edpisů publikovaných nebo oznámených
ve Sbírce zákonu a Sbírce mezinárodních smluv České republiky, dále pak ve ejn
dostupné zm ny platné pro servisovaný p edm t pln ní a nebo provoz FN HK. V p ípad ,
kdy nebude možné dodržet zákonný termín, bude zadavatel s p im eným p edstihem
vyzván k písemné dohod o termínu dodání úpravy. Zadavatel požaduje, aby součástí
servisní podpory (servisního paušálu) byla i implementace/instalace t chto zm n do
servisovaného p edm tu pln ní.
Účastník poskytuje zadavateli záruku, že poskytovaná servisní podpora bude prostá
jakýchkoliv vad v cných, právních i ostatních a servisovaný p edm t pln ní a každá
jeho část bude mít vlastnosti výslovn stanovené smlouvou o dílo, zadávací
dokumentací ve ejné zakázky, nabídkou účastníka, norem a ostatních p edpisů po
celou dobu platnosti servisní smlouvy. Sjednaná záruka se vztahuje také na p ípadný
update a upgrade realizovaný účastníkem, či další rozvoj nebo úpravy díla či jeho
části. Po dobu poskytování servisní podpory dle servisní smlouvy je rozsah garance
vztahující se k servisovanému p edm tu pln ní, či jeho části, neomezený, což znamená
zejména, že servisovaný p edm t pln ní bude prostý jakýchkoliv vad bez ohledu na
skutečnost, zda se jedná o vadu skrytou nebo zjevnou, která mohla být ze strany
zadavatele identifikována v dob p ed datem p edání p íslušné části díla či díla jako
celku, jeho updatu, upgradu či rozvoje. V p ípad ukončení servisní smlouvy nebo její
části je účastník povinen poskytnout 12 m síční záruku na servisovaný p edm t pln ní
či jeho část, a to ode dne ukončení servisní podpory na dodaný IS nebo jeho část,
s výjimkou HW. Záruka se vztahuje na vady resp. nedod lky, které se projeví b hem
záruční doby s výjimkou vad, u nichž účastník prokáže, že jejich vznik zap íčinil
zadavatel. Doba pro odstran ní nahlášených vad se po dobu záruky ídí stejnými
podmínkami, které jsou platné pro odstraňování vad dle servisní smlouvy. Reklamaci
lze uplatnit do posledního dne záruční doby, p ičemž i reklamace odeslaná
zadavatelem v poslední den záruční doby se považuje za včas uplatn nou.

21
12. Každá významná zm na systému musí být dokumentována, a to minimáln vydáním
zprávy o zm n systému a zm nou kontextové nápov dy. Každá zm na systému musí být
účastníkem p ed instalací do produkčního prost edí otestována. Testy nesm jí probíhat na
produkčním prost edí. Akceptace musí být součástí dokumentace každé zm ny SW (nap .
záznam v helpdesku, akceptační protokol apod.). Dokumentace k významné zm n musí
být dodána nejpozd ji do 10 dnů ode dne akceptace.

13. Vzhledem k tomu, že systém obsahuje osobní údaje vysokého počtu fyzických osob, a to
p edevším údaje zvláštního charakteru (citlivé), zaručí se, že jeho zam stnanci,
provád jící servis, budou vázáni mlčenlivostí o obsahu osobních údajů obsažených v
systému, se kterými p ijdou p i své činnosti do styku. Dále se zaváže, že jeho zam stnanci
nep edají osobní údaje v systému obsažené jiné právnické nebo fyzické osob bez
p edchozího souhlasu zadavatele. Po p ípadném ukončení servisní smlouvy vymaže
účastník všechny osobní údaje u n j uložené a umožní zadavateli nebo jím pov enému
auditorovi kontrolu opat ení k ochran osobních údajů.

14. Pokud účastník nep ijme bezpečnostní opat ení za účelem ochrany dův rných informací
týkajících se objednatele, poruší-li účastník povinnou mlčenlivost ohledn dův rných
informací, bude zadavatel oprávn n vyúčtovat účastníkovi jednorázovou smluvní pokutu
ve výši 3.000.000,- Kč (slovy t i miliony korun českých), a to za každý takový p ípad
zvlášť.

15. Zaplacením smluvní pokuty nebude dotčen nárok zadavatele na náhradu škody způsobené
porušením povinností účastníka. Zadavatel bude mít nárok na náhradu škody v plné výši,
tzn. že uhrazená smluvní pokuta se na náhradu škody nezapočítává.

4.7.2 Ostatní servisní podmínky a sankce pro část 1

1. Servisní smlouva bude uzav ena na dobu neurčitou, s výjimkou servisní podpory na HW a
SW t etích stran dodaných dle kapitoly 4.4 (viz kapitola 4.7 článek „Ostatní servisní
podmínky a sankce“ odstavec 34), kde servisní podpora bude uzav ena na dobu 5 let.
Servisní smlouva nabude účinnosti okamžikem celkové akceptace díla s tím, že servisní
podpora dle servisní smlouvy bude zadavateli poskytována ode dne účinnosti této
smlouvy (s výjimkou odstraňování vad a nedod lků, které budou po dobu záruční doby
odstraňovány dle smlouvy o dílo).
Smluvní strany jsou oprávn ny platnost této smlouvy nebo její části jednostrann ukončit
písemnou výpov dí s výpov dní dobou v délce 18 m síců, která počne b žet prvním dnem
m síce následujícího po doručení písemné výpov di druhé smluvní stran . Účastník bude
oprávn n vypov d t servisní smlouvu, resp. servisní podporu jednotlivé části či
jednotlivých částí informačního systému, nejd íve po uplynutí 10 let od data nabytí
účinnosti této smlouvy, a to za podmínek stanovených níže, není-li v této zadávací
dokumentaci dále stanoveno jinak.
Po uplynutí 10 let od data nabytí účinnosti této smlouvy je účastník oprávn n vypov d t
servisní podporu klinického informačního systému pouze v p ípad :
a) ukončení servisní podpory klinického informačního systému na trhu (tj. bude-li v této
dob životní cyklus dodaného klinického informačního systému ukončen, a to pouze

22
na základ vydaného oficiálního rozhodnutí výrobce klinického informačního systému
o ukončení servisní podpory tohoto systému),
b) v p ípad , že účastník vstoupí do likvidace nebo bude-li v p ípad účastníka soudem
prohlášen úpadek, pop . podá-li účastník na sebe, jakožto dlužník, insolvenční návrh.
Po uplynutí 10 let od data nabytí účinnosti této smlouvy je účastník oprávn n vypov d t
servisní podporu portálu pacienta pouze v p ípad ukončení podpory dodaného klinického
informačního systému.
Po uplynutí 10 let od data nabytí účinnosti této smlouvy je účastník oprávn n vypov d t
servisní podporu integrační platformy pouze v p ípad :
a) ukončení servisní podpory dodané integrační platformy na trhu (tj. bude-li v této dob
životní cyklus dodané integrační platformy ukončen, a to pouze na základ oficiálního
oznámení výrobce o ukončení podpory integrační platformy),
b) v p ípad , že účastník vstoupí do likvidace nebo bude-li v p ípad účastníka soudem
prohlášen úpadek.

V p ípad ukončení servisní podpory dodané integrační platformy d íve než po uplynutí
lhůty 10 let je účastník povinen zajistit kontinuitu ešení zdarma (dodávka nové integrační
platformy včetn implementace a migrace všech stávajících vazeb).
Servisní podporu na HW a SW t etích stran dodaných dle kapitoly 4.4

Zadavatel je oprávn n vypov d t servisní smlouvu v celém jejím rozsahu nebo vypov d t
servisní podporu jednotlivých částí informačního systému bez udání důvodu, a to kdykoli
v průb hu doby platnosti servisní smlouvy.
Pokud by se kterékoliv ustanovení Smlouvy ukázalo být neplatným z důvodu rozporu s
kogentním ustanovením obecn závazných právních p edpisů, pak tato skutečnost působí
neplatnost pouze tohoto konkrétního ustanovení, pokud je odd litelné od ostatního obsahu
Smlouvy. Smluvní strany se zavazují takové neplatné ustanovení nahradit dohodou svým
obsahem nejbližší duchu takového neplatného ustanovení respektující požadavky
kogentních ustanovení právních p edpisů.

Tuto Smlouvu lze m nit, upravovat a doplňovat pouze formou písemných, vzestupn
číslovaných dodatků, odsouhlasených a podepsaných ob ma Smluvními stranami,
p ičemž podpisy obou Smluvních stran musí být na téže listin . Tyto dodatky se stávají
nedílnou součástí Smlouvy.
Veškeré spory vzešlé z této smlouvy či se jakkoli dotýkající práv a povinností
vyplývajících ze závazkového vztahu dle této smlouvy budou smluvními stranami ešeny
smírnou cestou. Nepoda í-li se tímto způsobem spor vy ešit, budou tyto spory ešeny p ed
v cn a místn p íslušnými českými soudy.

Vztahy vznikající ze smlouvy a v ní výslovn neupravené se ídí Právním ádem ČR,
zejména pak p íslušnými ustanoveními občanského zákoníku
Účastník nesmí bez p edchozího písemného souhlasu zadavatele postoupit svá práva a
povinnosti plynoucí z této smlouvy t etí osob .

23
2. Účastník se smluvn zaváže, že požadavky s kategorií poruchy odstraní do 8 hodin od
okamžiku nahlášení poruchy zadavatelem, pokud se smluvní strany nedohodnou jinak.
Pokud požadavek s kategorií poruchy nebude odstran n do 8 hodin od okamžiku
nahlášení zadavatelem nebo v jiné sjednané lhůt , je zadavatel oprávn n uplatnit vůči
účastníkovi smluvní pokutu 10.000 Kč za každou hodinu, kdy systém není funkční.

3. Nebude-li zahájeno ešení požadavku s kategorií poruchy ve stanovené lhůt , je zadavatel
oprávn n uplatnit vůči účastníkovi jednorázovou smluvní pokutu 50.000 Kč za každý
jednotlivý p ípad zvlášť.

4. Účastník se smluvn zaváže, že požadavky s kategorií závady odstraní do 24 hodin od
zadání požadavku, pokud se smluvní strany nedohodnou jinak. Pokud požadavek
s kategorií závady nebude odstran n do 24 hodin od zadání požadavku nebo v jiné
sjednané lhůt , je zadavatel oprávn n uplatnit vůči účastníkovi smluvní pokutu 100.000
Kč za každý i započatý den prodlení.

5. Nebude-li zahájeno ešení požadavku s kategorií závady ve stanovené lhůt , je zadavatel
oprávn n uplatnit vůči účastníkovi smluvní pokutu 20.000 Kč za každý jednotlivý p ípad
zvlášť.

6. Účastník se smluvn zaváže, že požadavky s kategorií ostatní vady odstraní do 14
kalendá ních dnů od zadání požadavku, pokud se smluvní strany nedohodnou jinak.
Pokud požadavek s kategorií ostatní vady nebude odstran n do 14 kalendá ních dnů od
zadání požadavku nebo v jiné sjednané lhůt , je zadavatel oprávn n uplatnit vůči
účastníkovi smluvní pokutu 10.000 Kč za každý i započatý den prodlení.

7. Výpadek klinického informačního systému a integrační platformy nesmí p ekročit 8 hodin
za rok.

8. Účastník popíše způsob monitorování dostupnosti a její pravidelný reporting pro
jednotlivé části p edm tu pln ní viz čty hlavních částí definovaných v kap. č. 2.

9. Součástí poskytované servisní podpory musí být bezplatný rozvoj servisovaného p edm tu
pln ní dle pot eb zadavatele, a to v objemu 40 hodin m síčn . Nevyčerpané hodiny budou
p evoditelné mezi m síci a lze je p evést z daného roku pouze do bezprost edn
následujícího kalendá ního roku.

10. Zadavatel požaduje trvalý on-line dohled dodaného systému dodavatelem systému nebo
jeho výrobcem – včetn generování včasného hlášení pro servis v p ípad poruchy.
Dohled se požaduje minimáln pro komponenty KIS, integrační platformu a dodaného
HW.

11. Účastník se smluvn zaváže, že v p ípad rozvojových požadavků o podporu zadaných do
Helpdesku s prioritou vysoká navrhne ešení požadavku nejdéle do 15 pracovních dnů od
nahlášení požadavku.

12. Pokud účastník nep edloží návrh ešení nejdéle do 15 pracovních dnů (pokud se smluvní
strany nedohodnou jinak) od nahlášení rozvojového požadavku s prioritou vysoká je
zadavatel oprávn n uplatnit vůči účastníkovi smluvní pokutu 2.000 Kč za každý celý den
prodlení.

24
13. Pokud rozvojový požadavek Helpdesku s prioritou vysoká nebo st ední nebude realizován
v dohodnuté lhůt , je zadavatel oprávn n uplatnit vůči účastníkovi smluvní pokutu 5.000
Kč za každý celý den prodlení.

14. Nebude-li Hotline dostupný v dohodnutém režimu, bude zadavatel oprávn n uplatnit vůči
účastníkovi smluvní pokutu 5.000 Kč za každý jednotlivý p ípad nedostupnosti zvlášť.

15. Pokud v rámci p íslušného kalendá ního roku bude dodaný klinický informační systém
nebo integrační platforma nedostupná (závada kategorie Porucha) a tato nedostupnost u
t chto systémů bude v součtu za oba tyto systémy dohromady v tší než 8 hodin/kalendá ní
rok, je zadavatel oprávn n uplatnit vůči účastníkovi smluvní pokutu ve výši 50.000,- Kč
za každých započatých 8 hodin nedostupnosti.

16. Účastník se zaváže, že po celou dobu platnosti servisní smlouvy bude mít sjednánu
pojistnou smlouvu s vinkulovaným pojistným pln ní ve prosp ch objednatele pro p ípad,
že svou činností v souvislosti s pln ním p edm tu této smlouvy způsobí škodu t etí osob
(p ičemž touto t etí osobou se rozumí v první ad zadavatel) s limitním pojistným
pln ním na jednu škodnou událost minimáln 20.000.000 Kč (slovy dvacet milionů korun
českých) a že tuto pojistnou smlouvu bude udržovat po celou dobu pln ní p edm tu této
smlouvy v platnosti tak, aby výše uvedené limitní pojistné pln ní nebylo sníženo či jinak
ovlivn no v neprosp ch zadavatele. Účastník se zaváže p edkládat zadavateli v průb hu
pln ní p edm tu této smlouvy kopie pojistných certifikátů či jiných obdobných dokladů o
pojišt ní, a to vždy nejpozd ji do 1 m síce po jejich obdržení.

17. V p ípad prodlení p i instalaci a nasazení update či upgrade je zadavatel oprávn n
uplatnit vůči účastníkovi smluvní pokutu 10.000 Kč za každý i započatý den prodlení.

18. V p ípad nedodání dokumentace k významné zm n systému je zadavatel oprávn n
uplatnit vůči účastníkovi smluvní pokutu 10.000 Kč za každý i započatý den prodlení.

19. Podmínky odstraňování vad díla po dobu pln ní p edm tu smlouvy o dílo a v průb hu
záruční doby a podmínky poskytování servisní podpory do okamžiku akceptace díla jako
celku jsou uvedeny v závazném návrhu smlouvy o dílo (p íloha č. 4 této zadávací
dokumentace).

20. P i pln ní práv a povinností dle servisní smlouvy bude účastník postupovat samostatn ,
bude však vázán zejména písemnými pokyny zadavatele. V p ípad nevhodných pokynů
zadavatele bude účastník povinen na nevhodnost t chto pokynů zadavatele písemn
upozornit, v opačném p ípad ponese účastník zejména odpov dnost za škodu a
nemajetkovou újmu, která v důsledku nevhodných pokynů zadavatele nebo t etím osobám
vznikla.

21. V paušální cen servisu je i zapojování nových zdravotnických prost edků vybavených
rozraním DICOM nebo GDT (jako nap . ultrazvuky, EKG) k interní integrační vrstv .
P ipojení nových za ízení musí být provedeno nejpozd ji do 10 pracovních dnů od
objednání a práce s tím spojené se nezapočítávají do využití volných hodin vymezených
v rámci paušálu pro rozvoj systému - viz bod 9. Zadavatel p edpokládá p ipojení deseti
kusů za ízení zdravotnických prost edků různých typů ročn .

25
22. Pro všechny dodané servery, úložišt a p ípadn i další dodané HW komponenty pro
serverovny, se požaduje servisní podpora s opravou v míst instalace serveru s
garantovaným potvrzením nahlášeného servisního p ípadu/závady do 15 minut od vzniku
(telefonicky) a nástupem technika on-site do 4 hodin od nahlášení servisního
p ípadu/závady. Vy ešení servisního požadavku do 24 hodin (oprava či vým na vadných
komponent, p ípadné zapůjčení ekvivalentního dílu/serveru) od nahlášení závady. Servisní
podpora musí zahrnovat jak podporu na HW, tak SW t etích stran dodaných dle kapitoly
4.4. Servisní podpora na HW a SW t etích stran dodaných dle kapitoly 4.4 musí být
poskytována po dobu 5 let od nabytí účinnosti servisní smlouvy. Servisní podpora musí
být dostupná v českém jazyce a nep etržit – tedy v režimu 24x7x365. Součástí ceny
servisní podpory je dodávka náhradních dílů včetn služeb. V p ípad systémového
software je účastník povinen v rámci poskytované servisní podpory instalovat
bezpečnostní i jiné aktualizace neprodlen po jejich vydání výrobcem. Bude-li výpadek
funkčnosti servisovaného díla či jeho části zap íčin n vadou či nedod lkem systémového
software, p ičemž nebude k dispozici bezpečnostní či jiná aktualizace pro zabezpečení
rutinního chodu díla či jeho části, bude účastník povinen v rámci servisní podpory
bezodkladn zabezpečit chod servisovaného díla či jeho části náhradním způsobem (nap .
instalací jiné verze systémového software), a to tak, aby byl tento náhradní způsob
zabezpečení chodu servisovaného díla či jeho části funkční do doby, kdy výrobce vydá
bezpečnostní či jinou aktualizaci systémového software. K provedení tohoto náhradního
způsobu zabezpečení chodu servisovaného díla či jeho části je účastník povinen nastoupit
a tento náhradní způsob realizovat ve stejných lhůtách, jaké jsou touto zadávací
dokumentací stanoveny pro nástup na odstran ní vad v režimu Porucha a odstraňování
vad v režimu Porucha. Dostane-li se účastník do prodlení se spln ním n které ze svých
povinností dle p edchozí v ty, bude zadavatel oprávn n účtovat účastníkovi smluvní
pokutu, která je touto zadávací dokumentací stanovena pro prodlení účastníka s nástupem
na odstran ní vad v režimu Porucha a pro prodlení účastníka s odstran ním vad v režimu
Porucha.

23. Nezahájí-li účastník práce na odstran ní vady dodaného serveru či hardwarových
komponentů pro serverovny bezodkladn po jejich nahlášení objednatelem, nejpozd ji do
4 hodin od nahlášení vady zadavatelem, a to v míst sídla zadavatele, bude zadavatel
oprávn n vyúčtovat účastníkovi jednorázovou smluvní pokutu ve výši 20.000,- Kč (slovy
dvacet tisíc korun českých), a to za každý takový p ípad zvlášť.

24. Neodstraní-li účastník vadu dodaného serveru či hardwarových komponentů pro
serverovny v nejkratší možné dob , nejpozd ji do 24 hodin od nahlášení vady
zadavatelem, bude zadavatel oprávn n vyúčtovat účastníkovi smluvní pokutu ve výši
10.000,- Kč (slovy deset tisíc korun českých) za každou i započatou hodinu prodlení, a to
za každý takový p ípad zvlášť. To neplatí pro p ípad, kdy účastník poskytne zadavateli k
bezúplatnému užívání na celou dobu odstraňování vad, která p esáhne sjednanou lhůtu,
ekvivalentní díl či server.

4.7.3 Platební podmínky pro servisní smlouvu

· Daňový doklad - faktura musí obsahovat veškeré náležitosti stanovené zákonem č.
235/2004 Sb., o dani z p idané hodnoty, v platném zn ní, a dalšími platnými
daňovými a účetními p edpisy, včetn § 435 odst. 1 zákona č. 89/2012 Sb.,
občanského zákoníku, v platném zn ní. Na faktu e musí být mimo jiné uveden odkaz

26
na tuto smlouvu, název ve ejné zakázky a evidenční číslo ve ejné zakázky; prohlášení
účastníka, že ke dni vystavení faktury není veden v registru nespolehlivých plátců
dan z p idané hodnoty; soupis p íloh; razítko a podpis osoby oprávn né k vystavení
daňového dokladu. Daňový doklad - faktura bude p edán zadavateli v den p evzetí
služby.
· účastník je oprávn n fakturovat m síčn , a to vždy po uplynutí daného kalendářního
měsíce. Přílohou faktury bude výčet poskytnutých služeb. Dnem uskutečnění
zdanitelného plnění bude poslední den příslušného kalendářního měsíce.
· Pokud faktura p edložená účastníkem neobsahuje všechny zákonem a smlouvou
stanovené náležitosti, je zadavatel oprávn n ji do data splatnosti vrátit s tím, že
účastník je poté povinen vystavit novou fakturu s novou lhůtou splatnosti. V takovém
p ípad není zadavatel v prodlení s úhradou faktury. Nová lhůta splatnosti, co do počtu
dnů nikoli kratší než lhůta původní, započne b žet dnem ádného doručení opravené či
nov vystavené faktury zadavateli.
· Splatnost každé faktury je 30 dní ode dne jejího prokazatelného doručení zadavateli.
Platební povinnost zadavatele se považuje za spln nou dnem, kdy je p íslušná částka
odepsána z bankovního účtu zadavatele.
· Veškeré platby mezi smluvními stranami se budou uskutečňovat prost ednictvím
bankovního spojení, které bude uvedeno v záhlaví smlouvy. Účastník ve smlouv
prohlásí, že uvedené číslo jeho bankovního účtu splňuje požadavky dle § 109 zákona
č. 235/2004 Sb., o dani z p idané hodnoty, v platném zn ní, a jedná se o zve ejn né
číslo účtu registrovaného plátce dan z p idané hodnoty.
· Účastník musí ve smlouv prohlásit, že ke dni uzav ení této smlouvy není veden
v registru nespolehlivých plátců dan z p idané hodnoty a ani mu nejsou známy žádné
skutečnosti, na základ kterých by s ním správce dan mohl zahájit ízení o prohlášení
za nespolehlivého plátce dan dle § 106a zákona č. 235/2004 Sb., o dani z p idané
hodnoty, v platném zn ní.
· Zadavatel, jako p íjemce zdanitelného pln ní, je oprávn n, v p ípad , že účastník je
v okamžiku uskutečn ní zdanitelného pln ní veden v registru nespolehlivých plátců
dan z p idané hodnoty, uhradit částku odpovídající výši dan z p idané hodnoty na
účet správce dan za účastníka. Uhrazení částky odpovídající výši dan z p idané
hodnoty na účet správce dan za účastníka bude považováno v tomto rozsahu za
spln ní závazku zadavatele uhradit sjednanou cenu účastníkovi.
· Zadavatel neposkytuje zálohové platby.
· Cena za servisní podporu může být, po uplynutí 48 m síců platnosti smlouvy,
upravena. Tato úprava může být provedena maximáln 1x v kalendá ním roce s
platností min. 12 m síců. P ípustná zm na ceny je následující:

o Cena za servisní podporu:
§ Cena bez DPH (Může činit maximáln cenu stanovenou servisní
smlouvou. V p ípad , že oficiální prům rná roční míra inflace
zve ejn ná Českým statistickým ú adem za p edchozí kalendá ní rok
dosáhla více než 2%, může být smluvní cena bez DPH navýšena až o
částku odpovídající 65% stanovené oficiální prům rné roční míry
inflace, maximáln však o 3%).
§ DPH xx % (aktuáln platná snížená sazba)
§ DPH xx % (aktuáln platná sazba základní)
§ Cena celkem, včetn DPH

Tato úprava může být provedena jednostranným písemným právním jednáním.

27
4.8 Licenční požadavky
Účastník popíše licenční schéma všech druhů jím nabízeného SW, tedy nap . zda se daný SW
licencuje campusov , na server, na uživatele, jednotku uložených dat, studie, dle funkčnosti
atd. Pokud se nabízejí uživatelské licence, uvede účastník informace, zda jsou tyto
pojmenované nebo konkurenční (pool licencí) a zda se liší ceny licencí dle rolí.
Požadavky na způsob licencování viz p íloha č. 4a.
Účastník musí zajistit poskytnutí licencí zadavateli na veškerá autorská díla, která budou
součástí nebo p íslušenstvím p edm tu pln ní. Funkční požadavky na počet současn
pracujících uživatelů viz p íloha č. 3.
Další podrobnosti k licenčním požadavkům viz kap. 4.4

4.9 Ostatní požadavky

· Účastník navrhne způsob zaškolení uživatelů dodaného systému, a to
diferencovan pro klíčové a b žné uživatele systému a pro správce systému.

· Zadavatel požaduje provést zaškolení dodavatelem jako součást dodávky.
· Účastník v nabídce navrhne p im ený rozsah zaškolení a zakalkuluje je do

nabídkové ceny.
· Veškerá zaškolení uživatelů budou probíhat v míst sídla zadavatele, a to v českém

jazyce s vybavením zajišt ným zadavatelem. K dispozici budou dv učebny
vybavené PC, každá pro 20 uživatelů.
· Součástí dodávky musí být zaškolení uživatelů dodaného klinického informačního
systému. Zadavatel p edpokládá zaškolení cca 3215 uživatelů dodaného klinického
informačního systému. Minimální délka zaškolení každého uživatele bude 4
hodiny.
· Součásti dodávky musí být i úvodní zaškolení 6 administrátorů do klinického
informačního systému v rozsahu, který navrhne účastník, avšak v rozsahu min. 40
hodin.
· Součásti dodávky musí být i úvodní zaškolení 2 metodiků klinického informačního
systému v rozsahu, který navrhne účastník, avšak v rozsahu min. 40 hodin.
· Součásti dodávky musí být i úvodní zaškolení 2 administrátorů do integrační
platformy v rozsahu, který navrhne účastník, avšak v rozsahu min. 16 hodin.
· Součásti dodávky musí být i úvodní zaškolení 2 administrátorů do portálu pacienta
v rozsahu, který navrhne účastník, avšak v rozsahu min. 16 hodin.
· Účastník vytvo í testovací prost edí pro pot eby zkoušení, testování funkcionalit a
školení uživatelů a správců na dodané provozní infrastruktu e.
· Zadavatel požaduje dodávku videomanuálů v rozsahu základní práce s klinickým
informačním systémem a portálem pacienta a práce s elektronickou zdravotnickou
dokumentací. Zadavatel má pod pojmem Videomanuál na mysli zejména soubor
audiovizuálních sekvencí s názornými komentovanými demonstracemi ovládání
systému. Jedná se o základní práce s klinickým informačním systémem a portálem
pacienta a práce s elektronickou zdravotnickou dokumentací jako nap . založení
ambulantní karty, tisk ambulantního záznamu. Zadavatel ponechává formu
videomanuálu na účastníkovi. Videomanuály musí být p ehratelné voln
dostupnými p ehrávači. Detaily budou up esn ny mezi zadavatelem a účastníkem
v rámci Provád cího projektu.

28
5 Požadavky na ešení část 2

Účastník ve své nabídce p edloží podrobný popis nabízeného ešení. Názvy a po adí kapitol
takto p edloženého dokumentu zadavatel požaduje ve struktu e dle této kapitoly.

Zadavatel požaduje pokrytí funkčních a technických požadavků uvedených v této kapitole.

5.1 Minimální požadavky na zabezpečený dlouhodobý dův ryhodný archiv

Zabezpečený dlouhodobý dův ryhodný archiv (dále ZDDA) sestávající se z aplikační vrstvy a
navazujícího garantovaného úložišt . ZDDA musí být schopen zajistit realizaci následujících
klíčových procesů:

· validace, uchovávání a prokazování platnosti a v rohodnosti podpisů, pečetí a
časových razítek,

· uložení a fyzické zabezpečení archivovaných dat,
· skartace elektronických dokumentů.
ZDDA musí komunikovat se spolupracujícími aplikacemi zadavatele prost ednictvím
sjednocujícího rozhraní, které jasn odd luje prostor zdrojových systémů, uživatelů a
samotného uložení a uchování dokumentů. ZDDA poskytuje komunikační rozhraní pro vstup
dokumentů, funkce pro práci uživatelů a p ehledové a statistické funkce poskytující informace
o stavu archivu.

5.1.1 Shoda s legislativou

Účastníkem nabízené ešení musí na aplikační úrovni i na úrovni garantovaného úložišt
disponovat mechanismy, které zajistí uložení dat ve shod s národními normami pro
dův ryhodné uložení dat a organizačními sm rnicemi a na ízeními:

· eIDAS - na ízení Evropské unie č. 910/2014,
· zákon č. 499/2004 Sb., Zákon o archivnictví a spisové služb a o zm n n kterých

zákonů,
· vyhláška č. 259/2012 Sb., Vyhláška o podrobnostech výkonu spisové služby
· zákon č. 372/2011 Sb., Zákon o zdravotních službách a podmínkách jejich

poskytování
· vyhláška č. 98/2012 Sb., Vyhláška o zdravotnické dokumentaci
· zákon č. 297/2016 Sb., Zákon o službách vytvá ejících dův ru pro elektronické

transakce
· Národní standard pro vedení elektronického systému spisové služby NSESSS

Tato schopnost bude doložena certifikátem shody s výše uvedenými normami vydaným
nezávislým subjektem oprávn ným posuzovat shodu (nap . certifikační autoritou).

5.1.2 Aplikační vrstva
Aplikační vrstva musí aktivn používat API garantovaného úložišt pro ízení uchování
(retencí) a další relevantní funkce pro zajišt ní bezpečnosti dokumentů

29
5.1.2.1 Integrační rozhraní
Integrační rozhraní umožní napojení stávajících i v budoucnu po ízených produkčních
systémů spravujících a po izujících zdravotnickou, p ípadn jinou dokumentaci k archivaci.
Zadavatel požaduje i schopnost konsolidovat ukládání a p ístup k dokumentům nap íč celou
organizací.

5.1.2.2 Obecné požadavky

ZDDA elektronických dokumentů
· Forma rozhraní
o Webové služby typu SOAP nebo REST.
o P edávání dokumentů dle standardu MTOM (SOAP) nebo multipart (REST).
· Operace rozhraní
o P edání dokumentu a souvisejících metadat k archivaci. Dokument lze p edat
jako binární p ílohu nebo jako externí identifikaci ve zdrojovém systému.
o Získání dokumentu a souvisejících metadat z archivu.
o Skartace dokumentu v archivu.
· Zabezpečení rozhraní
o Rozhraní dostupné po šifrovaném protokolu HTTPS.
o Autentizace pomocí HTTP/BASIC nebo pomocí certifikátu.

Validace elektronických dokumentů
· Forma rozhraní
o Webové služby dle standardu OASIS Digital Signature Service (DSS) –
Verifying Protocol.
· Operace rozhraní
o Ov ení platnosti elektronického dokumentu
· Zabezpečení rozhraní
o Rozhraní dostupné po šifrovaném protokolu HTTPS.
o Autentizace pomocí HTTP/BASIC nebo pomocí certifikátu.

5.1.2.3 Požadované funkce a vlastnosti
· Napojení na minimáln tyto typy úložišť (výstupní konektory):
o souborové systémy NAS a SAN pomocí protokolů NFS/CIFS,
o databáze,
o systémy pro správu dokumentů,
o specializovaná garantovaná úložišt typu CAS.
· Vstupní konektory:
o standardní vstupní rozhraní SOAP/REST pro p íjem požadavků,
o možnost konfigurace vstupního rozhraní administrátorem zadavatele nap .
skriptem
o možnost ručního vkládání dokumentů.
· Centrální mezipam ť (cache):
o uložení dokumentů pro rychlý p ístup,
o v p ípad nedostupnosti cílového úložišt v dob zápisu dočasn dokument i
s metadaty uchová a následn jej uloží do cílového úložišt p i jeho op tovné
dostupnosti,

30
· uložení dokumentu do ZDDA,
· p esun dokumentů mezi úložišti,
· zp ístupn ní dokumentů ostatním IS a aplikacím,
· komprese ukládaných dokumentů,
· orchestrace služeb jako nap . zapečet ní, ov ení, uložení, archivování poskytovaných

dokumentů,
· centrální monitorování v reálném čase sleduje stav a výkon integračních procesů:

o stav a výkon integrace s dokumentovými úložišti,
o stav sít , dostupnost a odezva jednotlivých koncových za ízení,
o stav/výkon aplikačních serverů – odezva, kapacita (pam ť, diskový prostor).

5.1.2.4 Funkce ZDDA

ZDDA musí zajistit proces:

· ov ení a dlouhodobého uchovávání ov itelnosti a průkaznosti elektronických
podpisů, pečetí a časových razítek v souladu s Na ízením eIDAS,

· tvorbu AIP balíčků dle modelu OAIS včetn jejich zapečet ní.

Nabídnuté ešení musí v oblasti dlouhodobého uchovávání elektronických podpisů a pečetí
dle elDAS nabídnout minimáln následující vlastnosti:

· podporu pro všechny formáty rozší eného podpisu (AdES), tak, aby jejich zpracování
prob hlo nezávisle na jejich formátu,

· možnost ukládat archivované dokumenty p ímo do aplikační databáze jako binární
objekty,

· možnost uložit uchovávané dokumenty do samostatného bezpečného úložišt typu
CAS,

· možnost nastavení požadované úrovn dův ry p i ov ování platnosti podpisů/pečetí
(uznávaný(á), kvalifikovaný (á)),

· provád ní separace certifikátů, na kterých jsou založené bezpečnostní prvky a jejich
další zpracování,

· ov ení neporušenosti (integrity) obsahu elektronických dokumentů,
· ov ení správného použití daného certifikátu k účelu, ke kterému byl vystaven,
· dlouhodobé uchování jednotlivých prvků, které mohou být v budoucnu použity jako

důkazní materiál k danému elektronickému dokumentu,
· ov ování všech AdES formátů, ale i dalších (minimáln PDF, PDF/A a S/MIME),
· dlouhodobé uchování certifikátů (včetn certifikačních cest), na kterých jsou založené

bezpečnostní prvky (podpis, pečeť, razítko),
· dlouhodobé uchování CRL/OCSP, které se vztahují k certifikátům (viz výše),
· balíčkování - tvorba AIP podle OAIS dle principů elDAS,
· p erazítkovávání - sledování bezpečnostních prvků elektronického dokumentu v čase

tak, aby byla realizována aktivní péče o elektronické dokumenty, které zabezpečuje
jejich dlouhodobou platnost (digitální kontinuita),
· poskytnutí důkazu pro prokázání právní relevance uloženého dokumentu,
· vyhledávání dokumentů dle různých kritérií, metadat, typu dokumentu, času,
· stažení dokumentu,
· náhled na dokument,
· full-textové vyhledávání v rámci dokumentu,
· možnost editace metadatových položek,
· zobrazení detailu o dokumentu,

31
· monitoring a reportování činnosti,
· podpora využití technologie pro bezpečné ukládání kryptografických klíčů,
· podpora AdES formátů v úrovni „B-B“ a „B-T“,
· kontrola platnosti používaných certifikátů,
· jednoduché napojení na autority poskytující kvalifikovaná časová razítka,
· integrace aplikací t etích stran,
· správa systémových účtů, certifikátů a jejich propojení,
· logování a audit,
· nastavení práv a p ístupů pomocí LDAP.

5.1.3 Garantované diskové úložišt
Diskové úložišt ZDDA bude sloužit pro dlouhodobé dův ryhodné uložení informací, které
podléhají legislativním požadavkům na dlouhodobé uložení dat – archivaci.
V následujících podkapitolách jsou uvedeny povinné funkční a technické parametry, které
musí nabídnuté ešení na hardwarové úrovni splnit.

5.1.3.1 Architektura úložišt
Úložišt musí používat architekturu Content Addressed Storage (dále jen CAS). Tato
architektura je navržena pro dlouhodobé ukládání velkého objemu různorodých dat. Krom
samotných dat umožňuje ukládání souvisejících metadat, a to garantovaným způsobem,
nezávislým na externích aplikacích a způsobu uložení (tedy na typu souborového systému,
lunů nebo volumů). Je garantována jedinečnost ukládaných dat a v budoucnu jejich p enos
mezi různými typy platforem bez narušení autenticity.

5.1.3.2 Vynucení skartační doby
Diskové úložišt musí umožnit vynucení skartační doby pro ukládaná data. Krom toho musí
umožnit definování skartačních t íd v závislosti na druhu ukládaného obsahu.
Skartační lhůty musí být možno nastavit individuáln či skupinov . Dále musí úložišt
disponovat funkcionalitou pro:

· definici skartační lhůty na základ události,
· nastavení minimální a maximální délky skartační lhůty,
· nastavení zámku na všechny objekty (bez ohledu na to, zda je na nich skartační lhůta

či nikoliv), který je použit nap . v p ípad soudního ízení nebo auditu.

5.1.3.3 Zapojení systémových komponent
Diskový systém musí být navržen tak, aby systém byl odolný proti výpadku jednotlivé
komponenty, a aby architektura umožňovala ochranu na úrovni objektové parity (bez nutnosti
provád t zálohu uložených dat).
Komponenty budou zapojeny ve dvou lokalitách v režimu zrcadlení.

5.1.3.4 Požadovaná čistá kapacita
Zadavatel požaduje dodat minimáln 6TB do jedné lokality.

5.1.3.5 Rozši itelnost
Návrh architektury diskového systému musí umožňovat snadné a automatické rozši ování
systémových prost edků v horizontu desítek let na násobky původní konfigurace bez nutnosti
zm ny fyzického systému a aplikačního prost edí, tzn., musí být implementován
mechanismus ochrany proti zastarání.

32
Disková hrubá kapacita systému musí být rozši itelná on-line, za provozu bez nutnosti
migrace dat na jiný typ za ízení, bez výpadku dostupnosti dat a fyzického systému v rámci
jednoho fyzického systému minimáln na ády PB.

5.1.3.6 Virtualizace
Diskový systém musí disponovat možností virtuálního sdružování více fyzických systémů
prezentovaných jako jeden logický celek.
Logická kapacita tohoto systému musí být dostupná op t beze zm ny konfigurace aplikačního
prost edí, které ukládá na systém data. Takový systém musí být spravován jako jeden celek.

5.1.3.7 Multitenancy
Diskový systém musí umožňovat logické rozd lení diskového systému na logické podcelky,
které jsou prezentovány jako samostatné fyzické systémy – jsou tedy odd leny datové
prostory, uživatelské účty a správa a mohou být prezentovány prost ednictvím jiných
segmentů sít .
Dále je požadováno, aby bylo možno nastavovat diskové kvóty pro množství a objem
ukládaných dat.

5.1.3.8 Způsob uložení dat
Diskový systém musí disponovat dokumentovaným mechanismem pro ukládání dat, který:

· zabezpečí jejich ochranu p ed manipulací s obsahem uložených dat,
· ochrání data proti podvržení obsahu,
· zajistí funkcionalitu pro kontrolu konzistence dat,
· zajistí globální jedinečnost identifikátoru ukládaných dat (tak, aby byla vyloučena

kolize uloženého obsahu p i p ípadných migracích nebo zm nách v architektu e).
Způsob uložení dat musí být nezávislý na použité technologii – nesmí tedy záviset na
konkrétním typu disků, adiče, či architektu e. Je požadováno, aby

· identifikátory ukládaných dat nebyly p ístupné p ímo externím subjektům (uživatelům
a aplikacím),

· systém umožnil krom uložení samotných dat i uložení metadat (systémová i
uživatelská), a to tak, aby byla zajišt na jejich konzistence a nep etržitá kontrola po
celou dobu životního cyklu uložených dat.

5.1.3.9 Vysoká bezpečnost
Nesmí existovat natolik privilegovaný administrátor diskového systému, aby mohl získat
p ístup k obsahu objektů, p ípadn objekty mazat nebo manipulovat s podpisy a obsahem.

5.1.3.10 Audit událostí
Úložišt musí obsahovat funkcionalitu pro audit všech událostí, které se v rámci životního
cyklu stanou (logování administrátorských p íkazů, zm n nastavení, systémových zm n,
manipulaci s daty apod.).
Tento audit musí být zajišt n systémovými prost edky úložišt tak, aby k n mu m li p ístup
pouze oprávn ní uživatelé, a není možné je modifikovat, nebo smazat.

5.1.3.11 Skartační mechanismus
Úložišt musí mít garantovaný skartační algoritmus, který zajistí násobný průchod mazacího
algoritmu tak, aby byly napln ny skartační mechanismy podle NSA (data, která byla aplikací
vymazána, jsou nejenom logicky odstran na z disků, ale zároveň je proveden vícenásobný

33
p epis diskových sektorů tak, aby nebylo možné objekt rekonstruovat ani v p ípad získání
fyzických disků).

5.1.3.12 Rozši itelnost a technologická inovace
Úložišt musí um t růst společn s růstem množství ukládaných dat bez nutnosti migrace dat
na nové technologie.
Musí um t adaptovat nové technologie za chodu (růst kapacity disků, zvyšování rychlosti
infrastruktury apod.). P i rozši ování se nesmí m nit způsob ukládání, není tedy t eba
modifikovat aplikaci. Musí umožňovat bezproblémovou a dlouhodobou rozši itelnost
realizovatelnou bez ohrožení uložených dat.

5.1.3.13 Mazání dat
Po výmazu dat musí existovat auditní záznam o výmazu p ímo na HW úrovni úložišt a musí
vzniknout nativními prost edky úložišt – není p ípustný zápis auditu externí aplikací.

5.1.3.14 Replikace
Úložišt musí umožňovat zprovozn ní standardní asynchronní replikace v různých lokalitách.
Dále systém musí umožnit distribuci jednoho logického systému p es n kolik geograficky
odd lených lokalit s prezentací jednoho logického name space.

5.1.3.15 Správa za ízení
Diskový systém musí disponovat administrátorskými nástroji pro správu celého za ízení
(webové administrátorské rozhraní, Command Line Interface, p ípadn další) a reporting
stavu (počty uložených objektů, obsazená kapacita, stav uložených dat, p ehled o
systémových procesech, stav replikace dat, atd.). Za ízení dále musí disponovat možnostmi
pro zapojení do centrálních monitorovacích nástrojů prost ednictvím standardních protokolů
(SNMP, SMI, apod.).

5.1.3.16 Ochrana dat proti výpadku systémových komponent
Architektura úložišt musí být navržena tak, aby byla zajišt na ochrana dat proti výpadku
systémových komponent. Tento mechanismus musí zajišťovat izolaci vadné komponenty a
automatické zotavení nap . p i výpadku jednoho nebo více disků, napájení, portů, nebo jiných
klíčových komponent bez manuálního zásahu administrátora. Systém musí obsahovat
procesy, které na HW úrovni automaticky monitorují zdraví a stav dat a jsou schopny
automaticky nastartovat procesy pro obnovení dat p i jejich ohrožení systémovými chybami.
Systém musí umožnit šifrování dat (minimáln FIPS-140-2 Level 1) a externí autentifikaci
prost ednictvím externího key manageru.

5.1.3.17 Vysoká dostupnost dat
Úložišt na HW úrovni musí ukládat data takovým způsobem, aby byla zaručena jejich
vysoká dostupnost, nap . formou redundantních kopií. Systém musí mít zabudován vysoký
stupeň ochrany dat buď formou zrcadlení, nebo paritních kopií tak, aby ztráta (nap . havárie
disku) nevedla ke ztrát dat (interní mechanismus bez závislosti na software pro replikace
nebo tvorbu klonů a snapů).

5.1.3.18 Dostupnost dat
Data uložená v úložišti musí být p ístupná on-line s konstantní p ístupovou dobou v ádech
milisekund.

34
5.1.3.19 P ístup k datům
Úložišt musí disponovat různými typy mechanismů pro ukládání a prezentaci dat. Je
vyžadováno minimáln následující:

· API – veškerá funkcionalita úložišt musí být dostupná prost ednictvím popsaného
API; pro integraci s aplikacemi t etích stran musí existovat programátorská p íručka a
voln dostupné SDK,

· REST API,
· S3,
· Swift,
· HDFS,
· NFS.

5.1.3.20 Integrace do infrastruktury
Z hlediska celkových nákladů na provoz a správu je požadováno zapojení za ízení do LAN
infrastruktury (1000BASE-T a 10G BaseT).
Diskový systém musí umožnit dynamické škálování výkonnosti (propustnosti) pro p ístup
k datům nebo pro replikaci násobným zapojováním ETH rozhraní nebo je naopak izolovat pro
separátní segmenty sít v p ípad logického rozd lení diskového systému (nap . pro lokální
organizační jednotky). Minimální požadovaný počet je 8 portů pro ETH 1GB s garantovanou
rozši itelností.

5.2 Realizační podmínky
Účastník v nabídce navrhne postup implementace systému vč. harmonogramu.

5.3 Požadavky na vlastnosti systému v oblasti bezpečnosti
Účastník v nabídce popíše způsob zajišt ní bezpečnosti a doporučený způsob kontroly.

Národní ú ad pro kybernetickou a informační bezpečnost podle § 22a odst. 1 zákona č.
181/2014 Sb., o kybernetické bezpečnosti a o zm n souvisejících zákonů (zákon o
kybernetické bezpečnosti), ve zn ní pozd jších p edpisů, v ízení ve v ci určení Fakultní
nemocnice Hradec Králové rozhodl, že Fakultní nemocnice Hradec Králové je
provozovatelem základní služby: Poskytování zdravotních služeb. Informační systém, na
kterém je tato služba závislá, je informačním systémem základní služby.
Dodávka IS, jeho nasazení, migrace dat a zabezpečení p i provozu i údržb musí být v
souladu se zákonem č. 181/2014 Sb. (zákon o kybernetické bezpečnosti) v aktuálním zn ní a
vyhlášky č. 82/2018 Sb. (vyhláška o kybernetické bezpečnosti) v aktuální zn ní a
navazujícími a souvisejícími právními p edpisy.

Dodavatel systému bude z hlediska kybernetické bezpečnosti za azen jako významný
dodavatel zadavatele.

Dodaný IS bude chránit osobní údaje 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ů.

Detailní požadavky na bezpečnost zabezpečeného dlouhodobého dův ryhodného archivu jsou
uvedeny v rámci této kapitoly zadávací dokumentace.

35
5.4 Dodávka nezbytné HW a SW infrastruktury

· Účastník musí specifikovat v nabídce název výrobce, označení nabízeného HW a SW,
u kterého uvede verzi a typ licence.

· Účastník je povinen ve své nabídce uvést sizing serveru(ů) pro jím navrhovaný
systém. Navržený sizing bude obsahovat počet a typ doporučených procesorů, velikost
RAM a interní diskový prostor serveru(ů).

· Zadavatel požaduje dodat redundantní ešení nezávislé na výpadku jednoho fyzického
serveru, jednoho provozního úložišt , a vše s recovery time objective (dále RTO) max.
5 min (stanovená mez RTO se vztahuje na obnovu funkce dodaného SW vybavení a
serverových HW technologií).

· Zadavatel neposkytne pro poptávaný projekt žádné licence pro virtualizaci, systémový
SW, databázové licence ani hardware. Součástí požadované dodávky je tedy
kompletní provozní infrastruktura pro nasazované ešení.

· Aktivní síťové prvky nejsou p edm tem dodávky, konektivitu poskytne zadavatel.
· Zadavatel poskytne pro pot eby nového IS maximáln tuto konektivitu:

o v serverovn v budov č.24 je k dispozici 5 + 5 portů 1000/10000 Ethernet
10GBASE-T, tedy je k dispozici 5 p ipojení ke každému ze dvou switchů
CISCO Nexus.

o v serverovn v budov č.12 je k dispozici 5 + 5 portů 1000/10000 Ethernet
10GBASE-T, tedy je k dispozici 5 p ipojení ke každému ze dvou switchů
CISCO Nexus. "

· Pokud budou součástí nabídky licence na produkty firmy Microsoft, zadavatel sd luje,
že je v této oblasti smluvn vázán Microsoft Select - cenová kategorie D.
Kontakt:
Ministerstvo vnitra
editel odboru kybernetické bezpečnosti a koordinace informačních a komunikačních
technologií
fax: +420 974 816 209
ID datové schránky: 6bnaawp

· Pokud budou součástí nabídky licence na produkty firmy VMware, zadavatel sd luje,
že je v této oblasti smluvn vázán kontraktem s Ministerstvem vnitra.
Kontakt:
Ministerstvo vnitra

36
editel odboru kybernetické bezpečnosti a koordinace informačních a komunikačních
technologií
fax: +420 974 816 209
· Pokud budou součástí nabídky licence na produkty firmy IBM, zadavatel sd luje, že je
v této oblasti smluvn vázán kontraktem s Ministerstvem vnitra.
Kontakt:
Ministerstvo vnitra

editel odboru kybernetické bezpečnosti a koordinace informačních a komunikačních
technologií
fax: +420 974 816 209
· P edm tem dodávky není dodávka bezpečnostních p edm tů (čipových karet resp.
tokenů), kvalifikovaných certifikátů ani kvalifikovaných časových razítek.

5.5 Integrační požadavky
Účastník dodá detailní popis integračního rozhraní zabezpečeného dlouhodobého
dův ryhodného archivu minimáln v rozsahu vyplývajícím z kap. 5.1 a zajistí jeho realizaci
s integrační platformou. Integrační platforma bude fungovat v souladu s technickými a
funkčními požadavky popsanými v p íloze č. 3 v položkách IP_001 až IP_018.

5.6 Požadavky na migraci dat
Zadavatel nepožaduje žádnou migraci dat v rámci této části ve ejné zakázky.

5.7 Servisní podmínky

Součástí nabídky účastníka pro část 2 musí být návrh servisní smlouvy na poskytování
servisní podpory po akceptaci díla jako celku (a to tak, že servisní podpora dle servisní
smlouvy bezprost edn naváže na technickou podporu poskytovanou v rámci pln ní
p edm tu smlouvy o dílo do okamžiku akceptace díla jako celku. Návrh servisní smlouvy
bude respektovat minimáln požadavky zadavatele stanovené v bodech 5.7 a 7 této
zadávací dokumentace.

Vzhledem k významu poptávaného IS pro chod zadavatele považuje zadavatel za
minimální akceptovatelnou úroveň servisního zabezpečení následující požadavky.
Všechny požadavky uvedeny v kapitole 4.7.1 a dále všechny níže uvedené požadavky
v kapitole 5.7.1 musí být zapracovány do návrhu servisní smlouvy.

5.7.1 Ostatní servisní podmínky a sankce pro část 2

1. Servisní smlouva nabude účinnosti okamžikem celkové akceptace díla s tím, že servisní
podpora dle servisní smlouvy bude zadavateli poskytována ode dne účinnosti této
smlouvy (s výjimkou odstraňování vad a nedod lků, které budou po dobu záruční doby
odstraňovány dle smlouvy o dílo).
Smluvní strany jsou oprávn ny platnost této smlouvy nebo její části jednostrann ukončit
písemnou výpov dí s výpov dní dobou v délce 18 m síců, která počne b žet prvním dnem
m síce následujícího po doručení písemné výpov di druhé smluvní stran . Účastník bude
oprávn n vypov d t servisní smlouvu nejd íve po uplynutí 10 let od data nabytí účinnosti

37
této smlouvy, a to za podmínek stanovených níže, není-li v této zadávací dokumentaci
dále stanoveno jinak.

Po uplynutí 10 let od data nabytí účinnosti této smlouvy je účastník oprávn n vypov d t
servisní podporu zabezpečeného dlouhodobého dův ryhodného archivu pouze v p ípad :
a) ukončení servisní podpory dodaného zabezpečeného dlouhodobého dův ryhodného

archivu na trhu (tj. bude-li v této dob životní cyklus dodaného zabezpečeného
dlouhodobého dův ryhodného archivu ukončen, a to pouze na základ oficiálního
oznámení výrobce o ukončení podpory zabezpečeného dlouhodobého dův ryhodného
archivu),
b) v p ípad , že účastník vstoupí do likvidace nebo bude-li v p ípad účastníka soudem
prohlášen úpadek.

V p ípad ukončení servisní podpory dodaného zabezpečeného dlouhodobého
dův ryhodného archivu d íve než po uplynutí lhůty 10 let (tj. bude-li v této dob životní
cyklus dodaného zabezpečeného dlouhodobého dův ryhodného archivu ukončen, a to
pouze na základ oficiálního oznámení výrobce o ukončení podpory zabezpečeného
dlouhodobého dův ryhodného archivu) je účastník povinen zajistit kontinuitu ešení
zdarma (dodávka nového zabezpečeného dlouhodobého dův ryhodného archivu včetn
implementace a migrace všech dat).

Zadavatel je oprávn n vypov d t servisní smlouvu v celém jejím rozsahu bez udání
důvodu, a to kdykoli v průb hu doby platnosti servisní smlouvy.

Pokud by se kterékoliv ustanovení Smlouvy ukázalo být neplatným z důvodu rozporu s
kogentním ustanovením obecn závazných právních p edpisů, pak tato skutečnost působí
neplatnost pouze tohoto konkrétního ustanovení, pokud je odd litelné od ostatního obsahu
Smlouvy. Smluvní strany se zavazují takové neplatné ustanovení nahradit dohodou svým
obsahem nejbližší duchu takového neplatného ustanovení respektující požadavky
kogentních ustanovení právních p edpisů.

Veškeré spory vzešlé z této smlouvy či se jakkoli dotýkající práv a povinností
vyplývajících ze závazkového vztahu dle této smlouvy budou smluvními stranami ešeny
smírnou cestou. Nepoda í-li se tímto způsobem spor vy ešit, budou tyto spory ešeny p ed
v cn a místn p íslušnými českými soudy.

Vztahy vznikající ze smlouvy a v ní výslovn neupravené se ídí Právním ádem ČR,
zejména pak p íslušnými ustanoveními občanského zákoníku

Účastník nesmí bez p edchozího písemného souhlasu zadavatele postoupit svá práva a
povinnosti plynoucí z této smlouvy t etí osob .

2. Účastník se smluvn zaváže, že požadavky s kategorií poruchy odstraní do 8 hodin od
okamžiku nahlášení poruchy zadavatelem, pokud se smluvní strany nedohodnou jinak.

38
Pokud požadavek s kategorií poruchy nebude odstran n do 8 hodin od okamžiku
nahlášení zadavatelem nebo v jiné sjednané lhůt , je zadavatel oprávn n uplatnit vůči
účastníkovi smluvní pokutu 3.000 Kč za každou hodinu, kdy systém není funkční.
3. Nebude-li zahájeno ešení požadavku s kategorií poruchy ve stanovené lhůt , je zadavatel
oprávn n uplatnit vůči účastníkovi jednorázovou smluvní pokutu 10.000 Kč za každý
jednotlivý p ípad zvlášť.
4. Účastník se smluvn zaváže, že požadavky s kategorií závady odstraní do 24 hodin od
zadání požadavku, pokud se smluvní strany nedohodnou jinak. Pokud požadavek
s kategorií závady nebude odstran n do 24 hodin od zadání požadavku nebo v jiné
sjednané lhůt , je zadavatel oprávn n uplatnit vůči účastníkovi smluvní pokutu 20.000 Kč
za každý i započatý den prodlení.
5. Nebude-li zahájeno ešení požadavku s kategorií závady ve stanovené lhůt , je zadavatel
oprávn n uplatnit vůči účastníkovi smluvní pokutu 5.000 Kč za každý jednotlivý p ípad
zvlášť.
6. Účastník se smluvn zaváže, že požadavky s kategorií ostatní vady odstraní do 14
kalendá ních dnů od zadání požadavku, pokud se smluvní strany nedohodnou jinak.
Pokud požadavek s kategorií ostatní vady nebude odstran n do 14 kalendá ních dnů od
zadání požadavku nebo v jiné sjednané lhůt , je zadavatel oprávn n uplatnit vůči
účastníkovi smluvní pokutu 2.000 Kč za každý i započatý den prodlení.
7. Součástí poskytované servisní podpory musí být bezplatný rozvoj servisovaného p edm tu
pln ní dle pot eb zadavatele, a to v objemu 5 hodin m síčn . Nevyčerpané hodiny budou
p evoditelné mezi m síci a lze je p evést z daného roku do následujícího kalendá ního
roku.

5.7.2 Platební podmínky pro servisní smlouvu
Platební podmínky pro servisní smlouvu jsou uvedeny v kapitole 4.7.3.
5.8 Licenční požadavky
Účastník popíše licenční schéma všech druhů jím nabízeného SW, tedy nap . zda se daný SW
licencuje campusov , na server, na uživatele, jednotku uložených dat, studie, dle funkčnosti
atd. Pokud se nabízejí uživatelské licence, uvede účastník informace, zda jsou tyto
pojmenované nebo konkurenční (pool licencí) a zda se liší ceny licencí dle rolí.
Požadavky na způsob licencování viz p íloha č. 4b.
Účastník musí zajistit poskytnutí licencí zadavateli na veškerá autorská díla, která budou
součástí nebo p íslušenstvím p edm tu pln ní.
Další podrobnosti k licenčním požadavkům viz kap. 5.4

5.9 Ostatní požadavky

· Účastník navrhne způsob školení uživatelů dodaného systému, a to diferencovan
pro klíčové a b žné uživatele systému a pro správce systému.

· Zadavatel požaduje provést zaškolení dodavatelem jako součást dodávky.

39
· Účastník v nabídce navrhne p im ený rozsah zaškolení a zakalkuluje je do
nabídkové ceny.

· Veškerá zaškolení uživatelů budou probíhat v míst sídla zadavatele, a to v českém
jazyce s vybavením zajišt ným zadavatelem.

· Součásti dodávky musí být i úvodní zaškolení 2 administrátorů do zabezpečeného
dlouhodobého dův ryhodného archivu v rozsahu, který navrhne účastník, avšak
v rozsahu min. 16 hodin.

· Účastník vytvo í testovací prost edí pro pot eby zkoušení, testování funkcionalit a
zaškolení uživatelů a správců na dodané provozní infrastruktu e.

6 Požadavky zadavatele na způsob zpracování nabídkové ceny:

Celková nabídková cena musí být pro každou z částí zpracována ve struktu e dané cenovou
tabulkou – viz p íloha č. 7: Cenová tabulka. Účastník do tabulky pro každou položku uvede,
z čeho se cena sestává (cena za jednotlivé položky). Cena za jednotlivé položky musí být
uvedena v Kč vč. DPH a v Kč bez DPH.
Součástí nabídkové ceny musí být i práce, dodávky či činnosti, které v této zadávací
dokumentaci nejsou explicitn uvedeny, ale které účastník musí s ohledem na svoji odbornost,
na jím nabízený p edm t ve ejné zakázky a jeho ádnou a úplnou realizaci provést k dosažení
zadavatelem požadovaného cílového stavu.
Nabídková cena účastníka musí být stanovena jako cena nejvýše p ípustná a obsahující
veškeré náklady účastníka nutné pro pln ní p edm tu ve ejné zakázky ke dni podání nabídky
daného účastníka, a bude cenou nejvýše p ípustnou po celou dobu pln ní ve ejné zakázky,
včetn záručních podmínek (není-li v této zadávací dokumentaci uvedeno jinak).
Nabídková cena za pln ní každé části této zakázky musí obsahovat cenu základní včetn
ostatních poplatků a musí se jednat o cenu konečnou. Ostatními poplatky se myslí nap .
cestovné, ubytování, clo, dopravné do místa určení, balné atd.

Zadavatel nep ipouští žádné další vícenáklady.
Účastník v nabídce uvede ceny prací nad rámec standardní sjednané servisní podpory ve
struktu e uvedené v p íloze č. 7. Nacen ní t chto služeb, které však nejsou součástí hodnocení
p edm tné ve ejné zakázky je podmínkou pro podání nabídky.

7 Doba a místo pln ní

Doba plnění: do 22 m síců od nabytí účinnosti smlouvy o
dle smlouvy o dílo část 1 dílo
dle smlouvy o dílo část 2 do 4 měsíců od doručení výzvy ze strany
zadavatele

40
dle servisní smlouvy dle podmínek uvedených v servisní smlouvě
Místo plnění: Fakultní nemocnice Hradec Králové

8 Obsah nabídky

Nabídka bude obsahovat zejména tyto požadované náležitosti:

· Krycí list nabídky podepsaný osobou oprávn nou jednat jménem účastníka (viz
p íloha č. 1 zadávací dokumentace),

· smlouvu o sdružení (je-li nabídka podána více subjekty společn )
· doklady prokazující spln ní kvalifikace,
· doklad o poskytnutí jistoty (platí pouze pro část 1),
· celkovou nabídkovou cenu v rozsahu dle kapitoly č. 6 této zadávací dokumentace -

Požadavky zadavatele na způsob zpracování nabídkové ceny,
· čestné prohlášení o pravdivosti údajů uvedených v nabídce, podepsané osobou

oprávn nou jednat jménem či za účastníka,
· čestné prohlášení ke garanci uložení dat dle na ízení Evropského parlamentu a Rady

(EU) 2016/679 , p ičemž bude povinen zajistit, aby data neopustila území České
republiky. Daty jsou mín ny osobní údaje pacientů zadavatele a dalších osob, daty
jsou dále mín ny i veškeré informace, které se účastník v průb hu pln ní p edm tu
ve ejné zakázky dozví o činnosti, struktu e a IT prost edí zadavatele.
· podrobný popis nabízeného pln ní dle struktury v kapitole č. 4 s výjimkou kapitoly
4.7 Servisní podmínky, která bude uvedena dále (platí pouze pro část 1),
· vypln ná p íloha č. 3 této Zadávací dokumentace (platí pouze pro část 1),
· vypln ná p íloha č. 8 této Zadávací dokumentace – Zvýhodn né funkcionality (platí
pouze pro část 1)
· audiovizuální záznam (dále také „AVZ“) vyhotovený účastníkem v souladu
podmínkami uvedenými níže - kapitola č. 10.3 Kritérium č. 3 - Kvalita ešení
„Ergonomie (platí pouze pro část 1)
· návrh implementačního plánu, který popíše ídící mechanismy, bude mít níže
definovanou strukturu a bude obsahovat minimáln (platí pouze pro část 1):

o Organizace, role a zodpov dnost
§ ídící týmy
§ Rozhodovací kompetence až do role vedoucích týmů
§ Součinnost s externím dohledem nad implementací

o Požadavky na součinnost zadavatele v jednotlivých fázích projektu včetn
odhadu časové náročnosti zadavatele

o Procedury a standardy ízení implementace
o Způsob vedení dokumentace projektu
o Zásady pro akceptační ízení
o ízení kvality projektu
o ízení zm n projektu
o ízení rizik projektu
o Definice základních pravidel ešení konfliktů
o Podpora rozvoje
o Návrh zabezpečení aplikačn konzistentní zálohy bez vlivu na výkon systému

41
Pozn.: Návrh implementačního plánu bude rozpracován v rámci tvorby Provád cího
projektu.

· návrhy smluv:
o účastník je povinen vyplnit a použít obligatorní návrh smlouvy o dílo, která je
p ílohou č. 4 zadávací dokumentace (relevantní pro tu část ve ejné zakázky, do
které účastník podává svou nabídku). Úprava závazného návrhu smlouvy
v neprosp ch zadavatele je důvodem vyloučení účastníka z další účasti
v zadávacím ízení.
o účastník je povinen p edložit návrh servisní smlouvy. Součástí nabídky musí
být návrh servisní smlouvy s respektováním smluvních podmínek uvedených
v této zadávací dokumentaci.
Pozn.: Účastník ve své nabídce p edloží návrhy smluv podepsané osobou
oprávn nou jednat jménem či za účastníka. Pokud návrh smlouvy podepíše
zmocn ná osoba, musí být součástí nabídky účastníka též p íslušná platná plná
moc.

· ostatní dokumenty dle uvážení účastníka.
Součástí nabídky musí být návrhy smluv (vč. požadovaných p íloh), podepsané osobou
oprávn nou jednat jménem či za účastníka.
Návrh smlouvy vč. požadovaných p íloh požaduje zadavatel doložit k podané nabídce též
v editovatelném formátu.

Nabídka včetn veškerých požadovaných dokladů musí být zpracována výhradn v českém
jazyce. Toto ustanovení se netýká katalogů a prospektové dokumentace, které mohou být
p edloženy i v jiném, než v českém jazyce. Ta část textu, která se týká nabízeného p edm tu
pln ní, musí být p eložena do češtiny. P eklad musí být jednoznačný. Za jeho správnost ručí
účastník (tato skutečnost musí být v p edložené nabídce uvedena). Doklady ve slovenském
jazyce a doklady o vzd lání v latinském jazyce se p edkládají bez p ekladu.
Veškeré doklady či prohlášení, u nichž je vyžadován podpis účastníka, musí být podepsány
statutárním orgánem účastníka; v p ípad podpisu jinou osobou musí být doklad jejího
zmocn ní doložen v nabídce.
Veškeré doklady musí být kvalitním způsobem zpracovány tak, aby byly dob e čitelné. Žádný
doklad nesmí obsahovat opravy a p episy, které by zadavatele mohly uvést v omyl.

Vyjád ení k jednotlivým požadavkům na p edm t pln ní dle zadávací dokumentace bude
uvedeno způsobem, ze kterého bude jasné, které požadované vlastnosti a funkce navrhované
ešení splňuje.

9 Další podmínky a požadavky zadavatele

Zadavatel si vyhrazuje:
a) právo nevracet podané nabídky,
b) právo vyloučit účastníka ze zadávacího ízení v souladu se zákonem,

42
c) právo zrušit zadávací ízení v souladu se zákonem,
d) právo na poskytnutí objasn ní v nebo dopln ní údajů, dokladů, vzorků nebo modelů

v souladu s § 46 zákona.

Účastníkovi podáním nabídky nevznikají žádná práva na uzav ení smlouvy se zadavatelem.
Účastník nemá nárok na úhradu nákladů, které mu vznikly v souvislosti s účastí na sout ži.

Zadavatel upozorňuje, že nespln ní formálních požadavků zadavatele na obsah nabídky nebo
na její zpracování může být důvodem k vyloučení účastníka ze zadávacího ízení. Zadavatel
bude p i nespln ní takto stanovených formálních požadavků postupovat p i svém rozhodování
v souladu s platnou právní úpravou a judikaturou vztahující se k této oblasti.

10 Hodnocení nabídek

Část 1
Hodnocení nabídek podaných pro část 1 bude provedeno dle jejich ekonomické výhodnosti
na základ nejvýhodn jšího pom ru nákladů životního cyklu a kvality. Hodnocení nabídek
podle pravidel stanovených v ZD provede hodnotící komise. Zadavatel/hodnotící komise si
vyhrazuje právo p izvat odborníky a použít jejich vyjád ení pro své rozhodování.

U každé nabídky budou sečteny body získané v jednotlivých hodnotících kritériích. Poté
budou nabídky se azeny sestupn podle počtu získaných bodů. Jako nejvýhodn jší bude
hodnotící komisí označena nabídka, která získala nejvíce bodů.

UPOZORN NÍ:
V p ípad rovnosti nejvyššího počtu celkových dosažených bodů více účastníky rozhoduje o
po adí vyšší počet bodů za kvalitu, který bude stanoven na základ součtu dosažených bodů v
rámci dílčích hodnotících kritérií č. 2, 3 a 4. V p ípad rovnosti i takto stanovených bodů za
kvalitu rozhodne o celkovém po adí los. Losování prob hne v termínu stanoveném
zadavatelem. Účastníci, u kterých byl počet bodů dle výše uvedeného postupu shodný, mají
právo se losování účastnit.

P i azená váha k jednotlivým dílčím hodnotícím kritériím vyjad uje stupeň jejich významu
pro zadavatele. Pro účely hodnocení nabídek stanovil zadavatel následující dílčí hodnotící
kritéria:

Dílčí hodnotící kritéria Váha

Náklady životního cyklu - celková nabídková cena v Kč vč. DPH
tvo ená součtem nabídkové ceny za dodávku IS, nabídkové ceny
1 za servisní podporu u dodaného IS č. 1 a nabídkové ceny za 50 %

servisní podporu u dodaného IS č. 2. Pro účely hodnocení jsou
rozhodné informace uvedené v krycím listu (viz p íloha č. 1 ZD).

2 Kvalita ešení „Povinné požadavky“ 15%

3 Kvalita ešení „Ergonomie“ 30%

43
4 Kvalita ešení „Nice to have“ 5%

Hodnotící komise ohodnotí všechny nabídky, které nebyly ze zadávacího ízení vy azeny.
Hodnocení kvalitativních dílčích hodnotících kritérií u nabízeného informačního systému
bude provád no na základ p edloženého audiovizuálního záznamu (AVZ) a dle informací
uvedených v nabídce účastníka.

10.1 Kritérium č. 1 – Náklady životního cyklu

Hodnocená nabídka získá bodovou hodnotu, která vznikne násobkem 100 a pom ru hodnoty
nejnižších nákladů životního cyklu k nákladům životního cyklu hodnocené nabídky. Výsledná
bodová hodnota bude následn p epočtena vahou dílčího kritéria (váha 50%) a zaokrouhlena
matematicky na 2 desetinná místa.

10.2 Kritérium č. 2 – Kvalita ešení „Povinné požadavky“

Zvýhodn né funkcionality klinického informačního systému, kterým zadavatel p isoudil
kvalitativní význam nabízeného klinického informačního systému v rámci kritéria č. 2, jsou
uvedeny v p íloze č. 8. Takto stanovené zvýhodn né funkcionality informačního systému mají
pro zadavatele oproti vymezenému minimálnímu stavu p idanou užitnou hodnotu.

Pro účely hodnocení budou rozhodující a závazné informace uvedené účastníkem v podané
nabídce, a to na základ vypln né p ílohy č. 8 této Zadávací dokumentace.
U každé položky zvýhodňující funkcionality informačního systému, kterou zadavatel stanovil
v p íloze č. 8, budou p id lovány dílčí body dle následující hodnotící škály:

0 bodů - účastníkem nabízený klinický informační systém neobsahuje ke dni podání
nabídky zvýhodn nou funkcionalitu dle p ílohy č. 8,

1 bod - účastníkem nabízený klinický informační systém obsahuje ke dni podání
nabídky funkční zvýhodn nou funkcionalitu dle p ílohy č. 8.

Následn bude stanovena u hodnocené nabídky celková dosažená bodová hodnota, která se
stanoví jako součet získaných bodů za jednotlivé zadavatelem zvýhodn né funkcionality
informačního systému. Takto získaná bodová hodnota se dosadí do níže uvedeného vzorce a
stanoví se výsledná bodová hodnota, kterou hodnocená nabídka získá v rámci tohoto kritéria.
Výsledná bodová hodnota bude následn zaokrouhlena matematicky na 2 desetinná místa.

Vzorec pro výpočet výsledné bodové hodnoty:
Výsledná bodováhodnota = 100´ celkovábodová hodnota hodnocené nabídky ´ 0,15

nejvyšší dosažená celkovábodováhodnota

Pozn.: Pojmem „Nejvyšší dosažená celková bodová hodnota“ se rozumí celková dosažená
bodová hodnota, která bude ze strany zadavatele p id lena té nabídce, která bude obsahovat

44
nabídku na dodávku klinického informačního systému s nejv tším počtem p iznaných
zvýhodn ných funkcionalit.

10.3 Kritérium č. 3 – Kvalita ešení „Ergonomie“

P edm tem tohoto kritéria je hodnocení ergonomických vlastností nabízeného klinického
informačního systému, a to na základ účastníkem v nabídce p edloženého AVZ. Požadavky
na zpracování a obsah AVZ jsou uvedeny v kapitole č. 10 a v p íloze č. 9 této Zadávací
dokumentace. V rámci dílčího kritéria č. 3 „Ergonomie“ byla ze strany zadavatele stanovena
pro hodnocení následující subkritéria:

Poř. číslo Subkrit érium Váha v %
10
1 Grafické provedení nabídek a podnabídek 10
2 10
3 Přítomnost navigačních prvků 10
4 Grafika a symboly ikon ovládacích prvků 20
5 Kontextová nápověda
Prostorové, systematické a grafické uspořádání pracovních ploch, karet, 20
6 objektů a ovládacích prvků
10
7 Hlavní ovládací prvky systému pro často používané činnosti/ funkce (např.
10
8 uložit, tisknout), objekty identifikující pacienta a objekty identifikující do

systému přihlášeného uživatele
Počet kroků/ operací k dosažení požadovaného následku

Přítomnost a rozsah automatizovaných, kontrolních, vyhledávacích a
filtračních funkcí

Pravidla pro hodnocení jednotlivých subkritérií:
Subkritérium č. 1 „Grafické provedení nabídek a podnabídek“:
0 bodů- Grafické provedení nabídek a podnabídek není pro uživatele dob e čitelné a nejasn

je mezi sebou odd luje.
1 bod - Grafické provedení nabídek a podnabídek není pro uživatele dob e čitelné nebo je

nejasn mezi sebou odd luje.
3 body - Grafické provedení nabídek a podnabídek je pro uživatele dob e čitelné a z eteln je

mezi sebou odd luje.

Subkritérium č. 2 „P ítomnost navigačních prvků“:
0 bodů - Chyb jící navigační prvky anebo jejich rozsah v jednotlivých krocích neumožňuje

uživateli snadnou orientaci a rychlý pohyb v aplikaci.
3 body - P ítomnost a rozsah navigačních prvků umožňuje uživateli v jednotlivých krocích

snadnou orientaci a rychlý pohyb v aplikaci.

Subkritérium č. 3 „Grafika a symboly ikon ovládacích prvků“:
0 bodů - Grafika a symboly ikon ovládacích prvků nereflektují, pop . z v tší části nereflektují

z pohledu uživatele jejich obsah anebo nejsou nap íč celým systémem mezi
jednotlivými obrazovkami konzistentní.

45
1 bod - Grafika a symboly ikon ovládacích prvků p evážn reflektují z pohledu uživatele
jejich obsah a jsou nap íč celým systémem mezi jednotlivými obrazovkami
konzistentní.

3 body - Grafika a symboly ikon všech ovládacích prvků reflektují z pohledu uživatele jejich
obsah a jsou nap íč celým systémem mezi jednotlivými obrazovkami konzistentní.

Subkritérium č. 4 „Kontextová nápověda“:
0 bodů - Kontextová nápov da není pro uživatele srozumitelná.
1 bod - Kontextová nápov da je pro uživatele srozumitelná a není stručná.
3 body - Kontextová nápov da je pro uživatele stručná a srozumitelná.

Subkritérium č. 5 „Prostorové, systematické a grafické uspo ádání pracovních ploch, karet,
objektů a ovládacích prvků“:
0 bodů - Prostorové, systematické a grafické uspo ádání pracovních ploch, karet, objektů a

ovládacích prvků nep ispívá k pocitu pracovního komfortu anebo k maximálnímu
využití výkonností kapacity uživatele. Uživatel má zejména pocit nep im ené
složitosti a nep ehlednosti (složitá, matoucí či nejasná logika uspo ádání pracovních
ploch, karet, objektů a ovládacích prvků).
3 body - Prostorové, systematické a grafické uspo ádání pracovních ploch, karet, objektů a
ovládacích prvků umožňuje uživateli snadnou orientaci ve funkcionalitách systému
a procesu, p ispívá k pocitu pracovního komfortu anebo maximálního využití
výkonností kapacity uživatele. Systém na uživatele působí jako p ehledný a
intuitivní.

Subkritérium č. 6 „Hlavní ovládací prvky systému pro často používané činnosti/funkce (nap .
uložit, tisknout), objekty identifikující pacienta a objekty identifikující do systému
p ihlášeného uživatele“:
0 bodů - Hlavní ovládací prvky systému pro často používané činnosti/funkce (nap . uložit,

tisknout) anebo objekty identifikující pacienta nebo objekty identifikující do
systému p ihlášeného uživatele m ní své umíst ní na pracovní ploše nebo nejsou
uživateli stále snadno dostupné a viditelné.
1 bod - Objekty identifikující pacienta a objekty identifikující do systému p ihlášeného
uživatele nem ní své umíst ní na pracovní ploše a jsou uživateli stále snadno
dostupné a viditelné. Hlavní ovládací prvky systému pro často používané
činnosti/funkce (nap . uložit, tisknout) m ní své umíst ní na pracovní ploše nebo
nejsou uživateli stále snadno dostupné a viditelné.
3 body - Hlavní ovládací prvky systému pro často používané činnosti/funkce (nap . uložit,
tisknout), objekty identifikující pacienta a objekty identifikující do systému
p ihlášeného uživatele nem ní své umíst ní na pracovní ploše a jsou uživateli stále
snadno dostupné a viditelné.

Subkritérium č. 7 „Počet kroků/operací k dosažení požadovaného následku“:
0 bodů - Systém z hlediska počtu kroků/operací nezbytných k dosažení požadovaného

následku působí na uživatele jako náročný/nep im ený anebo výskyt sloučených
funkcí do jediného funkčního p íkazu (nap . tisk + uložení, uložení + zav ení aj.) je
v oblasti uživatelského ovládání ojedin lý/omezený, a to nap íč systémem.
Z hlediska uživatele je v rámci hodnoceného parametru systém vnímám jako mén
efektivní.

46
3 body - Systém z hlediska počtu kroků/operací nezbytných k dosažení požadovaného
následku považuje uživatel za nenáročný a v rámci hodnoceného parametru je ze
strany uživatele vnímán jako efektivní. Výskyt sloučený funkcí do jediného
funkčního p íkazu (nap . tisk + uložení, uložení + zav ení aj.) je v oblasti
uživatelského ovládání b žnou součástí systému.

Subkritérium č. 8 „P ítomnost a rozsah automatizovaných, kontrolních, vyhledávacích a
filtračních funkcí“:
0 bodů - Nabízený systém obsahuje automatizované, kontrolní, vyhledávací a filtrační funkce

a jejich míra dostupnosti dostatečn nezajišťuje minimalizaci vzniku
potencionálních chyb.
1 bod - Nabízený systém obsahuje automatizované, kontrolní, vyhledávací a filtrační funkce a
jejich dostupnost nap íč celým systémem zajišťuje minimalizaci vzniku
potencionálních chyb. Vyhledávací anebo filtrační funkce jsou k dispozici pro
uživatele v omezeném rozsahu anebo vyhledávací a filtrační funkce neumožňují
uživatelsky komfortním způsobem získat veškeré nezbytné provozní data v čase
pot eby nap íč celým systémem. Za uživatelsky komfortní způsob se nepovažují
filtrační a vyhledávací funkce definované uživatelem nap . za pomocí SQL dotazu či
jiného programovacího jazyka. Snížený počet bodů obdrží i nabídka takového
systému, která i p es kladné hodnocení vyhledávacích a filtračních funkcí nebude
obsahovat v rámci kontrolních funkcí dostatečn efektivní systém pro odstraňování
chyb (nap . pro uživatele nejasná/nesrozumitelná chybová hlášení, složité
vyhledávání chybn uvedeného/nevypln ného údaje).
3 body – Nabízený systém obsahuje automatizované, kontrolní, vyhledávací a filtrační funkce
a jejich dostupnost nap íč celým systémem zajišťuje minimalizaci vzniku
potencionálních chyb. Vyhledávací a filtrační funkce jsou uživatelsky komfortní a
p edstavují pro uživatele efektivní nástroj pro získání veškerých nezbytných
provozních dat v čase pot eby nap íč celým systémem. Nabízený systém umožňuje
uživateli provést efektivní/rychlé odstran ní identifikovaných chyb.

Požadavky na audiovizuální záznam (AVZ)
· AVZ, včetn jeho kopie, musí být zadavateli doručen ve lhůt pro podání nabídek
osobn nebo doporučen poštou (či jinou obdobnou p epravou) na adresu Fakultní
nemocnice Hradec Králové, Odd lení ve ejných zakázek, budova č. 29, Sokolská 581,
500 05 Hradec Králové – Nový Hradec Králové. AVZ, včetn jeho kopie, musí být
doručen v uzav ené neporušené obálce či jiném vhodném obalu (zabraňujícím
poškození jeho obsahu) s nápisem „Modernizace IT FN HK v návaznosti na eHealth –
AVZ“. Na obálce/obalu musí být dále uvedena kontaktní adresa účastníka, k jehož
nabídce se doručený AVZ vztahuje.
· Zadavatel požaduje, aby soubory obsahující AVZ byly dodány na datových nosičích
CD/DVD nebo nosičích p ipojitelných pomocí USB 3.0 nebo nov jším a ve formátu
(dále jen „datové nosiče“), který musí být p ehratelný voln dostupnými p ehrávači na
PC s operačním systémem Microsoft Windows 10. Každý soubor obsahující AVZ
musí být uložen duplicitn (originál + záloha). Originální soubory a zálohové soubory
musí být uloženy zvlášť, a to na samostatném datovém nosiči. Účastník dodá AVZ

47
ve lhůt pro podání nabídek minimáln na dvou samostatných datových nosičích .
Každý datový nosič musí být pojmenován. Datové nosiče obsahující originální
soubory AVZ musí být označeny jako „Originál + po adové číslo datového nosiče“,
datové nosiče obsahující zálohu souborů AVZ musí být označeny jako „Záloha +
po adové číslo datového nosiče“.

· AVZ musí být po ízen pomocí aplikace pro snímání pracovní plochy (obrazovky PC),
na které bude zobrazován nabízený KIS. V rámci záznamu musí být zachycena celá
obrazovka a její záznam musí být ve form videa (nikoli jako sada či soubor obrázků).
V rámci záznamu nesmí být p idávány žádné efekty (animace) či barevné klíčování,
které nejsou vlastnostmi nabízeného KIS. Záznam musí být po ízen minimáln
v rozlišení 1280x1024 bez komprese videa.

· Zadavatel požaduje, aby AVZ každého scéná e, který je uveden v p íloze č. 9, byl
uložen samostatn do vlastního souboru (soubor musí vždy obsahovat AVZ
kompletního scéná e tak, jak je definován v p íloze č. 9). Soubory obsahující AVZ
jednotlivých scéná ů musí být označeny názvem souboru ve form slovního popisu
„Scenar“ a po adového čísla zaznamenaného scéná e (nap . pro scéná 001 -
Scenar_001.avi).

· K jednotlivým souborům AVZ (dle počtu scéná ů) uloženým na datovém nosiči musí
být vytvo eny kontrolní součty za použití secure hash algoritmu SHA-256. Soubory
s kontrolními součty musí být uloženy na dodaných datových nosičích a jejich
hodnoty musí být totožné s kontrolními součty jednotlivých souborů AVZ uložených
na datových nosičích.

· Součástí doručené obálky/obalu musí být krom datových nosičů rovn ž dokument
podepsaný osobou oprávn nou jednat jménem či za účastníka, který bude obsahovat
následující informace (pro každý datový nosič zvlášť):
§ název datového nosiče,
§ názvy jednotlivých souborů AVZ, které jsou uloženy na datovém nosiči,
§ hodnoty kontrolních součtů generovaných secure hash algoritmem SHA-256
pro jednotlivé soubory AVZ uložené na datovém nosiči,
§ datum a čas (hodina, minuta) zm ny souboru AVZ umíst ném na datovém
nosiči – zadavatel upozorňuje, že datum a čas zm ny souboru AVZ na
datovém nosiči musí p edcházet uplynutí lhůty pro podání nabídek, resp.
termínu, kdy byla obálka/obal zadavateli doručen. V opačném p ípad ,
nebude-li možné zp tn objektivn prokázat doručení souborů AVZ ve lhůt
pro podání nabídek, bude nabídka zatížená touto vadou vyloučena z další
účasti ze zadávacího ízení.

· Celková délka AVZ (všech souborů obsahujících AVZ) nesmí v součtu p esáhnout 6
hodin.

· Pro jednotlivé scéná e v rámci AVZ musí být systém nastaven tak, aby zobrazení
nabízeného KIS v rámci AVZ odpovídalo situaci, jako by byl KIS provozován na
monitorech s rozlišením 1280x1024. Součástí prvního AVZ musí být záznam o
nastavení operačního systému na požadované rozlišení. Toto rozlišení musí být
zachováno nap íč celým AVZ nabízeného klinického informačního systému (tzn.
veškeré soubory obsahující AVZ musí být vytvo eny p i takto definovaném rozlišení).
Jiný parametr rozlišení, než zde uvedený, není pro účely hodnocení AVZ p ípustný.

48
· Na datových nosičích musí být uloženy všechny soubory obsahující AVZ ke všem
Zadavatelem požadovaným scéná ům. Rozsah scéná ů, včetn dalších pokynů pro
vyhotovení AVZ, jsou Zadavatel stanoveny v p íloze č. 9. Jednotlivé body scéná e
musí být v rámci AVZ prezentovány v po adí a posloupnosti, ve kterém jsou uvedeny
v p íloze č. 9 ZD. Jednotlivé kroky scéná ů musí být vždy čteny/uvád ny p ed
samotným p edvedením bodu.

· Pokud účastník bude v souladu s podmínkami uvedenými v p íloze č. 9 používat pro
n které akce/úkony klávesnici (zejména klávesové zkraty, funkční klávesy), vyjma
úkonů souvisejících s použitím klávesnice p i psaní textu, je v takovém p ípad
účastník povinen p ed takto zamýšleným způsobem použití klávesnice tento způsob
v AVZ popsat (nap . jaká klávesová zkratka/funkční klávesa bude použita a za účelem
jakého úkonu), a to slovním komentá em.

· Pokud jsou ve scéná ích uvedeny hodnoty k vypln ní, účastník v rámci AVZ musí tyto
hodnoty respektovat a nezadávat hodnoty jiné. Dtto platí i pro situace, kdy zadavatel
v p íloze č. 9 p íslušného scéná e vymezí p esný rozsah informací, které účastník bude
zadávat. Pokud by p edvád ný systém nedovolil zadání požadované hodnoty nebo
zadání hodnoty je pro navazující úkon nezbytné, opraví/doplní účastník hodnoty
v t chto polí až po neúsp šném pokusu. Účastník je povinen v takových situacích na
AVZ zachytit a popsat p ípadný kontrolní mechanismus, chybová hlášení, jejich
obsah, způsob vyhledání identifikovaných chyb a jejich odstran ní (bude-li to pro
danou situaci p íznačné).

· V p ípad , že systém n kterou funkcionalitu či úkon uvedený ve scéná i neumožňuje,
musí účastník tuto informaci sd lit slovn v rámci AVZ.

Pro účely objektivního posouzení míry ergonomie zadavatel určí skupinu osob, která bude
tvo ena z vybraných zam stnanců zadavatele anebo jiných osob. Každý člen z této skupiny
bude jednotlivá subkritéria hodnotit samostatn a nezávisle na ostatních členech skupiny na
základ AVZ.

Bodová hodnota v rámci dílčího subktritéria bude stanovena na základ součtu p id lených
bodů od všech členů skupiny, která bude p epočtena váhou daného subkritéria.

Výsledná bodová hodnota v rámci dílčího kritéria č. 3 bude stanovena na základ
následujícího vzorce:

Výsledná bodováhodnota = 100 ´ sumabodů za subkritéria ´ 0,30

nejvyšší suma dosažených bodů za subkritéria

Pozn.: Pojmem „Nejvyšší suma dosažených bodů za subkritéria“ se rozumí celková dosažená
bodová hodnota, která bude p id lena té nabídce, která bude obsahovat nabídku na dodávku
klinického informačního systému s nejv tším počtem p iznaných bodů v rámci tohoto kritéria.

Výsledná bodová hodnota se zaokrouhluje matematicky na 2 desetinná místa.

49
10.4 Kritérium č. 4 – Kvalita ešení „Nice to Have“

Rozši ující funkcionality informačního systému (dále také „kategorie „Nice to Have“), kterým
zadavatel p isoudil kvalitativní význam nabízeného klinického informačního systému v rámci
kritéria č. 4, jsou uvedeny v p íloze č. 3 a vyznačeny ve sloupci Z písmenem N. Takto
stanovené funkcionality klinického informačního systému mají pro zadavatele p idanou
užitnou hodnotu.

U každého požadavku kategorie „Nice to Have“ budou p id lovány dílčí body dle následující
hodnotící škály:

0 bodů - účastník daný požadavek kategorie „Nice to Have“ nenabízí (v p íloze č. 3
vybral možnost „N“).

1 bod - účastník daný požadavek kategorie „Nice to Have“ nabízí (v p íloze č. 3
vybral možnost S nebo D).

Následn bude stanovena u hodnocené nabídky celková dosažená bodová hodnota, která se
stanoví jako součet získaných bodů za jednotlivé nabídnuté položky kategorie „Nice to
Have“, které jsou uvedeny v p íloze č. 3. Takto získaná bodová hodnota se dosadí do níže
uvedeného vzorce a stanoví se výsledná bodová hodnota, kterou hodnocená nabídka získá
v rámci tohoto kritéria. Výsledná bodová hodnota bude zaokrouhlena matematicky na 2
desetinná místa.

Vzorec pro výpočet výsledné bodové hodnoty:

Výsledná bodová hodnota = 100 ´ celková bodová hodnota hodnocené nabídky ´ 0,05
maximální bodová hodnota

Pozn.: Pojmem „Maximální bodová hodnota“ se rozumí celková bodová hodnota, kterou by
nabídka získala v p ípad , že by byl nabídnut takový informační systém, který splňuje veškeré
požadavky kategorie „Nice to Have“.

Účastníkem nabízená kategorie „Nice to Have“ musí být nedílnou součástí jeho nabídky (tzn.
účastník je povinen veškeré nabízené funkcionality kategorie „Nice to Have“ dodat jako
nedílnou součást pln ní p edm tu ve ejné zakázky).

Část 2
Hodnocení nabídek podaných pro část 2 bude provedeno dle jejich ekonomické výhodnosti,
p ičemž jediným hodnotícím kritériem jsou nejnižší celkové náklady životního cyklu v Kč vč.
DPH tvo ené součtem nabídkové ceny za dodávku ZDDA a nabídkové ceny za servisní
podporu u dodaného ZDDA. Pro účely hodnocení jsou rozhodné informace uvedené v
krycím listu (viz p íloha č. 1 ZD). Hodnocení nabídek podle pravidel stanovených v ZD
provede hodnotící komise. Zadavatel/hodnotící komise si vyhrazuje právo p izvat odborníky a
použít jejich vyjád ení pro své rozhodování.

11 Výb r dodavatele

50
Zadavatel uzav e po vyhodnocení této ve ejné zakázky s vít zným účastníkem následující
smlouvy:

· smlouvu o dílo
· servisní smlouvu na dobu neurčitou.
UPOZORN NÍ
U vybraného dodavatele, je-li právnickou osobou, zadavatel zjistí údaje o jeho skutečném
majiteli podle zákona o n kterých opat eních proti legalizaci výnosů z trestné činnosti a
financování terorismu (dále jen "skutečný majitel") z evidence údajů o skutečných majitelích
podle zákona upravujícího ve ejné rejst íky právnických a fyzických osob. Zjišt né údaje
zadavatel uvede v dokumentaci o ve ejné zakázce. Pro tyto účely umožní Ministerstvo
spravedlnosti zadavateli dálkový p ístup k údajům o skutečném majiteli podle zákona
upravujícího ve ejné rejst íky právnických a fyzických osob; pro účely výkonu dozoru podle
části t inácté hlavy II umožní takový p ístup Ministerstvo spravedlnosti také Ú adu pro
ochranu hospodá ské sout že.

Nelze-li zjistit údaje o skutečném majiteli postupem podle p edchozího odstavce, zadavatel
vyzve vybraného dodavatele k p edložení výpisu z evidence obdobné evidenci údajů o
skutečných majitelích nebo

a) ke sd lení identifikačních údajů všech osob, které jsou jeho skutečným, a
b) k p edložení dokladů, z nichž vyplývá vztah všech osob podle písmene a) k

dodavateli; t mito doklady jsou zejména
1. výpis z obchodního rejst íku nebo jiné obdobné evidence,
2. seznam akcioná ů,
3. rozhodnutí statutárního orgánu o vyplacení podílu na zisku,
4. společenská smlouva, zakladatelská listina nebo stanovy.

V p ípad , že vybraný dodavatel nesplní shora uvedené povinnosti, bude zadavatelem ze
zadávacího ízení vyloučen.
Zadavatel je dále povinen vyloučit vybraného dodavatele též v p ípad , pokud z informací
vedených v obchodním rejst íku vyplývá, že vybraný dodavatel je akciovou společností nebo
má právní formu obdobnou akciové společnosti a nemá vydány výlučn zaknihované akcie.
Vybraný dodavatel se sídlem v zahraničí, který je akciovou společností nebo má právní formu
obdobnou akciové společnosti, je povinen na základ výzvy zadavatele p edložit písemné
čestné prohlášení o tom, které osoby jsou vlastníky akcií, jejichž souhrnná jmenovitá hodnota
p esahuje 10 % základního kapitálu účastníka zadávacího ízení, s uvedením zdroje, z n hož
údaje o velikosti podílu akcioná ů vychází.

V p ípad , že zadavatel vyloučí vybraného účastníka zadávacího ízení, vyzve zadavatel
k poskytnutí součinnosti k uzav ení smluv dalšího účastníka zadávacího ízení, a to v po adí,
které vyplývá z výsledku hodnocení nabídek. Do uzav ení smluv může zadavatel p i výb ru
dodavatele postupovat opakovan , a to v souladu s § 125 odst. 2 zákona.

Součinnost před uzavřením smlouvy:
Zadavatel v souladu s § 104 písm. e) zákona sd luje, že bude od vybraného dodavatele jako
další podmínku pro uzav ení smlouvy požadovat součinnost v podob prezentace nabízeného
informačního systému p ed uzav ením smlouvy.

51
Účelem p edvedení (prezentace) nabízeného informačního systému je ov ení nabízeného
pln ní v návaznosti na p edloženou nabídku (dále jen „prezentace“).

Prezentace bude provedena na základ písemné výzvy zadavatele (dále jen „výzva“) doručené
účastníkovi s p edstihem alespoň 5 pracovních dnů. Prezentace prob hne dle pokynů
zadavatele, a to v termínu, čase a prostorách určených zadavatelem ve výzv (vždy v Hradci
Králové).
Nabízený klinický informační systém bude účastníkem pro účely prezentace p ednastaven na
práci s databází dopln nou o minimáln 1000 vzorových pacientů, z toho alespoň 10 pacientů
s nejmén 100 dokumenty zdravotnické dokumentace, 100 dokumenty žádanek, 10
dokumenty laboratorních výsledků s minimálním množstvím 100 metod v součtu.
Účastník je povinen p edvést funkční klinický informační systém v podob pln funkční verze
v režimu b žného provozu. Je nep ípustné p edvedení v podob pouhé animace, pop . snímků
obrazovky.
Další požadavky na pot ebná data, která budou prezentována, jsou blíže specifikovány
v p íloze č. 5 zadávací dokumentace.
Zadavatel upozorňuje účastníky, že z prezentace bude po izován audiovizuální (AV) záznam.
Zpracování AV záznamu bude probíhat v souladu s p íslušnými právními p edpisy na ochranu
osobních údajů, zejména v souladu s Na ízením 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ů). Pracovníci účastníka, kte í budou prezentovat, podepíší
p ed zahájením prezentace souhlas (p edložený zadavatelem) s po ízením a použitím AV
záznamu. Tento AV záznam bude použit výhradn pro účely zadávacího ízení a archivován
po dobu stanovenou zákonem a podmínkami poskytovatele dotace. Souhlas s po ízením AV
záznamu je podmínkou pro poskytnutí součinnosti p ed podpisem smlouvy. Zadavatel
upozorňuje, že odmítne-li pracovník účastníka podepsat zadavatelem p edkládaný souhlas
s po ízením a použitím AV záznamu, bude tento krok považován za neposkytnutí součinnosti
p ed podpisem smlouvy.

Technické podmínky prezentace:
1. Účastník si pro prezentaci zajistí takové technické vybavení, které umožní
demonstraci funkce nabízeného technického ešení a napln ní podmínek zákona
č.181/2014 Sb., o kybernetické bezpečnosti, ve zn ní novel a doplňků, tj. i sm rnice
GDPR. Pro pot eby prezentace stačí single server bez clusteru a replikace, rovn ž
storage pro demo postačí lokální bez replikace.
2. Účastník provede prezentaci na minimáln dvou současn pracujících klientských
stanicích.

52
3. Zadavatel neposkytne pro prezentaci své klientské stanice. Zadavatel požaduje
prezentaci na klientské stanici dle specifikace v kapitole 4.4 s operačním systémem
Windows 7 nebo Windows 10 ve variant x64.

4. Účastník použije p i prezentaci nejmén jednu tiskárnu a nejmén jednu čtečku
čárových kódů.

5. Zadavatel v místnosti určené pro prezentaci garantuje dostupnost internetu
prost ednictvím LAN -RJ45 (reálná ší ka pásma 80Mbps symetricky k poskytovateli
internetu).

6. Zadavatel poskytne dva FullHD projektory.

Náklady na prezentaci si nese každá strana samostatn .

Průb h prezentace

Zadavatel si vyhrazuje právo p izvat pro účely ov ení nabízeného pln ní komisi odborníků.
Vlastní prezentace bude proces ízený vedoucím komise odborníků.

Na p ípravu prezentace v zadavatelem určených prostorách bude účastníkovi poskytnuta 1
hodina.
V úvodu má účastník vyhrazený prostor cca 15 min. pro prezentaci nezbytných informací
o fungování KIS. Tím je myšleno:

1. vysv tlit uspo ádání formulá ů na obrazovce a logiku ovládání,
2. popsat orientačním způsobem funkcionality KIS pro vyt žování dat zdravotníky,

personálem využívajícím ekonomicko-výkaznické funkce a dle časových možností i
IT specialisty, které pak budou demonstrovány v průb hu prezentace.
Pro prezentaci platí:
· Nemá smysl prezentovat funkcionality a vlastnosti nabízeného systému, které jsou nad
rámec požadavků zadavatele stanovených v zadávací dokumentaci.
· Účastníkem zvolené informace mohou být sd leny libovolnou formou, nicmén
žádáme maximální úspornost sd lení cíleného na informace relevantní pro vlastní
prezentaci!

Prezentace nabízeného KIS proběhne dle scénářů popsaných v příloze č. 5 zadávací
dokumentace.

Cílem prezentace je ízeným způsobem oddemonstrovat na živém informačním systému
(KIS) všechny zadavatelem vybrané povinné požadavky na funkcionality KIS definované
v p íloze č. 3 na modelových situacích/scéná ích specifikovaných v p íloze č. 5, vč. v nabídce
doložené ergonomie a deklarovaných zvýhodňujících funkcionalit. Zadavatelem vybrané
povinné požadavky (atribut „P“) pro účely ov ení funkcionalit nabízeného technického
ešení jsou uvedeny v p íloze č. 3 a jsou zvýrazn ny zelenou barvou. Zadavatel nebude
v rámci prezentace provád t kontrolu spln ní veškerých povinných požadavků (atribut „P“)
stanovených v p íloze č. 3.

53
Závazné pokyny pro prezentující osoby účastníka v průběhu prezentace:
· Prezentace slouží výhradn k deklaraci jednotlivých kroků sout žních scéná ů
v souladu s informacemi p edloženými v nabídce.
· Jednotlivé kroky scéná ů budou čteny/uvád ny vedoucím nebo vybranými členy
komise odborníků; zadavatel v rámci prezentace s ohledem na časovou náročnost
celého procesu očekává situaci, kdy komise odborníků bude pouze sledovat d je na
obrazovkách demonstrovaného živého KIS v průb hu pln ní scéná ů.
· Prezentace není určena k demonstraci potencionálních možností nabízeného systému,
a to ani formou ústního sd lení, ani promítáním jakékoli formy prezentace. Na
nežádoucí prezentaci budou osoby účastníka upozorn ny vedoucím komise odborníků
a na jeho pokyn je musí neprodlen ukončit. Pokud tak neučiní, bude takovéto jednání
považováno za neposkytnutí součinnosti p ed podpisem smlouvy.
· Dotazy vedoucího komise odborníků vůči prezentujícím osobám nejsou limitovány.

Účastník je povinen v rámci prezentace ukázat i nabízené zvýhodn né funkcionality, které
jsou součástí jeho nabídky, a které byly ze strany zadavatele stanoveny jako součást dílčího
hodnotícího kritéria „Kvalita ešení – povinné požadavky“. Účastník je povinen zadavatele na
veškeré nabízené zvýhodn né funkcionality p edem upozornit. Účastníkem veškeré
prezentované nabízené zvýhodn né funkcionality jsou nedílnou součástí jeho nabídky (tzn.
účastník je povinen veškeré prezentované nabízené zvýhodn né funkcionality dodat jako
nedílnou součást pln ní p edm tu ve ejné zakázky).

Účastníkem prezentovaný KIS musí disponovat takovými ergonomickými vlastnostmi, které
budou shodné s podanou nabídkou (tj. vlastnostmi doloženými prost ednictvím AVZ).

Veškeré účastníkem prezentované vlastnosti systému (včetn funkcionalit) musí být nedílnou
součástí jeho nabídky (tzn. účastník je povinen veškeré prezentované vlastnosti dodat jako
nedílnou součást pln ní p edm tu ve ejné zakázky).

V p ípad , že z prezentovaného KIS bude z ejmé, že:
· veškeré zadavatelem vybrané povinné požadavky definované v p íloze č. 3 nejsou
spln né,
· systém nebo funkcionality nejsou funkční nebo jsou omezen funkční,
· není pln v souladu s podanou nabídkou (vč. zvýhodn ných funkcionalit, ergonomie),

bude tento stav považován na nesoulad prezentovaného KIS s p edloženou nabídkou.
V takovém p ípad bude nabídka účastníka vyloučena z další účasti v zadávacím ízení.

V p ípad , že prezentovaný KIS nebude ádn nastaven v souladu s podmínkami uvedenými
v zadávací dokumentaci, nebude prezentace KIS p ipravena v termínu nebo čase v prostorách
určených zadavatelem nebo nebude provedena prezentace KIS ve stanoveném rozsahu, bude
toto považováno za neposkytnutí součinnosti.

12 Požadavek zadavatele na poskytnutí jistoty

Zadavatel v souladu s § 41 zákona požaduje pro část 1 poskytnutí jistoty.

54
Zadavatel požaduje jistotu ve výši 1 000 000,- Kč.

Jistotu poskytne účastník zadávacího ízení v souladu se zn ním § 41 odst. 3 zákona a násl.
P i složení jistoty (pen žní částky) na účet zadavatele musí být uvedená částka p ipsána na
účet zadavatele, který je vedený u České národní banky, č. účtu 110007-24639511/0710,
variabilní symbol Z2019022009.
Zadavatel požaduje v takovém p ípad uvést v nabídce číslo účtu včetn bankovního spojení,
na který má být jistota vrácena.
Jistota musí být poskytnuta ve lhůt pro podání nabídek.
Pro část 2 zadavatel jistotu v souladu s § 41 zákona nepožaduje.

13 Rozsah požadavků zadavatele na kvalifikaci

Požadavky na kvalifikaci splňuje účastník, který prokáže:
a) základní způsobilost,
b) profesní způsobilost,
c) ekonomickou kvalifikaci,
d) technickou kvalifikaci.

13.1 Základní způsobilost dle § 74 zákona

Prokázání základní způsobilosti dle § 74 zákona požaduje zadavatel pro ob části ve ejné
zakázky.

Způsobilým není dodavatel, který:
a) byl v zemi svého sídla v posledních 5 letech p ed zahájením zadávacího ízení
pravomocn odsouzen pro trestný čin uvedený v p íloze č. 3 k zákonu nebo obdobný
trestný čin podle právního ádu zem sídla dodavatele; k zahlazeným odsouzením se
nep ihlíží,
b) má v České republice nebo v zemi svého sídla v evidenci daní zachycen splatný
daňový nedoplatek,
c) má v České republice nebo v zemi svého sídla splatný nedoplatek na pojistném
nebo na penále na ve ejné zdravotní pojišt ní,
d) má v České republice nebo v zemi svého sídla splatný nedoplatek na pojistném
nebo na penále na sociální zabezpečení a p ísp vku na státní politiku zam stnanosti,
e) je v likvidaci, proti n muž bylo vydáno rozhodnutí o úpadku, vůči n muž byla
na ízena nucená správa podle jiného právního p edpisu nebo v obdobné situaci podle
právního ádu zem sídla dodavatele.

Prokázání základní způsobilosti

55
Dodavatel prokazuje spln ní podmínek základní způsobilosti ve vztahu k České republice
p edložením

a) výpisu z evidence Rejst íku trestů ve vztahu k § 74 odst. 1 písm. a) zákona,
b) potvrzení p íslušného finančního ú adu ve vztahu k § 74 odst. 1 písm. b) zákona,
c) písemného čestného prohlášení ve vztahu ke spot ební dani ve vztahu k § 74 odst. 1
písm. b) zákona,
d) písemného čestného prohlášení ve vztahu k § 74 odst. 1 písm. c) zákona,
e) potvrzení p íslušné okresní správy sociálního zabezpečení ve vztahu k § 74 odst. 1
písm. d) zákona,
f) výpisu z obchodního rejst íku, nebo p edložením písemného čestného prohlášení v
p ípad , že není v obchodním rejst íku zapsán, ve vztahu k § 74 odst. 1 písm. e)
zákona.

K prokázání základní způsobilosti, kterou účastník prokazuje prost ednictvím čestného
prohlášení, může účastník využít p ílohu č. 6 k této zadávací dokumentaci.

Je-li dodavatelem právnická osoba, musí podmínku podle § 74 odst. 1 písm. a) zákona
splňovat tato právnická osoba a zároveň každý člen statutárního orgánu. Je-li členem
statutárního orgánu dodavatele právnická osoba, musí podmínku podle § 74 odst. 1 písm. a)
zákona splňovat

a) tato právnická osoba,
b) každý člen statutárního orgánu této právnické osoby a
c) osoba zastupující tuto právnickou osobu v statutárním orgánu dodavatele.

Účastní-li se zadávacího ízení pobočka závodu
a) zahraniční právnické osoby, musí podmínku podle § 74 odst. 1 písm. a) zákona
splňovat tato právnická osoba a vedoucí pobočky závodu,
b) české právnické osoby, musí podmínku podle § 74 odst. 1 písm. a) zákona
splňovat osoby uvedené v odstavci 2 a vedoucí pobočky závodu.

13.2 Profesní způsobilost dle § 77 zákona

Prokázání profesní způsobilosti dle § 77 odst. 1 zákona požaduje zadavatel pro ob části
ve ejné zakázky.

Dodavatel prokáže spln ní profesní způsobilosti dle § 77 odst. 1 zákona ve vztahu k České
republice p edložením výpisu z obchodního rejst íku nebo jiné obdobné evidence, pokud jiný
právní p edpis zápis do takové evidence vyžaduje.

13.3 Ekonomická kvalifikace dle § 78 zákona

Zadavatel požaduje v části 1 prokázání ekonomické kvalifikace, kterou je minimální roční
obrat dodavatele dosahující minimální úrovn 20.000.000,- Kč, a to každý rok za 3
bezprost edn p edcházející účetní období; jestliže dodavatel vznikl pozd ji, postačí, p edloží-
li údaje o svém obratu v požadované výši za všechna účetní období od svého vzniku.

56
Dodavatel prokáže obrat výkazem zisku a ztrát dodavatele nebo obdobným dokladem podle
právního ádu zem sídla dodavatele.
Pro část 2 zadavatel prokázání ekonomické kvalifikace dle § 78 zákona nepožaduje.
13.4 Technická kvalifikace dle § 79 zákona

13.4.1 Dle ustanovení § 79 odst. 2 písm. b) zákona – seznam významných dodávek
K prokázání kritérií technické kvalifikace dle § 79 odst. 2 písm. b) zákona zadavatel požaduje
pro každou z částí předložení seznamu alespoň 1 významné zakázky (dodávky/služby, resp.
jejich kombinace) realizované za poslední 3 roky před zahájením zadávacího řízení včetně
uvedení ceny a doby jejich poskytnutí a identifikace objednatele.
Toto technické kvalifikační kritérium splňuje dodavatel, který jednoznačně doloží, že v
uvedeném období realizoval dodávky/služby, resp. jejich kombinaci, kde:
Pro část 1:

Předmětem byla nejméně 1 významná zakázka poskytnutá za poslední 3 roky před
zahájením výběrového řízení, jejímž předmětem byla dodávka nemocničního systému v
nemocnici v hodnotě minimálně 5.000.000,- Kč bez DPH nebo poskytnutí podpory
nemocničního systému v hodnotě 4.500.000,- Kč bez DPH. Požadovaný minimální
finanční objem se musí vztahovat pouze k samotné dodávce, implementaci a podpoře
nemocničního informačního systému, nikoli k dodání souvisejícího hardwaru. Za
nemocniční systém je považován takový, který zajišťuje provoz na ambulancích,
hospitalizační části, operačních sálech a účtování poskytnuté zdravotní péče.
Pro část 2:
Předmětem byla nejméně 1 významná dodávka, kde dodávkou bylo dodání, implementace
nebo servis zabezpečeného dlouhodobého důvěryhodného archivu dat v celkovém
minimálním objemu alespoň 500.000,- Kč bez DPH.

Předložený seznam (platí pro obě části veřejné zakázky) musí zároveň obsahovat identifikační
údaje objednatele a kontaktní údaje na oprávněnou osobu objednatele za účelem případného
ověření si předložených informací, a to alespoň v rozsahu telefonní číslo a e-mail.

13.4.2 Dle ustanovení § 79 odst. 2 písm. c) a d) zákona – seznam techniků a osv dčení o
vzd lání a odborné kvalifikaci fyzických osob odpov dných za poskytování pln ní
Spln ní tohoto bodu technické kvalifikace prokáže dodavatel, který p edloží čestné
prohlášení, v n mž uvede seznam techniků, kte í se budou podílet na pln ní ve ejné zakázky
(realizační tým).
Vymezení minimální úrovn :

57
Realizační tým určený dodavatelem pro pln ní ve ejné zakázky musí mít minimáln
následující složení, p ičemž členové realizačního týmu musí splňovat níže uvedené minimální
požadavky stanovené zadavatelem. Zadavatel neumožnuje plnit více rolí stejnou osobou:
Pro část 1:
1 osoba – vedoucí projektu – disponuje VŠ vzděláním, osv dčení o vzd lání v oblasti
projektového ízení na pokročilé úrovni (nap . Practitioner metodiky PRINCE2), jazykovou znalostí
českého jazyka (případně slovenského) na úrovni pracovní komunikace, v posledních 5 letech
před zahájením zadávacího řízení vedl minimálně 2 zakázky, které spočívaly v dodávce a
implementaci informačního systému. Finanční rozsah u jednoho vedeného projektu byl
minimálně ve výši 50.000.000,- Kč bez DPH a u druhého vedeného projektu byl minimálně
30.000.000,- Kč bez DPH.
1 osoba – hlavní architekt řešení – disponuje VŠ vzděláním, jazykovou znalostí českého
jazyka (případně slovenského) na úrovni pracovní komunikace, v posledních 5 letech před
zahájením zadávacího řízení navrhoval 1 řešení, které spočívalo v dodávce a implementaci
informačního systému ve zdravotnictví. Finanční rozsah provedené zakázky byl minimálně ve
výši 5.000.000,- Kč bez DPH.
1 osoba – senior konzultant – disponuje VŠ vzděláním, jazykovou znalostí českého jazyka
(případně slovenského) na úrovni pracovní komunikace, v posledních 5 letech před zahájením
zadávacího řízení se účastnil minimálně 2 zakázek, které spočívaly v dodávce nebo
implementaci nebo supportu informačního systému ve zdravotnictví. Finanční rozsah
provedené zakázky byl minimálně ve výši 1.000.000,- Kč bez DPH.
3 osoby – konzultant – disponuje minimálně SŠ vzděláním, jazykovou znalostí českého
jazyka (případně slovenského) na úrovni pracovní komunikace, v posledních 5 letech před
zahájením zadávacího řízení se účastnil minimálně 2 zakázek, které spočívaly v dodávce
nebo implementaci nebo služeb supportu informačního systému ve zdravotnictví.
1 osoba – konzultant specialista systému účtování poskytnuté zdravotní péče – disponuje
minimálně SŠ vzděláním, jazykovou znalostí českého jazyka (případně slovenského) na
úrovni pracovní komunikace, v posledních 5 letech před zahájením zadávacího řízení se
účastnil minimálně 1 zakázky, která spočívala v dodávce a implementaci nebo služeb
supportu Nemocničního informačního systému s funkcionalitami pro oblast účtování
poskytnuté zdravotní péče, který pracuje v souladu s platnou legislativou ČR a je
provozovaný poskytovatelem zdravotních služeb, jež je nositelem min. 3 center vysoce
specializované péče v souladu se zákonem č. 372/2011 Sb., o zdravotních službách, v platném
zn ní.
1 osoba – konzultant specialista integrací a výměny dat s napojenými informačními systémy
s využitím integrační platformy - disponuje minimálně SŠ vzděláním, jazykovou znalostí
českého jazyka (případně slovenského) na úrovni pracovní komunikace, v posledních 5 letech
před zahájením zadávacího řízení se účastnil minimálně 2 zakázek v hodnotě min. 1 mil. Kč
bez DPH každá, které spočívaly v dodávce a implementaci nebo služeb supportu, pro
komunikaci mezi systémy.

Pro část 2:
58
1 osoba – konzultant specialista na implementaci dlouhodobého důvěryhodného archívu -
disponuje minimálně SŠ vzděláním, jazykovou znalostí českého jazyka (případně
slovenského) na úrovni pracovní komunikace, v posledních 5 letech před zahájením
zadávacího řízení se účastnil minimálně 2 zakázek v hodnotě min. 1 mil. Kč bez DPH každá,
které spočívaly v dodávce a implementaci nebo služeb supportu, pro dlouhodobý
důvěryhodný archív.
Požadavky společné pro obě části:
Zadavatel v souvislosti s prokázáním splnění této kvalifikace požaduje u příslušné osoby
předložit profesní životopis, z něhož bude vyplývat splnění požadavků zadavatele, a to ve
vztahu k výše uvedeným osobám odpovědným za plnění předmětu veřejné zakázky (v
profesním životopise musí být k prokázání relevantní zkušenosti uvedeny konkrétní projekty,
kterých se tyto osoby účastnily a na jaké pozici, včetně uvedení subjektů, pro které byly
projekty realizovány, přesného vymezení předmětu projektu, doby realizace a kontaktních
údajů na objednatele).
Přílohou životopisu bude:
1) kopie dokladu o dosaženém vzdělání člena realizačního týmu a
2) kopie certifikátu nebo jiného obdobného osvědčení, je-li to u daného člena týmu

požadováno.

13.5 Výpis ze seznamu kvalifikovaných účastníků
Účastník může p i prokazování své kvalifikace p edložit zadavateli výpis ze seznamu
kvalifikovaných dodavatelů (dle § 228 zákona), který nahrazuje doklad prokazující:

a) základní způsobilost podle § 74 zákona,
a

b) profesní způsobilost podle § 77 zákona v tom rozsahu, v jakém údaje ve výpisu ze
seznamu kvalifikovaných dodavatelů prokazují spln ní kritérií profesní způsobilosti.

Zadavatel p ijme výpis ze seznamu kvalifikovaných dodavatelů, pokud k poslednímu dni, ke
kterému má být prokázána základní způsobilost nebo profesní způsobilost, není výpis ze
seznamu kvalifikovaných dodavatelů starší než 3 m síce.
Stejn jako výpis ze seznamu kvalifikovaných dodavatelů může dodavatel prokázat
kvalifikaci osv dčením, které pochází z jiného členského státu, v n mž má dodavatel sídlo, a
které je obdobou výpisu ze seznamu kvalifikovaných dodavatelů.

13.6 Forma spln ní kvalifikace
Pokud není v zákon či této Zadávací dokumentaci stanoveno jinak, p edkládá účastník
doklady prokazující spln ní kvalifikace v prosté kopii. Je-li zadavatelem vyžadováno čestné
prohlášení, musí být podepsáno osobou oprávn nou jednat jménem či za účastníka. V p ípad

59
podpisu jinou osobou na základ plné moci, musí být zmocn ní této osoby součástí dokladů,
kterými účastník prokazuje spln ní kvalifikace.
Dodavatel může prokázat určitou část ekonomické kvalifikace, technické kvalifikace nebo
profesní způsobilosti s výjimkou kritéria podle § 77 odst. 1 zákona, požadované zadavatelem
prost ednictvím jiných osob. Dodavatel je v takovém p ípad povinen postupovat v souladu s
§ 83 zákona.
Doklady prokazující základní způsobilost podle § 74 zákona a profesní způsobilost podle § 77
odst. 1 zákona musí prokazovat spln ní požadovaného kritéria způsobilosti nejpozd ji v dob
3 m síců p ede dnem zahájení zadávacího ízení.

14 Způsob a doba pro podávání nabídek

Lhůta pro podání nabídek je v části 1 zadavatelem stanovena do 11. 11. 2019, do 10:00
hodin.

Lhůta pro podání nabídek je v části 2 zadavatelem stanovena do 2. 10. 2019, do 10:00 hodin.

Nabídky se podávají pouze v elektronické podobě prostřednictvím zadavatelem
stanoveného elektronického nástroje (dále jen "nabídka v elektronické podobě"), s výjimkou
AVZ v části 1. Podmínky pro dodání AVZ v části 1 jsou stanoveny v kapitole č. 10 této
Zadávací dokumentace. Odlišná úprava podmínek pro doručení AVZ v části 1 je stanovená
z důvodu nedostatečné kapacity certifikovaného elektronického nástroje.

Nabídky v elektronické podobě musí být podány v souladu s § 28 odst. 1 písm. i) zákona
prostřednictvím profilu zadavatele, jehož adresa je uvedena v kapitole 2 tohoto dílu zadávací
dokumentace (Základní identifikační údaje zadavatele).

Zadavatel uvádí podrobné informace k podání nabídek v elektronické podobě (pozn.:
nevztahuje se na AVZ v části 1 - viz podmínky uvedené v kapitole č. 10):

· Nabídka v elektronické podob nesmí p esáhnout velikost 200 MB, z čehož
maximáln 100 MB dokumenty k prokázání kvalifikace a maximáln 100 MB ostatní
dokumenty nabídky. Nabídka musí být zpracována prost ednictvím akceptovatelných
formátů souborů, tj. Microsoft Office (Word, Excel), Open Office, PDF, JPEG, GIF,
nebo PNG.

· Pro podání nabídky v elektronické podob bude použit certifikovaný elektronický
nástroj eGORDION v. 3.3 - Tender arena, (dále jen „Tender arena“) dostupný na
internetové adrese www.tenderarena.cz, kde je rovn ž dostupný podrobný návod na
jeho použití (odkaz „nápov da“ v zápatí) a kontakty na uživatelskou podporu.

· Účastník zadávacího ízení musí pro podání nabídky disponovat osobním počítačem,
s minimáln následujícím výkonem: frekvence CPU 1 GHz, operační pam ť 1024
MB, pevný disk 20 GB, osobní počítač musí být p ipojen k síti Internet, a to s
minimální rychlostí p ipojení 2 Mbps (DOWNLOAD) / 512 Kbps (UPLOAD),
účastník zadávacího ízení musí mít v počítači nainstalovaný internetový prohlížeč
(Microsoft Internet Explorer verze 9.0 nebo vyšší, Mozilla Firefox verze 30.0 a vyšší),
který má nainstalovaný SW Java verze 1.8 a vyšší.

60
· Účastník zadávacího ízení musí být pro možnost podání nabídky registrován jako
dodavatel v elektronickém nástroji Tender arena (odkaz „registrace dodavatele“ na
webové stránce www.tenderarena.cz) a uživatel dodavatele musí pro podání nabídky
disponovat rolí „účastník zakázky“. Vy ízení registrace trvá max. 48 hodin (v pracovní
dny) po doložení všech požadovaných dokladů a není zpoplatn na.

· Pakliže je v této zadávací dokumentaci uveden požadavek na podepsání konkrétních
dokumentů p i současném nep ipušt ní nahrazení tohoto dokumentu jeho prostou
kopií či scanem, musejí být jednotlivé dokumenty tvo ící obsah nabídky, u nichž je
podepsání osobou oprávn nou zastupovat účastníka zadávacího ízení vyžadováno,
opat eny elektronickým podpisem založeným na kvalifikovaném certifikátu dle
zákona č. 297/2016 Sb., o službách vytvá ejících dův ru pro elektronické transakce,
ve zn ní pozd jších p edpisů, pop . se musí jednat o autorizovan konvertovaný
dokument ve smyslu zákona č. 300/2008 Sb., o elektronických úkonech a
autorizované konverzi dokumentů.

· Zadavatel nenese odpov dnost za technické podmínky na stran účastníka zadávacího
ízení. Zadavatel doporučuje účastníkům zadávacího ízení zohlednit zejména rychlost
jejich p ipojení k internetu p i podávání nabídky tak, aby tato byla podána ve lhůt pro
podání nabídek (podáním nabídky se rozumí finální odeslání nabídky do nástroje po
nahrání veškerých p íloh!).

Dodavatel může podat pro danou část pouze jednu nabídku.
Dodavatel, který podal nabídku v zadávacím řízení, nesmí být současně osobou, jejímž
prostřednictvím jiný dodavatel v tomtéž zadávacím řízení prokazuje kvalifikaci.
Zadavatel vyloučí účastníka zadávacího řízení, který podal více nabídek samostatně nebo
společně s jinými dodavateli, nebo podal nabídku a současně je osobou, jejímž
prostřednictvím jiný účastník zadávacího řízení v tomtéž zadávacím řízení prokazuje
kvalifikaci.
Nabídka, která nebyla zadavateli doručena ve lhůt pro podání nabídek, se nepovažuje za
podanou a v průb hu zadávacího ízení se k ní nep ihlíží.

15 Lhůta, po kterou jsou účastníci nabídkami vázáni
Lhůta, po kterou jsou účastníci nabídkami vázáni, činí 365 kalendá ních dní ode dne
následujícího po skončení lhůty pro podání nabídek.

16 Otevírání nabídek
Otevírání nabídek se uskuteční v souladu s §109 zákona. Jelikož mohou být podány
elektronické nabídky, nebude zadavatel provád t otevírání obálek ve ejn .

61
17 Komunikace mezi zadavatelem a dodavatelem
V souvislosti s platnou legislativou, je od 18. 10. 2018 možná písemná komunikace mezi
zadavatelem a dodavateli v zadávacím ízení pouze elektronickou formou s výjimkou
p ípadů uvedených v § 211 zákona.
Zadavatel sd luje, že preferuje písemnou komunikaci mezi zadavatelem a dodavatelem
prost ednictvím elektronického nástroje - profilu zadavatele, jehož adresa je uvedena v kapitole
1 tohoto dílu zadávací dokumentace (Základní identifikační údaje zadavatele).
V Hradci Králové dne

Seznam p íloh:
P íloha č. 1 Krycí list nabídky
P íloha č. 2 Popis současného stavu
P íloha č. 3 Funkční požadavky
P íloha č. 4a Smlouva o dílo – část 1
P íloha č. 4b Smlouva o dílo – část 2
P íloha č. 5 Požadavky na prezentaci KIS p ed podpisem smlouvy
P íloha č. 6 Čestné prohlášení k základní způsobilosti
P íloha č. 7 Cenová tabulka
P íloha č. 8 Zvýhodn né funkcionality
P íloha č. 9 Scéná e pro AVZ

62
P íloha č. 1 – Krycí list

Krycí list veřejné zakázky – část 1

Modernizace IT FN HK v návaznosti na eHealth

1.1 Identifikační údaje zadavatele veřejné zakázky

Zadavatel Název Fakultní nemocnice Hradec Králové

Sídlo Sokolská 581
500 05 Hradec Králové – Nový Hradec
Králové

IČ 00179906
Bankovní spojení 40002-24639511/0710

Zastoupený prof. MUDr. Vladimírem Paličkou, CSc., dr. h. c. - editelem
Kontaktní osoba zadavatele Kontaktní údaje

Telefon

E-mail

Adresa profilu zadavatele https://www.egordion.cz/nabidkaGORDION/profilFNHK

1.2 Identifikační údaje účastníka

Účastník, sídlo/místo podnikání
IČ:
DIČ:
Bankovní spojení:
Čísla účtů:
Telefon:
Fax:
E-mail:
Kontaktní osoba ve věci ve ejné zakázky:
Telefon:
Fax:
E-mail:

My, náležitě oprávnění a níže podepsaní, nabízíme realizaci výše uvedené VE EJNÉ ZAKÁZKY,
v rozsahu a za podmínek stanovených ZADÁVACÍ DOKUMENTACÍ, včetně všech jejich p íloh
k ní vydaných, za nabídkovou cenu:

Náklady životního cyklu - celková nabídková cena tvořená součtem nabídkové
ceny za dodávku IS, nabídkové ceny za servisní podporu u dodaného IS č. 1 a
nabídkové ceny za servisní podporu u dodaného IS č. 2.

Nabídková cena v Kč bez DPH
DPH

Nabídková cena v Kč včetně DPH

Prohlašujeme, že nám bude Vámi p idělena tato ve ejná zakázka, budou informace uvedené v naší
nabídce pro nás zavazující k uzav ení smlouvy.

-1-
P íloha č. 1 – Krycí list
Dále prohlašujeme, že jsme si p ed podáním nabídky vyjasnili všechny pot ebné technické údaje, které
jednoznačně vymezují množství a druh požadovaných služeb a dodávek v souvislosti s plněním této
ve ejné zakázky.
Dále prohlašujeme, že souhlasíme se zadávacími podmínkami uvedenými zadavatelem v zadávací
dokumentaci a se zve ejněním všech náležitostí budoucího smluvního vztahu (vlastní smlouva a
podmínky servisní smlouvy a smlouvy o dílo vážící se na p edmět plnění, množstevní bonusy a
podobné) a že poskytneme veškeré nezbytné informace pro naplnění povinnosti zadavatele stanovené
Zákonem.
Toto prohlášení činíme na základě své jasné, srozumitelné, svobodné a omylu prosté vůle a jsme si
vědomi všech následků plynoucích z uvedení nepravdivých údajů.
V ..................... dne...............
podpis účastníka

-2-
P íloha č.2 :
Popis současného stavu IT infrastruktury
zadavatele
Obsah

P íloha č.2 : ........................................................................................................................... 1

Popis současného stavu IT infrastruktury zadavatele ............................................................ 1

1 Současný stav IT FN HK................................................................................................... 3

1.1 Stručná charakteristika nejdůležitějších systémů FN HK .............................................. 3

1.2 P ehled pokrytí hlavních procesů z hlediska IS............................................................. 6

1.3 Hlavní procesy.............................................................................................................. 6

1.3.1 ídcí procesy ................................................................................................... 8

1.3.2 Podpůrné procesy ............................................................................................ 9

1.4 Popis základní IT infrastruktury (serverů a úložišť) FN HK...........................................10

1.4.1 Servery............................................................................................................11

1.4.2 LAN Cisco .......................................................................................................13

1.4.3 SAN HP Brocade ............................................................................................13

1.4.4 Datová úložiště FN HK (Storage) ....................................................................15

1.4.5 Pracovní stanice s MS Windows ....................................................................17

1.4.6 Zálohování a dohled........................................................................................17

2
1 Současný stav IT FN HK
FN HK provozuje rozsáhlou ICT infrastrukturu. Její popis následuje. Některé ze systémů
jsou moderní, jiné zastarávají. Nejkritičtější aplikace FN HK je Klinický Informační Systém
(KIS) z r. 1996, který je morálně i fyzicky zastaralý. Některé oblasti nejsou stávajícím KIS
pokryty vůbec – jako elektronická zdravotnická dokumentace a její archivace a sdílení
s pacienty, chybí pokrytí významných částí procesu poskytování zdravotnické péče,
nap íklad ošet ovatelská dokumentace. Podrobnosti viz další kapitola.
Technicky nevyhovující pro provoz nového IS jsou také servery a část klientských stanic.
1.1 Stručná charakteristika nejdůležitějších systémů FN HK
FN HK v současné době využívá mnoho různých SW pro pokrytí procesů FN HK. Výčet
nejdůležitějších systémů včetně způsobu komunikace s KIS je uvedený v následující tabulce.

Název IS/aplikace/SW Stručný popis systému Způsob komunikace s KIS
KIS pro správu a vedení zdravotnické
AMIS*H dokumentace a léčebné péče ve FN HK. -
Klinický informační systém pro vedení
AMIS*HD dokumentace TCM On-line
Jednosměrné p enášení
OPEN LIMS Laborato e UKM, UKBD, UKIA výsledků p es rozhraní
DASTA verze 3, KDAVKA
PACS – FUSION PACS Obrazová dokumentace PACS HL7
MEDIOX Lékárenský IS Webové služby
NAVISION Ekonomické agendy – ERP systém CSV soubory
Textové soubory
FAMA plus podpora OZT – evidence zdravotnického Ne
VEMA materiálu a techniky
AMADEUS mzdové agendy, personalistika Textové soubory
Astris IS pro Transfuzní oddělení KDAVKA
CATO Stravování pacientů Ne
CLINICPHARM IS pro oddělení p ípravy cytostatik Textové soubory,
E_spis Statistické vyhodnocení činností KDAVKA
MEDIX klinického farmaceuta Textové soubory
MERIT Spisová služba
MIS AMIS H Ne
NEFRIS
PC DENT IS pro centrální sterilizaci a sály Textové soubory
ProMED Textové soubory
SOPHIS Manažerský IS Textové soubory, datové
VYVOLÁVACÍ SYSTÉM pumpy
Winzis Manažerský IS pro analýzu produkce KDAVKA
KDAVKA
Nefrologie
Ambulantní systém pro stomatologickou Textové soubory
kliniku Textové soubory
Sledování komplikací pro chirurgické
obory Ne
Manažerský IS nad spot ebou léků a SZM Webové služby,
PIO, psychiatrie, chirurgie, neurologie,
stomatologie, hematologie
Patologie

3
Název IS/aplikace/SW Stručný popis systému Způsob komunikace s KIS
Zasílání výsledků Vybrané ambulance KDAVKA
praktickým léka ům Textové soubory

Následuje popis nejdůležitějších zdravotnických systémů FN HK:

AMIS_H

AMIS_H je klinický informační systém (KIS), který umožňuje vedení zdravotnické
dokumentace a provozní podporu činnosti na jednotlivých klinických pracovištích.

K AMIS_H aktuálně p istupuje 4200 uživatelů. Ve špičkách s AMIS_H pracuje až 800
uživatelů současně.

Fakultní nemocnice Hradec Králové provozuje klinický informační systém AMISH od firmy
ICZ a.s., který byl postupně uváděn do provozu od roku 1996. Od té doby základní
technologie ani funkcionality nebyly výrazněji modernizovány. Nap . klient je stále typu
"terminálová relace". Stávající KIS neumožňuje rozší ení o nové vlastnosti, kterými
modernější systémy běžně disponují a uživatelé je požadují. Z důvodu nemožnosti inovace
systému p estaly postupně možnosti stávajícího KIS vyhovovat pot ebám Fakultní
nemocnice Hradec Králové a jejím klientům. FNHK v současné době provozuje níže
uvedené moduly. Seznam modulů dává základní p edstavu o rozsahu funkcionality AMIS_H.

· lůžkové oddělení – moduly pro vedení zdravotnické dokumentace lůžkových
pacientů (chorobopis – dekurz, strukturovaná medikace, závěrečná zpráva, podpora
TISS, hlášení nozokomiálních nákaz, list o prohlídce zem elého, onkologické hlášení
atd.)

· ambulance – vedení zdravotnické dokumentace pro ambulantní pacienty,
ambulantní karty, p edepisování receptů, SZM, plánování návštěv pacientů.

· operační sály – operační protokoly,
· porodnice – vedení zdravotnické dokumentace rodiček, porodopisy,
· novorozenec – vedení zdravotnické dokumentace novorozenců,
· hospitalizační p ípad – dokumentace pacientů hospitalizovaných postupně na více

klinikách,
· registr pacientů – správa údajů o pacientech vedených v NIS (základní osobní

údaje),

· hematologická laborato – komplexní agenda hematologické laborato e vč. sběru dat
z analyzátorů,

· rentgen – popisy RTG snímků, p íruční sklady SZM
· žádanky – na vyšet ení mezi klinickými a ambulantními pracovišti nebo mezi

klinickými pracovišti a laborato emi (do LISu Open LIMS jsou výhradně papírové
žádanky) a automatické p ebírání výsledků, žádanky na dopravu pacientů
· pojišťovna – vykazování veškeré péče zdravotním pojišťovnám a samoplátcům,
podpora DRG
· externí vstup dat – do modulu pojišťovny AMIS*H z pracovišť, která v AMIS*H
nepracují, data vstupují ve tvaru KADAVKA
· AMIS*CLASS modul – zpracování pojišťovny v metodice DRG
· p ehledy o pacientech – různé pohledy do zdravotnické dokumentace pacientů s
možností výběrů podle zadaných kritérií,
· zdravotnická doprava – elektronické žádanky na p epravu pacientů, dispečink
sanitních vozů – jen do úrovně vygenerování p íkazu k jízdě, vyúčtování pojišťovny

4
· organizační struktura – stromy zdravotnických pracovišť a pracovišť správy
nemocnice včetně jejich parametrů, členění FN dle různých pohledů

· administrace – správa funkcionality jednotlivých podsystémů a p idělování
p ístupových práv uživatelům,

· personalistika – slouží pro p idělení login a p ístupových práv – import ze SW fy
VEMA

· výkaznictví – sběr, agregování a p edávání informací Ústavu zdravotnických
informací a statistik (ÚZIS) a Národním zdravotnickým registrům,

· diety – sběr požadavků na druh diet lůžkových pacientů,
· administrace lůžek – evidence lůžkového fondu nemocnice (klinika, pokoj, lůžko,

ukládání pacientů na lůžko).
· komunikační modul – p ebírání výsledků z externích komplementů, které své

agendy v KISu nevedou – biochemie, mikrobiologie, UKIA a některé ambulance
· komunikace s PACS – p enos některých údajů do PACS ve standardu HL7
Open LIMS
Open LIMS je určen pro vybrané laborato e. Podporuje specifické komplementární procesy v
odbornostech: biochemie, imunologie, sérologie, parazitologie, mykologie, virologie,
cytologie, bakteriologie. Součástí Open LIMS je i komunikace se SW praktických léka ů.
Hematologická laborato používá stávající systém v KIS a p ed implementací by měl být
tento SW nahrazen novým systémem.
PACS
Specializované ešení pro elektronické zpracování, archivaci a distribuci obrazových dat ve
zdravotnictví. Propojení s KIS modul RTG je p es HL7.
PC DENT
Komplexně eší problematiku a administrativu ambulantní části stomatologické kliniky.
Podporuje statistické výstupy a sledování nákladů. Pracuje s grafickou dokumentací.
NEFRIS
Systém pracuje se specifiky administrativy dialyzační služby. Vede se v něm kompletní
zdravotnická ambulantní dokumentace pacientů včetně pojišťovny a statistik. Má databázi
oddělenou od KIS.
MEDIOX
Systém pro komplexní ízení provozu lékárny, včetně obsluhy výdejového robota.
WINZIS
Systém pro podporu patologie. Komplexně eviduje histologická, cytologická a pitevní
vyšet ení včetně vyúčtování dat pro pojišťovny. Systém je propojen s AMIS_H p es webové
služby a je zde synchronizace osobních údajů pacienta.
MEDIX
MEDIX je komplexní informační systém na pracoviště centrálních operačních sálů a centrální
sterilizace.

5
AMADEUS
Program Amadeus pokrývá veškeré činnosti a procesy používané pro ízení provozu
transfuzního oddělení: evidenci dárců, zvaní dárců, odběry, výrobu a sklad krve, dodávky
plasmy pro zpracovatele, expedice na oddělení nemocnice, karanténní plasmu, sklad
transfuzních p ípravků a spot ebního materiálu, výstupy pro plátce péče zdravotní
pojišťovny) a denní archivaci celého provozu transfuzního oddělení.
CATO
Program CATO pokrývá veškeré činnosti a procesy používané pro ízení provozu edírny
cytostatik. Disponuje možností vytvo ení datového výstupu ve formátu KDAVKA pro finální
vyúčtování zdravotní péče v KIS. Mezi SW CATO a MEDIOX jsou p enášeny textové
soubory.
CLINICPHARM
Program CLINICPHARM slouží pro statistické vyhodnocení činností klinického farmaceuta.
Vazba s KIS je zabezpečená pomocí textových souborů.
ProMED
Aplikace pro sledování komplikací pro chirurgické obory. Vazba s KIS je zabezpečená
pomocí textových souborů.
1.2 P ehled pokrytí hlavních procesů z hlediska IS
V této kapitole je popsáno pokrytí stávajících procesů informačními systémy, pokud jsou IS
využívány.
1.3 Hlavní procesy
Hospitalizace pacienta
Hlavní činností procesu hospitalizační péče z hlediska funkcionalit KIS je po izování
záznamů o diagnostické a léčebné péči o pacienta. Veškerá zdravotnická dokumentace je
vedena primárně v tištěné formě. Dokumentace v elektronické formě je doplňkem tištěné
dokumentace. V rámci strategie FN HK je vždy prezentována myšlenka, že p echod na čistě
elektronickou dokumentaci (vč. ošet ovatelské dokumentace viz níže) je budoucím cílem
managementu. Dostupnost historie pacientské dokumentace v elektronické formě je
v AMIS_H v současné době neomezená, respektive je zachována od okamžiku spuštění
jednotlivých modulů, proto témě odpadá nutnost dohledávání papírových chorobopisů
v archivech.
Hospitalizace pacienta je jedním z hlavních procesů realizovaných ve FN HK. Základním
stavebním kamenem KIS je centrální registr pacientů. Databáze obsahuje základní nacionále
pacienta použitelné pro jeho identifikaci (jméno, p íjmení, rodné číslo, číslo pojištěnce,
adresa/kontaktní údaje, zdravotní pojišťovna). Díky využití pacientské databáze (centrální
registr pacientů) jsou do vzorových formulá ů generovány nacionále pacienta a pracoviště
FN. To usnadňuje práci zdravotnických pracovníků a snižuje chybovost p i ručním vpisování
dat. Dále KIS umožňuje tisk identifikačních štítků s čárovým kódem pacienta, které slouží pro
identifikaci žádanek, poukazů na vyšet ení, nádobek pro odběry primárních vzorků apod.
Data z KIS jsou rovněž využívána pro tvorby hlášení - List o prohlídce zem elého, Hlášení
nozokomiálních nákaz, Hlášení novotvarů a dalších povinných hlášení pro matriky a
ÚZIS(některé registry).

6
Systém umožňuje ukládání pacientů na konkrétní pokoj a lůžko, což zdravotnickému
personálu zjednodušuje práci s pacientem.
Systém dále umožňuje vedení multiklinické hospitalizace s tím, že po zvolení pokračující
hospitalizace na jiné klinice systém p edvyplní některé údaje v KIS.
Průběh hospitalizace je evidován v jednotlivých částech dokumentace, jako je nap . dekurz,
epikríza, stav p i p ijetí, stav a průběh hospitalizace, strukturovaná medikace, elektronické
žádanky, TISS výkony. Systém disponuje kompilací p ekladových a propouštěcích zpráv na
základě různých částí zdravotnické dokumentace. Pro sestavy zpráv a ostatní výstupy jsou
využívány jednoduché šablony, obsahově uzpůsobené jednak požadavkům legislativy a dále
standardům zavedeným ve FNHK.
V celé FNHK se využívá pro hospitalizační péči AMIS_H, kromě jediné JIP, která využívá
vlastní SW – KIS JIP 3.Int.
Ambulantní péče
Poskytování ambulantní péče je z hlediska průběhu workflow obdobné s poskytováním péče
lůžkové. Primárně jsou využívána data z centrálního registru pacientů. Evidence pacientů
konkrétní ambulance je propojena s centrální databází. Systém disponuje omezeným
objednáváním pacientů na vyšet ení elektronicky. Jedná se o objednávání ze strany
ambulance (ne aktivní p ístup pacienta) a vedení objednávek v elektronické formě. Možnost
elektronického objednávání i ze strany pacienta nebo externího zdravotníka na vhodných
ambulancích je požadovaným budoucím stavem.
Systém ízení zdravotnické dokumentace, tvorby zpráv a tiskových sestav je pro proces
ambulantní péče identický s procesem péče hospitalizační.
Ošet ovatelská péče
Proces ošet ovatelské péče je evidován papírovou formou, což významně snižuje efektivnost
ošet ovatelského personálu a vlastního procesu. Dokumentace je tedy vedena v papírové
podobě. Management p edpokládá budoucí p echod na elektronickou ošet ovatelskou
dokumentaci v plném rozsahu aktuální p edstavy o ošet ovatelské dokumentaci
Porodnická péče
Zdravotnická dokumentace vztahující se k porodnické péči je vedena standardně v rámci
KIS. KIS disponuje specializovaným modulem pro vedení porodopisu a je zde p ímá vazba
na agendu dokumentace o novorozenci. Dokumentace rodičky obsahuje informace o
průběhu těhotenství, anamnézu rodičky, záznamy o p edporodních vyšet eních apod.
Z průběhu vlastního porodu je pak doplňován kompletní porodopis. Novorozenci se zakládá
a vede vlastní dokumentace. Tyto dvě dokumentace jsou v KIS p ímo propojeny.
Novorozenecké oddělení má p ístup k vybraným údajům o matce, stejně tak porodnice má
p ístup k vybraným údajům o novorozenci.
Provoz porodnické péče rovněž p ináší subjektu povinnost hlášení do registrů NZIS 1 a do
Národního registru rodiček. Systém disponuje výstupem ve formátu XML s údaji o rodičce a
o novorozenci, ale není v současné využíváno p ímé hlášení z KIS do registrů.
V souvislosti s poskytováním porodnické péče je rovněž nutné upozornit na specifickou
oblast o utajeném porodu, tato agenda je ešena pouze organizačně vnit ními p edpisy FN
HK.

7
Operační péče
Operační zákroky jsou evidovány v KIS, současně s operačním protokolem je rovněž
vykazován spot ebovaný materiál a výkony pro pojišťovnu. Tento modul je propojen
s lůžkovou i ambulantní péčí. P ímo z tohoto modulu lze vytvo it elektronickou žádanku na
patologii a také prohlížení histologických výsledků. Modul není vybaven plánováním operací
a také není p ímé napojení na SW sterilizace. Tyto integrace by byly žádoucí pro urychlení
práce zdravotnického personálu s dokumentací a i vzhledem ke zvýšení bezpečnosti péče o
pacienta.
Hemodialyzační služba
FN HK provozuje st edisko hemodialyzační služby. Pro ízení provozu hemodialýzy je
využíván specifický klinický informační systém Nefris. Systém umožňuje komplexní vedení
zdravotnické dokumentace o pacientech hemodialýzy vč. záznamů o průběhu vlastní
hemodialýzy. Z tohoto pohledu je klinickými uživateli všech subjektů hodnocen jako
vyhovující jejich pot ebám. V současné době není databáze Nefris propojena s databází KIS.
Pacienti jsou do Nefris zadáváni jako do samostatného systému, dále je jejich evidence
vedena rovněž v KIS v modulu ambulantní nebo lůžkové péče, veškeré změny je tedy nutno
zadávat dvakrát, do Nefris a současně do KIS. Tato oblast je uživateli hodnocena spíše
negativně, propojení databází obou systémů by bylo žádoucím aspektem pro optimalizaci
provozu. Dle specifikace dodavatele (ProDoss.r.o.) je Nefris vybaven různými možnostmi
komunikačních rozhraní pro výměnu dat s dalšími IS vč. datového standardu MZ ČR
(DaSta).

1.3.1 ídící procesy

Proces management zdravotnického za ízení lze členit na několik dalších subprocesů
podle problémových oblastní:

· Personalistika a ízení mezd – proces personálního a mzdového ízení je ešen v
SW VEMA. V systému je vedena základní pracovně-právní agenda, tj. evidence
zaměstnanců a jejich základních údajů. Systém je rovněž určen k ízení mezd.
V tomto smyslu je propojen se systémem pro ízení ekonomiky a účetnictví
(NAVISION). Plánování směn ani detailní evidence pracovní doby není v tomto
systému vedena.

· Ekonomika a účetnictví - procesy jsou pokryty systémem NAVISION. Systém je
schopen pomocí dataportů nahrát výstupy z KIS ve formátu TXT. Propojení se
systémy FAMA a MEDIOX je zabezpečeno pomocnou databázi, kde si systémy
navzájem sdílejí data. Ostatní systémy CATO, AMADEUS a další, které jsou
pot ebné pro účtování, mají domluvenou strukturu a formáty souboru pro
mezisystémovou komunikaci.

· Statistiky, výkazy, controlling a vyúčtování zdravotní péče – statistické p ehledy
a výkaznictví jsou nedílnou a velmi důležitou součástí managementu zdravotnického
za ízení. Pro statistickou a výkaznickou činnost je nezbytná spolupráce KIS, LIS,
dalších systémů a ekonomického systému. Data jsou dále shromažďována a
vyhodnocována v určeném MIS. Vazba k KIS je identifikována pouze na pot ebu
datových propojení a variabilitu pro statistické hodnocení a reportování. Vyúčtování
zdravotní péče pro zdravotní pojišťovny je prováděno elektronickými dávkami na
portály ZP, v dávkách jsou konsolidována data za všechny výkony a veškerá tato
agenda je vedena v AMIS_H. Ze samostatných SW jsou ručně nahrávána data ve
formátu KADAVKA do KIS. Pro controlling jsou využívány SW MERIT, MIS_AMIS_H
a SOPHIS.

8
· Hlášení do registrů – Hlášení do registrů je nezbytnou součástí provozu
zdravotnického za ízení. V současné době neprobíhá p ímý export dat mezi KIS a
ÚZIS. KIS je schopen pouze tvorby XML souboru dle platného XSD schématu, a to
jen pro základní registry.

Sledování kvality a bezpečí péče
Pro sledování a vyhodnocování nežádoucích událostí je využíván Systém sledování
mimo ádných událostí pod 3. LF UK Praha a pro hlášení Pádů a dekubitů je využíván systém
Sledování a vyhodnocování dekubitů a pádů také pod 3. LF UK Praha. Pro sledování
komplikací v chirurgických oborech je využíván SW ProMed.

ízení dokumentace
Vzhledem k faktu, že FN HK je akreditována v souladu s požadavky §98 odst. 1 zákona
č.372/2011 Sb., je proces ízení dokumentace jedním z klíčových procesů úspěšnosti
procesu posouzení souladu. Podpora ízení dokumentace je ešena vnit ními p edpisy FN
HK., spisovou službou a SW EISOD, v kterém je veden proces schvalování smluv.

1.3.2 Podpůrné procesy
Správa zdravotnických prost edků
Pro zprávu zdravotnických prost edků je využíván IS FaMa+. V současné době neexistuje
žádné propojení FaMa+ a KIS.

ízení léčiv a spot ebního zdravotnického materiálu
Základním aspektem v oblasti ízení léčiv a SZM je výběr ze „schváleného seznamu“ tzv.
pozitivního listu. Nakupování, resp. objednávání probíhá a skladová evidence je vedena
v systému MEDIOX. Sledování preskripce je využíváno zejména jako kontrolní mechanismus
v systému SOPHIS. Elektronické recepty v současné době SW neumožňuje. Propojení s KIS
je p es webové služby, které zabezpečují následující vazby SW MEDIOX a KIS a p edávají
se:

· průměrné ceny lékárny pro preskripci
· průměrné ceny pro vyúčtování zdravotní péče
· dostupnost léčiva na jednotlivých lékárnách
· podpora pozitivního lisu.
Stravování pacientů
SW podpora stravovacího provozu (objednávky diet pro pacienty) je ešena programem IS
Astris a neexistuje žádné propojení s AMIS_H
Sledování epidemiologického režimu
V současné době není epidemiologický režim podpo en systémově informačním systémem.
V KIS jsou zabezpečeny pouze dílčí procesy.
Laboratorní služby
Laborato e většinou využívají stejný LIS, a to Open LIMS (Stapro), výjimkou je pouze
hematologická laborato a FÚP. Zadávání žádanek na laboratorní vyšet ení je v papírové

9
podobě, pouze na hematologickou laborato a FÚP jsou žádanky elektronické. P echod na
elektronickou žádanku na všechny laboratorní metody je plánovaným stavem. Součástí IT
strategie FN HK je i odchod hematologické laborato e od modulu KIS a p echod na nový
SW.
P enos výsledků vyšet ení je zajištěn elektronicky pomocí rozhraní DASTA do dokumentace
pacienta, a i p esto jsou dodávány výsledky také v papírově formě (autorizované uvolňující
osobou). V p ípadě FÚP jsou žádanky a výsledky vyšet ení zpracovány elektronicky a
zapisovány p ímo do KIS. Jde o pracoviště, které používá samostatný SW WINzis. Externím
zadavatelům jsou výsledky elektronicky poskytovány formou zabezpečeného p enosu. Jsou
využívány aplikace Medidata a Mise. Důraz je kladen zejména na bezpečnost p enosu dat a
včasné dodání výsledků oprávněnému klinickému žadateli.
Zobrazovací metody
V p ípadě založení vyšet ení v KIS s využitím zobrazovacích metod je zajištěno elektronické
podání požadavku p es datové rozhraní HL7 z modulu RDG KIS. O zpracování a archivaci
obrazové dokumentace se stará SW JiveX, který je produktem společnosti VISUS
Technology Transfer GmbH, Bochum, Německo. K p enosu obrazových dat mezi
jednotlivými poskytovateli je využíván zabezpečený export v ePACS.
Výroba transfuzních p ípravků
Úsek výroby transfuzních p ípravků ídí SW AMADEUS firmy Steiner, propojení na KIS je
pouze prost ednictvím datových souborů ve formátu KDAVKA. Systém využívá objednávání
dárců p es internet.
Sterilizace
Proces sterilizace je podpo en SW MEDIX. Systém používá své elektronické žádanky a
vytvá í sesterskou dokumentaci k operačním sálům. V nočních hodinách probíhá
synchronizace časů operací mezi KIS a MEDIX, kde je za základ brán čas ze sesterského
protokolu.
1.4 Popis základní IT infrastruktury (serverů a úložišť) FN HK
Níže je stručně popsán současný stav IT infrastruktury zadavatele.
Umístění serverů a úložišť
Dvě serverovny FN HK jsou umístěny v budovách č. 24 a č. 12, vzdálených od sebe asi 300
m. Obě serverovny jsou vybaveny zabezpečením proti vniknutí osob, požáru, povodni (jsou v
1. a 2. pat e), klimatizací a centrálními UPS s napojením na diesel agregát.
Tyto dvě serverovny tvo í základ pro budování IS s požadovanou dostupností. Kritické
nonstop běžící aplikace (nap . KIS, LIS, PACS, EIS atd.) jsou provozovány tak, aby výpadek
jedné serverovny, pokud možno nezpůsobil výpadek služby nebo, pokud to není možné, aby
výpadek služby nebyl delší než 30 minut.

10
1.4.1 Servery

1.4.1.1 Servery HPUX

Současný KIS AMIS_H běží na dvou Itaniových serverech zapojených v clusteru HP Service
Guard s garancí dostupnosti na úrovni serverů:

· SPOF pro všechny komponenty
· p i výpadku jednoho serveru musí nejdéle do 30ti min druhý server p evzít funkci

serveru s poruchou.
Server „hps“ = HP rx2800

CPU: 2x Quad-Core Intel Itanium 9340 1,60 GHz procesor s 20 MB L3 cache
RAM: 64GB
HDD: 8x 146 GB 15k RPM 2-portový 6 Gbit/s SAS SFF (2,5") Enterprise Hot-
plugHDD.
Data a virtualizace jsou umístěny s vysokou dostupností na diskových polích.
SAN: 2ks 8Gb porty, p ipojení do SAN je redundantně p es Fabric 8Gb a 16Gb
LAN: Servery jsou též redundantně p ipojeny k LAN s využitím SW doplňku HP APA
Ostatní: Zdroje, ventilátory jsou redundantní.
Server „hpa“ = HP rx2800 i4
CPU: 2x 8Core Intel Itanium 9560 1,60 GHz procesor s 20 MB L3 cache
RAM: 128GB
HDD: 6x 300GB 15k RPM SAS 12G 2,5“ Hot-plugHDD

2x 400GB SAS SSD SLC 6G 2,5“ Hot-plugHDD
Data a virtualizace vPar jsou umístěny s vysokou dostupností na diskových polích
SAN: 2ks 8Gb porty, p ipojení do SAN je redundantně p es Fabric 8Gb a 16Gb
LAN: Servery jsou též redundantně p ipojeny k LAN s využitím SW doplňku HP APA
Ostatní: Zdroje, ventilátory jsou redundantní.
Servis: Servery jsou pod platnou servisní smlouvou (odezva 24x7 do 2hod vzdáleně a do
4hod v místě, FIX do 24hod a s automatickým zakládáním servisního požadavku p i poruše)
Operační systém: HP-UX
Verze: 11i DC-OE B.11.31 U ia64 0383831464 unlimited-user license
Servis: operační systémy jsou pod platnou servisní smlouvou (odezva 24x7 do 2hod

vzdáleně a do 4hod v místě a s automatickým zakládáním servisního
požadavku p i poruše)

Databáze: IBM-Informix
Verze: IBM Informix Dynamic Server Enterprise Edition Version 11.70.FC4.
Licence:

11
Part number Quantity

1 IBM Informix Express Edition CPU OptionProcessorValue Unit (PVU) Annual SW
Subscription& Support Renewal

E022LLL 200

2 IBM Informix UltimateEdition CPU OptionProcessorValue Unit (PVU) Annual SW Subscription&
Support Renewal

E08SLLL 500

3 IBM Informix 4GL RDS DevelopmentRegistered User Annual SW Subscription& Support
Renewal

E2DGCLL 1

4 IBM Informix SQL DevelopmentRegistered User Annual SW Subscription& Support Renewal

E2DJBLL 4

Servis: Databáze je pod platnou servisní smlouvou IBM (odezva 24x7 do 2hod
vzdáleně a do 4hod v místě)

Pozn: Dále licence INFORMIX 4GL COMPILER RUNTIME 400PVU ver.7.20, která již
není pod supportem

1.4.1.2 Servery Win a Linux

Zadavatel provozuje Intelové servery X86 zejména na jednotné platformě VMware, kde je
zajištěna vysoká dostupnost, škálovatelnost a speciální dohled VCO. Virtualizována je již
většina serverů.

Operační systémy serverů jsou umístěny na lokálních HDD, data jsou na diskových polích
p ipojených p es SAN.

Odůvodněné výjimky jsou provozovány na rackových serverech z ady HP DL380 (generace
G5 až G9)

VMware

VMware se skládá ze dvou nezávislých farem, každá ze 4 fyzických serverů.

Servery: Lenovo System X 3650 M5
Licence: vSphere 6 Enterprise Plus
Verze 6.5u1
Servis: všechny licence VMware jsou pod platnou servisní smlouvou (odezva
24x7 do 2hod vzdáleně a do 4hod v místě)
LAN+SAN: VMware servery i ostatní významné servery jsou redundantně
p ipojeny do SAN (rychlostí 4 až 16 Gb) a LAN (rychlostí 1 až 10Gb):
(VMware 2x 10Gb)

Win servery na VMware jsou pokryty licencemi MS Win Server DC s SA na všech fyzických
hostech VMware farem

Na fyzických serverech provozují operační systémy Win2003 až Win2012, Std, p evážně již
64bit verze.

Linux servery: p evážně s operačním systémem SUSE nebo RedHat

12
Servery unixového typu jsou ově ovány vůči hlavnímu HPUX server s KIS, synchronizace
účtů pomocí YelowPages (NIS). Tato autorizace se postupně nahrazuje autorizací proti
Microsoft AD s postupujícím nasazením Identity managementu na hlavní systémy FN HK.

1.4.2 LAN Cisco
Datové centrum FN HK je vybaveno rozhraním 1000/10000 Ethernet 10GBASE-T. P ípadná
agregace portů je realizována p es redundantní rozhraní protokolem LACP. Pro správu
serverů a úložišť se stále používá 10/100 100Base-T. LAN je rozdělena do VLANů. Páte
datové sítě je osazena p epínači ady CISCO 6500 v režimu VSS.
Jednotlivé budovy v areálu FN HK Sokolská jsou p ipojeny 2x 1Gbps LACP. Počítače
uživatelů pak rychlostí 1Gbps.
Areál Staré nemocnice (Nezvalova ulice) je p ipojen rychlostí 150Mbps vyhrazeným
rádiovým spojem v licencovaném pásmu. Lokální síť 80. počítačů je propojena rychlostí
100Mbps.
Areál Léčebny návykových nemocí Nechanice je p ipojena VPN tunelem rychlostí 100Mbps
vyhrazeným rádiovým spojem v licencovaném pásmu. Lokální síť 16. počítačů je propojena
rychlostí 100Mbps.
Ambulance Kliniky nemocí z povolání (2 počítače) jsou p ipojeny VPN tunelem do areálu FN
HK p es poskytovatele internetu s rychlostí 40/40 Mbps.
Ambulance Protetiky (2 počítače) jsou p ipojeny VPN tunelem do areálu FN HK p es ADSL
s rychlostí 6/0,5Mbps.

1.4.3 SAN HP Brocade
SAN FNHK se skládá z dvou zcela nezávislých Fabriců a je tedy plně redundantní, typ
Brocade, dodala firma HP (nyní již HPe).
První Fabric 16 Gb, se skládá z 4x SAN switch 16 Gb po 24 portech, zapojených do Mash.
Druhý Fabric, základ 8 Gb (a satelitní SAN switch jen 4Gb), se skládá z 4x SAN switch 8 Gb
po 24 portech, zapojených do Mash, a na ně jsou napojeny 4x 4Gb SAN switche po 16
portech, pro rozší ení počtu portů a možnost p ipojení „starších“ a pomalejších nodů 2Gb.
Verze: 16Gb SAN switche Fabos Version 7.4.1

8Gb SAN switche Fabos Version 7.0.1a
Servis: SAN switche 16 a 8 Gb systémy jsou pod platnou servisní smlouvou (odezva 24x7 do
2hod vzdáleně a do 4hod v místě a s automatickým zakládáním servisního požadavku p i
poruše)
SAN switche 4Gb jsou již bez platné servisní podpory a tudíž se k nim již nep ipojují nová
za ízení.

13
14
1.4.4 Datová úložiště FN HK (Storage)

Koncepcí zadavatele je centralizovat všechna významná data FN-HK na diskových polích,
kde je zajištěna vysoká dostupnost, škálovatelnost a výkonnost. Většina dat je již
provozována z diskových polí.
Vysoká dostupnost je mimo jiné garantována umístěním ve dvou lokalitách (budova č 12 a
č. 24) a replikacemi na úrovni diskových polí.
Všechna data serverů budou finálně zálohována centrálním zálohováním HP Data Protector,
a to buď na disková pole, nebo na páskové knihovny.

1.4.4.1 Disková pole pro provozní data

2x HP 3PAR Storage
Všechna provozní data serverů jsou uložena na dvou diskových polích HP 3PAR, které se
mezi sebou synchronně replikují. Servery jsou napojeny redundantně p es 8Gb SAN.
Je garantována vysoká dostupnost nejen díky SPOF, ale i p i výpadku trasy nebo celého
pole nesmí být p erušen chod aplikací (funkce Peer Persistent port).
Snahou je, aby kritické aplikace nebyly p erušeny ani p i výpadku celé serverovny v jedné
budově.
Z hlediska výkonu lze data aplikací p i azovat mezi základními t emi tiery (SSD, SAS a NL).
Změny tieru lze dělat za chodu.
Hlavní funkcionality jsou nap : „AutoTiering“, „SSD alá Cache“, „Remote Copy“, „SnapShot a
SnapClone“, „Peer Persistent port“, QoS, atd.
První pole HP 3PAR 7200C, tzv. „DP9“ :

2x controller 40 GB Cache;
4x HDD police 2,5“+ 1x HHD police 3,5“
1.Tier SSD: 20HDDx480GB + 8HDDx1,8TB = 9,6+15,2TB hrubé kapacity
2.Tier SAS: 60HDDx900GB + 32HDDx1,8TB = 36+57,6TB
3.Tier NL: 24HDDx6TB = 144TB
po ízeno 2015 + 2017
umístěno v budově č. 12
je certifikováno pro virtuálním systémem VMware a vMSC.
Druhé pole HP 3PAR 7200C, tzv. „DP10“ :
2x controller 40 GB Cache;
4x HDD police 2,5“+ 1x HHD police 3,5“
1.Tier SSD: 20HDDx480GB + 8HDDx1,8TB = 9,6+15,2TB hrubé kapacity
2.Tier SAS: 60HDDx900GB + 32HDDx1,8TB = 36+57,6TB

15
3.Tier NL: 24HDDx6TB = 144TB
po ízeno 2015 + 2017
umístěno v budově č. 24
je certifikováno pro virtuálním systémem VMware a vMSC.

Obě pole jsou pod platnou servisní smlouvou (odezva 24x7 do 2hod vzdáleně a do 4hod
v místě, FIX do 24hod a jsou dohledována výrobcem s automatickým zakládáním servisního
požadavku p i poruše)

1.4.4.2 Disková pole pro zálohu, p ípadně dat malého významu pro provoz FN-HK

Pro zálohování D2D2T se využívá speciální pole StoreOnce4800 a „starší vysloužilá“ pole
EVA a MSA.

Snahou je zajistit vysokou dostupnost díky D2D2T tak, že zálohovací pole jsou umísťovány
do budovy č. 12 a páskové knihovny do budovy č. 24.

1x HP StoreOnce 5100

Pro zálohování D2D.
Hlavní funkcionality jsou nap : deduplikace, VTL,
Pro Centrální zálohování HP DataProtector a Acronis.
Pole má aktívní servis 24x7 odezva (2hod_vzdáleně a 4hod_v místě) a p i poruše jsou
automaticky zakládány servisní požadavky u výrobce HP.

3x HP EVA (EVA4000 + EVA6100 + EVA6400)

Kapacita: Cca 200 GB NL

SAN: s redundantním p ipojením na SAN (starší 4 GB novější 8 GB)

SW: HPCommandView, Continue Access, Business Copy (dále jen CV, CA, BC)

Kapacitně neomezené licence CA + BC a CV

a 1TB ZeroDowntimeBackup (dále jen ZDB) licence

Pole již nemají aktívní servis.

„DP6“ = HP EVA4000
Kapacita cca 56 TB hrubé kapacity, 4 GB cache
po ízeno 2006
„DP7“ = HP EVA6100
Kapacita cca 112 TB hrubé kapacity, 4 GB cache
po ízeno 2008
„DP8“ = HP EVA6400
Kapacita cca 84 TB hrubé kapacity, 8 GB cache
po ízeno 2010

16
1.4.4.3 Páskové knihovny

Zálohovací knihovny
Zálohovací knihovny jsou využity pro Centrální zálohování a archivování (nyní již až 10let) –
princip D2D2T (2T), jsou redundantně p ipojeny do SAN (rychlost p ipojení dle stá í od 4 Gb
do 8 Gb). FN HK vlastní níže uvedená za ízení:

· 2x HP MSL4048 každá po 48 slotech a 2xLTO6, označené Lib7 a Lib8
· 2x HP MSL4048 každá po 48 slotech a 2xLTO5, označené Lib5 a Lib6
· 1x HP MSL6060 60slotů 3x LTO4, označené Lib4
· 1x Overland NEO4000 60slotů 2xLTO3, označené Lib2

1.4.5 Pracovní stanice s MS Windows

Zadavatel provozuje zhruba 3150 pracovních stanic.
Pracovní stanice (PC) jsou p ipojeny a ově ovány v ActiveDirectory Win2008R2
Stanice jsou p evážně vybaveny procesory i3, 4GB RAM, MS Win7 32bit Prof. Nově se
distribuují počítače s procesory i3, 8GB RAM, Win10 64bit Prof. Lůžkové stanice v areálu FN
HK jsou p ipojeny do datové sítě 1000BASE-T. Mimo areál pak (Stará nemocnice a léčebna
Nechanice) 100BASE-T.
Většina monitorů je 19“ s poměrem stran 5:4 a rozlišením 1280x1024.

1.4.6 Zálohování a dohled

IT FN-HK jsou i v oblastech virtualizace, dohledů a zálohování založeny na celosvětově
osvědčených a rozší ených technologiích.

1.4.6.1 Centrální zálohování

Pro centrální zálohování dat FN HK využívá níže uvedené technologie:
a) specializované lokální nástroje pro aplikačně konzistentní zálohování. Jde
většinou o utility, které jsou součástí databází nebo operačních systémů (nap .
ontape z Informixu, zálohovací utilita z MSSQL, Ignite z HPUX apod.). Zálohovací
nástroje databází navíc mohou využívat technologie transakční logů pro obnovy
s RPO blízké 0 min.
b) SW pro centrální zálohování HP DataProtector., který běží na dvou cellech. V roce
2018 proběhne upgrade na ver 9 a napojení na nové pole HP StoreOnce.
Licenčně je vybaveno:
1x Cell Mng for HPUX
1x Cell Mng for Win
2x Drive for UNIX/SAN/NAS
6x Drive for WIN/Linux/Netware
2x Adv Backup to Disk 10TB

17
1x Online Ext for Win
Všechny tyto licence jsou podporovány servisní smlouvou.
c) SW pro centrální zálohování Acronis BaR v5 (hlavně pro „disk images“ oper.
systémů), které pokrývá virtuální servery na 8 fyzických hostech VMware a 2x
normální fyzický server
Licenčně je vybaveno a pokryto servisní smlouvou:
7x ABA Univ
1x ABA Virtual
2x ABA Adv Srv

Výše uvedené zálohovací nástroje spolupracují s technologiemi diskových polí nebo VMware
a využívají jejich funkcionality (hlavně SnapShot) pro optimalizaci záloh a zajištění
konzistence („System crash konzistence“ nebo „Aplikačně crash konzistence“)

Popis hlavních vlastností záloh:

a) Víceúrovňové zálohování s centrálním ovládáním,
· „zálohování krátkodobé/provozní“ jehož hlavním smyslem je rychlá obnova
s minimálními ztrátami dat (min. RTO dle množství dat a minimální RPO, které se
blíží 0 min)
· S exspirací záloh nejčastěji 1den až 1 měsíc. Zálohy jsou většinou uložený na
discích.
· „zálohování dlouhodobé“ jehož hlavním smyslem je obnova určitých částí dat
nebo možnost doložení stavu dat k danému datumu.
S exspirací 6 týdnů až 10let. Důležitým kritériem je cena za uložení dat a jejich
dlouhodobé uložení, proto jsou zatím většinou ukládány na LTO pásky.

Zálohování je koncipováno jako více úrovňové (v první úrovni se většinou nástroji
databází konzistentně zálohují data na „lokální disky“ a teprve v druhé úrovni se
DataProtectorem zálohují krátkodobě požadované data a poté se většinou provádějí
„dlouhodobé zálohy“ (Backup Copy) na LTO pásky. Vybraná zálohovací media jsou
dostupná p íslušným správcům, aby p ípadná obnova proběhla s min. prodlevou.

b) P i zálohování zadavatel využívá různé technologie/funkcionality pro optimalizaci.
Nejčastěji používané funkcionality: D2D2T, Full+IncrX, Paralelní SubJoby, SnapShot,
BackupCopy, plánování spouštění a exspirace a správy medií, funkcionality pro
požadovanou úroveň konzistence dat, konsolidace dat, deduplikace ...

c) Frekvence záloh bývá nejčastěji 1x denně.

Pro KIS AMIS_H jsou využity tyto zálohovací technologie:
a) pro provozní zálohy (důraz na RPO a RTO blízké 0)
HPUX : DRD , Ignite
Informix: ontape a transakční logy (tzv. logické logy)
FS + konfig DataProtector ( zálohováním vybraných dat filesystému)
b) pro dlouhodobé zálohy (důraz na cenu za GB + dlouhodobost uložení + možnosti
správy těchto dat, nap rearchivace)
se používá DataProtector s ukládáním na LTO .
Pro činnost jsou využity
- systémové zdroje (cca 2TB z disk.polí a dvě Library s cca 20ks LTO5 a 10xLTO3)

Licence DataProtectoru (cca 1xCell Mng for HPUX; 1x Drive for UNIX; 1x Drive for WIN)

18
1.4.6.2 Dohledy IT infrastruktury
Dohled HW produktů HP, které jsou nonstop dohledované p ímo výrobcem s automatickým
zakládáním Case a s dobou odezvy od 2hod po NBD (různé technologie HP: HP 3PAR, SIM,
IRS, CV, ACU,...).
Dohled operačního systému HPUX je nástroj HP (SMH d íve SAM)
Dohled HW produktů Lenovo, které jsou servisovány p ímo výrobcem nonstop
s automatickým zakládáním Case a s dobou odezvy od 2hod po NBD.
Hlavní dohled virtuálních serverů v jedné VMware farmě (100 ks VCO)
Dohled sítě LAN: HP IMC
Dohled systému Microsoft: SCOM (jen omezený počet licencí)

19
Příloha č. 3:

Funkční požadavky
Obsah

P íloha č. 3: ..................................................................................................................... 1
Funkční požadavky......................................................................................................... 1

1 Koncepce..................................................................................................................... 5

1.1 Specifikace požadovaného ešení ...................................................................... 6

1.1.1 Architektura požadovaného ešení .................................................................................... 6

1.1.2 Technologická a infrastrukturní architektura .................................................................... 10

2 Minimální požadavky na Klinický informační systém............................................... 12

2.1 Základní požadavky...........................................................................................12

2.1.1 Obecné požadavky .......................................................................................................... 12

2.1.2 Číselníky........................................................................................................................... 26
2.1.3 Národní registry a výkazy................................................................................................. 33

2.1.4 Statistické výstupy – reporting ......................................................................................... 33

2.1.5 Tiskové sestavy................................................................................................................ 36

2.1.6 Editor textů ....................................................................................................................... 38
2.1.7 P ístupová práva .............................................................................................................. 38

2.1.8 Logování a auditní služby ................................................................................................ 40

2.2 Požadavky na klinické subsystémy....................................................................40

2.2.1 Lůžkový fond .................................................................................................................... 40
2.2.2 Akutní lůžková péče (multiklinická hospitalizace) ............................................................ 43
2.2.3 IT ešení pro porodnictví a neonatologii........................................................................... 55

2.2.4 Procesní podpora sledování nozokomiálních nákaz a podpory oddělení nemocniční
hygieny ............................................................................................................................. 60

2.2.5 Operační sály ................................................................................................................... 61
2.2.6 Ošet ovatelskádokumentace v KIS .................................................................................. 65

2.2.7 Základní ošet ovatelské složky ........................................................................................ 66

2.2.8 Ambulance ....................................................................................................................... 87

2.2.9 Univerzální klinické funkce............................................................................................... 96

2.2.10 IT podpora vyšet ování na patologii ................................................................................. 96

2.2.11 Poukaz na léčebnou a ortopedickou pomůcku, Poukaz na brýle a optickou pomůcku a
Poukaz na foniatrickou pomůcku ..................................................................................... 99

2.2.12 Komplexní IT ešení pro procesy spojené se zobrazovacími metodami ......................... 99

2.2.13 Dočasná pracovní neschopnost, eNeschopenka........................................................... 105

2.3 Požadavky na specifické funkcionality.............................................................105

2.3.1 Doprava.......................................................................................................................... 105

2.3.2 AISLP ............................................................................................................................. 107

2.3.3 Sledování pacientů léčených v centrech........................................................................ 107
2.3.4 IT ešení procesů klinického farmaceuta ....................................................................... 107
2.3.5 Funkce KIS pro sledování chirurgických komplikací...................................................... 110

2
2.3.6 Funkce pro proces onkologického p ípadu .................................................................... 111

2.3.7 Obecné požadavky na žádanky pro laboratorní komplement........................................ 113

2.3.8 IT ešení pro zobrazování laboratorních komplementárních výsledků .......................... 115

2.4 Požadavky na komplexní ešení procesu po izování výkazů a vyúčtování

zdravotní péče pro všechny typy plátců péče (p ípusné ešení - modul „Pojišťovna“) .....117

2.4.1 Po ízení, editace a kontrola dat ..................................................................................... 117

2.4.2 Po ízení položky (výkon, ZULP/ZUM) vyžadující schválení RL - Žádanka o schválení 118

2.4.3 Kontroly .......................................................................................................................... 118

2.4.4 Externí vstup K-dávek z jiných systémů ........................................................................ 120
2.4.5 Podpora DRG výkaznictví .............................................................................................. 120

2.4.6 Centrální zpracování zdravotní péče dle metodiky pojišťoven - „uzávěrka“................. 121
2.4.7 Vyúčtování dopravy........................................................................................................ 121
2.4.8 Opravy dokladů po vyúčtování ZP ................................................................................. 122
2.4.9 Import chybových protokolů ........................................................................................... 122
2.4.10 Kapitace ......................................................................................................................... 122

2.4.11 Práce se samoplátci a pojištěnci z EU ........................................................................... 123
2.4.12 Podpora agendy tzv. Centrových léků (CL, léky s vykazovacím limitem „S“) a domácích

receptů ........................................................................................................................... 123
2.4.13 Agenda poplatků ............................................................................................................ 124
2.4.14 P íloha č. 2 (VZP)........................................................................................................... 125

3 Minimální požadavky na portál pacienta ................................................................125

3.1 Obecné požadavky..........................................................................................125

3.2 Autentifikace uživatele.....................................................................................126

3.3 Zobrazované informace...................................................................................127

4 Minimální požadavky na integrační platformu včetně zhotovení komunikačních
vazeb s vyjmenovanými systémy ........................................................................... 128

4.1 Požadavky na integrační platformu..................................................................128

4.2 Seznam požadovaných komunikací ................................................................130

5 Požadavky na migraci dat a p echod na nový systém .......................................... 148

5.1 Migrace dat a p echod na nový systém ...........................................................148

5.1.1 Migrace dat..................................................................................................................... 148

5.1.2 P echod na nový systém................................................................................................ 149

6 Zálohování............................................................................................................... 150

7 Bezpečnost.............................................................................................................. 152

8 Provozní podmínky ................................................................................................. 154

8.1 Uživatelé .........................................................................................................154

8.2 Požadované provozní podmínky......................................................................154

8.3 Zajištění provozu ešení ..................................................................................155

8.4 Technická, technologická a aplikační podpora.................................................155

3
9 Požadované služby ................................................................................................. 157

9.1 Služby v rámci dodávky...................................................................................157

4
1 Koncepce

Podstatou projektu je vytvo ení IS, který umožní efektivní komunikaci a p enos
informací v rámci nemocnice a mimo ní, čímž dojde ke značnému zefektivnění
sdílení a zpracování dat. V rámci projektu je p edpokládaná zabezpečená
komunikace s dalšími zdravotnickými za ízeními, léka i a pacienty. Významným
p ínosem projektu tak je mimo jiné podstatné zvýšení bezpečnosti a spolehlivosti
veškerých dat vznikajících v heterogenním prost edí informačních systémů
implementovaných v nemocnici p i zvýšené možnosti komunikace s jinými
specializovanými pracovišti.

1. Projekt bude zahrnovat p edevším po ízení:
2. Portálu pacienta.
3. Integrační platformy včetně zhotovení komunikačních vazeb s vyjmenovanými

systémy.
4. Klinického informačního systému disponujícím požadovanými vlastnostmi,
5. Hardware pro provoz těchto komponentů.

5
1.1 Specifikace požadovaného řešení
1.1.1 Architektura požadovaného řešení

6
Katalog aplikačních komponent a funkcí

Typ prvku Aplikační prvek Význam
Aplikační SÚKL eRecept Součástí projektu je integrace na IS eRecept pro
rozhraní ČSSZ eNeschopenka elektronickou preskripci.
Aplikační ÚZIS Dále budou využívány následující IS:
rozhraní
Aplikační · RLPO – registr pro léčebné p ípravky s omezením
rozhraní · CDNU – centrální databáze nežádoucích účinků
· CÚER – centrální úložiště elektronických receptů
Součástí projektu je integrace na IS eNeschopenka pro
p edávání informací o neschopenkách na ČSSZ/OSSZ
Součástí projektu je optimalizace vykazování na ÚZIS
Systém musí zajistit maximálně automatizovanou komunikaci
a p edávání dat na ÚZIS, resp. do relevantních registrů v
rozsahu požadavků daných legislativou, p ípadně zajistit
export dat pro ÚZIS. Konfigurace a nastavení komunikace
musí být realizovatelná zaškolenými pracovníky
poskytovatele.

Aplikační Poskytovatelé služeb Součástí projektu je integrace a podpora výměny dat s
rozhraní zdravotních ostatními zdravotnickými za ízeními a dalšími externími
(PZS) systémy dle budoucích požadavků státní strategie eHealth.
Aplikační Systém musí být p ipraven na perspektivní napojení na
rozhraní integrované datové rozhraní resortu (právě probíhají ve ejné
Aplikační zakázky MZ ČR, které jej vytvá í); v době tvorby zadávací
rozhraní dokumentace požadujeme p ipravenost integrační platformy
Aplikační na p edávání dat ve standardech HL7, DASTA4, DASTA3..
rozhraní Systém také musí zajistit zasílání zpráv a výsledků smluvním
Aplikační poskytovatelům zdravotních služeb pro p edávání výsledků
rozhraní komplementárních vyšet ení bezpečnou šifrovanou formou
elektronické komunikace. Dále pak podporovat komunikaci
Aplikační se ZZS formou p íjmu informace o výjezdu.
rozhraní
Pacienti Pro služby pacientovi bude Portál pacienta, kterého hlavním
zdrojem dat bude integrační platforma. Hlavní využití bude
možnost vyhledávat informace o zdravotních službách,
objednávat termíny vyšet ení, získávat upozornění na
plánované termíny cestou SMS nebo e-mailu.

Zdravotní pojišťovny Součástí projektu je vykazování péče zdravotním
pojišťovnám v souladu s platnou legislativou.

NIX-ZD (eMedocs) NIX ZD – Národní systém pro výměnu zdravotnické
dokumentace.

Externí certifikační Součástí projektu je integrace na externí certifikační autoritu
autorita pro zajištění autentizačních služeb, agendy související se
správou certifikátů apod.

IDRR IDRR – Integrované datové rozhraní rezortu je aktuálně
NIA vytvá eno na MZČR v rámci ve ejné zakázky a mělo by být
eH NCP známé na konci realizace projektu. Integrace na Informační
systém základních registrů, konkrétně na registr obyvatel
(ROB), jakmile bude umožněn p ístup a využívání
bezvýznamového identifikátoru (AIFO).

NIA – Národní bod pro identifikaci a autentizaci nebo též

7
Typ prvku Aplikační prvek Význam
Národní identitní autorita zajišťující identifikační a
autentizační služby garantované státem.
eH NCP - Národní kontaktní místo pro eHealth pro Českou
republiku
Integrace bude součástí projektu jen v p ípadech, kdy v době
realizace projektu budou tyto systémy p ipraveny pro
integraci, a bude zajištěno legislativní prost edí, které
integraci umožní.

Aplikační KIS Klinický informační systém je součástí projektu
komponenta
Aplikační Lékárna Lékárenské IS – není p edmětem dodávky, součástí je
komponenta integrace.
Aplikační
komponenta Laboratorní informační systém pro biochemii, Imunologii,
mikrobiologii a hematologii – není p edmětem dodávky,
Aplikační LIS součástí dodávky je ale obousměrná integrace s tímto IS.
komponenta
Nap . elektronické žádanky i sdělování výsledků.
Aplikační
komponenta LIS Patologie Laboratorní informační systém – není p edmětem dodávky,
součástí je integrace s tímto IS a zprost edkování
Aplikační komunikace tohoto SW prost ednictvím integrační platformy
komponenta s datovým rozhraním ÚZIS pro p edávání výsledků.
Aplikační
komponenta Transfuzní oddělení IS pro transfuzní oddělení – není p edmětem dodávky,
Aplikační součástí je obousměrná integrace s tímto IS. Jde nap . o
komponenta objednávání transfuzních p ípravků pro pacienty, p edávání
Aplikační informací o krevní skupině, výsledků z diagnostických
komponenta vyšet ení.
Aplikační
komponenta PACS Správa obrazových informací – není p edmětem dodávky,
Aplikační součástí je integrace s tímto IS.
komponenta
Aplikační ePACS správa obrazových informací – není p edmětem dodávky,
komponenta součástí je integrace s tímto IS.
Aplikační
komponenta Stravovací systém IS pro Stravování je podporován dvěma SW – není
p edmětem dodávky, součástí je integrace.
Aplikační
komponenta EIS Ekonomický systém – není p edmětem dodávky, součástí je
integrace s tímto IS.
Aplikační
komponenta MIS Manažerský systém (MIS) - není p edmětem dodávky,
součástí je integrace s tímto IS.

PaM Mzdový a personální systém, základní správa zaměstnanců
– není p edmětem dodávky, součástí je integrace s tímto IS.

Spisová služba Spisová služba – není p edmětem dodávky, součástí je
integrace s tímto IS.

Zabezpečený Dlouhodobý bezpečný archiv pro zajištění životního cyklu
dlouhodobý a elektronické zdravotnické i nezdravotnické dokumentace –
důvěryhodný archiv není p edmětem dodávky, součástí je integrace s tímto IS.

ízení p ístupů ízení p ístupů (autentizace) uživatelů na základě oprávnění
– není p edmětem dodávky.
Součástí projektu je integrace na MS ActiveDirectory FN HK
a Identity management (IDM).

Ostatní integrované Ostatní systémy, které nejsou p edmětem dodávky, ale
systémy p edpokládá se integrace - viz kapitola Integrační platforma.

8
Typ prvku Aplikační prvek Význam
Aplikační
komponenta Ostatní systémy bez Nejsou p edmětem dodávky, součástí není integrace s tímto
integrace IS.

9
1.1.2 Technologická a infrastrukturní architektura

Katalog technologických komponent

Typ prvku Technologický Význam
prvek
Služba infrastruktury
Bezpečné Veškeré služby vstupně výstupní brány, vzdálený p ístup
Uzel p ipojení k správců k aplikacím, p ístup zaměstnanců, pacientů a
Zařízení internetu návštěvníků k internetu.
Aplikační rozhraní
Systémový software Datové centrum Všechna data a systémy jsou umístěny zde, ve dvou
Uzel serverovnách, které tvo í jednotně kontrolované centrum.
Aplikační rozhraní
Lokace Diskové pole Požadovaná kapacita, bezpečnost, rychlost, vysoká
Služba infrastruktury dostupnost.
Služba infrastruktury
Služba infrastruktury DMZ Demilitarizovaná zóna

Infrastrukturní Veškeré SW pat ící k technologické infrastruktu e
SW

Komunikační Spravuje redundantní lokální sítě a demilitarizovanou
uzel zónu.

LAN FN HK Lokální síť FN HK. Každá budova má vlastní VLAN.

Lokalita Budou zachovány současné lokace
serverovny

Provozní a Technologie a služby technologické úrovně pro veškeré
servisní služby aplikační služby, podpůrné služby, údržbové služby.

Publikace Zve ejnění služeb datového centra nemocnice
služeb DC

P ístup Technologické zabezpečení (síť – aktivní i pasivní prvky,
koncových koncové stanice atd.)

10
Typ prvku Technologický Význam
Služba infrastruktury prvek
Služba infrastruktury
uživatelů k
internímu
portálu

P ístup Technologické zabezpečení (síť – aktivní i pasivní prvky,
koncových koncové stanice atd.)
uživatelů k
jednotlivým IS

P ístup Technologické zabezpečení demilitarizovaných zón a
koncových jejich propojení s interním systémem, kontrola, obrana
uživatelů k p ed útoky.
ve ejnému
portálu

Služba infrastruktury Sdílené Poskytuje vnější subjekt (v rámci eGov), technologická
technologické infrastruktura o nich musí vědět a znát jejich popis.
služby
eGovernmentu

Sdílené Poskytuje vnější subjekt (v rámci eGov), technologická
InfrastructureFunction technologie infrastruktura o nich musí vědět a znát jejich popis.
Serverovna v budově číslo 24 (OVS)
eGovernmentu Serverovna v budově číslo 12 ( editelství)

Uzel Serverovna 1 Monitorování provozu celého systému se odehrává
p edevším na technologické a infrastrukturní úrovni.
Uzel Serverovna 2
Služby elektronického podpisu a dalších principů, které
Služba infrastruktury Služba zajišťují důvěru p i elektronické komunikaci, musí
monitoringu a poskytovat jednotně technologická infrastruktura.
alertovací
služba

Služba infrastruktury Technologie
eIDAS

11
2 Minimální požadavky na Klinický informační systém

2.1 Základní požadavky
2.1.1 Obecné požadavky

Sloupec Z vyplňuje ZADAVATEL!

P – Povinný požadavek k datu podání nabídky.
D_II – Povinně doprogramovatelný požadavek k datu zahájení testovacího provozu druhé etapy
D_III – Povinně doprogramovatelný požadavek k datu zahájení testovacího provozu t etí etapy
D_IV – Povinně doprogramovatelný požadavek k datu zahájení testovacího provozu čtvrté etapy
N – Nepovinný požadavek. Bude součástí hodnocení nabídek.

Sloupec U vyplňuje ÚČASTNÍK

Výběrem z variant, deklaruje svoji p ipravenost na splnění konkrétního požadavků:

S – Splňuje
D- Doprogramuje
N- Nesplňuje

Podrobný popis metodiky vyplňování viz kapitola 4.1 ZD.
POŽADAVEK

ČÍSLO FORMULACE Z U

KIS_001 Pro plnění zakázky je podstatné splnění všech funkcí
dodávaného IT ešení v souladu s požadavky specifikovanými
níže v této zadávací dokumentaci. KIS může být modulární s tím,
že použité moduly a jejich vzájemné kombinace poskytnou
optimální procesní podporu pro zdravotnická pracoviště. Jinými
slovy: Pokud bude dodávka ešena modulárně, uchazeč musí
dodat všechny pot ebné moduly svého ešení tak, aby úplně P Vyberte
dosáhl všech požadovaných funkcí dodávaného IT ešení.
Možnost volání funkcí v KIS musí být p ístupné
z implementovaného ešení tak, aby bylo možné použít plnou
variabilitu produktu (p íklady – naplánovat operaci nebo provést
preskripci léčiva na recept musí být možné jak u
hospitalizovaného, tak ambulantně léčeného pacienta).

KIS_002 KIS principiálně umožní detailní nastavení jednotlivých
funkcionalit (nap . struktura dokumentace, parametrizace hodnot,
kontroly vyplňování, p ístupová práva, nastavení grafiky a fontu
písem) podle pot eb vedení nemocnice a konkrétních pracovišť.
Nastavení funkcí KIS jako celku, ale i pro jednotlivá pracoviště, P Vyberte

nebudou p ístupná každému uživateli, ale jen zadavatelem
určené skupině osob; tím podpo í procesní ízení.

KIS_003 KIS musí z pohledu uživatele komunikovat výhradně v jazyce P Vyberte
českém.

KIS_004 Pro práci správců a administrátorů se u definovaných P Vyberte
systémových komponent p ipouští komunikace i v jazyce
anglickém.

12
KIS_005 KIS musí ve všech svých komponentách kontinuálně garantovat
shodu s legislativou a rozhodnutími orgánů s výkonem státní
moci (nap . SÚKL, SÚJB), z níž za nejdůležitější aktuálně
považujeme zejména:

· Zákon č. 110/2019 Sb., o zpracování osobních údajů, P Vyberte
v platném znění

· 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ů

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

· Zákon č. 378/2007 Sb. o léčivech, ve znění pozdějších
p edpisů

· Zákon č. 268/2014 Sb. o zdravotnických prost edcích, ve
znění pozdějších p edpisů

· Vyhláška č. 54/2008 Sb., o způsobu p edepisování
léčivých p ípravků, údajích uváděných na léka ském
p edpisu a o pravidlech používání léka ských p edpisů,
ve znění pozdějších p edpisů

· Vyhláška č. 84/2008 Sb., o správné lékárenské praxi,
bližších podmínkách zacházení s léčivy v lékárnách,
zdravotnických za ízení a u dalších provozovatelů a
za ízení vydávajících léčivé p ípravky, v platném znění

· Vyhláška č. 62/2015 Sb., o provedení některých
ustanovení zákona o zdravotnických prost edcích,

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

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

znění vyhlášky č. 137/2018 Sb. v platném znění
· Vyhláška č. 373/2016 Sb., o p edávání údajů do

Národního zdravotnického informačního systému,
v platném znění

KIS_006 Pro účely vytvá ení vlastních reportů zadavatelem p edá
dodavatel zadavateli popis kompletního datového modelu včetně
informací o propojení jednotlivých tabulek a informací o významu
sloupců. Dodavatel se dále zaváže tento popis udržovat aktuální P Vyberte

a p edávat zadavateli aktuální verzi vždy nejpozději do 14 dní od
provedení změny, a to po celou dobu životnosti produktu.

KIS_007 KIS musí umožnovat fulltextové vyhledávání pomocí etězce a P Vyberte
klíčových slov.

KIS_008 KIS musí mít možnost administrátorsky definovat systémové N Vyberte
zkratky k ovládání systému.

KIS_009 Konkrétní záznam ve formě parametrického údaje nebo volného
textu KIS automaticky p enáší do ostatních formulá ů, kde se
totožný záznam také vyskytuje. Takový p enos informace není
izolovaný pouze na okamžik otev ení formulá e, ale KIS umí P Vyberte
synchronizovat shodné položky průběžně, a to i s časovým
odstupem od okamžiku, kdy bylo ukončeno poskytování
zdravotních služeb (nap . synchronizace skutečného rodného

13
čísla v dokumentaci rodičky a novorozence/-ů). Taková
aktualizace se ale neuplatní u již archivované a vůči editaci
uzamčené zdravotnické dokumentace – tj. pokud v budoucnu
uživatel zp ístupní, pop . vytiskne nebo elektronicky odešle již
uzav enou zdravotnickou dokumentaci, veškeré údaje v
dokumentu musí zůstat se stejnými hodnotami, které byly platné
v okamžiku archivace dokumentu. Pokud je v konkrétních
p ípadech synchronizace parametrických nebo textových údajů
nepot ebná či dokonce nežádoucí, zadavatel ji označí v rámci
p ípravného projektu.

KIS_010 KIS bude disponovat funkcí pro upozornění nežádoucích N Vyberte
interakcí léků v souladu s legislativou.

KIS_011 KIS bude p i práci s číselníkovými položkami disponovat funkcí
nástroje pro urychlení vyhledávání požadovaných položek na
základě alfanumerických znaků či skupin znaků zadaných P Vyberte

uživatelem (tzv. našeptávače).

KIS_012 KIS musí také umožňovat podepisování elektronických
dokumentů kvalifikovaným elektronickým podpisem,
kvalifikovanou elektronickou pečetí a p ipojování kvalifikovaného
časového razítka v souladu s pravidly podle eIDAS. Pokud
nebude požadován kvalifikovaný elektronický podpis, KIS ke
každému zápisu informací do systému, a to včetně logu událostí,
p ipojí identifikaci oprávněné osoby, které náleží p ihlašovací
údaje použité pro vstup do KIS; p itom nehraje roli, jestli se P Vyberte
oprávněná osoba do KIS zalogovala v rámci tzv. single sign on
p i p ihlášení do zabezpečené sítě zadavatele nebo jestli se
zalogovala zadáním loginu a unikátního hesla nebo jestli se
zalogovala použitím komerčního osobního certifikátu na
bezpečnostním p edmětu a zadáním PIN nebo dokonce jinou
možností akceptovanou v rámci zásad kybernetické bezpečnosti,
kterou uchazeč může také nabídnout.

KIS_013 KIS má zabudovaný systém průběžného automatického ukládání P Vyberte
jako prevence ztráty dat včetně možnosti nastavení délky
časového intervalu.

KIS_014 Užívání KIS musí být intuitivní a snadné tak, aby nezvyšovalo
administrativní zátěž uživatelů. Ergonomie užívání KIS musí být
jednotná, vst ícná po stránce grafické i funkční.

KIS_015 Grafické rozhraní (dále také „GUI“) KIS je pro uživatele nap íč
celým systémem, v p ípadě modulární struktury nap íč všemi
moduly, jednotné. Pod pojmem jednotné se rozumí takové (GUI)
ovladatelné klávesnicí a myší, v rámci kterého bude zajištěno u
všech dodávaných částí KIS ovládání jednotným způsobem, tzn. P Vyberte
stejné ovládací prvky a stejná logika/funkcionalita u jednotlivých
ovládacích prvků. Odlišnosti v grafickém rozhraní zadavatel
p ipouští pouze pro systémové správce nebo administrátory
systému.

KIS_016 Zadavatel požaduje systém s grafickým uživatelským rozhraním
(GUI), který ve všech svých částech bude ovládán klávesnicí a
myší a umožní operace běžně dostupné v GUI (nap . označení P Vyberte

textu tažením myší, jeho vyjmutí, kopírování, vložení).

KIS_017 Grafické rozhraní je vybaveno svislými i horizontálními posuvníky P Vyberte
všude tam, kde se zobrazovaný obsah (zejména u sestav,
tabulek atp.) nevejde celý na monitor. Formulá e pro vkládání

14
informací musí být navrženy tak, aby pravé okraje všech oken P Vyberte
pro zadávání informací byly viditelné na obrazovce bez pot eby
použít horizontální posuvník (tj. horizontální posuvník u formulá ů P Vyberte
zadavatel nep ipouští). Pokud se formulá jako celek nevejde na P Vyberte
obrazovku monitoru a uživatel použije vertikální posuvník, roluje
pouze formulá pro záznam informací, svisle uspo ádaná nabídka P Vyberte
funkcí KIS vlevo na obrazovce (je-li p ítomna), nebo horizontálně P Vyberte
uspo ádaná nabídka funkcí KIS v horní části obrazovky (je-li D_II Vyberte
p ítomna) neroluje, zůstává zobrazena a je stále dostupná pro D_IIP Vyberte
uživatele (dá se popsat podobně jako funkce „ukotvit p íčky“
v MS-Excell). To nevylučuje situaci, kdy vertikálně uspo ádaná
nabídka funkcí KIS u levého okraje obrazovky může mít svůj
vlastní vertikální posuvník. Horizontálně uspo ádané nabídky
funkcí u horního nebo dolního okraje obrazovky musí být
zobrazeny najednou, tj. horizontální posuvník je u nich
nep ípustný.
KIS_018 Některé formulá e (nap . formulá e požadované ÚZIS – Zpráva o
rodičce, Zpráva o novorozenci aj.) mají p esně definovanou
velikost a strukturu textových polí, která se uplatňuje p i tisku
finálního dokumentu. Okna ve formulá ích KIS pro záznam
volného textu, která slouží k zadání informací právě do takového
definovaného pole formulá e, musí být v grafickém rozhraní
ešena tak, aby KIS obsahoval funkcionalitu pro hlídání a
následné upozornění uživatele na p ekročení maximálně
dostupného prostoru nap . velikostí nebo grafickým označením,
text se pak ve formulá i vytiskne celý, nesmí dojít ke ztrátě
informace.
KIS_019 KIS umožňuje měnit umístění nebo velikosti oken ve formulá ích
tam, kde změna negativně neovlivní p edem definovaný vzhled
tiskového výstupu (nap . u definovaných formulá ů ÚZIS).
KIS_020 Alespoň uvnit oken pro záznam volného textu KIS umožňuje
minimálně změnu fontu písma, jeho velikosti, zvýraznění textu
změnou typu písma (tučným, podtrženým nebo kurzívou), změnu
barev písma. Takové úpravy textu jsou dostupné i pro vytvá ení
individuálních úprav formulá ů a v uživatelských číselnících textů.
KIS_021 Všude tam, kde jsou v KIS informace o pacientech uspo ádány
do tabulek v ádcích a sloupcích, musí existovat možnost
kliknutím na záhlaví sloupce adit zobrazené informace dle
konkrétních hodnot ve sloupci (p íklady – se azení seznamu
pacientů dle p íjmení v abecedním po adí vzestupně/sestupně,
se azení seznamu podle data a času p íchodu, podle data
narození/čísla pojištěnce, p ítomnosti/nep ítomnosti konkrétního
zobrazeného kritéria).
KIS_022 Tam, kde jsou v KIS informace o pacientech uspo ádány do
tabulek v ádcích a sloupcích, zadavatel požaduje možnost v
záhlaví sloupce filtrovat zobrazené informace dle konkrétních
hodnot ve sloupci.
KIS_023 Tam, kde KIS jako odpověď na databázový dotaz
poskytne informace o pacientech ve formě jmenného
p ehledu/seznamu , zadavatel požaduje možnost intuitivně
snadného p echodu p ímo do relevantních zdravotních záznamů
zobrazených pacientů.
KIS_024 KIS kromě ovládání klávesnicí a myší musí disponovat i
klávesovými zkratkami pro nejčastěji prováděné činnosti,

15
zejména ukládání vytvo ené zdravotnické dokumentace, otev ení D_IIP Vyberte
nápovědy, tisk dokumentace, ale i další činnosti. D_II Vyberte
Vyberte
KIS_025 P idělené klávesové zkratky pro konkrétní činnost musí zůstat P Vyberte
nap íč celým systémem konstantní. P íklad: Klávesová zkratka P
pro vyvolání nápovědy nebo pro uložení po ízených informací Vyberte
musí zůstat stejná p i práci na recepci, ambulanci, lůžkovém P
oddělení, operačním sálu, p i vykazování péče atp. Vyberte
P
KIS_026 KIS umožňuje funkci „zpět psaní“ (tzn. ekvivalent funkce UnDo v
produktech MS-Office) p ed tím, než je text uložen.

KIS_027 KIS u konkrétního pacienta kromě textových informací musí být
schopen pro zdravotníky ukládat a zp ístupňovat informace i ve
formě zvuku, obrazu nebo videa.

KIS_028 Systém umožní p i po izování zdravotnické dokumentace
p ipojovat zvukový záznam diktovaný léka em tak, aby vlastní
p epis mohl provést následně administrativní pracovník a šet ila
se tím práce léka e. Systém upozorňuje (nap . graficky) na
existenci zvukového záznamu k dokumentování zdravotní služby.
Administrativní pracovnice má možnost zvukový záznam
p ehrávat, posouvat zpět i dop edu, aby jej mohla p epsat do
p íslušných polí v KIS. P epis textu administrativním pracovníkem
do KIS neznamená hned zp ístupnění textu ostatním uživatelům
KIS – toto je možné až poté, co p epis zkontroluje a autorizuje
léka , který zvukový záznam po ídil (aplikace principu
vícestupňové kontroly). Zadavatel požaduje, aby bylo možné
využívat také specializované p episovací SW t etích stran pro
oblast zdravotnictví, které jsou již dostupné a využívané v ČR
(nap . NovaVoice®, Philips Speech); pro publikaci takto
po ízených dokumentů také platí, že jejich zp ístupnění vůči
dalším uživatelům KIS je možné až po kontrole a autorizaci
léka em.

KIS_029 KIS je centrální bod ve FN, který vznikající zdravotnické
dokumentaci bude p idělovat identifikační údaje pacienta. Děje se
tak:
1. p ímo:
1.1. u textové zdravotnické dokumentace vytvá ené p ímo
v KIS
1.2. u obrazové dokumentace binární povahy, kterou KIS
p ipojí z jejich zdroje (nap . fotoaparátu, endoskopické
věže)
1.3. u zvukového záznamu po ízeného diktováním p ímo do
PC nebo nahraného jiným záznamovým za ízením a
p ipojeném uvnit KIS ke konkrétnímu pacientovi
2. nep ímo:
p edáním identifikačních údajů pacienta pomocí integračních
vazeb do jiných specializovaných softwarových nástrojů.
P íkladem takové situace je p edání žádanek na
komplementární vyšet ení laboratorní (LIS) a zobrazovací
(systémy PACS)

KIS_030 KIS kromě funkce po izování zdravotnické dokumentace musí být
vybaven pokročilými vyhledávacími nástroji a být zdrojem
informací v reálném čase, tj. alespoň k rutinním provozním
informacím musí KIS zprost edkovat p ístup v okamžiku pot eby.

16
KIS_031 U každého dokumentu o poskytování zdravotních anebo P Vyberte
sociálních služeb vytvo eného prost ednictvím KIS nebo do KIS
importovaného (nap . výsledku komplementárního vyšet ení) u D_IV Vyberte
konkrétního pacienta (fyzické osoby) systém rozlišuje, jestli
dokument vznikl v rámci poskytování ambulantních zdravotních D_IV Vyberte
služeb, nebo hospitalizace. Zdravotnická dokumentace je podle D_IV Vyberte
těchto souvislostí seskupována do samostatných částí Vyberte
zdravotnické dokumentace konkrétního pacienta v rámci P Vyberte
zadavatele. Samostatnou část dokumentace tvo í také výsledky P
komplementárních vyšet ení (radiologie, patologie, laborato e
atp.), které zadavatel provedl na vyžádání jiným externím
poskytovatelem zdravotních služeb (tj. pacient p ed provedením
vyšet ení nebyl ošet ován na pracovištích zadavatele).

KIS_032 Každá samostatná část dokumentace uvnit KIS vede k p idělení
skartačního znaku a nastavení doby uchování v souladu
s platnou legislativou. Skartační znak i odpovídající doba
uchování je uvnit KIS p idělena všem jednotlivým dokumentům,
které jsou integrální součástí samostatné části dokumentace
zadavatele. Skartační znak i odpovídající doba uchování jsou
editovatelné oprávněnými osobami, aby bylo možné reagovat na
změny zdravotního stavu pacienta a na změny legislativy.
Jakmile KIS obdrží informaci z registru pacientů o úmrtí pacienta,
umožní oprávněné osobě změnit skartační znak a dobu uložení
samostatné části zdravotnické dokumentace v souladu
s legislativou. KIS p idělený skartační znak využívá k:
1. nabídce samostatných částí zdravotnické dokumentace
zadavatele ke skartaci po uplynutí doby uchování v souladu
s legislativou; KIS musí být schopen bezpečně odstranit
dokumenty určené ke skartaci ze všech svých částí,
2. vytvá ení sestav pro další softwarové systémy obsahující
části zdravotnické dokumentace pacienta a integrované
s KIS v době dodávky i p ípadně v budoucnu za účelem
posouzení provedení skartace dokumentů vedených v těchto
systémech,
3. vytvá ení sestav samostatných částí listinné zdravotnické
dokumentace pacienta uložených ve spisovnách zadavatele
za účelem posouzení pot ebnosti dokumentace a vzniku
podklad pro sestavení skartačního seznamu.

KIS_033 KIS umožňuje po ídit a uchovat záznam, který obsahuje soupis
zničené zdravotnické dokumentace společně s informací o tom,
kdy, jak a kým byla dokumentace zničena v souladu s platnou
legislativou.

KIS_034 KIS v souladu s platným zněním vyhlášky o zdravotnické
dokumentaci podporuje tvorbu a správu léka ských posudků.
Zadavatel tím myslí zejména parametrická pole pro povinné
údaje, pole pro záznam účelu vydání posudku, posudkového
závěru, evidenčního označení posudku.

KIS_035 KIS umožňuje u všech procesů a jednotlivých polí v rámci
formulá ů na obrazovce práci s libovolným počtem uživatelem
p eddefinovaných textů nebo hodnot. U parametrických polí
s p esně definovatelným oborem hodnot vkládaných informací
může být alternativou k číselníku textů rozbalovací seznam.

KIS_036 Každé pole pro záznam volného textu v rámci formulá ů je
vybaveno funkcí historie. Funkce historie umožní zobrazit

17
všechny p edchozí texty v poli, které pochází z uložené anebo D_II Vyberte
uzav ené dokumentace; texty v konkrétním poli se nabízejí
azené od časově nejmladších k časově nejstarším. P Vyberte
KIS_037 Tam, kde na zdravotnickém pracovišti konkrétní odbornosti
k žádnému zápisu do pole volného textu dosud nedošlo, KIS D_IV Vyberte
začne všem oprávněným uživatelům ve funkci historie nabízet
všechny p edchozí použité texty ve stejném poli, které pochází D_II Vyberte
z uložené anebo uzav ené dokumentace z ostatních pracovišť D_II Vyberte
zadavatele odlišné odbornosti, pokud takové texty existují; jsou-li Vyberte
takové, jsou azeny v po adí od časově nejmladšího zápisu P Vyberte
k časově nejstaršímu. P Vyberte
KIS_038 Zadavatel pod pojmem parametrické pole chápe pole, jehož P
hodnoty nabývají hodnot dle číselníku nebo je jeho hodnota Vyberte
definována a zároveň omezená obecně známým způsobem. P
Obecnou vlastností parametrického pole je i možnost kontroly
vložených dat již p i zadávání dat. Jako p íklad lze uvést datum,
kód z číselníku Seznamu zdravotních výkonů s bodovými
hodnotami, t ímístné číselné pole pro výšku pacienta v cm.
KIS_039 KIS umožňuje kontrolovat datum zadání p edchozích údajů
v parametrickém poli. KIS umožňuje u definovaných
parametrických polí ponechat pole prázdné, pokud od okamžiku
vyplnění p edchozí hodnoty v KIS uplynula stanovená doba a
nelze je již považovat za aktuální (p íklad – u pacienta KIS
nabídne hodnotu hmotnosti pouze tehdy, pokud p edchozí
zadaný údaj nebude starší 3 měsíců).
KIS_040 Zadavatel níže v textu ZD up esňuje, kdy a kde takový
automatický p enos hodnot zadaných do parametrických polí
anebo dostupnost funkce historie u polí pro záznam volného
textu není požadována, nebo je dokonce nežádoucí. Detailní
nastavení p enosů informací obsažených v jednotlivých polích
bude up esněno v rámci prováděcího projektu.
KIS_041 Systém umožní oprávněným uživatelům tvorbu nových, p ípadně
úpravu vizuální stránku stávajících formulá ů v konfiguraci
systému bez nutnosti využití nap . programovacích prost edků.
KIS_042 Ve formulá ích na obrazovce zadavatel požaduje zarovnávání
textu k levému okraji textového pole. P i tisku je preferováno
zarovnávání do bloku.
KIS_043 Nejmenší použitá velikost písma ve formulá ích nesmí být menší
než 10 tiskových bodů.
KIS_044 Zadavatel požaduje tisk všech dokumentů tak, aby velikost písma
u všech informací týkajících se pacienta nebyla menší než 10
tiskových bodů. Menší velikost písma je výjimečně p ípustná
pouze v hlavičkách dokumentů nebo jiných provozních
informacích.
KIS_045 Pokud jsou ve formulá i okna pro záznam volného textu ve
výchozím, tj. nevyplněném stavu redukována jen na několik málo
ádků s cílem dostat formulá (nebo alespoň jeho podstatnou
část) na obrazovku najednou, pak zadavatel požaduje
dynamickou změnu velikosti takových textových polí pro vkládání
volného textu tak, aby byl do pole zapsaný text viditelný celý.
Text je v okně automaticky zarovnáván. Stisk Enter uvnit okna
vytvá í nový odstavec, neslouží k p echodu do následujícího
okna. Tuto variantu z ergonomického hlediska zadavatel

18
považuje za optimální. Zadavatel jako alternativní ešení p ipouští
pevnou velikost okna (minimální velikost alespoň 10 ádků) pro
záznam volného textu, u kterého se objeví vertikální posuvník
vždy, jakmile zapsaný text p esáhne prostor vymezený v okně.
Okna pro záznam volného textu ve formulá ích nesmí svým
pravým okrajem zasahovat mimo viditelnou část obrazovky a
automatické zarovnávání musí být funkční. Zadavatel nep ipouští
psaní textu horizontálně mimo okraj okna – tj. situaci, kdy by
léka p i kontrole zapsaného textu musel využívat horizontální
posuvník.

KIS_046 KIS disponuje nastavitelným systémem vícestupňové kontroly.
Vícestupňová kontrola je konfigurovatelná u libovolné role
v systému – u léka ů, neléka ských zdravotníků, administrativních
pracovnic, referentek pro zdravotní pojišťovny atp. Výsledkem
takového nastavení může nap . být situace, kdy zp ístupnění, P Vyberte

pop . tisk kteréhokoli dokumentu uvnit KIS vůči ostatním
oprávněným osobám nebo pacientovi je možné až po autorizaci
osobou, která má odpovídající práva.

KIS_047 Uzamčení dokumentu vůči změnám po jeho odsouhlasení
oprávněnou osobou samo o sobě neznamená vy azení
dokumentu z rozpracovaných dokumentů zejména kvůli
vyúčtování. Definitivní archivace dokumentů oprávněnou osobou
je možná až po uzav ení všech souvisejících administrativních a
účetních úkonů, mezi které zejména pat í:
· léka ská zpráva je uzav ená oprávněným léka em P Vyberte

· ošet ovatelská dokumentace je uzav ena a potvrzena

oprávněným NLP je ukončené vykázání kódů MKN-10

pro statistiku, systém DRG a vyúčtování

· je vykázán účet zdravotní pojišťovně

KIS_048 Legální p ístup k dokumentaci pacienta uvnit KIS léka p i azený
k jinému pracovišti v organizační struktu e KIS získá tím, že na
jeho pracoviště je vystavena žádanka na poskytnutí zdravotní
služby pro pacienta. Pokud se do zdravotnické dokumentace
pacienta pokusí nahlédnout, měnit, nebo dokumentaci tisknout
osoba, která na daném pracovišti podle organizační struktury
v KIS nemá k takovému p ístupu oprávnění, KIS ji na takový
postup upozorní a p ístup zprvu zablokuje. Pro omezenou
skupinu rolí může být v KIS povolena varianta, kdy se po
upozornění na možný nelegální p ístup otev e dialogové okno pro
záznam odůvodnění p ístupu takovou osobou. Pokud má daná
osoba důvod k pokračování v činnosti, zadá jej do dialogového
okna, s datem a časem se odpověď zaznamená do logu KIS, a
teprve poté bude moci pokračovat v činnosti. Pokud důvod
nevyplní, KIS jí p ístup definitivně odep e. Variantou je místo P Vyberte

dialogového okna pro zápis odůvodnění vstupu nabídnout
následující číselník, editovatelný zadavatelem (následuje
minimální sada položek odůvodnění):
· manažerská kontrola nap . ze strany zdravotnických

náměstků editele nebo editelem

· revize zdravotní pojišťovny – p i volbě této položky

vyskočí textové okno, kam je pracovník povinen uvést

seznam všech účastníků revize včetně instituce

· šet ení mimo ádné události

· auditní činnost – včetně textového okna účelu/typu auditu

· šet ení stížnostní agendy nebo žaloby

19
· šet ení orgánu ochrany ve ejného zdraví

· vědecko-výzkumné účely se specifikací názvu
výzkumného úkolu

· doplňování údajů do registrů národních nebo smluvních
pro zadavatele

· opravy vyúčtování péče
· jiné a povinný text vysvětlení
KIS svými funkcemi a vlastnostmi nesmí ohrozit bezpečnost
provozu ostatních informačních technologií užívaných ve FN, tj.
komunikace a p edávání údajů mezi KIS a ostatními systémy
zadavatele musí být vy ešena tak, aby nesprávná struktura
p edávaných dat nemohla způsobit nesprávné chování, ztrátu
nebo zneužití dat v jiné databázi/aplikaci.

KIS_049 KIS musí poskytovat procesní podporu všech zdravotníků –
kromě strukturovanosti záznamů musí kontrolovat, p ípadně
vynucovat vyplnění/aktualizace položek v záznamu; rozsah P Vyberte
nastavení funkce rozhodne zadavatel v průběhu analýzy a bude
součástí Prováděcího projektu.

KIS_050 Zadavatel očekává, že pro zadání informací jsou v jednotlivých
částech (modulech) KIS vytvo eny strukturované formulá e. Jde-li
údaje v oddílu zadávat jako parametrizovatelné, neměl by být
používán volný text. Tím KIS podpo í výběr informací pro
p edávání údajů pot ebných k ešení akutních zdravotních stavů P Vyberte
(tzv. pacientský souhrn) a vyhledávací funkce. Pouze tam, kde se
zaznamenávané informace mohou významně lišit co do obsahu, i
co do délky záznamu, očekává zadavatel formulá ová okna, do
kterých se vkládá volný text

KIS_051 P i editaci informací uvnit KIS zadavatel vylučuje nutnost použít P Vyberte
textový či jiný editor t etích stran – všechny záznamové
prost edky musí být nativní součástí KIS.

KIS_052 Zadavatel očekává funkční podporu ze strany KIS (může být
ešeno i modulárně) u následujících procesů minimálně
v následujícím rozsahu: ambulantní provoz (zahrnující i
neléka ské zdravotníky – nap . fyzioterapeuty, nutriční terapeuty,
sestry specialistky pro hojení chronických ran), provoz pro
ambulantní péči ve stacioná i, lůžkový provoz, provoz operačních
sálů a specializovaných výkonových pracovišť (nap . katetrizační
laborato , endoskopické pracoviště), provoz porodního sálu,
provoz neonatologie (p íklady - oddělení fyziologických
novorozenců, novorozenecká JIP, činnost na porodním sálu),
provoz oddělení zobrazovacích metod (tj. radiologický informační
systém), proces žádání o a zobrazování a výběru
komplementárních laboratorních výsledků včetně tabelárního a P Vyberte

grafického zobrazení volitelných typů vyšet ení a mě ených
hodnot, proces ošet ovatelské péče, proces preskripce léčivých
p ípravků kompatibilní plně s elektronickou preskripcí v souladu
s platnou legislativou, proces preskripce poukazů na zdravotnické
prost edky, komplexní ešení procesu po izování výkazů a
komplexu vyúčtování zdravotní péče pro všechny hypotetické
typy plátců péče (tj. od samoplátce až po úplnou úhradu
z prost edků ve ejného zdravotního pojištění), proces
elektronického způsobu vedení agendy dočasné pracovní
neschopnosti v souladu s platnou právní úpravou. Specifická
podpora procesů v oblasti resuscitační a intenzivní péče je

20
výhodou, není podmínkou. D_IV Vyberte
KIS_053 KIS musí být p ipraven na vedení čistě elektronické formy
P Vyberte
zdravotnické dokumentace v plném souladu s platnými právními
p edpisy. P Vyberte
KIS_054 Systém je plně kompatibilní se systémem Centrálního úložiště P Vyberte
elektronických receptů SÚKL a umí plně využívat veškerý P Vyberte
potenciál systému elektronické preskripce v ČR. P i vyhledávání D_II Vyberte
léčivých p ípravků p edepisovaných na recept využívá platný D_II Vyberte
číselník zve ejňovaný SÚKL na www.opendatasukl.cz, tak aby P Vyberte
nedocházelo k neztotožnění léků.
Systém umožní vyhledání kvalifikovaného certifikátu na základě
otisku a dostupných údajů uložených v sekci „Subjekt“ pomocí
kombinace „OU“(obsahuje osobní číslo zaměstnance) + „T“
(obsahuje login do KIS bez úvodního písmena „N“) včetně
ově ení platnosti (nejnovější). V p ípadě kdy se certifikát
nedohledá ani jedním z výše uvedených způsobů, tak systém
nabídne seznam dostupných certifikátů na pracovní stanici
uživatele. Zadavatel p ipouští i jinou metodu vyhledání
kvalifikovaného certifikátu za p edpokladu, že nedojde k
administrativnímu zatížení uživatele respektive zadavatele.
KIS_055 Pro ordinaci léčiv na lůžkových odděleních je systém vybaven
vlastním systémem, který je p esně specifikován v požadavcích
na podporu práce na lůžkovém oddělení včetně jednotek
intenzivní péče.
KIS_056 Systém v průběhu preskripce léčivých p ípravků poskytuje léka i
informaci o tom, jestli je lék na pozitivním listu (zdravotní
pojišťovny, zadavatele). Správu pozitivního listu může ovlivňovat
pracovník zadavatele. Informace může být poskytnuta barevnou
signalizací v názvu léčivého p ípravku, optimálně podbarvením
textového pole, je p ípustné i označení značkou v ádku léčivého
p ípravku. Konkrétní nastavení bude p edmětem analytické fáze
a nastavení systému p ed implementací.
KIS_057 KIS v průběhu preskripce a medikace léčivých p ípravků umožní
vyhledání a výběr léčivého p ípravku tím, že léka začne psát
název hledaného léčivého p ípravku.
KIS_058 KIS musí umět využívat skladových informací lékáren zadavatele
o místě a dostupnosti léčivého p ípravku, které nabídne v rámci
ambulantní preskripce.
KIS_059 Pokud léka vystaví p edpis na léčivý p ípravek (eRecept) nebo
zdravotnický prost edek p ed uzav ením ambulantní zprávy nebo
závěrečné zprávy z hospitalizace, KIS údaj o p edepsaných
léčivých p ípravcích nebo zdravotnických prost edcích
automaticky p enese do ambulantní zprávy nebo závěrečné
zprávy z hospitalizace.
KIS_060 KIS musí být vybaven schopností upozorňovat na zadavatelem
zvolené informace o pacientovi – systémem alertů.
Alert a jeho kategorie musí být definovatelné dle zadání
zadavatele; úprava položek je podmíněna p idělením konkrétních
p ístupových práv. Alert má svou složku ve ejnou a složku
skrytou.
1. Do ve ejné části alertu, která může být zprost edkována

nap . vyskakovacím dialogovým oknem, poznámkou
v dolním okraji okna, pat í zejména:

21
● upozornění hygienického a protiepidemického P Vyberte
charakteru; editace je omezena na oddělení nemocniční P Vyberte
hygieny, P Vyberte
P Vyberte
● upozornění na osobu se zdravotním postižením včetně D_IV Vyberte
informace o nezbytných zdravotnických prost edcích; u
osob hluchých, slepých nebo kombinace obojího i
informace o způsobu komunikace

● upozornění na dospělého pacienta s omezenou
svéprávností

● upozornění na existenci osobního p ání pacienta
s podstatným vlivem na rozsah poskytovaných
zdravotních služeb nebo p ístup k němu; pat í sem nap .
upozornění na d íve vyslovené p ání v souladu s platnou
legislativou, odmítnutí pacienta účastnit se na výuce;
editace bude pod ízena platnému nastavení p ístupových
práv.

● riziko dekubitu nebo pádu
2. Neve ejná část alertu se nesmí prvoplánově objevit jako

textová informace na obrazovce počítače, musí být ešena
nap . ikonami, specifickým zabarvením části obrazovky –
konkrétní nastavení vyplyne ze vzájemné debaty zadavatele
s uchazečem v rámci analytické fáze projektu; alert by měl
být schopen upozorňovat na následující skupiny či vlastnosti
pacientů (p íklady):
● osoby se sklonem ke slovní či fyzické agresivitě
● toxikomanie objektivně dokumentovaná (alkohol či jiné

omamné nebo psychotropní látky), další …

KIS_061 KIS umožňuje k pacientům p i azovat atributy, které upozorňují
zdravotníky na vybrané typy informací; funkce je dostupná nap íč
celým systémem a musí být nastavitelná. Atributy musí být
editovatelné zadavatelem a počítáme s možností jejich využití p i
správě fronty pacientů dle naléhavosti stavu v rámci triage.

KIS_062 KIS musí mít službu centrální a lokální recepce pro ízení toku
pacientů. Funkce recepce umožní i záznam časových parametrů
jednotlivých úseků poskytování zdravotní služby (tím je myšleno
čas registrace k ošet ení, čas prvního vstupu na pracoviště, čas
odeslání na komplementární vyšet ení, čas ukončení ošet ení
atp.).

KIS_063 KIS musí mít pokročilý plánovací nástroj, který umožní
zdravotnickému pracovišti nahlížet do plánovacích nástrojů
(kalendá ů) ostatních pracovišť nemocnice z důvodu tzv.
sdruženého objednávání pacientů - tím je myšleno mít možnost
z jednoho místa najednou pacientovi na stejný kalendá ní den
objednat v časové návaznosti více zdravotních služeb na různých
zdravotnických pracovištích.

KIS_064 KIS obsahuje funkci, která u konkrétního pacienta zobrazí nejen
historii zdravotních služeb včetně jejich výsledků, které byly
pacientovi na pracovištích zadavatele poskytnuty, ale zobrazí i
p ehled všech do budoucna naplánovaných zdravotních služeb
včetně seznamu pracovišť, dat a časů.

KIS_065 Plánovací nástroj umožňuje i kontakt s pacientem –

22
prost ednictvím Portálu pacienta lze požádat o p eklad/zrušení
naplánované návštěvy.

KIS_066 KIS musí mít dispenzarizační nástroj, který umožní plánovat
pravidelné kontroly pacienta, upozorňovat na nedostavení se
pacienta k plánované kontrole, vyhledávat pomocí nástroje P Vyberte
skupiny pacientů se společnými znaky. Jako p íklad lze uvést
sledování těhotných žen v poradně.

KIS_067 KIS v sobě obsahuje podporu procesu tvorby a odesílání
žádanek. KIS prost ednictvím integrační vrstvy zajistí p ístup
k vystavování všech relevantních žádanek – o zdravotní služby
uvnit nemocnice i u externích poskytovatelů, komplementární
vyšet ovací metody, sanitní dopravu, logistiku léčivých p ípravků, P Vyberte
zdravotnických prost edků atp. KIS importuje uzav ené výsledky
parametrické nebo textové z vyžádaných vyšet ení nebo jiných
zdravotních služeb a nabízí je pro editaci zpráv z ambulantních
vyšet ení i hospitalizace. Viz podrobněji v kapitolách 2.2 a 2.3.

KIS_068 KIS umí zobrazovat číselné hodnoty ve formě tabulek, ale i
grafických trendů. KIS obsahuje nástroj, který zdravotníkům
umožní výběr sledovaných parametrů a nastavení časového P Vyberte
intervalu, ze kterého mají být hodnoty zobrazeny. Oba výstupy je
možné exportovat jako objekty do souboru.

KIS_069 KIS umožňuje sledování čekacích a objednacích dob, včetně
časových lhůt poskytování zdravotních služeb a tím podporuje
jejich ízení (nap . doba od indikace k operaci do doby jejího
poskytnutí, doba od skutečného propuštění pacienta do vystavení P Vyberte

definitivní závěrečné zprávy nebo zprávy z ambulantního
vyšet ení).

KIS_070 KIS musí umět vést agendu objednacích knih
k hospitalizacím, výkonům a operacím. Objednací knihy jsou
zp ístupněny vrcholovému vedení nemocnice k provádění P Vyberte
kontrolní a ídící činnosti. Zápisy do objednacích knih jsou
logovány.

KIS_071 KIS vede v rámci ešení procesů pro operační sály a výkonová P Vyberte
pracoviště statistiky jejich využití, zejména časové údaje, typy
operací, jmenovitě operační či výkonové týmy a anestézii.

KIS_072 Nový KIS kompletně podporuje agendy spojené s úmrtím
pacienta. Systém z ambulantní i lůžkové části umožní zadat údaj
o úmrtí pacienta, a to minimálně datum úmrtí; údaj je logován – tj.
zpětně zjistitelný, který uživatel a kdy údaj o úmrtí zadal. Datum
úmrtí pacienta zadané do KIS se objeví v Master Patient Indexu a
automaticky se nabídne pro výpočet délky uložení samostatných
složek zdravotnické dokumentace zadavatele všude tam, kde je P Vyberte
to v souladu s legislativou relevantní. KIS má v sobě
zabudovanou podporu pro vyplnění Listu o prohlídce zem elého
(LOPZ) v souladu s platnou legislativou; léka em se
specializovanou způsobilostí (omezení p ístupových práv)
vyplněný LOPZ umožní vytisknout v pot ebném počtu kopií
v souladu s vyhláškou.

KIS_073 Pokud budou u zem elého pacienta existovat budoucí
objednávky zdravotních služeb uvnit KIS, na všech
zdravotnických pracovištích u všech těchto objednávek se P Vyberte
zobrazí alert s informací o úmrtí nejpozději v okamžik, kdy
oprávněná osoba zahájí nějakou činnost s pacientovými

23
záznamy. P Vyberte
KIS_074 KIS v sobě obsahuje nástroje pro vykázání poskytnutých
D_II Vyberte
zdravotních služeb, spot ebovaných léčivých p ípravků a D_II Vyberte
zdravotnických prost edků; údaje poskytuje ekonomickému úseku D_II Vyberte
pro vyúčtování vůči plátcům péče, ale i do systémů Vyberte
manažerského ízení nemocnice. Nástroje pro vykázání péče P Vyberte
v sobě obsahuje i prvotní kontrolní mechanismy podporující D_II Vyberte
procesní ízení vykazování péče p ímo na místě vzniku – na
zdravotnickém pracovišti; jeho podrobná specifikace je P Vyberte
v samostatné kapitole.
KIS_075 KIS je integrován s lékárenským SW nemocnice, umožňuje ízení P
nabídky léčivých p ípravků podle pozitivního listu stanoveného
vedením FN, dostupností léčivých p ípravků, zobrazením cen a
doplatků pro pacienta. KIS pro účely ízení nemocnice poskytuje
preskripční statistiky. Podobně funguje i pro p edepisování a
výdej zdravotnických prost edků.
KIS_076 KIS musí podporovat bezpečný vzdálený p ístup prost ednictvím
internetu prost ednictvím počítačů, tabletů nebo chytrých
mobilních telefonů, a to bez ohledu na jejich operační systém.
Zadavatel očekává zejména p ístup k manažerským informacím
a výsledkům databázových dotazů, dále pak k informacím o
kapacitách v ambulancích a na lůžkách a jejich vytížení.
KIS_077 KIS sám o sobě, nebo po integraci s jinými SW podporuje
vyvolávací systémy a upozorňuje na plánované návštěvy
pacienta (vyvolávací systémy v čekárnách, portál pacienta
vzdáleným p ístupem).
KIS_078 KIS umožňuje využití čteček čárových anebo QR kódů ke
snímání informací z léčivých p ípravků i zdravotnických
prost edků; v p ípadě pot eby umožňuje p enést načtené
informace do konkrétních polí zdravotnické dokumentace
pacienta (nap . snímání informací o zdravotnických prost edcích
t ídy IIb nebo III, informací z vaků p ipravených roztoků cytostatik
nebo transfuzních p ípravků).
KIS_079 KIS bude umožnovat vedení skladového hospodá ství
jednotlivých st edisek minimálně s možností automatického
hlídání množství, expirace včetně vystavení žádanky na lékárnu
FN HK.
KIS_080 KIS obsahuje kontextovou nápovědu alespoň u ovládacích prvků,
jejichž funkce není specifikována slovem nebo skupinou slov.
KIS_081 Pokud některý z dodaných systémů (mimo systémů, kde se
p edpokládá práce pouze administrátorů z ad pracovníků
výpočetního st ediska zadavatele) umožňuje uživateli provádět
nastavení vzhledu a funkčnosti (p idávat a odebírat sloupce do
seznamů - nap . seznamu pacientů v ambulanci, seznamu
hospitalizovaných na lůžkovém oddělení; definovat a zapínat filtry
apod.) a systém toto nastavení uchovává i po znovuspuštění,
jsou požadovány následující funkčnosti:

· Možnost provést reset nastavení do výchozí podoby
samotným uživatelem (nikoliv pouze administrátorem).

· Možnost hromadně (tj. pro všechny nebo zvolenou
skupinu uživatelů najednou) změnit výchozí nastavení
(pouze pro oprávněné uživatele).

· Možnost hromadně resetovat nastavení všem uživatelům

24
(pouze pro oprávněné uživatele).
· Možnost individualizovaného nastavení omezit nebo

zakázat p ístupovým právem.
· Možnost hromadně měnit nastavení uživatelům bez

nutnosti resetu do výchozího nastavení.

KIS_082 Snadná konfigurace pracovního prostoru rozdělena na D_II Vyberte
systémovou/uživatelskou, která umožní minimálně změnu
formulá ů, pohledů, filtrů, datových polí a p idávání nových D_II Vyberte
objektů.
D_II Vyberte
KIS_083 Rychlost odezvy uživatelského prost edí (GUI) p i běžné práci D_II Vyberte
pod 1,5 sekundy minimálně v rozsahu: D_IV Vyberte
· zobrazení libovolného uživatelského okna
· uložení dat libovolného uživatelského okna
Konfigurace referenční pracovní stanice pro všechny testy
odezev:
HW: Procesor Intel Pentium G4600 3.6 GHz 3MB cache; RAM
8GB; 500 GB SATA 7.2k
rpm; LAN 1Gb; grafická karta integrovaná Intel HD
OS: Windows 10 pro 64bit Způsob p ipojení klávesnice a myši
bude prost ednictvím USB portu 2.0.
Rychlost síťového rozhraní je 1Gb.

KIS_084 Odezva prezentovaného systému na stisk kláves a operace
s myší bude do 300 milisekund.

KIS_085 Sestavení tisku zdravotnické dokumentace do 5 sekund.
Požadovaný rozsah sestavy určené k tisku: ambulantní zpráva
včetně všech právně požadovaných informací minimálně v
rozsahu dvou normostran.

KIS_086 KIS bude podporovat založení hlášení o vzniku nové mimo ádné
události, bude-li hlášení dokončeno a hlásící osobou uzav eno,
KIS pomocí alertu upozorní odbor ízení kontroly a kvality.

2.1.1.1 Podpora klinických studií/hodnocení prost ednictvím KIS

KIS_087 Kromě obecného uživatelského dotazu a specializovaných dotazů
do databáze KIS systém dále poskytuje následující podporu pro
vědecko-výzkumné aktivity typu klinických studií, klinických D_IV Vyberte
hodnocení. D_IV Vyberte
D_IV Vyberte
KIS_088 KIS v sobě udržuje databázi spravovanou pově enými osobami
s p íslušnými p ístupovými právy (nap . zástupci právního odboru,
pracovníci referátu klinických hodnocení). Tito pracovníci mají
oprávnění udržovat číselník aktuálně probíhajících klinických
studií/hodnocení. Číselník má vzhled formulá e s parametrickým
seznamem, který obsahuje minimálně následující údaje:

· název klinické studie/hodnocení zkratkou – parametrický
údaj

· plný název klinické studie/hodnocení – okno volného textu
· hlavní zkoušející – parametrický údaj osoby, která nese

odpovědnost za výzkumný úkol na pracovištích
zadavatele, kontrola oproti oficiálnímu seznamu
zaměstnanců FN HK

KIS_089 KIS v okně konkrétního pacienta poskytne parametrická okna pro

25
označení:
· data, kdy pacient udělil informovaný souhlas s účastí v
klinické studii/hodnocení; je-li okno vyplněné a není-li
současně vyplněn datum ukončení pacienta v klinické
studii/hodnocení, KIS blokuje za azení pacienta do jiné
klinické studie/hodnocení,
· názvu projektu zkratkou – léka , který pacienta za adil do
klinické studie/hodnocení, vybere p íslušnou zkratku ze
seznamu aktivních klinických studií/hodnocení,
· pracoviště hlavního zkoušejícího telefonický kontakt a
mailový kontakt na hlavního zkoušejícího,
· telefonický kontakt a mailový kontakt na koordinátora
studie a/nebo spoluzkoušejícího léka e,
· pole pro zápis data ukončení účasti pacienta v klinické
studii/hodnocení.

KIS_090 Je-li pacient za azen do klinické studie/hodnocení, je v okně
pacienta v KIS zobrazen grafický alert informující o účasti; alert je
ešen tak, aby léka pracující se zdravotnickou dokumentací D_IV Vyberte
pacienta nemusel nic potvrzovat (je jen zobrazen) a p i jeho
zvolení se otev e formulá s detailní informací o klinické
studii/hodnocení, a výzvou, ke kontaktování uvedeného
zkoušejícího léka e.
Jakmile je pacient za azen do klinické studie/hodnocení,
samostatná součást zdravotnické dokumentace po izovaná po
dobu za azení pacienta do klinické studie/hodnocení získá
skartační znak V a doba uchování zdravotnické dokumentace
bude alespoň 15 let, pokud smlouva se zadavatelem klinické
studie/hodnocení nebo aktuálně platná legislativa nebude
vyžadovat ještě delší dobu uchování; zadavatel může tuto dobu
uchování v čase editovat v souladu se změnami v právní úpravě.

2.1.2 Číselníky
2.1.2.1 Obecné vlastnosti

KIS_091 KIS musí disponovat agendou nahrávání a údržby celostátních P Vyberte
číselníků, a to včetně historie a nastavení platností. D_II Vyberte
Vyberte
KIS_092 Celostátně platné číselníky budou spravovány dodavatelem. To P Vyberte
znamená aktualizaci struktur číselníků, tak aby odpovídaly aktuálně P Vyberte
platným formátům číselníků, včetně možnosti jejich automatického D_II
importu a aktualizačních nástrojů. Zadavatel bude odpovídat pouze
za obsah číselníků, které prokazatelně sám modifikoval.

KIS_093 KIS musí umožnit zadávaní platnosti od-do až u jednotlivých
položek, zachování historie a zapisování poznámek k jednotlivým
verzím.

KIS_094 Nastavení platnosti jednotlivých položek číselníků musí být možné
na plátce, IČP, nejnižší organizační jednotku, odbornost, položku.
Jedná se nap . o číselníky bodových hodnot, nasmlouvaných
výkonů, kombinace výkonů, frekvence výkonů apod.

KIS_095 KIS musí umožnovat tvorbu vlastních doplňkových číselníků,
editovatelných zadavatelem pro speciální položky. U těchto
číselníků bude možné nastavit platnost.

26
KIS_096 KIS musí umožnit nahrávání číselníků co nejvíce automatizovaně P Vyberte
včetně možnosti nastavení, které číselníky se nahrávají ručně a
které automaticky. Funkce bude dostupná také oprávněným P Vyberte
uživatelům zadavatele. D_II Vyberte

KIS_097 Číselníky musí být ve výchozím stavu pro běžného uživatele P Vyberte
uzav ené a bez možnosti provádění změn, nebo dle nastavení P Vyberte
oprávnění KIS.

KIS_098 Na administrátorské úrovni musí být kromě úpravy možné tyto
číselníky nahradit vlastními zmodifikovanými číselníky.

KIS_099 Systém musí umožnit aplikačnímu administrátorovi spravovat
jednotlivé číselníky.

KIS_100 KIS musí mít možnost práce se zúženým seznamem pro vybraná
pracoviště. Podmínky výběru bude možné nadefinovat uživatelsky
dle oprávnění systému.

2.1.2.2 Organizační struktura

KIS_101 KIS musí obsahovat číselník pro organizační strukturu zadavatele P Vyberte
včetně možnosti definování vícero pohledů (nap . léka ský, P Vyberte
ekonomický, personální) a vzájemných vazeb mezi pohledy. D_II Vyberte

KIS_102 KIS musí obsahovat minimálně pětiúrovňovou hierarchickou
strukturu (tzn. 5 pozic kódu).

KIS_103 Číselník organizační struktury musí mít vazbu na číselník
fyzického umístění jednotlivých pracovišť zadavatele a možnost
zadání dalších údajů o organizační jednotce.

2.1.2.3 Číselník fyzického umístění pracovišť

KIS_104 KIS musí obsahovat číselník pro evidenci fyzického umístění P Vyberte
pracovišť v hierarchické struktu e nap . budova, část budovy,
pracoviště atd.

2.1.2.4 Registr pacientů

KIS_105 Informační systém musí obsahovat optimálně v rámci KIS centrální P Vyberte
registr pacientů (tzv. master pacient index, MPI). MPI umožní D_II Vyberte
p edevším sjednocení správy identit pacientů v ostatních
integrovaných informačních systémech zadavatele, pokud
dodavatel nedodá samostatné IT ešení centrálního registru
pacientů nad integrační platformou včetně jeho integrace s KIS,
tzn. zadavatel p ipouští obě ešení. Popis integrací je popsán
v „4 Minimální požadavky na integrační platformu včetně zhotovení
komunikačních vazeb s vyjmenovanými systémy“.

KIS_106 Dodané ešení musí podporovat minimálně jednosměrnou
synchronizaci změn v registru pacientů z KIS, nebo samostatného
IT ešení MPI nad integrační platformou se všemi ostatními
spolupracujícími systémy, ke kterým pat í nap íklad PACS, LIS,

27
Patologie atd., popis požadavků na integraci je uveden D_II Vyberte
v 4 Minimální požadavky na integrační platformu včetně zhotovení
komunikačních vazeb s vyjmenovanými systémy. P Vyberte

KIS_107 Dodané ešení provede automatické založení pacienta v KIS v D_II Vyberte
p ípadech, kdy není rodné číslo (pop ípadě číslo pojištěnce) v KIS, P Vyberte
ale v jiných systémech ano. Pak se do KIS nahrávají jeho data – P Vyberte
nap . Kdávky z LIS, patologie atd.

KIS_108 KIS musí v rámci MPI obsahovat (kompletní sadu informací
používanou ve statistických formulá ích pro ÚZIS a další položky),
minimálně však tyto údaje:
· p íjmení a jméno/jména pacienta
· rodné p íjmení pacienta
· rodné číslo (náhradní rodné číslo) anebo AIFO (anonymní
identifikátor fyzické osoby) podle zásad eGovernmentu ČR
nebo obojí
· číslo pojištěnce
· kód zdravotní pojišťovny; součástí záznamů je i historie
zdravotního pojištění pacienta v čase
· pohlaví
· e-mailovou adresu
· prostor pro min. dvě telefonní čísla pacienta
· adresu trvalého bydliště včetně kódu obce v souladu s
požadavky ÚZIS
· prostor pro další dvě adresy, z toho jedna doručovací
adresa
· rodinný stav
· pole pro p íjmení a jméno zvolené osoby blízké (manžela,
registrovaného partnera, otce, matky, jiné osoby blízké)
anebo opatrovníka
· telefonické spojení na osobu blízkou nebo opatrovníka – 2
kontakty
· e-mail na osobu blízkou nebo opatrovníka
· adresu osoby blízké nebo opatrovníka
· adresu zaměstnavatele
· údaj o dočasné pracovní neschopnosti (DPN) s možností
vyznačit, že se jedná o osobu v evidenci Ú adu práce (ÚP)
· ostatní statistické údaje používané ve formulá ích vůči
ÚZIS (kód dosaženého vzdělání, kód typu zaměstnání, …)
· parametrická pole pro: jméno registrujícího praktického
léka e, adresu/místo ordinace, telefon, e mail, další
poznámky
· parametrická pole pro: jméno registrujícího gynekologa u
žen, adresu/místo ordinace, telefon, e mail, další
poznámky; nabízí se jen u pacientek
· číselníky PSČ obcí a krajů
· možnost p i azení fotografie

KIS_109 KIS bude schopen spolupracovat s národními výpočetními systémy
tak, aby byl schopen zpracovávat agendy pot ebné pro
eNeschopenku v souladu s platnou právní úpravou.

KIS_110 KIS bude disponovat funkcí pro znemožnění zadání pacientů se
stejným rodným číslem a zároveň stejným číslem pojištěnce
ve ejného zdravotního pojištění.

KIS_111 KIS musí umožnit on-line validaci dat z centrálního registru VZP -
B2B.

28
KIS_112 KIS bude disponovat kontrolami rodného čísla pop ípadě čísla P Vyberte
pojištěnce minimálně v těchto p ípadech: P Vyberte
· správnost P Vyberte
· duplicita
· možnost stornování (zneplatnění), sloučení duplicit – P Vyberte
veškeré akce se budou zapisovat do logu – kdy, kdo a co
N Vyberte
KIS_113 KIS musí mít možnost opravy registru pacientů minimálně v úrovni: P Vyberte
· oprava D_II Vyberte
· storno D_II Vyberte
· zneplatnění P Vyberte
· sloučení

KIS_114 KIS musí disponovat aparátem, který zajistí opravu na správné RČ
(číslo pojištěnce) nebo AIFO (bude-li legislativně umožněno) v celé
aktuální dokumentaci pacienta.

KIS_115 KIS umožňuje pro účely poskytování zdravotních služeb pacientovi
neznámé totožnosti, novorozenců, cizích státních p íslušníků, osob
bez zdravotného pojištění automaticky vygenerovat náhradní
identifikátor (nap . číslo pojištěnce či rodné číslo), pod kterým bude
pacient identifikován v rámci poskytovatele až do okamžiku zjištění
skutečné totožnosti a skutečných identifikačních údajů pot ebných
pro poskytování a úhradu poskytnutých zdravotních služeb.
Jakmile dojde k opravě identifikačních údajů na ty skutečné, KIS
tyto nové údaje p i adí ke všem částem zdravotnické dokumentace
a všem statistickým a ekonomickým výkazům, které byly po ízeny
do doby zjištění skutečné identity pacienta; p i takové operaci musí
být plně zachována kompletní historie dokumentů, nesmí dojít ke
ztrátě původního náhradního rodného čísla či jiného zvoleného
identifikátoru a nesmí dojít ke ztrátě žádného z dokumentů, které
byly u pacienta po ízeny. KIS vytvo í finální výkazy zdravotní péče
a finální verzi všech dosud po ízených částí zdravotnické
dokumentace se skutečnými identifikátory pacienta; takto
zaktualizovanou dokumentaci pak umožní vyhledávat v databázi
pod skutečnými identifikátory pacienta spolu s jeho p edešlou i
návaznou dokumentací, pokud taková existuje. Zadavatel
p ipouští, že se skutečné rodné číslo pacienta někdy nepoda í
zjistit, pak zůstávají veškeré po ízené informace v informačních
systémech vedeny pod náhradním rodným číslem/identifikátorem.

KIS_116 KIS bude obsahovat aparát pro automatizovanou opravu rodného
čísla novorozenců na základě nahraných podkladů z matriky
(soubor ve formátu CSV).

KIS_117 KIS musí mít možnost u generovaného rodného čísla povolit
opravu během, nebo až po ukončení hospitalizace v nemocnici
nebo v průběhu ambulantního poskytování zdravotních služeb.

KIS_118 KIS umožní práci s AIFO v souladu s eIDAS a právní úpravou
upravující eGovernment v ČR v p ípadě dostupného rozhraní do
doby akceptace díla.

KIS_119 KIS umožní práci s anonymními pacienty (nap . utajovaný porod).

KIS_120 Osobní údaje pacientů se mohou v čase měnit a historii změn MPI
uchovává. U uzav ené zdravotnické dokumentace musí KIS p i
jejím zobrazení, tisku či p edání v elektronické formě zachovat
stejné osobní údaje pacienta, které byly platné v okamžiku
vytvo ení této zdravotnické dokumentace, p estože mezi po ízením
a novými transakcemi s dokumentací mohlo dojít k jejich změně;

29
taková změna osobních údajů nesmí vést k rozdělení nebo ztrátě P Vyberte
informací po ízených o pacientovi do informačního systému P Vyberte
dodaného v rámci ve ejné zakázky (jinými slovy – historie P Vyberte
zdravotních služeb v KIS musí zůstat kompletní). P Vyberte
KIS_121 KIS musí disponovat funkcí pro snadné vyhledávání v registru D_II Vyberte
pacientů podle osobních údajů, pojišťovny, RČ, čísla pojištěnce,
ale i částí těchto údajů.
KIS_122 KIS umožní zobrazení historie pojištění včetně možné aktualizace
uživatelem dle p ístupových práv a nastavení auditu systému.
KIS_123 KIS umožní zobrazení historie adres a kontaktů souběhu pojištění
dle p ístupových práv a nastavení auditu systému.
KIS_124 KIS musí mít možnost importu ově eného registru, který se bude
nahrávat v měsíčních intervalech bez historie a bude pouze pro
čtení. Veškeré úpravy budou možné dle p ístupových práv pouze
v Centrálním registru pacientů FNHK.
KIS_125 KIS bude mít možnost porovnání Centrálního registru VZP
s Registrem FNHK.

2.1.2.5 Informované souhlasy

KIS_126 KIS umožní práci s informacemi o udělení informovaných souhlasů
pacientů včetně rozhodnutí pacienta o sdělování informací o svém
zdravotním stavu, o existenci „d íve vyslovených p ání pacienta“ D_II Vyberte
v souladu se zákonem, rozhodnutí nepodávat informace o D_II Vyberte
zdravotním stavu, o neochotě být vyšet ován studenty zdravotních
škol apod. Zadavatel tímto požadavkem reaguje na avizované
legislativní změny s posílením vážnosti p ání pacienta a
závaznosti pro zdravotníky taková p ání respektovat. Agenda
informovaných souhlasů dle zákona 372/2011 Sb

· uchazeč navrhne vlastní ešení tohoto legislativního
požadavku:

· Součástí práce s tímto registrem musí být vytvá ení a
evidence veškerých dokumentů vyplývajících ze zákona
372/2011 Sb. o zdravotních službách a podmínkách jejich
poskytování (zákon o zdravotních službách) v platném
znění.

· Jednotlivé formulá e musí být v souladu s vnit ní směrnicí
FNHK SM_65 o zdravotnické dokumentaci. Zadavatel na
vyžádání pošle uchazeči vzory jednotlivých formulá ů.

· Zadavatel rovněž požaduje jednoduchý pohled na všechny
vystavené informované souhlasy daného pacienta nap .
formou skenů podepsaných informovaných souhlasů
pacienta ve formátu PDF/A.

· Budou vytvo eny šablony v různých jazykových mutacích
– angličtina, němčina, ruština, polština, ukrajinština,
francouzština, španělština a vietnamština.

KIS_127 KIS podporuje správu informovaných souhlasů pro jednotlivá
pracoviště včetně p ípadného tisku. Správu elektronických
dokumentů informovaných souhlasů smí provádět jen oprávněný
uživatel. KIS umožňuje záznam informace, že zvolený informovaný
souhlas byl od pacienta získán.

30
KIS_128 KIS umožňuje nastavit parametrizovatelné pohledy na informace o
zdravotním stavu pacienta. Tím je myšleno zaslepení informací, u
kterých pacient vyslovil nesouhlas s jejich p edáváním. Je tím P Vyberte
myšleno i nastavení zobrazování historie zdravotního stavu, které D_II Vyberte
může být vázáno na konkrétní odbornost, nebo naopak může
zobrazovat veškerou zdravotní problematiku (nap . pro pot eby
urgentního p íjmu).

KIS_129 KIS musí umožnovat p iložení souboru k agendě informovaných
souhlasů.

2.1.2.6 Čárový kód a RFID čipy

KIS_130 KIS musí umět pracovat s čárovými kódy (tisk na samolepící
štítky, recepty, žádanky, identifikační pásky pacientů, identifikace
p ístrojů apod.) a současně i s možností snímání těchto čárových P Vyberte
kódů. D_II Vyberte

KIS_131 KIS bude podporovat identifikaci pacientů „náramky“ – a to jak
náramky s čárovým kódem, tak s RFID čipem.

2.1.2.7 Registr zaměstnanců

KIS_132 KIS musí pot ebná data pro registr zaměstnanců čerpat
z aktuálního personálního systému zadavatele (v současné době
FNHK používá personální systém fy VEMA). Integrace a rozsah D_II Vyberte
p enášených dat je popsán v kapitole 4 Minimální požadavky na
integrační platformu včetně zhotovení komunikačních vazeb
s vyjmenovanými systémy

2.1.2.8 Registr poskytovatelů zdravotních služeb

KIS_133 KIS musí umožnovat import číselníku „Soubor platných IČP pro P Vyberte
poskytovatele vyžádané péče“ od VZP. P Vyberte
D_II Vyberte
KIS_134 KIS bude disponovat kontrolou během po izování dat na číselník
registru smluvních léka ů (nap . žadatel o péči, externí žádanka, D_IV Vyberte
atd.) VZP.

KIS_135 KIS bude umožnovat použití číselníku/registru, který bude v době
p edání díla funkční – pokud budou oba, tak preferujeme kontrolu
na registr zdravotnických pracovníků.

KIS_136 Dodané softwarové ešení umožní komunikaci s Národním
registrem poskytovatelů zdravotních služeb a alespoň v kategorii
léka , zubní léka a farmaceut i s Národním registrem zdravotníků;
oba registry jsou ze zákona provozovány ÚZIS, mají definované
datové rozhraní a je platné i Datové rozhraní VZP. Bude-li v době
ukončení projektu funkční IDRR na MZ ČR, zadavatel p ipouští
komunikaci s národními registry prost ednictvím IDRR.

2.1.2.9 Číselníky zdravotních pojišťoven a SÚKL

KIS_137 Systém musí umět automatizovaně bez zásahu administrátora D_II Vyberte
nahrávat a pracovat s číselníky:

31
· VZP,
· SÚKLu včetně otev ených dat (https://opendata.sukl.cz/).

KIS_138 KIS musí mít možnost vložení a práce s fiktivními pojišťovnami pro P Vyberte
ešení nestandardních pojištěnců.

2.1.2.10 Číselníky diagnóz

KIS_139 KIS musí umět pracovat s číselníky mezinárodní klasifikace P Vyberte
nemocí verze 10 (MKN-10) včetně importu dle rozhraní JDG4 v
aktuální verzi; zdrojem klasifikace je ÚZIS.

KIS_140 KIS musí uchovávat historii jednotlivých verzí MKN-10 v čase P Vyberte
ekvivalentně tomu, jak se děje i u kódů diagnóz, úhradových
parametrů léčivých p ípravků nebo zdravotnických prost edků.

KIS_141 KIS musí mít možnost p epsat v dokumentaci pacienta slovní P Vyberte
specifikaci diagnózy, aniž by došlo ke změně kódu diagnózy dle
MKN-10.

KIS_142 KIS musí mít kontrolu na kombinaci - hlavní, vedlejší diagnózy a
systém podvojné klasifikace MKN-10 (tzv. systém k ížek + -
hvězdička *) dle aktuálně platných metodických pravidel pro P Vyberte
kódování hlavní diagnózy a vedlejších diagnóz, publikovaných
ÚZIS.

KIS_143 KIS umožní v rámci dokumentace pacienta nabízet editovatelný N Vyberte
seznam kódů diagnóz podle MKN-10, které byly u pacienta již
použity, formou individuálního číselníku.

KIS_144 KIS nesmí do nově vytvá ené dokumentace pacienta automaticky
p enášet kódy MKN-10 z p edchozích ambulantních ošet ení nebo
hospitalizací. Zadavatel p ipouští, že KIS může d íve použité kódy P Vyberte

zobrazit a umožnit uživateli aktivně je vybrat.

KIS_145 V číselníku kódů diagnóz MKN-10 musí být umožněno
vyhledávání nástrojem pro vyhledání (tzv. našeptávačem) kdekoli
v KIS, kde je pole pro zadání diagnózy. Našeptávač kódů MKN-10
podporuje vyhledávání po zadání kombinace alfanumerických
znaků jak v parametrickém poli pro kód diagnózy, tak zápisem P Vyberte
textu diagnózy do p ipojeného textového pole. Našeptávač zobrazí
kódy diagnóz s p ipojenými texty do seznamu, ze kterého může
pracovník zvolit diagnózu kliknutím myši. P i zadávání kódů i textů
lze využít i zástupné znaky pro dotazy (nap . * hvězdička).

2.1.2.11 Interní číselníky

KIS_146 KIS bude disponovat dalšími číselníky minimálně v rozsahu: P Vyberte
· skórovací tabulky jako základní TISS D_II Vyberte
· diety

KIS_147 KIS bude disponovat dalšími číselníky minimálně v rozsahu:
· podrobnější členění nozokomiálních nákaz
· číselníky pro dekubity a pády
· číselníky typů ambulantních pacientů (nový, akutní,
dispenzarizace apod.)
· číselníky atributů pacienta s globálním dopadem na péči
(alergik, diabetik, imobilní, kolonizace multirezistentním
mikrobem - integrace na mikrobiologii apod.)

32
2.1.3 Národní registry a výkazy

KIS_148 Systém musí zajistit maximálně automatizovanou komunikaci a
p edávání dat na ÚZIS, resp. do relevantních registrů v rozsahu
požadavků daných legislativou, p ípadně zajistit export dat pro D_II Vyberte
ÚZIS. Konfigurace a nastavení komunikace musí být D_II Vyberte
realizovatelná zaškolenými pracovníky poskytovatele. Registry pro
p edávání dat jsou definovány zákonem č. 372/2011 Sb. v platném
znění, o zdravotních službách. Aktuálně se jedná o následující
registry:

· Národní onkologický registr (NOR)
· Národní registr hospitalizovaných (NRHOSP)
· Národní registr reprodukčního zdraví (NRRZ)
· Národní registr kardiovaskulárních operací a intervencí

(NRKOI)
· Národní registr kloubních náhrad (NRKN)
· Národní registr nemocí z povolání (NRNP)
· Národní registr léčby uživatelů drog (NRLUD)
· Národní registr úrazů (NRU)
· Národní registr osob trvale vyloučených z dárcovství krve

(NROVDK)
· Národní registr pitev a toxikologických vyšet ení

prováděných na oddělení soudního léka ství (NRPATV)
· List o prohlídce zem elého dle platných právních p edpisů
· Národní registr osob čekajících na transplantaci orgánů
· Informační systém tkáňových bank (Tissis)
· Integrovaný systém transplantačních registrů (Trinis)
· Národní registr zdravotnických pracovníků (NRZP)
· Národní registr poskytovatelů zdravotnických služeb
· Registr nežádoucích událostí
Vymezení rozsahu informací p edávaných poskytovateli
zdravotních služeb do Národních zdravotních registrů je p esně
stanoveno v datovém standardu Ministerstva zdravotnictví a
závazných metodických pokynech k NZIS. Uchazeč je povinen
udržovat aktuální rozhraní po celou dobu životnosti produktu na
pracovištích zadavatele.

KIS_149 Systém musí podporovat automatickou tvorbu vybraných výkazů
ÚZIS, nebo minimálně tvorbu podkladů pro dané výkazy. Jejich
výčet bude blíže specifikován v Prováděcím Projektu, minimálně
však v rozsahu poskytovaných zdravotních služeb. Popis
jednotlivých výkazů je dostupných na webu
https://www.uzis.cz/vykazy.

2.1.4 Statistické výstupy – reporting

KIS_150 KIS pro základní statistiky umožní tvorbu výstupů (reporting) z

informací uložených v DB prost edky běžného uživatele ve

stejném GUI jako KIS, a to podle libovolného údaje, kombinací

podmínek (použití více podmínek současně včetně vícenásobného P Vyberte
použití jednoho DB sloupce v rámci podmínky, slučování

podmínek pomocí operátorů AND a OR) a s využitím zástupných

znaků. KIS musí zprost edkovat p ístup k rutinním provozním

informacím v okamžiku pot eby.

33
KIS_151 Seznamy pacientů, které KIS na základě definovaných podmínek
reportingu vytvo í a zobrazí uživateli, musí umožňovat snadný
p ístup do zdravotnické dokumentace jednotlivých pacientů D_II Vyberte
za azených do odpovědi na dotaz; takový p ístup se děje P Vyberte
v rozsahu, který umožňují p ístupová práva uživatele.

KIS_152 Součástí dodaného KIS bude soubor výchozích reportů
dostupných běžnému uživateli, včetně možnosti zadání kritérií
vytvo ených dle požadavků zadavatele, kdy podrobná specifikace
bude součástí Prováděcího Projektu. V době podání p ihlášek do
ve ejné zakázky musí mít uchazeč alespoň jeden report v každé z
těchto oblastí:

· Vytížení operačních sálů
· P ehledy ambulantních pacientů včetně specifikace

diagnózy

· P ehledy o p edepsaných receptech, zdravotnických

prost edcích apod.

· P ehledy hospitalizací, doprovodů, včetně specifikace
diagnózy či výkonů

· P ehledy diet, ordinací léků
· P ehledy o poskytnuté a vykázané zdravotní péči nap .

výkonů, léků, atd.
· P ehledy podle segmentů péče v návaznosti na úhradovou

vyhlášku (hospitalizační a ambulantní segment,
individuální smluvní úhrada,…)

· P ehledy za oblast DRG

KIS_153 Součástí dodaného KIS bude soubor výchozích reportů
dostupných běžnému uživateli, včetně možnosti zadání kritérií
vytvo ených dle požadavků zadavatele, kdy podrobná specifikace D_II Vyberte
bude součástí Prováděcího Projektu minimálně však v rozsahu
těchto oblastí:

· Vytížení operačních sálů

· P ehledy ambulantních pacientů, v další specifikaci
minimálně pohledy p es: výkonové st edisko, vyšet ujícího
léka e, časové intervaly, vybrané diagnózy, výkony či
jejich kombinace, dispenzární skupiny,

· P ehledy o p edepsaných receptech, zdravotnických

prost edcích, vystavených žádankách na vyžádanou péči
uvnit nemocnice, ale i u externích poskytovatelů; v další
specifikaci minimálně pohledy p es: p edepisujícího
léka e, realizaci v lékárně zadavatele, časové intervaly
apod.,

· P ehledy hospitalizací, a to minimálně pohledy p es
výkonová st ediska, pracoviště zadavatele, hospitalizační
p ípady realizované na více pracovištích různých
odborností, konkrétní poskytnuté zdravotní služby či jejich
kombinace, diagnózy, léka e jmenovitě, s výskytem
hlášených mimo ádných událostí, nozokomiálních nákaz,

pobytu na lůžkách intenzivní péče apod.,

· P ehledy sledovaných ukazatelů kvality, zejména pak

34
celonomocničních ukazatelů kvality, včetně sledování
dekubitů a pádů pacientů,
· P ehledy diet,

· P ehledy ordinací léků, minimálně podle ATC skupin, léků
vázaných na centra se smluvní úhradou od zdravotních

pojišťoven,
· P ehledy, seznamy pacientů, a to minimálně statistiky dle

pohlaví, věku, ošet ovatelské kategorie, využití invazivních
vstupů apod.,
· P ehledy o poskytnuté a vykázané zdravotní péči,
· P ehledy podle segmentů péče v návaznosti na úhradovou
vyhlášku (hospitalizační a ambulantní segment,
individuální smluvní úhrada, pacienti samoplátci, pacienti

cizinci mimo systém zdravotního pojištění ČR apod.),
· P ehledy za oblast DRG, minimálně sledování výskytu

DRG markerů (a to v systému IR-DRG i CZ-DRG), podle
jednotlivých DRG bazí a DRG skupin, p ehledy postavené

na jednotlivých prvcích používaných ve vstupní větě
grouperu DRG,

· Odběrové listy, p ehledy vyšet ení, hromadné tisky
některých typů vyšet ení,

· P ehledy lůžek – minimálně historie pacienta, atributy u
jednotlivých lůžek a jejich změny v čase apod.,

· P ehledy za oblast léků s kódem S (individuální smluvní
úhrada) a evidence pacientů léčených v centrech.

KIS_154 Pro účely po izování pokročilejších statistických výstupů bude KIS

nebo jeho doprovodné SW nástroje disponovat dotazovacím

jazykem podle typu databázového stroje, nebo jiným dotazovacím

nástrojem pro tvorbu vlastních dotazů, dostupným pouze P Vyberte

oprávněným uživatelům.

Pro účely tvorby pokročilých reportů musí mít oprávněný uživatel

možnost vytvo it vlastní databázové objekty jako nap . VIEW či

dočasné tabulky. Uživatel bude moci využívat obecných SQL

p íkazů, nebo jiného dotazovacího aparátu/jazyka.

KIS_155 Statistické výstupy (reporty), ať už základní či pokročilé, musí být

možné směrovat na obrazovku, tiskárnu p ípadně do souboru, či

automaticky odeslat e-mailem jako p ílohu. V p ípadě výstupu do P Vyberte
souboru jsou požadovány minimálně formáty TXT, PDF, HTML,

XLS, vytvo ené p ímo v prost edí KIS bez nutnosti použít další

SW.

KIS_156 Jednotlivé definice statistických výstupů, ať už základních či

pokročilých, musí být možné uložit na úrovni uživatele, který je P Vyberte
vytvo il, pro účely opakovaného využití či sdílení s dalšími

oprávněnými uživateli.

KIS_157 Veškerá činnost uživatele v rámci statistických funkcí musí být

detailně logována, tzn. kdo, kdy a na jaké pracovní stanici dané P Vyberte

statistické operace prováděl, jaká kritéria, či jejich kombinaci

použil, p ípadně jaký dotaz sestavil, jak s výsledkem naložil (tzn.

pouze zobrazil na obrazovce, exportoval, odeslal - komu, či tiskl).

35
K výsledku dotazu uvést počet vrácených záznamů.
Záznamy z logů bude možné zobrazit na obrazovce, tisknout,
exportovat do souboru, nebo p esměrovat do externích systémů
pro správu logů.

KIS_158 Procesy užívající statistické funkce a vytvá ející výstupy, ať už
základní či pokročilé, budou disponovat plánovačem, který umožní
plánované vykonávání určených definic. Jednotlivé události budou D_II Vyberte
logovány: autor, datum vytvo ení, název, plán, co má být

prováděno, status (úspěch, neúspěch).

2.1.5 Tiskové sestavy

KIS_159 Veškeré tisky musí být v souladu s platnou právní úpravou,
zejména vyhláškou o zdravotnické dokumentaci. Konkrétní tvar
(hlavičky, číslování stránek apod.) bude up esněn v dokumentaci P Vyberte
Prováděcího projektu. P Vyberte

KIS_160 Dodavatel má vytvo eny tiskové šablony alespoň pro typy D_II Vyberte
dokumentů specifikované platnými právními p edpisy, zejména ve
vyhlášce o zdravotnické dokumentaci, dále pro dokumenty
specifikované ÚZIS v rámci plnění statistické povinnosti, dále
v aktuálně platné Metodice pro po izování a p edávání dokladů
VZP.

KIS_161 V rámci realizace projektu dodavatel podle požadavků zadavatele
upraví nebo vytvo í tiskové šablony pro tisk všech dokumentů
minimálně v rozsahu (p esná specifikace bude součástí
Prováděcího projektu) :

· Závěrečná zpráva,
· Prozatímní propouštěcí zpráva,
· První strana chorobopisu,
· Anamnéza, stav p i p ijetí, hlášení hospitalizace, hlášení

p íjmu a propuštění,
· Operační protokol,
· Anesteziologický záznam,
· Zpráva o rodičce (porodopis),
· Zpráva o novorozenci,
· Hlášení vrozené vývojové vady
· Ambulantní zpráva,
· Dotisk ambulantní zprávy,
· Recepty,
· Žádanky,
· Průvodka eReceptu,
· Tisky čárových kódů,
· List o prohlídce zem elého,
· Hlášení nozokomiálních nákaz,
· Neschopenka a eNeschopenka,
· Poukaz na léčebnou a ortopedickou pomůcku,
· Žádanka o zvýšenou úhradu,
· Skórovací tabulky,
· Šablony pro ošet ovatelskou dokumentaci,
· Hlášení novotvaru,
· Informované souhlasy,
· Samolepící štítky,
· Pooperační záznamy na stacioná ích,
· Monitorovací záznamy,

36
· Šablony pro propustky,
· Adresy na obálky,
· Šablony pro agendu samoplátců,
· Poplatky – p edpisy k úhradě,
· Ambulance – hlášení úrazu
· Sestavy k lůžkovému fondu včetně atributů

KIS_162 Dále musí KIS umožňovat tyto šablony editovat a doplňovat
možnosti tisku o další šablony. Tiskové šablony bude možné vázat
až na nejnižší organizační jednotku a skupinu uživatelů. Šablony P Vyberte
budou určovat strukturu, vzhled a části dokumentace určené k
tisku. V rámci tisku bude možné umístit na pozadí i obrázky, a to i P Vyberte
více obrázků v rámci jednoho tisku (nap . pro tisk formulá e, logo
do hlavičky apod.). Tyto úpravy musí být možné provádět P Vyberte
vyškolenými pracovníky zadavatele a jejich provádění a P Vyberte
zp ístupnění pro uživatele omezit p ístupovými právy. P Vyberte
P Vyberte
KIS_163 Součástí dodávky bude grafický návrhá tiskových sestav s P Vyberte
minimálně těmito entitami: P Vyberte
D_II Vyberte
· textové pole (možnost doplnit vlastní text),
· databázové pole (možnost vkládat údaje z databáze),
· vzorce (možnost definovat vlastní vzorce a výpočty),
· čárový kód (možnost vložit čárový kód odpovídající normě),
· logo firmy,
· obrázek (možnost vložit do sestavy libovolný rastrový

obrázek),
· graf (možnost vytvá et sestavy se sloupcovými, kruhovými a

čárovými grafy),
· čáry a rámečky,
· štítky (možnost vytvá et sestavy adresních či jiných štítků),
· uživatelské varianty sestav (možnost každou originální

sestavu upravit nebo ji rozmnožit),
· speciální sestavy (možnost vytvá et různé tiskové sestavy,

jako nap . tiskopisy apod.),
· možnost schovávání pole p i nevyplnění hodnoty, nebo na

základě jiné podmínky.

KIS_164 Primárně bude tiskový výstup KISu směrován na výchozí tiskárnu
operačního systému pracovní stanice. Uživatel však bude mít
možnost volby jiné tiskárny a úpravy parametrů tisku, tzn., že bude
moci:

· určit počet kopií
· definovat rozsah stran pro tisk
· zvolit jednostranný i oboustranný tisk
· definovat okraje stránky

KIS_165 KIS bude podporovat tisk samolepících štítků.

KIS_166 KIS bude umožňovat tisk tzv. do souboru. Výstupní formát bude
PDF/A.

KIS_167 Tisky budou grafické s plnou podporou češtiny a čárového kódu.

KIS_168 KIS bude mít možnost tisku do standardizovaných formulá ů dle
metodiky VZP nebo p ímý tisk vyplněného formulá e.

KIS_169 KIS bude mít možnost náhledu p ed tiskem.

KIS_170 KIS bude mít možnost dotisku zpráv. Jedná se o funkci tisku, kdy

37
na první straně nedojde k tisku hlavičky zprávy s identifikací
zdravotnického za ízení a pacienta a tisk začíná posunut od
horního okraje papíru o uživatelem udanou vzdálenost. Tuto
vzdálenost zadává uživatel bezprost edně p ed tiskem
v centimetrech/milimetrech.

KIS_171 KIS bude umožňovat tisk na různé formáty papíru resp. formulá ů P Vyberte
– standardní je A4.

2.1.6 Editor textů

KIS_172 Textový editor musí být vestavěnou součástí KIS; zadavatel P Vyberte
nep ipouští použití SW produktů t etích stran. P Vyberte
P Vyberte
KIS_173 Funkcionalita KIS umožní do dokumentů vložit výsledky vyšet ení, N
popisy nálezů a jiných dokumentů, a to na základě volby uživatele, P Vyberte
který si zvolí část a rozsah dokumentace nebo výsledků, které
chce p enést na vybrané místo upravovaného dokumentu. P Vyberte

KIS_174 Editace dokumentace bude probíhat v textovém editoru, který D_IV Vyberte
P Vyberte
umožní minimálně volit velikost písma, font písma, typ písma
(tučné, podtržené, kurzíva), barvu písma, formát odstavců, umožní
používat znak tabulátor.

KIS_175 Výhodou je možnost ovládání výchozími klávesovými zkratkami N af ormát ováno:
WINDOWS. přeškrtnuté

KIS_176 Funkcionalita KIS umožní p i editaci dokumentu zobrazit všechny
p edchozí dokumenty v rámci historie pacienta s možností filtrace
daného typu dokumentu. P i editaci zprávy určitého typu (nap .
ošet ovatelský p íjem – anamnéza) bude možné zobrazit všechny
p edchozí ošet ovatelské p íjmy pacienta.

KIS_177 Funkcionalita KIS umožní p iložit jakýkoliv soubor do dokumentace
pacienta s možností vazby na konkrétní dokument v rámci KIS.
Zároveň musí být pro uživatele možné zobrazit všechny klinické
události s p ílohou nebo všechny p ílohy u všech klinických
událostí zvoleného pacienta, pokud má ke zmíněným klinickým
událostem a/nebo p ílohám p ístupová práva. Funkcionalita KIS
zajistí omezení velikosti vkládaných souborů (tím je myšleno nap .
omezení formátu fotografie vyfocené ve formátu 4K na formát
FullHD). Soubor bude navázán na ten dokument, ke kterému byl
vložen - nap . ambulantní zpráva.

KIS_178 P i p ipojování obrázků nebo videa, které budou mít velikost větší,
než bude zadavatelem povoleno, systém musí umožnit redukci
velikosti (změna rozlišení minimálně ve t ech variantách kvality),
po jejím potvrzení se do KISu uloží redukovaný obrázek.

KIS_179 Uživatel bude moci vkládat a p enášet části textu pomocí schránky
operačního systému funkcí Kopírovat-Vložit. P i p enosu dojde k
zachování takového formátování, které je podporováno v KIS.

2.1.7 Přístupová práva

KIS_180 KIS musí být propojen na systém správy uživatelů zadavatele a P Vyberte

38
musí provádět autentizaci uživatelů vůči této externí autoritě. KIS
bude umět autentifikovat uživatele minimálně některým z těchto
způsobů:

· MS Active Directory nebo Network Information Service
(d íve HP UNIX Yellow Pages)

· Single Sign On
· Prost ednictvím certifikátu uloženého na QSCD prost edku.

KIS_181 Funkcionalita KIS umožní napojení na systém centrální správy D_II Vyberte
uživatelských účtů a ízení p ístupu prost ednictvím IDM - identity
management. P Vyberte

KIS_182 KIS musí umožnit zadat a dále pracovat minimálně s následujícími P Vyberte
charakteristikami oprávněné osoby – zaměstnance: P Vyberte
P Vyberte
· p íslušnost k pracovišti ve smyslu výkonových st edisek P Vyberte
nebo jiných pracovišť v souladu s organizační strukturou P Vyberte
zadavatele (nap . oddělení výpočetních systémů – oddělení
systémové péče, editelství – vrcholový management,
chirurgická klinika, ale t eba i jen specializované pracoviště
uvnit kliniky – laborato intervenční kardiologie na I. interní
kardioangiologické klinice),

· profesi (nap . léka , ekonom, zdravotní laborant),
· oprávnění k výkonu profese z pohledu vzdělání anebo

stanovených kompetencí (nap . pracovník pracující pod
dohledem, samostatně pracující pracovník, vedoucí
pracovník, specialista pro stanovenou konkrétní činnost,
oprávnění tzv. superuživatele systému),
· oprávnění k výkonu služby mimo ádnou pracovní dobu,
· oprávnění k práci v rizikovém prost edí stanoveném
orgánem ochrany ve ejného zdraví.
Jednotlivé charakteristiky se mohou vzájemně kombinovat a tím
vytvo í jedinečné individuální oprávnění zaměstnance k p ístupu
k jednotlivým funkcím a částem KIS.

KIS_183 KIS umožní hierarchicky strukturované nastavení p ístupových práv
se stanovením rozsahu p ístupu i stupně oprávnění manipulace se
záznamem (čtení / nový záznam / úprava / rušení záznamu).
Princip nastavování p ístupových práv jednotlivým uživatelům musí
vycházet z definice libovolného množství uživatelských rolí, do
kterých jsou samotní uživatelé p i azování, ale kromě rolí musí
umožňovat i individuální úpravy rozsahu p ístupových práv pro
konkrétní osobu.

KIS_184 KIS musí umožnovat nastavení p ístupových práv včetně nastavení
datumového omezení platnosti role, uživatele, skupiny, individua.

KIS_185 KIS musí disponovat funkcionalitou automatického sčítání
oprávnění vyplývající ze všech rolí p i azených konkrétnímu
uživateli a pracovat tak, jako by uživatel disponoval pouze jednou
rolí obsahující všechna oprávněními všech jeho rolí dohromady.

KIS_186 KIS musí umožnit omezení p ístupu pouze na pacienty vybraného
pracoviště nebo na konkrétní typ dokumentace. Neomezené
nahlížení na veškeré pacienty ošet ované na pracovištích
zadavatele je možné jen po p idělení exkluzivních p ístupových
práv.

KIS_187 KIS musí mít možnost pro uživatele s p íslušným oprávněním
označit dokumentaci pacienta za skrytou a individuálně nastavit její
p ístupnost uvnit systému. Tím dojde k znemožnění p ístupu k této
dokumentaci všem uživatelům, kte í taková individuálně nastavená

39
kritéria nebudou splňovat.

KIS_188 Systém umožní definování oprávnění až na položku formulá e. P Vyberte
Vyberte
KIS_189 KIS bude disponovat možnosti automatického odhlášení nečinného
uživatele včetně nastavení délky časového intervalu. Ve
výjimečných p ípadech může oprávněná osoba (administrátor) P

automatické odhlášení konkrétního uživatele zcela vypnout.

2.1.8 Logování a auditní služby

KIS_190 ešení umožní logování veškerých kroků a operací uživatelů (kdo, P Vyberte
co, kdy, kam). Tyto logy musí být zabezpečeny proti změnám. P Vyberte

KIS_191 V systému bude evidována jednoznačná identifikace kdo, odkud, P Vyberte
kdy, nad kterými daty provedl jakou činnost v systému. Systém P Vyberte
bude podporovat kompletní historizaci dat (v p ípadě dat v D_II Vyberte
databázi je nutná kompletní historizace včetně služebních P Vyberte
záznamů, v p ípadě dokumentů a objektů mimo databázi je nutné P Vyberte
alespoň logovat tuto interakci ze strany KISu v maximálním
možném rozsahu).

KIS_192 Všechny součástí KIS (DB, IS, klientské aplikace) musí logovat
svou činnost do logů s možnosti nastavit úroveň logování pro
pot eby diagnostiky.

KIS_193 Systém musí umožnit automatizovaný i manuální export logových
záznamů do externích systémů pro správu logů (nap . log
management, SIEM) a v p ípadě výstupu do souboru umožní
uložení minimálně ve formátu CSV.

KIS_194 ešení umožní poskytovat auditní reporty o p ístupech uživatelů
na základě parametrizace prováděné pově eným auditorem.

KIS_195 Auditní systém musí být 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ů.

KIS_196 Auditní systém bude v souladu se zákonem č. 181/2014 Sb.
(zákon o kybernetické bezpečnosti) v platném znění a vyhlášky
82/2018 Sb. (vyhláška o kybernetické bezpečnosti) v platném
znění a navazujícími právními p edpisy.

2.2 Požadavky na klinické subsystémy

2.2.1 Lůžkový fond

KIS_197 KIS obsahuje funkcionalitu na správu fyzického fondu lůžek na
pracovištích zadavatele. Umožňuje zadavateli zadat lůžko na
pokoj pracoviště dle organizační struktury. Oprávněným
pracovníkům umožní editovat fyzickou strukturu jednotlivých
pracovišť ve smyslu uvedení počtu pokojů a rozmístění P Vyberte
stanoveného počtu lůžek v nich. Každé jednotlivé lůžko je tedy
v KIS unikátně identifikováno tak, aby na něj bylo možné umístit
pacienta. Oprávněné osoby jsou schopné fyzickou strukturu
průběžně upravovat.

40
KIS_198 KIS umožňuje zadavateli charakterizovat typy lůžek, a to podle
pot eb statistických a úhradových (nap . lůžka akutní lůžkové péče
standardní, lůžka akutní lůžkové péče intenzivní, lůžka následné P Vyberte
péče standardní, lůžka pro doprovody pacientů, lůžka p istýlková). P Vyberte
Tyto typy se uplatňují p i vytvá ení sestav v rámci reportů. P Vyberte
D_II Vyberte
KIS_199 KIS musí disponovat administraci lůžkových kapacit pro
oprávněné pracovníky zadavatele. Ti mohou ídit jejich plánované P Vyberte
otevírání, uzavírání nap . v době plánovaných dovolených,
stavebních akcí na oddělení, změnách rozsahu smluvních
ujednání s plátci péče. Takové ízení reálné lůžkové kapacity je
nutné promítnout do statistik, p ekladů v rámci reportingu.

KIS_200 KIS musí umožnovat zpracování sestavy pro počty lůžek
v hierarchii pracovišť dle organizační struktury. Reporting o
lůžkovém fondu zadavatele musí být dostupný ze statistického
pohledu dle pracovišť podle ÚZIS.

KIS_201 KIS musí pracovat i s tzv. sdíleným lůžkovým fondem – tj. se
situací, kdy na jednom fyzickém oddělení s pevně danou
kapacitou fyzických lůžek existují dvě různá zdravotnická
pracoviště s různými výkonovými st edisky, situace navíc může
být komplikovaná tím, že obě pracoviště se mohou lišit svou
odborností. Podle provozních pot eb se distribuce fyzických lůžek
mezi obě výkonová st ediska dynamicky mění – tj. ve stejný
okamžik lůžko otev ené pro „pracoviště A“ musí být současně
uzav ené pro „pracoviště B“. Skutečné lůžkové kapacity obou
výkonových st edisek se zobrazují kontaktnímu místu pro
zdravotnickou záchrannou službu a v rámci tohoto zobrazení
nesmí dojít k situaci, aby kontaktní místo dostalo informaci o větší
lůžkové kapacitě, než která je skutečně fyzicky k dispozici.
Zadavatel považuje za optimální ešení p i správě lůžkového
fondu na oddělení se sdíleným lůžkovým fondem takovou situaci,
kdy p idělení fyzického lůžka „pracovišti A“ automaticky povede
k uzav ení tohoto lůžka na „pracovišti B“.

KIS_202 KIS musí umožňovat p idělovat lůžkům atributy minimálně v těchto
hodnotách a jejich kombinacích:

● p – atribut uzav ení lůžka z personálních důvodů; jedná
se o centrálně neplánované uzav ení lůžka vynucené
náhlou změnou personálních podmínek pracoviště;
uvedení atributu se nepromítá do výpočtů obložnosti
oddělení a lůžko je zobrazeno kontaktnímu místu pro ZZS
jako nedostupné

● t – atribut uzav ení lůžka z provozně technických důvodů;
jedná se o centrálně neplánované uzav ení lůžka
vynucené náhlou změnou provozních podmínek
pracoviště; uvedení atributu se nepromítá do výpočtů
obložnosti oddělení a lůžko je zobrazeno kontaktnímu
místu pro ZZS jako nedostupné

● i – atribut izolačního lůžka p i ordinaci zvýšeného
hygienického režimu

● v – atribut lůžka s ventilátorem
● r – rezervované lůžko; p idělení atributu je omezeno

speciálními p ístupovými právy

● e – p istýlkové lůžko evidované v lůžkovém fondu, lůžko
se vůbec nezobrazuje kontaktnímu místu pro ZZS, není

41
zahrnuto do vzorců pro výpočet obložnosti a dalších
statistických charakteristik oddělení; p idělení atributu je
omezeno speciálními p ístupovými právy

● d – lůžko doprovodu, lůžko není součástí oficiálního
lůžkového fondu vůči ÚZIS, není zahrnuto do výpočtů
statistik obložnosti, lůžko se vůbec nezobrazuje
kontaktnímu místu pro ZZS; p idělení atributu je omezeno
speciálními p ístupovými právy

● KIS dále umožní rozlišovat lůžka podle pohlaví
hospitalizovaných na m – mužská, z – ženská, x – pohlaví

nerozlišeno; pokud je u lůžka na vícelůžkovém pokoji
standardního oddělení zvoleno pohlaví hospitalizovaného
pacienta, všechna ostatní volná fyzická lůžka na stejném
pokoji mají automaticky p idělen p íznak shodného
pohlaví a takto jsou volná lůžka zobrazována i
v informacích kontaktního místa pro ZZS, kombinace

atributu m, z a x na jednom pokoji standardního oddělení
je nep ípustná.

P idělování atributů fyzickým lůžkům p ísluší pouze oprávněným
pracovníkům zadavatele podle individuálního nastavení
p ístupových práv; pro atributy d, e a r jsou nutná další mimo ádná
oprávnění.

KIS_203 KIS umožní ukládat hospitalizovaného pacienta na konkrétní
lůžko, a to vyhledáním konkrétního pokoje/lůžka v KIS a uložením
pacienta na něj prost ednictvím p íkazu/klávesy, nebo p etažením P Vyberte
identifikátoru pacienta myší na značku konkrétního lůžka – „drag D_II Vyberte
and drop“, nebo kombinací obou postupů.
P Vyberte
KIS_204 Fyzická struktura lůžkových oddělení musí KIS umožňovat použití
p istýlky na konkrétním oddělení. Pacient uložený na p istýlkové P Vyberte
lůžko (atribut e) je zahrnut do statistik zadavatele vytížení D_II Vyberte
oddělení v KIS stejně, jako kdyby ležel na regulérním lůžku
daného oddělení (matematicky tedy může vyjít obložnost vyšší
než 100 %!).

KIS_205 KIS musí mít v rámci historie možnost trasování pohybu pacienta
po nemocnici p i veškerých p ekladech v rámci nemocnice a je
schopen podat informaci o tom, kdy a kým byly měněny atributy
lůžka, pacient na lůžko uložen i z něj propuštěn. Pomocí položky
historie je možné zobrazovat posloupnost pacientů
hospitalizovaných na konkrétním lůžku. KIS (zejména pro pot eby
oddělení nemocniční hygieny) také umožní pomocí historie
uložení pacienta na lůžko vypátrat všechny kontakty, které
s konkrétním pacientem v průběhu hospitalizace sdílely společný
pokoj/-e. KIS musí umožnit vyhledávání v informacích o pohybu
pacienta podle jeho identifikačních údajů, ale i podle časového
údaje a organizační struktury nemocnice až na úroveň
konkrétního fyzického lůžka.

KIS_206 KIS musí zp ístupnit oprávněným osobám, pracovištím a dále
kontaktnímu místu ZZS v souladu s platnou legislativou, okamžité
aktuální pohledy na obsazení fyzického lůžkového fondu FN HK a
informaci o volných lůžkách zvlášť na standardních odděleních a
zvlášť na jednotkách intenzivní péče (JIP).

KIS_207 KIS musí umožnovat grafické a tabulkové znázornění obsazenosti

42
lůžek jako samostatný dashboard a zároveň i formou tiskové
sestavy (statistiky) včetně informace o atributech lůžek.

KIS_208 Jakmile jsou zahájeny úkony spojené s p ekladem nebo
propuštěním pacienta (vytvá ení závěrečné zprávy, vyplnění
hlášení o hospitalizaci, zadávání statistických údajů o úmrtí D_II Vyberte
pacienta atp.), je lůžko obsazené pacientem v p ehledu graficky
zvýrazněno jako informace pro ídící pracovníky o perspektivní
volné lůžkové kapacitě.

2.2.2 Akutní lůžková péče (multiklinická hospitalizace)
2.2.2.1 Obecné vlastnosti IT ešení lůžkového oddělení

KIS_209 Chorobopis pacienta je z pohledu archivace považován na
samostatnou součást zdravotnické dokumentace zadavatele
v souladu s platnou legislativou. Veškeré části zdravotnické
dokumentace, které vzniknou v průběhu hospitalizace pacienta na P Vyberte
kterémkoli z pracovišť zadavatele (tedy i na pracovišti jiné
odbornosti, než na kterém je pacient aktuálně hospitalizován!),
jsou součástí chorobopisu.

KIS_210 KIS umožňuje propojení chorobopisů v p ípadě p ekladů pacienta
mezi odděleními akutní lůžkové péče (včetně JIP) různých
odborností zadavatele. Tím KIS umožní vytvá ení tzv.
hospitalizačního p ípadu v souladu s Metodikou sestavení p ípadu
hospitalizace, vydávanou ÚZIS. Pokud je p i p ekladu mezi
akutními lůžky různých odborností zvolen v označení pot eby další
péče kód „3“ vyjad ující pot ebu ústavní léčby a v označení
způsobu ukončení léčení kód „3“ vyjad ující p eklad na akutní
lůžko jiné odbornosti v rámci stejného zdravotnického za ízení,
pak KIS umožní nejen spojení dokladů o vykázání péče, tak jak je
uvedeno v kapitole o ešení procesů výkaznictví, ale umožní i
p enos zdravotnické dokumentace mezi p edávajícím a
p ebírajícím pracovištěm zadavatele. Uchazeč navrhne
sofistikovanou kontrolu na propojení hospitalizací. Takový p enos
v oblasti zdravotnické dokumentace obsahuje minimálně:
· p ekladovou zprávu,

· údaje uvedené v Master Patient Indexu včetně p ípadných
aktualizací údajů na začátku aktuálního hospitalizačního
p ípadu P Vyberte

· poslední Epikrízu,

· nabídku léků ordinovaných v posledním dekurzu
p edávajícího pracoviště v parametrických polích včetně
možnosti editace,

· kompletní poslední dekurz včetně záznamu o ordinované
dietě, léčebné rehabilitaci, hygienickém režimu pacienta,
ordinacích jiných terapeutických postupů než výše
uvedených léčivých p ípravků,
· informaci o datu získání informovaného souhlasu
s hospitalizací na lůžkách zadavatele,
· informaci o datu hlášení nedobrovolné hospitalizace
Okresnímu soudu v Hradci Králové, je-li relevantní,

· údaj o počtu hodin umělé plicní ventilace anebo
neinvazivní plicní ventilace (dále v textu UPV/NIV)
v souladu s Metodikou užití DRG markerů v systému
IR-DRG či v dokumentu, který v čase tento dokument
v pravidlech DRG systému České republiky perspektivně

43
oficiálně nahradí; p ebírající pracoviště může p idávat
další hodiny UPV/NIV, které se v systému budou p ičítat
k počtu hodin p eneseném z p edávajícího pracoviště,
· údaj o izolačním režimu včetně jeho typu (číselníková
položka označovaná velkým tiskacím písmenem)
s vyznačením od a do kdy byl u pacienta zaveden; je
možná varianta, že zavedený izolační režim bude
v platnosti i na p ebírajícím pracovišti,
· informace o již hlášených nozokomiálních nákazách
· údaj o již existující, nebo zadavatelem vystavené dočasné
pracovní neschopnosti včetně jejího evidenčního čísla.

KIS_211 Založení chorobopisu je možné jak z IT ešení ambulantního
procesu, tak p ímo na lůžkovém oddělení. Zadavatel požaduje,
aby pro vybraná pracoviště bylo možné nastavit i následující
podmínku: Je-li pacient p ijímán p ímo na JIP, pak je pro něj
zároveň obsazeno i lůžko na některém ze standardních oddělení P Vyberte

pracoviště.
U pacienta p ijatého na lůžkové oddělení jsou p ístupné všechny
informace obsažené v Master Patient Indexu.

KIS_212 KIS umožňuje p ijmout na lůžko doprovod pacienta, zobrazit jej P Vyberte
v grafickém anebo tabulkovém p ehledu fyzické lůžkové kapacity
zadavatele (atribut d).

KIS_213 Každý chorobopis obsahuje úvodní stranu s informacemi, které
slouží pro identifikaci pacienta a zjištění údajů, které je zadavatel
povinen p edávat ÚZIS v souladu s pravidly statistických výkazů P Vyberte

hospitalizací.

KIS_214 KIS umožňuje p ijmout pacienta bez známého čísla pojištěnce či
rodného čísla, založit u něho chorobopis a pomoci automaticky
vygenerovat náhradní identifikátor (nap . číslo pojištěnce či rodné
číslo), jak je specifikováno výše. V podobném režimu je KIS P Vyberte
p ipraven i na poskytování péče novorozencům, u kterých mívá
zpoždění p idělení rodného čísla či jiného identifikátoru fyzických
osob matrikou zpoždění ádově v týdnech od narození.

2.2.2.2 P íjem pacienta na oddělení

KIS_215 P íjem pacienta na lůžko zadavatele se z pohledu zdravotnické
dokumentace skládá z následujících částí:
· příjem pacienta na oddělení – obsahuje datum a čas p ijetí
k hospitalizaci, kód p íjmové pracovní diagnózy v souladu
s pravidly kódování nemocnosti MKN-10, ostatní údaje
vyžadované ÚZIS; p íjem pacienta vzniká okamžitě se
založením chorobopisu,
· parametrický záznam data a času získání písemného
informovaného souhlasu s hospitalizací – KIS je vybaven
P Vyberte
nástrojem pro záznam data a času, kde personál zaškrtne
pole či stiskne tlačítko poté, kdy byl souhlas získán. Pokud
zůstane záznam prázdný, za 24 hodin po p ijetí KIS
zobrazí pracovníkům výkonového st ediska alert, že je
nutné souhlas získat, nebo hlásit nedobrovolnou
hospitalizaci soudu (v tom p ípadě zůstává i nadále
záznam nevyplněný).
· anamnéza – její struktura je popsána níže; musí být
sepsána v souladu s legislativou do 24 hod. od p ijetí
k hospitalizaci,

44
· objektivní fyzikální nález při přijetí – jeho struktura je
popsána níže; musí být sepsán v souladu s legislativou do
24 hod. od p ijetí k hospitalizaci,

· epikríza při přijetí – specifikace je uvedena níže

Anamnéza

KIS_216 Anamnéza - oddíl musí být vyplněný a uzav ený léka em do 24
hodin od p ijetí pacienta – KIS by měl automaticky upozorňovat,
pokud povinnost není splněná; u hospitalizovaných pacientů se
zaznamenává do formulá e, který má minimálně následující oddíly
(uchazeč může navrhnout i jemnější členění či jiné po adí):
· Záznam údajů o registrujícím praktickém léka i
· Záznam údajů o ostatních ambulantních specialistech
· Rodinná anamnéza

· Alergická anamnéza P Vyberte

· Osobní anamnéza

· Gynekologická anamnéza

· Farmakologická anamnéza

· Pracovní anamnéza

· Sociální anamnéza

· Riziková anamnéza

· Epidemiologická anamnéza

· Nynější onemocnění

KIS_217 Záznam údajů o registrujícím praktickém lékaři –
parametrickou formou: jméno, p íjmení, adresa nebo alespoň
obec, ve které se ordinace nachází; jsou-li tyto údaje v KIS
k dispozici z p edchozích ošet ení pacienta, vyplní se automaticky
(údaj je i součástí MPI). Pokud budou do konce realizace projektu
v roce 2021 dostupné údaje z Národního registru zdravotnických P Vyberte

pracovníků a Národního registru poskytovatelů zdravotních služeb,
KIS má být schopný prost ednictvím integrační platformy ově it
identitu léka e a vložit jeho ově ené údaje z registru do záznamů
pacienta.

KIS_218 Záznam údajů o ostatních ambulantních specialistech, které
pacient navštěvuje; je p ípustné volné textové okno, nebo sestava
parametrických oken pro záznam jména, p íjmení léka ů,
specializací a míst ordinací. Pokud budou do konce realizace
projektu v roce 2021 dostupné údaje z Národního registru P Vyberte
zdravotnických pracovníků a Národního registru poskytovatelů
zdravotních služeb, KIS má být schopný prost ednictvím integrační
platformy ově it identitu léka e a vložit jeho ově ené údaje
z registru do záznamů pacienta.

KIS_219 Rodinná anamnéza – okno se zápisem volného textu libovolné P Vyberte
délky

KIS_220 Alergická anamnéza – sestava parametrických oken, která je
možné po ádcích p idávat, každý ádek obsahuje alergen, typ
alergické reakce (typ reakce může být ešen výběrem z číselníku,
jednou z položek je konstatování „bez bližšího určení“), závažnost
alergické reakce (nap . alergická rýma, anafylaktický šok). Jsou-li
známy alergie z p edchozích vyšet ení u zadavatele, vyplní se P Vyberte

automaticky. Na závěr oddílu budou zaškrtávací pole, která budou
kritickým bodem s povinností vyplnit právě jedno z nich d íve, než
bude možné anamnézu uzav ít. Pole budou následující:

· „aktualizováno“ – léka ově il s pacientem kompletnost

45
údajů o alergii; možnost se bude nabízet vždy
· „neaktualizováno“ – bude se používat u alergické

anamnézy p evzaté z historických záznamů bez
nemožnosti od pacienta aktuálně ově it informace;
možnost bude ve výběru pouze v okamžiku, kdy bude
existovat alespoň jeden historický údaj o alergii
· „nezjistitelné“ – bude se užívat nap . u pacienta
neschopného komunikovat bez jakéhokoli údaje o alergii
z minulosti; možnost bude ve výběru pouze v okamžiku,
kdy budou jakékoli historické údaje o alergii nedostupné.
Dokud bude za současné hospitalizace zvolena volba
„neaktualizováno“ nebo „nezjistitelné“, bude informační pole o
alergiích pacienta v p ehledu údajů o něm nějakým způsobem
zvýrazněno do okamžiku, dokud nedojde k doplnění alergické
anamnézy a léka nezvolí položku „aktualizováno“.
Parametrické ešení alergické anamnézy bude sloužit i pro záměr
vyhotovení pacientského souhrnu s využitím funkcí KIS.

KIS_221 Osobní anamnéza – okno se zápisem volného textu libovolné P Vyberte
délky.

KIS_222 Gynekologická anamnéza – okno se zápisem volného textu P Vyberte
libovolné délky; objeví se výhradně u pacientů ženského pohlaví
podle údaje v Master Patient Indexu.

KIS_223 Farmakologická anamnéza – tvo í samostatný oddíl, který má
využití v dalších procesech podporovaných KIS. I v tomto oddílu je
p ístupná historie, která na prvním místě zp ístupní vždy časově
poslední zápis do farmakologické anamnézy bez ohledu na to,
jestli se jedná o záznam ambulantní nebo z hospitalizace.
Farmakologická anamnéza se skládá minimálně ze dvou částí.
I. První část tvo í parametrická část uspo ádaná do ádků.
ádky je možné p idávat dle pot eby. Do ádků
parametrické části pat í parametrické okno pro název léku.
Léka léky vybírá ze stejného číselníku, který musí
uchazeč dodat pro ordinaci léků na lůžkových odděleních
– bližší specifikace je popsána níže. Dále následuje
parametrické okno pro zápis formy léku (tj. tableta,
injekce, kapky; uchazeč může nabídnout volbu
z editovatelného číselníku), textové okno pro zápis
dávkování (uchazeč může nabídnout i p eddefinované
varianty podávání léků ve čty ech časech Ráno – Poledne
– Večer – Noc) a zbytek ádku vyplní volné textové okno P Vyberte
pro vložení dalších informací k užívanému léku.
I. Druhou částí je volné textové okno pro zápis těch druhů
léčivých p ípravků, pro které je výše uvedený způsob
zápisu nevhodný (nap . pacient si nepamatuje p esně
názvy užívaných léků, individuálně p ipravované léčivé
p ípravky, …).
Logika tohoto uspo ádání Farmakologické anamnézy smě uje ke
následujícím cílům:
· Takto parametricky zadané léky se z anamnézy nabídnou
léka i p i sestavování dekurzu na lůžkových odděleních –
viz blíže tato kapitola, ušet í čas léka i p i sestavování
dekurzu.

· Takto parametricky zadané léky z anamnézy se budou
nabízet léka i p i editaci závěrečné propouštěcí zprávy
proto, aby mohly být respektovány lékové zásoby pacienta
ve vlastním sociálním prost edí a šet il tak náklady na
nově p edepisovaná léčiva; léka p i propuštění nebude

46
muset vystavovat tolik receptů.
· Parametricky odebraná farmakologická anamnéza bude

využita p i sestavování pacientského souhrnu s využitím
KIS.

KIS_224 Pracovní anamnéza – okno se zápisem volného textu libovolné
délky. Vedle okna zaškrtávací pole o požadavku na vystavení
dočasné pracovní neschopnosti (DPN) za této hospitalizace.
Součástí pracovní anamnézy je okno, do kterého se p enese
informace o již existující dočasné pracovní neschopnosti, p ípadně P Vyberte

eNeschopence (bude-li technicky možné s ohledem na legislativní
vývoj), pokud p i p íjmu pacienta byly informace o její existenci
známy a uvedeny do Master Patient Indexu.

KIS_225 Sociální anamnéza – okno se zápisem volného textu libovolné P Vyberte
délky.

KIS_226 Riziková anamnéza – okno se zápisem volného textu libovolné P Vyberte
délky, zvlášť pro kou ení tabáku, konzumaci alkoholu, zneužívání
jiných omamných nebo psychotropních látek.

KIS_227 Nynější onemocnění – okno se zápisem volného textu libovolné
délky.

· Toto pole nenabízí žádnou historii p edchozích anamnéz
z minulosti na stejném pracovišti (tzn., že text vždy musí
být unikátní a nový) u hospitalizací probíhajících pouze na
jednom zdravotnickém pracovišti zadavatele.

· V p ípadě p ekladu pacienta mezi různými zdravotnickými
pracovišti poskytovatele (viz požadavek propojení
chorobopisů v rámci jednoho hospitalizačního případu) P Vyberte
dojde k automatickému p evzetí textu Anamnézy p íčiny
aktuální hospitalizace z prvního p edávajícího pracoviště v
adě a funkce historie nabídne všechny p edchozí
záznamy Anamnézy p íčiny aktuální hospitalizace ze
všech navazujících zdravotnických pracovišť propojených
do aktuálního hospitalizačního p ípadu. Údaje
z jednotlivých anamnéz lze do textu z historie vkládat a
neomezeně editovat (výběr podstatných skutečností).

KIS_228 Parametry pro ošet ovatelskou dokumentaci p i p ijetí pacienta
jsou popsány v samostatné kapitole této p ílohy. Jsou-li
v ošet ovatelském p íjmu některé z údajů totožné s údaji
v léka ské části p íjmové dokumentace, KIS zprostředkuje jejich
vzájemný přenos do ostatních částí zdravotnické P Vyberte

dokumentace od toho z účastníků příjmu pacienta, který daný
údaj získal jako první s výjimkou alergické anamnézy, kterou
musí vždy definitivně odsouhlasit lékař.

Objektivní nález při přijetí

KIS_229 Objektivní nález p i p ijetí – oddíl musí být vyplněný a uzav ený
léka em do 24 hodin od p ijetí pacienta – KIS by měl automaticky
upozorňovat, pokud povinnost není splněná do 20 hodin po p ijetí;
po uložení definitivní verze Objektivního nálezu p i p ijetí p ijímající
léka odpovědný za p íjem text uzamkne (automaticky nejpozději
po 24 hodinách od času p ijetí pacienta k hospitalizaci) proti P Vyberte

možnosti jej editovat; objektivní nález je rozdílný pro dětské
pacienty, kde zadavatel požaduje možnost nastavení položek
s ohledem na věk dítěte (nap . fyzikální známky bolesti
novorozenců), u dospělých pacientů se skládá alespoň

47
z následujících položek:
· Hmotnost pacienta
· Výška pacienta
· BMI – body mass index
· Tepová frekvence
· Krevní tlak
· Dechová frekvence
· Tělesná teplota
· Performance status dle WHO
· Fyzikální vyšet ení

KIS_230 Hmotnost pacienta – povinná položka má dvě parametrická okna
pro zadání hmotnosti „změ ené“, nebo „odhadnuté“; kterákoli ze
zadaných hodnot se p enáší do žádanek pro radiologii.
„Odhadnutá“ hmotnost se nenabízí pro účely ordinací léčiv (nap . P Vyberte
pro dávkování cytostatik, biologické léčby).
Na pediatrických odděleních je možné nastavit hmotnost
v gramech, a to bez zaokrouhlování.

KIS_231 Výška pacienta – povinná položka má dvě parametrická okna pro
zadání výšky „změ ené“, nebo „odhadnuté“; kterákoli ze zadaných
hodnot se p enáší do žádanek pro radiologii. „Odhadnutá“ výška P Vyberte
se nenabízí pro účely ordinací léčiv (nap . pro dávkování
cytostatik, biologické léčby).

KIS_232 BMI – body mass index – parametrické okno, výpočet vždy jen ze P Vyberte
změ ených hodnot.

KIS_233 Tepová frekvence – povinná položka, parametrické okno. P Vyberte

KIS_234 Krevní tlak – povinná položka, parametrická okna pro hodnotu P Vyberte
systolického a diastolického TK.

KIS_235 Dechová frekvence – povinná položka, parametrické okno. P Vyberte

KIS_236 Tělesná teplota – povinná položka, parametrické okno. P Vyberte

KIS_237 Performance status (PS) dle WHO – parametrické okno;
nepovinné, pro vybraná zdravotnická pracoviště zadavatele, u
ostatních může být požadavek na jeho skrytí; KIS nabízí nápovědu P Vyberte

pro léka e s tabulkou hodnocení PS.

KIS_238 Fyzikální vyšetření – povinná položka, okno volného textu.
S možností také využívat uživatelem p eddefinované texty z
číselníku k editaci pro konkrétního pacienta, s tím, že KIS může P Vyberte
mít tyto p eddefinované vzory individuální s možností editace dle
individuálních preferencí.

KIS_239 Bolest při přijetí – okno se zápisem volného textu libovolné délky; P Vyberte
je povinnou položkou v dětském léka ství, kde jsou známky
p ítomnosti bolesti součástí objektivního nálezu.

Epikríza

KIS_240 Epikríza – povinná položka, první epikríza se pro editaci otvírá
automaticky poté, co léka uzav e Objektivní nález p i p ijetí, aby
mohl zapsat první souhrn pracovních diagnóz pacienta a uvést
důvody p ijetí a plán dalšího poskytování zdravotních služeb. P Vyberte

Epikríza je v průběhu hospitalizace opakovaně upravována ve
všech svých částech a v průběhu hospitalizace tedy vzniká několik

48
verzí, které musí být zpětně k dispozici pro náhled, nikoliv však pro
editaci; uzamčení aktuální epikrízy proti editaci probíhá nejpozději
k 24. hodině p íslušného kalendá ního dne. Kromě toho léka
píšící epikrízu musí mít možnost ji uzamknout proti další editaci
kdykoli; pokud tedy ve stejném dni vznikne další epikríza, bude se
jednat o další verzi, p edchozí zůstane zachovaná. Ve všech
oddílech epikrízy je dostupná historie. Časově poslední epikríza
poskytne informace pro tvorbu závěrečné propouštěcí zprávy.
Pokud na více zdravotnických pracovištích zadavatele dojde
k propojení hospitalizací do hospitalizačního p ípadu, pak se
všechny části časově poslední epikrízy z p edávajícího pracoviště
p evezmou do první p íjmové epikrízy p ebírajícího pracoviště tak,
aby nedocházelo ke ztrátě informací a léka je mohl dále editovat.

KIS_241 Epikríza se člení alespoň na následující části:
· Hlavní diagnóza

· Diagnostický souhrn

· Průběh hospitalizace P Vyberte
· Plán dalšího poskytování zdravotních služeb

· Hygienický režim

· Nozokomiální nákazy
Poznámka: Počty hodin UPV/NIV bude systém sledovat
v samostatné funkci na JIP.

KIS_242 Hlavní diagnóza – povinná položka, začíná parametrickým polem P Vyberte
pro kód MKN-10 s navazujícím polem textu z číselníku diagnóz
MKN-10; kód je využíván pro tisk samolepicích štítků

KIS_243 Diagnostický souhrn – povinná položka, pole volného textu pro P Vyberte
záznam jednotlivých diagnóz pacienta.

KIS_244 Průběh hospitalizace – povinná položka, pole volného textu. P Vyberte

KIS_245 Plán dalšího poskytování zdravotních služeb – povinná P Vyberte
položka, pole volného textu.

KIS_246 Hygienický režim – povinná položka, parametrické pole
s číselníkem editovatelným zadavatelem. Pokud bude zvolen jiný
režim než „S – standardní“, léka musí povinně vyplnit
parametrické pole pro datum zavedení p ísnějšího režimu
(nabídne se kalendá pro volbu data) a v epikríze se objeví i
parametrické pole pro zadání ukončení platnosti p ísnějšího
režimu (nabídne se kalendá pro volbu data). Epikríza umožní
v p ípadě pot eby p idávat další ádky pro záznam změny P Vyberte
hygienického režimu stejným způsobem, jak je popsáno výše;
p edchozí po ízené záznamy o hygienických režimech zůstanou
zachovány (změny nep episují p edchozí údaje a v epikríze je
vidět celá historie změn hygienického režimu). Zadavatel považuje
za optimální ešení situaci, kdy bude údaj o změně hygienického
režimu do Epikrízy p enášen KIS automaticky poté, kdy dojde
k jeho ordinaci/změně do léka ského dekurzu (viz níže).

Lékařský dekurz

KIS_247 Lékařský dekurz. Dokumentuje poskytování zdravotních služeb
vždy po dobu 24 hodin, a to od 7:00-7:00 následujícího dne dle
požadavku zadavatele. Zadavatel bude využívat k dokumentování
popisu zdravotního stavu pacienta listinnou dokumentaci, KIS P Vyberte

bude poskytovat podporu pro její tvorbu.
Zadavatel požaduje možnost flexibilního nastavení léka ského

49
dekurzu tak, aby v první mezní variantě mohl být léka ský dekurz
včetně všech ordinací léčivých p ípravků obsažen na jednom listu
papíru, druhá mezní varianta je stav, kdy bude možné nastavit dva
různé listinné dokumenty – na jednom z nich budou ordinované
léčivé p ípravky na libovolný počet (max. 7) dnů, tzn. léková karta,
a na druhém bude vytvo en strukturovaný prostor pro veškeré
ostatní záznamy (nap . ordinace diet, záznam vizit, ordinace
vyšet ení) – tzn. vlastní léka ský dekurz.
Konkrétní nastavení pro jednotlivá oddělení pak budou realizována
v průběhu analýz u zadavatele v průběhu dodávky. Zadavatel
požaduje možnost tvorby šablon dekurzu, které bude moci pro
konkrétní typ oddělení nastavit jako defaultní a v p ípadě pot eby
je rychle změnit. Každý dekurz ve svém záhlaví obsahuje
upozornění na alergie pacienta.

KIS_248 Lékařský dekurz umožňuje alespoň následující činnosti:
· ordinaci výživy – specifikace je v samostatném oddílu
· ordinaci léčebné rehabilitace a vystavení žádanky P Vyberte
· ordinaci hygienického režimu – parametrický údaj výběrem
z číselníku a vyznačením data, od kdy režim platí (datum P Vyberte
se shoduje s tím v Epikríze) D_II Vyberte
· ordinaci vyšet ení – tj. záznam informací pot ebných pro Vyberte
vystavení všech žádanek, zejména pro laboratorní P Vyberte
komplement P
· záznam vizit
· ordinaci terapeutických intervencí v textové formě –
lékových (nap . ordinace individuálně vyráběných léčivých
p ípravků, složitá podmíněná podání léčivých p ípravků,
složité infuze s kombinací 2 a více léčivých p ípravků
s roztokem edění a instrukcemi pro podání) i nelékových
(nap . péče o dýchací cesty, o vstupy); okno pro zápis
volného textu
· ordinaci léčivých p ípravků – specifikace je v samostatném
oddílu níže

KIS_249 Ordinace výživy – výběr diety bude v parametrickém okně
z číselníku diet v dietním systému zadavatele a v dalším
parametrickém okně možnost z číselníku zadavatele vybrat
p ídavky. Kromě parametrického okna bude vedle okno pro zápis
volného textu pro zadání dalších pokynů (nap . nesnáší luštěniny,
alergie na mléčné výrobky). KIS musí umožňovat zadat dietu
pacienta i s p edstihem na několik dnů. Ordinace diety v KIS musí
být dostupné léka i, sest e a nutričnímu terapeutovi.

KIS_250 KIS bude obousměrně integrován s dietním systémem zadavatele
ASTRIS. Kompletní údaje ordinace diet z obou oken musí být
dávkově k p edem stanoveným časům p enositelné do systému
ASTRIS. KIS musí umožňovat zadat dietu pacienta i s p edstihem
na několik dnů a s tímto p edstihem dávkově p edat informace
systému ASTRIS. Uchazeč v rámci integračních vazeb zachová
p ístup k informacím na „Nástěnce“ systému ASTRIS (nap .
harmonogramu rozvozu stravy, jídelníčkům).

KIS_251 Zcela mimo integraci se systémem ASTRIS (viz integrace) budou
ordinace enterální výživy, parenterální výživy a potravinových
doplňků pro léčebné účely, které budou ve stejném oddílu
dekurzu, právo ordinovat má pouze léka .

KIS_252 Ordinace hygienického režimu – v dekurzu je vždy aktuálně
platný hygienický režim, a to bez historie změn.

50
KIS_253 Ordinace vyšetření – samostatný oddíl pro zápis volného textu, P Vyberte
do kterého zapisuje léka . Z kteréhokoli oddílu dekurzu je možné P Vyberte
spustit funkci vystavení žádanek. P Vyberte
P Vyberte
KIS_254 Přehled ordinovaných vyšetření – KIS v sobě obsahuje službu
dostupnou z IT ešení procesů na ambulancích i lůžkových P Vyberte
oddělení, která u konkrétního pacienta zobrazí seznam všech
objednaných vyšet ení. V seznamu uspo ádaném do tabulky se D_II Vyberte
zobrazuje druh vyšet ení (nap . ambulantní vyšet ení, zobrazovací N Vyberte
vyšet ení, vyšet ení laboratorního komplementu), datum
objednání, datum p iděleného termínu (je-li relevantní nap . u
zobrazovacích vyšet ení), datum skutečného provedení
vyžádaného vyšet ení. Tabulku se seznamem vyšet ení lze t ídit
podle nadpisů jednotlivých sloupců buď podle metod vyšet ení,
nebo vzestupně či sestupně pomocí dat.

KIS_255 Přehled provedených vyšetření – KIS musí obsahovat report
s p ehledem vyšet ení, který bude obsahovat minimálně parametry
uvedené v p edchozím bodě „P ehled ordinovaných vyšet ení“.
Výběrem položky z p ehledu lze zprávu či výsledek z provedeného
vyšet ení alespoň zobrazit.

KIS_256 Záznam vizit – okno pro záznam volného textu léka em. Léka má
také p ístupová práva do záznamového listu pacienta vedeného
v rámci SW podpory ošet ovatelských procesů, aby mohl do
parametrických oken zapsat životní funkce (nap . TK, TF,
hmotnost).

KIS_257 Ordinace léčivých přípravků – zadavatel požaduje
kombinovanou formu, kde na parametrické okno/okna (závisí na
ešení uchazeče) pro zápis:

· názvu léčivého p ípravku (nap . Ibalgin)
· množství účinné látky v jedné dávce (je-li relevantní) -

nap . 400 mg
· formy léčivého p ípravku (nap . tbl.),
navazuje textové okno pro zápis dávkování. Zadavatel očekává
možnost výběru parametrického údaje cesty podání (nap . i.v.,
p.o.) formou číselníku a p eddefinovaných textů pro dávkování
(nap . ráno – poledne – večer- noc ve formě etězce „1-1-1-1“), ale
i možnost vepsat dávkování volným textem.
Záleží na volbě uchazeče, jakou formou zp ístupní léka i t i výše
uvedené klíčové údaje pro ordinaci léčivého p ípravku – název
léčivého p ípravku, množství účinné látky v jedné dávce (je-li
relevantní) a formu léčivého p ípravku; uchazeč může zadání ešit
vlastním číselníkem pro ordinaci léčivých p ípravků nebo použít
nástroj, který požadované údaje bude ad hoc extrahovat z aktuální
verze oficiálního číselníku léčivých p ípravků SÚKL, p ipouštíme
ale i jiné ešení.
Zadavatel jako výsledný stav po ešení navrženém uchazečem
požaduje, aby proces vyhledání léčivého p ípravku byl rychlý a KIS
nabízel pro výběr seznam vhodných hromadně vyráběných
léčivých p ípravků (HVLP) hned po zadání části textu obchodního
názvu léčivého p ípravku.

KIS_258 Pově ené osoby zadavatele mohou buď p ímo, nebo
prost ednictvím dodavatele ovlivňovat po adí azení navrhovaných
léčivých p ípravků. KIS na první pozice nabízeného seznamu
nabídne léčivé p ípravky na pozitivním listu zadavatele.

KIS_259 Ordinace léčivých přípravků — Je s výhodou, pokud nabídku
názvu HVLP zahájí KIS i po zadání části textu generického názvu

51
léčivého p ípravku.

KIS_260 Zadavatel požaduje možnost upozorňovat léka e na léčivé
p ípravky, které jsou zadavatelem umístěny na pozitivní list;
zadavatel je schopen na základě své obchodní politiky takový D_II Vyberte
pozitivní list vytvá et a měnit; forma upozornění záleží na uchazeči P Vyberte
(nap . barevné podbarvení položky v seznamu, za azení položky P Vyberte
v rámci ATC skupiny na první místa v seznamu). P Vyberte
P Vyberte
KIS_261 KIS umožňuje automaticky aktualizovaný údaj o počtu dnů
podávání léčivého p ípravku. P Vyberte

KIS_262 Zadavatel požaduje ve funkci Ordinace léčivých p ípravků také P Vyberte
možnost vytvá et ordinace injekčních roztoků (infuzí) nebo D_II Vyberte
inhalačních roztoků tak, že p i rozpisu jednotlivých složek infuze se
uplatňuje stejný princip výběru HVLP popsaný výše v kombinaci
s textovým polem pro doplnění dalších informací (nap . počtu
jednotlivých dávek, specifikace objemu), stanovení cesty podání
roztoku, počáteční rychlosti a dalších podmínek podávání.

KIS_263 Zadavatel požaduje možnost vytvá ení šablon ordinací vybraných
HVLP (nap . rozpis standardního edění noradrenalinu, inzulinu)
tak, aby tyto šablony bylo možné rychle vkládat do seznamu
ordinovaných léčiv, zejména na JIP.

KIS_264 Po skončení zadávání jednotlivých léků jsou ordinovaná léčiva na
tištěném dekurzu rozdělena podle cesty podání na injekční léčiva
podávaná intravenózně, injekční léčiva podávaná jinou než
intravenózní cestou (tj. s.c., i.m., k proplachům drénů atp.), léčiva
podávaná perorálně, léčiva podávaná lokálně (nap . kapky, masti).
Samostatně jsou pak v seznamu ordinovaných léčivých p ípravků
vyčleněny všechny ATC skupiny antiinfektiv (tj. antibiotik,
antivirotik, antimykotik a antiparazitik), opět azené podle cesty
podání (injekčně, perorálně, lokálně).

KIS_265 Specifika lékařského dekurzu pro JIP:
Jednotka intenzivní péče (JIP) musí mít z pohledu funkcionality
KIS alespoň ty výše popsané funkcionality, které má IT ešení pro
standardní oddělení.
Zadavatel požaduje funkci pro záznam ordinaci umělé plicní
ventilace (UPV) nebo neinvazivní ventilace (NIV).
Jestliže bude režim UPV nebo NIV platný už na začátku směny,
zp ístupní se parametrické pole pro zadání počtu hodin
v p edchozím ošet ovacím dni (od 7:00 do 7:00 hod.). P i p ekladu
pacienta mimo JIP (i v rámci vlastního pracoviště) se automaticky
otev e místo pro záznam hodin UPV/INV. Zadavatel p ipouští i
situaci, kdy vyplnění na daném pracovišti bude kontrolní
podmínka, bez jejího splnění nebude možné v procesu p ekladu
pokračovat. Dny UPV/NIV se v KIS sčítají a sumární součet je
p enesen do závěrečné zprávy z hospitalizace hned za text
poslední Epikrízy. Pokud bude více chorobopisů propojeno do
hospitalizačního p ípadu, pak se do závěrečných zpráv bude
p enášet suma všech hodin UPV/NIV získaná v rámci
hospitalizačního p ípadu jako celku.

KIS_266 KIS nabízí možnost šablon nejen pro ordinace léčivých p ípravků,
ale i pro ostatní činnosti, které je na JIP pot eba denně
p ehodnocovat – nap . pohybový režim a rehabilitace, sedaci,
výživu, polohování.

KIS_267 Zadavatel očekává možnost elektronického záznamového listu

52
pacienta na JIP pro zápisy a sdílení informací pro ošet ovatelskou
dokumentaci. Kromě tabelárního zobrazení zadavatel požaduje
možnost zvolené fyziologické funkce zobrazit v grafickém trendu –
nap . teplotu. Zadavatel požaduje zejména manuální zadávání
hodnot do parametrických polí v čase. Pro funkci elektronického
záznamového listu není pot eba on-line napojení KIS na monitory
životních funkcí či jiné zdravotnické prost edky na JIP, musí
fungovat i v režimu výhradně manuálního zadávání hodnot.

KIS_268 Uchazeč může nabídnout integraci s centrálními monitorovacími N Vyberte
systémy pro elektronický p enos hodnot mě ených fyziologických
funkcí do dokumentace pacienta v KIS.

IT řešení zobrazování laboratorních výsledků – platí pro lůžka i ambulance

KIS_269 IT ešení pro zobrazování laboratorních komplementárních
vyšet ení: KIS poskytne pro lůžkové oddělení i ambulance funkce
procesu prohlížení a zobrazování výsledků laboratorních
komplementárních vyšet ení včetně možnosti výběru konkrétních
vyšet ení a v rámci nich konkrétních namě ených hodnot (nap .
zaškrtávacím polem, časovým intervalem od-do). Zvolený výběr
laboratorních hodnot KIS zobrazuje ve formě tabulky; typy P Vyberte
vyšet ení, které uživatel nevybral pro zobrazení, zůstanou skryty.
Výběr alespoň 5 zvolených laboratorních vyšet ení a u nich
namě ených hodnot KIS umí zobrazit i graficky (možnost zahrnout
do výběru 6 a více typů vyšet ení je výhodou). Zvolený výběr
laboratorních vyšet ení a u nich zobrazovaných hodnot KIS musí
umět exportovat také do souboru alespoň ve formátu xls.

KIS_270 Princip možnosti výběru laboratorních vyšet ení a výběru rozsahu
stanovených hodnot vyšet ených v průběhu hospitalizace KIS
musí poskytovat i pro editaci závěrečné zprávy. Výsledky
laboratorních metod jsou do závěrečné zprávy p eváděny
výhradně ve formátu: název vyšet ení zkratkou (zkratky jsou P Vyberte
editovatelné zadavatelem) – hodnoty v časové adě od časově
prvních (vstupních) až po časově poslední (výstupní). Zadavatel
nep ipouští zobrazení ve formě „první, poslední, minimální,
maximální hodnota“.

Závěrečná zpráva z hospitalizace

KIS_271 Zadavatel požaduje, aby procesu tvorby závěrečné zprávy
z hospitalizace sledoval pevnou sekvenci následujících kroků
s cílem ídit léka e a zabránit ztrátám informací:
1. Otev ení statistického výkazu o hospitalizaci v souladu
s pokyny ÚZIS, kde léka povinně musí uvést alespoň
datum a čas ukončení hospitalizace, kód „Pot eby další
péče po propuštění“ a kód „Ukončení hospitalizace“.
V p ípadě úmrtí pacienta musí léka vyplnit také kód
diagnózy podle MKN-10 pro „Základní p íčinu smrti“ a
„Bezprost ední p íčinu smrti“. P Vyberte

2. Po uložení statistického výkazu o hospitalizaci se u
pacienta otev e Epikríza, ve které léka provede
závěrečnou editaci diagnostického souhrnu pro
závěrečnou zprávu, editaci vlastního textu epikrízy,
kontrolu zadání informací o hygienickém režimu.
3. Po uložení Epikrízy dojde k otev ení IT ešení pro
zobrazování laboratorních komplementárních vyšet ení,
kde podle rozhodnutí léka e vznikne výběr výsledků

53
p enášených do závěrečné zprávy.

KIS_272 Po dokončení těchto t í kroků dojde k vlastnímu vygenerování
závěrečné zprávy s oddíly azenými v následujícím po adí:
1. hlavička závěrečné zprávy s uvedením informací o pacientovi,
ale i o propouštějícím oddělení; do hlavičky se automaticky
doplní data od kdy, do kdy hospitalizace probíhala
2. diagnostický souhrn slovně – p evzat z epikrízy, bez kódů
MKN-10
3. kompletní alergická anamnéza
4. krevní skupina pacienta – je-li známa
5. u malignit TNM klasifikace, p ípadně pTpNpM – povinný údaj,
jsou-li známy a relevantní
6. seznam implantovaných zdravotnických prost edků
p ítomných v těle pacienta, je-li relevantní
7. průběh hospitalizace textem – p evzat z epikrízy
8. hygienický režim včetně celé historie v průběhu hospitalizace
– p evzat z epikrízy
9. počet hodin UPV/NIV – p evzat z funkce pro sledování počtu
hodin ventilace na JIP
10. kompletní anamnéza získaná p i p ijetí pacienta (tj. všechny
části specifikované výše)
11. objektivní nález zjištěný p i p ijetí pacienta
12. seznam operačních výkonů p evzatý z operačních protokolů;
každá operace s existujícím operačním protokolem je
reprezentována datem a časem zahájení operace, názvem
operace a jménem operatéra
13. výběr komplementárních laboratorních výsledků azených po
jednotlivých druzích vyšet ení v časových adách od časově
nejstarších po časově nejmladší
14. popisy vybraných zobrazovacích vyšet ení azené od časově
nestarších po časově nejmladší P Vyberte

15. doporučení strukturované s následujícími položkami:
15.1. doporučení dietního režimu
15.2. doporučení pohybového režimu
15.3. doporučená farmakologická léčba – pro výběr léků se
nabídnou záznamy z parametrických oken i okna
volného textu z farmakologické anamnézy (cílem je
využít zásoby léčivých p ípravků, které má pacient
doma) a záznamy z parametrických oken i okna
volného textu z časově posledního dekurzu lůžkového
oddělení; léka má možnost editace seznamu
15.4. údaj o doporučených zdravotnických prost edcích
15.5. vygenerování ošet ovatelských problémů a doporučení
z uzav ené ošet ovatelské dokumentace (je-li
relevantní)
15.6. údaj o pot ebě dočasné pracovní neschopnosti včetně
známých údajů o eNeschopence (jsou-li dostupné),
včetně údajů o informacích pro Ú ad práce u pacientů
v jeho evidenci, p ípadně údaje o vystavení dokladů
pro získání p íspěvku, tzv. dlouhodobého ošet ovného.
15.7. údaje o dopravě pacienta, údaj o vystaveném p íkazu
ke zdravotnickému transportu
15.8. další údaje požadované plátci péče – údaje o
vystavených receptech, p edpisech na výdej
zdravotnických prost edků
15.9. podpis léka e, který generoval závěrečnou zprávu,
informace z KIS
15.10. podpis vedoucího léka e lůžkového oddělení,
informace z KIS

54
15.11. Automaticky vložený datum a čas, kdy byl text
závěrečné zprávy schválen a uzav en jako definitivní a
vytištěn.

KIS_273 Závěrečná zpráva je v kterékoli své části editovatelná léka em. Je
možné průběžně ukládat její verze. Dokud není definitivně
schválena léka em se specializovanou způsobilostí s p íslušnými P Vyberte
právy zprávu uzav ít pro archivaci, je každá vytištěná kopie
z etelně systémem označena pouze jako kopie.

2.2.3 IT řešení pro porodnictví a neonatologii

KIS_274 KIS v ešení procesu porodnictví a neonatologie obsahuje také
všechny položky, optimálně v parametrické formě s volbou
prost ednictvím výběru z číselníků, které pracovníci zadavatele P Vyberte
musí vyplňovat a p edávat Ústavu zdravotnických informací a
statistiky (ÚZIS) v rámci p edávání informací do jednotlivých částí D_II Vyberte
Národního registru reprodukčního zdraví (NRRZ), a to konkrétně P Vyberte
v dokumentech p edávaných do: P Vyberte
P Vyberte
· Národního registru rodiček (NRROD)
· Národního registru novorozenců (NRNAR)
· Národního registru potratů (NRPOT)
· Národního registru vrozených vad (NRVV)
· Národního registru asistované reprodukce (NRAR)
Povinný obsah položek jednotlivých dokumentů je publikován na
webových stránkách ÚZIS v aktuálně platném znění. Uchazeč ve
formulá ích pro zápis informací v rámci jednotlivých typů hlášení
do KIS respektuje i situaci, že u některých položek ve formulá i
ÚZIS je možné vybrat i více než jednu variantu odpovědi, která
k položce pat í. Pokud neexistuje možnost elektronického
p edávání dat rozhraním p ímo do databáze ÚZIS (ať už on-line,
nebo dávkově), KIS vytvo í listinné dokumenty ekvivalentní
tištěným formulá ům od ÚZIS.

KIS_275 Zavatel požaduje, aby bylo možné údaje pro formulá e v rámci
NRRZ p edávat na ÚZIS i elektronickou cestou, je-li pro ně
p ipraveno komunikační rozhraní.

KIS_276 Zejména informace parametrického typu zadaná do IT ešení
porodnictví a neonatologie se elektronicky p enáší již z ambulantní
dokumentace těhotné do porodopisu i zpráv novorozence a
dalších relevantních hlášení vůči ÚZIS. Pediatr pečující o
novorozence má také oprávnění zobrazit a použít v rámci KIS
zdravotní záznamy matky získané p i poskytování zdravotních
služeb pouze na pracovištích oboru gynekologie a porodnictví.
Detailní nastavení bude součástí analytické fáze v rámci
prováděcího projektu.

KIS_277 KIS je p ipraven pro sledování těhotné po celou dobu od koncepce
až do porodu. Tím zadavatel myslí, že automaticky vypočítává
délku gravidity podle kritérií v následující hierarchii:

a) podle výsledku prvotrimestrálního screeningu,
b) není-li položka a) k dispozici, pak podle UZ vyšet ení

v prvním trimestru,
c) není-li položka b) k dispozici, pak podle posledních

menzes.

KIS_278 KIS pro sledování těhotné poskytuje procesní podporu porodníkovi
návrhem termínů povinných prohlídek těhotné s tím, že upozorňuje

55
na povinné složky vyšet ení, které se p i konkrétní návštěvě
v poradně mají provést – tím je nap . UZ vyšet ení plodu
v konkrétním gestačním týdnu, provedení laboratorních testů na
vybrané infekce. Zadavatel upozorňuje, že odborné požadavky na
skladbu vyšet ení těhotné se v čase mění – proces musí být
v čase možné upravovat proškoleným zaměstnancem zadavatele.

KIS_279 U patologických těhotenství se st edním a vysokým rizikem je
volba odstupů jednotlivých ambulantních návštěv individuální – tj.
porodník musí mít možnost volit termíny dalších kontrol dle svého P Vyberte
uvážení s podporou kalendá e, ve kterém bude objednávat další
kontroly.

KIS_280 U fyziologických těhotenství probíhá do 36. týdne těhotenství
sledování v intervalu 4-6 týdnů – zadavatel očekává, že systém
v plánovacím kalendá i bude nabízet k objednání termíny v tomto
odstupu. Od 37. týdne těhotenství probíhá sledování v intervalu 1 P Vyberte

týdne - zadavatel očekává, že systém v plánovacím kalendá i
bude nabízet k objednání termíny v tomto odstupu.

KIS_281 Procesní podpora sledování těhotné musí parametrickým P Vyberte
způsobem umožňovat zadání četnosti plodů – nap . dvojčata,
trojčata.

KIS_282 Procesní podpora sledování těhotné musí parametrickým P Vyberte
způsobem umožňovat zadání četnosti placent, pole je označeno
slovem „chorionicita“.

KIS_283 Procesní podpora sledování těhotné musí parametrickým P Vyberte
způsobem umožňovat zadání četnosti žloutkových váčků, pole je
označeno slovem „amnionicita“.

KIS_284 KIS umožňuje strukturovaný odběr anamnézy těhotné v souladu
s popisem položek v kapitole ambulantní vyšet ení včetně
následujících položek:

· povolání rodičky v prvním trimestru – volný text,
· průběhu těhotenství – volný text,
· výsledků vyšet ení, konkrétně :
o krevní skupiny a Rh faktoru – parametrický údaj,
o BWR – parametrický údaj;
o HBsAg – parametrický údaj;
o HIV – parametrický údaj;
o screening GBS (kolonizace streptokoky skupiny B)
– parametrický údaj;
o ultrazvuk v I. trimestru – okno volné ho textu;
o ultrazvuk v II. trimestru – okno volné ho textu;
o ultrazvuk ve III. trimestru (30.-32. gestační týden) P Vyberte
– okno volného textu
o prvotrimestrální screening – okno volného textu;
o invazivní prenatální diagnostika včetně jejího
druhu – okno volného textu;
o karyotyp – okno volného textu;

· farmakologické anamnézy zaznamenatelné stejným
způsobem, jak je popsáno v kapitole lůžkového oddělení,
záznam farmakologické anamnézy se rozděluje na léky
užívané v prvním trimestru, na léky užívané v druhém
trimestru a léky užívané ve t etím trimestru + za porodu,

· informací o otci, je-li znám, včetně jeho povolání a
kontaktu na něj, nap . telefonu – okno volného textu;
Tyto informace jsou v rámci KIS p enášeny do porodopisu, zprávy
o novorozenci, chorobopisu novorozence (v p ípadě

56
novorozenecké patologie a navazující hospitalizace na
neonatologickém oddělení), chorobopisu rodičky (v p ípadě
patologie těhotenství). Pediatr aktuálně pečující o novorozence
má prost ednictvím KIS zp ístupněno nahlížení a p enos informací
ze zdravotnických záznamů matky pocházejících výhradně z
pracovišť porodnicko-gynekologické odbornosti do dokumentace
novorozence.

KIS_285 P i zakládání dalších dokumentů, nap . hlášenka vrozené vývojové
vady – VVV, geneticky podmíněného onemocnění - GPO, listu o
prohlídce zem elého, poskytne KIS podporu p enesením také D_II Vyberte
následujících známých parametrů: D_II Vyberte

· identifikace za ízení: IČO/PČZ/oddělení
· jméno, p íjmení, RČ event. IČ dítěte i matky,
· porodní hmotnost,
· porodní délka,
· gestační týden p i porodu/potratu,
· pohlaví,
· státní občanství,
· datum narození,
· datum úmrtí,
· informace o provedené invazivní prenatální diagnostice

(p inejmenším formát ano/ne) a dopsání metody nebo lépe
strukturovaně parametricky jako v hlášence VVV (metody,
vyšet ení);
· Asistovaná reprodukce

KIS_286 KIS nabídne podporu pro vyplnění formulá ů p i
prenatálně/postnatálně diagnostikované VVV či GPO (následuje
citace položek ve formulá i ÚZIS):

· Zjištění VV_GPO
· Těhotenství
· Dokončený týden těhotenství p i zjištění VV_GPO
· Ukončení těhotenství
· Spontánní potrat
· Zjištění VV_GPO
· Rodné číslo dítěte
· Státní občanství
· Porodní hmotnost v gramech
· Porodní délka v cm
· Datum úmrtí
· Výsledek těhotenství
· Pohlaví
· Prenatální diagnostika
· Prenatální diagnostika invazivní
· Metoda
· Vyšet ení v rámci invazivní prenatální diagnostiky
· Po adí gravidity
· Po adí parity
· Počet p edcházejících samovolných potratů
· Počet p edcházejících umělých ukončení těhotenství

(UUT)
· Dokončený týden těhotenství
· Četnost těhotenství
· Dvojčata
· Číslo obce bydliště matky v době porodu nebo obce

bydliště pacienta – KIS dodá automaticky p i zadání
bydliště

57
· Číslo kraje a okresu (NUTS3 a NUTS4) – KIS dodá
automaticky p i zadání bydliště

· Číslo obce s rozší enou působností (ORP) – KIS dodá
automaticky p i zadání bydliště

· vrozená vada v rodině - diagnóza vrozené vady u
postiženého (MKN-10)

KIS_287 Ve formulá i VVV je kromě parametrického a textového pole
diagnózy podle MKN-10 pot eba vytvo it parametrická pole pro:
D_II Vyberte
· diagnózu. dle Orpha number Orphanetu P Vyberte
· diagnózu dle Online Mendelian Inheritance in Man (OMIM)
· diagnózu dle Society for the Study of Inborn Errors of

Metabolism (SSIEM)

KIS_288 Aktuálně platná zpráva o novorozenci je dostupná na
https://www.uzis.cz/system/files/dokumenty/hlasenka_NRNAR_15_02.pdf
Body týkající se zprávy o novorozenci:
Identifikace za ízení

§ zpráva číslo
§ číslo dítěte/chorobopisu
§ identifikace za ízení: IČO/PČZ/oddělení
1. Údaje o novorozenci

§ rodné číslo novorozence
§ rodné číslo matky
§ státní p íslušnost

§ četnost těhotenství
§ po adí

§ rok narození otce

§ číslo obce bydliště matky – automaticky p i zadání bydliště
§ číslo obce s rozší enou působností – automaticky p i

zadání bydliště
§ číslo kraje a okresu – automaticky p i zadání bydliště
2. Údaje z porodního sálu

§ porod

§ způsob porodu
§ způsob vaginálního porodu
§ poloha plodu

§ datum narození

§ vitalita

§ pohlaví

§ porodní údaje - hmotnost (g)

§ porodní údaje - délka (cm)

§ porodní údaje - gestační stá í
§ léčba na sále
§ Apgarové skóre (1., 5.,10. minuta)

3. Údaje z oddělení
§ datum a čas p ijetí dítěte na oddělení
§ léčba
§ počet dní na UPV
§ operační Dg.
§ vybrané nemoci a komplikace

§ vitamin K

58
§ provedený screening

§ vrozená vada

§ diagnózy vrozené vady (kód MKN-10)

4. Informace o propuštění dítěte
§ datum a hodina ukončení Zprávy o novorozenci (ZN)
§ hodnoty p i propuštění - hmotnost (g)
§ hodnoty p i propuštění - obvod hlavy (cm)
§ výživa

§ důvod ukončení Z.
§ důvod ukončení ZN - p eklad - IČO, PČZ za ízení a oddělení
§ důvod ukončení ZN - úmrtí - p íčina
§ další diagnózy (MKN-10) - p i propuštění, p ekladu, úmrtí.

KIS_289 KIS umožňuje zadání informací o očkování – parametrické okno
pro název očkovací látky, číslo šarže a pro datum vakcinace. Okno
pro záznam musí být dostupné pro očkování provedené na
kterémkoli z pracovišť zadavatele; zdravotníci zadavatele jsou P Vyberte
povinni jej použít. KIS může umožnit zadat i výše uvedené údaje
pro očkování provedená jinými poskytovateli zdravotních služeb,
pokud jsou všechny pot ebné informace známé.

KIS_290 KIS v průběhu po izování porodnické dokumentace žádným P Vyberte
způsobem neblokuje neonatology a dětské sestry v práci se
záznamy novorozence.

KIS_291 Zadavatel požaduje, aby v průběhu porodu v elektronických
záznamech rodičky porodník anebo porodní asistentka po
narození dítěte založil jeho záznam v KIS. Tím je zajištěno
jednoznačné propojení matky a dítěte. Další práci se záznamy
novorozence provádí neonatolog a dětské sestry. Založení P Vyberte

záznamu novorozence není omezeno vyplněním kompletní
anamnézy matky, tato aktualizace dat může být provedena
dodatečně.

KIS_292 KIS umožňuje rovněž možnost založení čistě novorozenecké
dokumentace zdravotníky Dětské kliniky p i p ijetí novorozence po
p evozu od jiného poskytovatele na oddělení Dětské kliniky;
součástí této dokumentace se rovněž musí stát informace o matce P Vyberte

a otci (jsou-li známé) s ohledem na povinnost vykazování hlášení
ÚZIS.

KIS_293 Založení záznamu novorozence není omezeno počtem (vícečetná P Vyberte
těhotenství).

KIS_294 KIS umožňuje vést porodopis nezávisle na množství údajů, které
zadavatel znal o rodičce p ed začátkem porodu. Zadavatel tímto
bodem myslí, že porodopis lze založit rodičce, která:
· nikdy nebyla vyšet ována na pracovištích zadavatele a
p ijíždí porodit (tj. jedná se o první kontakt s porodnicí
zadavatele), P Vyberte

· byla pravidelně sledována v perinatologické poradně
zadavatele a p ijíždí porodit do porodnice zadavatele,

· je hospitalizována na kterémkoli oddělení zadavatele
libovolně dlouhou dobu a porod začal.

KIS_295 Zadavatel očekává, že u fyziologického porodu je porodopis a P Vyberte
zpráva o novorozenci finální způsob vedení zdravotnické
dokumentace rodičky a jejího novorozence/-ů. Zadavatel u

59
patologických těhotenství a porodů požaduje možnost založit
rodičce anebo novorozenci/novorozencům chorobopis v p ípadě
porodnické či neonatologické patologie. Pak porodopis a zpráva o
novorozenci splní svou roli statistických výkazů a jejich tvorba
v KIS nesmí být znemožněna.

KIS_296 KIS v záznamu o novorozenci umožňuje zadávat parametrickým
způsobem povinné položky včetně Apgar skóre v 1., 5. a 10.
minutě. Zadání Apgar skóre probíhá ve všech hodnocených P Vyberte
znacích a KIS počítá finální hodnotu. P Vyberte

KIS_297 Pokud ve formulá ích porodopisu, zprávy o novorozenci, hlášení o P Vyberte
potratu nebo ve formulá i hlášení vrozených vývojových vad je P Vyberte
t eba zvolit kód diagnózy podle MKN-10, zadavatel požaduje D_II Vyberte
možnost zúžit výběr diagnóz pouze na relevantní kapitoly
klasifikace (nap . počínající písmenem O, P, Q, E).

KIS_298 KIS musí být p ipraven na p edání agendy porodu mezi směnami
zdravotníků – vlastní děj může probíhat až 24 hodin a zdravotníci
se vyst ídají. Musí být umožněno podepsání dokumentace
v okamžik odchodu p edávající porodní asistentky anebo léka e a
zároveň plynulé navázání ve vedení dokumentace p ebírajícím
léka em anebo porodní asistentkou.

KIS_299 KIS porodníka automaticky upozorní na nevyplněné údaje v
porodopisu p ed limitem 24h.

KIS_300 Zadavatel požaduje podporu vedení utajovaného porodu v souladu
se zákonem. Způsob ešení navrhne uchazeč. P edpokládáme, že
bude možnost založení porodopisu bez udání jména a ostatních
identifikátorů rodičky p i žádosti o utajovaný porod.

2.2.4 Procesní podpora sledování nozokomiálních nákaz a podpory oddělení
nemocniční hygieny

KIS_301 KIS zabezpečuje zápis údajů o vzniku, průběhu nozokomiální
nákazy a povinné zaevidování v chorobopisu pro pot eby vnit ních
analýz FNHK a hlášení na hygienickou službu a ÚZIS (Hlášení P Vyberte
NN). Kromě toho je KIS prost ednictvím formulá e schopen vytvo it P Vyberte
listinné Hlášení infekční nemoci (DITIS 1130230). Vyplněné údaje D_II Vyberte
KIS p edá oddělení nemocniční hygieny.
P Vyberte
KIS_302 IT ešení je dostupné v ambulancích i na lůžkových odděleních,
dále má svou manažerskou část pro oddělení nemocniční hygieny
a vedoucí pracovníky.

KIS_303 Podpora evidence nozokomiální nákazy p i prohlížení výsledků
kultivace z oddělení mikrobiologie – p i pozitivitě nálezu p i
prohlížení výsledku má léka možnost otev ít formulá Hlášení
infekční nemoci; léka i zůstává možnost záznamy editovat.

KIS_304 · Nutná evidence p íznaku epidemiologické pozitivity u
konkrétních pacientů s tím, že tato skutečnost bude v
průběhu vytvá ení pacientské dokumentace zobrazena
formou informačního okna p i každém p ihlášení
zdravotníka do KIS a zahájení práce s takto označeným
pacientem - tzv. „Infekční pacient“.

· Okno s informací o epidemiologickém riziku pacienta se
zobrazí konkrétnímu zdravotníkovi vždy jen p i prvním
zahájení prací s pacientem v daném kalendá ním dnu.

60
· Možnost měnit údaje o pacientovi omezena p ístupovými
právy pouze na útvar nemocniční hygieny.

KIS_305 IT ešení musí umožnit zobrazit historii hlášení infekčního
onemocnění a nozokomiální nákazy vůči oddělení nemocniční
hygieny včetně data, nemocnice jako celku, jednotlivých P Vyberte
výkonových st edisek. P Vyberte
P Vyberte
KIS_306 Nad daty oddělení nemocniční hygieny jsou funkční obecně P Vyberte
dostupné reportovací nástroje KIS včetně možností tisku a exportu
výstupů v elektronické formě pro oddělení jako takové, ale i pro D_II Vyberte
jednotlivá výkonová st ediska a oddělení ízení kvality a kontroly.
D_II Vyberte
KIS_307 Možnost dalších statistických výstupů - parametrické zadání
(lůžka, pokoje, agens apod.).

KIS_308 IT ešení pro oddělení nemocniční hygieny má p ehled hlášených
infekčních onemocnění a nozokomiálních nákaz, který je vybaven
filtry a dalšími funkcemi pro azení jednotlivých záznamů
minimálně podle kultivačního výsledku, data zjištění infekce, data
hlášení infekce.

KIS_309 Zadavatel informuje uchazeče o dosavadní praxi práce oddělení
nemocniční hygieny (ONH), která může být zachována i v rámci
poptávaného ešení: Ústav klinické mikrobiologie z laboratorního
systému OpenLIMS jedenkrát denně provede export definovaných
nálezů (definice je již v OpenLIMS zadána) a musí zůstat dostupná
historie mikrobiologických výsledků pro pot eby ONH. Zadavatel
p ipouští i jiné, funkčně lepší ešení s dosažením stejného cíle.

KIS_310 Zadavatel požaduje možnost exportu vybraných hlášení o
infekčních onemocněních i mimo FN HK pro pot eby ÚZIS nebo
orgánu ochrany ve ejného zdraví v p ípadě existence datového
rozhraní.

2.2.5 Operační sály

KIS_311 IT podpora procesu umožní plánování programu operačních sálů
v obou režimech:
I. Režim perspektivního plánování operace: S p edstihem
v délce dnů až měsíců umožní plánovat operační výkony,
míra detailu může být až na konkrétní operační sál;
v rámci plánu je uvedeno p íjmení pacienta, další
identifikátor (optimálně číslo pojištěnce), diagnóza, typ
plánovaného operačního výkonu, čas výkonu, ASA
klasifikace, jméno indikujícího léka e. Alergie nap . na kov
(vhodné).
II. Režim detailního plánování operace: S p edstihem
jednotek dnů až hodin umožní do detailu naplánovat P Vyberte
operační výkon prostým p etažením z perspektivního
plánování myší a doplněním údajů; kromě identifikace
pacienta (kde leží), je potvrzena či doplněna diagnóza,
plánovaný typ operace, stanoven operatér (optimálně celý
tým) a anesteziolog, sál určený po operaci a čas výkonu.
Součástí detailního plánování je i vystavení požadavků na
dodání materiálu z oddělení centrální sterilizace anebo
sálového zázemí (nap . implantabilní zdravotnické
prost edky, osteosyntetický materiál). Je vhodné uvést
důležité atributy o pacientovi, zejména pak p ítomné
infekce (hepatitidy, multirezistentní kmeny), další

61
podstatné faktory (nap . odmítání podání krevních derivátů
u svědků Jehovových, existence d íve vyslovených p ání
pro p ípad komplikací výkonů – nap . odmítnutí
resuscitace).

KIS_312 Minimální sada informací, kterou je možné zadat/volit v průběhu
plánování operace na konkrétní den a hodinu v parametrizovatelné
formě (číselníkové položky,…):

· identifikace pacienta min. jménem a p íjmením, číslem

pojištěnce, pop . datem narození, kde leží p ed operací a
kam půjde po operaci

· diagnóza, poloha pacienta, typ a čas operačního výkonu

· operatér – provazba na personální strukturu nemocnice

· ostatní členové operačního týmu – provazba na personální

strukturu nemocnice

· „konziliární“ operatér – operatér jiného oboru, který se

podílí na operaci, provazba na personální strukturu

nemocnice

· hostující členové operačního týmu – (nap . operaté i

z ciziny, stážisté, studenti)

· instrumentá ka P Vyberte
· obíhající sestra

· anesteziolog, provazba na personální strukturu nemocnice

· typ anestezie, pot eba anesteziologické p ípravy

· anesteziologická sestra, provazba na personální strukturu

nemocnice

· požadavky na zdravotnické prost edky k operaci (nap .

kloubní náhrady, chlopenní náhrady,…) či speciální

nástroje

· požadavky na dodávku sterilního materiálu z centrální

sterilizace

· p enesení informace o známých alergiích pacienta –

propojení na alergickou anamnézu

· plánované požadavky na transfuzní p ípravky

· údaj hygienicko-protiepidemické povahy (nap . MRSA,

osídlení multirezistentním patogenem)

· poznámka, okno volného textu

KIS_313 Musí být možnost zadat informace o použitých zdravotnických P Vyberte
prost edcích (zejména t ídy IIb a III), a to snímáním kódů čtečkou
(čárové kódy, QR kódy) nebo snímáním RFID čipů.

2.2.5.1 Požadované pohledy

Pohled primáře oddělení centrálních operačních sálů:

KIS_314 Zobrazuje plán operačních sálů po jednotlivých kalendá ních P Vyberte
dnech. Požadovaná je i možnost zobrazení plánovaného obsazení
operačních sálů alespoň v délce pracovního týdne (tj. min. 5 dnů).

KIS_315 Zobrazuje všechny operační sály konkrétního fyzického
operačního traktu (upozorňujeme, že v budoucnu bude mít
největší operační trakt současně 21 operačních sálů) současně, a P Vyberte

to tak, že jednotlivé sály jsou na svislé ose „y“ tabulky operačních

62
sálů. Horizontální osa „x“ zobrazuje čas, vždy je na ní zvýrazněn
aktuální čas. Mě ítko tohoto zobrazení lze plynule měnit tak, aby
primá mohl zobrazit buď všechny sály najednou, anebo detail
výběru sálů včetně podrobností o již provedených, probíhajících a
plánovaných operacích (nap . pomocí nástroje Lupa ve Windows
stiskem Ctrl a otáčením kolečka myši). Zobrazování je možné také
omezit na zadavatelem definovatelné skupiny sálů, které jsou
vyčleněny pro konkrétní odbornosti. Poznámka k odůvodnění
požadavku: Zadavatel plánuje existenci společného traktu celkem
21 operačních sálů.

KIS_316 Je schopen provádět p esuny operačních výkonů prostým
p etažením okna konkrétní operace uvnit plánovacího kalendá e
na jiný sál či jiný čas. Je schopen rušit dosud nezahájené operační
výkony s tím, že operační výkon bude buď zcela smazán bez
náhrady, nebo jej p esune do fronty všech očekávaných
operačních výkonů, které čekají na naplánování konkrétních
detailů operace. Pokud operační výkon odpadne, je t eba uvést P Vyberte

důvod. Je schopen měnit čas začátku první operace v souladu
s požadavky zadávajících operatérů. V p ípadě p idání akutního
výkonu do operačního programu dojde k posunu operací a bude
jasně patrné, které výkony se časově dostávají mimo denní
operační čas.

KIS_317 Primá operačních sálů má možnost blokovat objednávání na
operační sály nap . z důvodů sanitárních dnů. Primá má právo
p idělovat kapacity jednotlivých operačních sálů jednotlivým P Vyberte

klinikám a tím jim zp ístupnit tyto kapacity pro plánování operací.

KIS_318 Primá má oprávnění definovat délky technologických pauz. P Vyberte

KIS_319 V daném čase, který stanoví zadavatel, bude plánování operací
pro léka e chirurgických oborů uzav eno a dále bude mít možnost
vstupu do plánování už jen primá či oprávněná osoba
s p ístupovými právy primá e oddělní centrálních operačních sálů. P Vyberte

Tento mechanismus se bude uplatňovat také mimo ádnou
pracovní dobu, o víkendech a státních svátcích.

KIS_320 Primá může měnit po adí operací s ohledem na jejich urgentnost,
pot ebu protiepidemických opat ení (nap . pacient osídlený
multirezistentním patogenem musí jít jako poslední v plánu na P Vyberte

daném sále).

KIS_321 U každé operace se zaznamenávají následující časové údaje:
· p edání na sál
· zahájení práce anesteziologa + ukončení jeho práce P Vyberte
· zahájení práce chirurgického týmu
· čas ezu
· čas ukončení operace
· čas p edání ze sálu

Pohled plánujícího operatéra (primář operačního oboru nebo pověřená osoba)

KIS_322 Zobrazuje plánovací kalendá s výběrem těch sálů, do jejichž
plánování má konkrétní operatér konkrétní odbornosti p idělena
p ístupová práva. V plánovacím kalendá i se seznamem sálů na
ose svislé a časem na ose horizontální do jednotlivých oken P Vyberte
plánuje operační výkony se zadáním identifikačních údajů
pacienta, typu a délky trvání výkonu, uložení pacienta p ed a po
výkonu, operačního týmu. Ší e okna v horizontální ose udává

63
plánovanou (odhadovanou) délku operačního výkonu. Za každou
provedenou operaci KIS p idá časový úsek tzv. technologické
pauzy, jehož délku může zadavatel měnit. Plánování operací
pouhým p etažením z perspektivního plánování myší nebo
vyplněním údajů v KIS nedovolí plánujícímu operatérovi p ekročit
délku plánovaného provozu operačního sálu v daný den; takové
p ekročení kapacity je umožněno pouze osobě s právy primá e
oddělení operačních sálů.

Pohled anesteziologa

KIS_323 Léka odpovědný za plánování anesteziologických služeb má
právo náhledu na vznikající plán operací kdykoli v průběhu jeho
sestavování; náhled je pro něj uzamčen pro úpravy až do P Vyberte

okamžiku uzav ení plánu operací.

KIS_324 Po uzav ení plánu operací se zobrazí plán léka i odpovědnému za
plánování anesteziologických služeb pro oddělení operačních sálů
v editovatelné formě. Anesteziolog má možnost jednotlivým sálům
p idělit anesteziologické týmy, p ípadně zasáhnout do časování
výkonů úpravou času začátku prvního výkonu, kde vyžaduje pro
zabezpečení anesteziologického servisu delší čas (nap . situace
s kompletním zajištěním vstupy). U každého výkonu KIS nabízí P Vyberte
samostatné anesteziologické okno s parametrickými položkami,
kde je časově vymezena p íprava, tj. její p edpokládaná délka a
obsah (nap . žilní vstup, arteriální vstup, obtížná intubace),
p ípadně další specifika (do okna volného textu); okno je viditelné i
pro chirurgy. Po zadání těchto úprav se plán operací vrací
k definitivnímu schválení primá i oddělení operačních sálů.

KIS_325 IT ešení procesu práce anesteziologa obsahuje i
anesteziologického okno pro zobrazování rizik. Do tohoto okna
dochází k p enosu parametrických informací o alergii z časově
poslední dokumentace v KIS lůžkové nebo ambulantní. Do tohoto
okna dochází také k p enosu informace z p íslušného oddílu rizik P Vyberte

ambulantní dokumentace anesteziologické ambulance, okno pro
záznam volného textu (nap . obtížná intubace, maligní
hypertermie).

2.2.5.2 Administrativa operačních sálů - operační protokol a žádanky

KIS_326 Detailní rozčlenění údajů o operaci mezi léka ský operační
protokol a sesterský operační protokol bude stanoven
v p ípravném projektu. Sesterský operační protokol bude mít vždy D_II Vyberte
listinnou podobu, protože slouží jako prostor pro umístění
samolepících štítků od zdravotnických prost edků a sterilního P Vyberte
materiálu. P Vyberte
P Vyberte
KIS_327 Šablona léka ského operačního protokolu obsahuje automaticky
p enesené informace z plánování operace + automaticky doplněné
časy + informace o relevantních zdravotnických prost edcích,
kterými je sál vybaven.

KIS_328 Editace operačního protokolu operatérem nesmí zablokovat práci
ostatních zdravotníků v jiných částech KIS p i ošet ování pacienta
– nap . tvorbu dekurzů a jiných částí dokumentace na dospávacím
pokoji či na JIP.

KIS_329 P ed zahájením psaní operačního protokolu se KIS dotáže

64
operatéra, jestli v průběhu operace odebral materiál na patologické
či jiné laboratorní vyšet ení. Odpoví-li ANO, pak KIS nabídne
nejd íve vyplnění všech pot ebných žádanek. V ešení operačních
sálů musí být zp ístupněna zejména žádanka na patologické
vyšet ení (specifikovaná v sekci dokumentace patologie), dále na
mikrobiologii, ale obecně na jakékoli pot ebné komplementární
vyšet ení. Z operačního sálu je možné vystavovat v KIS také
žádanky na transfuzní p ípravky. Pokud vznikne žádanka na
komplementární vyšet ení, stává se p ílohou operačního protokolu
– je k němu p ipojena do jednoho dokumentu.

KIS_330 Operační protokol je dokument, u kterého KIS kromě tisku umožní
i vznik plnohodnotného elektronického dokumentu podepsaného
kvalifikovaným elektronickým podpisem s kvalifikovaným časovým
razítkem. KIS využívá systém dvoustupňové kontroly; v p ípadě P Vyberte

elektronické verze dokumentu by podepisoval až léka se
specializovanou způsobilostí.

KIS_331 Operační protokol ve své části léka ské a sesterské bude finálně
nastaven v průběhu analytické fáze prováděcího projektu; má
alespoň tyto oddíly:
· hlavičku s parametrizovatelnými údaji označující
minimálně sál, pracoviště operatéra, identifikaci pacienta,
datum, název operační diagnózy s kódem MKN-10,
· parametrizovatelné okno pro zadání názvu operace,

· parametrizovatelný oddíl pro záznam jmen operatéra,
asistencí, instrumentá ky, obíhací sestry, sanitá e,
hostujícího operatéra jiného oboru (je-li p izván), dalších
osob p ítomných operaci

· parametrický oddíl, do kterého budou p eneseny výše
uvedené sledované časové údaje o průběhu operačního
výkonu,

· textové okno pro záznam průběhu operace – není P Vyberte
omezeno délkou, volný text,

· oddíl pro dokumentaci použití ionizujícího zá ení
v průběhu operace dle požadavku radiologů (výška a
hmotnost pacienta, dávka – specifikaci dokončí Mgr.
Storm)

· automaticky ukládaný časový údaj vzniku operačního
protokolu,

· parametrizovatelné okno pro zadání identifikace operatéra
(provazba na seznam zaměstnanců nemocnice).
· možnost p ipojit binární soubor – fotografie z fotoaparátu,
statické snímky z endoskopických p ístrojů
· pokud byla vystavena žádanka na patologii, mikrobiologii,
p ipojí se jako součást operačního protokolu
· seznam použitých zdravotnických prost edků alespoň t ídy
IIb a III.
Operační protokol umožní dokumentovat i výměnu personálu
v průběhu operace způsobenou st ídáním směn (běžné u
anestézie, obíhací sestry, instrumentá ky atp.).

2.2.6 Ošetřovatelská dokumentace v KIS
Formulá e zobrazené v zadávací dokumentaci zadavatel na vyžádání uchazeče
poskytne v originální velikosti. Veškeré tisky formulá ů prost ednictvím KIS musí být
ve stupních šedé, nikoliv barevně.

65
P estože listinných vzorů je více, v realitě se velké množství parametrických údajů
opakuje, tj. není t eba vytvá et mnoho rozsáhlých formulá ů, ale spíše základ
s modifikacemi dle pot eb konkrétních typů oddělení, tj. standardní versus JIP,
oddělení dospělých versus oddělení novorozenecké.

Výsledné tisky vyplněných parametrických údajů v jednotlivých formulá ích pak
nemají obsahovat všechny možnosti zobrazené na papírových formulá ích, ale
tisknout se budou pouze ty hodnoty, které byly p ijímající sestrou zvoleny. Pozor na
fakt, že u některých položek p ipadá do úvahy vždy jen jedna zadaná hodnota (nap .
bodové hodnoty v položkách skóre), ale u jiných položek může sestra současně
vybrat hned několik vhodných variant (nap . kompenzačních pomůcek může mít
pacient více – brýle, sluchadlo, hůl).

Všude tam, kde se v ošet ovatelské dokumentaci objevuje obrázek lidské postavy,
zadavatel neočekává pot ebu zakreslovat skutečný rozsah poškození kůže a tkání.
Zadavatel požaduje pouze bodové označení místa poškození kůže a tkání s dalším
popisem rány mimo obrázek.

2.2.7 Základní ošetřovatelské složky

Ošetřovatelský příjem

KIS_332 IT ešení ošet ovatelského procesu v KIS musí být k dispozici p i
p íjmu pacienta. K datu podání nabídky musí mít uchazeč
k dispozici Ošet ovatelský p íjem - standardní oddělení viz obrázek P Vyberte
1, obrázek 2 D_II Vyberte

KIS_333 IT ešení ošet ovatelského procesu musí disponovat minimálně
parametrickými položkami s nabídkami variant odpovědí
obsaženými v následujících formulá ích, dle pot eb zadavatele
budou některé položky vybaveny kontrolními body s vynucením
odpovědi, nap . sonda, pumpa, stomie, Kůže/Dekubity,
kompenzační pomůcky, invazívní vstupy (optimální způsob
vyplňování buď zaškrtávání polí anebo výběry z rozbalovacích
číselníků):

· Ošet ovatelský p íjem - standardní oddělení viz obrázek 1,
obrázek 2

· Ošet ovatelský p íjem – oddělení JIP viz obrázek 3,
obrázek 4

· Ošet ovatelský p íjem (varianta pro věkové rozmezí děti 0
– 2 roky, děti 2 roky a více) viz obrázek 6, obrázek 7,
obrázek 8

· Ošet ovatelský p íjem JIRP pro novorozence, IMP nov. viz
Obrázek 9,Obrázek 10.

66
Obrázek 1 k požadavku OŠP KIS_333

Obrázek 2 k požadavku OŠP KIS_333

67
Obrázek 3 k požadavku OŠP KIS_333

Obrázek 4 k požadavku OŠP KIS_333.

68
Obrázek 5 k požadavku OŠP KIS_333.

Obrázek 6 k požadavku OŠP KIS_333.

69
Obrázek 7 k požadavku OŠP KIS_333.

Obrázek 8 k požadavku OŠP KIS_333

70
Obrázek 9 k požadavku OŠP KIS_333.

Obrázek 10 k požadavku OŠP KIS_333.

71
KIS_334 Požadavky na parametrizaci a funkcionalitu minimálně na úrovni:
· Výživa – metabolismus

o P ijímání potravy – sonda, pumpa, stomie a
přenesení parametrické info do Záznamového listu do
položky „Invazívní vstupy“)

o Kanyla – NE, ANO + parametrické okno s nabídkou
číselné hodnoty hodnocení v rozsahu 0-5 viz obrázek
11 a přenesení parametrické info do Záznamového
listu do položky „Invazívní vstupyi“)

o Dekubity – NE, ANO (ANO - odkaz na hodnocení
rizika vzniku dekubitů – stupnici Nortonové +
spočítání, přenesení parametrické info do
Záznamového listu/Péče o ránu a Zhodnocení a péče
o rány, dekubity a jiné kožní defekty, možnost
bodového označení tělesné krajiny a možnost
připojení pomocí binárního souboru fotografie

· Bolest – MÁ, NEMÁ, ( v p ípadě MÁ zadat včetně
inetinzity VAS:…../ 4 (přenesení parametrické info do
Záznamového listu do položky „Bolesti“)

· Sreeningové vyšet ení

o Test základních všedních činností ADL - p i označení
jednotlivých hodnocených ukazatelů ve formulá i
automatické spočítání parametrického údaje, nabídka P Vyberte

aktuální ošet ovatelské kategorie pacienta a

přenesení parametrické info do Záznamu vývoje
stavu pacienta/ ošetřovatelská kategorie)
P epracovaná stupnice Nortonové - p i označení
jednotlivých hodnocených ukazatelů ve formulá i
automatické spočítání parametrického údaje a
přenesení parametrické info do Záznamu vývoje
stavu pacienta do položky „Hodnotící škály/ Riziko

dekubitů“.
o Zhodnocení rizika pádu u pacienta - p i označení
jednotlivých hodnocených ukazatelů ve formulá i
automatické spočítání parametrického údaje a
přenesení parametrické info do Záznamu vývoje
stavu pacienta do položky „Hodnotící škály/Riziko

pádu“.

o Nutriční screening – automatické spočítání BMI,p i
zjištění problémů a označení jednotlivých
hodnocených ukazatelů ve formulá i automatická
informace pro léka e, nabídka nutričního sledování
pacienta v Záznamovém listu P íjem – Strava a

přenesení parametrické info do Záznamu vývoje
stavu pacienta do položky „Hodnotící škály/Nutriční
screening“.

o další požadované specifické škály dle oborů a
modifikované formulá e ošet ovatelského p íjmu pro

dospělé, pro děti 0-2 let, intenzivní péči o
novorozence a intenzivní péči o dospělé – obrázky

72
viz výše

· Vybrané parametrické údaje po ízených zdravotní sestrou
p evést i do anamnézy léka e, pop . zpětně (nap .
hmotnost, výška ve smyslu změ ená, nebo odhadnutá
analogicky tomu, jak má být zadávána v léka ském p íjmu
v procesech lůžkového oddělení.

· Po vyplnění ošet ovatelské anamnézy a vygenerování
problémů pacienta automatické p enesení parametrických
informací zjištěných problémů pacienta do
Ošet ovatelského spisu.

· Na základě zjištění sociální anamnézy Sociální oddělení
kontaktovat NE / ANO – následná nabídka žádanky na
sociální oddělení

KIS_335 Systém umožní po vyplnění oblastí Výživa – metabolismus,
Vylučování - vyměšování, Pohybová aktivita, Spánek – únava,
Bolest, Vnímání – komunikace, Stres, zátěžové situace
Kompenzační pomůcky, Invazívní vstupy, Sociální oddělení a
zjištění patologií (pravý sloupec obrázku 1) automatické p ebírání P Vyberte

zaznamenaných údajů problémů pacienta do Dalších zjištěných
údajů/Stručný souhrn v Ošet ovatelském p íjmu. Do datového
pole Stručný souhrn je možné umožnit i volný text.

Obrázek 11 k požadavku OŠP KIS_334.

Záznam vývoje stavu pacienta

KIS_336 KIS bude pro konkrétního pacienta umožnovat tisk formulá ů ve
stupnici šedé 1x denně s p edvyplněnými informacemi pro
následujících 24 hodin. Zadavatel p ipouští i variantu, kdy zápisy D_II Vyberte
vývoje stavu pacienta budou po izovány elektronicky do systému D_II Vyberte
průběžně s vytištěnou identifikací sestry p ihlášené do KIS a tisk
kompletní za 24 hodin.

KIS_337 Součástí jednodenního dokumentu budou základní informace o
pacientovi, sledované v KIS minimálně v rozsahu:

· operační den, hygienický režim
· hodnotící škály – možnost denního p ehodnocení, pop .

73
signalizace p ehodnocení 1x za 7 dní (riziko pádu, riziko
dekubitů včetně možnosti doplnění prováděné prevence,
nutriční screening), ošet ovatelská kategorie – dle
soběstačnosti pacienta a dle psychického stavu.
· vygenerování základních známých problémů pacienta s
možností editace

KIS_338 KIS bude disponovat strukturovaností dat, aby bylo možné
sledovat parametrizované údaje vyskytující se v následujících
formulá ích: D_II Vyberte

· Záznam stavu pacienta standardní oddělení viz obrázek
12

· Záznam stavu pacienta JIP viz obrázek 13
· Záznam vývoje stavu pacienta, kde pro psaní záznamů

na směnu bude velikost polí dynamická včetně
dynamického tiskového formulá e viz obrázek 14.
· Záznam stavu pacienta – psychiatrický pacient denní
záznamy viz obrázek 15
· Záznam stavu pacienta – psychiatrický pacient týdenní
záznamy viz obrázek 16 a obrázek 17
· Záznam stavu JIRP novorozenci viz obrázek 18
· Záznam vývoje stavu dětský pacient viz obrázek 19

Obrázek 12 k požadavku OŠP KIS_338

74
Obrázek 13 k požadavku OŠP KIS_338

Obrázek 14 k požadavku OŠP KIS_338

75
Obrázek 15 k požadavku OŠP KIS_338

Obrázek 16 k požadavku OŠP KIS_338.

76
Obrázek 17 k požadavku OŠP KIS_338

Obrázek 18 k požadavku OŠP KIS_338.

77
Obrázek 19 k požadavku OŠP KIS_338
KIS_339 KIS bude umožnovat bodového označení defektu na postavě a

obličeji v záznamu o stavu JIRP novorozenec včetně možnosti
p ipojení fotodokumentace

D_II Vyberte

Záznamový list

KIS_340 Pro standardní oddělení bude KIS umožnovat sledování
fyziologických funkcí 5 krát denně s možnosti grafického zobrazení
trendů (cílem je eliminace dosud užívané listinné teplotní tabulky), D_II Vyberte
p íjem a výdej tekutin. Grafické zobrazení trendů zvolených D_II Vyberte
parametrických číselných údajů umožní i náhled na zvolené
fyziologické veličiny v intervalu i několika dnů (rozsah alespoň 5,
optimálně neomezeně dnů, budou-li k dispozici údaje).

KIS_341 Pro standardní oddělení bude KIS umožnovat sledování
hodnocení bolesti, polohování, péče o ránu (orientační i podrobné
hodnocení), odsávání, sledování stravy, hodnocení invazívních
vstupů, hodnocení stavu p i fyzickém omezení. Zadavatel
požaduje i možnost rozší ení o další sledované oblasti formou

78
parametrických údajů vzhledem k oboru, nap . kontrola ozev
plodu. Grafické zobrazení trendů zvolených parametrických
číselných údajů umožní i náhled na zvolené fyziologické veličiny
v intervalu i několika dnů (rozsah alespoň 5, optimálně neomezeně
dnů, budou-li k dispozici údaje – pot ebné zejména p i sledování
trendu vývoje tělesné teploty a hmotnosti).

KIS_342 Pro JIP, KARIM bude KIS disponovat p ehledem po 1 hodině -
mě ení vitálních hodnot, podávání medikací, SAS/VAS, bilance
tekutin od 7 do 6 hodin, polohování, odsávání + p ehled o D_II Vyberte
zavedených invazivních vstupech včetně hodnocení, sledování D_II Vyberte
počtu dnů zavedení jednotlivých vstupů (kanyl, katétrů, elektrod, D_II Vyberte
drénů atp.). Kromě tohoto záznamu na 24 hodin zadavatel
požaduje i možnost zápisu krátkodobého podrobného
monitorování po 5, 10, 15, 20, 30 minutách, pokud v daném dnu
pacient podstoupil operaci nebo intervenci. Zadavatel počítá
zejména s manuálně doplňovanými údaji a nespoléhá na
dostupnost elektronicky p edávaných informací ze zdravotnických
prost edků na JIP.

KIS_343 KIS bude umožnovat propojení záznamového listu s dekurzem
léka e včetně informacích o problému nebo parametrických
údajích.

KIS_344 KIS bude disponovat strukturovaností dat a tiskem formulá ů pro
možnosti sledování údajů definovaných:

· Záznamový list – standardní oddělení viz obrázek 20
· Záznamový list – psychiatrický pacient viz obrázek 21
· Záznamový list – dětský pacient viz obrázek 22
· Záznamový list – DK JIRP NOV viz obrázek ošp 23
· Záznamový list IP viz Obrázek OŠP 24 a obrázek ošp 25

79
Obrázek 20 k požadavku OŠP KIS_344.

Obrázek 21 k požadavku OŠP KIS_344.

80
Obrázek 22 k požadavku OŠP KIS_344

Obrázek OŠP 23 k požadavku KIS_344

81
Obrázek OŠP 24 k požadavku KIS_344

Obrázek OŠP 25 k požadavku KIS_344.

82
Překladová a propouštěcí ošetřovatelská zpráva

KIS_345 Systém bude umožnovat sestrou vybrané získané údaje (ze
Záznamu vývoje stavu pacienta, Záznamového listu či ze
Zhodnocení a péče o rány, dekubity a jiné kožní defekty) p evést D_II Vyberte
do závěrečné zprávy léka e – parametrické údaje formátově D_II Vyberte
ohraničeno

KIS_346 Systém bude procesně orientován s nemožností uzav ít
závěrečnou zprávu léka e, pokud nebudou údaje z dokončené
ošet ovatelské dokumentace p eneseny, editace možná

Požadavky na hodnocení kvality ošetřovatelské péče

KIS_347 Dekubity, riziko vzniku dekubitů (škála Nortové) – sběr
parametrických dat, vyhodnocování a prezentování výsledků,
záznam vývoje dekubitů, vč. možnosti záznamů o použitých D_II Vyberte
zdravotnických prost edcích a možnost získání dat o jejich využití.
KIS podpo í p enesení parametrických dat do systému hlášení D_II Vyberte
dekubitů na národní úrovni, který spravuje ÚZIS. D_II Vyberte
D_II Vyberte
KIS_348 Sledování počtu dnů katétrů (venózní, močové aj.), drenů, pop . D_II Vyberte
dalších invazívních vstupů.
D_II Vyberte
KIS_349 Sledování počtů ošet ovatelských výkonů.

KIS_350 Možnost sledování a vyhodnocení aktuální či průměrné
ošet ovatelské kategorie – za směnu, za den, za měsíc, ¼ roku,
rok na dané pracoviště

KIS_351 Automatické vyplňování ošet ovatelské kategorie s možností
editace – dle zápisů v Ošet ovatelském p íjmu, p i stanovení
problémů pacienta v Ošet ovatelském spisu do Záznamu vývoje
stavu pacienta

KIS_352 KIS umožní sledování problematiky pádů – už uskutečněných
pádů a také počet pacientů v riziku pádu podle parametrického
údaje rizikové škály. KIS bude podporovat p edávání
parametrických údajů do systému hlášení pádů na národní úrovni,
který spravuje ÚZIS.

Další požadavky na složky zdravotnické dokumentace (informace, záznamy sester i
lékařů) dle potřeb pacienta:

KIS_353 Záznam p íjmu stravy, Zhodnocení nutričního stavu léka em:
· propojení s ošet ovatelským p íjmem, p i dosažení skóre
identifikujícího problém – nabídka formulá e Záznam D_II Vyberte
p íjmu stravy, Zhodnocení nutričního stavu léka em
· počítání BMI průběžné p i zadávání aktuálních hodnot
hmotnosti v průběhu hospitalizace nebo v ambulantní
dokumentaci; parametrický údaj
· propojení s dekurzem léka e – možnost pro léka e zobrazit
záznamy o p íjmu stravy zaznamenané sestrami
· údaje ze záznamu o p íjmu stravy musí být k dispozici
také v procesu pro podporu nutričních terapeutek –
optimálně formou zobrazení jako pro léka e
· záznam p íjmu stravy elektronicky pomocí zaškrtávacích
polí v matici stejné jako na obrázku
· zhodnocení nutričního stavu je také uváděno v

83
Ošet ovatelském spisu intenzivní péče – obrázek 13,
Týdenním ošet ovatelském záznamu – obrázek 16,
zadavatel očekává i možnost tisku p ehledu p íjmu stravy
ve vybraném časovém rozmezí
· zhodnocení nutričního stavu léka em viz obrázek 26
pouze elektronicky s parametrickými údaji a výpočtem
skóre
· záznam p íjmu stravy viz obrázek 27 - elektronicky
s parametrickými údaji a výpočtem skóre s i možností tisku
pro listinnou formu dokumentu

KIS_354 KIS umožňuje parametrický záznam hodnot v následujících
formulá ích:
D_II Vyberte
· zhodnocení nutričního stavu léka em viz obrázek 26
· záznam p íjmu stravy viz obrázek 27

Obrázek 26 k požadavku OŠP KIS_354

84
Obrázek 27 k požadavku OŠP 84KIS_354

KIS_355 Hodnocení bolesti (děti do jednoho roku) podle stupnice VAS
· propojení s ošet ovatelským p íjmem, p i problému
nabídne systém škálu pro spočítání skóre, parametrický D_II Vyberte
údaj
· propojení s dekurzem léka e – p enesení hodnoty VAS
· viz obrázek 28.

85
Obrázek 28 k požadavku OŠP KIS_355.

KIS_356 Zhodnocení a péče o rány, dekubity a jiné kožní defekty
· propojení s Ošet ovatelským p íjmem a se Záznamovým
listem/Péče o ránu, p i zjištění/vzniku rány/dekubitu p i KIS D_II Vyberte
nabídne formulá Zhodnocení a péče o rány, dekubity a
jiné kožní defekty
· v nabídce možnost označení lokalizace defektu/-ů bodem
na nákresu postavy, KIS umožní vložení fotodokumentace
· možnost otev ení jednotlivých defektů p es označení v
nákresu postavy
· KIS obsahuje matici parametrických údajů podle obrázku
30 a volné textové okno „Poznámky:“. Podpis NLP je dán
identifikací NLP p ihlášené do systému.
· KIS umožňuje dokumentování více ran/dekubitů spolu se
způsobem ošet ení formou volného textu do pole
Poznámky a s možností signalizace dalšího p evazu
s upozorněním v Ošet ovatelském spise
· Pro jeden dekubit/kožní defekt jeden formulá i
v souhrnném tisku.
· Možnost zobrazit grafický vývoj stupňů jednotlivých
dekubitů v čase, nap . z II. stupně na IV. stupeň.
· Propojení s dekurzem léka e – léka má možnost

86
zobrazení formulá e se záznamy sester v časové ose o
ošet ování dekubitu/rány ((Záznamový liste/Péče o ránu a
Zhodnocení a péče o rány, dekubity a jiné kožní defekty)
· KIS po vyplnění formulá e p i ukončení hospitalizace
umožní jeho tisk do listinné dokumentace - viz obrázek
29.

Obrázek 29 k požadavku OŠP KIS_356

KIS_357 Systém zp ístupní informace z Transfuzního oddělení p i podávání D_II Vyberte
transfuzních p ípravků o deponovaných transfuzních p ípravcích,
délce jejich použitelnosti ve vztahu k provedené k ížové zkoušce.

2.2.8 Ambulance

2.2.8.1 IT ešení procesů na ambulanci a ambulantním pracovišti typu stacioná e
Ambulantní dokumentace

KIS_358 Kromě údajů v MPI bude ambulantní dokumentace obsahovat
možnost použít alespoň výběr z níže uvedených polí pro
následující informace:

· alergickou anamnézu; konkrétní struktura záznamu P Vyberte
alergické anamnézy je specifikovaná v oddílu lůžkové
péče.
· pole volného textu pro varování p ed známými riziky
(latinsky „CAVE“) – nap . upozornění na obtížnou intubaci

87
· ádek s kódem TNM klasifikace s parametrickými poli pro
T–N–M

· ádek s kódem pTpNpM s parametrickými poli pro pT – pN
– pM

· pole dispenzarizace – pole pro kód MKN-10 a volného
textu pro zápis diagnózy k dispenzarizaci, za kterými
navazuje další parametrické pole pro zápis intervalu
kontrol v měsících; po jeho vyplnění KIS bude
v p íslušném odstupu nabízet kalendá pro zadání termínu
p íští kontroly

· pole pro periodické prohlídky v rámci pracovněléka ských
služeb – parametrické pole pro volbu typu rizika
s navazujícím parametrickým polem pro zadání intervalu
kontrol v měsících

· Farmakologickou anamnézu, jejíž záznam včetně formy je
detailně specifikován v kapitole p íjmu pacienta na lůžko.
Farmakologická anamnéza získaná v průběhu
ambulantního ošet ení pacienta je využitelná v rámci KIS
stejným způsobem, jako kdyby byla získána p i p íjmu na
lůžko. Smyslem opat ení je takto parametricky vedený
časově poslední seznam medikace nabízet u
hospitalizovaných pacientů jako nápovědu p i p ípravě
dekurzu (léka bude moci volbu potvrdit/odmítnout/upravit
a p ijmout) a dále bude sloužit jako zdroj parametrických
dat pro perspektivní tvo ení tzv. „pacientského souhrnu“
nap . pro pot eby ešení emergentních situací pro
zdravotnickou záchrannou službu, registrujícího léka e,
ostatní poskytovatele. I farmakologická anamnéza bude
mít historii, kde se jako první položka bude nabízet
seznam léčivých p ípravků z časově posledního
doporučení bez ohledu na pracoviště, odbornost,
hospitalizaci či ambulantní návštěvu.

· ádek parametrických polí pro implantabilní zdravotnické
prost edky (nap . kardiostimulátory, ICD, chlopenní
protézy, protézy nosných kloubů) bude obsahovat:
o parametrické pole pro název zdravotnického
prost edku,
o parametrické pole pro výrobní číslo (LOT),
o parametrické pole pro záznam kompatibility
s vyšet ením v nukleární magnetické rezonanci
(intenzita pole v T /Tesla/, údaj o
omezeném/celotělovém skenování),
o parametrické pole pro záznam implantujícího
pracoviště a telefon na něj (9-místný formát).

· Parametrické pole pro pětimístný kód diagnózy
ambulantního vyšet ení dle MKN-10

· Parametrické pole pro epidemiologický status - forma
alertu.

· Parametrické pole pro nemocné v paliativní péči, pole je
doplněno datem a údajem o zdravotnickém pracovišti
zadavatele, kdy a kde k takovému stanovení léčebného
plánu došlo.

· Parametrické pole s upozorněním na existenci d íve
vysloveného p ání podle platné legislativy, pole je
doplněno datem a údajem o zdravotnickém pracovišti
zadavatele, kdy a kde ke vzniku d íve vysloveného p ání
došlo.

· Parametrické pole (s možností výběru z editovatelného
číselníku) pro další specifické skupiny - nap . dialyzovaní,

88
transplantovaní, pacienti na domácí parenterální výživě,
diabetici na inzulinové pumpě.

KIS_359 Zadavatel požaduje možnost p idávat další pole buď parametrická,
nebo textová s ohledem na oborové odlišnosti p i poskytování
ambulantních služeb – nap . šablonu pro p edanestetické
vyšet ení, pro kontrolu v onkologické ambulanci, ambulancích P Vyberte

neinvazivní kardiologie. (Konkrétní množství polí a jejich
uspo ádání bude stanoveno v rámci analytické fáze projektu.)

KIS_360 IT podpora procesů na ambulanci strukturovaně obsahuje
následující pole (jejich skutečné po adí ve formulá i na obrazovce
bude stanoveno až v průběhu analýz se zadavatelem):
· Diagnostický souhrn

· Osobní anamnéza

· Nynější onemocnění P Vyberte
· Objektivní nález

· Okna pro vložení výsledků ostatních vyšet ení
· Závěr
· Doporučení
Identifikace léka e, datum a čas dokončení úprav a definitivního
uzav ení zprávy z ambulantního vyšet ení

KIS_361 Diagnostický souhrn – pole pro zápis volným textem. Pokud byl
pacient hospitalizován na stejném zdravotnickém pracovišti nebo
má p edchozí ambulantní vyšet ení na stejném zdravotnickém
pracovišti, pro vyplnění tohoto pole se jako první položka v historii
všech p edchozích vyšet ení nabídne diagnostický souhrn
z p edchozího ambulantního vyšet ení, není-li, pak z časově
poslední hospitalizace. Pokud pacient na zdravotnickém pracovišti P Vyberte

dané odbornosti léčen dosud nebyl, v rámci historie se nabízí
ostatní diagnostické souhrny dostupné v KIS, jako první je
v seznamu časově poslední diagnostický souhrn pacienta
z hospitalizace/ambulantního vyšet ení na jiném zdravotnickém
pracovišti jiné odbornosti.

KIS_362 Osobní anamnéza: Pole p ipravené na psaní volného textu.
V historii se na prvním místě nabízí časově poslední osobní
anamnéza získaná na stejném zdravotnickém pracovišti (bez
ohledu na to, jestli je z ambulantního vyšet ení nebo P Vyberte
z hospitalizace). Není-li taková k dispozici, nabídne se jako první
časově poslední osobní anamnéza získaná na jiném
zdravotnickém pracovišti jiné odbornosti.

KIS_363 Nynější onemocnění: Pole p ipravené na psaní volného textu.
V historii se na prvním místě nabízí časově poslední nynější
onemocnění zapsané na stejném zdravotnickém pracovišti (bez
ohledu na to, jestli je z ambulantního vyšet ení nebo
z hospitalizace). Není-li takový záznam k dispozici, nabídne se
jako první časově poslední záznam nynějšího onemocnění získaný
na jiném zdravotnickém pracovišti. Jestliže se jedná o ambulantní P Vyberte

vyšet ení na žádost jiného pracoviště zadavatele, pak se jako
první v historii nabídne záznam nynějšího onemocnění ze
žádajícího pracoviště. U tohoto pole může být zadavatelem také
nastaveno, že není nabízena žádná historie (tj. každé nynější
onemocnění je aktuální originál).

KIS_364 Objektivní nález: P Vyberte
Je složen z okna pro vlastní vyšet ení pro záznam volného textu a
sestavy parametrických oken pro záznam:

89
· Hmotnosti pacienta – nepovinná položka má dvě
parametrická okna pro zadání hmotnosti „změ ené“, nebo
„odhadnuté“; kterákoli ze zadaných hodnot se p enáší do
žádanek pro radiologii. „Odhadnutá“ hmotnost se nenabízí
pro účely ordinací léčiv (nap . pro dávkování cytostatik,
biologické léčby). Na pediatrických odděleních je možné
nastavit hmotnost v gramech, a to bez zaokrouhlování;
pokud není vyplněná, netiskne se.

· Výšky pacienta – nepovinná položka má dvě
parametrická okna pro zadání výšky „změ ené“, nebo
„odhadnuté“; kterákoli ze zadaných hodnot se p enáší do
žádanek pro radiologii. „Odhadnutá“ výška se nenabízí pro
účely ordinací léčiv (nap . pro dávkování cytostatik,
biologické léčby); pokud není vyplněná, netiskne se.

· tepové frekvence (TF)
· systolického/diastolického krevního tlaku v mmHg

(TKs/TKd), na vybraných pracovištích lze p idat tato pole
pro opakovaný záznam TK

· saturace krve kyslíkem měřené pulzním oxymetrem
(SpO2)

· dechové frekvence (DF)
· Performance status (PS) dle WHO

KIS_365 Okna pro vložení výsledků ostatních vyšetření včetně textů z
jiných ambulancí, výsledků laboratorního komplementu (léka
může volit podle data a času vyšet ení, vybírat pouze některé P Vyberte
provedené metody), popisů zobrazovacích vyšet ení, p ipojení
binárních souborů nap . fotografií

KIS_366 Výkony - okno volného textu s chronologickým výčtem operací či P Vyberte
jiných zdravotně zásadních výkonů, které pacient podstoupil.

KIS_367 Závěr: Parametrické pole pro pětimístný kód MKN-10 a pole pro P Vyberte
volný text k zápisu diagnózy, pro kterou se ambulantní návštěva
uskutečnila

KIS_368 Doporučení:
Parametrický záznam a zároveň okno se zápisem volného textu
pro záznam doporučených léčivých p ípravků – p enese se
z farmakologické anamnézy a umožní neomezenou editaci
(p idání/smazání/úpravy u jednotlivých léčivých p ípravků).
Parametrický seznam a zároveň okno se zápisem volného textu
pro zápis doporučených zdravotnických prost edků.
Parametrický záznam, který do doporučení vloží termín další
plánované kontroly/kontrol včetně označení pracoviště, do jehož
plánovacího kalendá e byla návštěva naplánovaná.
Okno pro záznam údajů o dočasné pracovní neschopnosti a
ostatních skutečností, které jsou pro tuto agendu závazné (pacienti P Vyberte

v evidenci ÚP).
Okno pro záznam indikace p epravy sanitkou s parametricky
vyznačeným požadavkem na druhého člena posádky, nebo
doprovod; pokud se požadavek na dvouposádku/doprovod vyplní,
otev e se okno s číselníkem pro zadání odůvodnění indikace pro
takovou službu; zadané hodnoty se automaticky p enesou do
žádanky na zdravotní dopravu.
Okno s volným textem pro zápis doporučení léka e.
Parametrická okna se záznamem o p edepsaných léčivých
p ípravcích a zdravotnických prost edcích, které se automaticky

90
p enesou z IT ešení procesů pro p edpisy.

KIS_369 Identifikace lékaře, datum a čas dokončení úprav a P Vyberte
definitivního uzavření zprávy z ambulantního vyšetření – P Vyberte
doplněno automaticky KIS. N Vyberte

KIS_370 Ambulantní systém sleduje délku rozpracovanosti jednotlivých D_III Vyberte
pacientů a v intervalu, který zadavatel může upravovat, aktivně
upozorňuje vedoucího léka e provozu a léka e, který pacientovi
poskytoval zdravotní služby, že interval pro uzav ení ambulantní
dokumentace byl p ekročen. Upozornění je formou alertu na
obrazovce systému. Jakmile se léka p ihlásí ambulantního
systému na konkrétní ambulanci, pacienti s neuzav enou
dokumentací jsou azeni v seznamu rozpracovaných pacientů
naho e a zvýrazněni.

KIS_371 Zadavatel uvítá, pokud bude KIS poskytovat nástroj na podporu
plánování ambulantního provozu, zadavatel má na mysli rozpisy
ambulancí pro konkrétní léka e, sestry, vyšet ovací či léčebnou
metodu.

KIS_372 KIS musí obsahovat p ehled pacientů v evidenci závodních léka ů,
bude umožňovat editaci jednotlivých záznamů a vkládání
doplňujících údajů.
Informace o pacientovi:

· jméno
· p íjmení
· pojišťovna – možnost zachování historie
· bydliště – možnost zadaní více
· možnost další kontaktní informace – mail, mobilní telefon,

kontakt na blízkou osobu
· datum vzniku a zániku registrace
· IČ léka e, pacienta, záznamu
· IČZ, IČP, VAR.

Ambulantní objednávací systém

KIS_373 Objednávání pacientů do jednotlivých ambulancí a poraden
probíhá prost ednictvím objednávacích kalendá ů. V záhlaví
každého objednacího kalendá e je číslo telefonu P Vyberte

ambulance/poradny.

KIS_374 Objednávací kalendá e se vztahuji k fyzickým prostorům P Vyberte
ambulantních traktů – KIS má tedy v sobě mapu veškerých
ambulantních kapacit.

KIS_375 Plánovací kalendá e se v KIS povedou alespoň na 2 roky dop edu P Vyberte
od aktuálního data.

KIS_376 Pracoviště má možnost označit časové intervaly, které jsou
defaultně vyhrazeny pro jednoho pacienta v krocích po 5
minutách; údaj je možné individualizovat dle pot eb zadavatele a
pracovišť. Pokud dojde k naplánování pacienta, který svou
problematikou tento interval jistě p esáhne, objednávající P Vyberte
pracovník má okamžitě možnost čas vyhrazený na takovou
návštěvu v objednacím kalendá i protáhnout na pot ebný čas.
Takový krok posune všechny další objednané pacienty navazující
po této návštěvě.

91
KIS_377 Do časového intervalu, ve kterém je již naplánované ambulantní P Vyberte
vyšet ení pacienta, nelze objednat dalšího pacienta.

KIS_378 Konkrétnímu časovému úseku v dané poradně lze p i adit P Vyberte
zdravotnické pracoviště, pop . konkrétního léka e a typ ambulantní
agendy (nap . kardiologická poradna, koloproktologická poradna).

KIS_379 Konkrétní časový úsek, pop . i celá pracovní doba, lze v p ípadě P Vyberte
pot eby uzamknout s nemožností na tento termín objednávat.

KIS_380 Objednávací kalendá ambulance/poradny jednoho zdravotnického
pracoviště umožňuje rezervovat kapacitu ambulance/poradny pro
pot eby jiného pracoviště, které v tomto termínu obvykle žádá o
péči. P íkladem je situace, kdy kardiologická poradna ve čtvrtek
dopoledne žádá ambulanci neinvazivní kardiologie o UZ vyšet ení
srdce. Výsledkem funkcionality je situace, kdy do takto
rezervovaného času smí objednávat pouze konkrétní žádající P Vyberte
pracoviště a žádné jiné; toto pravidlo může prolomit pouze
ambulance/poradna, které náleží konkrétní objednací kalendá
(vztaženo k p íkladu uvedenému výše – JIP bude pot ebovat
emergentní UZ srdce a ambulance neinvazivní kardiologie
pacienta z JIP vmeze í do programu, který si objednala
kardiologická poradna).

KIS_381 Pracoviště bude také moci ídit prost ednictvím KIS postupné
uvolňování volných kapacit v čase s ohledem na blížící se termín.
Zadavatel tím myslí následující situaci – p íklad: 30 dubna bude na
gastroskopii možné vyšet it 12 lidí. 6 lidí bude automaticky
v kalendá i zablokováno pro pot eby uvnit FNHK (akutní,
hospitalizování,…). Ze zbývajících 6 volných míst nap . 3 měsíce
dop edu budou pro pot eby objednání elektivních výkonu uvolněny P Vyberte

pouze 2 pozice (4 pozice stále zůstanou pro objednávání
nedostupné). 1 měsíc p ed 30. dubnem budou uvolněny další 2
pozice a týden p ed 30. dubnem budou uvolněny zbývající 2
pozice. Funkce má za cíl zabránit skokovému zaplnění kapacit,
které by neumožnilo získat termíny pro akutní pacienty.

KIS_382 Již v objednacím systému i na kartotéce na straně zdravotníků má P Vyberte
být u nemocného zobrazen p ípadný epidemiologický alert či jiný
pomocný alert.

KIS_383 P i objednávání konkrétního pacienta se p i jeho výběru na
obrazovce automaticky zobrazí p ehled všech dalších
objednaných návštěv a hospitalizací na kterémkoli zdravotnickém
pracovišti zadavatele tak, aby již někým jiným naplánovaná P Vyberte

p ítomnost pacienta v nemocnici mohla být využita i pro poskytnutí
plánované zdravotní služby objednávajícího pracoviště.

KIS_384 Pokud je pot eba k poskytnutí ambulantní služby získat i výsledky
z vyšet ení v jiných ambulancích/poradnách nebo
komplementárních diagnostických pracovištích, má objednávající
pracovník možnost zobrazit plánovací kalendá e ostatních
pracovišť poskytujících součinnost. Pokud jsou v plánovacím
kalendá i volné, nebo pro objednávající pracoviště rezervované P Vyberte

termíny, může pracovník pacienta rovnou na konkrétní termín
objednat. Cílem je umožnit tzv. sdružené objednávání
zdravotních služeb, aby byla maximálně využita fyzická
p ítomnost pacienta v areálu zadavatele.

KIS_385 Zadavatel uvítá, pokud bude KIS vybaven funkcí automatizace N Vyberte
popsaného sdruženého objednávání.

92
KIS_386 V p ípadě zrušení termínu pro konkrétního pacienta a pot ebě
p eobjednat systém nabídne alespoň 3 nejbližší volné termíny do
stejné ambulance, pokud žádný nevyhovuje, p ejde zdravotník do P Vyberte

objednávacího kalendá e.

KIS_387 Pokud dojde ke zrušení termínu či celého programu ambulance
v konkrétním dnu, systém nabídne automaticky seznam
objednaných pacientů. Ze seznamu umožní p ejít do pacientovy P Vyberte
zdravotnické dokumentace a u každého z nich postupně umožní
zvolit nový termín.

KIS_388 KIS je schopen v p ípadě dostupných kontaktů odeslat SMS nebo
e-mail s informací o zrušeném termínu a s nabídkou nového
termínu pacientovi včetně telefonického spojení na poradnu, aby N Vyberte

mohl pacient žádat o změnu termínu telefonicky.

KIS_389 U konkrétního pacienta v objednacím kalendá i lze kontextovou
nápovědou zobrazit jeho telefonní číslo (není-li, tak e-mail) a p ímo
p ejít do jeho ambulantní karty (nap . kliknutím myši, klávesovou P Vyberte

zkratkou).

Funkce recepce a fronty pacientů včetně funkcí pro urgentní příjem

KIS_390 KIS má v sobě zabudované funkce, které umí spravovat fronty
čekajících pacientů, aktualizovat jejich osobní údaje do Master
Patient Indexu, roz azovat je do front pacientů pro konkrétní P Vyberte
ambulance/poradny. D_III Vyberte
Vyberte
KIS_391 V rámci této činnosti je KIS integrován se stávajícími vyvolávacími P Vyberte
systémy, které jsou provozovány zadavatelem. Popis integrací je P Vyberte
popsán v „4 Minimální požadavky na integrační platformu včetně P Vyberte
zhotovení komunikačních vazeb s vyjmenovanými systémy. P Vyberte
P
KIS_392 U každého pacienta na urgentním p íjmu je rozhodným
okamžikem čas registrace k ošet ení, který je po celou dobu práce
s pacientem zobrazený v tabulce čekajících pacientů. Čas
registrace je možné použít k azení fronty čekajících pacientů.

KIS_393 V p ípadě urgentního p íjmu je nutné zobrazovat všechny pacienty
zaregistrované k ošet ení najednou, tj. nerozdělovat je do front
čekajících do jednotlivých ambulancí/pozic urgentního p íjmu, jako
prevence p ehlédnutí p ítomnosti pacienta a tím rizika pozdního
ošet ení.

KIS_394 Pro poradny s plánovanými pacienty je rozhodným okamžikem čas
objednání pacienta, který je po celou dobu práce s pacientem
zobrazený v tabulce čekajících pacientů. Čas objednání je také
možné použít k azení fronty čekajících pacientů.

KIS_395 Neobjednaní pacienti, kte í jsou ošet ováni v akutních
ambulancích klinik nebo odborných poradnách, jsou v seznamu
pacientů v čekárně konkrétní ambulance graficky zvýrazněni –
způsob navrhne uchazeč. Místo času plánovaného termínu
ošet ení se u nich zobrazuje čas registrace k ošet ení.

KIS_396 KIS registruje alespoň následující časové údaje: čas objednání
pacienta k vyšet ení, čas skutečné registrace pacienta do
systému, čas p evzetí/prvního vstupu pacienta do ambulance a
čas definitivního ukončení p ítomnosti pacienta na
ambulanci/poradně a jeho vy azení z fronty ošet ovaných
pacientů. Tyto časové hodnoty jsou udržovány v systému pro další

93
analýzy.

KIS_397 Na urgentním příjmu musí být KIS vybaven možností p ipojit
k zaregistrovanému pacientovi také hodnotu (parametrický údaj)
v rámci pětistupňového systému triage podle Manchester Triage
Systém (hodnoty 1-5, p ípadně barevný kód, ideálně kombinace
obojího), kterou zobrazuje p ímo ve frontě pacientů. Systém dále
umožňuje uvést v rámci záznamu triage krátký popis symptomu
(nap . „dušnost“ – parametrické okno, variantou i výběr
z editovatelného číselníku), který se také zobrazuje p ímo ve
frontě čekajících pacientů, a spolu s ním umožňuje do KIS uvést i
detailní popis symptomu pacienta tak, jak jej zaznamenala
triážující osoba do okna pro zápis volného textu s omezenou
délkou (nap . 200 slov). Zadavatel uvítá, když takový detailní popis
z triage bude možné zobrazit p i pohledu na frontu
zaregistrovaných pacientů nap . ve vyskakovacím okně či bublině P Vyberte
tak, že se léka myší zastaví nad krátkým popisem symptomu. KIS
aktivně vybízí pracovníky urgentního p íjmu, aby v zadavatelem
stanoveném časovém intervalu, jehož délka je nastavitelná pro
každý stupeň triage, zdravotníci prováděli p ehodnocení triage.
Aktualizovaná hodnota stupně v rámci triage slouží
k automatickému azení čekajících pacientů tak, aby urgentnější
pacienti byli ve frontě čekajících zobrazeni v seznamu naho e
v defaultním zobrazení. P echodně lze azení pacientů změnit
podle jiných atributů (viz. níže). Číselné hodnoty stupně triage a
časy jejich změny, které byly do KIS zaznamenány v průběhu od
registrace pacienta k ošet ení až do ukončení jeho ošet ení,
zůstávají v historii v KIS a je možné je získat pro p ípad hodnocení
poskytování péče a šet ení stížnostní agendy.

KIS_398 Podle typu pracoviště může zadavatel volit, jestli fronta čekajících
pacientů bude azena podle:
· hodnoty stupně triage

· času registrace k vyšet ení

· vyšet ujícího léka e P Vyberte

· plánovaného času objednání pacienta (tj. respektují se
časovky dané už v procesu objednávání k ambulantní
návštěvě)

· podle dodání výsledků vyšet ení, o které bylo v průběhu
poskytování ambulantního ošet ování požádáno

nebo kombinace p edchozích možností

KIS_399 KIS aktivně graficky upozorňuje ve frontě rozpracovaných pacientů
na doručení výsledků, o které bylo požádáno v průběhu
ambulantního ošet ování (nap . popis zobrazovacích vyšet ení, P Vyberte
výsledky laboratorních vyšet ení). Opat ení smě uje k podpo e
zkrácení celkové doby pobytu pacienta na ambulanci.

Ambulantní pracoviště stacionářového typu

KIS_400 Je vybaveno možností objednávání postavenou na stejných P Vyberte
principech jako u ambulance/poradny. P Vyberte
D_II Vyberte
KIS_401 Pracoviště jako výsledek své práce může vytvo it zprávu z
ambulantního vyšet ení jako jakákoli jiná ambulance/poradna. Má
i stejné funkce – může žádat o a p ijímat výsledky
komplementárních vyšet ení.

KIS_402 Podpora procesů pro stacioná ové ambulantní pracoviště by

94
principiálně měla být využitelná na široké škále pracovišť – interní
stacioná OAP, Oddělení urgentní medicíny, monitorovací lůžka u
ambulantně prováděných výkonů (endoskopie, urologie,
vazografie, malé gynekologické výkony,…), stacioná e k aplikaci
terapií (hematologie, onkologie, onkogynekologie, ÚKIA, …).

KIS_403 Kromě vlastní ambulantní zprávy je na tomto pracovišti možné
vytvo it dokumenty pro sledování vývoje zdravotního stavu
pacienta průběžně po celou délku pobytu. Zadavatel požaduje P Vyberte
p ípravu škály protokolů sledování s tabulkami pro záznam P Vyberte
fyziologických funkcí a jiných skutečností p ipravené pro různé D_II Vyberte
délky sledování, mezi kterými si zdravotníci vyberou; optimálním P Vyberte
ešením by byl uživatelský nástroj pro tvorbu takových protokolů P Vyberte
podle specifických pot eb jednotlivých stacioná ů. P Vyberte

KIS_404 Dokument pro sledování vývoje stavu zároveň umožňuje ordinaci D_II Vyberte
léků stejným způsobem, jak to umožňuje léka ský dekurz
lůžkového oddělení nebo JIP – funkcionalita je popsána výše.

KIS_405 Dokument umožňuje volat systém CATO pro ordinaci léčivých
p ípravků p ipravovaných Centrální p ípravnou cytostatik; jakmile
je rozpis léčiv hotový a p íprava byla provedena, systém CATO
odešle do KIS finální p edpis léčiv tak, aby se stal součástí
ambulantní dokumentace pacienta.

KIS_406 Ambulantní dokumentace na stacioná i umožňuje p idat k
ambulantní zprávě seznam použitých zdravotnických prost edků
t ídy IIb nebo III, které byly použity. Jejich vložení je také
zabezpečeno snímáním čárových kódů ze seznamů
zdravotnických prost edků; lze je vepsat p ímo nebo vybrat z
p i azených seznamů zdravotnických prost edků daného
pracoviště v KIS.

KIS_407 V ambulantní dokumentaci stacionárního typu jsou p ipravená
parametrická pole pro záznam informací podstatných pro
radiodiagnostiku – odkaz na tuto problematiku v radiologickém
informačním systému.

KIS_408 Z ambulantní dokumentace na stacioná i lze spouštět IT ešení
týkající se provozu operačního (výkonového) sálu se všemi
funkcemi tak, jak je popsáno v kapitole operačních sálů – podpora
pro jednodenní chirurgii prováděnou se zázemím stacioná e.

Ambulantní pracoviště rehabilitace

KIS_409 KIS bude umožnovat plánování rehabilitačních procedur
minimálně v rozsahu:

· Rezervace
· Nastavení léčby
· Rozpis procedur
· Rozší ené ruční časování
· Pravidelné časování
· Automatické časování
· Kontraindikace procedur
· Časy pro p esun pacienta
· Blokace časů
· Propojení více pracovišť do logických celků
· Definice pracovní doby na úrovni pracovník, pracoviště,

procedura. V p ípadě zadání více úrovní, je potom čas pro
časování určen průnikem všech dostupných časů,

95
Pracovní dobu půjde zadat jako pravidelnou, na směny
nebo občasnou.

2.2.9 Univerzální klinické funkce

KIS_410 Z kterékoli zdravotnické části KIS lze u konkrétního pacienta
zobrazit veškeré zdravotní služby, které má již naplánované na
všech pracovištích zadavatele, tabulka obsahuje alespoň
plánovaný datum, pracoviště, rozlišení typu služby (tj. ambulantní – P Vyberte
hospitalizace – diagnostika). Vyšet ení v tabulce lze filtrovat a adit
pomocí záhlaví sloupců. Zadavatel požaduje za výhodu, pokud je
ke sloupci pracoviště p ipojen i telefon.

KIS_411 Z kterékoli zdravotnické části KIS je možné zobrazit časový plán
zdravotních služeb na konkrétní den, které má na kterémkoli
pracovišti zadavatele pacient naplánované; plán lze i pro pacienta P Vyberte

vytisknout.

2.2.10 IT podpora vyšetřování na patologii
2.2.10.1 Žádanka na patologické vyšet ení

KIS_412 Zadavatel požaduje, aby žádanka na patologické vyšet ení byla
vytvá ena v KIS. Kromě hlavičky žádanky s pot ebnými údaji
identifikace pacienta, identifikace žádajícího pracoviště a kódu P Vyberte
zdravotní pojišťovny bude žádanka obsahovat minimálně
následující oddíly: D_II Vyberte
D_II Vyberte
· Laborato Vyberte
· kód a text diagnózy vyšet ení P
· kód a text hlavní diagnózy
· Režim vyšet ení z hlediska časové odezvy:

STATIM,RUTINA,SUPERSTATIM,PEROPERAČNÍ
BIOPSIE
· Typ vyšet ení detailně popsán v bodě KIS_417
· Datum a čas odběru materiálu
· Vyšet ení:
· Okno pro stručnou epikrízu
· Parametrické okno klinické TNM klasifikace, kde je
relevantní
· Okno pro p edmět vyšet ení a požadavky na patologa
· Identifikace žádajícího léka e

KIS_413 Zadavatel požaduje, aby žádanka na patologické vyšet ení byla
pomocí integrační vazby p enesena do SW patologie, který již
zadavatel provozuje.

Detailní popisy vybraných částí žádanky

KIS_414 Laborato – parametrický údaj, výběr konkrétní laborato e ústavu
patologie zadavatele z číselníku pracovišť, zadavatel má možnost
číselník upravovat dle svých pot eb.

KIS_415 Diagnóza k vyšet ení – skládá se z parametrického pole kódu
MKN 10 a na něj navazujícího parametrického pole s textem
diagnózy podle MKN 10. Tento ádek KIS automaticky nevyplňuje,

96
žádající léka musí pomocí nástroje vyhledávání kódů najít co
nejp esnější kód pro vyšet ovaný materiál.

KIS_416 Hlavní diagnóza - skládá se z parametrického pole kódu MKN 10 a
na něj navazujícího parametrického pole s textem diagnózy podle
MKN 10. KIS tuto diagnózu vyplňuje kódem hlavní diagnózy z P Vyberte
časově poslední Epikrízy u hospitalizovaných. U ambulantních
pacientů musí léka zvolit relevantní kód pomocí nástroje. I u P Vyberte
automatického vyplnění je položka editovatelná žádajícím léka em. D_II Vyberte

KIS_417 Typ vyšet ení – parametrický údaj, kde z číselníku editovatelného P Vyberte
zadavatelem je zvolena metoda; požadujeme minimálně P Vyberte
následující položky: biopsie – cytologie – elektronová mikroskopie P Vyberte
– výsledky p edchozích vyšet ení – cerkviko-vaginální cytologie – P Vyberte
imunofluorescence – molekulární vyšet ení – nekropsie. P Vyberte
P Vyberte
KIS_418 U metody „cerkviko-vaginální cytologie“ zadavatel požaduje, aby v D_II Vyberte
KIS vznikla nová elektronická verze žádanky s parametrickými
poli, u kterých budou funkční kontrolní body (bez vyplnění nelze
pokračovat dál), konkrétní obsah bude součástí analytické fáze
projektu.

KIS_419 Okno pro stručnou epikrízu – okno volného textu, do kterého lze u
hospitalizovaných p enést prost ednictvím schránky text poslední
epikrízy s dg. souhrnem a textem, žádající léka text může editovat
a p íslušným způsobem zkrátit na relevantní informace. Analogicky
u ambulantních pacientů lze p enést text z poslední ambulantní
zprávy ze žádajícího pracoviště.

KIS_420 Parametrické okno klinické TNM klasifikace – sestava 3
samostatných parametrických oken pro složky klasifikace
zhoubných nádorů pro T, N a M položku klasifikace; položka
nemusí být vždy povinně vyplněna léka em.

KIS_421 Okno pro p edmět vyšet ení a požadavky na patologa – okno pro
zápis volného textu, do kterého žádající léka popíše získaný
materiál, specifikuje otázky pro patologa atp.

KIS_422 Identifikace žádajícího léka e – parametrické okno, provazba na
číselník léka ů s oprávněním p ístupu do KIS.

KIS_423 Pokud dojde k úmrtí pacienta a je do statistického výkazu vyplněn
kód 7 nebo 8 v parametru Pot eba další péče, po uzav ení
statistického formulá e dojde automaticky k otev ení žádanky pro
patologii; v p ípadě indikace zdravotní pitvy na Ústavu soudního
léka ství zadavatele může léka žádanku uzav ít nevyplněnou
(není zde kontrolní bod, jedná se pouze o procesní podporu).

KIS_424 Zadavatel požaduje, aby byla žádanka p enesena elektronicky, ale
zároveň musí být umožněn tisk všech údajů žádanky na papír.

KIS_425 Systém umožní každou uzav enou a odsouhlasenou žádanku
vytisknout a odeslat pouze jednou. Pokud žadatel získá více typů
materiálu a bude nutné provedení různých patologických vyšet ení
(metod), každý z takových vzorků musí mít svou vlastní žádanku.
Opat ení smě uje proti situaci, kdy na několik kopií stejné žádanky
žadatel odesílá různé vzorky a žádá vyšet ení různými metodami.
Chybnou žádanku je nutné stornovat a vystavit novou správnou.

97
Výsledek vyšetření z patologie

KIS_426 Patolog má p ístupová práva do KIS u pacienta, jehož materiál
právě vyšet uje. Může zobrazovat, nikoliv editovat, zdravotnickou
dokumentaci, která je u pacienta v KIS p ístupná, a to ve stejném P Vyberte
rozsahu, jako ošet ující léka pacienta, tj. včetně výsledků D_II Vyberte
ostatních komplementárních vyšet ení (zobrazovacích, Vyberte
laboratorních). V KIS tedy existuje role „patolog“, která má taková P Vyberte
p ístupová práva. D_II

KIS_427 Výsledky ze SW patologie zadavatele jsou prost ednictvím
integrace importovány zpět do KIS ke konkrétnímu pacientovi.
Transport výsledku probíhá v „push“ režimu – tj. jakmile je uzav en
patologem se specializovanou způsobilostí a uvolněn vůči
p íjemcům, integrační platforma výsledek p enese a za adí do KIS
s grafickým upozorněním (formu navrhne uchazeč) pro p íjemce.
P i transportu výsledku z patologické laborato e do KIS je
respektovaná struktura výsledku co do obsahu parametrických polí
a polí se zápisem volného textu. Popis integrací je popsán
v „4 Minimální požadavky na integrační platformu včetně zhotovení

komunikačních vazeb s vyjmenovanými systémy“.

KIS_428 Výsledky vyšet ení se zobrazují v seznamu výsledků z patologie u
konkrétního pacienta. Výsledky z patologie jsou v rámci KIS
prezentovány v tabulce, kde je možné je adit podle následujících
kritérií:

· Datum a čas
· Žádající pracoviště
· Vyšet ení (tj. metoda viz specifikace žádanky)

KIS_429 Ve výsledku vyšet ení z patologie je možné zachovat následující
položky ze žádanky – finální stav bude výsledkem analytické fáze:

· kód a text diagnózy vyšet ení zadané žadatelem
· Datum a čas odběru materiálu
· Vyšet ení:
· Okno pro stručnou epikrízu
· Parametrická okna klinické TNM klasifikace
· Parametrická okna patologické TNM klasifikace (pT pN

pM)
· Okno pro p edmět vyšet ení a požadavky na patologa
· Identifikace žádajícího léka e

KIS_430 KIS musí být schopen generovat ALERT v p ípadě jakékoliv P Vyberte
změny v uzav eném výsledkovém protokolu (dodatečné vyšet ení,
storno, atd.).

KIS_431 Popis vyšet ení patologem také obsahuje jako svou součást:
· parametrická okna pro pT pN pM analogicky popisu
klinické TNM v žádance; stran vyplnění patologem P Vyberte
nepovinná položka
· okno pro záznam volného textu pro zápis výsledku,
· morfologický kód nádoru jako parametrický údaj

KIS_432 Zadavatel požaduje, aby k výsledku patologického vyšet ení bylo P Vyberte
možné p ipojit binární soubor (nap . fotografii).

KIS_433 Zadavatel požaduje, aby v p ípadě změny/vyplnění pTpNpM – N Vyberte
tedy nálezu maligního onemocnění – odlišně od klinického zadání
byla tato změněná klasifikace nějakým grafickým způsobem na

98
obrazovce zvýrazněna – konkrétní ešení ponecháváme na
rozhodnutí uchazeče.

KIS_434 Zadavatel požaduje, aby bylo možné parametricky zaznamenané
kódy TNM ze žádanek a pTpNpM z patologických výsledků
p enášet i do závěrečných propouštěcích či ambulantních zpráv.
Zároveň tyto parametrické kódy musí KIS umět p enést i do P Vyberte

formulá e Hlášení zhoubného novotvaru v souladu s platnou
metodikou ÚZIS.

List o prohlídce zemřelého

KIS_435 KIS poskytuje plnou podporu léka i pro vyplnění formulá ů Listu o
prohlídce zem elého p esně v souladu s platnou legislativou.
Požadujeme automatický p enos všech položek, které už uvnit P Vyberte
KIS jsou zaznamenány; všechny takové položky jsou editovatelné. P Vyberte
Položky vyžadující zadání kódu MKN 10 jsou opět parametrické a D_II Vyberte
léka je vyplňuje pomocí nástroje pro vyhledání kódu v těch
p ípadech, pokud k jejich vyplnění nedošlo automaticky.

KIS_436 KIS podporuje také tisk všech legislativou požadovaných částí
Listu o prohlídce zem elého.

KIS_437 Po vyplnění formulá e Listu o prohlídce zem elého KIS zajišťuje
elektronický p enos zaznamenaných informací do SW patologie
tak, aby s nimi mohli patologové dále pracovat v elektronické
formě. P enos informací z Listu o prohlídce zem elého do
databáze ÚZIS nemusí uchazeč ešit, protože ji zajišťuje speciální
SW patologie.

2.2.11 Poukaz na léčebnou a ortopedickou pomůcku, Poukaz na brýle a
optickou pomůcku a Poukaz na foniatrickou pomůcku

KIS_438 Údaje dle platné Metodiky pro po izování a p edávání dokladů P Vyberte
VZP

KIS_439 Možnost vystavení účtenky-stvrzenky za pomůcku, která není P Vyberte
hrazena za zdravotního pojištění nebo je hrazene částečně

2.2.12 Komplexní IT řešení pro procesy spojené se zobrazovacími metodami
2.2.12.1 Žádanka na zobrazovací metody

KIS_440 Zadavatel vyžaduje vytvo ení šablon žádanek pro vyšet ení podle
požadované zobrazovací modality minimálně ve spektru:
· ultrazvuk (UZ)

· skiaskopie, skiagrafie

· mamografie

· kostní denzitometrie P Vyberte
· angiointervenční metody
· CT

· magnetická rezonance (MR)

· pozitronová emisní tomografie/CT (PET/CT)

· ostatní zobrazovací metody nukleární medicíny (nap .
scintigrafie)

99
KIS_441 KIS v souladu s platnou Metodikou pro po izování a p edávání
dokladů poskytne pro vystavení žádanky údaje požadované v
hlavičce žádanky a nabídne minimálně všechna další pole, která P Vyberte

obsahuje vzorový formulá na www.vzp.cz.

KIS_442 KIS nabídne parametrické pole pro kódy MKN 10 a k nim
náležející textové etězce pro diagnózu vyšet ení – Pozor! Pole je
vždy prázdné a léka pomocí nástroje vyhledávání kódů v MKN 10
vyhledá správný kód (zadavatel nep ipouští, aby se do pole
automaticky p enášela jakákoli diagnóza zavedená v epikríze P Vyberte
nebo v záhlaví ambulantní zprávy jako prevence neshody kódu
diagnózy a p edmětu zobrazovacího vyšet ení). U pole je
zavedena kontrola – není-li vyplněno, nemůže léka pokračovat v
editaci žádanky.

KIS_443 P i vystavování žádanky se automaticky p enesou z anamnézy
kompletní údaje o známých alergiích pacienta a léka tento
seznam potvrdí (nap . zaškrtávací pole). Tyto údaje KIS na
žádance zvýrazní. U pole je zavedená kontrola – bez potvrzení P Vyberte

pole léka em nebude možné vystavit žádanku na veškeré modality
s výjimkou UZ.

KIS_444 KIS žádajícímu léka i umožňuje, jsou-li známy, vložit do žádanky
vybrané hodnoty laboratorních komplementárních vyšet ení (nap .
krevní obraz, vyšet ení funkce ledvin, vyšet ení koagulačních
parametrů. Jsou-li známy, umožňuje p enést i pacientem užívané P Vyberte
léčivé p ípravky, do těla pacienta již d íve zavedené zdravotnické
prost edky (implantabilní). Všechny takové automaticky vnesené
parametry jsou editovatelné léka em.

KIS_445 Součástí žádanky bude údaj o zavedeném hygienickém režimu v
KIS z lůžkových oddělení. Pokud je odlišný od režimu S –
standardní, a je tedy zaveden jakýkoli zvýšený hygienický režim, u
elektronických žádanek bude na obrazovce zvýrazněno dle návrhu
uchazeče, na tištěné žádance nějak graficky zvýrazněno. U
žádanek vystavovaných z ambulantního systému je povinná
parametrická položka, kterou musí potvrdit léka v p ípadech P Vyberte
podez ení na TBC nebo jinou závažnou infekční chorobu; vedle
této položky je textové okno na specifikaci problému (nap . TBC
plic, hepatitida C - u vyšet ení, kde může radiolog p ijít do kontaktu
s tělesnými tekutinami pacienta). U těchto nemocných KIS
zablokuje elektronické objednávání a termín bude nutné domluvit s
radiologickým pracovištěm telefonicky.

KIS_446 Žádanka obsahuje i následující položky, bez jejichž vyplnění nelze
pokračovat v její další editaci:
· hmotnost pacienta – je-li v posledních 3 měsících v KIS
zadána do systému jako změ ená, vyplní se automaticky.
Pokud je v KIS pouze odhad hmotnosti nebo údaj úplně
chybí, léka ji musí vyplnit.

· výška pacienta - je-li v KIS zadána do systému jako
změ ená, vyplní se automaticky. Pokud je v KIS pouze
odhad výšky nebo údaj úplně chybí, léka ji musí vyplnit. P Vyberte

· P edchozí RTG vyšet ení – nenabízí se u všech
vyšet ovacích modalit, které nepoužívají ionizující zá ení;
parametrická položka typu Ano/Ne

· Lze toto vyšet ení využít? – nenabízí se u všech
vyšet ovacích modalit, které nepoužívají ionizující zá ení;
pokud na p edchozí otázku byla odpověď Ne, automaticky
se vyplní odpověď Ne; parametrická položka typu Ano/Ne

100
· Těhotenství lze vyloučit – nenabízí se u všech
vyšet ovacích modalit, které nepoužívají ionizující zá ení;
nenabízí se u pacientek mladších 14 let a starších 60 let;
parametrická položka typu Ano/Ne

KIS_447 Na žádance je možné rozhodnout, jestli se jedná o vyšet ení P Vyberte
požadované v režimu STATIM, nebo plánované vyšet ení. P Vyberte
P Vyberte
KIS_448 Žádanka na zobrazovací vyšet ení obsahuje prostor pro záznam D_II Vyberte
upozornění na p ítomnost kardiostimulátoru nebo ICD. Žádanka
na zobrazovací vyšet ení obsahuje prostor pro záznam
upozornění na p ítomnost intravaskulárního implantovaného portu;
je-li p ítomen, pak žádanka obsahuje parametr „CT port: ANO-NE“
s možností parametrické volby. Na žádance je parametrické pole
pro informace o i.v. vstupu – jeho ší e (rozbalovací seznam) a
umístění (rozbalovací seznam).

KIS_449 Součástí šablon žádostí u konkrétní modality je parametrické okno
pro zadání lokality vyšet ení s rozbalovacím seznamem. Po tomto
oknu následuje okno pro záznam volného textu pro zadání klinické
otázky.

KIS_450 Specifika žádanky na MR:
Zadavatel požaduje možnost vložit do žádanky na MR
dotazníkové položky v počtu a s textem, který si zvolí. Vedle každé
otázky v dotazníku je prostor pro reakci žádajícího léka e –
uchazeč navrhne možné způsoby ešení (nap . zaškrtávací pole
Ano/Ne s možností vložit text p esněji specifikující odlišnost).
Vyplnění všech polí v dotazníku je povinné – bez jejich vyplnění
nelze žádanku dokončit a odeslat.

2.2.12.2 IT ešení funkcí spojených s procesy na vlastním pracovišti
zobrazovacích metod

KIS_451 IT ešení pro pracoviště zobrazovacích metod (dle nabízené
varianty se shoduje s tzv. radiologickým modulem) je integrální
součástí dodávaného KIS a má v rámci integrační vazby D_II Vyberte
obousměrnou komunikaci s PACS systémem zadavatele od firmy P Vyberte
JIVEX, viz integrační vazby P Vyberte
P Vyberte
KIS_452 Zadání žádanky do systému musí umožnit pracovníkům radiologie
její za azení do fronty (workflow) na konkrétní modalitu,
vyšet ovnu, léka e, datum a čas. P i za azování do fronty
plánovaných pacientů jsou zvýrazněni ti, u kterých je údaj o
zvýšeném hygienickém režimu.

KIS_453 IT ešení má robustní objednávací systém se stejnými možnostmi
plánování vyšet ení, jaké jsou popsány v kapitole o IT ešení
procesů na ambulancích – tj. nap . objednávací kalendá e, ve
kterých je možné vyčleňovat kapacity pro konkrétního léka e nebo
modalitu a typ vyšet ení, termíny blokovat, p esouvat, rezervovat
časy trvání vyšet ení dle jejich typu (tj. musí umožňovat rozdílnou
dobu na objednávání v rozsahu 10 – 70 minut s krokem po 5
minutách). Objednávkový systém umí nabízet nejbližší volné
termíny na vyšet ení konkrétním specialistou, na konkrétním
p ístroji atp. Objednávkový systém umí upozorňovat pacienta
prost ednictvím SMS nebo e-mailu na blížící se termín vyšet ení.

KIS_454 Objednávací systém aktivně upozorňuje na došlou žádanku v
režimu „push“. Žádanku je možné p evzít, odmítnout se

101
současným záznamem důvodu odmítnutí radiologem, které se
zobrazí žádajícímu léka i, zrušení žádanky se současným
záznamem důvodu zrušení, které se zobrazí žádajícímu léka i.
Osoba t ídící došlé žádanky může žádanku p esunout v rámci
kliniky na jiné pracoviště nebo na jiný p ístroj. Po p idělení
žádanky na konkrétní pracoviště a termín je žádanka odstraněna z
fronty čekajících žádanek.

KIS_455 Je možné p ijímat informace buď z jiných skladových systémů
zadavatele nebo prost ednictvím snímání čárových nebo QR kódů
použitých zdravotnických prost edků tak, aby tyto prost edky byly P Vyberte
do dokumentace vyšet ení zaneseny (zejména se týká
zdravotnických prost edků t ídy IIb a III) a s vyšet ením propojeny P Vyberte
pro další informatickou práci se záznamy. P Vyberte
D_II Vyberte
KIS_456 Umožňuje vystavit žádanku na radiologické, mikrobiologické a D_II Vyberte
patologické a biochemické vyšet ení a vyšet ení krevního obrazu. D_II Vyberte
Je-li žádanka vystavena v rámci procesů na zobrazovacích P Vyberte
pracovištích, má radiolog nárok na p ístup k výsledku P Vyberte
mikrobiologického nebo patologického nebo biochemickému P Vyberte
výsledku či výsledku krevního obrazu či radiologického vyšet ení. P Vyberte

KIS_457 IT ešení procesů zobrazovacích pracovišť musí umožňovat
záznam radiační dávky pro pacienta, kterou má v sobě PACS.

KIS_458 IT ešení procesů zobrazovacích pracovišť umožňuje záznam
osoby, které byl p edán výsledek vyšet ení, p ípadně vypáleno CD
s dokumentací nemocného (datum poskytnutí) – okno pro zápis
volného textu.

KIS_459 KIS bude umožňovat zanesení označení jednotlivých p ístrojů
použitých k vyšet ení do parametrických polí v dokumentaci
vyšet ení; pole obsahují označení modality, název p ístroje,
výrobní číslo p ístroje a evidenční číslo v databázi poskytovatele.

KIS_460 KIS musí disponovat bezpečným způsobem p ihlašování se do IT
ešení procesů zobrazovacích pracovišť pomocí dálkového
p ístupu tak, aby léka i mohli popisovat obrazová vyšet ení do KIS
z domova. Zároveň uchazeč definuje minimální a optimální
hardwarové vybavení počítače pro tento p ístup.

KIS_461 V IT ešení procesů zobrazovacích pracovišť jsou odděleně
umístěny popisy vyšet ení z tzv. ePACS provozovaného v ČR, a to
t íděné podle zobrazovacích modalit. Zadavatel požaduje možnost
zobrazení výsledků vyšet ení (myšleno textových popisů) jak
provedených na pracovišti zadavatele, tak z ePACS vedle sebe.

KIS_462 U každého vyšet ení KIS zaznamenává formou parametrického
záznamu ově eného na číselník oprávněných uživatelů jméno
radiologického asistenta a léka ů, kte í popis prováděli. KIS
umožňuje zápis identifikačních údajů minimálně dvou léka ů.

KIS_463 IT ešení procesů zobrazovacích pracovišť umožňuje systém
vícestupňové kontroly podobně jako ostatní části KIS; dokud není
výsledný popis schválen oprávněným specialistou, není dostupný
uvnit KIS klinickým pracovištím.

KIS_464 V IT ešení procesů zobrazovacích pracovišť, a to zejména část
určená pro popis angiointervenčních a CT vyšet ení, je dostupná
funkce pro péči o ambulantního pacienta na stacioná i/výkonovém
pracovišti včetně podpory vytvá ení dokumentace pro sledování
pacienta po vazografickém vyšet ení včetně podpory záznamu

102
sledování životních funkcí pacienta.

KIS_465 IT ešení procesů zobrazovacích pracovišť má v sobě
implantovaný nástroj pro označení zajímavých p ípadů (stačí
zaškrtávací parametrické pole, pop . vybavené textovým polem D_II Vyberte
pro komentá ). D_II Vyberte

KIS_466 IT ešení procesů zobrazovacích pracovišť má v sobě P Vyberte
implantovaný nástroj pro p ípravu meziklinických seminá ů s účastí
radiologů, tj. p ipravit sestavu prezentovaných pacientů a výběr P Vyberte
vyšet ení, která by měla být demonstrována – funkce na urychlení P Vyberte
p ístupu k podstatným snímkům. P Vyberte
D_II Vyberte
KIS_467 V IT ešení procesů zobrazovacích pracovišť je možné k popisu D_II Vyberte
vyšet ení p ipojit tzv. binární soubor (nap . fotografii P Vyberte
intravaskulárního portu, žilního vstupu). Typem p ipojovaného P Vyberte
souboru budou i PDF soubory se skeny dotazníků anebo
informovaných souhlasů podepsaných pacientem. Dále je možné
vytvá ení anebo integrace šablon popisů vyšet ení (nap . jako je PI
RADS pro pacienty s tumorem prostaty).

KIS_468 IT ešení procesů zobrazovacích pracovišť má v rámci KIS
zp ístupněný náhled na epikrízu hospitalizovaného pacienta, ze
které je možné p enášet požadované informace do okna pro popis
nálezu.

KIS_469 IT ešení procesů zobrazovacích pracovišť v okně pro popis
podporuje vytvá ení šablon pro vybrané typy vyšet ení (nap . UZ
Doppler renálních tepen, perfuzní CT mozku, angiografie,
intervence nevaskulární).

KIS_470 V souladu s obecnými vlastnostmi KIS si jednotliví léka i mohou
vytvá et kromě globálních šablon i osobní šablony textů dostupné
v oknech pro záznam textových informací.

KIS_471 IT ešení procesů zobrazovacích pracovišť je navrženo tak, aby jej
bylo možné integrovat s komerčně dostupnými SW pro p evod
mluveného slova na text (nap . od firmy NovaVoice®).

KIS_472 V průběhu analýzy ve fázi prováděcího projektu uchazeč navrhne
způsob roz azování vyšet ení na jednotlivé modality a instalované
p ístroje Radiologické kliniky p ímo z workflow fronty v rámci IT
ešení procesů zobrazovacích pracovišť.

KIS_473 Popis radiologem je členěn do následujících textových oken:
· stručný požadavek vyšet ení/klinická otázka
· popis nálezu
· závěr a doporučení

KIS_474 IT ešení procesů zobrazovacích pracovišť má svůj oddíl určený
pro výkaznictví pro plátce péče a fakturaci samoplátcům.

Specifika IT řešení procesů zobrazovacích pracovišť pro pracoviště nukleární
medicíny

KIS_475 Zadavatel požaduje, aby IT ešení procesů zobrazovacích
pracovišť provedlo z výkazu pro zdravotní pojišťovnu automatickou
kopii: D_II Vyberte

· kódu použitého radiofarmaka
· velikost aplikované aktivity (jednotkou je MBq)
do parametrického okna v popisu nálezu z vyšet ení (konkrétní

103
umístění importovaných údajů bude stanoveno v rámci analytické
fáze projektu).

KIS_476 U každého vyšet ení na nukleární medicíně musí u konkrétního P Vyberte
vyšet ení zůstat použité hodnoty výšky a hmotnosti dohledatelné D_II Vyberte
zpětně jako parametrický údaj.

KIS_477 IT ešení procesů zobrazovacích pracovišť umožňuje vystavit
žádanku na radiologické, mikrobiologické, patologické,
biochemické vyšet ení a vyšet ení krevního obrazu. Je-li žádanka
v IT ešení procesů zobrazovacích pracovišť vystavena, má léka
nukleární medicíny nárok na p ístup k těmto výsledkům.

Zobrazovací vyšetření z pohledu klinika na ambulancích nebo lůžkovém oddělení
Pro níže popsanou funkcionalitu zadavatel bere na vědomí, že léka musí být
p ihlášen svými p ístupovými údaji k pracovní stanici Windows v rámci zabezpečené
sítě zadavatele.

KIS_478 Klinický léka smí zobrazit výhradně specialistou uvolněný popis
zobrazovacího vyšet ení – kontrolní opat ení. Pokud je p i
vyšet ení STATIM zp ístupněn k nahlédnutí pracovní popis od P Vyberte
léka e bez specializované způsobilosti nebo zvláštní odborné P Vyberte
způsobilosti, KIS na tuto skutečnost výrazně graficky upozornění u P Vyberte
zobrazení na monitoru i u výsledku tištěného na papír. P Vyberte
D_II Vyberte
KIS_479 Pokud dojde k revizi nálezu a popis vyšet ení je radiologem se D_II Vyberte
specializovanou způsobilostí změněn, v KIS musí zůstat dostupný
i původní popis včetně data a času jeho uvolnění pro klinické
pot eby – takový popis je z etelně označen jako pozměněný (nap .
p eškrtnutím, petitem – způsob navrhne uchazeč); původní,
nesprávný popis se p i editaci závěrečné zprávy nep enáší k další
editaci. Nový revidovaný popis bude automaticky odeslán klinikovi.

KIS_480 Provedená zobrazovací vyšet ení jsou u konkrétního pacienta
zobrazená v tabulce obsahující:

· datum a čas vyšet ení,
· modalitu vyšet ení,
· lokalizaci vyšet ení p evzatou z parametrického okna

KIS_481 Údaje v tabulce lze rychle uspo ádat anebo filtrovat kliknutím na
záhlaví sloupce podle uvedených kategorií. Vyšet ení jsou
primárně azena podle data po ízení a naho e je časově poslední
vyšet ení.

KIS_482 Po výběru vyšet ení KIS se zobrazí kompletní popis vyšet ení
včetně odkazu/tlačítka ve formulá i, jehož prost ednictvím se
spustí prohlížeč PACS systému JIVEX a otev e zvolené vyšet ení
u konkrétního pacienta díky funkční integrační vazbě.

KIS_483 KIS analogicky, ale odděleně od vyšet ení provedených na
pracovištích zadavatele, zobrazuje dokumentaci, která je uložená
v systému ePACS provozovaném na území České republiky.
Dostupná vyšet ení z ePACS jsou azena v tabulce podle data a
času zhotovení vyšet ení. Jejich výběrem se otev e popis včetně
odkazu/tlačítka ve formulá i, jehož prost ednictvím se spustí
prohlížeč systému JIVEX a otev e zvolené vyšet ení u konkrétního
pacienta díky funkční integrační vazbě.

104
2.2.13 Dočasná pracovní neschopnost, eNeschopenka D_II Vyberte

KIS_484 ešení procesu DPN a eNeschopenky v KIS musí umět zajistit P Vyberte
komplexní zpracování agendy eNeschopenek a musí vycházet P Vyberte
z platné legislativy tj. zákona č. 187/2006 S. o nemocenském D_II Vyberte
pojištění, v platném znění ke dni akceptace díla, protože už od 1.
1. 2020 je elektronické vedení dokumentace DPN umožněno
zákonnými normami. S ohledem na probíhající, ale pokročilé
legislativní úpravy zadavatel vyžaduje podporu vystavování tzv.
eNeschopenky podle právní úpravy a metodiky vydané MPSV či
ČSSZ. Kdekoli se o eNeschopence hovo í v textu této zadávací
dokumentace, zadavatel ji považuje za funkci povinnou nejd íve
od fáze „D_II“ a neplatí povinnost mít funkcionalitu p ipravenou už
ve fázi p edložení nabídky v rámci ve ejné zakázky (znak „P“).
Konkrétní načasování zadavatel s dodavatelem dohodne v rámci
prováděcího projektu.

KIS_485 Funkcionalita záznamu DPN musí být p ístupná na všech
ambulantních i lůžkových stanicích – všem léka ům, vybraným
sestrám a administrativním pracovnicím a to na úrovni p íprava
(sestry, administrativní pracovnice) a schválení a doplnění údajů
(léka )

KIS_486 Agenda by měla obsahovat vystavování, evidenci, sledování
stavu pracovních neschopenek (dále PN) až na jednotlivé
formulá e – tj. pohyb neschopenek od jejího vystavení, p es
jednotlivé změny - včetně p edání pacienta do jiného za ízení,
p ijetí pacienta s neschopenkou vystavenou od jiného léka e a až
po ukončení DPN a dále i archivaci vystavených DPN

KIS_487 Systém musí umět vystavit „Potvrzení o trvání dočasné pracovní
neschopnosti nebo karantény“ a evidovat jej, p ípadně v rámci
FNHK zaslat na mzdovou účtárnu do SW Vema.

2.3 Požadavky na specifické funkcionality

2.3.1 Doprava
2.3.1.1 Obecné požadavky

KIS_488 KIS musí umožnit tvorbu žádanky na dopravu. Pro ilustraci D_II Vyberte
současná forma žádanky viz Obrázek 30. D_II Vyberte

KIS_489 KIS musí mít možnost samostatné volby pro žádanku na
dopravu včetně p edvyplněných položek ze všech procesů
ešených v rámci KIS včetně – nap . lůžka, ambulance, RDG.

2.3.1.2 Žádanka na sanitní dopravu dle požadavků legislativy včetně integračních
vazeb

KIS_490 Obsah žádanky v KIS a P íkazu ke zdravotnímu transportu musí D_II Vyberte
být v souladu s Metodikou VZP pro po izování a p edávání D_II Vyberte
dokladů ve verzi platné k datu akceptace etapy.

KIS_491 Žádanka je zdrojem dat pro P íkaz ke zdravotnímu transportu a
proto musí obsahovat veškerá data v době žádosti známá.

105
KIS_492 KIS musí umožnit tisk žádanky na papír formátu A4, který na D_II Vyberte
zadní straně obsahuje závazek pacienta, že uhradí p ípadný
doplatek. D_II Vyberte

KIS_493 Veškeré používané číselníky dopravy nemocnice musí být D_II Vyberte
součástí KIS. Aktuálně používané číselníky budou součástí D_II Vyberte
Prováděcího Projektu. D_II Vyberte
D_II Vyberte
KIS_494 KIS musí disponovat aktuální logikou tvorby žádanky zadavatele
popsanou v Prováděcím Projektu (nap . odkud, kam, nejbližší D_II Vyberte
SZZ).
D_II Vyberte
KIS_495 P i psaní žádanky bude možné opravit nebo doplnit osobní D_II Vyberte
údaje o pacientovi dle oprávnění uživatele. D_II Vyberte
D_II Vyberte
KIS_496 KIS musí mít možnost p edvyplnění nejčastějších situací
minimálně v rozsahu doprovod, odůvodnění doprovodu, mobilita,
důvod p epravy, atd.

KIS_497 KIS bude mít možnost funkční klávesy pro vyplnění odkud, kam
a možnosti volby žádajícího pracoviště, nebo adresy pacienta.

KIS_498 KIS musí využít a zapracovat číselníky místopisu FNHK – kde je
specifikováno pracoviště, název pracoviště, umístění pracoviště
a telefonní číslo nap :
1122 - 2.int.lůžkové oddělení E - 10/4p žlutá - 4762

KIS_499 KIS musí podporovat možnost tisku žádanky pouze po odeslání
žádanky.

KIS_500 KIS musí umožnovat náhled tisku p ed odesláním žádanky.

KIS_501 KIS musí mít výchozí nastavení tisku žádanky ve dvou kopiích.

KIS_502 KIS musí disponovat možnosti kopírování p edchozí žádanky dle
nastavených oprávnění uživatele.

Obrázek 30 Současná podoba žádanky.

106
2.3.2 AISLP

KIS_503 AISLP v intranetové Mikro-verzi bude integrován v rámci KIS pro D_II Vyberte
možnost vyvolání z jakéhokoliv místa KIS. D_II Vyberte

KIS_504 P i preskripci léků ambulantním pacientům a p i ordinaci léčivých
p ípravků pro hospitalizované pacienty možnost zobrazení na
úrovni zadávaného léku.

2.3.3 Sledování pacientů léčených v centrech

KIS_505 KIS umožní sledování, evidenci zadávání a uchovávání
vybraných informací o všech epizodách léčeb centrových
pacientů. Každý záznam léčby je tvo en informacemi o pacientovi, D_II Vyberte
diagnóze onemocnění, začátku a konci léčebné epizody a o
vlastní léčbě (co se léčí, čím se léčí, kde se léčí). D_II Vyberte
D_II Vyberte
KIS_506 Evidence bude mít vazbu na léky skutečně vykázané na D_II Vyberte
pojišťovny (ZULP, recepty). D_II Vyberte

KIS_507 KIS poskytne p ehledy adeptů na zahájení a ukončení v evidenci,
upozorňuje na změnu léčby u pacientů, na změnu pojišťovny u
pacientů, na p ípadná úmrtí pacientů vedených v evidenci.

KIS_508 KIS umožní kontrolu vykazovaných dat (vazby rodného čísla či
jiného identifikátoru, diagnózy, kombinace léků a diagnóz,…).

KIS_509 KIS umožní sestavit a exportovat reporty pro zdravotní pojišťovny
a zpracovat zpětnou vazbu od zdravotních pojišťoven (dle
platných metodik jednotlivých pojišťoven).

2.3.4 IT řešení procesů klinického farmaceuta
2.3.4.1 Výkaz výkonů pro pojišťovnu a ÚZIS

KIS_510 KIS musí umět sledovat údaje o vstupní kontrole (komplexní D_II Vyberte
zhodnocení míry rizikovosti) dle definice uvedené v platné
úhradové vyhlášce. D_II Vyberte
D_IV Vyberte
KIS_511 KIS musí evidovat počty vstupních kontrol pro následné odeslání D_IV Vyberte
na ÚZIS. D_II Vyberte

KIS_512 KIS musí umět nastavení farmakoterapeutických plánů
racionalizace.

KIS_513 KIS musí disponovat funkcí pro ově ení účinnosti plánu.
KIS_514 KIS musí umožnit účtovat výkony pojišťovně včetně možnosti

náhledu do historie účtovaných výkonů klinickým farmaceutem u
konkrétního pacienta.

2.3.4.2 Pro management nemocnice

KIS_515 KIS umožní sledování statistických údajů o činnosti klinického D_IV Vyberte
farmaceuta a realizovaných zásazích (způsob jak zdokumentovat
sledování interakcí, bez nutnosti úpravy farmakoterapie).

107
KIS_516 KIS umožní vedení evidencí minimálně v těchto oblastech:
· IPLP a neregistrovaných LP
· pacientů v nízkém riziku (nejsou vykazování na D_IV Vyberte
pojišťovnu) D_II Vyberte
· konzultací – vyžádané konzilium, externí lékové dotazy D_II Vyberte
· následných opakovaných kontrol a D_II Vyberte
farmakoterapeutických doporučení nad rámec výkonů
hrazených ze zdravotního pojištění D_II Vyberte

KIS_517 KIS umožní nastavení a evidence individuálních rizikových faktorů
dle klinických oborů (prematurita u novorozenců, chemoterapie u
onkologie, cystická fibróza, biologická léčba, pracovní
neschopnost atp.)

KIS_518 KIS umožní rozlišení záznamů a doporučení viditelných pro
klinického farmaceuta a pro léka e.

KIS_519 KIS umožní evidenci údajů uvedených na snímku formulá e, viz
obrázek 31.

KIS_520 KIS umožní možnost evidence rizikových faktorů dle Vyhlášky č.
421/2016 Sb. (str. 6467) minimálně v rozsahu:

· polypragmazie − v chronické medikaci pacienta je 8 a
více systémově užívaných léčiv;

· léčivo s úzkým terapeutickým oknem (nap . vankomycin,
aminoglykosidová antibiotika, fenytoin, karbamazepin,
kyselina valproová, warfarin, LMWH (nízkomolekulární
heparin) v terapeutické dávce, cyklosporin, everolimus,
takrolimus, temsirolimus, digoxin, teofylin a p ípadně další
léčiva, jejichž plazmatické hladiny je t eba sledovat p i
úpravě dávkování p i změně funkcí eliminačních orgánů,
p i projevu nežádoucího účinku nebo p i sledování
dopadu lékové interakce);

· léčivo s vysokým interakčním potenciálem; léčivo s
popsanými/dokumentovanými lékovými interakcemi −
popisované v literatu e jako velmi závažné nebo závažné
(značené číselně, nebo pomocí písmen – podle použité
klasifikace);

· renální insuficience – hodnota glomerulární filtrace je
rovna nebo menší než 30 ml/min;

· laboratorní známky hepatální insuficience – albumin < 20
g/l, ALT, AST, GMT, bilirubin nad trojnásobek horní
hranice normy;

· další významné změny biochemických a/nebo
hematologických parametrů;

· pacient v intenzivní péči;
· diagnóza: diabetes mellitus (dle MKN: E10 – E14) – na

terapii PAD a/nebo inzulínu;
· epilepsie (dle MKN: G40, G41) na terapii antiepileptiky;
· fibrilace síní (I48);
· nádorové onemocnění (dle MKN: C) – kurativní nebo

paliativní farmakoterapie;
· pacient s dlouhodobou (déle než 1 týden) léčbou

systémovými kortikoidy nebo jinými imunosupresivy
· pacient s parkinsonským syndromem (dle MKN: G20,

G21)

108
Obrázek 31 Snímek formuláře s datovými poli, která požadujeme evidovat v rámci IT řešení procesů klinického farmaceuta.

109
2.3.5 Funkce KIS pro sledování chirurgických komplikací

KIS_521 KIS musí obsahovat ešení pro zaznamenávání a
vyhodnocování komplikací po chirurgických výkonech. Ke
klinické události typu chorobopis musí být možné p ipojit údaje, D_II Vyberte
kterých konečný počet a datové typy budou součásti
prováděcího projektu.
Minimální rozsah údajů:

· Klinika
· Číslo chorobopisu.
· Interní č. chorobopisu kliniky.
· Dg pacienta.

· Specifikace - bližší specifikace odbornosti.

· Ambulantní/hospitalizace.

· Datum začátku hospitalizace.
· Datum ukončení hospitalizace.
· Operatér.

· Druh operace (akutní/plánovaná/ /žádná).

· Výkony (výběr z číselníku, možno zadat více hodnot):
o Datum zavedení.

· Iatrogenní poškození (A/N).

· ASA (I/II/III/IV/Neurčeno).
· BMI.

· Počet dnů na JIP.
· Reoprerace (A/N):

o Důvod reoperace (etapový výkon/jiný
důvod/komplikace/nezadáno).

o Jiný důvod reoprerace (text).
· Rehospitalizace (A/N):

o Důvod rehospitalizace (etapový
výkon/komplikace/nezadáno).

o Jiný důvod rehospitalizace (text).
· Počet reoperací.
· Úmrtí (A/N).

· Komplikace (výběr z číselníku, možno zadat více
hodnot):
o Datum zavedení.
o Dindo
(I/II/III/IIIa/IIIb/IV/IVa/IVb/IVc/IVd/V/Va/Vb).

· Následky (zhojeno/nezhojeno/ /neurčeno).
· Handicap (A/N).

· Dg. (výběr z číselníku, možno zadat více hodnot).

Komplikace se vybírají z číselníku, který má 2 úrovně a
stromovou strukturu. Komplikace bude možné p i azovat buď
všem pracovištím, nebo každá organizační jednotka na úrovni
kliniky a všechny jí pod ízené organizační jednotky mohou mít
komplikace p i azené pouze pro sebe. P i výběru komplikací
se zobrazují pouze komplikace vázané na Dg. Údaje o
komplikaci:

· Název.

· Skupina komplikací.

110
· Nozokomiální výpočty (A/N).
· Kultivace, pro výpočty (A/N).
· Výpočty podle specializací (A/N).
· Historická (A/N).

KIS_522 KIS musí umožnit u všech již zadaných údajů v rámci
dokumentace pacienta automatický p enos parametrických
D_II Vyberte
údajů do IT ešení sledování chirurgických komplikací. D_II Vyberte

2.3.6 Funkce pro proces onkologického případu

KIS_523 KIS musí obsahovat IT ešení pro zaznamenávání a
vyhodnocování onkologických p ípadů.
K pacientovi musí být možné p ipojit údaje, kterých konečný
počet a datové typy budou součásti dokumentu Prováděcí
projekt.
Minimální rozsah údajů:

o Staging:
§ cT
§ cN
§ cM
§ p i M1 – up esnění orgánu
§ Klinické stádium
§ Histologie
§M
§G

§ Datum stanovení diagnózy
§ Pracoviště, které stanovilo dg.
§ Pracoviště, které stanovilo definitivní

staging
o Primární léčba - záměr

§ Kurativní
§ Paliativní
§ Symptomatická
o Chirurgie ano/ne
§ Datum

§ Typ chirurgického výkonu
§ pT
§ pN
§ Komplikace
o Radioterapie ano/ne
§ P edoperační
§ Pooperační
§ Samostatná
§ Paliativní
§ Od-do, dávka, počet frakcí, lokalita
§ Komplikace
o Systémová protinádorová farmakoterapie
§ Chemoterapie ano/ne
§ Hormonoterapie ano/ne
§ Biologická léčba ano/ne
§ Imunoterapie ano/ne

111
o Pokud ano, pak:
§ Neoadjuvatní
§ Adjuvantní
§ Konkomitantní s RT
§ Kurativní
§ Paliativní
§ Typ chemoterapie
§ Od-do, počet cyklů
§ Komplikace

o Restaging:
§ Kompletní remise, Parciální remise,
Stable Disease, Progressive Disease

- Onkolog. - odstup:
o Remise:
§ Remise 3M
§ Remise 6M
§ Remise 1R
§ Remise 2R
§ Remise 3R
§ Remise 4R
§ Remise 5R
§ Remise 6R
§ Remise 7R
§ Remise 8R
§ Remise 9R
§ Remise 10R
o Stabilní:
§ Bez progrese 3M
§ Bez progrese 6M
§ Bez progrese 1R
§ Bez progrese 2R
§ Bez progrese 3R
§ Bez progrese 4R
§ Bez progrese 5R
§ Bez progrese 6R
§ Bez progrese 7R
§ Bez progrese 8R
§ Bez progrese 9R
§ Bez progrese 10R
o Recidíva:
§ Recidiva 3M
§ Recidiva 6M
§ Recidiva 1R
§ Recidiva 2R
§ Recidiva 3R
§ Recidiva 4R
§ Recidiva 5R
§ Recidiva 6R
§ Recidiva 7R
§ Recidiva 8R
§ Recidiva 9R
§ Recidiva 10R

112
o Popis recidivy:

§ Recidiva – lokální, datum

§ Recidiva - regionální, datum

§ Vzdálená metastáza – datum, počet,
lokalita

§ Úmrtí datum

§ Souvislost úmrtí s onko onemocněním
§ Léčba relapsu - operace
§ Léčba relapsu - RT
§ Léčba relapsu – systémová léčba

KIS_524 KIS musí umožnit nastavení onkologického p ípadů, kterých
může být více typů, kdy v rámci jednoho typu onkologického
p ípadu nemusí docházet k zaznamenávání všech údajů, D_II Vyberte
p ípadně může docházet k záznamu údajů specifických pro
daný typ p ípadu. D_II Vyberte
D_II Vyberte
KIS_525 KIS musí umožnit u všech již zadaných údajů v rámci D_IV Vyberte
dokumentace pacienta automatický p enos parametrických

údajů do onkologického p ípadu.

KIS_526 KIS umožní sledování vícero onkologických p ípadů u jednoho
pacienta a to i stejného typu.

KIS_527 V rámci implementace požadujeme p evod stávajících dat do
nového KIS.

2.3.7 Obecné požadavky na žádanky pro laboratorní komplement

KIS_528 KIS musí umožňovat vystavení žádanky pro, p íjmu výsledků a
zobrazení výsledků minimálně v rozsahu níže uvedených
laborato í a pracovišť zadavatele: P Vyberte
D_II Vyberte
· Ústav klinické biochemie a diagnostiky Vyberte
· Ústav klinické mikrobiologie P
· Ústav klinické imunologie a alergologie
· Hematologickou laborato IV. interní kliniky
· Transfuzní oddělení
· Oddělení léka ské genetiky
· Patologie

KIS_529 KIS musí být integrován se systémy jednotlivých komplementů
a to obousměrně tak, aby bylo možné veškeré žádanky
zadané v KIS p enášet elektronicky do LIS jednotlivých
laborato í, a zároveň aby bylo možné veškeré laborato emi
uvolněné výsledky p enést do KIS. Podrobnosti k popisu
integrace viz 4 Minimální požadavky na integrační platformu
včetně zhotovení komunikačních vazeb s vyjmenovanými
systémy

KIS_530 Každá žádanka vystavovaná v KIS musí splňovat obsahem
p enášených parametrů všechny požadavky, které specifikuje
aktuálně platná Metodika pro po izování a p edávání dokladů
VZP ČR a které odpovídají platné právní úpravě, požadavkům
normy ČSN EN ISO15189 v platných verzích.

113
KIS_531 Uchazeč navrhne ešení jednoznačné identifikace vzorků a
žádanek – zadavatel p ipouští pro označení žádanky i vzorku
jak tisk štítků s čárovým kódem z KIS; v této souvislosti KIS D_II Vyberte
umožní vytisknout více štítků pro jednoho pacienta podle typu D_II
biologického materiálu. Vyberte

KIS_532 Sestra vystavující žádanku tak činí na podkladě ordinace Vyberte
léka e – žádanka v KIS ponese podpis ordinujícího léka e Vyberte
dodaný prost ednictvím číselníku v KIS; aby se zúžil seznam Vyberte
léka ů, číselník bude omezený na léka e, kte í jsou trvale Vyberte
p iděleni ke konkrétnímu pracovišti zadavatele. Součást finálně Vyberte
vytvo ené žádanky je i informace pro sestry o pot ebném počtu
a typech jednotlivých zkumavek a nádob v souladu
s odběrovým systémem, který využívají pracoviště zadavatele,
včetně pot ebného množství biologického materiálu.
Možnost p ipravit žádanku v p edstihu a odeslat ji až po
odběru materiálu, musí být jasně označeny odeslané a
neodeslané žádanky.
Bude možnost vygenerovanou žádanku vytisknout a společně
s identifikačním štítkem p edat p ípadně na jiné oddělení
provádějící odběr materiálu (nap . punkce, chirurgické zákroky
apod.)

KIS_533 Výsledky p enesené z LIS musí uvnit KIS fungovat jako
parametrické údaje, se kterými KIS bude schopen dále
pracovat – zobrazovat je tabelárně i graficky, p enášet do D_II
ambulantních anebo propouštěcích zpráv či do jiných D_II
formulá ů, bude-li to relevantní. Výsledek, který byl do KIS
p enesen a následně laborato í korigován nebo zrušen, je P
z etelně označen – formu zvolí dodavatel (nap . p eškrtnutí,
petit) a pro editaci ambulantních nebo závěrečných zpráv N
z hospitalizace se nenabízí. D_II

KIS_534 Zadavatel požaduje, aby KIS p ebíral z LIS komplementárních
pracovišť i textové části výsledku a aby umožňoval p ipojit i
grafickou podobu výsledku – nap . grafy distribuce hodnot,
histogramy z analyzátoru (alespoň formáty rtf, html, PDF, jpg,
png).

KIS_535 KIS musí umožňovat zobrazovat „stav“ výsledku – nap .
p edběžný, konečný, opravný. Všechny zobrazené výsledky
musí zůstat v KIS s p íslušným označením, tj. historie výsledku
musí zůstat zachována a konečný výsledek nesmí p epsat
hodnotu p edběžného výsledku zobrazeného klinikovi, protože
ten už mohl na podkladě p edběžného výsledku p ijmout
rozhodnutí o léčebném postupu. Zároveň ale KIS musí
umožňovat skrýt všechny historické verze výsledku a zobrazit
pouze aktuální (tj. zobrazit pouze konečný výsledek nebo
poslední opravný, pokud došlo k opravě). Zobrazení pouze
aktuálně platných verzí výsledků je také výchozím stavem
nastavení pro zobrazení. Zcela zrušené výsledky musí být
jednoznačně a nezaměnitelně označeny (nap . p eškrtnutím).

KIS_536 KIS umožní ešení neshod výsledků – nap . v p ípadě
mimo ádných událostí, změny identifikace, kdy z LIS byl do
KIS konkrétnímu pacientovi p enesen nesprávný výsledek. KIS
musí být schopen uvést k výsledku záznam o mimo ádné
události, o tom, kdo požádal a o důvodu zrušení výsledku.

KIS_537 Součástí analytické fáze projektu bude vy ešení otázky, jakým

114
způsobem budou synchronizovány údaje z Master Patient
Indexu v KIS do LIS.

KIS_538 Uchazeč zajistí synchronizaci všech číselníků pot ebných pro D_II Vyberte
vystavování žádanek a p edávání výsledků. D_II Vyberte

KIS_539 Zadavatel požaduje, aby oddělení nemocniční hygieny ídilo P Vyberte
systém upozornění na epidemiologicky závažné nálezy (alert,
nap . ikonou či vyskakujícím oknem) v KIS upozorňující léka e
na kolonizaci nebo infekci multirezistentními choroboplodnými
zárodky – k této práci pot ebuje p ístup ke kompletním
výsledkům Ústavu klinické mikrobiologie.

KIS_540 Zadavatel požaduje od uchazeče takové IT ešení práce se
žádankami, aby bylo možné individualizovaně sestavit
jednotlivá vyšet ení do logických skupin a vytvá et hotové sady
požadavků na vyšet ení podle zdravotního stavu
vyšet ovaného pacienta. Takové seskupování druhů vyšet ení,
jejich p idávání a ubírání ze spektra nabízených metod musí
zvládat proškolený zaměstnanec zadavatele.

2.3.8 IT řešení pro zobrazování laboratorních komplementárních výsledků

KIS_541 KIS musí disponovat prohlížením a zobrazováním výsledků
laboratorních komplementárních vyšet ení včetně možnosti
výběru konkrétních vyšet ení a v rámci nich konkrétních P Vyberte
namě ených hodnot (nap . zaškrtávacím polem, časovým P Vyberte
intervalem od-do). N Vyberte
D_II Vyberte
KIS_542 KIS musí umožnit výběr alespoň 5 typů laboratorních vyšet ení P Vyberte
včetně možnosti výběru namě ených hodnot a zobrazit data ve D_II Vyberte
formě tabulky včetně možnosti grafického zobrazení.
D_II Vyberte
KIS_543 Možnost zahrnout do výběru pro grafické zobrazení 6 a více
typů vyšet ení je výhodou.

KIS_544 KIS musí umět zvolený výběr laboratorních vyšet ení a u nich
získaných hodnot exportovat do souboru.

KIS_545 P i editaci závěrečné zprávy musí mít léka možnost volby od
p enesení všech výsledků od všech laboratorních vyšet ení na
straně jedné až po výběr jednotlivých hodnot pouze od
vybraných laboratorních vyšet ení.

KIS_546 KIS musí poskytovat možnost ALERTů u hlídaných položek,
které změnila nebo doplnila laborato jako je nap íklad
diagnóza.

KIS_547 KIS musí mít možnost zobrazit seznam vyšet ení, která byla
zvolenému pacientovi provedena. Výchozí t ídění seznamu
vyšet ení musí být nastavitelné proškoleným správcem
aplikace, minimálně však dle těchto položek a jejich
kombinace:

· Datum a čas.
· Pracoviště (žadatel).
· Metoda - u vyšet ení patologického, mikrobiologického

a RTG typu (obecně u vyšet ení, kde obvykle celé
vyšet ení odpovídá jedné metodě (nap . biopsie,
cytologie …).

115
KIS_548 U vyšet ení laboratorního typu (nap . biochemického,
hematologického), tedy obecně u vyšet ení, která obsahují
více jednotlivých metod, musí být jednotlivé metody v rámci D_II Vyberte
výsledku azeny dle požadavků laborato e. Tento požadavek
bude p edáván p es lokální číselník laboratorních položek
(LCLP) dle DASTA rozhraní. KIS musí umožňovat aktualizaci
tohoto číselníku opakovaným nahráváním LCLP. LCLP bude
poskytován laborato í zasílající p íslušné výsledky. Není
p ípustné, aby úprava číselníku LCLP v KIS musela být
prováděna ručně.

116
2.4 Požadavky na komplexní řešení procesu pořizování výkazů a
vyúčtování zdravotní péče pro všechny typy plátců péče (přípustné
řešení - modul „Pojišťovna“)

Zadavatel pod pojmem „Pojišťovna“ rozumí integrální součást KIS pro vykazování
zdravotní péče, vyúčtování zdravotní péče zdravotním pojišťovnám i ostatním typům
plátců včetně podpůrných mechanizmů KIS.
Zadavatel pod pojmem „Položka“ rozumí, že se jedná o výkony a skupiny číselníků
léčivých p ípravků (LP), zdravotnických prost edků (ZP) a stomatologických výrobků
(kód skupiny 1,2,3,4)

2.4.1 Pořízení, editace a kontrola dat

POJ_001 KIS musí v rámci procesu po izování a editace dat podporovat P Vyberte
usnadnění vykazování, nap . p es možnost definování zkratek pro
skupiny Položek, provázání p eddefinovaných textů p i vytvá ení P Vyberte
záznamů do zdravotnické dokumentace s p eddefinovanými P Vyberte
skupinami Položek apod.. D_II Vyberte
P Vyberte
POJ_002 KIS musí obsahovat funkcionalitu pro automatické založení účtu P Vyberte
p i p íjmu pacienta k hospitalizaci. P Vyberte
P Vyberte
POJ_003 KIS musí obsahovat podporu p enosu diagnóz klinické části do P Vyberte
účtu. P Vyberte
P Vyberte
POJ_004 KIS musí obsahovat podporu vykazování podaných léčiv P Vyberte
z medikace.

POJ_005 KIS musí umět automatické vykazování OD JIP dle vyplněného
TISS záznamu a dalších obligatorních podmínek pro vykázání
ošet ovacího dne.

POJ_006 KIS musí umět automatické vykazování standardních OD a musí
obsahovat podporu vykazování Kategorie pacienta v ústavní péči.

POJ_007 KIS musí obsahovat podporu automatického vykazování
vybraných výkonů (signální kódy, poplatky, výkon 09555, markery
UPV apod.).

POJ_008 KIS musí umožnit p i editaci jednotlivých položek účtu vstup do
p íslušných číselníků.

POJ_009 KIS musí obsahovat funkcionalitu pro sledování historie změn
jednotlivých dokladů (založení dokladu, editace), vč. záznamu
změn obsahu.

POJ_010 KIS musí umožnit provádět hromadné změny nad uživatelsky
sestaveným seznamem dokladů (nap . změnu hodnoty jednoho
parametru či záměnu dané hodnoty parametru za jinou).

POJ_011 KIS musí obsahovat funkcionalitu pro vkládání poznámek k
jednotlivým dokladům nebo nad seznamem dokladů se
zachováním historie těchto poznámek.

POJ_012 KIS musí obsahovat funkcionalitu pro automatickou změnu typu
dokladu (01 -> 06) v p ípadě hospitalizace pacienta.

117
POJ_013 KIS musí umět pracovat s tzv. “Průměrnými cenami lékárny“ D_II Vyberte
(Podrobnosti k popisu integrace viz 4 Minimální požadavky na
integrační platformu včetně zhotovení komunikačních vazeb D_II Vyberte
s vyjmenovanými systémy), kdy cena Položky bude určena jako P Vyberte
min. z nastavené ceny z lékárny a max. úhrady z číselníku VZP
Algoritmus p i po izování dat je následující:
P i po ízení Položky systém hledá v číselníku průměrných cen,
zda je cena nižší nebo rovna ceně číselníkové – v takovém
p ípadě cenu ponechá. Pokud je průměrná cena lékárny vyšší než
číselníková, do účtu se zapíše cena číselníková. Pozn. stejný
postup platí i pro položky číselníku NLEKY.

POJ_014 KIS musí umožnit evidenci požadavků na extramurální péči, a to
ve struktu e, která umožní vytvá et p ehledy a statistické výstupy.

POJ_015 KIS musí umět vystavit p íslušné druhy dokladů dle poskytované
péče, nap . i doklady 05, 14, 34, 80, 81, 82.

2.4.2 Pořízení položky (výkon, ZULP/ZUM) vyžadující schválení RL - Žádanka o
schválení

POJ_016 KIS musí umožnit samostatné vyvolání formulá e „Žádanky o P Vyberte
schválení revizním léka em“, musí být k dispozici kdykoliv během P Vyberte
práce léka e, sestry i administrativního pracovníka. P Vyberte
D_II Vyberte
POJ_017 KIS musí evidovat vystavené žádanky o schválení RL, do kterých
bude možné zanést informaci o schválení (či neschválení). D_II Vyberte

POJ_018 KIS p i po ízení Položky, která vyžaduje schválení RL, musí o
této skutečnosti uživatele upozornit a nabídnout mu vyplnění
formulá e s p edvyplněnými údaji pacienta

POJ_019 KIS bude mít možnost p i po ízení již schválené Položky
propojení na existující schválenou žádanku (pro účely kontroly na
nasmlouvané Položky).

POJ_020 KIS bude mít možnost pohledu na schválenou žádanku tak, aby
bylo z ejmé, se kterými po ízenými položkami byla žádanka
propojena (nap . p i schválení X balení léku musí být uživatelsky
snadno dohledatelné, kolik balení již bylo podáno, tj. po ízeno do
účtů, a kolik schválených podání ještě zbývá).

2.4.3 Kontroly

Základní a vyžadované kontroly musí plně respektovat „Pravidla pro vyhodnocení
dokladů ve VZP ČR“ v platné verzi.

POJ_021 KIS musí obsahovat kontroly, které jsou funkční v průběhu
celého procesu od vzniku dat až po konečné zpracování. Tyto
kontroly musí být administrátorsky nastavitelné na nejnižší
organizační jednotku, plátce, odbornost, diagnózu, výkon, lék, P Vyberte

zdravotnický prost edek apod. Zároveň musí být nastavitelný
okamžik jejich spuštění.

POJ_022 KIS musí disponovat spustitelnými kontrolami p ed vyúčtováním, P Vyberte
tj. kontrolami, které budou prováděny p es veškerá data v KIS,
nap . frekvence, kombinace výkonů, léků apod.

118
POJ_023 KIS musí disponovat kontrolami v souladu s pravidly pro P Vyberte
vyhodnocování dokladů ve VZP ČR.

POJ_024 KIS musí mít možnost administrátorského nastavení stupně
kontrol/vynutitelnosti opravy chyb v celém průběhu práce s daty,
minimálně ve struktu e:
• upozornění na možnou chybu (data lze odeslat na
pojišťovnu), P Vyberte

• upozornění na chybu bez nutnosti okamžité opravy (lze
po ídit, ale nelze odeslat na pojišťovnu),
• upozornění na chybu s nutností okamžité opravy

POJ_025 KIS musí zachovávat pevnou vazbu výkonového dokladu a
p íslušného dokladu 03, tj. bude-li doklad 03 označen jako
chybný, nesmí být p íslušný výkonový doklad považován za P Vyberte

bezchybný a p ipravený k vyúčtování (=odeslání na pojišťovnu).

POJ_026 KIS musí mít standardní kontroly na správnost vykazování dle
Metodiky VZP a Seznamu výkonů – minimálně v rozsahu (s
možností sestavení seznamu „chybných“ dokladů) -
kontroly p i po izování výkonů:
• výkony v P íloze č. 2
• výkony dle omezení úhrady hospitalizační, ambulantní a
intenzivní péče P Vyberte

• výkony s kategorií úhrady Z

• agregované výkony

• frekvence výkonů
• kombinace výkonů
• výkony pat ící do kapitace

POJ_027 P íklad kontrol p i po izování léčivých p ípravků a zvlášť
účtovaného zdravotnického materiálu minimálně v rozsahu:
• Dle hodnot jádrové úhrady LP/PZLÚ tj. LEG_JUHRn –
nap . symbol D
P Vyberte
• u hospitalizací na číselník NLEKY
• kontrola na průměrné ceny léků a zdravotnického
materiálu dle nemocniční lékárny FNHK
• kontrola na vykázané množství

• kontrola na nulovou cenu v číselníku léků

POJ_028 KIS bude mít kontroly p i po izování léčivých p ípravků a P Vyberte
zdravotnického materiálu na vazbu na výkon.

POJ_029 KIS bude disponovat kontroly na diagnózy: P Vyberte
• platnost dg,
• platnost *dg

POJ_030 KIS musí mít kontrolu externích žadatelů na aktuální číselník P Vyberte
žadatelů VZP.

POJ_031 KIS musí mít kontrolu na existenci schválené žádanky p i P Vyberte
vykazování položek vyžadujících schválení RL.

POJ_032 KIS musí mít kontrolu na p ípustnost vykázání dle věku a pohlaví. P Vyberte

POJ_033 KIS musí mít kontrolu na povolené odbornosti žadatelů. P Vyberte

POJ_034 KIS musí mít kontrolu na p ekrývání hospitalizací. P Vyberte

POJ_035 KIS musí mít kontrolu vyúčtování všech ukončených P Vyberte
hospitalizací.

119
POJ_036 KIS musí mít kontrolu na správné vykazování centrových léků P Vyberte
s vykazovacím limitem „S“, tj. takové vykazování, které je v
souladu s pravidly plátců – zdravotních pojišťoven.

POJ_037 KIS musí mít kontrolu na existující hospitalizaci p i po izování P Vyberte
dokladů 01, 06 s p ípadným automatickým vyplňováním
p íslušného lůžkového žadatele.

POJ_038 KIS musí mít kontrolu na vazbu operačního výkonu a anestezie. P Vyberte
Seznam operačních výkonu p ipraví zadavatel.

2.4.4 Externí vstup K-dávek z jiných systémů
V současné době ve FNHK existuje několik autonomních systémů, které samy
vytvá ejí K-dávky pro pojišťovny (nap . OpenLims, Nefris atd.).

POJ_039 KIS musí v rámci procesu nahrávání dat provádět minimálně tyto P Vyberte
kontroly: P Vyberte
· kontrola na formální správnost – datové rozhraní D_II Vyberte
· kontrola na obsahovou správnost, tj. použít veškerých
kontrol, které se aplikují p i běžném po izování dat

POJ_040 KIS musí umožnit na základě rozhodnutí obsluhy nahrát nebo
odmítnout nahrání K-dávky.

POJ_041 KIS musí umět z informací o nahraných i odmítnutých dávkách
vytvá et historii. Její součástí musí být datum nahrání, kdo nahrál,
p ípadně důvod odmítnutí a počet nahraných dokladů v dávce.

2.4.5 Podpora DRG výkaznictví

POJ_042 KIS musí umět pracovat s tzv. hospitalizačním p ípadem dle P Vyberte
platných metodik. P Vyberte

POJ_043 KIS musí mít možnost zobrazení p ípadu v pohledu DRG (vč. P Vyberte
možných variant za azení) již v průběhu hospitalizace, včetně
nákladového pohledu (body, ZULP, ZUM). D_II Vyberte
P Vyberte
POJ_044 KIS umožní pro pohled na konkrétní p ípady volbu verze P Vyberte
grouperu a volbu sady relativních vah, které mají být pro pohled Vyberte
použity. KIS podporuje i nově vznikající systém CZ-DRG (DRG- D_II Vyberte
markery, grouper atp.) D_II

POJ_045 KIS bude disponovat možnosti definice položek (na úrovni plátce,
čísla pojištěnce nebo dle ATC či kódu), které nebudou součástí
p ípadu.

POJ_046 KIS umožní automatické pozastavení všech dokladů týkajících se
hospitalizačního p ípadu do doby, než bude tento p ípad jako
celek schválen konkrétní osobou k vykázání.

POJ_047 KIS musí nabízet vždy aktuální pohled na p ípad, tj. včetně
promítnutí oprav.

POJ_048 KIS musí umožnit vyhledávání p ípadů p es jednotlivé položky
vstupní věty grouperu a produkce navázané na p ípad (Položky).

POJ_049 KIS nabídne možnost vlastní modelace p ípadu p i změněných
vstupních parametrech.

120
2.4.6 Centrální zpracování zdravotní péče dle metodiky pojišťoven
- „uzávěrka“

POJ_050 KIS musí obsahovat aparát k vyúčtování zdravotní péče P Vyberte
pojišťovnám. D_II Vyberte
Vyberte
POJ_051 KIS musí umět nastavit workflow procesu uzávěrky alespoň P Vyberte
v základních krocích. Včetně návratu o krok zpět. P Vyberte
P Vyberte
POJ_052 KIS musí umět vyúčtovat veškeré druhy dokladů po ízené ve P Vyberte
FNHK, tj. sestavovat dávky typu 05, 14, 80, p ípadně další, které D_II
budou ZP p ijímat elektronicky. Vyberte
P
POJ_053 KIS musí v rámci zpracování dat p ed konečnou uzávěrkou Vyberte
disponovat aparátem na separaci (nap . rozdělení výkonů na ty, P Vyberte
které mají být odeslány na zdravotní pojišťovnu a na ty, které P
odeslány nebudou), náhradu, doplnění, zrušení Položek apod.

POJ_054 KIS musí mít pro správce možnost pozastavit definovanou
množinu dokladů z procesu vyúčtování.

POJ_055 KIS musí mít možnost definování samostatných oblastí pro
vyúčtování (na pracoviště, plátce, výkon/-y), číslo pojištěnce,
období, a kombinaci uvedených).

POJ_056 KIS musí mít možnost definovat záměny obsahu dokladů (včetně
hlaviček dokladů), aby do sestavených dávek vstupovaly doklady
v podobě požadované konkrétním plátcem, ale aby v KIS zůstaly
doklady v původní podobě (typicky vykazování balíčkových kódů
či vykazování pod definovaným IČP).

POJ_057 KIS musí disponovat podporu editace vytvo ených souborů
K-dávek, či jejich zpětného rozpuštění, tj. zrušení za azení
dokladů do konkrétních K-dávek.

POJ_058 KIS musí umět vytvá et faktury podle požadavků pojišťoven a
bude disponovat exportem vybraných dat do EIS (vydané faktury
a regulační poplatky) – Integrace a rozsah p enášených dat je
popsáno v kapitole 4 Minimální požadavky na integrační
platformu včetně zhotovení komunikačních vazeb
s vyjmenovanými systémy.

POJ_059 KIS bude mít možnost editace vytvo ených faktur.

2.4.7 Vyúčtování dopravy

POJ_060 KIS musí umožnovat vyúčtování v dávce (typ 34) na základě
požadavků pojišťovny a azena dle nastavení správcem
aplikace, nap .:

· plátce P Vyberte
· registrační značka
· datum

· číslo pojištěnce
· čas

121
2.4.8 Opravy dokladů po vyúčtování ZP P Vyberte

POJ_061 KIS musí umět zpracovat následující typy oprav: P Vyberte
· vrácen celý doklad bez následné opravy P Vyberte
· vrácen celý doklad s následnou opravou P Vyberte
· vrácena část dokladu bez následné opravy P Vyberte
· vrácena část dokladu s následnou opravou
· část dokladu opravena již na straně pojišťovny (tzn. D_II Vyberte
provedení opravy na straně poskytovatele bez
následného odeslání na pojišťovnu) D_II Vyberte
P Vyberte
POJ_062 KIS musí umět provádět opravy nad jednotlivým dokladem
stejně tak jako nad vybranou množinou dokladů (hromadná
oprava):
· storno dokladu/ů či jejich částí
· kopie dokladu/ů či jejich částí
· změna charakteru dokladu
· změna čísla dokladu
· změna typu dokladu (01 « 06)
· změna jednotlivých údajů v dokladu (žadatel,
poskytovatel, číslo pojištěnce, záměna Položek,…)
· vkládání poznámky k jednotlivým dokladům

POJ_063 KIS musí jednoznačně identifikovat doklady obsahující chybu
pro snadný p ístup uživatele k těmto dokladům (p es seznamy,
sestavy) s p ímou možností editace/opravy.

POJ_064 KIS musí p i azovat k jednotlivým dokladům p ehledný záznam
chybových hlášení/upozornění.

POJ_065 KIS musí umožnit zp ístupnit doklady určené k opravám
definovaným osobám na klinikách.

2.4.9 Import chybových protokolů

POJ_066 KIS musí umět jednoduchým způsobem zpracovat chybové
protokoly z pojišťoven - tj. import odmítnutých dávek, dokladů a
položek (nejen z denní uzávěrky VZP).
Chybový protokol je seznam odmítnutých dokladů nebo částí
dokladů (nap . výkonů), který vedle jednoznačné identifikace, co
je odmítnuto (celý doklad či jeho část), obsahuje také
jednoznačnou identifikaci důvodu odmítnutí (text). P íklad datové
struktury vstupního souboru:
• číslo dokladu
• číslo dávky
• číslo pojištěnce
• popis chyby
• typ opravy - viz výše
• identifikace odmítnuté/korigované části dokladu
(prázdné v p ípadě vrácení celého dokladu).

POJ_067 KIS bude v p ípadě importu chybového protokolu p enášet
informaci o popisu chyby k původnímu i opravnému dokladu.

2.4.10 Kapitace

POJ_068 KIS musí obsahovat p ehled pacientů v evidenci registrujících

122
léka ů, bude umožňovat editaci jednotlivých záznamů a vkládání D_II Vyberte
doplňujících údajů. D_II Vyberte
Informace o pacientovi:

· jméno
· p íjmení
· pojišťovna – možnost zachování historie
· bydliště – možnost zadaní více
· možnost další kontaktní informace – mail, mobilní

telefon, kontakt na blízkou osobu
· datum vzniku a zániku registrace
· IČ léka e, pacienta, záznamu
· Registrující IČZ, IČP, VAR.

POJ_069 KIS umožní vyhledávání pacientů dle zadaných kritérií
(pojišťovna, RČ,…) a vytvá ení p ehledů pacientů včetně
p epočteného počtu pacientů.

POJ_070 KIS umožní vkládání kapitační sazby (dle dodatků jednotlivých
pojišťoven).

2.4.11 Práce se samoplátci a pojištěnci z EU

POJ_071 KIS umožní na základě propojení s EIS kontrolu bezdlužnosti P Vyberte
(p íznak v registru pacientů "dlužník") - Integrace a rozsah
p enášených dat je popsáno v kapitole 4 Minimální požadavky P Vyberte
na integrační platformu včetně zhotovení komunikačních vazeb
s vyjmenovanými systémy D_II Vyberte
P Vyberte
POJ_072 KIS umožní vystavování faktur (+ stvrzenek p i platbě v Vyberte
hotovosti) a jejich automatický export do EIS - Integrace a D_II Vyberte
rozsah p enášených dat je popsáno v kapitole 4 Minimální P Vyberte
požadavky na integrační platformu včetně zhotovení
komunikačních vazeb s vyjmenovanými systémy D_II

POJ_073 KIS umožní sledování pohybu cizinců v nemocnici pro snadné
získání informací o dosud poskytnuté péči.

POJ_074 KIS umožní vyúčtování pacientů z EU včetně vytvo ení K-dávek
a faktur (p enos do EIS).

POJ_075 KIS musí umět vystavit konečný komplexní účet s p ehledem
čerpané péče bezprost edně po poskytnutí péče na pracovišti.

POJ_076 KIS umožní vytvo it dílčí účty pro samoplátce.
POJ_077 Vystavený účet v KIS bude mít veškeré náležitosti a bude jej

možné vytisknout v následujících jazykových mutacích -
angličtina, němčina, ruština, polština, ukrajinština,
francouzština, vietnamština, slovenština a španělština.

2.4.12 Podpora agendy tzv. Centrových léků (CL, léky s vykazovacím limitem
„S“) a domácích receptů

POJ_078 KIS umožní sledování CL vykazovaných jako ZULP a P Vyberte
p edepisovaných na recept prost ednictvím číselníku CL. D_II Vyberte

POJ_079 KIS umožní kontrolovat správnost vykazování CL, provádět
kontroly v souladu s platnými metodikami (nap . číselník

123
diagnostických skupin, číselník KATDIAGNOP, seznam D_II Vyberte
nasmlouvaných pracovišť, …). D_II Vyberte
POJ_080 KIS umožní sledovat CL dle pravidel jednotlivých ZP a ve D_II Vyberte
skupinách nadefinovaných uživatelem.
POJ_081 KIS dokáže sledovat vývoj vykazovaných a číselníkových cen. P Vyberte
POJ_082 KIS bude disponovat funkcionalitou „domácí recept“: D_II Vyberte

· určení účtu, na který se má položka zapsat
· zápis položky na účet včetně aktualizace ohodnocení

na účtu (dokladu)
· doplnění výkonu s kódem 99991 (1x v rámci dne a účtu

p i výskytu položky CEP). Za položku CEP se považuje
ta položka, která je označena jako CEP na vstupu,
p ípadně se jedná o položku z číselníku položek CEP
· vytvo ení protokolu o zpracování, nap . info o
nenalezení účtu, (ne)zaúčtování výkonu 99991, atd.
Podrobnosti k popisu integrace viz 4 Minimální požadavky na
integrační platformu včetně zhotovení komunikačních vazeb
s vyjmenovanými systémy

2.4.13 Agenda poplatků

POJ_083 KIS musí obsahovat nástroj pro účtování poplatků. Tento
nástroj musí být p ístupný z pacientské dokumentace, ale musí
umět pracovat i samostatně.

POJ_084 KIS umožní p enos informace u vykázaných poplatků o jejich
zaplacení do EIS. V p ípadě následné platby poplatku systém
zajistí vykázání p íslušného kódu. - Integrace a rozsah
p enášených dat je popsáno v kapitole 4 Minimální požadavky
na integrační platformu včetně zhotovení komunikačních vazeb
s vyjmenovanými systémy

POJ_085 KIS umožní na základě propojení s EIS kontrolu bezdlužnosti P Vyberte
(p íznak v registru pacientů "dlužník") - Integrace a rozsah D_II Vyberte
p enášených dat je popsáno v kapitole 4 Minimální požadavky Vyberte
na integrační platformu včetně zhotovení komunikačních vazeb P Vyberte
s vyjmenovanými systémy P
Vyberte
POJ_086 KIS musí obsahovat kontrolní mechanismy a upozornění na P
nesprávně zaznamenané nebo chybějící údaje.

POJ_087 KIS musí být integrován s EIS – Podrobnosti k popisu integrace
viz 4 Minimální požadavky na integrační platformu včetně
zhotovení komunikačních vazeb s vyjmenovanými systémy

POJ_088 KIS musí umět vystavit pot ebné doklady (p edpis k úhradě
včetně složenky, potvrzení o zaplacení apod.). Současně
používané výstupy viz p ílohy POPL1.jpg a POPL2.jpg a
POPL3.jpg

POJ_089 KIS musí garantovat soulad s platnou legislativou v oblasti
hospitalizačních poplatků. KIS musí umět kontrolovat, zda byly
správně zaznamenány propustky, doprovody a údaje o
osvobození plateb. P ípadné číselníky musí být uživatelsky
(resp. administrátorem) nastavitelné.

124
2.4.14 Příloha č. 2 (VZP)

POJ_090 KIS bude disponovat možnosti p enositelnosti dat N Vyberte
(nasmlouvané výkony, p ípadně organizační strukturu) z
P íloh č. 2 (ve vhodném datovém rozhraní – viz VZP).

3 Minimální požadavky na portál pacienta

3.1 Obecné požadavky

PP_001 Portál pacienta bude webová aplikace garantující správné D_IV Vyberte
PP_002 fungování v prohlížečích Internet Explorer, Mozilla Firefox, D_IV Vyberte
Google Chrome, Opera, Safari - u všech prohlížečů D_IV Vyberte
p edpokládaná funkčnost minimálně pro t i poslední verze. D_IV Vyberte

ešení bude využívat HTTPS protokolu pro zabezpečení dat. D_IV Vyberte
D_IV Vyberte
PP_003 Vizuální část ešení bude postavena na principech D_IV Vyberte
responzivního designu – garance správného zobrazení na D_IV Vyberte
chytrých za ízeních s OS Android a iOS.
D_IV Vyberte
PP_004 P i prvním p ihlášení bude systém vyžadovat odsouhlasení
PP_005 licenčních podmínek použití.

ešení bude podporovat vynucení souhlasu se zpracováním
osobních údajů.

PP_006 ešení bude zahrnovat jednoduché, intuitivní a dynamické
uživatelské rozhraní, které nevyžaduje žádné proškolení
uživatelů.

PP_007 ešení bude obsahovat možnost aktivace/deaktivace
PP_008 automatického odhlašování klientů p i jejich nečinnosti na
základě nastavitelného timeoutu.

ešení bude zahrnovat domovskou stránku, kde budou
zobrazeny ikony pro vstup k nejvyhledávanějším
funkcionalitám Portálu. Domovská stránka musí zobrazovat
relevantní údaje o pacientovi, jako nap . demografické údaje a
aktivní upozornění a varování ohledně zdravotního stavu či
nutných vyšet ení a prohlídek.

PP_009 Portál pacienta umožní autorizovanému pacientovi zobrazení
seznamu vyšet ení s možnosti vyplnění žádosti o zaslání
vybrané uzav ené zdravotnické dokumentace.

PP_010 Systém bude detailně monitorovat veškerou činnost
p ihlášeného uživatele na portálu pro pot eby budoucích
auditů. Data z monitoringu bude možno filtrovat za libovolné
časové období podle konkrétního pacienta. Logování musí být
prováděno na takové úrovni, aby umožnilo auditovat p ístupy k
datům a práci s informačním systémem v souladu s platnou
legislativou a zároveň časově neomezovalo uživatele.
Zadavatel časovým omezováním uživatele chápe významný
vliv tvorby a správy logů na dobu vystavení požadavku
(časovým úsekem od zadání požadavku na danou akci na
serveru - typicky kliknutí na ovládací prvek - po vystavení a
odeslání požadovaných dat či zpětné vazby zpět ze serveru k

125
PP_011 uživateli – čas vlastní komunikace koncové stanice a serveru D_IV Vyberte
PP_012 považuje zadavatel za zanedbatelný a vzhledem k nutnosti
využití ve ejných sítí, neovlivnitelný dodavatelem) na provozní D_IV Vyberte
PP_013 serverové infrastruktu e s aktivovaným logováním proti situaci D_IV Vyberte
PP_014 s deaktivovaným logováním (nesmí se jednat o nárůst o více D_IV Vyberte
PP_015 než jednu vte inu v porovnání s deaktivovaným logováním). D_IV Vyberte
Návrh provozní infrastruktury a způsobu logování je v
odpovědnosti účastníka.

Portál pacienta umožní administrátorům zadavatele
hierarchické nastavování p ístupových práv se stanovením
rozsahu p ístupu i stupně oprávnění manipulace se
záznamem. Princip nastavování p ístupových práv jednotlivým
uživatelům musí vycházet z definice libovolného množství
uživatelských rolí a skupin, do kterých jsou samotní uživatelé
p i azováni. Počet rolí a skupin nebude omezen a současně
jednomu uživateli může být p i azen neomezený počet rolí.

ešení musí umožnit výběr komunikačního kanálu (nap . e-
mail, SMS,….) pro automatické upozornění a varování
určených uživatelům ohledně sjednaných a naplánovaných
návštěv léka e či zákroků (sjednané návštěvy léka e či
vyšet ení, laboratorní testy, očkování či podání léčebných
p ípravků), kterým chce být uživatel informován.

ešení musí nabízet funkci zasílání upozornění pacientům
minimálně formou e-mailových zpráv anebo SMS zpráv.
Součástí ešení musí být i seznam všech upozornění a
varování uchován bez odmazávání.

Portál pacienta bude p istupovat k datům FN HK
prost ednictvím externí integrační vrstvy (viz architektura
požadovaného ešení v kap. č. 1). Všechny pot ebné
konektory vybuduje dodavatel.

Objednávací formulá bude tzv. „inteligentní“, tj. bude
podporovat:

· validaci povinných polí,
· procesní podporu p i vyplňování formulá ů včetně

nápovědy

ešení umožní uživatelsky jednoduchou správu minimálně na
úrovni úpravy způsobu notifikace a kontaktních údajů.

3.2 Autentifikace uživatele

PP_016 Pro autorizaci p ímého p ístupu pacienta na Portál pacienta D_IV Vyberte
PP_017 musí dodané ešení užívat dvoufaktorové ově ení ve spojení D_IV Vyberte
PP_018 uživatelského loginu, hesla a kódu zaslaného buď SMS na D_IV Vyberte
mobilní telefon, nebo kódu zaslaného na udanou e-mailovou
adresu pacienta.

ešení umožní i následující způsoby autentifikace dle aktuálně
platné legislativy:

a) ově ování vůči NIA
b) ově ování vůči registru zdravotnických pracovníků
Uchazeč musí zadavateli umožnit, aby do účtu uživatele bylo
možné zadat více osob oprávněných ke vstupu k informacím –
opat ení smě uje zejména k zákonným zástupcům nezletilých,

126
PP_019 soudem ustanoveným opatrovníkům apod. Každá z takto
oprávněných osob má p ístup zajištěn vícefaktorovou
autentizací s dvoufázovým ově ením podobně, jako kdyby měl D_IV Vyberte
i informacím p istupovat pacient-uživatel sám.
Zp ístupnění údajů plnoletého pacienta bez omezení právní
způsobilosti jiným osobám (nap . dítěti, které k zastupování a
využívání Portálu pacienta zplnomocní její rodič-senior) je
možné až po udělení písemného souhlasu pacienta, měnit
osobu s možností takového p ístupu náleží výhradně
pacientovi.

3.3 Zobrazované informace

PP_020 ešení umožní pacientům z celé ČR léčeným ve FN HK D_IV Vyberte
PP_021 p ístup k jejich uzav ené zdravotní dokumentaci D_IV Vyberte
PP_022 prost ednictvím Portálu občana za podmínky, že v závěru D_IV Vyberte
PP_023 dodávky IT bude k dispozici pot ebná legislativa, a to zejména D_IV Vyberte
k:

· ambulantním zprávám,
· závěrečným (propouštěcím) zprávám z hospitalizace,
· pacientský souhrn.

ešení umožní p ístup k výpisu hrazených poplatků minimálně
v tomto rozsahu:

· hrazené léka ské úkony s rozpadem kdy, kde, částka,
stav (uhrazeno/neuhrazeno)

· a dalším, které budou blíže specifikovány
v prováděcím projektu

ešení umožní internetové objednávání pacientů v rozsahu
stanoveným zadavatelem buď samotným pacientem, nebo
jeho léka em s napojením na termíny otev ené pro širokou
ve ejnost v objednacích kalendá ích pracovišť nemocnice s
podporou komunikace systému s pacienty (upozornění, změna
termínů apod.) prost ednictvím SMS zpráv nebo e-mailu.
Portál bude integrován s objednávacím systémem, který bude
součástí dodávky nového KIS. Pacient bude moci p edat
informaci o nemožnosti dostavit se na vyšet ení a požádat o
náhradní termín.

ešení umožní zobrazení souhrnu vybraných informací o
pacientovi léka ům FN HK, které mají sloužit k rychlé orientaci
zdravotníků v p ípadě naléhavých zdravotních událostí, tzv.
„pacientský souhrn“.

127
4 Minimální požadavky na integrační platformu včetně
zhotovení komunikačních vazeb s vyjmenovanými
systémy

4.1 Požadavky na integrační platformu

IP_001 Součástí dodávky musí být Integrační platforma (IP) -
Enterprise Service Bus (ESB) - integrační SW, který dovoluje
vývoj, nasazení a správu integrovaných obchodních procesů P Vyberte
(business processes) a webových služeb založených na Vyberte
XML. Vyberte
Vyberte
IP_002 IP musí obsahovat dvě integrační vrstvy. Interní komunikační Vyberte
vrstvu pro komunikaci systémů uvnit ICT infrastruktury
zadavatele a externí komunikační vrstvu pro komunikaci Vyberte
s vnějším světem. V rámci ešení je požadováno minimálně P

logické oddělení dvou skupin adaptérů a procesů. Fyzické
oddělení na úrovni serverů není nutné.

IP_003 IP musí dovolovat propojit různé aplikace a graficky vytvá et P
a upravovat obchodní procesy, které využívají služby
poskytované danými aplikacemi.

IP_004 IP musí umět definovat specifikaci dokumentů a transformací P
pro komunikaci, monitorovat běžící procesy a logovat
komunikaci, která již proběhla.

IP_005 IP musí pracovat na principu publish/subscribe. Zpráva je P
publikována do IP, upravena do požadovaného formátu a
p esměrována jednomu nebo více p íjemcům (subscribers).

IP_006 IP musí umožňovat zpracovávat a p edávat data (mít
konektor) minimálně v těchto formátech:
· Volný text.

· Soubory (kopírovat a p esouvat soubory z/na místní
diskové jednotky a síťové disky zadané UNC cestou,
pracovat s adresá ovou strukturou).

· CSV.

· DASTA v. 3.

· DASTA v. 4.

· DICOM.

· FTP.

· FTPS.

· HL7 v. 2. P
· HL7 v. 3.

· IMAP.

· IMAPS.

· JSON.

· LDAP.

· SFTP.

· SMTP.

· SQL interface minimálně pro databáze (Microsoft
SQL Server, Oracle, IBM Informix, MySQL).

· SSH.

· XML.

· MTOM (SOAP) nebo multipart (REST).
A další formáty, nutné pro ešení vazeb uvedených níže.

128
IP_007 IP musí být schopna dimenzovaní pro zpracování stovek P Vyberte
IP_008 zpráv za vte inu. P Vyberte
IP_009 Pro vývoj integračních rozhraní musí IP (ESB) obsahovat P Vyberte
IP_010 nebo podporovat grafické uživatelské rozhraní umožňující P Vyberte
IP_011 vývoj, ladění (testování) a simulaci jednotlivých integračních
propojení. P Vyberte
IP_012 Musí být k dispozici výkonný a rychle implementovatelný
IP_013 prost edek pro transformaci dat obsažených ve zprávě, který P Vyberte
IP_014 má GUI, pro programování používá drag-and-drop a zároveň D_II Vyberte
IP_015 má možnost v p ípadě nutnosti p ímo editovat základní kód. D_II Vyberte
Systém musí umožňovat identifikaci problémových workflow Vyberte
IP_016 - schopnost p i vzniku problému konkrétního workflow P
snadno a p esně zjistit p íčinu a činnost, která tento problém Vyberte
IP_017 způsobila. P Vyberte
IP_018 P i selhání systému musí být průběh prací a procesů, které P Vyberte
jsou v danou chvíli nedo ešeny nebo nebyly dokončeny, D_II
uložen v aktuálním stavu a s aktuálními daty ve vysoce
dostupné databázi. Systém musí být schopen pokračovat
s každým procesem v tom stavu, ve kterém se nacházel
p ed selháním. Tato rekonstrukce procesů musí probíhat
automaticky.
Navrhovaný systém musí zajistit doručení dat s potvrzením o
p ijetí a žurnálování komunikace mezi odesilatelem a
p íjemcem. Zadavatel p ipouští i možnost ukládání pouze
metadat nap . id zprávy, odesilatel, p íjemce, čas odeslání,
čas p ijetí. Konkrétní ešení je na účastníkovi.
Všechny níže uvedené komunikace musí být realizovány
prost ednictvím komunikační platformy.
Komunikace nemusí být realizována prost ednictvím
integrační platformy pokud to umožnuje definice požadované
komunikační vazby uvedené níže.
Dodavatel může komunikace realizovat prost ednictvím
komunikační platformy jiným, než níže navrženým,
způsobem, pokud se s dodavatelem druhého IS a
zadavatelem dohodne na jiném formátu komunikace.
Náklady na jiný formát komunikace, než níže uvedený, hradí
dodavatel a to včetně nákladů na úpravu SW druhé strany.
Pokud dojde k výpadku komunikace (s výjimkou uživatelem
spouštěné komunikace), systém musí zabezpečit
bezobslužnou obnovu komunikace po odstranění p íčiny
výpadku a p enesení dat, která z důvodu výpadku nebyla
p enesena (zároveň nesmí dojít k duplikaci dat, tj.
opětovnému p enesení již úspěšně p enesených).
V p ípadě pot eby detailní analýzy rozsahu integrace (nap .
pro pot eby cenové nabídky), bude v době lhůty pro podání
nabídek uchazečům umožněna analýza stávajících dat, resp.
používaných komunikačních rozhraní.
Pro zajištění efektivní implementace IHE standardů jako
základu komunikace mezi systémy lokálními a národním
bude vyžadováno, aby p íslušné softwarové komponenty
měly doloženu kompatibilitu s ostatními IHE nástroji pomocí
tzv. IHE IntegrationStatement v p ípadě, že bude v době

129
implementace vyžadováno zákonnými normami nebo
na ízeno závazným p edpisem.
Jedná se o IHE profily:
1. PIXv3/PIXm.
2. PDQv3/PDQm.
3. XDS.b/MHD.

IP_019 Dodavatel musí p edat kompletní popis všech jím
vytvo ených komunikací a služeb v rámci Integrační
platformy včetně p esného popisu jednotlivých datových
položek a nastavených parametrů. Účastník se musí ke dni
podání nabídky zavázat k popisu všech jím vytvo ených
komunikací a služeb v rámci integrační platformy. Popis P Vyberte
všech jím vytvo ených komunikací k dané etapě p edá
uchazeč vždy p i akceptaci p íslušné části díla. Tento
seznam se musí zavázat aktualizovat tak, aby veškeré jím
provedené změny v komunikaci byly zaznamenány do 14 dní
od jejich provedení.

4.2 Seznam požadovaných komunikací

IP_020 Komunikace „Medix - Seznam nově založených pacientů“:
1. Komunikace za účelem synchronizace registrů pacientů
D_II Vyberte
z KIS do IS Medix.
2. Komunikace bude obsahovat všechny dnes založené

pacienty a pacienty, u kterých došlo ke změně osobních
údajů.
3. Systém musí být schopen v pravidelných intervalech
automatického bezobslužného exportu dat.
4. Data musí být možné exportovat do adresá e na síťovém
disku (zadaného prost ednictvím UNC cesty) ve formě
textových souborů v kódování PC-852 Latin2. Konce
ádků budou označeny znakem CR (nikoliv CR LF).
5. Oddělovačem jednotlivých datových položek bude znak
Pipe - „|“ (ASCII kód 124), za poslední položkou bude
oddělovač uveden.
6. Pokud není známá hodnota a v definici položky je
povolena hodnota NULL, potom bude pole ponecháno
prázdné, tj. budou po sobě následovat dva oddělovače
datových položek.
7. Export souboru bude probíhat každý den každých 10
minut od 0:09:59 hodin do 23:59:59 hodin.
8. Definice položek viz tabulka 1.

Tabulka 1 Definice datových položek pro požadavek IP_020.

Název t yp Al l ow Nul l s Popi s
i c_pac i nt 32 N i nt er ní č. paci ent a, pod kt er ýmj e veden v dat abázi KI S
r od_ci s char ( 11) N r odné čí sl o paci ent a
pr i j meni nchar ( 20) N pří j mení paci ent a
jm nchar ( 20) N j méno paci ent a
zpoj _kod char ( 4) N zdr avot ní poj i šťovna paci ent a
dat _nar oz dat e A dat umnar ození , f or mát DD. MM. RRRR
sex char ( 1) A pohl aví paci ent a ( " Z" pr o žena, "M" pr o muž)

IP_021 Komunikace „Medix - Sloučení pacienti“: D_II Vyberte

130
1. Komunikace za účelem synchronizace registrů
pacientů z KIS do IS Medix.

2. Pokud systém umožňuje slučovat záznamy více
pacientů do jednoho, bude systém exportovat
informace o sloučených pacientech.

3. Systém musí být schopen v pravidelných intervalech
automatického bezobslužného exportu dat.

4. Data musí být možné exportovat do adresá e na
síťovém disku (zadaného prost ednictvím UNC
cesty) ve formě textových souborů v kódování PC-
852 Latin2. Konce ádků budou označeny znakem
CR (nikoliv CR LF).

5. Oddělovačem jednotlivých datových položek bude
znak Pipe - „|“ (ASCII kód 124), za poslední položkou
bude oddělovač uveden.

6. Pokud není známá hodnota a v definici položky je
povolena hodnota NULL, potom bude pole
ponecháno prázdné, tj. budou po sobě následovat
dva oddělovače datových položek.

7. Export souboru bude probíhat každý den každých 10
minut od 0:09:59 hodin do 23:59:59 hodin.

8. Definice položek viz tabulka 2.
Tabulka 2 Definice datových položek k požadavku IP_021

Název t yp Al l ow Nul l s Popi s
i c_pac_z i nt 32
i c_pac_c i nt 32 N Vni t řní i dent i f i kační č. pac, kt er ý j e r ušen
r od_ci s char ( 11)
r owi d i nt 32 N Vni t řní i dent i f i kační č. pac, na kt er ého j sou převáděna dat a

N Rodné čí sl o paci ent a, kt er ý zůst ává v syst ému

N Jedi nečná i dent i f i kace záznamu o sl oučení

IP_022 Komunikace „Medix - seznam sterilizovatelných položek“: D_II Vyberte
IP_023 1. Komunikace za účelem p edávání seznamu
IP_024 D_II Vyberte
sterilizovatelých položek, kontejnerů, sít a ostatního D_II Vyberte
materiálu (dále jen sterilizovatelné položky)
dodávaného z pracoviště Centrální sterilizace na
operační sály. Data bude poskytovat IS Medix. Použití
těchto sterilizovatelných položek p i konkrétní operaci
bude následně v KIS zaznamenáno čtečkou čárových
kódů.
2. Zadavatel zajistí p edání popisu komunikačního
rozhraní, p edpokládá se použití view do databáze
Microsoft SQL.
Komunikace „Medix - žádanky“:
1. Komunikace za účelem vytvo ení žádanky na
sterilizaci. V rámci komunikace bude p edáván
seznam položek, použitých u operace, u nichž je
požadována resterilizace. Žádanka dále obsahuje
urgentnost sterilizace (statim/rutina), textovou
poznámku, počet obalů jednotlivých položek, zda je
požadováno mytí a/nebo dekontaminace. Data budou
p edávána z KIS do IS Medix.
2. Zadavatel zajistí p edání popisu komunikačního
rozhraní.
Komunikace „Cato“:
1. Komunikace za účelem p edávání dat o cenách

131
hromadně vyráběných léčivých p ípravků a potravin
pro zvláštní léka ské účely z KIS do IS Cato.
2. Soubor bude obsahovat ceny VZP, pokud je cena VZP
vyšší, než cena CMF použije se cena CMF. Zkratky
dle popisu datového rozhraní, volně dostupného na
webových stránkách VZP.
3. Data musí být možné exportovat do adresá e na
síťovém disku (zadaného prost ednictvím UNC cesty)
ve formě textových souborů v kódování PC-852 Latin2.
Konce ádků budou označeny znakem CR (nikoliv CR
LF).
4. Oddělovačem jednotlivých datových položek bude
znak Pipe - „|“ (ASCII kód 124), za poslední položkou
bude oddělovač uveden.
5. Pokud není známá hodnota a v definici položky je
povolena hodnota NULL, potom bude pole ponecháno
prázdné, tj. budou po sobě následovat dva oddělovače
datových položek.
6. Export bude vyvolán akcí uživatele.
7. Definice položek viz tabulka 3.

Tabulka 3 Definice datových položek pro požadavek IP_024.

Název t yp Al l ow Nul l s Popi s
l eky_kod char ( 10) N kód l éči va dl e SUKL
uhr ada deci mal ( 13, 2) N cena l éči va
pl at nost _od dat e N dat umzačát ku pl at nost i ceny, f or mát DD. MM. RRRR

IP_025 Import pacientských dat, medicinských výsledků, a diagnóz D_II Vyberte
IP_026 do „Cato“: D_II Vyberte
IP_027 1. Komunikace za účelem minimalizace manuálního D_II Vyberte

zadávání výše uvedených kategorií informací do
systému Cato.
2. P enos dat probíhá prost ednictvím cato® HL7
INTERFACE.
3. Zadavatel zajistí p edání popisu komunikačního
rozhraní.
Komunikace „Vema - Navision“:
1. Komunikace za účelem synchronizace registru

zaměstnanců z IS Vema do IS Navision.
2. Systém musí být schopen p edávat komunikační

soubor z adresá e na síťovém disku (zadaného
prost ednictvím UNC cesty) do jiného adresá e na
síťovém disku (zadaného prost ednictvím UNC cesty).
Pro oba adresá e bude možné nastavit autentizaci
samostatně.
3. Import se bude provádět na základě výskytu souboru
s daty v p edem určeném adresá i.
Komunikace „Export výsledků v Dasta“:
1. Komunikace za účelem exportu výsledků a záznamů
do externích IS.
2. Systém musí umožňovat exportovat výsledky ve
formátech Dasta 3 a Dasta 4. Musí být
implementována plná podpora všech možností formátu
Dasta 3 a Dasta 4.
3. Export výsledků musí být možné nastavit na
automatický bezobslužný export v p edem
definovaných intervalech.
4. Data musí být možné exportovat do adresá e na

132
IP_028 síťovém disku (zadaného prost ednictvím UNC cesty). D_II Vyberte
Pro každého žadatele musí být možné nastavit vlastní
IP_029 exportní adresá k ukládání souborů a vlastní formát D_II Vyberte
IP_030 exportu. D_II Vyberte
5. Musí být možné exportovat:
5.1. Ambulantní záznamy.
5.2. RTG popisy.
5.3. Závěrečné zprávy z hospitalizace.
5.4. Žádanky na vyšet ení (laboratorní i ambulantního

typu). Žádanky musí být možné v KIS i vytvá et.
6. Pokud to zvolený formát exportu umožňuje, musí být

možné exportovat výsledek nejen jako plain-text, ale
současně i jako formátovaný text (nap . rtf, html, ...) v
rámci jednoto exportního souboru. Zda bude
exportovaný soubor obsahovat i formátovanou verzi
výsledku, musí být možné nastavit zvlášť pro jednotlivé
žadatele.
Komunikace „Import výsledků v Dasta“:
1. Komunikace za účelem importu výsledků a záznamů
z externích IS.
2. Systém musí umožňovat importovat výsledky
(strukturované i nestrukturované) ve formátech Dasta 3
a Dasta 4. Musí být implementována plná podpora
všech možností formátu Dasta 3 a Dasta 4.
3. Import výsledků musí být možné nastavit na
automatický bezobslužný import v p edem
definovaných intervalech.
4. Data musí být možné importovat z adresá e na
síťovém disku (zadaného prost ednictvím UNC cesty).
Musí být možné omezit soubory k importu dle názvu na
základě definice názvu souboru regulárním výrazem.
Pro každého žadatele musí být možné nastavit vlastní
exportní adresá a vlastní omezení názvu souborů.
Systém musí umět automaticky rozeznávat formát
souboru k importu.
5. P i importu musí systém respektovat žadatele
z importovaného souboru a importovaná data p i adit
p íslušnému pracovišti dle organizační struktury.
Zároveň musí systém umožňovat z vybraného
adresá e pro soubory specifikované názvem import do
pevně zadaného pracoviště.
6. Pokud je výsledek v Dasta označen jako opravný nebo
storno výsledku, systém musí původní výsledek
p íslušným způsobem označit.
7. Musí být možné importovat:
7.1. Ambulantní záznamy.
7.2. RTG popisy.
7.3. Výsledky laboratorních vyšet ení a to jak

strukturovaně, tak jako plain-text.
7.4. Žádanky na vyšet ení.
Transformace Dasta - HL7:
1. V rámci integrační platformy musí být implementovány
funkce, zajišťující transformaci laboratorních výsledků
(strukturovaných), textových výsledků a žádanek
z formátu Dasta3 a Dasta4 do HL7 verze 2 i verze 3 a
naopak (z HL7 do Dasta3 a Dasta 4).
Komunikace „Navision faktury“:
1. Komunikace za účelem p edávání dat o fakturách pro
pojišťovny z KIS do IS Navision. Faktury jsou tvo eny

133
IP_031 na základě dávek pro jednotlivé pojišťovny (viz kapitola D_II Vyberte
IP_032 2.3 ). D_II Vyberte
IP_033 2. Export bude vyvolán akcí uživatele, systém se dotáže D_II Vyberte
na období, za které má dojít k exportu dat o
vystavených fakturách.
3. Data musí být možné exportovat do adresá e na
síťovém disku (zadaného prost ednictvím UNC cesty)
ve formě textových souborů v kódování PC-852 Latin2.
Konce ádků budou označeny znakem CR (nikoliv CR
LF).
4. Oddělovačem jednotlivých datových položek bude znak
St edník - „;“, za poslední položkou nebude oddělovač
uveden.
5. Všechny položky budou zarovnány doleva a budou
odstraněny mezery zprava.
6. Zadavatel zajistí p edání popisu datových položek.
7. Komunikace nemusí probíhat p es integrační platformu.
Komunikace „List o prohlídce zem elého“:
1. Komunikace za účelem p edávání dat o zem elých
pacientech z KIS do IS WinZis (Patologický LIS).
2. Jedná se o webovou službu SOAP p enášenou pomocí
HTTPS.
3. Server je na straně WinZis. KIS se musí
prost ednictvím IP s tímto serverem spojit a zaslat
požadované informace.
4. Vyslání požadavku bude automatické ve chvíli uzav ení
protokolu o prohlídce zem elého v KIS.
5. Rozsah komunikace odpovídá údajům v Listu o
prohlídce zem elého dle ÚZIS.
6. Technický popis komunikačního rozhraní včetně wsdl
popisu dodá zadavatel.
Komunikace „Žádanka na patologické vyšet ení“:
1. Komunikace za účelem p edávání dat o požadovaném
patologickém vyšet ení z KIS do IS WinZis (Patologický
LIS).
2. Jedná se o webovou službu SOAP p enášenou pomocí
HTTPS.
3. Server je na straně WinZis. KIS se musí
prost ednictvím IP s tímto serverem spojit a zaslat
požadované informace.
4. Vyslání požadavku bude automatické ve chvíli uzav ení
žádanky na patologické vyšet ení.
5. Komunikace obsahuje identifikační údaje o pacientovi,
identifikaci žadatele, identifikaci požadovaných metod,
textový popis materiálu, diagnózy, klinickou TNM
klasifikaci a další údaje.
6. Technický popis komunikačního rozhraní včetně wsdl
popisu dodá zadavatel.
Komunikace „Patologické výsledky“:
1. Komunikace za účelem p edávání výsledků
patologických vyšet ení z IS WinZis (Patologický LIS)
do KIS.
2. Jedná se o webovou službu SOAP p enášenou pomocí
HTTPS.
3. Dodavatel vytvo í server služby, na kterou se bude
prost ednictvím IP p ipojovat stávající klient.
4. Komunikace obsahuje identifikační údaje pacienta,
identifikaci žádanky a výsledku, textové popisy
výsledku, binární data (nejčastěji obrazová

134
IP_034 dokumentace), patologickou TNM klasifikaci a další D_II Vyberte
IP_035 údaje. D_II Vyberte
IP_036 5. Technický popis komunikačního rozhraní včetně wsdl D_II Vyberte
popisu dodá zadavatel.
IP_037 6. V rámci této komunikace je nutné vytvo it službu, která D_IV Vyberte
bude zajišťovat založení nového pacienta v registru KIS
na základě požadavku odeslaného z WinZis. Jedná se
o webovou službu SOAP p enášenou pomocí HTTPS.
Technický popis této služby včetně wsdl popisu dodá
zadavatel.
Komunikace „NIX-ZD - pacientský souhrn a emergency
card“:
1. Komunikace za účelem zapojení do infrastruktury pro
výměny dat prost ednictvím národních kontaktních míst
pro eHealth.
2. Technický popis ešení viz www.nixzd.cz
Komunikace „Žádanky na Transfuzní oddělení“:
1. Systém musí být schopen vytvá et a p edávat žádanky
na transfuzní p ípravky do laboratorního IS
Transfuzního oddělení.
2. Jedná se o systém Amadeus firmy Steiner, s.r.o.
Zadavatel zajistí p edání popisu komunikačního
rozhraní.
Komunikace „eMeDocS“:
1. Komunikace za účelem zobrazení výjezdové zprávy
ZZS KHK.
2. Výjezdová zpráva ZZS KHK je ukládána ve formátu
PDF/A s p íslušnými metadaty do Archivu zdravotnické
dokumentace (dále AZD1), který je pro tento účel ve
FN Hradec Králové dedikován a provozován ZZS KHK.
KIS musí podpo it p ímou práci uživatele v AZD1 dle
jeho p ístupových práv.
3. KIS otev e webový prohlížeč s URL a p edá následující
parametry jako parametry URL adresy:
3.1. Login uživatele KIS (logování a audit p ístupu).
3.2. Čas generování URL ve formátu dd.MM.yyyy

HH:mm (URL bude mít pouze omezenou
platnost).
3.3. Rodné číslo pacienta, jehož dokumenty mají být
zobrazeny.
3.4. Sha256hex hash etězce složeného z údajů výše.
4. P esný popis volání dodá zadavatel.
5. Komunikace nemusí probíhat p es integrační
platformu.
Komunikace „Napojení na ISAC Communication Node“:
1. Komunikace zajišťující výměnu zdravotnické
dokumentace mezi poskytovateli zdravotní péče.
2. Výměna DASTA zpráv:
2.1. Jedná se o obousměrné p edávání zprávy mezi
komunikačním uzlem a klinickým informačním
systémem.
2.2. P edmětem výměny jsou zprávy typu
ambulantní/hospitalizační zpráva, žádanky a
výsledky ambulantního vyšet ení a laboratorních
vyšet ení, výjezdové zprávy ZZS apod.
3. Vyhledání pacientského souhrnu EC:
3.1. Vyhledání životně důležitých informací pacienta v
klinickém informačním systému.

135
IP_038 3.2. Výsledek je souhrnný p ehled všech dostupných D_II Vyberte
IP_039 informací typu EC v následujícím rozsahu: D_II Vyberte
IP_040 3.2.1.Identifikační údaje pacienta a kontaktní D_II Vyberte
adresa.
3.2.2.Trvalé diagnózy.
3.2.3.Rizikové faktory.
3.2.4.Alergie.
3.2.5.Trvalé medikace.
3.2.6.Seznam ambulantních a hospitalizačních
návštěv za stanovené období.

4. Vyžádání dokumentu ke klinickému p ípadu:
4.1. Vyžádání a p edání dokumentu ke klinickému
p ípadu k nahlédnutí.
4.2. Výsledek je dokument ke klinickému p ípadu,
obvykle ambulantní nebo hospitalizační zpráva.

5. Vyžádání informací o dostupném lůžkovém fondu:
5.1. Vyžádání a p edání informací o volném lůžkovém
fondu ve zdravotnickém za ízení.
5.2. Výsledek je souhrnný p ehled dle jednotlivých
pracovišť s definovaným počtem volných lůžek dle
standardu DASTA ver.4.

6. Všechny metody rozhraní budou poskytovány
prost ednictvím HTTP(S) protokolu s využitím metody
GET nebo POST.

Komunikace „Domácí recept - vyvolání žádanky“:
1. Komunikace za účelem vytvo ení „domácího receptu“.

Data budou p edávána z KIS do Mediox (IS pro
lékárnu).
2. Na formulá „domácí repect“ jsou zapisovány zvlášť
účtované léčivé p ípravky (ZULP), které si pacient
z organizačních důvodů vyzvedává v lékárně FN HK a
odnáší sebou domů.
3. Komunikace bude realizována otev ením webového
žádankového systému v IS Mediox. Data jsou
p edávána jako parametry URL adresy.
4. Obsahem komunikace je zejména identifikace pacienta,
žádajícího oddělení a uživatele.
5. Zadavatel zajistí p edání URL adresy a popis jejích
parametrů.
6. Komunikace nemusí probíhat p es integrační platformu.
Komunikace „Domácí recept - vyúčtování pojišťovny“:
1. Komunikace za účelem p edávání informací o zvlášť
účtovaných léčivých p ípravcích (ZULP), vydaných
v lékárně na základě „domácího receptu“. Data budou
p edávána z IS Mediox do KIS.
2. Komunikace je realizována automatickým p edáváním
dat prost ednictvím webové služby. Rozsah
p edávaných údajů odpovídá KDávce VZP.
3. Informace o vydaných ZULP budou zapsány do
vyúčtování pojišťovny p íslušné klinické události.
4. Zadavatel zajistí p edání popisu komunikačních
rozhraní.
Komunikace „Domácí recept - zápis do klinické
dokumentace“:
1.Komunikace za účelem zápisu informace o p edepsání
„domácího receptu“ do klinické dokumentace pacienta.
2.Po vytvo ení domácího receptu v IS Mediox p edá IS
Mediox informaci o vytvo ení domácího receptu do KIS.
KIS musí provést zápis o p edepsání receptu do klinické

136
IP_041 dokumentace do samostatné položky v rámci klinické D_II Vyberte
IP_042 události, p i které byl domácí recept vytvo en. D_II Vyberte
IP_043 3.Zadavatel zajistí p edání popisu komunikačního rozhraní D_IV Vyberte
a popis způsobu zápisu.
Komunikace „X-view“:
1. Komunikace za účelem p edávání dat mezi IS X-view a

KIS.
2. V rámci komunikace musí docházet k:

2.1. Synchronizaci registrů pacientů.
2.2. P edávání žádanek o vyšet ení z KIS do

X-view.
2.3. P edávání popisů vyšet ení z X-view do KIS.
2.4. P edávání informací o implantátech z

X-view do KIS.
2.5. P edávání informací o radiační zátěži z

X-view do KIS nebo RIS.
3. Komunikace bude probíhat p ednostně v DICOM4

rozhraní, pokud pro konkrétní typ komunikace DICOM4
vyhovuje.
4. U ostatní komunikace zadavatel zajistí p edání popisu
komunikačního rozhraní.
Komunikace „Registry ÚZIS“:
1. Komunikace za účelem p edávání dat do registrů ÚZIS.
2. KIS musí být schopen komunikovat s registry ÚZIS
prost ednictvím webových služeb, pokud registr tuto
komunikaci umožňuje.
3. Pokud registr ÚZIS neumožňuje komunikaci pomocí
webových služeb, KIS vytvo í pro komunikace dávkový
soubor dle rozhraní ÚZIS.
4. Kontroly zadávaných údajů v KIS musí být nastaveny
tak, aby nedocházelo k odmítnutí dat ze strany ÚZIS.
Pokud k odmítnutí dojde, dodavatel je povinen provést
p íslušné opravy kontrol.
5. P ed odesláním dat musí být uživateli umožněno vybrat
data (nap . pacienty, hospitalizace apod.), která mají
být do registru zaslána.
6. Zadavatel se musí zavázat k realizaci komunikace se
všemi registry, které v době akceptace díla budou
umožňovat komunikaci.
7. Komunikace, která vyžaduje manuální p edání dat
uživatelem v aplikacích ÚZIS, nemusí probíhat p es
integrační platformu.
Komunikace „Schvalování ATB“:
1. Komunikace za účelem p edávání žádanek o schválení
antibiotik (ATB), vyjád ení k požadavku za strany
léka ů ATB st ediska a odeslání žádanky do lékárny.
2. Komunikace mezi IS OpenLIMS (ATB st edisko), KIS a
Mediox (lékárna).
3. Popis procesu:
3.1. V KIS bude vytvo ena žádanka na ATB, která

bude odeslána do lékárny jako dosud
neschválená a zároveň do ATB st ediska ke
schválení.
3.2. Léka ATB st ediska se vyjád í k žádosti (schválí,
neschválí, schválí s úpravou) - toto vyjád ení bude
p edáno do KIS a do lékárny, která následně
vydá/nevydá p íslušné ATB.
4. Zadavatel zajistí p edání popisu komunikačních
rozhraní s OpenLIMS a Mediox.

137
IP_044 Komunikace „Poplatky“: D_II Vyberte
IP_045 1. Komunikace za účelem p edávání p edpisů k úhradě D_II Vyberte

(za nezaplacené služby poskytnuté pacientům
pracovišti FN HK). Data se p edávají z KIS do
ekonomického informačního systému Navision.
2. V rámci informací o vyúčtování poskytnuté péče musí
KIS umožnit zadat i informaci, že pacientem hrazená
péče nebyla zaplacena. Tato data jsou pak podkladem
pro komunikaci s Navision.
3. Export dat bude vyvolán akcí uživatele, systém se
dotáže na typ p edpisu k úhradě (za amb. poplatek,
službu oddělení TCM, službu Laser centra, za dopravu
apod.) a časové období k exportu. Následně budou
vytvo eny dva soubory - s osobními údaji o pacientech
a s údaji o p edpisech k úhradě.
4. Pro soubory bude nabídnut implicitní nastavitelný název
ve tvaru + +
datum začátku období, za které se exportuje ve formátu
„RRRRMMDD“ + p ípona „txt“.
5. Systém musí umožňovat tyto akce naplánovat a
provádět automaticky. Časové období v tomto p ípadě
musí být možné zadat buď jako pevné datum, nebo s
ohledem na aktuální datum (nap . data za posledních
10 dní, poslední měsíc, za poslední 2 měsíce apod.).
6. Data musí být možné exportovat do adresá e na
síťovém disku (zadaného prost ednictvím UNC cesty)
ve formě textových souborů v kódování PC-852 Latin2.
Konce ádků budou označeny znakem CR (nikoliv CR
LF).
7. Oddělovačem jednotlivých datových položek bude znak
„;“.
8. Definice položek v jednotlivých souborech dodá
zadavatel. Datové položky se mohou lišit podle typu
p edpisu k úhradě (podle typu poskytnuté služby).
9. Komunikace vyvolaná zásahem uživatele nemusí
probíhat p es integrační platformu.
Komunikace „Navision - dlužníci“:
1. Komunikace za účelem p edávání seznamu dlužníků
z Navision do KIS.
2. V KIS musí být uživateli jednoznačně viditelná
informace, že je pacient dlužníkem, bez nutnosti tuto
informaci aktivně vyhledávat.
3. Import dat bude vyvolán akcí uživatele, systém se
dotáže na soubor s daty.
4. Systém musí umožňovat tuto akce i naplánovat a
provádět automaticky.
5. Data musí být možné importovat z adresá e na síťovém
disku (zadaného prost ednictvím UNC cesty) ve formě
textových souborů. Soubor bude v kódování Windows-
1250. Konce ádků budou označeny znakem CR LF.
6. Oddělovačem jednotlivých datových položek bude znak
„;“, za poslední položkou nebude oddělovač uveden.
7. Typ dluhu v současnosti může nabývat hodnot „DLUH“
a „DLUH_ADR“, v době implementace je možné
rozší ení množství evidovaných dluhů. Uživatel musí
být schopen v KIS odlišit, o jaký typ dluhu se jedná.
8. Definice položek viz tabulka 4.
9. Komunikace vyvolaná zásahem uživatele nemusí
probíhat p es integrační platformu.

138
Tabulka 4 Definice datových položek pro požadavek IP_045.

Název Typ Al l ow Nul l s Popi s
r od_ci s char ( 10) N Rodné čí sl o paci ent a bez l omí t ka
t yp char ( 10) N Typ dl uhu

IP_046 Podpora eReceptu: D_II Vyberte
IP_047 1. Systém musí podporovat veškeré procesy týkající se D_II Vyberte

eReceptů dle platné legislativy.
2. Zadavatel vyžaduje registraci KIS u SUKL v poslední

dostupné verzi.
Komunikace „Sophis - recepty“:
1. Komunikace za účelem p edávání dat z KIS do IS

Sophis.
2. Obsahem p edávaných dat bude seznam všech receptů

vystavených v KIS.
3. Export dat bude vyvolán akcí uživatele, systém se

dotáže na časové období exportu.
4. P edpokládá se, že IP p edá data zápisem do

komunikační databáze IS Sophis - jedná se o databázi
Microsoft SQL Server.
5. P edpokládaná struktura tabulky viz tabulka 5.

Tabulka 5 Předpokládaná datová struktura k požadavku IP_047.

Název Typ Al l ow nul l s Popi s
i c_r ec bi gi nt N čí sl o r ecept u / poukazu
vyk_pr ac nvar char ( 4) A kód předepi suj í cí ho pr acovi št ě ( var )
r od_ci s nvar char ( 11) A r odné čí sl o paci ent a
zpoj _kod nvar char ( 3) A kód zdr avot ní poj i šťovny paci ent a
dg_kod nvar char ( 5) A di agnóza paci ent a
t yp úhr ady u pr vní ho kódu pří pr avku ( P = hr adí paci ent ,
uhr ada1 nvar char ( 1) A C = spol uúčast paci ent a, I = hr adí poj i šťovna)
kód pr vní ho pří pr avku / pomůcky
i c_l ek1 i nt A množst ví pr vní ho pří pr avku / pomůcky
pocet 1 i nt A cel ková cena za pří pr avky / pomůcky s pr vní mkódem
cena1 money A cel kový dopl at ek za pří pr avky / pomůcky s pr vní mkódem
dopl at ek1 money A kód skupi ny ( 1 = HVLP, 2 = I VLP, 3 = PZT)
sk_kod1 nvar char ( 1) A t yp úhr ady u dr uhého kódu pří pr avku ( P = hr adí paci ent ,
C = spol uúčast paci ent a, I = hr adí poj i šťovna)
uhr ada2 nvar char ( 1) A kód dr uhého pří pr avku / pomůcky
množst ví dr uhého pří pr avku / pomůcky
i c_l ek2 i nt A cel ková cena za pří pr avky / pomůcky s dr uhýmkódem
pocet 2 i nt A cel kový dopl at ek za pří pr avky / pomůcky s dr uhýmkódem
cena2 money A kód skupi ny ( 1 = HVLP, 2 = I VLP, 3 = PZT)
dopl at ek2 money A uži vat el ské j méno předepi suj í cí ho l ékaře
sk_kod2 nvar char ( 1) A dat umvyst avení r ecept u
l ogi n nvar char ( 8) A
dat _vyst dat et i me A

IP_048 Komunikace „Sophis - ZUM a ZULP“:
1. Komunikace za účelem p edávání dat z KIS do IS
D_II Vyberte
Sophis.
2. Obsahem p edávaných dat bude seznam všech ZUM

(zvlášť účtovaný materiál) a ZULP (zvlášť účtované

139
léčivé p ípravky) vykázané v KIS pro pojišťovnu.
3. Export dat bude vyvolán akcí uživatele, systém se

dotáže na časové období exportu.
4. Systém musí umožňovat tyto akce naplánovat a

provádět automaticky. Časové období v tomto p ípadě
musí být možné zadat buď jako pevné datum, nebo s
ohledem na aktuální datum (nap . data za posledních
10 dní, poslední měsíc, za poslední 2 měsíce apod.).
5. P edpokládá se, že IP p edá data zápisem do
komunikační databáze IS Sophis - jedná se o databázi
Microsoft SQL Server.
6. P edpokládaná struktura tabulky viz tabulka 6.

Tabulka 6 Předpokládaná datová struktura pro požadavek IP_048.

Název Typ Al l ow nul l s Popi s
i c_ucet bi gi nt A čí sl o poj i šťovenského účt u
t yp účt u ( A = ambul ant ní , H = hospi t al i zační , E =
t yp_ucet nvar char ( 1) A poukaz)
kód výkonového pr acovi št ě
vyk_pr ac nvar char ( 4) A r odné čí sl o paci ent a
r od_ci s nvar char ( 11) A kód zdr avot ní poj i šťovny paci ent a
zpoj _kod nvar char ( 50) A kód skupi ny ( 1 = HVLP, 2 = I VLP, 3 = PZT)
sk_kod nvar char ( 1) A kód l éku nebo mat er i ál u
kod_VZP i nt A množst ví l éku nebo mat er i ál u
mnoz money A cel ková cena za l éky nebo mat er i ál
cena_cel k money A di agnóza paci ent a
dg_kod nvar char ( 5) A dat umvyst avení záznamu v NI S
dat um dat et i me A

IP_049 Komunikace „Sophis - ICP“:
1. Komunikace za účelem p edávání dat z KIS do IS
D_II Vyberte
Sophis.
2. Obsahem p edávaných dat bude aktuální číselník léka ů

FN HK.
3. Export dat bude vyvolán akcí uživatele nebo

automaticky ve zvolený čas (nap . 23:00), pokud od
posledního exportu došlo ke změně v exportovaných
údajích.
4. P edpokládá se, že IP p edá data zápisem do
komunikační databáze IS Sophis - jedná se o databázi
Microsoft SQL Server.
5. P edpokládaná struktura tabulky viz tabulka 7.

Tabulka 7 Předpokládaná datová struktura pro požadavek IP_049.

Název Typ Al l ow nul l s Popi s
i cp nvar char ( 8) N I ČP pr acovi št ě
r od_ci s nvar char ( 11) N r odné čí sl o l ékaře
l ogi n nvar char ( 8) N uži vat el ské j méno l ékaře
vyk_pr ac nvar char ( 4) N kód výkonové pr acovi št ě
j meno nvar char ( 40) N pří j mení a j méno l ékaře
t i t ul 1 nvar char ( 20) A t i t ul před j ménem
t i t ul 2 nvar char ( 20) A t i t ul za j ménem
odb nvar char ( 3) A odbor nost pr acovi št ě
pl a_od nvar char ( 6) N pl at nost záznamu od

140
Název Typ Al l ow nul l s Popi s
pl a_do nvar char ( 6)
A pl at nost záznamu do

IP_050 Komunikace „Sophis - Organizační struktura“:
1. Komunikace za účelem p edávání dat z KIS do IS
D_II Vyberte
Sophis.
2. Obsahem p edávaných dat bude číselník organizační

struktury FN - HK a vazba mezi výkonovými a
nákladovými pracovišti a platnost této vazby.
3. Export dat bude vyvolán akcí uživatele nebo
automaticky ve zvolený čas (nap . 23:00), pokud od
posledního exportu došlo ke změně v exportovaných
údajích.
4. P edpokládá se, že IP p edá data zápisem do
komunikační databáze IS Sophis - jedná se o databázi
Microsoft SQL Server.
5. P edpokládaná struktura tabulky viz Tabulka 8.

Tabulka 8 Předpokládaná datová struktura pro požadavek IP_050.

Název Typ Al l ow nul l s Popi s
vyk_pr ac i nt N kód výkonového pr acovi št ě
vyk_naz nvar char ( 35) A název výkonového pr acovi št ě
nak_pr ac i nt N kód nákl adového pr acovi št ě
nak_naz nvar char ( 35) A název nákl adového pr acovi št ě
pl a_od nvar char ( 6) N pl at nost záznamu od
pl a_do nvar char ( 6) A pl at nost záznamu do

IP_051 Komunikace „Sophis - Kliniky“:
1. Komunikace za účelem p edávání dat z KIS do IS
D_II Vyberte
Sophis. Vyberte
2. Obsahem p edávaných dat bude číselník klinik FN HK.
3. Export dat bude vyvolán akcí uživatele nebo

Tabulka 9 Předpokládaná datová struktura pro požadavek IP_051.

Název Typ Al l ow nul l s Popi s
kl i n i nt N kód kl i ni ky ( dvoj mí st né čí sl o)
zkr nvar char ( 5) A zkr at ka kl i ni ky
mai l nvar char ( 30) A mai l ová adr esa kl i ni ky
nazev nvar char ( 35) A cel ý název kl i ni ky

IP_052 Komunikace „Sophis - HVLP“:
1. Komunikace za účelem p edávání dat z KIS do IS
D_II
Sophis.
2. Obsahem p edávaných dat bude číselník HVLP

(hromadně vyráběné léčivé p ípravky a potraviny pro
zvláštní léka ské účely) uložený v KIS.
3. Export dat bude vyvolán akcí uživatele nebo
automaticky ve zvolený čas (nap . 23:00), pokud od

141
IP_053 posledního exportu došlo ke změně v exportovaných D_II Vyberte
IP_054 údajích. D_II Vyberte
IP_055 4. P edpokládá se, že IP p edá data zápisem do D_II Vyberte
komunikační databáze IS Sophis - jedná se o databázi
Microsoft SQL Server.
5. P edpokládá se struktura komunikační tabulky totožná
se strukturou číselníku na portálu VZP.
Komunikace „Sophis - IPLP“:
1. Komunikace za účelem p edávání dat z KIS do IS
Sophis.
2. Obsahem p edávaných dat bude číselník IVLP
(individuálně p ipravované léčivé p ípravky a výrobky
transfuzních stanic a radiofarmaka) uložený v KIS.
3. Export dat bude vyvolán akcí uživatele nebo
automaticky ve zvolený čas (nap . 23:00), pokud od
posledního exportu došlo ke změně v exportovaných
údajích.
4. P edpokládá se, že IP p edá data zápisem do
komunikační databáze IS Sophis - jedná se o databázi
Microsoft SQL Server.
5. P edpokládá se struktura komunikační tabulky totožná
se strukturou číselníku na portálu VZP.
Komunikace „Sophis - PZT“:
1. Komunikace za účelem p edávání dat z KIS do IS
Sophis.
2. Obsahem p edávaných dat bude číselník PZT
(prost edky zdravotní techniky) uložený v KIS.
3. Export dat bude vyvolán akcí uživatele nebo
automaticky ve zvolený čas (nap . 23:00), pokud od
posledního exportu došlo ke změně v exportovaných
údajích.
4. P edpokládá se, že IP p edá data zápisem do
komunikační databáze IS Sophis - jedná se o databázi
Microsoft SQL Server.
5. P edpokládá se struktura komunikační tabulky totožná
se strukturou číselníku na portálu VZP.
Komunikace „Merit“:
1. Komunikace za účelem p edávání dat z KIS do IS
Merit. Merit je controllingový systém, který slouží pro
tvorbu rozpočtů a sledování skutečnosti.
2. Obsahem exportovaných dat budou účty a jejich
položky vykázané pojišťovnám.
3. Export dat bude vyvolán akcí uživatele, systém se
dotáže na soubor s daty a časové období exportu.
4. Systém musí umožňovat tyto akce naplánovat a
provádět automaticky. Časové období v tomto p ípadě
musí být možné zadat buď jako pevné datum, nebo s
ohledem na aktuální datum (nap . data za posledních
10 dní, poslední měsíc, za poslední 2 měsíce apod.).
5. Data musí být možné exportovat do adresá e na
síťovém disku (zadaného prost ednictvím UNC cesty)
ve formě textových souborů, nabídnutý název musí být
„produkce“.
6. Oddělovačem jednotlivých datových položek bude znak
čárka „,“.
7. Definice položek viz tabulka 10.

142
Tabulka 10 Definice datových položek pro požadavek IP_055.

Název Typ Popi s
období i nt eger
t yp_dokl char ( 1) účt ovací období , f or mát r r r r mm
zvar i nt eger nabývá hodnot A, H nebo E podl e t ypu účt u
zad_i cz i nt eger kód žádaj í cí ho výkonového st ředi ska
var i nt eger i čz žádaj í cí ho výkonového st ředi ska
poj i nt eger kód pr ováděj í cí ho výkonového st ředi ska
kód pl át ce
sk_kod char ( 1)
kód skupi ny ( 0=výkon, 1 = HVLP, 2 = I VLP, 3 = PZT, 4 = st omat ol ogi e,
sk_kod1 char ( 2) K= kat egor i e, P= l ékový paušál , S=pásmo sest upné sazby)
kod char ( 7)
počet deci mal kód podskupi ny ( např. t r ansf úzní pří pr avky, r adi of ar maka)
body i nt eger kód pol ožky ( výkon, ZUP, . . )
uhr ada2 deci mal
deset i nné čí sl o ( des. odděl ovač t ečka)
počet bodů u výkonů u kor unových pol ožek 0
deset i nné čí sl o ( des. odděl ovač t ečka)

IP_056 Synchronizace registru pacientů: D_II Vyberte
1. Komunikace za účelem synchronizace registrů
IP_057 D_II Vyberte
IP_058 pacientů mezi registrem pacientů v KIS a dalšími D_II Vyberte
systémy zadavatele. K synchronizaci musí docházet
bezprost edně po změně údajů v některém
z komunikujících systémů.
2. Dodavatel navrhne technické ešení synchronizace
registrů a p ipraví p íslušné technické ešení.
3. Komunikace bude používat p ednostně rozhraní HL7,
pokud pro konkrétní komunikaci má rozhraní HL7
událost. Komunikace musí být schopná využívat
události ADT^A01, ADT^A04, ADT^A08, ADT^A18
z rozhraní HL7.
4. P edpokládaný rozsah p edávaných dat jsou
identifikační údaje pacientů (jména, p íjmení, tituly,
rodné číslo), údaje o zdravotním pojištění, adresy a
telefony.
5. Dále v integrační platformě dodavatel vytvo í webové
služby, které umožní dalším systémům získávat
identifikační údaje o pacientech z registru pacientů
v KIS, včetně jedinečného bezvýznamového
identifikátoru pacienta. Služby budou p ednostně v
rozhraní HL7, pokud pro konkrétní komunikaci má
rozhraní HL7 událost.
Synchronizace organizační struktury:
1. Komunikace za účelem synchronizace organizační
struktury mezi KIS a dalšími systémy zadavatele.
2. Dodavatel vytvo í v integrační platformě webové
služby, které umožní dalším systémům získávat údaje
o organizační struktu e.
Synchronizace číselníků:
1. Komunikace za účelem synchronizace číselníků

(číselník léka ů, zaměstnanců, číselníky VZP,
číselník laboratorních metod a další interní
číselníky FN HK) mezi KIS a dalšími systémy
zadavatele. V rámci ešení bude mít každý
číselník jednu „master“ verzi v konkrétním
integrovaném systému.
2. Dodavatel navrhne technické ešení automatické

143
IP_059 synchronizace číselníků a dodá p íslušné technické D_II Vyberte
IP_060 ešení. D_II Vyberte
Komunikace s vyvolávacími systémy: D_II Vyberte
IP_061 1. Komunikace za účelem ízení vyvolávacích systémů. D_II Vyberte
IP_062 2. Komunikace bude probíhat p edáváním souborů ve D_II Vyberte
IP_063 formátu „json“, komunikace bude obousměrná.
3. Zadavatel zajistí p edání popisu komunikačního
rozhraní.
Spouštění externího programu:
1. KIS musí být schopný spouštět externí programy
(umístěné na PC s klientem nebo na síťovém disku
zadaného pomocí UNC cesty) včetně vyplnění
parametrů p íkazové ádky. Toto spouštění musí být
uživateli umožněno volbou v menu a ikonou
v uživatelském prost edí.
2. Vytvo ení volby v KIS pro spouštění programu musí
být proveditelné proškolenými administrátory
zadavatele. Takto vytvo enou volbu musí být možné
p i adit jednotlivým uživatelům dle uživatelských rolí a
p ístupových práv.
3. Součástí volání externího programu musí být možnost
jako parametry p íkazové ádky zadat údaje z KIS
(nap . identifikace právě vybraného pacienta; bydliště
pacienta; č. editovaného chorobopisu; č. zobrazeného
vyšet ení; oddělení, na kterém se uživatel v KIS právě
nachází a další). Pro komunikaci musí být dostupné
všechny údaje uložené v KIS.
4. Počet takto vytvo ených voleb nesmí být omezen.
5. Komunikace nemusí probíhat p es integrační
platformu.
Komunikace „HL7 výsledky a žádanky“:
1. Komunikace za účelem p edávání výsledků a žádanek
mezi KIS a dalšími programy.
2. Integrační platforma musí být schopná do KIS zasílat a
z KIS p ijímat a p edávat dalším programům výsledky
vyšet ení (laboratorní výsledky, amb. záznamy a další)
a žádanky na tato vyšet ení v rozhraní HL7.
Komunikace „Objednávání stravy“:
1. Komunikace za účelem p edávání dat o požadované
pacientské stravě z KIS do IS ASTRIS – SW
stravovacího odboru.
2. V rámci zápisu dokumentace pacienta na lůžkovém
oddělení je zaznamenávána i p edepsaná dieta -
strava. Tyto informace je t eba sumarizovat (nap .
sečíst počet jednotlivých diet) a tato souhrnná data po
odděleních odeslat do IS ASTRIS.
3. Zadavatel zajistí p edání popisu komunikačního
rozhraní.
Komunikace s Národní identitní autoritou:
1. Komunikace za účelem aktualizace údajů o pacientech
v KIS (a dalších systémech se synchronizací registru
pacientů) na základě dotazů do Národní identitní
autority (NIA).
2. Dodavatel navrhne způsob a realizuje komunikaci
v plném rozsahu, který bude umožňovat NIA v době
akceptace díla.
3. Zadavatel sděluje, že je soukromoprávním uživatelem

144
IP_064 údajů. D_II Vyberte
IP_065 Komunikace s Infrastrukturními službami elektronického D_II Vyberte
IP_066 zdravotnictví (IDRR): D_II Vyberte
1. Komunikace za účelem výměny dat v rámci Národní
IP_067 D_II Vyberte
strategie elektronického zdravotnictví. D_IV Vyberte
IP_068 2. Dodavatel navrhne způsob a realizuje komunikace D_IV Vyberte
IP_069
v plném rozsahu, který bude umožňovat IDRR v době
akceptace díla.
Komunikace „LDAP“:
1. Komunikace za účelem správy uživatelů v KIS.
2. KIS musí být schopný spravovat uživatele
prost ednictvím LDAP komunikace. Tím se rozumí
zakládání nových uživatelů, změny osobních údajů
(jméno, p íjemní, tituly atd.), hlídání doby platnosti
p ístupu, rušení p ístupu a autentizaci uživatelů p i
p ihlášení na základě změn v Active Directory
zadavatele.
Komunikace „P ístupová práva“:
1. V době nasazení KIS bude ve FN HK v provozu
Identity management (IDM). KIS musí s tímto
systémem zabezpečeně komunikovat a ídit
p ístupová práva uživatelů v souladu s tímto
systémem.
2. Komunikace musí umožňovat správu uživatelských
účtů, všech jejich atributů a operace nad těmito účty
včetně p edání informací o konkrétním účtu, o všech
účtech, zablokování a odblokování účtu, modifikace
práv a atributů účtu.
3. V rámci Prováděcího Projektu dodavatel navrhne a
následně realizuje napojení na IDM ve FN HK a p ijme
komunikační rozhraní IDM.
Komunikace „eNeschopenka“:
1. Komunikace za účelem p edávání dat o dočasné
pracovní neschopnosti včetně elektronického hlášení
změn v průběhu pracovní neschopnosti dle legislativy
a požadavků Ministerstva práce a sociálních věcí
(MPSV).
2. Kontroly zadávaných údajů v KIS musí být nastaveny
tak, aby nedocházelo k odmítnutí dat ze strany MPSV.
Pokud k odmítnutí dojde, dodavatel je povinen provést
p íslušné opravy kontrol.
3. Zadavatel se musí zavázat k realizaci komunikace ve
verzi aktuální k datu akceptace díla.
Komunikace „Portál pacienta“:
1. Komunikace za účelem p edávání dat zobrazovaných
na portálu pacienta. Komunikace bude probíhat mezi
portálem pacienta a ostatními aplikacemi, ze kterých
budou získávána data pro zobrazení.
Komunikace „Fama“:
1. Komunikace za účelem p edávání údajů o
zdravotnických p ístrojích z IS Fama do KIS. V KIS je
nutné registrovat p ístroje použité v rámci klinické
události. Seznam těchto p ístrojů s informací o datu
provedení bezpečnostně technické kontroly a její
platnosti, výrobního čísla p ístroje a další údaje o
p ístrojích, musí být p enášeny z IS Fama do KIS.

145
2. Zadavatel zajistí p edání popisu komunikačního
rozhraní.

IP_070 Komunikace „PACS“: D_II Vyberte
1. Komunikace za účelem:
IP_071 D_II Vyberte
IP_072 1.1. Synchronizace registrů pacientů. D_IV Vyberte
1.2. P edávání dat o RTG vyšet eních (pacientské

údaje, žádanky a výsledky vyšet ení) mezi KIS a
PACS.
1.3. Plnění worklistů RTG modalit (worklisty RTG
modalit jsou ízeny p es PACS).
2. Pokud některá položka v komunikaci obsahuje rodné
číslo pacienta, musí být nastavitelné, zda bude rodné
číslo v rámci komunikace použito včetně lomítka, nebo
bez něj. Toto nastavení musí být možné správcem
systému z ad zaměstnanců FN HK a nastavení musí
být nezávislé na ostatních komunikacích.
3. Komunikace bude probíhat prost ednictvím HL7 zpráv.
4. KIS musí umožňovat p ipojit k položce
accessionNumber za účelem komunikace s PACS
prefix o délce minimálně 3 znaků dle požadavků
zadavatele. Prefix slouží k jednoznačnému oddělení
komunikace ze současného KIS (AMIS*H) a nově
dodávaného KIS.
5. KIS musí být schopen otev ít webový prohlížeč
s PACS dokumentací aktuálně zobrazeného pacienta
v KIS. Pokud je aktuálně prohlížen výsledek vyšet ení,
kde proběhla komunikace s PACS, musí být KIS
schopen otev ít prohlížeč PACS s dokumentací k
aktuálně zobrazenému vyšet ením. Komunikace bude
probíhat spuštěním programu dle zadavatelem
dodaného popisu.
5.1. Toto otev ení prohlížeče nemusí probíhat p es
integrační platformu.
6. Popis požadovaných IHE profilů a HL7 zpráv je
v p ílohách:
6.1. Priloha_Integracni_platforma_conformancestate
ment_hl7_en.pdf
6.2. Priloha_Integracni_platforma_conformancestate
ment_ihe_en.pdf.

Komunikace „Žádanky na dopravu“:
1. Komunikace za účelem p edávání žádanek na

dopravu mezi KIS a IS Dopravy.
2. V KIS musí být možné vytvo it a odeslat žádanku na

dopravu do externího IS.
3. Rozsah p edávaných dat odpovídá formulá i VZP -

P íkaz ke zdravotnímu transportu.
4. Zadavatel zajistí p edání popisu komunikačního

rozhraní.

Komunikace „Zabezpečeného dlouhodobého
důvěryhodného archivu“:
1. Komunikace za účelem ukládání uzav ené léka ské
dokumentace a metadat o této dokumentaci do Archivu
zdravotnické dokumentace (dle jen ZDDA), zobrazování
dokumentů uložených v ZDDA a změnách metadat o této
dokumentaci, včetně informací sloužících k určení
skartačních lhůt a zneplatnění dokumentů.
2. Zadavatel p edpokládá komunikaci pomocí webových
služeb p es API ZDDA. Archiv bude disponovat:
Formou rozhraní:

146
· Webové služby typu SOAP nebo REST.
· P edávání dokumentů dle standardu MTOM

(SOAP) nebo multipart (REST).
Operace rozhraní:

· P edání dokumentu a souvisejících metadat k
archivaci. Dokument lze p edat jako binární
p ílohu nebo jako externí identifikaci ve zdrojovém
systému.

· Získání dokumentu a souvisejících metadat z
archivu.

· Smazání dokumentu v archivu.
Zabezpečení rozhraní:

· Rozhraní dostupné po šifrovaném protokolu
HTTPS.

· Autentizace pomocí HTTP/BASIC nebo pomocí
certifikátu.

3. Komunikace s ZDDA bude probíhat automaticky, na
základě uzav ení, změn a p ípadně zneplatnění
dokumentu v KIS, nebo na základě požadavku uživatele
na zobrazení dokumentu, který je uložen v ZDDA.
4. Vzhledem ke skutečnosti, že p esný typ ZDDA ani jeho
API není v současné chvíli Zadavateli znám (bude
výsledkem výběrového ízení), požaduje Zadavatel na
straně komunikační platformy vytvo it konektor na API
ZDDA. Technický popis komunikačního rozhraní dodá
zadavatel dle výsledků výběrového ízení na ZDDA.

147
5 Požadavky na migraci dat a přechod na nový systém

5.1 Migrace dat a přechod na nový systém

5.1.1 Migrace dat

MIG_001 Uchazeč zajistí migraci dat ze stávajícího systému AMIS*H. D_II Vyberte
D_II Vyberte
MIG_002 Uchazeč zajistí migraci dat do odpovídajících položek
datových struktur navrženého systému ve strukturované formě, D_II Vyberte
minimálně dle aktuální struktury dat v systému tak, aby byla
zachována logika jednotlivých události. D_II Vyberte
D_IV Vyberte
MIG_003 Uchazeč musí zajistit migraci a kontinuitu provozu p i p echodu D_II Vyberte
ze stávajícího systému do nového minimálně na úrovni:
· registr pacientů
· registr zaměstnanců
· organizační struktura
· uzav ené závěrečné zprávy včetně p ekladů
· uzav ené ambulantní zprávy
· uzav ené výsledky výkonových pracovišť
· operační protokoly
· porodopisy
· zprávy o novorozenci
· popisy zobrazovacích vyšet ení
· výsledky laborato í patologie, RIA a hematologie
vedených v AMIS*H včetně archivu
· data pojišťovny v celém rozsahu
· recepty a poukazy minimálně za posledních 5 let

MIG_004 Účastník poskytne podporu pro zajištění kontinuity provozu p i
p echodu ze stávajícího systému do nového systému (nap .
automatizovaný export obložnosti lůžek, statistických výkazů)
v souladu s prováděcím projektem, který bude vytvo en i na
základě doporučení dodavatele a jím preferovaným způsobem
zachování kontinuity provozu.

MIG_005 Uchazeč zajistí p evod výjezdových zpráv zdravotnické
záchranné služby ve formátu PDF/A umístěných
v propůjčenému archívu, kterého vlastníkem je Zdravotnická
záchranná služba Královehradeckého kraje p.o.

MIG_006 Migrační scéná e a podrobný rozsah migrovaných dat budou
p edmětem dokumentace Prováděcího projektu minimálně v
rozsahu:
· Analýza dat určených pro migraci
· Dohoda struktury dat k migraci
· P íprava migračních skriptů
· P íprava dat k migraci
· Testovací migrace a vyhodnocení
· Revize migračních skriptů, oprava datových struktur,
oprava chybných dat
· Testovací migrace a vyhodnocení 2
· Revize migračních skriptů
· Testování po izování nemigrovaných dat
· Migrace provozních dat

148
MIG_007 Zadavatel požaduje migraci dat jako součást implementace. D_II Vyberte
D_II Vyberte
5.1.2 Přechod na nový systém
D_II Vyberte
MIG_008 Zadavatel požaduje zajištění kontinuity provozu
zdravotnického za ízení. Z důvodu nep etržitého provozu
p edpokládá pouze plánovanou odstávku na nezbytně nutnou
dobu – maximálně 4 hodin.

MIG_009 Samotnému spuštění do ostrého provozu bude p edcházet:
· test p evodu dat,
· zaškolení všech uživatelů a správců systému na
vlastních zmigrovaných datech,
· provedení zátěžových testů – souběžná práce
minimálně 30 % uživatelů,
· simulace výpadků HW,
· test poškození operačního systému nebo databáze a
jejich obnova ze záloh,
· provedení penetračních testů celého systému v
souladu s normami ČSN ISO/IEC TR 13335 a ISO/IEC
27002:2013 dle obecně uznávané metodiky (nap .
OSSTMM, OWASP, NIST, apod.),
· provedení akceptačních testů klíčových funkcionalit,
· podpora definice p ístupových práv,
· dodání videonávodů k typickým činnostem v KIS,
· dodání eLearningového kurzu minimálně pro typickou
činnost sestry, léka e a správce v KIS.

149
6 Zálohování

Informace k zálohovacímu systému objednatele jsou uvedeny v p íloze č.2.

ZAL_001 Pro zálohovaní uchazeč využije existujícího centrálního
zálohovacího ešení FNHK popsaného v p íloze č.2
zadávací dokumentace nap . kapitola 1.4.6.1. SW licence P Vyberte
zálohovacího systému pro první úroveň zálohování musí Vyberte
zajistit zhotovitel.
Vyberte
ZAL_002 Pokud bude uchazeč pro jím navržený zálohovací postup
požadovat navíc jiné zálohovací HW a SW, pak náklady na Vyberte
rozší ení stávajícího zálohovacího ešení zadavatele musí P Vyberte
Vyberte
zahrnout do celkových nákladů dodávky. Vyberte

ZAL_003 Účastník popíše zálohování/archivace všech dodávaných
komponent, tedy portálu pacienta, integrační platformy
včetně komunikačních vazeb, zabezpečeného
důvěryhodného archívu a klinického informačního systému.
Detailní konečná specifikace zálohování bude součásti
dokumentu „prováděcí projekt“.
Minimální rozsah požadavků:
· online zálohy operačního systému se splněním
podmínky crash konzistence dat

· online zálohy dat databází všech dodávaných P
komponent se splněním podmínky aplikační crash
konzistence dat

· doporučení frekvence záloh a požadavky na RPO
minimálně však RPO 2 hodiny, historie databáze s
granularitou posledních 7 dní po dni

· specifikaci co bude obsahem záloh a s jakými
podmínkami (Unix/Win, typ DB, konzistence objektů,
operační systém/konfigurace, data, programy, jiné)
· specifikaci objemu dat v GB četně plánovaných
p írůstků za rok

ZAL_004 Uchazeč zajistí zálohu všech denních transakčních protokolů P
za posledních 52 týdnů po týdnu a posledních 5 let po 3
měsících.

ZAL_005 Požadujeme zálohovat vlastní data všech komponent P
s frekvencí minimálně 1x denně a full záloha nesmí být delší
než 3 hod.

ZAL_006 Všechny softwarové části informačního systému mimo P
vlastní data aplikací (tedy operační systém, aplikace,
databázový stroj apod.) požadujeme minimálně 1x týdně.

ZAL_007 Všechny dodávané komponenty musí být schopny a
p ipraveny na zálohování p es zálohovací systém
objednatele.
Integrace do centrálního systému zálohování není součástí
dodávky, konfiguraci si zajistí objednatel. Zhotovitel poskytne
parametry, podmínky a součinnost p i nastavení zálohování
dodaného ešení. Za dostupnost a integritu záložních dat a P

archívů v první úrovni nese plnou odpovědnost zhotovitel, ve
druhé úrovni (HP Data Protectorem), pak zadavatel.
Zadavatel pro první úroveň zálohování p ipouští nastavení
dostatečně zabezpečeného sdílení. Data Protectorem se
budou zálohovat pouze data z namountovaných filesystémů

150
serveru (mezi nimi mohou být vysdílené filesystému/složky).
DataProtector nebude zálohovat data ze sdílených (p esněji
ečeno namapovaných) filesystémů ať již jsou jakéhokoliv
typu (SMB, FTP apod.).

ZAL_008 Zálohy musí zajistit p edevším ochranu p ed:

· nechtěným nebo úmyslným zásahem uživatele nebo
správce

· negativním působením škodlivých SW a kódů (viry P Vyberte
apod.)

· poškozením dat vlivem chyb aplikace, databáze,
oper. systému nebo jiných SW

· poškozením dat vlivem chyb HW, výpadkům proudu
· poškozením vlivem jiných negativních vlivů

151
7 Bezpečnost

BEZ_001 Dodaný IS 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četně zajištění p ipravenosti na
postupné opuštění rodných čísel jako jediného a výměnného P Vyberte
identifikátoru a zavedení bezvýznamových identifikátorů Vyberte
během doby udržitelnosti, pokud nebude možné tento Vyberte
p echod realizovat během realizace projektu. Vyberte
Vyberte
BEZ_002 Dodaný IS bude chránit osobní údaje pacientů a bude v Vyberte
souladu s Na ízením Evropského parlamentu a Rady (EU)
2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob P Vyberte
(GDPR) v souvislosti se zpracováním osobních údajů a o
volném pohybu těchto údajů.

BEZ_003 Dodaný IS bude v souladu se zákonem č. 181/2014 Sb.
(zákon o kybernetické bezpečnosti) v aktuálním znění a
vyhlášky č. 82/2018 Sb. (vyhláška o kybernetické
bezpečnosti) v aktuální znění a navazujícími právními
p edpisy. Zadavatel dále uvádí, že Národní ú ad pro
kybernetickou a informační bezpečnost podle § 22a odst. 1
zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o P
změně souvisejících zákonů (zákon o kybernetické
bezpečnosti), ve znění pozdějších p edpisů, v ízení ve věci
určení Zadavatele rozhodl, že Zadavatel je provozovatelem
základní služby. Dodaný IS bude v souladu
s bezpečnostními podmínkami informačního systému
základní služby.

BEZ_004 Dodané ešení bude disponovat možnosti automatického P
odhlášení nečinného uživatele včetně nastavení délky
časového intervalu.

BEZ_005 Všichni uživatelé dodaného IS zůstávají v systému i po
ukončení platnosti jejich účtu bez p ístupu k systému.
Uchování neaktivního uživatele (zánik objektu v AD) je pro P

pot eby uchování historie.

BEZ_006 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.
Systém umožní hierarchické nastavení p ístupových práv se
stanovením rozsahu p ístupu i stupně oprávnění manipulace P

se záznamem (čtení / nový záznam / úprava / rušení
záznamu). Princip nastavování p ístupových práv
jednotlivým uživatelům musí vycházet z definice libovolného
množství uživatelských rolí, do kterých jsou samotní
uživatelé p i azování.

BEZ_007 ízení p ístupů:
1. Zavedení uživatelských rolí, zajišťujících p ístup k
odpovídajícím funkcím a datům v systému na všech
úrovních.
2. Možnost dočasného p i azení rolí v p ípadě zástupů – P

zadáním počátečního a koncového data p idělení role a
umožnění definovaného p ístupu jen v tomto intervalu.
3. Zabránění vstupu neautorizovaného subjektu do systému

152
– zamezení možnosti p ístupu neoprávněného subjektu.

BEZ_008 Výměna dat: P Vyberte
1. Zajištění šifrované komunikace koncových stanic v Vyberte
síťovém prost edí zadavatele
Vyberte
BEZ_009 Výměna dat: Vyberte
1. Zajištění šifrované komunikace koncových stanic v Vyberte
odděleném síťovém prost edí. Vyberte
2. Zajištění výhradní komunikace mobilního prost edku pro
zadávání dat s datovým centrem prost ednictvím P

broadbandovým 4G p ipojením p es privátní síť APN
(eliminace jiného druhu datového p ipojení – Wi-Fi, BT
apod.)

BEZ_010 U mobilních za ízení (tabletů) udržovat lokálně jen data,
která jsou nutná pro aktuální práci. Po ukončení (potvrzené
p edání na server) automaticky mazat data uložená na P
mobilních za ízeních. Umožnit administrátorsky vzdáleně
smazat data z tabletu (nap . ztráta/krádež/servis tabletu).

BEZ_011 Evidence p ístupů všech uživatelů do systému (logování) P
včetně časových údajů a identifikace místa p ístupu
(za ízení).

BEZ_012 Veškerá externí komunikace (mimo LAN) bude zajišťována P
prost ednictvím zabezpečených (šifrovaných kanálů).

BEZ_013 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 koncových
za ízení použitím anti-X ešení. Po ízení firewallů/UTM a
anti-malware ešení nejsou p edmětem této zakázky. Jedná P

se pouze o požadavek na obecnou podporu IS pro tyto
technologie. P ístup do prostor s fyzickými servery bude
ízen a umožněn jen oprávněným osobám.

153
8 Provozní podmínky

V této kapitole jsou uvedeny podmínky následného provozu a údržby pro zajištění
provozu IS a jeho částí a zajištění udržitelnosti projektu.
8.1 Uživatelé

PRP_001 KIS musí umožnit využívání následujícími minimální počty
uživatelů:

Kategorie Počet uživatelů

Lékaři 880

Farmaceuti 5
JVŠ
25 P Vyberte

NLP 2 060 Vyberte
Vyberte
POD 0

Nezdravotníci 245

Počet celkem 3215

PRP_002 KIS musí být dimenzován minimálně pro 1500 současně P
pracujících uživatelů.

PRP_003 Portál pacienta umožní vytvo it neomezený počet uživatelů. P

8.2 Požadované provozní podmínky

PRP_004 Požadované provozní podmínky ešení:
· Systém by měl s rezervou splňovat výkonnostní a
kapacitní požadavky na komfortní práci po dobu
minimálně 10 let.
· Systém bude odolný proti výpadků min. 1 fyzického
serveru. Všechny servery využité v ešení mají
vnit ní redundanci komponent.

· Datová úložiště budou chráněna redundancí na
úrovni vnit ních komponent, vlastních úložišť a
rozdělením do dvou datových center. Komunikace P Vyberte

datových úložišť bude zajištěna p es SAN
infrastrukturu s redundancí komunikačních kanálů.
· Bude zajištěná redundance na úrovni napájení.
· Konečné ešení bude odolné proti výpadku jednoho
datového centra.

· Celkové ešení musí umožnit realizaci vysoké
dostupnosti minimálně formou Active/Passive
clusteru.

154
8.3 Zajištění provozu řešení

PRP_005 Datová centra jsou provozována v režimu 24x7x365, tj.
nonstop. Popis následné technické a technologické podpory
realizovaného ešení a způsobu jejího zajištění je obsažen v
následujících bodech:

· Technologie budou navrženy tak, aby bylo možné
dodržet vysokou dostupnost, a zajistit tak vysokou
dostupnost služeb.

· Správa a administrace p íslušného aplikačního,
databázového a systémového software a správa
p íslušné technické infrastruktury – nap . konfigurace
a rekonfigurace, systémová nastavování,
nastavování p ístupových oprávnění, správa licencí
atd.

· Dohled nad ešením, p ípadně jeho částmi
· Zálohování ešení (data, konfigurace, SW
infrastruktura).
· 1st level support, vyhodnocení hlášených problémů a
p edávání závad na technickou a technologickou
podporu dodavatele.
P Vyberte
· Technická a technologická podpora a aplikační
podpora budou zajištěny na základě smluvních
vztahů s dodavateli (viz následující kapitola).
Součástí smluv budou také dohody o úrovni služeb
(SLA). P edpokládá se dlouhodobé využití projektu,
kdy jeho funkčnost a stabilita bude zajišťována
jednak interními zaměstnanci tak i externími
dodavateli.

· Změny v informačním systému budou závislé na
vývoji a změně legislativy ovlivňující zdravotnická
za ízení a jiných souvisejících standardů (nap íklad
nová verze datového standardu Ministerstva
zdravotnictví – DASTA, nebo HL7) a změny
vyplývající z nových pot eb a požadavků
provozovatele IS FN HK. Programové zapracování
těchto změn bude upraveno smluvně s dodavatelem
ešení.

· V rámci provozu mohou být ešeny i další služby,
které budou zajištěny buď pracovníky žadatele a
p íjemce, nebo smluvně u poskytovatele služeb.

8.4 Technická, technologická a aplikační podpora

PRP_006 Technická, technologická a aplikační podpora projektu bude D_IV Vyberte
zajištěna v následujícím rozsahu:
· V režimu 7x24x365 – jde o kritický systém, základní
služby s vedením, který je nezbytný pro provoz klinik FN
HK. Systém zpracovává osobní údaje a citlivá data
(zdravotnická dokumentace).
· Součástí bude podpora a údržba (maintenance)
technologií a dodaného SW, technická a technologická
podpora a aplikační podpora nad rámec záruky s
kratšími SLA než v p ípadě záruky.
· Součástí technické a aplikační podpory budou:
o Nezbytné úpravy systému vyplývající ze změn
legislativy, vyhlášek, p ípadně dalších závazných

155
dokumentů.
o Rozvoj systému v návaznosti na nové pot eby

zadavatele.
o Pozáruční servis HW a SW infrastruktury.
o Poskytnutí helpdesku jako jednoho kontaktního

místa pro hlášení incidentů a požadavků.
o Provádění pravidelných profylaktických činností.
o Poskytování konzultací v dohodnutém rozsahu.
o Závazky zapracovat změny vyplývající z opuštění

rodných čísel jako jediného a výměnného
identifikátoru a zavedení bezvýznamových
identifikátorů od rodných čísel k bezvýznamovým
identifikátorům.
·

156
9 Požadované služby

9.1 Služby v rámci dodávky

PRP_007 . V rámci dodávky budou požadovány následující služby

· Projektové ízení dodávky ešení.
· Zpracování analýzy a návrhu ešení – konkretizace

implementačního postupu, p esné konfigurace a
instalačního a montážního návrhu ešení z nabídky.
· Dodávka, implementace, instalace, konfigurace HW a
SW infrastruktury.
· Vytvo ení integračních vazeb s vybranými systémy a
komunikace s jejich dodavateli.
· Implementace informačního systému a jeho součástí.
· Výchozí import datových zdrojů a metadat do systému
(migrace dat).
· Ově ení funkčnosti dodaného systému a jeho částí.
· Zpracování dokumentace 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 elektronicky.

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á. P Vyberte

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ě.
· Zhotovitel dodá dokumentaci k dodanému systému a
jeho částí minimálně v rozsahu:
o 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.
o 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í

157
a detailní popis údržby systém.
o 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.
o Dokumentace Prováděcí projekt – dodavatel
zpracuje komplexní a detailní návrh nasazení
informačního systému, a to ve vazbě na požadavky
uvedené v této p íloze dokumentace, jejích
p ílohách a smlouvě o dílo na dodávku na systém
jako celek a na jeho hlavní funkcionality. Cílem je
zpracování dokumentu v takové mí e detailu
jednotlivých postupů a prací zasazení do prost edí
a jeho nastavení, která umožní dosažení zavedení
systému do rutinního provozu ízenou formou.
Dokument proto bude jednoznačně a jasně
konkretizovat jednotlivé kroky prací a to min. v
rozsahu, které kroky a jakým způsobem budou
ešeny, kým budou ešeny, za jaké součinnosti
objednatele a v jakém čase. Taková konkretizace
bude dále dodržovat časovou, věcnou a logickou
souslednost a bude z ní tedy možné v každém
okamžiku realizace díla určit co je právě
realizováno a v jakém stavu a co bude následovat.
Objednatel bude moci na základě takových
podkladů alokovat své pot ebné kapacity na
součinnost a průběžnou kontrolu plnění díla.
Dokument bude dále konkretizovat minimálně tyto
oblasti

• návrh ešení instalace aplikační a databázové
části systému (architektura technického ešení)
• detailní popis nastavení / konfigurace /
parametrizace jednotlivých oblastí (společné
registry, role a p ístupová oprávnění, číselníky,
reporty atd.)

• návrh technického ešení integračních vazeb
(vazby mezi subsystémy, vazby s vybranými
aplikacemi objednatele, vazby se
spolupracujícími centrálními systémy)

• návrh ešení postupu a po adí p i nasazování
jednotlivých oblastí – up esnění harmonogramu
projektu

• návrh ešení migrace dat (oblasti / agendy k
migraci, výčet jednotlivých atributů, mapování
na cílovou tabulku, časový rozsah migrovaných
dat); mapování dat migrace z původních
databází NIS bude provedeno na takovou
úroveň, aby bylo možné jednoduše a
jednoznačně dohledat odkud (DB, tabulky,
sloupce) byla konkrétní data p esunuta kam
(DB, tabulky, sloupce)

• popis p ípadných organizačních opat ení
nutných pro implementaci (nap . pracovní
schůzky)
• up esnění časového harmonogramu projektu,
součástí harmonogramu dodávky budou i
p edpokládané termíny pro dodávku a nasazení
dílčích technologií v souvislosti
· postup s nasazením NIS na jednotlivých

158
odděleních (tiskárny, čtečky, velkoplošné
monitory - tyto technologie dodá objednatel)

• rozsah součinnosti ze strany objednatele
• návrh průběhu testovacího provozu
o Bezpečnostní dokumentace - Účelem
bezpečnostní dokumentace je definovat závazná
pravidla pro zajištění informační bezpečnosti
včetně stanovení 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.)
o Kompletní projektovou dokumentaci, která bude
obsahovat minimálně - smluvní dokumentace,
harmonogram realizace projektu, analýzy a
prováděcí projekt, zápisy z jednání, protokoly
(p edávací, akceptační)
Všechny dodávky a p evzetí plnění/ ešení (i částečného)
budou vždy stvrzeny písemně (akceptačním/p edávacím
protokolem nebo dodacím listem).

159
Příloha č. 5 - Požadavky na prezentaci KIS před podpisem smlouvy
Název projektu : Modernizace IT FN HK v návaznosti na eHealth

Modrá barva písma – instrukce pro prezentující osoby uchazeče v průběhu prezentace díla
Hnědá barva písma – komentáře pro prezentující osoby uchazeče, které popisují:

• prvky ve scénáři, které si uchazeč ve své databázi musí připravit dopředu před prezentací díla
(např. sestavy pacientů, konkrétní zdravotníky v jejich předem definovaných rolích),

• stanovují anamnestické údaje a ostatní okolnosti, které mají význam pro průběh scénáře
(např. obsahují časové informace, názvy zúčastněných pracovišť zadavatele) a budou mít v průběhu scénáře význam a dopad na zaznamenané skutečnosti.

Červená barva písma - použití čtečky nebo tisk dokumentu bude předveden - uchazeč načte čárový kód nebo vytiskne specifikovaný dokument na papír.

Č. PC1 / PC2 Instrukce / komentář Zvýhodněná funkcionalita
pro ověření přílohy č. 8
ř.

Pokud nemá uchazeč Master Patient Index (MPI) umístěn a spravován přímo v KIS, pro účely prezentace díla vytvoří takové

1 řešení, které MPI zpřístupní v samostatné aplikaci a KIS v průběhu prezentace díla bude využívat služeb a informací umístěných
v takové aplikaci. Nemožnost prezentovat funkcionality MPI a KIS ve vzájemné interakci s cílem předvést níže popsané scénáře

v rámci prezentace díla znamená vyloučení uchazeče z účasti na veřejné zakázce.

Uchazeč provede přípravu na prezentaci díla dle níže uvedených scénářů. Každý fiktivní pracovník má své jméno, příjmení,

2 osobní číslo v personální struktuře nemocnice a unikátní login. Soubor fiktivních pracovníků nemocnice, který si uchazeč
připraví, není omezen; takový soubor fiktivních pracovníků ale musí obsahovat alespoň níže uvedené postavy účinkující ve

scénářích.
Uchazeč pro účely prezentace díla předvede body scénářů v chronologickém pořadí daném zadavatelem v příloze č. 5.

3 Uchazeč si zvolí způsob a technické řešení, jakým musí simulovat specifikovaný časový odstup jednotlivých akcí při

prezentaci díla.
Fiktivní pracovníci uvedení níže mají přidělené své unikátní:

• loginy a hesla,

• role,

4 • vymezení přístupu na konkrétní pracoviště

• vymezení přístupu ke specifickým funkcím, jestliže je to relevantní

• všechni fiktivní pracovníci mají přístupný nástroj obecného dotazu v KIS

s výjimkou jednoho z nich: Chirurga Zkušeného.

5 Minimální soubor fiktivních pracovníků pro scénář plánované hospitalizace na chirurgii:

• Chirurg Zkušený – lékař se specializovanou způsobilostí, chirurg, má přístupová práva do Master Patient Indexu (MPI),

přístup na standardní oddělení, operační sály, chirurgickou JIP, chirurgickou ambulanci, urgentní příjem, má pravomoci

primáře ve smyslu plánování operací jménem chirurgického oddělení výhradně mimo řádnou pracovní dobu od 15:00-7:00 ve

všední dny, má práva pro vystavování žádanek na magnetickou rezonanci, může definitivně uzavírat zdravotnickou

6 dokumentaci, digitálně podepisovat uzavřenou dokumentaci. U Chirurga Zkušeného v rámci scénáře níže předvede uchazeč

kompletní proces přidělení rolí nikoliv de novo, ale právě přenosem od jiných v systému již existujících a oprávněných lékařů,

vymezení rozsahu přístupových práv na konkrétní pracoviště nemocnice a jiné zpřístupněné funkce, které jsou k problematice

relevantní. U Chirurga Zkušeného přístupová práva jiného chirurga, od kterého bude „dědit“ svá přístupová práva, nezahrnují

urgentní příjem – přístupové právo na urgentní příjem bude uchazeč při prezentaci díla přidávat.

1
• Chirurg Mladý - lékař bez specializované způsobilosti, chirurg, má přístupová práva do MPI, přístup na standardní oddělení,

operační sály, chirurgickou JIP, chirurgickou ambulanci, urgentní příjem, nemá oprávnění pro vystavení žádanky na

7 magnetickou rezonanci, nemá oprávnění finalizovat a uzavírat zdravotnickou dokumentaci, má v souladu s KIS_048

oprávnění po zdůvodnění přístupu způsobem specifikovaným zadavatelem nahlížet do zdravotních záznamů v KIS u pacientů

i z jiných pracovišť nemocnice, než je pro jeho roli specifikováno výše,
• Operatér Centrální – lékař se specializovanou způsobilostí s přístupovými právy na úrovni primáře oddělení centrálních

operačních sálů, lékař se specializovanou způsobilostí, chirurg, má přístupová práva do MPI,přístup na standardní oddělení,

8 operační sály, chirurgickou JIP, chirurgickou ambulanci, urgentní příjem, má práva pro vystavování žádanek na magnetickou

rezonanci, může definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci,

• Anesteziolog Zkušený – lékař se specializovanou způsobilostí, anesteziolog, má přístupová práva do MPI, přístup do

9 anesteziologické ambulance pro předoperační vyšetření, ordinace léků pro premedikaci, plánování anestezie u pacientů

zařazených do operačního programu, přístup na chirurgickou JIP, ARO, urgentní příjem, má práva pro vystavování žádanek,

může definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.
• Anesteziolog Mladý – lékař bez specializované způsobilosti, anesteziolog, má přístupová práva do MPI, přístup do

10 anesteziologické ambulance pro předoperační vyšetření, ordinace léků pro premedikaci, plánování anestezie u pacientů

zařazených do operačního programu, přístup na chirurgickou JIP, ARO, urgentní příjem, má práva pro vystavování žádanek,

nemůže definitivně uzavírat zdravotnickou dokumentaci.
• Radiolog Zkušený – lékař se specializovanou způsobilostí, radiolog, má přístupová práva do MPI, přístup do formulářů

11 dedikovaných pro radiodiagnostická pracoviště, může zobrazovat u rozpracovaného pacienta jeho zdravotnickou dokumentaci

tak, jak je specifikováno v ZD, může definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou

dokumentaci
• Radiolog Mladý – lékař bez specializované způsobilosti, radiolog, má přístupová práva do MPI, přístup do formulářů

12 dedikovaných pro radiodiagnostická pracoviště, může zobrazovat u rozpracovaného pacienta jeho zdravotnickou dokumentaci
tak, jak je specifikováno v ZD, nemá oprávnění definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat

uzavřenou dokumentaci.
• Asistent Radiologický – pozice radiologického asistenta, má přístupová práva do MPI, přístup do formulářů dedikovaných

13 pro radiodiagnostická pracoviště v rozsahu odpovídajícím této pracovní pozici, nemůže přistupovat do popisu nálezu, nemůže

uzavřít radiologickou zdravotnickou dokumentaci.
• Administrativa Kartotéční – nezdravotník, má přístupová práva do Master Patient Indexu (MPI). Může přidělovat pacienty do

front čekajících na konkrétní ambulantní pracoviště. Může zobrazit v KIS zpřístupněnou historii ošetření pacienta, ale nemůže

zobrazovat detailní záznamy ve zdravotnické dokumentaci (např. číst uzavřené ambulantní zprávy nebo závěrečné zprávy z

hospitalizace). Může na pokyn lékaře vyhledávat termíny a objednávat pacienty na ambulantní vyšetření. Má ale přístup k

funkcionalitám pro radiologii, aby mohla zapisovat diktované záznamy.

14 • Náměstek Lékařský – lékař se specializovanou způsobilostí, zástupce nejvyššího vedení FN HK, odborností pediatr, má

přístupová práva do MPI, může přistupovat na všechna výkonová střediska nemocnice, zobrazovat přehledy lůžkové kapacity

jako na OUM, má přístupné i funkce pro oddělení nemocniční hygieny; má neomezený přístup do zdravotnické dokumentace

pacientů pro její čtení, nikoliv editaci – při zobrazování jejich výsledků musí být jeho vstup logován.

• Náměstkyně Ošetřovatelská – sestra se specializovanou způsobilostí, zástupce nejvyššího vedení FN HK, má přístupová

práva do MPI, může přistupovat na všechna výkonová střediska nemocnice, zobrazovat přehledy lůžkové kapacity jako na

OUM, má přístupné i funkce pro oddělení nemocniční hygieny; má neomezený přístup do zdravotnické dokumentace pacientů

pro její čtení, nikoliv editaci – při zobrazování jejich výsledků musí být jeho vstup logován.

2
• Dokumentaristka – nezdravotník, má oprávnění vidět uzavřenou zdravotnickou dokumentaci, zadávat kódy MKN 10 do účtu

pro zdravotní pojišťovny i do výkazu pro ÚZIS. Právo vykazovat zdravotní výkony včetně ZUM a ZULP, vystavovat poukazy,

vykazovat účty za hospitalizaci, provést opravy, provést finální vyúčtování a finální archivaci zdravotnické dokumentace tak,

že po splnění podmínky schválení dokumentace lékařem se specializovanou způsobilostí pro kohokoli definitivně uzavře proti

změnám. Má přístup výhradně ke čtení zdravotnické dokumentace ambulantně ošetřovaných a hospitalizovaných pacientů;

tyto typy dokumentů nesmí editovat, mazat a nemá oprávnění vytvářet nová ambulantní ošetření nebo dokumentačně

zahajovat hospitalizace; její přístup do dokumentace je logován.

• Sestra Chirurgická – zdravotní sestra s přístupovými právy role zdravotní sestry kdekoli na chirurgické klinice včetně

oddělení centrálních operačních sálů má přístupová práva do MPI.

15 • Instrumentářka Chirurgická – zdravotní sestra s přístupovými právy role zdravotní sestry na oddělení centrálních operačních

sálů.

• Sestra Anesteziologická – zdravotní sestra s přístupovými právy role zdravotní sestry na oddělení centrálních operačních

sálů a do anesteziologické ambulance, má přístupová práva do MPI.

• Hygienička Nemocniční – lékařka, přístup na všechna výkonová střediska nemocnice, ale nemá neomezený přístup do

zdravotnické dokumentace pacientů, kdy může zobrazovat a tisknout mikrobiologické, hematologické, biochemické a

patologické výsledky, ambulantní zprávy, epikrízy a závěrečné zprávy z hospitalizací může číst, případně tisknout, nemá

oprávnění texty editovat – při zobrazování jejich výsledků musí být její vstup logován. Má práva k formulářům v rámci procesní

podpory nemocniční hygieny, zejména pak k historii hospitalizovaných. Má právo nastavovat alert protiepidemických opatření.

• Doktor Akutní – internista, lékař se specializovanou způsobilostí, má přístupová práva do MPI, kmenově pracuje na

urgentním příjmu, kde z pohledu činnosti KIS může vykonávat všechny činnosti, které ambulantnímu pracovišti

stacionářového typu přísluší včetně definitivního uzavírání ambulantních zpráv a vyúčtování poskytnutých zdravotních služeb;

má oprávnění nahlížet do systému volné lůžkové kapacity a je příjemcem informací KIS o obsazenosti lůžkové kapacity v

rámci kontaktního místa poskytovatele vůči záchranné službě.

• Sestra Akutní – zdravotní sestra s přístupovými právy role zdravotní sestry na urgentním příjmu; má přístup do MPI, má

oprávnění nahlížet do systému volné lůžkové kapacity a je příjemcem informací KIS o obsazenosti lůžkové kapacity v rámci

kontaktního místa poskytovatele vůči záchranné službě.

16 • Neurolog Mladý – lékař bez specializované způsobilosti, neurolog, má přístup do MPI, přístup na všechna pracoviště

neurologické kliniky – ambulance, lůžka standardní i JIP, může zobrazovat u rozpracovaného pacienta jeho zdravotnickou

dokumentaci tak, jak je specifikováno v ZD, nemá oprávnění definitivně uzavírat zdravotnickou dokumentaci, digitálně

podepisovat uzavřenou dokumentaci.

• Neurolog Zkušený – lékař se specializovanou způsobilostí, neurolog, má přístupová práva do MPI, přístup na všechna

pracoviště neurologické kliniky – ambulance, lůžka standardní i JIP, má práva pro vystavování žádanek na všechna vyšetření,

může definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

• Sestra Jipecká - zdravotní sestra s přístupovými právy role zdravotní sestry na neurologické JIP, má přístupová práva do

MPI.

3
• Neurochirurg Zručný - lékař se specializovanou způsobilostí, neurochirurg, který má v rámci pracoviště přístup na všechny

ambulantní pracoviště, operační sály, lůžkové stanice standardní i JIP neurochirurgické kliniky. Má přístupová práva do MPI,

má práva pro vystavování žádanek na všechna vyšetření, může definitivně uzavírat zdravotnickou dokumentaci, digitálně

podepisovat uzavřenou dokumentaci.

• Gynekolog Zkušený - lékař se specializovanou způsobilostí, gynekolog, který má v rámci pracoviště přístup na všechny

ambulantní pracoviště, operační sály, lůžkové stanice standardní i JIP a trakt porodních sálů včetně sekčního sálu pro

císařské řezy. Má přístupová práva do MPI, má práva pro vystavování žádanek na všechna vyšetření, může definitivně

uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

• Asistentka Ambulantní – porodní asistentka se specializovanou způsobilostí s přístupem na příjem těhotných, porodní sály,

sál pro císařské řezy, má přístupová práva do MPI,

17 • Gynekolog Mladý – lékař bez specializované způsobilosti, gynekolog, má přístupová práva do MPI, přístup na všechna

pracoviště gynekologické kliniky – ambulance včetně poraden, lůžka standardní i JIP, porodní sály, operační sály

gynekologie, může zobrazovat u rozpracovaného pacienta jeho zdravotnickou dokumentaci tak, jak je specifikováno v ZD,

nemá oprávnění definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

• Asistentka Zkušená – porodní asistentka se specializovanou způsobilostí s přístupem na příjem těhotných, porodní sály, sál

pro císařské řezy, má přístupová práva do MPI.

• Gynekolog Nejmladší – lékař bez specializované způsobilosti, gynekolog, má přístupová práva do MPI, přístup na všechna

pracoviště gynekologické kliniky – ambulance včetně poraden, lůžka standardní i JIP, porodní sály, operační sály

gynekologie, může zobrazovat u rozpracovaného pacienta jeho zdravotnickou dokumentaci tak, jak je specifikováno v ZD,

nemá oprávnění definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

• Gynekolog Vedoucí - lékař se specializovanou způsobilostí, gynekolog, který má v rámci pracoviště přístup na všechny
ambulantní pracoviště, operační sály, lůžkové stanice standardní i JIP a trakt porodních sálů včetně sekčního sálu pro
císařské řezy. Má přístupová práva do MPI, má práva pro vystavování žádanek na všechna vyšetření, může definitivně
uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.
• Pediatr Zkušený - lékař se specializovanou způsobilostí, pediatr, který má v rámci pracoviště přístup na neonatologické

oddělení porodního sálu, všechna ambulantní pracoviště, lůžkové stanice standardní i JIP pro větší děti i lůžkové stanice

standardní i JIP neonatologického oddělení dětské kliniky. Má přístupová práva do MPI, má práva pro vystavování žádanek

na všechna vyšetření, může definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

18 • Pediatr Mladý- má přístupová práva do MPI, lékař bez specializované způsobilosti, pediatr, který má v rámci pracoviště

přístup na neonatologické oddělení porodního sálu, všechna ambulantní pracoviště, lůžkové stanice standardní i JIP pro větší

děti i lůžkové stanice standardní i JIP neonatologického oddělení dětské kliniky. Má práva pro vystavování žádanek na
všechna vyšetření, ale nemůže definitivně uzavírat zdravotnickou dokumentaci.
• Sestra Dětská - má přístupová práva do MPI, přístupová práva na všechna pracoviště neonatologie,
• Neonatolog Vedoucí - lékař se specializovanou způsobilostí, pediatr, který má v rámci pracoviště přístup na neonatologické
oddělení porodního sálu, neonatologickou lůžkovou stanici standardní i neonatologickou resuscitační JIP dětské kliniky. Má

přístupová práva do MPI, má práva pro vystavování žádanek na všechna vyšetření, může definitivně uzavírat zdravotnickou
dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

19 Hlavní scénář Plánovaný Pacient

Předvedení kompletního procesu přidělení rolí pro uživatele: Uchazeč provede přidělení přístupových práv v rozsahu specifikovaném výše ve scénáři tak, že využije práva v minulosti již Při přidělování

Chirurga Zkušeného přidělená jinému chirurgovi se specializovanou způsobilostí a bude demonstrovat "zkopírování/dědění" přístupových práv, ke přístupových práv KIS

kterým pak de novo přidá přístupová práva na urgentní příjem fiktivní nemocnice (bude mít právo pracovat s dokumentací na umožňuje kopírovat role s

20 urgentním příjmu včetně přístupu do MPI, práva uzavírat dokumentaci, digitálně ji podepisovat a nahlížet na systém nastavením oprávnění
zobrazování lůžkové kapacity v souladu se specifikací v ZD). odpovídající pracovní

pozici i zdravotnickému
pracovišti současně.

4
Na chirurgickou kartotéku přichází pacient Marod Zažívací s doporučením vyšetření na chirurgické ambulanci, ale není
objednán – má jen doporučení a není akutní!

21 Pacient v minulosti v nemocnici už byl 1x hospitalizován na chirurgii, ambulantně vyšetřen na gastroenterologii – veškeré
související dokumenty byly pořízeny v předváděném KIS.
Administrativa Kartotéční v rámci centrální recepce zadá Pacient nesouhlasí s přítomností mediků a účastí na výuce - je již nastaven neveřejný alert.
pacienta do Master Patient Indexu s B2B kontrolou a s Při hospitalizaci na ORL byl do Rodinné anamnézy zaznamenán následující údaj:
kompletním přehledem všech požadovaných položek. Po „Otec + 77 let na 3. infarkt myokardu, léčil se s cukrovkou. Matka žije, narozena 1936, je po cévní mozkové příhodě. Bratr
22 kontrole údajů jej zařadí do fronty objednaných pacientů na Upacchiaeznetač žuikjeá,žjee vzšderácvh.n“y položky v MPI, které má systém připraven pro záznam údajů, tak aby je komise mohla jednu po druhé
ošetření na ambulantní pracoviště chirurgie, neoznačí shlédnout a zkontrolovat jejich existenci v souladu se zadávací dokumentací.
Maroda Zažívacího jako akutního pacienta.

Administrativa Kartotéční přidělí pacienta z fronty Pracoviště má 5 chirurgických ambulancí.
23 objednaných do fronty čekajících v chirurgické ambulanci č.

Sestra Chirurgická řadí frontu čekajících pacientů na Uchazeč kromě našeho vzorového pacienta bude mít připraveno alespoň 7 dalších testovacích pacientů, z toho 3 akutní bez Akutní pacienti jsou
24 chirurgické ambulanci č. 3. předchozího objednání. vizuálně zvýrazněni v
seznamu čekajících
Sestra Chirurgická předvede možnosti řazení čekajících řazení podle: pacientů.
pacientů pomocí názvů sloupců • příjmení,
25 • data narození, Systém nabízí převzetí
• času registrace, textu v oddílu anamnéza
Chirurg Mladý si vybere Maroda Zažívacího na vyšetření do • ne-/objednané jako součást služby
ambulance. historie pro okno se
Ve zdravotnické dokumentaci v anamnéze zobrazí text z záznamem volného textu
gastroenterologické poradny a převezme jej do své (tj. lékař nemusí otvírat
ambulantní zprávy k další editaci. celou historii ošetření
pacienta v nemocnici,
26 najít vyšetření na interně
a text anamnézy přenášet
pomocí funkce Kopírovat-
Vložit).

5
Chirurg Mladý zjistí anamnesticky alergii na jód – ekzém a Záznam alergií je

provede záznam do ambulantní dokumentace. strukturovaně připraven v

parametrické podobě, aby

27 mohl být využit k

automatizovanému

vytváření pacientského

souhrnu (emergency data

Chirurg Mladý doplní do ambulantní zprávy objektivní nález V systému jsou pomocí funkce vkládání předdefinovaných textů připraveny alespoň tři následující položky pro výběr pro toto sPeotuuž).ití Lupy s nabídkou

vyšetření a texty dodané pomocí Lupy upraví. Do „nálezu na okno volného textu, které umožní postupně jedna po druhé zapsat alespoň „stav vědomí“, „nález na hrudníku“, „nález na uživatelem vytvořených

břiše“ zapíše text v následujícím znění: „hmatná rezistence v břiše“. textových řetězců, pohyb

28 levém dolním kvadrantu“. v jejich seznamu a jejich
vložení na pozici kurzoru

v okně pro volný text

nevyžaduje více než 2

Text nálezu na břiše vložený v předchozím bodu do okna volného textu ambulantní zprávy uchazeč zvýrazní tučným písmem kliknutí myší.

29 a změnou fontu na jakýkoli jiný, než jakým jsou zapsány předchozí text o vědomí a nálezu na hrudníku. Uchazeč v tomto okně

volného textu ukáže i možnosti měnit velikost písma nejdříve u textu o stavu vědomí na velikost 18 tiskových bodů a poté na

textu nálezu na hrudníku na nejmenší dostupnou velikost textu v souladu se zadávací dokumentací.
Chirurg Mladý vystaví žádanku na CT břicha s kontrastem. Budeme sledovat přenesení v KIS dostupných informací o pacientovi do žádanky. Dále postup vyplňování povinných položek Zobrazení více

Na žádance na CT bude uveden následující text: „Pacient s dle požadavků zadavatele. Chirurg uvidí plánovací kalendář CT radiologie, ale nebude mít oprávnění přímo obsadit konkrétní plánovacích kalendářů na

30 údajem občasného krvácení vzhledu enterorhagie z termín. jednotlivé modality

konečníku.“ radiologie současně na

obrazovce.

Chirurg Mladý vystaví žádanku na rtg srdce a plic vstoje PA + Budeme sledovat přenesení v KIS dostupných informací o pacientovi do žádanky. Dále postup vyplňování povinných položek

31 L bočný. dle požadavků zadavatele. Chirurg uvidí plánovací kalendář skiagrafie, objednávání do něj je bez omezení pro lékaře

Chirurg Mladý vystaví žádanku na ultrazvuk břicha. kterékoli odbornosti a bude mít oprávnění přímo obsadit libovolný konkrétní termín.
Zobrazení plánovacích kalendářů pro CT, skiagrafii a UZ najednou, termín pro UZ musí být v jiný den než CT, nebo mu musí Grafické vyznačení oblasti

Na žádance bude uveden následující text: „Žádám o ve stehném dni předcházet. v plánovacím kalendáři,

32 předoperační UZ břicha v následujícím týdnu kvůli plánování Budeme sledovat přenesení v KIS dostupných informací o pacientovi do žádanky. Dále postup vyplňování povinných položek kam mám oprávnění
operace.“ dle požadavků zadavatele. Chirurg uvidí plánovací kalendář UZ radiologie a bude mít pro chirurgické pracoviště vyhrazené objednávat.

časy s možností přímo obsadit konkrétní termín.

Asistent Radiologický žádanky uvidí a zobrazí na svém
33 pracovišti. Bude mít na výběr ze tří CT vyšetřoven. Zařadí

žádanku do fronty objednaných na vybraném CT.
Asistent Radiologický potvrdí termín UZ břicha zvolený
34 chirurgem v objednacím kalendáři.

Radiolog Zkušený provede a zapíše nález UZ vyšetření
35 břicha, který uzavře jako definitivní a vykáže zdravotní

pojišťovně.
Radiolog Zkušený popíše snímky plic a srdce, nález uzavře
36 jako definitivní a vykáže zdravotní pojišťovně.

6
Sestra Chirurgická vystaví žádanku na laboratorní vyšetření: Protože neexistuje integrované propojení s laboratorním komplementem FN HK, uchazeč si v KIS předem připraví soubor

krevního obrazu, hodnot požadovaných laboratorních vyšetření (bude jimi simulovat dodání výsledků laboratorním informačním systémem

vyšetření moče chemicky a sediment, směrem do KIS). Archiv výsledků Maroda Zažívacího v KIS nebude prázdný – navíc bude u každého z aktuálně

biochemické vyšetření séra – urea, krea, urikémie, Na, K, Cl, požadovaných typů laboratorních vyšetření (s výjimkou krevní skupiny) obsahovat minimálně tři další hodnoty z minulosti. Ve
37 bil celkový, bil konjugovaný, ALT, AST, LDH, ALP, glu,
výsledku bude možné prostřednictvím KIS zobrazit u každého z laboratorních vyšetření specifikovaných v řádku 29 alespoň

celkový protein, albumin, CRP, čtyři různé hodnoty.

INR, poměru APTT, fibrinogenu,

vyšetření krevní skupiny.

38 Tisk štítků Provede posun po jednotlivých položkách v tabulce směrem do minulosti a poté rychlý návrat k vyšetřením s aktuálním datem. Přehled o plánovaných a
39 Tisk pouze žádanky na biochemii. recentně uskutečněných
ošetření pacienta se
Chirurg Mladý si zobrazí přehledovou tabulku o otevře na aktuálním datu,
naplánovaných a uskutečněných vyšetřeních pacienta. nikoliv na prvním
poskytnutém ošetření v
40 minulosti, které je v KIS k
dispozici. Přehled je
vybaven klávesami či
posuvníkem, které po
historii umožňuje rychlý
pohyb na ose od časově
nejstaršího po časově
nejaktuálnější záznam, je
dostupná klávesa
umožňující rychlý návrat
na dnešní datum.

Chirurg Mladý objedná pacienta na další kontrolu v Do okna volného texu ambulantní zprávy vloží libovolné texty, třeba i s použitím lupy, ale s tím, že text zprávy bude (včetně Okno pro záznam volného
chirurgické ambulanci s výsledky všech objednaných vkládání konce odstavců) dosahovat alespon 20 řádků pod sebe, aby bylo patrné chování okna pro záznam volného textu. textu má tzv. dynamickou
vyšetření. Ambulantní zprávu dokončí a uloží s diagnózou Označí myší text v rozsahu 3.-6. řádku a takto označený blok textu myší přetáhne na jeho konec v rámci okna pro záznam velikost - pokud původně
kódem „D37.4“ a text dodaný defaultně KIS pozmění na volného textu (i když tím záznam ztratí jazykově smysl). vyhrazený prostor nestačí,
„Novotvar sigmatu neznámé povahy“. velikost okna se ve
vertikálním směru začne
41 zvětšovat tak, že nakonec
je libovolně dlouhý text
celý zobrazen v okně.
Dynamická změna
velikosti se netýká šířky
okna, která je stabilní a
text se automaticky
zarovnává k levému okraji
okna.

7
42 Označí bez použití myši text v rozsahu 3.-6. řádku v předchozím bodu přesunutý na konec zápisu v okně, takto označený blok
textu klávesovou zkratkou vyjme - klávesovou zkratku při prezentaci slovně popíše, najede kurzorem na konec 2. řádku a text
Vytiskne pro pacienta neuzavřenou kopii zprávy z klávesovou zkratkou - slovně popíše - vloží zpět. Zápis v okně se tím vrátí do původního stavu. Uchazeč oznámí klávesovou
ambulantního vyšetření. zkratku, kterou průběžně uloží zaznamenané informace.

Radiolog Mladý provede popis CT vyšetření. Ve formulářích

pro procesní podporu zobrazovacích vyšetření je funkční
44 systém vícestupňové kontroly a v souladu s pokyny výše

tento lékař nemá oprávnění uzavřít popis jako definitivní.

45 Radiolog Mladý provede vyúčtování provedeného vyšetření
včetně ZULP Ultravist o objemu 20 ml.

46 Chirurg Zkušený se podívá do tabulky hotových výsledků u
pacienta stále rozpracovaného v ambulanci.

Chirurg Zkušený provede zápis do ambulantní dokumentace.

Původní diagnózu z ambulantního vyšetření změní na C18.7

Karcinom tlustého střeva v sigmoideu. Pokud to KIS umožní,

47 v ambulantní zprávě vyplní i parametrická pole pro klasifikaci

zhoubných nádorů T1N0M0. Pacientovi objednává další

návštěvu v chirurgické ambulanci.

Chirurg Zkušený zprávu vytiskne, uzavírá návštěvu pacienta Pokud KIS funkcí disponuje, uchazeč předvede tisk a uzavření návštěvy pacienta s jeho vyřazením z fronty rozpracovaných

48 a vyřazuje jej z fronty rozpracovaných. pacientů pomocí klávesové zkratky, kterou dopředu oznámí. Při jejím použití zůstává ukazatel myši umístěný v okně pro

záznam volného textu a nehýbe se.

Současně s dokončením zprávy provede za podpory KIS

49 vyúčtování ambulantního vyšetření, do účtu uvede kód

komplexního vyšetření chirurgem.

Datum práce s pacientem se posune o 10 dnů dopředu - tedy do dne naplánované ambulantní návštěvy pacienta na

50 chirurgické ambulanci.

Pacient se dostaví na recepci jako objednaný pacient na

chirurgickou ambulanci. Administrativa Kartotéční jej vybere z
51 fronty plánovaných pacientů do stejné chirurgické ambulance.

Chirurg Zkušený z ambulance provede plánování termínu

52 hospitalizace a předběžné zařazení pacienta do fronty
plánovaných pro operační řešení.

53 Ve vzorku pacientů připravených pro prezentaci díla má uchazeč zavedeno minimálně 15 pacientů s diagnózou C18.-
léčených na kterémkoli pracovišti fiktivní nemocnice. Z těchto 15 pacientů bylo 10 vyšetřeno v posledním roce na chirurgii. V
posledním roce bylo operováno 8 pacientů, 2 z nich už zemřeli.

8
Chirurg Mladý spustí formulář pro zadání dotazu a za Prezentující osoba spustí požadovaný nástroj pro zadání obecného dotazu k vytěžení informací z KIS, který je určen pro
poslední kalendářní rok vyhledává sestavu pacientů, u běžného uživatele v souladu se zadávací dokumentací, tj. nepotřebuje znát specifický jazyk pro vytěžování dat z databáze.
54 kterých byla pouze na pracovištích chirurgie zadána Názorně provede zadání specifikovaných parametrů pro vyhledávání, které charakterizují množinu hledaných případů a spustí
diagnóza C18.-, tzn. různé lokalizace karcinomu tlustého provedení zadaného dotazu tak, aby získala výpis pacientů splňujících kritéria vyhledávání.
střeva.

55 Vrácený seznam pacientů řadí dle záhlaví sloupců a
namátkou si dva z těchto pacientů vybere.

Přejde do archivované zdravotnické dokumentace v KIS u

pacientů zvolených v předchozím kroku, jako důvod

56 nahlédnutí zadá či zvolí z rolovacího seznamu (záleží na

způsobu řešení funkce uchazečem) "doplňování údajů do

registrů".

57 Jeden z těchto pacientů již zemřel - uchazeč předvede, jakým způsobem je tento fakt v KIS zaznamenán.

Chirurg Mladý opět spustí formulář pro zadání obecného Chirurg Mladý je pro potřebu prezentace vybaven kompetencí, která odpovídá spíše manažerské pozici na úrovni nejvyššího

dotazu, vyhledá bez časového omezení do minulosti všechny vedení FN HK - tedy může vidět pacienty napříč pracovišti bez ohledu na odbornost.

58 pacienty s kódem C18.- na kterémkoli pracovišti libovolné

fiktivní nemocnice a seřadí je dle data ošetření a dle

pracoviště ošetření.
Chirurg Mladý se pokusí některý z obdržených záznamů z

59 jiného pracoviště než chirurgie otevřít pro potřeby nahlédnutí

pro vědecké účely. Zobrazení plánovacích kalendářů s tím, že anesteziologická ambulance bude mít pro chirurgickou ambulanci vyčleněné dva
Chirurg Mladý vystaví žádanku do anesteziologické

60 ambulance na anesteziologické konzilium. Žádanku vystaví bloky termínů v týdnu, kam může objednávat chirurg.
na konkrétní datum a čas ve vyčleněném objednacím

kalendáři.
Anesteziolog Mladý najde pro pacienta náhradní termín ve Pacientovi není možné v objednaném termínu provést anesteziologické konzilium z důvodu chybění volné kapacity

61 stejný čas, ale následující den a provede jeho přeobjednání. anesteziologů.

Anesteziolog Mladý vyhledá pacienta mezi objednanými Uchazeč má pro
pacienty v anesteziologické ambulanci, vybere si jej bez ambulantní vyšetření u
62 asistence sestry a provádí anesteziologické konzilium. konktrétní lékařské
Zobrazí kompletní průchod všemi předchozími ošetřeními odbornosti připraveny
pacienta v nemocnici včetně ambulantních nálezů i šablony nad rámec
laboratorních výsledků - vše anesteziolog zobrazí. obecného požadavku na
Provede velmi stručný zápis anesteziologického konzilia s strukturování ambulantní
použitím automaticky přenesených položek a přenosu dokumentace.
informací z předchozího vyšetření v chirurgické ambulanci.

Pacient má anamnézu „velmi obtížné intubace“, proto
64 Anesteziolog Mladý provede aktivaci veřejného alertu pro

ostatní kolegy.

Anesteziolog Mladý provede vyúčtování anesteziologického
65 konzilia vůči zdravotní pojišťovně.

9
Sestra Chirurgická vystaví žádanky na laboratorní vyšetření: Uchazeč připraví pro účely prezentace takové konkrétní hodnoty výsledků všech požadovaných vyšetření dostupné v KIS,
KO+diff, INR, APTT, fibrinogen, moč chemicky + sediment, které budou pro daný typ laboratorního vyšetření uvnitř intervalu rozpětí fyziologických hodnot.
66 biochemický standard, který zahrnuje glu, TP, Alb, Na, K, Cl,
Mg, urea, krea, urik, bil, bil konj., ALT, AST, ALP, GMT, LDH,
CRP.
Pacient v naplánovaný den nastupuje hospitalizaci. Sestra
Chirurgická na příjmové chirurgické ambulanci provede
67 kontrolu požadovaného souboru předchozích objednaných
vyšetření a také toho, zda byla provedena. Když je vše
hotové, provede administrativní založení chorobopisu.

Uchazeč pro účely ukázky připraví následující situaci:

Chirurgická klinika má standardní oddělení s následující strukturou a obsazeností:

Pokoj .č 1 a 2 je jednolůžkový, na jednom z pokojů bude hospitalizovaný pacient, který bude mít izolační režim, druhý pokoj

bude obsazený pacientem bez zvláštního atributu; pokoje jsou v systému považovány jako bez rozlišení pohlaví

hospitalizovaných.

68 Pokoje č. 3-6 jsou dvojlůžkové. Na pokoji č. 5 je přijata žena v izolačním režimu, druhé lůžko na pokoji je neobsazené. Pokoj č.

3 je plně obsazen. Pokoj č. 6 je volný a je na něm umístěna 1 přistýlka. Na pokoji č. 4, lůžku č. 1 je již hospitalizován mužský

pacient Pepa Tuberkulózní, který byl na chirurgii přeložen den před přijetím Maroda Zažívacího z plicního oddělení, kde byl

hospitalizován celkem 4 dny na trojlůžkovém pokoji s dalšími 2 pacienty – Karlem Dýchavičným a Frantou Cyanotickým.

Pokoje č. 7 a 8 jsou trojlůžkové, na pokoji č. 7 jsou hospitalizováni dva muži.

Chirurgická klinika má JIP o 6 lůžkách, 5 z nich je obsazených, 2 pacienti mají zavedený izolační režim; lůžka nerozlišují

pohlaví hospitalizovaných. Dospávací pokoj má 4 lůžka; lůžka nerozlišují pohlaví hospitalizovaných.

69 Sestra Chirurgická přijímá pacienta na pokoj č. 4, lůžko č. 2.

70 Sestra Chirurgická provede ošetřovatelský příjem. Pacienta Pacient nemá žádné hendikepy pro vyplňování ošetřovatelských škál s výjimkou vyprazdňování - střídá se zácpa a průjem a v
zváží a změří, změří i TK a TF, DF. případě průjmu někdy dochází k inkontinenci stolice.

71 Po dokončení zápis uzavře a vytiskne.

Chirurg Mladý provede kompletní lékařský příjem dle popisu v Do všech oken pro volný text vloží vždy nějaké uchazečem připravené texty z číselníku textů (mohou být i významově Záznam farmakologické

zadávací dokumentaci. nesmyslné ve vztahu ke konkrétnímu případu); pouze v oddíle osobní anamnéza budou alespoň 3 různé texty a každý z nich anamnézy je umožněn

Farmakologická anamnéza, kde chirurg zadá následující léky: bude alespoň na 3 řádky. formou parametrických

• Atoris 20 mg p. os. 1-0-0, Uchazeč předvede funkci historie v oknech pro záznam volného textu – jako optimální místo pro ukázku využije rodinnou oken, nikoliv výhradně

72 • Furon 40 mg p. os 1-1-0, anamnézu. formou volného textu.
• Ibuprofen AL 400 mg p. os 1-0-1 při bolesti,

• Volteren gel lokálně dle potřeby na P koleno

• Lantus Solostar inzulín s.c. 6-0-16 j.s.c.

• Oční kapky – název si nepamatuje – do OPL 1-0-1

73 Po dokončení Anamnézy zápis uzavře a vytiskne. Před uzavřením a tiskem anamnézy se uchazeč myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS

Chirurg Mladý provede objektivní vyšetření s podporou KIS, umístěném podél horního okraje obrazovky a postupně zobrazí všechny kontextové nápovědy.
Vkládání textů pro jednotlivé tělesné krajiny (alespoň 2 z nich) z šablon předdefinovaných textů.

74 alespoň 1 z nich jakkoli upraví (slovo umaže nebo slovo
vloží).

75 Po dokončení jej uzavře a vytiskne.

10
Chirurg Mladý vyplní příjmovou Epikrízu dle požadavků
zadavatele. Do Plánu další péče bude zapsáno:
76 „Naplánována standardní příprava před operací, premedikace
dle ordinace anesteziologa.“ Pacient bude mít standardní
hygienický režim, žádnou umělou plicní ventilaci.

Chirurg Mladý v návaznosti vytvoří lékařský dekurz. Zadavatel pro účely prezentace díla vyžaduje dekurz, kde ordinace léčivých přípravků nebude odděleně od ostatních KIS při zadávání začátku

• Bude ordinovat dietu 0s – čajovou záznamů, tj. nepoužije samostatnou „lékovou kartu“. obchodního názvu

• Režim pohybu po oddělení „C“ léčivého přípravku

• Hygienický režim „S“ – standardní nabídne vlastní

• Do záznamu vizity napíše: „Přijat a vyšetřen k plánované uživatelský seznam

operaci.“ léčivých přípravků

• Přistoupí k ordinaci léků. vyhovující zadanému

• Oční kapky neznámého názvu smaže a nahradí ordinací – kritériu pouze s názvem,
77 napíše přesně řetězec „dorzolamidum“, pokud KIS začne sílou a formou. Pokud se

nabízet léčivé přípravky, zvolí Trusopt 1-0-1 OPL. Pokud KIS nabízí kompletní řetězec

nebude reagovat na název generika, začne psát obchodní názvu léčivého přípravku

název „Trusopt“. Jedná se o N-položku! (kromě názvu,síly a formy

• Inzulín Lantus vysadí a nahradí ordinací Humulin R 4-4-4 je ve zkratce i velikost

j.s.c. balení a popř. další

• Začne psát přesně řetězec „Trit“. Nabídne-li se seznam informace) z oficiálního

preparátů s obsahem látky, zvolí Tritace 2,5 mg 1-0-0. číselníku SÚKL, uchazeč

78 Hotový dekurz vytiskne. bod nezískává.

Operatér Centrální předvádí správu společného traktu 6 Operatér Centrální spravuje trakt 6 operačních sálů, na kterých nejsou před prezentací díla provedena žádná další nastavení.

operačních sálů dle instrukce. Uchazeč předvede administraci operačních sálů, kterou má Operatér Centrální k dispozici:

• Pro potřeby chirurgické kliniky vyčlení sály 1-3 na celou pracovní dobu 7:00-15:00. Na sále č. 4 vyčlení kapacitu pro chirurgii

79 od 7:00 do 11:00 každý den.

• Ve středu Operatér Centrální na sále č. 2 nařídí sanitární den a uzavře jej pro plánovaný provoz.

• Operatér Centrální nastaví délku technologické pauzy mezi výkony na 20 min.

Operatér Centrální pomocí nástroje obecného dotazu zobrazí Uchazeč má v databázi KIS připravenou situaci, kdy pro každý sál je vyčleněný alespoň 1 sanitární den v intervalu zhruba 2
počet sanitárních dnů na jednotlivých operačních sálech v měsíců.
80 traktu operačních sálů za poslední kalendářní rok. Selektivně
ze seznamu pomocí funkce řazení vybere ty dny, kdy byl
sanitární den na sále č. 1.

11
Chirurg Zkušený přijatého pacienta naplánuje k výkonu na KIS osobě bez
příslušného oprávnění
středu, zapíše veškeré údaje – operační tým lékařů, nedovolí při plánování
operačního programu v
požadavek na speciální instrumentárium, které za chirurgické předstihu pro standardní
pracovní dobu se
pracoviště má vyplňovat do podrobného plánu operací na sál zohledněním nastavené
délky technologických
č. 3, výkon laparoskopicky asistovaný, délka plánována na přestávek naplánovat
operační výkon tak, aby
180 min. Nejdříve zkusí operaci naplánovat na sál č. 1. byla standardní pracovní
doba překročena.
81 Operační program pro sál č. 1 je již téměř zaplněn jinými
operacemi, do konce pracovní doby zbývá pouze 120 min.

čistého času a KIS jej minimálně na tuto časovou kolizi

upozorní. Chirurg Zkušený si proto ve finále vybere sál č. 3

zpřístupněný chirurgické klinice. Tím se Marod Zažívací

dostane do operačního programu.

82 Chirurg zkušený se právě dozvěděl o nedostatku sester –
trojlůžkový pokoj č. 8 uzavírá z personálních důvodů.

Operatér Centrální si zobrazí plánovací kalendář sálů včetně Očekáváme ukázku všech možností KIS, jak se k takové situaci systém může zachovat - od upozornění (jeho forma?),

detailů jednotlivých, už naplánovaných výkonů. U operace nabídku přeuspořádání výkonů na sálech dle plánované délky až po zablokování takové změny - a nabídku možností, jak se

Maroda Zažívacího provede přeplánování výkonu na sál č. 1 může chovat osoba s oprávněním primáře operačních sálů.

83 jako druhý výkon, dobu trvání výkonu zachová. Tím nastane

situace, kdy dosud plánovaný program začne přesahovat

řádnou pracovní dobu a je na to systémem upozorněn.

Anesteziolog Zkušený si zobrazí plánování anesteziologické Uchazeč má pro
péče. Uvidí Maroda Zažívacího včetně všech dostupných plánování
údajů dle požadavků zadavatele. Provede aktuální anesteziologického
předanestetické vyšetření, naplánování anesteziologické servisu informační
péče a ordinaci premedikace. S ohledem na typ a rozsah podporu, která rychle a s
84 výkonu rozhodne o potřebě úplného zajištění – centrální žilní dobrou dostupností
katétr, arteriální katétr, močový katétr, celková anestézie. informuje lékaře o úkolech
Takový rozsah si vyžádá delší čas pro práci anesteziologa, ve vztahu k přípravě
než bývá vyhrazeno na běžnou celkovou anestézii (10 min).V pacientů na operaci.
operačním plánu zaznamená, že potřebuje na svou práci
interval 20 min. před vlastní operací.

Operatér Centrální prohlíží náhled na všechny operační sály Je den před dnem operace (D-1). Uchazeč má na tento den připravené pacienty a obsazené funkční operační sály

pro dnešní den (D-1), sleduje výkony již provedené, výkony jednotlivými operacemi tak, že původní plán u sálů 1, 2, 3, 5 a 6 kompletně vyčerpal standardní pracovní dobu od 7:00 do

již probíhající a případný posun dosud neprovedených 15:00 hod. Volná kapacita zůstává jen na sále č. 4 od 11:30 hod.

plánovaných operací oproti původnímu plánu (zejména ve
85 vztahu ke konci řádné pracovní doby). V plánu operací uvidí

další časové posunutí výkonů na sále č. 1, a proto se

rozhodne poslední plánovaný výkon ze sálu č. 1 přesunout

na dosud neobsazený sál č. 4 do dopoledních hodin.

12
Chirurg Zkušený do 11 hod. odevzdává finální plán operací
pro Operatéra Centrálního k definitivnímu rozplánování
výkonů, protože ví o blokování editace návrhů operačních
programů účinnému od 11:00 hod. U Maroda Zažívacího je
86 operatér Chirurg Mladý, asistentem je Chirurg Zkušený. Bude
provedena laparoskopicky asistovaná resekce levé části
tračníku včetně sigmatu bez kolostomie. Pacient bude na
zádech. Chirurg k výkonu požaduje připravit 2
deleukotizované erymasy.

Náměstek Lékařský v rámci stížnostní agendy na dlouhé

čekací lhůty na operaci si prohlíží seznam hospitalizovaných

na Chirurgické klinice a namátkou si vybere Maroda

87 Zažívacího, aby se podíval na oprávněnost relativně akutní

indikace k operaci. Rozhodne se zobrazit poslední

ambulantní vyšetření z chirurgické ambulance a kompletní

příjmovou dokumentaci z hospitalizace.

Operatér Centrální ve 12 hod. uzavře plán operací pro Uchazeč připraví alespoň 3 další naplánované operace na různé sály a mohou být i pro různé obory, kde ukáže škálu detailů,

požadavky ze stran operačních oborů. U Maroda Zažívacího které je možné k operacím v KIS zadat.

stanoví, že instrumentuje Instrumentářka Chirurgická, obíhací
88 sestrou bude Sestra Chirurgická.

Operatér centrální si prohlédne kompletní plán operací na

následující den, otevře 1 další plánovanou operaci.

Hotový plán operačních výkonů dostane k dispozici
Anesteziolog Zkušený, aby mohl zaplánovat anesteziologický
servis pro oddělení centrálních operačních sálů.
U Maroda Zažívacího si všimne údaje o plném zajištění
89 pacienta 3 vstupy a upozornění na alergii a obtížnou intubaci.
Anestézii bude podávat Anesteziolog Zkušený se Sestrou
Anesteziologickou.

Operatér Centrální prohlíží náhled na všechny operační sály
pro dnešní den (D-1) a pro následující den (D). Zobrazí finální
90 operační program na den D, včetně operace Maroda
Zažívacího.

91 Operační plán na den D obsahující i operaci Maroda
Zažívacího vytiskne.

92 Je den operace (D).

Sestra Chirurgická předá Sestře Anesteziologické pacienta – způsob zadání časů dějů
na operačním sálu je
je zaznamenán čas předání pacienta na operační sál v rámci poloautomatizován - stisk
tlačítka nebo snímání
Oddělení operačních sálů. specifického čárového
kódu s automatickým
93 přiřazením reálného času.

13
Anesteziolog Zkušený zahájí svou práci – zaznamená se čas

94 začátku – a za 15 minut je pacient kompletně připraven k
zahájení operace.

Přichází oba Chirurgové a zahajují svou práci – záznam času
95 zahájení práce chirurgického týmu.

Zaznamená se čas řezu.

Uchazeč přiveze 5 různých čárových kódů včetně alfanumerického záznamu informace, který je obsažen v čárovém kódu, od

zdravotnických prostředků. Dvojice „čárový kód – odpovídající obsah informace“ uchazeč očísluje od 1 do 5. Tyto čárové kódy

od zdravotnických prostředků budou mít provazbu na číselník ZUM uvnitř předváděného KIS, aby snímanou informaci bylo

96 možné užít i při vyúčtování péče na sále.

V průběhu prezentace díla komise zadavatele vybere namátkou 3 z těchto připravených čárových kódů, které uchazeč

nasnímá čtečkou čárových kódů do zdravotnické dokumentace a vyúčtování péče na operačním sále.

Operace je úspěšně skončena, zaznamená se čas ukončení
97 operace.

Anesteziolog Zkušený extuboval pacienta a připravil jej na
98 předání na pooperační pokoj. Je zaznamenán čas ukončení

práce anesteziologa.

99 Anesteziolog Zkušený stanovil sledování po operaci v délce
120 min.

Po převezení pacienta na pooperační pokoj, tj. ambulantní V tento okamžik bude na PC1 přihlášen Anesteziolog Mladý na pooperačním pokoji, současně s tím bude na PC2 Chirurg
Mladý psát operační protokol.
100 pracoviště stacionářového typu, je zaznamenán čas předání
pacienta z operačního sálu. Současně s tímto okamžikem Operační protokol a ambulantní pracoviště typu stacionáře - prezentace na obou PC ve stejnou dobu.

začíná práce Chirurga Mladého na operačním protokolu.

101

14
Ve stejnou dobu bude: Uchazeč poskytuje v
PC1 - Anesteziolog Mladý přihlášený na PC1 a vytvoří rámci funkcionality
dokument pro pooperační sledování pacienta v délce 120 předdefinovaných textů i
min. Mezi sledované funkce patří alespoň TF, TK, SpO2, ordinace uživatelem
vědomí, DF, diuréza, zvracení (ano/ne), krvácení (ano/ne), definovaných infuzních
glu, odpad z drénů. roztoků, které ordinující
Do dokumentu zaznamená čas převzetí Maroda Zažívacího z lékař vybírá z nabídky a
operačního sálu. Provede i ordinaci léčivých přípravků (může vkládá do sekce ordinací
použít připravené ordinace v předdefinovaných textech): ve zdravotnické
Novalgin 1 g do F1/1 100 ml i.v. na 30 min. dokumentaci s možností
podmíněnou ordinaci Dipidolor 15 mg 1 amp. i.v. bolusem na plné editace vloženého
5 min. v případě bolesti VAS rovno nebo silnější než 2/4 textu.
102 (=čtyřstupňová škála).
Jako podmínky pro možné propuštění sestrou z pooperačního I u dokumentace z
pokoje jsou stanoveny: operačního sálu je
• Analgézie zajištěna a je dostatečná: zavedený systém
• Kašle: dvojstupňové kontroly -
• Polyká: definitivní uzavření
• Není nauzea: dokumentace může
• Krvácení, odhad objemu < 100 ml provést jen lékař se
Anesteziolog Mladý - Čtečkou čárových kódů jsou načteny specializovanou
čárové kódy dvou připravených zdravotnických prostředků způsobilostí.
nepoužitých na operačních sálech, které se vnesou do
dokumentu jako přístroje použité k monitorování pacienta.
Připravený dokument uchazeč vytiskne.
PC2 - Chirurgovi Mladému při zahájení editace OP se
nabídne předvyplněný formulář operačního protokolu s
přenesenými parametrickými údaji, které byly nashromážděny
prostřednictvím KIS v předešlém čase a mají vztah k operaci.
103 Automaticky přenesené položky lze editovat - uchazeč
předvede při úpravě času zahájení práce chirurgů, který
upraví o 2 minuty dopředu. Dokončený operační protokol
Chirurg Mladý vytiskne.

Po dokončení operačního protokolu Chirurg Mladý provede

104 kompletní vykázání operačního výkonu včetně anestézie
(zahrnuje i výkaznictví ZUM, ZULP).

Pokud je tabulka pro sledování základních životních funkcí a I nadále probíhá souběžná práce na PC1 i PC2. Bod je nepovinná položka, kterou uchazeč v případě zájmu může předvést
odpadu z drénů připravena pro vyplňování i v elektronické fyzicky; ke KIS bude při vyplňování hodnot životních funkcí přihlášená Sestra Anesteziologická na dospávacím pokoji.
formě (N-položka), uchazeč může předvést práci s ní a poté
105 následný tisk – při zápisech do tabulky bude přihlášena
Sestra Anesteziologická; položky jsou stejné jako v
předchozím odstavci.

15
Po uplynutí sledování po operaci na pooperačním pokoji se
pacient vrací zpět na standardní oddělení. Chirurg Mladý
vytvoří dekurz na standardním oddělení. K lékům, které byly
podávány před operací, nyní přibudou léky na bolest:
106 Novalgin 500 mg tbl. p. os 1-1-1
a přibude i kontinuální infuze:
Ringerfundin 1000 ml i.v. rychlostí 100 ml/hod

Chirurg Mladý 2. den po operaci propouští Maroda V době psaní zprávy jsou k dispozici všechny výsledky vyšetření, o kterých se ve scénáři jednalo. Uchazeč tedy předvede Při vytvoření doporučení
Zažívacího domů a vytváří kompletně všechnu listinnou
agendu k tomu nutnou podle požadavků zadavatele: způsob výběru výsledků vyšetření z laboratorního komplementu i ostatních typů vyšetření a konzilií, předvede způsob jejich závěrečné zprávy se
• Statistické hlášení o hospitalizaci včetně všech kódů
požadovaných ÚZIS. vložení do závěrečné zprávy, její editaci včetně plného rejstříku grafických úprav textu pomocí textového editoru KIS v lékaři nabídnou údaje o
• Závěrečnou propouštěcí zprávu se všemi náležitostmi dle
107 požadavků zadavatele. souladu se zadávací dokumentací. Uchazeč do sekce Doporučení vloží 2 různé položky výběrem z dostupného uživatelského farmakologické anamnéze
V průběhu editace závěrečné zprávy si Chirurg Mladý text
několikrát průběžně uloží. číselníku textů. získané při přijetí

současně s naposledy

ordinovanými léky na

lůžkové stanici; záznamy

jsou editovatelné bez

omezení.

108 Po skončení výroby všech dokumentů Chirurg Mladý
vytiskne hlášení hospitalizace.

Chirurg Zkušený zkontroluje dokumentaci vytvořenou Při vytváření závěrečné
zprávy jsou do zprávy
Chirurgem Mladým. Závěrečnou zprávu uzavře jako přeneseny všechny
relevantní parametrické
definitivní a vytiskne. Poté se odhlásí od pracovní stanice. údaje, které se vážou k
hospitalizaci automaticky
109 s možností neomezené
editace.
Hygienička Nemocniční za týden po propuštění Maroda
Zažívacího mapuje pacienta – jeho pohyb po nemocnici v
průběhu hospitalizace. V návaznosti na to zjistí společný
pobyt s Pepou Tuberkulózním. U Pepy Tuberkulózního bude
stopovat všechna místa a spolupacienty, se kterými byl Pepa
110 Tuberkulózní hospitalizován, kde a jak dlouho; výstupy ze
šetření vytiskne.

Pepa Tuberkulózní je stále hospitalizován na chirurgii –
111 Hygienička Nemocniční mu nastaví alert infekčního

onemocnění.

16
Chirurg Zkušený se přihlásí do KIS na své pracoviště – bude Hygienický alert se

upozorněn na protiepidemický alert. automaticky zobrazí,

jakmile přihlášený

zdravotník zvolí pacienta

s nastaveným

upozorněním na závažnou

112 infekci. Po uzavření

alertového okna

uživatelem zůstává na

obrazovce grafické

upozornění, že po

hygienicko-

protiepidemické stránce je

V samotném závěru scénáře uchazeč zobrazí log událostí u Maroda Zažívacího a budeme kontrolovat záznamy vstupů do pLoacgiejentppřerohblelédmnýo,vý.

dokumentace s přesnou lokalizací v čase se zvláštním důrazem na fiktivní pracovníky, kteří nejsou kmenoví zaměstnanci umožňuje vyhledávání a

Chirurgické kliniky a ARO (tzn. zejména Náměstka Lékařského, Dokumentaristku, Administrativu Kartotéční). Budeme hledat i třídění podle záhlaví

záznam o databázových dotazech provedených Chirurgem Mladým včetně záznamů o činnostech, které se zpřístupněnou sloupců a registruje

113 dokumentací z jiného oddělení včetně zápisu důvodu nahlížení do dokumentace provedl. všechny operace se

zdravotními záznamy - tj.

alespoň nahlížení, tisk,

důvod k nahlížení, export

zdravotnické

dokumentace.

114 Záznamy z logu o databázových dotazech provedených Chirurgem Mladým včetně záznamů o činnostech, které se
zpřístupněnou dokumentací z jiného oddělení včetně zápisu důvodu nahlížení do dokumentace provedl, uchazeč vytiskne.

115 Klinický scénář - Dvojčata - porodnicko gynekologická a neonatologická klinika

Uchazeč připraví do souboru pacientů pacientku Rodičku Rizikovou, aktuálně jí je 35 let. Jedná se o ženu, která má v

anamnéze 1x spontánní potrat a 2 předchozí porody. První porod byl fyziologický záhlavím, narodil se chlapec. Druhý porod

před 2 lety od prezentace díla byl císařským řezem pro patologii plodu, narodilo se děvče. Pacientka mezi 18.-20. rokem

života užívala hormonální antikoncepci. Je vdaná, manželovi je 37 let a v osobní a rodinné anamnéze není žádná známá

geneticky přenášená choroba. Manžel je zdravý. Rodička Riziková po spontánním potratu trpěla významnou úzkostí a byla

116 vyšetřována na psychiatrické klinice fiktivní nemocnice, kam docházela 1 rok na celkem 4 kontroly. Rodička Riziková je

diabetička na inzulínu, užívala Humulin R 16-12-12-0 j.s.c., Lantus Solostar 0-0-0-8 j. s.c. Neužívá pravidelně jiné léky. Nemá

žádnou známou alergii.

Rodička Riziková chodila do rizikové poradny na gynekologickou kliniku zadavatele už před 2. porodem – její ambulantní i

porodnická dokumentace je tedy v KIS dostupná.

Oddělení fyziologických novorozenců má 3 dvoulůžkové pokoje ve fyzické struktuře lůžkového fondu.

Neonatologická JIP má 4 inkubátorová lůžka pro novorozence.

Administrátor KIS provede na žádost pacientky zaslepení Rodička Riziková po spontánním potratu trpěla významnou úzkostí a byla vyšetřována na psychiatrické klinice fiktivní
záznamů o 4 ambulantních ošetřeních na psychiatrii vůči nemocnice, kam docházela 1 rok na celkem 4 kontroly. Protože ví, že další péče o těhotenství bude probíhat ve fiktivní
117 ostatním pracovištím fiktivní nemocnice, včetně osob s nemocnici, projevila přání, aby informace o psychiatrické léčbě nebyla viditelná vůči jiným odbornostem a k její dokumentaci z
minimálně omezeným přístupem, jako jsou Náměstci. psychiatrie měli přístup výhradně zaměstnanci psychiatrické kliniky.

17
Dětská klinika má pro matky k dispozici 4 dvoulůžkové pokoje pro hospitalizaci doprovodů.

V prezentovaném scénáři Rodička Riziková absolvovala primotrimestrální screening u svého registrujícího gynekologa. V té

118 době nebyly zaznamenány žádné patologické jevy. Ve 30. týdnu těhotenství ji registrující gynekolog odesílá do rizikové

poradny gynekologické kliniky jen pro jistotu, těhotenství stále probíhá jako fyziologické.

Gynekolog Zkušený ji přebírá do péče rizikové poradny. Zadá Uchazeč se myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS umístěném podél horního okraje KIS nabídne automaticky
datum primotrimestrinálního screeningu do KIS pro stanovení obrazovky a postupně zobrazí všechny kontextové nápovědy. sérii termínů dalších
intervalů dalších ambulantních kontrol rodičky a s podporou plánovaných kontrol až do
KIS objedná alespoň následnou kontrolu. Rodička Riziková očekávatelného termínu
119 má bichoriální – biamniální dvojčata, na kterých není zjevná porodu.
žádná patologie. Provede zápis všech dostupných informací
včetně využívání funkce historie pro okna volného textu. Ambulantní zpráva o
Zkontroluje předchozí historii všech vyšetření v nemocnici. sledování těhotné je
připravena tak, aby
Zkontroluje automaticky přenesené parametrické údaje, které relevantní data z ní mohla
zaktualizuje. Humulin R má nyní v dávkování 14-14-14-0 j. být prostřednictvím KIS
120 s.c. a Lantus Solostar v dávce 0-0-0-10 j.s.c. Ambulantní automaticky převedena do
vyšetření uzavře a provede vykázání pojišťovně s maximální porodopisu (zprávy o
mírou automatizace výkaznictví. rodičce) a do zprávy o
novorozenci/cích v
121 V 38+3 (je to všední den) se začnou objevovat porodní bolesti v 10 hod. dopoledne. Postupně začnou být pravidelné s případě vícečetných
těhotenství.
122 odstupem mezi kontrakcemi 10 min. Protože si je Rodička vědoma rizik u porodu dvojčat a nechutná jí jíst, z obav z možné
Asistentka Ambulantní provede první vyšetření rodičky,
hypoglykémie přijíždí na příjem rodiček gynekologické kliniky ve 13 hod. odpoledne.
123 zapíše všechny nezbytné a dostupné informace do příjmové Uchazeč provede posun provozního data systému směrem dopředu.
dokumentace rodičky, zavolá lékaře Gynekologa Mladého.

Gynekolog Mladý provede veškeré lékařské úkony nezbytné Uchazeč se myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS umístěném podél horního okraje
u příjmu rodičky včetně provedení vyšetření glykémie. V obrazovky a postupně zobrazí všechny kontextové nápovědy.
průběhu příjmu Rodičce Rizikové odtéká plodová voda –
porod začal a Gynekolog Mladý zakládá porodopis. Zobrazí
si prostřednictvím KIS všechny jemu přístupné zdravotní
124 záznamy pacientky.

Asistentka Ambulantní provádí zápisy tak, jak průběžně Uchazeč předvede styl průběžného dokumentování průběhu 1. doby porodní.
125 zjišťuje stav rodičky a postup porodu.

18
Porod probíhá pomalu, kontrakce se jen pomalu objevují v Uchazeč předvede řešení předání dokumentace probíhajícího porodu mezi střídající se týmy na porodnici včetně tisku

kratších intervalech, kolem 19. hodiny v průběhu střídání dokumentace.

porodních asistentek jsou kontrakce zatím až po 5 minutách a

není žádná známka brzkého skončení porodu – proběhne
126 střídání směn porodních asistentek. Místo Asistentky

Ambulantní přichází Asistentka Zkušená. Ve 20 hod. se

střídají i lékaři, přichází do služby Gynekolog Nejmladší a

Gynekolog Vedoucí.

Až následující den v 02:00 hod ráno začne porod 1. dítěte. Gynekolog Nejmladší zůstává přihlášen na PC1 až do porodu 2. dítěte!!!

Porod je zcela nekomplikovaný, narodí se děvče. Gynekolog
127 Nejmladší založí dokumentaci pro Dorotku Rizikovou a získá

pro ni náhradní identifikátor.

Pediatr Zkušený a začne psát první informace do Záznamu o Pediatr Zkušený se přihlásí na PC2. Na PC2 se budou až do další instrukce střídat všichni ostatní zdravotníci scénáře.
128 novorozenci pro Dorotku Rizikovou.

Porod pokračuje dál, ale nyní se začne komplikovat. Druhé Zde se může Gynekolog Nejmladší odhlásit od PC1.

129 děvče se narodí s poruchou životních funkcí a je neprodleně

nutné zahájit resuscitaci.

130 Asistentka Zkušená zakládá v KIS zprávu o novorozenci pro
Annu Rizikovou.

Neonatologický tým resuscituje a resuscitace končí úspěšně,

je rozhodnuto o přijetí Anny Rizikové na novorozeneckou JIP,
131 Pediatr Zkušený zaznamená do KIS popis resuscitace,

včetně ordinace léčiv.

Současně se zprávou o novorozenci je Anně Rizikové
132 založen i standardní chorobopis hospitalizovaného dítěte.

Pediatr Zkušený vyplní anamnézu při přijetí na Pediatr může informace z
novorozeneckou JIP pomocí přístupu do zdravotnických anamnézy rodičky
záznamů Rodičky Rizikové a předá Annu Rizikovou do péče přebírat do dokumentace
133 Neonatologovi Vedoucímu. dítěte pomocí služby
historie, tj. nemusí užívat
Dorotka Riziková i Rodička Riziková mohou být propuštěny 5. Na PC1 pracuje Gynekolog Nejmladší. funkci kopírovat-vložit.
den po porodu z hospitalizace těhotné a novorozence. Po
134 skončení všech dějů je vyroben definitivní porodopis, je
archivován a vytištěn.

135 Je vytvořena zpráva o novorozenci pro Dorotku Rizikovou, je Na PC2 pracuje Pediatr Zkušený.
archivována a vytištěna.

Pediatr Zkušený předvede odložený přenos informací mezi

porodopisem a zprávou o novorozenci, včetně změny

136 náhradního identifikátoru novorozence na číslo pojištěnce
přidělenézdravotní pojišťovnou. Následuje vyúčtování

poskytnutých zdravotních služeb a archivace dokumentace

novorozenecké dokumentace.

19
Pediatr zkušený si prohlédne zpětně dokumentaci obou dětí, I v případě, kdy bude
u kterých měnil identifikátor – konkrétně ji bude prohledávat pediatr prohlížet
podle náhradního identifikátoru i podle skutečného čísla novorozeneckou
pojištěnce či rodného čísla. dokumentaci vyhledanou
podle skutečného
137 rodného čísla,
archivovaná dokumentace
bude existovat pod
původním náhradním
rodným číslem.

Pediatr Zkušený bude prostřednictvím KIS vytvářet listinný .

138 dokument pro vrozenou vývojovou vadu vůči ÚZIS, který Klinický scénář - Komplikované CMP úmrtí
vytiskne. Doktor Akutní bude v tomto scénáři kontinuálně přihlášen na PC1 a nebude se odhlašovat, dokud neuzavře
zdravotnickou dokumentaci ukázkové pacientky.
139 Všichni ostatní zdravotníci v tomto scénáři pracují na PC2.

Uchazeč připraví seznam alespoň 15 různých rozpracovaných pacientů se známými jmény a rodnými čísly, kteří budou mít
následující rozdělení triage:
• 1 bude mít naléhavost 2
• 6 bude mít naléhavost 3
• 6 bude mít naléhavost 4
• 2 budou mít naléhavost 5.

140 V databázi fiktivních pacientů v KIS je pro účely ukázky připravena i pacientka Marie Ochablá, rozená Ducháčková, která byla

v nemocnici vyšetřována ještě pod svým rodným příjmením Ducháčková před 10 lety v kardiologické ambulanci (3 návštěvy)

pro arteriální hypertenzi a má známou alergii na Amoksiklav – kožní ekzém.

Na urgentní příjem nemocnice je avizovaný příjezd posádky ZZS s pacientkou neznámé totožnosti s odhadovaným stářím
mezi 60-65 lety. V anamnéze je náhle vzniklá porucha řeči, zmatenost a zvracení ve vestibulu obchodního domu, kabelka s
doklady byla v této situaci ukradena a totožnost není známá. Při příjezdu ZZS klinický stav vypadá jako možná cévní mozková
příhoda a jako taková je pacientka ohlášena na urgentní příjem.
Doktor Akutní aktivizuje Radiologa Zkušeného a Neurologa Mladého, aby byli připraveni na možný akutní zásah na urgentním
příjmu (odehrává se telefonicky, KIS není zapojený do procesu).

ZZS přijíždí s pacientkou, která kromě expresivní afázie postupně začíná trpět i levostrannou hemiparézou, více vyjádřenou
na dolní končetině. Má zavedený periferní žilní katétr G20 do pravé kubitální žíly.
Sestra Akutní zakládá ambulantní dokumentaci na urgentním
příjmu pro Pacientku Neznámou s náhradním rodným číslem,
141 které získá prostřednictvím funkce KIS, přiděluje jí
Manchester triage naléhavost 2. Do popisu symptomu dodá
text "hemiparéza + porucha vědomí".

20
Doktor Akutní se dívá na seznam všech pacientů na Po zastavení kurzoru myši
urgentním příjmu, který má stále otevřený na svém počítači. na přidělené hodnotě
142 Myší kontroluje hodnoty přidělené Manchester triage a Manchester triage se
sloupec se specifikací symptomu. zobrazí okno s detailním
popisem symptomů.
Doktor Akutní nachází Pacientku Neznámou v seznamu
143 ošetřovaných, vybere si ji. KIS umožňuje přípravu
sestav žádanek
Doktor Akutní vystaví žádanku (STATIM) na neurologické vybraných laboratorních
konzilium a pověřuje Sestru Akutní, aby co nejrychleji vyšetření, které umí
připravila žádanky STATIM a odebrala materiál v rámci vyvolat uživatelsky
standardu pro laboratorní vyšetření v rámci akutního iktu, definovanou ikonou, popř.
který v sobě zahrnuje: i klávesovou zkratkou.
144 • KO Systém nabízí menu či
• INR, APTT jinak organizovaný výběr
• glu, mineralogram, vyšetření funkce ledvin, jaterní testy, konkrétních typů
CRP, zobrazovacích vyšetření
• krevní plyny tak, aby lékař výběrem
položky zadal údaje o
Doktor Akutní pro Pacientku Neznámou okamžitě vyrábí typu zobrazovacího
vyšetření, režim
dokumentaci ambulantního pracoviště typu stacionáře - rutina/statim, požadavek
na případné použití
145 dokument pro sledování životních funkcí a ordinace léčby kontrastní látky.
(obdobu dekurzu lůžkového oddělení pro ambulantní

pracoviště).

Dokument tiskne, aby do něj bylo možné provádět ruční
146 zápisy o stavu nemocné a o ordinacích vyšetření a léčby.

Doktor Akutní provádí první záznamy do ambulantní Uchazeč zapíše 2 věty, využije informace z úvodu scénáře.

147 dokumentace o okolnostech příjezdu pacientky a o
dosavadním vývoji zdraví.

Sestra Akutní nejrychlejším možným způsobem, jakým je toho Uchazeč se myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS umístěném podél horního okraje
KIS schopen, vystavuje žádanky, tiskne je a sleduje počty a obrazovky a postupně zobrazí všechny kontextové nápovědy.
typy odběrových zkumavek, do kterých musí získat
148 doporučené objemy krve.

Neurolog Mladý rychle provádí nezbytné neurologické
vyšetření a pro sílící podezření na akutní cévní mozkovou
příhodu vystavuje žádanku na perfuzní CT mozku statim.

149

21
Po vystavení žádanky v režimu statim se Radiologovi Zkušený Radiolog dá ústní pokyn Asistentovi Radiologickému k okamžitému provedení CT mozku podle iktového protokolu. Žádanky ve STATIM
Zkušenému v přehledu pacientů na CT přístroji určeném pro Asistent Radiologický pacientku zvolí pro další práci. režimu se v seznamu
vyšetřování pacientů z urgentního příjmu objeví Pacientka pacientů čekajících na
150 Neznámá s náhradním rodným číslem. Radiolog Zkušený vyšetření objevují buď
zkontroluje žádanku. jako zvýrazněné, nebo
jsou KIS automaticky
Radiolog Zkušený nález nadiktuje do formuláře pro řazeny na začátek
radiologické pracoviště KIS jako zvukový záznam. seznamu.
151
Vyšetření je virtuálně provedeno a jsou k dispozici snímky, které potvrzují původní podezření na ischemickou cévní mozkovou
Administrativa Kartotéční nadiktovaný záznam přehraje a příhodu v pravé mozkové hemisféře. Jako kontrastní látka je podán Optiray v objemu 50 ml.
152 zapíše do formuláře radiologického pracoviště.

153 Radiolog Zkušený přepsaný text zkontroluje a popis uzavře.

Radiolog Zkušený provede kompletní vyúčtování statim CT Pokud uživatel předvede
usnadnění vykázání –
154 mozku včetně použití jodové kontrastní látky, a to nejlépe přes zkratku pro balíček,
použitím předdefinované zkratky pro vykázání výkon CT případně tlačítko apod.

mozku a kontrastní látky. Doktor Akutní zprávu průběžně uloží, ale neuzavírá. Po každém uložení zprávy se vrátí do přehledu fronty pacientů
Doktor Akutní mezitím otevře dva jiné pacienty z fronty ošetřovaných na urgentním příjmu.

155 ošetřovaných na urgentním příjmu. U každého z nich do
ambulantního nálezu napíše dvě slova.

Sestra Akutní provedla s jedním z čekajících pacientů po

určité době řízený rozhovor a změnila stupeň naléhavosti
156 podle Manchester triage ze 4 na stupeň 2; přidává symptom

dušnost.

Doktor Akutní dokončí ambulantní dokumentaci Pacientky
157 Neznámé a odesílá ji na JIP neurologie. Stanoví diagnózu

„I63.4 Mozkový infarkt způsobený embolií mozkových tepen“.

158 Provede kompletní vyúčtování péče na urgentním příjmu. Tisk
ambulantní zprávy.

Neurolog Zkušený přijímá pacientku na neurologickou JIP. Kompletní příjem - tedy anamnézu (tu uchazeč napíše kompletní – je velmi stručná a dá se pomocí historie přenést) a stav při

Provede kompletní příjem - respektuje pokyny ve vedlejším přijetí, který se omezí na 3 položky vložené pomocí předdefinovaných šablon pro fyzikální vyšetření – „neurologický stav“,

159 sloupci. „vyšetření hrudníku“, „vyšetření břicha“. Fyzikální nález bude obsahovat TK 225/115 mmHg, TF bude 74/min. Včetně

automatického založení účtu.

22
Neurolog Zkušený připraví dekurz pro JIP. Dieta nic p. os. Pokud to KIS umožňuje, uchazeč většinu ordinací vnese do dokumentace pomocí předdefinovaných šablon pro standardní Předdefinované šablony
pro standardní ředění léků
Rehabilitace pasivně na lůžku. Z léčiv bude ordinovat: ředění léků. jsou uvnitř KIS dále
roztříděny podle druhu
• Glu 20 % 500 ml i.v. na 12 hod. kontinuálně léčiva (kategorie výživa,
kategorie vasoaktivní léky
• Fraxiparine 0,4 ml 1 inj. s.c. ve 20 hod. atp.).

• Ebrantil 50 mg 2 amp. doředit F1/1 do 50 ml i.v. pumpou
160 posun 5 ml/hod a dále systolický TK udržovat v rozmezí 160-

180 mmHg

• Humulin R 50 j doředit F1/1 do 50 ml i.v. pumpou posun 1

ml/hod a glu udržovat v rozmezí 6-10 mmol/l

Tisk dekurzu.

Sestra Jipecká provede ošetřovatelský příjem Pacientky Uchazeč bude volit v jednotlivých škálách nějaké hodnoty sledovaných parametrů, které neodpovídají zdravému člověku
161 Neznámé. Po skončení příjmu jsou zobrazena dosažená (příklad - porucha příjmu stravy, porucha příjmu tekutin, porucha hybnosti, inkontinence moče). Cílem je dosáhnout bodových
hodnot, které indikují potřebu zvýšené ošetřovatelské péče.
skóre ošetřovatelských klasifikací dostupných v KIS.
Zhoršení stavu. Ochrnutí levé poloviny těla je více vyjádřeno a jsou známky dechové tísně, proto pacientku na 3 hodiny připojí
Dokumentace 3 hodin neinvazivní ventilace prostřednictvím na neinvazivní plicní ventilaci (NIV). Dech se upraví a NIV je možné ukončit. Postupně se rozvíjí porucha vědomí se
162 KIS. zachovalou dechovou a srdeční aktivitou.

Sestra Jipecká po zazvonění otvírá dveře na JIP, kde stojí policista a sděluje skutečnou identitu Pacientky Neznámé.

163 Pacientka se ve skutečnosti jmenuje Marie Ochablá, číslo pojištěnce 586023/9999, je pojištěna u zdravotní pojišťovny č. 205.

Sestra Jipecká provede korekci zjištěných údajů v Master
164 Patient Indexu.

165 Neurolog Zkušený zobrazí historii pacientky v KIS a projde
veškerou dostupnou dokumentaci.

166 Jako doklad o předchozím ošetřování vytiskne poslední
zprávu z kardiologické ambulance.

167 Vytiskne i uzavřenou ambulantní dokumentaci z urgentního
příjmu před přijetím na jejich neurologickou JIP.

Neurolog Zkušený přeloží pacientku na ARO. Vyplní hlášení Uchazeč bude demonstrovat, jakým způsobem je v KIS nastaveno automatické generování závěrečné zprávy.

168 hospitalizace a automaticky bez jakýchkoli úprav vyrobí Uchazeč pro tato vyšetření připraví do databáze laboratorních výsledků fiktivní číselné hodnoty, které některé spadají do
fyziologického rozmezí hodnot pro vyjmenovaná vyšetření, některé meze intervalu fyziologického rozmezí překračují ve
závěrečnou zprávu, kterou hned uzavře jako definitivní. smyslu plus (vždy CRP, někdy Na, K, glu) i mínus (Cl, někdy pH, Na). Zadavatel požaduje tyto hodnoty proto, aby bylo možné
Sestra Chirurgická vystavuje žádanky na aktuální odběry je ve formulářích pro procesní podporu zobrazení laboratorních výsledků prohlížet a vidět způsob zobrazení referenčního
intervalu pro dané vyšetření a způsob uchazečem zvoleného znázornění hodnot mimo fyziologický interval včetně komentářů
biochemie a chystá si i žádanky na pravidelně denně u patologických hodnot.

prováděná laboratorní vyšetření - urea, krea, Na, K, Cl, glu,
169 CRP, pCO2, p02, SatO2, pH.

Proběhne administrativní přijetí na ARO v redukovaném V rámci úspory času uchazeč ukáže, které oddíly chorobopisu při překladu mezi odděleními téže nemocnice mohou být
170 rozsahu - viz popis. přeneseny a jak jsou přeneseny. Vše, co lze, uchazeč převezme a bez navazující editace uloží jako součásti chorobopisu na
ARO.
Anesteziolog Mladý v dekurzu JIP (ARO) od D+1 vysadí
171 infuzi glukózy a ordinuje Smof-Kabiven 1980 ml i.v. pumpou

na 24 hod. kontinuálně.
Provede hlášení pneumonie prostřednictvím KIS do
172 hygienického systému nemocnice a zároveň vyplní Hlášení
infekční nemoci, mikrob byl určen jako „Pseudomonas
aeruginosa“.

23
Pacientka je léčena, ventilována na ARO do D+6. Na každý Uchazeč ukáže nejrychlejší dostupný způsob výroby dekurzu se stejným obsahem ordinací vyšetření a léčby na následující

den Anesteziolog Mladý připraví dekurz prostým dny. Uchazeč se bude snažit ve scénáři popsané činnosti zvládnout co nejrychlejším způsobem, který KIS umožní.

prodloužením ordinací bez jakýchkoli dalších úprav léčby.

Každý den od D+1 do D+5 zadá do KIS 24 hodin umělé plicní

173 ventilace (UPV).

Ze všech vyrobených dekurzů zobrazí pouze dekurz na den V D+6 v 17:00 dochází náhle k zástavě základních životních funkcí, KPR je neúspěšná, pacientka umírá. Výkaz umělé plicní
174 D+5, pak si prohlédne přehled výsledků všech vyšetření a ventilace se kryje s
Až do úmrtí trval zvýšený hygienický režim C. Trval více než 96 hod., Dokumentaristka bude moci vykázat kód pro izolaci lékařským dekurzem -
prohlédne si za všechny dny hospitalizace získané „Z29.0“. tedy od 7:00 do 7:00 hod..
laboratorní výsledky.
175 Nechá si graficky zobrazit trend urea, krea, draslíku (K).
Anesteziolog Mladý ukončuje výkaz hodin umělé plicní
ventilace za celou hospitalizaci na ARO až do hodiny úmrtí
176 pacientky.

Anesteziolog Mladý vytvoří poslední epikrízu dodáním prosté

věty o úmrtí, statistický záznam o hospitalizaci, v něm bude
177 požadovat provedení pitvy. Jako diagnózu příčiny smrti udá

„J18.0 Bronchopneumonie“.

Anesteziolog Mladý si pomocí formulářů pro procesní Uchazeč pro text závěrečné zprávy předvede vložení všech vstupních hodnot laboratorních vyšetření provedených v průběhu KIS umožňuje výběr

podporu zobrazení laboratorních komplementárních výsledků prvního ošetření na urgentním příjmu. Dále vloží všechny hodnoty laboratorních vyšetření KO, INR, poměru APTT laboratorních hodnot pro

prohlédne různě vybrané laboratorní hodnoty, provede výběr provedených při překladu na ARO a vloží kompletní řadu vyšetření CRP za celou dobu hospitalizace. vytvoření závěrečné

hodnot, které chce přenést do závěrečné zprávy. zprávy ve formulářích pro

procesní podporu

prohlížení laboratorních

178 výsledků. Přenos všech

dostupných výsledků do

závěrečné zprávy s jejich

následnou editací není

bodově ohodnocen.

Anesteziolog Zkušený vytvoří závěrečnou propouštěcí zprávu Závěrečná zpráva je vygenerována s vybranými hodnotami, nenásleduje žádné další dodání textu.
s využitím informací tak, aby byl zachován kompletní obraz
179 obtíží od přijetí na lůžko až k úmrtí. Závěrečnou zprávu
uzavře a vytiskne.

Anesteziolog Zkušený vyplní List o prohlídce zemřelého a
180 vytiskne všechny potřebné výtisky v souladu s platným

právním předpisem.

24
Náměstek Lékařský šetří stížnosti na urgentní příjem. Zobrazí Uchazeč předvede orientaci v logu a vyhledání událostí na konkrétních pracovištích, konkrétních datech, vyhledávání činností Log zaznamenává i obsah

v logu den, kdy byla přijata Marie Ochablá a zobrazí si konkrétních osob nebo zobrazování akcí prováděných se záznamy konkrétního pacienta. okna pro zápis krátkého

181 jednotlivé pacienty z urgentního příjmu včetně stupně popisu symptomu.

naléhavosti triage, jejich změn – kdo, kdy, jak. Zobrazí

činnosti Doktora Akutního v daném dni přijetí Marie Ochablé.

Uchazeč ukáže, jak jsou všechny získané dokumenty KIS je schopen každé

označeny jako součásti zdravotnické dokumentace samostatné části

zadavatele – konkrétně vznikne jedna ambulantní zdravotnické

dokumentace urgentního příjmu a dva chorobopisy z dokumentace ve fiktivní

182 neurologie a ARO. nemocnici přidělit i
editovatelný skratační

znak a přiřadit délku

uchování podle platných

právních předpisů.

183 Výkaznictví
V rámci vytvoření ambulantního účtu bude pořízen mj. výkon

184 vyžadující schválení revizním lékařem a následně bude
vystavena žádanka o schválení.

Následně bude prezentováno, že daný účet nebude možno Ukázka kontroly na existenci schválené žádanky.
185 vykázat na pojišťovnu.

Následně bude označena příslušná žádanka jako schválená Kontrola na schválení výkonu (existenci schválené žádanky) již bude považovat daný výkon za schválený.
186 a účet bude možné vykázat na pojišťovnu.

187 Hospitalizační oblast a DRG
188 Bude předveden pohled na hospitalizační případ přes DRG.

Bude předveden přenos diagnóz klinické části do účtu i
189 promítnutí úprav v diagnózách v průběhu hospitalizace -

změna hlavní a vedlejších diagnóz.

190 Bude předvedena kontrola na vykázání diagnóz s "*"
(hvězdičkou).

Po ukončení hospitalizace a uzavření účtu nebude možné Systém bude nastaven na nemožnost vykázat na pojišťovnu péči vztahující se k dosud neschválenému hospitalizačnímu
případu.
191 tento účet vykázat na pojišťovnu - příslušný hospitalizační
případ nebude schválen k vykázání.

Po schválení případu oprávněnou osobou bude prezentována Uchazeč se myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS umístěném podél horního okraje
192 připravenost účtů k vyúčtování na pojišťovnu. Zároveň bude obrazovky a postupně zobrazí všechny kontextové nápovědy.

předveden případ v pohledu DRG.

193 Bude předvedena možnost nastavení stupně kontrol a na konkrétních případech bude prezentováno

Upozornění – na situaci: je vykázán účet anestezie, chybí
194 účet s operačním výkonem.

25
Účet lze pořídit, ale nelze vykázat pojišťovně – na situaci: je

pořízen účet (doklad 06) s ambulantním žadatelem a s
195 výkonem s omezením pouze na ambulanci. V době pořízení

tohoto účtu ale bude pacient hospitalizován.

Účet nelze pořídit – na situaci: bude vykázán výkon 09117 s
196 omezením podle věku u dvacetiletého pojištěnce.

Na dokladu 03 dojde k vykázání nesmyslného množství léku. Příslušná kontrola bude nastavena na okamžik před vyúčtováním a tento doklad bude označen jako chybný (lze pořídit, ale

Příslušný navázaný výkonový doklad pak bude v tomto nelze vykázat na pojišťovnu).

197 případě také označen jako chybný a bude předveden způsob
zobrazení historie dokladu s popisem důvodu chyby.

Dojde k pokusu pořídit účet s neexistujícím externím
žadatelem. Bude předveden možný postup opravy - vstup do
198 číselníku externích žadatelů, možnost vyhledávání dle
známých kritérií (jméno lékaře?)

Bude předvedena hromadná změna hodnot nad vícero účtů –
bude provedena oprava výkonu 11021 za výkon 11022 a
199 bude do historie těchto účtů vložena poznámka s důvodem
změny „vykázané komplexní vyšetření změněno na cílené“.

Import dvou K-dávek z externího SW - doprava, laboratoř Budou nahrány doklady obsahující následující chyby:
200 a) Neexistující pacient v centrálním registru KISu,
b) Pacient s jinou pojišťovnou na dokladu a v registru,
Oprávněná osoba si zobrazí seznam chybných dokladů a c) Poukaz s ambulantním žadatelem v době hospitalizace pacienta (agregované výkony + změna žadatele na příslušnou
201 provede jejich opravu. lůžkovou stanici),
d) Externí žadatel neexistující v číselníku žadatelů KISu.

V rámci vyúčtování péče bude předvedeno:

202 V systému budou doklady, kde budou vykázány společně výkony 75347, 75348 a 75427, a to minimálně v počtu 5 dokladů
pro poj. 111, 5 dokladů pro poj. 207 a 5 dokladů pro ostatní pojišťovny.

V rámci vyúčtování poj. 111 - z výkonů 75347, 75348 a
203 75427 bude pojišťovně vykazován pouze výkon 75347,

ostatní výkony budou vykázány na fiktivní pojišťovnu 11x.

V rámci vyúčtování poj. 207 - z výkonů 75347, 75348 a
204 75427 budou pojišťovně vykazovány zvlášť výkony 75347 v

samostatné dávce a ostatní výkony s ostatní péčí.

U ostatních pojišťoven budou doklady s výkony 75347, 75348
205 a 75427 vyúčtovány standardně (tj. s ostatní péčí).

26
Bude předvedeno sestavení dávek na vybrané číslo
pojištěnce z EU – pacient bude mít vykázány účty za
206 hospitalizační péči, komplementárních vyšetření a dopravu.
Dále bude mít vykázanou ambulantní návštěvu, která bude
mimo interval hospitalizace.

Následně bude provedeno vystavení faktury za péči pro
207 tohoto pojištěnce.

Na vzorku minimálně deseti dokladů dopravy bude
prezentováno sestavení do dávky dle registrační značky a
208 data. Po té bude dávka rozpuštěna a bude sestavena znovu,
doklady budou tentokráte řazeny nejprve dle data a pak dle
registrační značky.

Bude předvedeno vyúčtování pacienta, který navštívil

závodního lékaře (ambulance ZL je součástí KISu). Účet
209 připravený k vyúčtování bude obsahovat vedle kódů

spadajících do kapitace i kódy, které se účtují pojišťovně.

210 Zpracování oprav

Bude předvedeno zpracování následujících „chyb“ vrácených Uchazeč se myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS umístěném podél horního okraje

ze ZP: obrazovky a postupně zobrazí všechny kontextové nápovědy.

a) Vrácen celý doklad, po opravě chyby bude doklad

následně připraven znovu k odeslání na ZP,

b) Vrácen celý doklad, který nebude opravován a znovu

odesílán,

c) Vrácena jedna položka z dokladu, která bude následně

opravena a připravena k odeslání na ZP,

211 d) Vrácena jedna položka z dokladu, která nebude

opravována a znovu odesílána,

e) Vrácena jedna položka z dokladu, kterou si ZP sama ve

svých datech korigovala (např. změna počtu vykázaných

výkonů ze dvou na jeden).

V každém uvedeném případě bude v původním dokladu
zobrazený textový záznam o „chybě“ a v historii dokladu bude
patrný záznam o manipulaci s dokladem.

Bude předvedeno, že se uvedené opravy chyb správně
promítají do sestav / přehledů produkce péče nebo do
pohledu na případ DRG. Budou předvedeny sestavy
212 a) pro konkrétního pojištěnce,
b) pro konkrétního plátce a na zvolené pracoviště,
a to v pohledu před opravou dat a po opravě.

213

KONEC PREZENTACE

27
Příloha č. 6
Čestné prohlášení
Čestné prohlášení

o splnění základní způsobilosti dle § 75 zákona č. 134/2016 Sb., zákon o zadávání veřejných
zakázkách, v platném znění (dále jen „zákon“)

Já, níže podepsaný statutární orgán účastníka:
název společnosti: ……………………
sídlo: ………………………………….
IČ: …………………………………….

čestně prohlašuji, že nejsem dodavatel, který:
b) má v České republice nebo v zemi svého sídla v evidenci daní zachycen splatný daňový
nedoplatek ke spotřební dani,
c) má v České republice nebo v zemi svého sídla splatný nedoplatek na pojistném nebo na
penále na veřejné zdravotní pojištění.

V……………………. dne ………………….

...……………………….
statutární orgán účastníka
Příloha č. 7 - Cenová tabulka - část 1
Název projektu : Modernizace IT FN HK v návaznosti na eHealth

Položka Okamžik pro fakturaci Maximálně Cena Cena
I. Etapa - Zpracování provádědcího projektu přípustná cena [Kč bez DPH] [Kč vč. DPH]
II. Etapa - Dodávka HW pro provoz integrační platformy a KISu
[Kč vč. DPH]

Odsouhlasený akceptační protokol první 4 849 600
etapy ze strany zadavatele

II. Etapa - Dodávka systémového SW pro provoz KISu a integrační platformy (zejména operační Odsouhlasený akceptační protokol
systém serverů, virtualizační platforma, databáze pro KIS a pro platformu) druhé etapy ze strany zadavatele

II. Etapa - Implementace integrační platformy včetně vybudování potřebných vazeb a Odsouhlasený akceptační protokol 81 730 400
implementace KISu – vše v rozsahu „pilotní projekt" druhé etapy ze strany zadavatele

III. Etapa - Dokončení implementace integrační platformy včetně vybudování potřebných vazeb a
implementace KISu – na zbývající pracoviště FN HK dle prováděcího projektu

IV. Etapa - Dodávka HW Portál pacienta Odsouhlasený akceptační protokol pro
IV. Etapa - Vytvoření a zprovoznění portálu pacienta portál pacienta ze strany zadavatele

Nabídková cena za dovávku IS celkem: 0,00 0,00

Maximálně

Servisní podpora č. 1 (po akceptaci díla) Maximálně přípustná výše Cena za rok Cena za rok Cena za 10 let Cena za 10 let
přípustná cena/rok plnění ve vztahu k [Kč bez DPH] [Kč vč. DPH] [Kč bez DPH] [Kč vč. DPH]
Portálu pacienta celkové nabídkové
Integrační platformy včetně komunikačních vazeb [Kč vč. DPH] ceně za servisní 0,00
Klinického informačního systému Cena za rok
podporu č. I/rok [Kč bez DPH]
Servisní podpora č. 2 (po akceptaci díla)
Dodaného HW a SW dle kapitoly 4.4. ZD 12 500 000 - 0,00 0,00 0,00
0,00 0,00
75,00% 0,00 0,00
0,00 0,00
Nabídková cena za servisní podporu u dodaného IS č. 1: 0,00
Cena za rok Cena za 5 let Cena za 5 let
Maximálně Limit maximální [Kč vč. DPH] [Kč bez DPH] [Kč vč. DPH]
přípustná cena/rok přípustné ceny
0,00 0,00 0,00
[Kč vč. DPH] [%] 0,00 0,00

2 000 000 100% 0,00
0,00
Celková nabídková cena za servisní podporu č. 1 a 2:

Celková nabídková cena v Kč bez DPH
Celková nabídková cena v Kč vč. DPH *

Název požadované role Maximálně Cena za Cena za Cena za Cena za
(cena prací nad rámec standardní sjednané servisní podpory) - NENÍ SOUČÁSTÍ HODNOCENÍ PŘEDMĚTNÉ přípustná cena za člověkohodinu - člověkohodinu - člověkohodinu - člověkohodinu -
člověkohodinu - běžná pracovní
VEŘEJNÉ ZAKÁZKY noční hodina víkend svátek
běžná pracovní doba [Kč vč. DPH] [Kč vč. DPH] [Kč vč. DPH]
Konzultant IS doba [Kč vč. DPH]
Senior konzultant IS 0,00 0,00 0,00
Analytik (architekt) IS [Kč vč. DPH]
Programátor IS
2 000

2 000

Cena celkem: 0,00

Pozn.: Účastník vyplní všechna oranžově podbarvená pole
* Tuto hodnotu uveďte do krycího listu nabídka - hodnota, která je předmětem hodnocení

Stránka 1 z 1 Příloha č. 7 - Cenová tabulka.xlsx
Příloha č. 8 - Zvýhodněné funkcionality
Název projektu : Modernizace IT FN HK v návaznosti na eHealth

Pozn. V případě, že k datu podání nabídky obsahuje nabízený systém zvyhodněnou funkcionalitu, vyplní účastník oranžově podbarvené pole hodnotou "ANO". Pokud k datu podání nabídky nabízený systém neobsahuje zvýhodněnou
funkcionalitu, vyplní účastník podbarvené pole hodnotou "NE". Sloupec A až C slouží pouze pro upřesnění případného významu zvýhodněné funkcionality v návaznosti na případnou konkrétní modelou situaci uvedenou v Příloze č. 5
Zadávací dokumentace. Texty uvedené jinou než černou barvou nemají funkční význam pro účely hodnocení.

Č. Bod scénaře Instrukce / komentář Zvýhodněná funkcionalita Vyberte
ke dni podání nabídky ANO nebo
ř.
KIS umožnuje uživateli NE
napříč celým systémem
používat shodné klávesové
zkratky s klávesovými
zkratkami Microsoft Word
minimálně v rozsahu:
Ctrl+S - Uložit,
Ctrl+X - Vyjmout vybrané
položky a uložit je do
schránky,
Ctrl+C - Zkopírovat
vybrané položky do
schránky,
Ctrl+V -Vložit obsah ze
schránky,
Ctrl+Z - Zpět,
Ctrl+A -Výběr všech
položek.

Chirurga Zkušeného přidělená jinému chirurgovi se specializovanou způsobilostí a bude demonstrovat "zkopírování/dědění" přístupových práv, ke přístupových práv KIS

kterým pak de novo přidá přístupová práva na urgentní příjem fiktivní nemocnice (bude mít právo pracovat s dokumentací na umožňuje kopírovat role s

20 urgentním příjmu včetně přístupu do MPI, práva uzavírat dokumentaci, digitálně ji podepisovat a nahlížet na systém zobrazování nastavením oprávnění

lůžkové kapacity v souladu se specifikací v ZD). odpovídající pracovní

pozici i zdravotnickému

Sestra Chirurgická řadí frontu čekajících pacientů na Uchazeč kromě našeho vzorového pacienta bude mít připraveno alespoň 7 dalších testovacích pacientů, z toho 3 akutní bez pracovišti současně.
Akutní pacienti jsou

24 chirurgické ambulanci č. 3. předchozího objednání. vizuálně zvýrazněni v
seznamu čekajících

Chirurg Mladý si vybere Maroda Zažívacího na vyšetření do pacientů.
Systém nabízí převzetí

ambulance. textu v oddílu anamnéza

Ve zdravotnické dokumentaci v anamnéze zobrazí text z jako součást služby

gastroenterologické poradny a převezme jej do své ambulantní historie pro okno se

zprávy k další editaci. záznamem volného textu

26 (tj. lékař nemusí otvírat

celou historii ošetření

pacienta v nemocnici,

najít vyšetření na interně a

text anamnézy přenášet

pomocí funkce Kopírovat-

Chirurg Mladý zjistí anamnesticky alergii na jód – ekzém a Vložit).
Záznam alergií je

provede záznam do ambulantní dokumentace. strukturovaně připraven v

parametrické podobě, aby

27 mohl být využit k
automatizovanému

vytváření pacientského

souhrnu (emergency data

vyšetření a texty dodané pomocí Lupy upraví. Do „nálezu na okno volného textu, které umožní postupně jedna po druhé zapsat alespoň „stav vědomí“, „nález na hrudníku“, „nález na břiše“. uživatelem vytvořených

břiše“ zapíše text v následujícím znění: „hmatná rezistence v textových řetězců, pohyb v

28 levém dolním kvadrantu“. jejich seznamu a jejich
vložení na pozici kurzoru v

okně pro volný text

nevyžaduje více než 2

Chirurg Mladý vystaví žádanku na CT břicha s kontrastem. kliknutí myší.
Budeme sledovat přenesení v KIS dostupných informací o pacientovi do žádanky. Dále postup vyplňování povinných položek dle Zobrazení více

Na žádance na CT bude uveden následující text: „Pacient s požadavků zadavatele. Chirurg uvidí plánovací kalendář CT radiologie, ale nebude mít oprávnění přímo obsadit konkrétní termín. plánovacích kalendářů na
30 údajem občasného krvácení vzhledu enterorhagie z jednotlivé modality
radiologie současně na
konečníku.“ obrazovce.

Chirurg Mladý vystaví žádanku na ultrazvuk břicha. Zobrazení plánovacích kalendářů pro CT, skiagrafii a UZ najednou, termín pro UZ musí být v jiný den než CT, nebo mu musí ve Grafické vyznačení oblasti

Na žádance bude uveden následující text: „Žádám o stehném dni předcházet. v plánovacím kalendáři,

32 předoperační UZ břicha v následujícím týdnu kvůli plánování Budeme sledovat přenesení v KIS dostupných informací o pacientovi do žádanky. Dále postup vyplňování povinných položek dle kam mám oprávnění
operace.“ požadavků zadavatele. Chirurg uvidí plánovací kalendář UZ radiologie a bude mít pro chirurgické pracoviště vyhrazené časy s objednávat.

možností přímo obsadit konkrétní termín.

Chirurg Mladý si zobrazí přehledovou tabulku o naplánovaných Provede posun po jednotlivých položkách v tabulce směrem do minulosti a poté rychlý návrat k vyšetřením s aktuálním datem. Přehled o plánovaných a
a uskutečněných vyšetřeních pacienta. recentně uskutečněných
ošetření pacienta se
40 otevře na aktuálním datu,
nikoliv na prvním
Chirurg Mladý objedná pacienta na další kontrolu v chirurgické Do okna volného texu ambulantní zprávy vloží libovolné texty, třeba i s použitím lupy, ale s tím, že text zprávy bude (včetně poskytnutém ošetření v
minulosti, které je v KIS k
ambulanci s výsledky všech objednaných vyšetření. vkládání konce odstavců) dosahovat alespon 20 řádků pod sebe, aby bylo patrné chování okna pro záznam volného textu. dispozici. Přehled je
vybaven klávesami či
Ambulantní zprávu dokončí a uloží s diagnózou kódem „D37.4“ Označí myší text v rozsahu 3.-6. řádku a takto označený blok textu myší přetáhne na jeho konec v rámci okna pro záznam posuvníkem, které po
historii umožňuje rychlý
a text dodaný defaultně KIS pozmění na „Novotvar sigmatu volného textu (i když tím záznam ztratí jazykově smysl). pohyb na ose od časově
nejstaršího po časově
neznámé povahy“. nejaktuálnější záznam, je
dostupná klávesa
41 umožňující rychlý návrat
na dnešní datum.
Okno pro záznam volného
textu má tzv. dynamickou
velikost - pokud původně
vyhrazený prostor nestačí,
velikost okna se ve
vertikálním směru začne
zvětšovat tak, že nakonec
je libovolně dlouhý text
celý zobrazen v okně.
Dynamická změna velikosti
se netýká šířky okna, která
je stabilní a text se
automaticky zarovnává k
levému okraji okna.

Provede velmi stručný zápis anesteziologického konzilia s Uchazeč má pro
použitím automaticky přenesených položek a přenosu ambulantní vyšetření u
informací z předchozího vyšetření v chirurgické ambulanci. konktrétní lékařské
odbornosti připraveny
63 šablony nad rámec
obecného požadavku na
strukturování ambulantní
dokumentace.
Chirurg Mladý provede kompletní lékařský příjem dle popisu v Do všech oken pro volný text vloží vždy nějaké uchazečem připravené texty z číselníku textů (mohou být i významově nesmyslné Záznam farmakologické

zadávací dokumentaci. ve vztahu ke konkrétnímu případu); pouze v oddíle osobní anamnéza budou alespoň 3 různé texty a každý z nich bude alespoň anamnézy je umožněn

Farmakologická anamnéza, kde chirurg zadá následující léky: na 3 řádky. formou parametrických

• Atoris 20 mg p. os. 1-0-0, Uchazeč předvede funkci historie v oknech pro záznam volného textu – jako optimální místo pro ukázku využije rodinnou oken, nikoliv výhradně

72 • Furon 40 mg p. os 1-1-0, anamnézu. formou volného textu.
• Ibuprofen AL 400 mg p. os 1-0-1 při bolesti,

• Volteren gel lokálně dle potřeby na P koleno

• Lantus Solostar inzulín s.c. 6-0-16 j.s.c.

• Oční kapky – název si nepamatuje – do OPL 1-0-1

Chirurg Mladý v návaznosti vytvoří lékařský dekurz. Zadavatel pro účely prezentace díla vyžaduje dekurz, kde ordinace léčivých přípravků nebude odděleně od ostatních záznamů, KIS při zadávání začátku
• Bude ordinovat dietu 0s – čajovou tj. nepoužije samostatnou „lékovou kartu“. obchodního názvu
• Režim pohybu po oddělení „C“ léčivého přípravku nabídne
• Hygienický režim „S“ – standardní vlastní uživatelský seznam
• Do záznamu vizity napíše: „Přijat a vyšetřen k plánované léčivých přípravků
operaci.“ vyhovující zadanému
• Přistoupí k ordinaci léků. kritériu pouze s názvem,
• Oční kapky neznámého názvu smaže a nahradí ordinací – sílou a formou. Pokud se
77 napíše přesně řetězec „dorzolamidum“, pokud KIS začne nabízí kompletní řetězec
nabízet léčivé přípravky, zvolí Trusopt 1-0-1 OPL. Pokud KIS názvu léčivého přípravku
nebude reagovat na název generika, začne psát obchodní (kromě názvu,síly a formy
název „Trusopt“. Jedná se o N-položku! je ve zkratce i velikost
• Inzulín Lantus vysadí a nahradí ordinací Humulin R 4-4-4 balení a popř. další
j.s.c. informace) z oficiálního
• Začne psát přesně řetězec „Trit“. Nabídne-li se seznam číselníku SÚKL, uchazeč
preparátů s obsahem látky, zvolí Tritace 2,5 mg 1-0-0. bod nezískává.

Chirurg Zkušený přijatého pacienta naplánuje k výkonu na KIS osobě bez příslušného
oprávnění nedovolí při
středu, zapíše veškeré údaje – operační tým lékařů, požadavek plánování operačního
programu v předstihu pro
na speciální instrumentárium, které za chirurgické pracoviště standardní pracovní dobu
se zohledněním nastavené
má vyplňovat do podrobného plánu operací na sál č. 3, výkon délky technologických
přestávek naplánovat
laparoskopicky asistovaný, délka plánována na 180 min. operační výkon tak, aby
byla standardní pracovní
81 Nejdříve zkusí operaci naplánovat na sál č. 1. Operační doba překročena.
program pro sál č. 1 je již téměř zaplněn jinými operacemi, do
Uchazeč má pro plánování
konce pracovní doby zbývá pouze 120 min. čistého času a KIS anesteziologického servisu
informační podporu, která
jej minimálně na tuto časovou kolizi upozorní. Chirurg Zkušený rychle a s dobrou
dostupností informuje
si proto ve finále vybere sál č. 3 zpřístupněný chirurgické lékaře o úkolech ve vztahu
k přípravě pacientů na
klinice. Tím se Marod Zažívací dostane do operačního operaci.

programu.
Anesteziolog Zkušený si zobrazí plánování anesteziologické

péče. Uvidí Maroda Zažívacího včetně všech dostupných údajů

dle požadavků zadavatele. Provede aktuální předanestetické

vyšetření, naplánování anesteziologické péče a ordinaci

premedikace. S ohledem na typ a rozsah výkonu rozhodne o

84 potřebě úplného zajištění – centrální žilní katétr, arteriální
katétr, močový katétr, celková anestézie. Takový rozsah si

vyžádá delší čas pro práci anesteziologa, než bývá vyhrazeno

na běžnou celkovou anestézii (10 min).V operačním plánu

zaznamená, že potřebuje na svou práci interval 20 min. před

vlastní operací.

Sestra Chirurgická předá Sestře Anesteziologické pacienta – je způsob zadání časů dějů
zaznamenán čas předání pacienta na operační sál v rámci na operačním sálu je
Oddělení operačních sálů. poloautomatizován - stisk
tlačítka nebo snímání
93 specifického čárového
kódu s automatickým
přiřazením reálného času.

Ve stejnou dobu bude: Uchazeč poskytuje v rámci
PC1 - Anesteziolog Mladý přihlášený na PC1 a vytvoří funkcionality
dokument pro pooperační sledování pacienta v délce 120 min. předdefinovaných textů i
Mezi sledované funkce patří alespoň TF, TK, SpO2, vědomí, ordinace uživatelem
DF, diuréza, zvracení (ano/ne), krvácení (ano/ne), glu, odpad z definovaných infuzních
drénů. roztoků, které ordinující
Do dokumentu zaznamená čas převzetí Maroda Zažívacího z lékař vybírá z nabídky a
operačního sálu. Provede i ordinaci léčivých přípravků (může vkládá do sekce ordinací
použít připravené ordinace v předdefinovaných textech): ve zdravotnické
Novalgin 1 g do F1/1 100 ml i.v. na 30 min. dokumentaci s možností
podmíněnou ordinaci Dipidolor 15 mg 1 amp. i.v. bolusem na 5 plné editace vloženého
min. v případě bolesti VAS rovno nebo silnější než 2/4 textu.
102 (=čtyřstupňová škála).
Jako podmínky pro možné propuštění sestrou z pooperačního
pokoje jsou stanoveny:
• Analgézie zajištěna a je dostatečná:
• Kašle:
• Polyká:
• Není nauzea:
• Krvácení, odhad objemu < 100 ml
Anesteziolog Mladý - Čtečkou čárových kódů jsou načteny
čárové kódy dvou připravených zdravotnických prostředků
nepoužitých na operačních sálech, které se vnesou do
dokumentu jako přístroje použité k monitorování pacienta.
Připravený dokument uchazeč vytiskne.

PC2 - Chirurgovi Mladému při zahájení editace OP se nabídne I u dokumentace z

předvyplněný formulář operačního protokolu s přenesenými operačního sálu je

parametrickými údaji, které byly nashromážděny zavedený systém

prostřednictvím KIS v předešlém čase a mají vztah k operaci. dvojstupňové kontroly -

103 Automaticky přenesené položky lze editovat - uchazeč definitivní uzavření

předvede při úpravě času zahájení práce chirurgů, který upraví dokumentace může

o 2 minuty dopředu. Dokončený operační protokol Chirurg provést jen lékař se

Mladý vytiskne. specializovanou

způsobilostí.
Chirurg Mladý 2. den po operaci propouští Maroda Zažívacího V době psaní zprávy jsou k dispozici všechny výsledky vyšetření, o kterých se ve scénáři jednalo. Uchazeč tedy předvede způsob Při vytvoření doporučení

domů a vytváří kompletně všechnu listinnou agendu k tomu výběru výsledků vyšetření z laboratorního komplementu i ostatních typů vyšetření a konzilií, předvede způsob jejich vložení do závěrečné zprávy se lékaři

nutnou podle požadavků zadavatele: závěrečné zprávy, její editaci včetně plného rejstříku grafických úprav textu pomocí textového editoru KIS v souladu se zadávací nabídnou údaje o

• Statistické hlášení o hospitalizaci včetně všech kódů dokumentací. Uchazeč do sekce Doporučení vloží 2 různé položky výběrem z dostupného uživatelského číselníku textů. farmakologické anamnéze

požadovaných ÚZIS. získané při přijetí

107 • Závěrečnou propouštěcí zprávu se všemi náležitostmi dle současně s naposledy

požadavků zadavatele. ordinovanými léky na

V průběhu editace závěrečné zprávy si Chirurg Mladý text lůžkové stanici; záznamy

několikrát průběžně uloží. jsou editovatelné bez

omezení.

Chirurg Zkušený zkontroluje dokumentaci vytvořenou Při vytváření závěrečné
Chirurgem Mladým. Závěrečnou zprávu uzavře jako definitivní zprávy jsou do zprávy
a vytiskne. Poté se odhlásí od pracovní stanice. přeneseny všechny
109 relevantní parametrické
údaje, které se vážou k
Chirurg Zkušený se přihlásí do KIS na své pracoviště – bude hospitalizaci automaticky s
upozorněn na protiepidemický alert. možností neomezené
editace.
112 Hygienický alert se
automaticky zobrazí,
jakmile přihlášený
zdravotník zvolí pacienta s
nastaveným upozorněním
na závažnou infekci. Po
uzavření alertového okna
uživatelem zůstává na
obrazovce grafické
upozornění, že po
hygienicko-protiepidemické
stránce je pacient
problémový.
V samotném závěru scénáře uchazeč zobrazí log událostí u Maroda Zažívacího a budeme kontrolovat záznamy vstupů do Log je přehledný,

dokumentace s přesnou lokalizací v čase se zvláštním důrazem na fiktivní pracovníky, kteří nejsou kmenoví zaměstnanci umožňuje vyhledávání a

Chirurgické kliniky a ARO (tzn. zejména Náměstka Lékařského, Dokumentaristku, Administrativu Kartotéční). Budeme hledat i třídění podle záhlaví

záznam o databázových dotazech provedených Chirurgem Mladým včetně záznamů o činnostech, které se zpřístupněnou sloupců a registruje

113 dokumentací z jiného oddělení včetně zápisu důvodu nahlížení do dokumentace provedl. všechny operace se
zdravotními záznamy - tj.

alespoň nahlížení, tisk,

důvod k nahlížení, export

zdravotnické

dokumentace.
Gynekolog Zkušený ji přebírá do péče rizikové poradny. Zadá Uchazeč se myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS umístěném podél horního okraje obrazovky KIS nabídne automaticky

datum primotrimestrinálního screeningu do KIS pro stanovení a postupně zobrazí všechny kontextové nápovědy. sérii termínů dalších

intervalů dalších ambulantních kontrol rodičky a s podporou plánovaných kontrol až do

KIS objedná alespoň následnou kontrolu. Rodička Riziková má očekávatelného termínu

119 bichoriální – biamniální dvojčata, na kterých není zjevná žádná porodu.

patologie. Provede zápis všech dostupných informací včetně

využívání funkce historie pro okna volného textu. Zkontroluje

předchozí historii všech vyšetření v nemocnici.

Gynekolog Mladý provede veškeré lékařské úkony nezbytné u Uchazeč se myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS umístěném podél horního okraje obrazovky Ambulantní zpráva o

příjmu rodičky včetně provedení vyšetření glykémie. V průběhu a postupně zobrazí všechny kontextové nápovědy. sledování těhotné je

příjmu Rodičce Rizikové odtéká plodová voda – porod začal a připravena tak, aby

Gynekolog Mladý zakládá porodopis. Zobrazí si prostřednictvím relevantní data z ní mohla

KIS všechny jemu přístupné zdravotní záznamy pacientky. být prostřednictvím KIS

124 automaticky převedena do

porodopisu (zprávy o

rodičce) a do zprávy o

novorozenci/cích v případě

vícečetných těhotenství.

Pediatr Zkušený vyplní anamnézu při přijetí na Pediatr může informace z
novorozeneckou JIP pomocí přístupu do zdravotnických anamnézy rodičky přebírat
záznamů Rodičky Rizikové a předá Annu Rizikovou do péče do dokumentace dítěte
133 Neonatologovi Vedoucímu. pomocí služby historie, tj.
nemusí užívat funkci
kopírovat-vložit.

Pediatr zkušený si prohlédne zpětně dokumentaci obou dětí, u I v případě, kdy bude
kterých měnil identifikátor – konkrétně ji bude prohledávat pediatr prohlížet
podle náhradního identifikátoru i podle skutečného čísla novorozeneckou
pojištěnce či rodného čísla. dokumentaci vyhledanou
podle skutečného rodného
137 čísla, archivovaná
dokumentace bude
existovat pod původním
náhradním rodným číslem.

Doktor Akutní se dívá na seznam všech pacientů na urgentním Po zastavení kurzoru myši
na přidělené hodnotě
příjmu, který má stále otevřený na svém počítači. Myší Manchester triage se
zobrazí okno s detailním
142 kontroluje hodnoty přidělené Manchester triage a sloupec se popisem symptomů.
specifikací symptomu.

Sestra Akutní nejrychlejším možným způsobem, jakým je toho Uchazeč se myší zastaví na ikonách všech ovládacích prvků v ovládacím panelu KIS umístěném podél horního okraje obrazovky KIS umožňuje přípravu

KIS schopen, vystavuje žádanky, tiskne je a sleduje počty a a postupně zobrazí všechny kontextové nápovědy. sestav žádanek vybraných

typy odběrových zkumavek, do kterých musí získat doporučené laboratorních vyšetření,

148 objemy krve. které umí vyvolat
uživatelsky definovanou

ikonou, popř. i klávesovou

zkratkou.

Neurolog Mladý rychle provádí nezbytné neurologické vyšetření Systém nabízí menu či
a pro sílící podezření na akutní cévní mozkovou příhodu jinak organizovaný výběr
vystavuje žádanku na perfuzní CT mozku statim. konkrétních typů
zobrazovacích vyšetření
149 tak, aby lékař výběrem
položky zadal údaje o typu
zobrazovacího vyšetření,
režim rutina/statim,
požadavek na případné
použití kontrastní látky.

Po vystavení žádanky v režimu statim se Radiologovi Žádanky ve STATIM
režimu se v seznamu
Zkušenému v přehledu pacientů na CT přístroji určeném pro pacientů čekajících na
vyšetření objevují buď jako
vyšetřování pacientů z urgentního příjmu objeví Pacientka zvýrazněné, nebo jsou KIS
automaticky řazeny na
150 Neznámá s náhradním rodným číslem. Radiolog Zkušený začátek seznamu.
zkontroluje žádanku.

Radiolog Zkušený provede kompletní vyúčtování statim CT Pokud uživatel předvede
usnadnění vykázání – přes
154 mozku včetně použití jodové kontrastní látky, a to nejlépe zkratku pro balíček,
použitím předdefinované zkratky pro vykázání výkon CT mozku případně tlačítko apod.
Předdefinované šablony
a kontrastní látky. pro standardní ředění léků
jsou uvnitř KIS dále
Neurolog Zkušený připraví dekurz pro JIP. Dieta nic p. os. Pokud to KIS umožňuje, uchazeč většinu ordinací vnese do dokumentace pomocí předdefinovaných šablon pro standardní roztříděny podle druhu
léčiva (kategorie výživa,
Rehabilitace pasivně na lůžku. Z léčiv bude ordinovat: ředění léků. kategorie vasoaktivní léky
atp.).
• Glu 20 % 500 ml i.v. na 12 hod. kontinuálně

• Fraxiparine 0,4 ml 1 inj. s.c. ve 20 hod.

• Ebrantil 50 mg 2 amp. doředit F1/1 do 50 ml i.v. pumpou

160 posun 5 ml/hod a dále systolický TK udržovat v rozmezí 160-

180 mmHg

• Humulin R 50 j doředit F1/1 do 50 ml i.v. pumpou posun 1

ml/hod a glu udržovat v rozmezí 6-10 mmol/l

Tisk dekurzu.

Anesteziolog Mladý ukončuje výkaz hodin umělé plicní V D+6 v 17:00 dochází náhle k zástavě základních životních funkcí, KPR je neúspěšná, pacientka umírá. Výkaz umělé plicní
ventilace za celou hospitalizaci na ARO až do hodiny úmrtí
176 pacientky. ventilace se kryje s

Až do úmrtí trval zvýšený hygienický režim C. Trval více než 96 hod., Dokumentaristka bude moci vykázat kód pro izolaci „Z29.0“. lékařským dekurzem - tedy

od 7:00 do 7:00 hod..

Anesteziolog Mladý si pomocí formulářů pro procesní podporu Uchazeč pro text závěrečné zprávy předvede vložení všech vstupních hodnot laboratorních vyšetření provedených v průběhu KIS umožňuje výběr
laboratorních hodnot pro
zobrazení laboratorních komplementárních výsledků prohlédne prvního ošetření na urgentním příjmu. Dále vloží všechny hodnoty laboratorních vyšetření KO, INR, poměru APTT provedených vytvoření závěrečné
zprávy ve formulářích pro
různě vybrané laboratorní hodnoty, provede výběr hodnot, při překladu na ARO a vloží kompletní řadu vyšetření CRP za celou dobu hospitalizace. procesní podporu
prohlížení laboratorních
které chce přenést do závěrečné zprávy. výsledků. Přenos všech
dostupných výsledků do
178 závěrečné zprávy s jejich
následnou editací není
Náměstek Lékařský šetří stížnosti na urgentní příjem. Zobrazí v Uchazeč předvede orientaci v logu a vyhledání událostí na konkrétních pracovištích, konkrétních datech, vyhledávání činností bodově ohodnocen.
logu den, kdy byla přijata Marie Ochablá a zobrazí si jednotlivé konkrétních osob nebo zobrazování akcí prováděných se záznamy konkrétního pacienta. Log zaznamenává i obsah
pacienty z urgentního příjmu včetně stupně naléhavosti triage, okna pro zápis krátkého
181 jejich změn – kdo, kdy, jak. Zobrazí činnosti Doktora Akutního v popisu symptomu.
daném dni přijetí Marie Ochablé.

Uchazeč ukáže, jak jsou všechny získané dokumenty KIS je schopen každé
označeny jako součásti zdravotnické dokumentace zadavatele samostatné části
– konkrétně vznikne jedna ambulantní dokumentace zdravotnické dokumentace
urgentního příjmu a dva chorobopisy z neurologie a ARO. ve fiktivní nemocnici
182 přidělit i editovatelný
skartační znak a přiřadit
Já níže podepsaný čestně prohlašuji, že veškeré zvýhodněné funkcionality, kterým bylo přiřazeno „ANO“, jsou předmětem nabídky a takto nabízené funkcionality obsahuje/splňuje nabízený délku uchování podle
klinický inf. systém již k datu podání nabídky. platných právních
předpisů.

V …………….. ……………………………………………….
Dne ………….. Podpis
Příloha č. 9 - Scénáře pro AVZ
Název projektu : Modernizace IT FN HK v návaznosti na eHealth

Černá barva písma - vlastní scénář popisující v návaznosti činnosti simulované uchazečem prostřednictvím KIS, čtený text uchazečem musí být součástí AVZ
Modrá barva písma – instrukce pro prezentující osoby uchazeče v průběhu soutěžní ukázky vzorku, čtený text uchazečem musí být součástí AVZ
Hnědá barva písma – komentáře pro prezentující osoby uchazeče (tyto texty uchazeč do AVZ nečte), které popisují:

• prvky ve scénáři, které si uchazeč ve své databázi musí připravit dopředu před výrobou AVZ
(např. sestavy pacientů, konkrétní zdravotníky v jejich předem definovaných rolích),

• stanovují anamnestické údaje a ostatní okolnosti, které mají význam pro průběh scénářů pro výrobu AVZ
(např. obsahují časové informace, názvy zúčastněných pracovišť zadavatele) a budou mít v průběhu scénáře význam a dopad na
zaznamenané skutečnosti.

Č. řádku Monitor PC V průběhu simulace scénářů prostřednictvím KIS při výrobě AVZ bude uchazeč číst texty uvedené
1 Černou a modrou barvou v časové posloupnosti směrem zleva doprava a shora dolů ve sloupcích
2 nadepsaných Č. řádku, monitor PC a Instrukce / komentář. Uchazeč při výrobě AVZ vždy slovně
3 okomentuje situace, kdy provádí posun času v systému, aby simuloval požadované časové
4 odstupy ve scénářích.
5
Účastník v rámci každého souboru AVZ uvede (slovně) na začátku název společnosti a název a číslo
6 scénáře, který je v souboru zaznamenán.
Po celou dobu simulace scénář uchazeč systém nastaví tak, aby zůstal viditelný ukazatel myši.
Funkčnost klávesových zkratek bude také odvozena z provedení akce v rámci KIS, aniž by byl patrný
pohyb ukazatele myši (ten při této akci bude umístěn do takové části obrazovky mimo ovládací prvky
KIS, kde bude dobře patrný a bude zřetelně vidět, že se nepohybuje) nebo aniž by se otevřelo
uživatelské menu v místě umístění ukazatele myši.
Postup odhlašování a přihlašování osob v rámci scénářů je součástí obsahu AVZ.

Instrukce/komentář
Pokud nemá uchazeč Master Patient Index (MPI) umístěn a spravován přímo v KIS, pro účely
simulace scénářů a výroby AVZ vytvoří takové řešení, které MPI zpřístupní v samostatné aplikaci a
KIS v průběhu tvorby AVZ bude využívat služeb a informací umístěných v takové aplikaci.
Nemožnost prezentovat funkcionality MPI a KIS ve vzájemné interakci s cílem předvést níže
popsané scénáře a dokumentovat je na AVZ znamená vyloučení uchazeče z účasti na veřejné
zakázce.
Uchazeč provede přípravu pro výrobu AVZ dle níže uvedených scénářů. Každý fiktivní pracovník má
své jméno, příjmení, osobní číslo v personální struktuře nemocnice a unikátní login. Soubor fiktivních
pracovníků nemocnice, který si uchazeč připraví, není omezen; takový soubor fiktivních pracovníků
ale musí obsahovat alespoň níže uvedené postavy účinkující ve scénářích.

Uchazeč pro účely simulace scénářů při výrobě AVZ předvede body scénářů v chronologickém pořadí
daném zadavatelem v příloze č. 9. Uchazeč si zvolí způsob a technické řešení, jakým musí simulovat
specifikovaný časový odstup jednotlivých akcí při výrobě AVZ.
Vždy, kdy v rámci předvádění scénářů uchazeč provede časový posun děje vyžadovaný scénářem,
upozorní na tuto akci v rámci mluveného komentáře v AVZ.
Fiktivní pracovníci uvedení níže mají přidělené své unikátní:
• loginy a hesla,
• role,
• vymezení přístupu na konkrétní pracoviště
• vymezení přístupu ke specifickým funkcím, jestliže je to relevantní
• všechni fiktivní pracovníci mají přístupný nástroj obecného dotazu v KIS
s výjimkou jednoho z nich: Chirurga Zkušeného.

Minimální soubor fiktivních pracovníků pro scénáře simulované pro výrobu AVZ:
• Chirurg Mladý - lékař bez specializované způsobilosti, chirurg, má přístupová práva do MPI, přístup
na standardní oddělení, operační sály, chirurgickou JIP, chirurgickou ambulanci, urgentní příjem,
nemá oprávnění pro vystavení žádanky na magnetickou rezonanci, nemá oprávnění finalizovat a
uzavírat zdravotnickou dokumentaci, má v souladu s KIS_048 speciální oprávnění po zdůvodnění
přístupu způsobem specifikovaným zadavatelem nahlížet do zdravotních záznamů v KIS u pacientů i z
jiných pracovišť nemocnice, než je pro jeho roli specifikováno výše,

• Operatér Centrální – lékař se specializovanou způsobilostí s přístupovými právy na úrovni primáře

oddělení centrálních operačních sálů, lékař se specializovanou způsobilostí, chirurg, má přístupová

7 práva do MPI,přístup na standardní oddělení, operační sály, chirurgickou JIP, chirurgickou ambulanci,
urgentní příjem, má práva pro vystavování žádanek na magnetickou rezonanci, může definitivně

uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci

• Radiolog Zkušený – lékař se specializovanou způsobilostí, radiolog, má přístupová práva do MPI,

8 přístup do radiologického modulu, může zobrazovat u rozpracovaného pacienta jeho zdravotnickou
dokumentaci tak, jak je specifikováno v ZD, může definitivně uzavírat zdravotnickou dokumentaci,

digitálně podepisovat uzavřenou dokumentaci
• Radiolog Mladý – lékař bez specializované způsobilosti, radiolog, má přístupová práva do MPI,

9 přístup do radiologického modulu, může zobrazovat u rozpracovaného pacienta jeho zdravotnickou
dokumentaci tak, jak je specifikováno v ZD, nemá oprávnění definitivně uzavírat zdravotnickou

dokumentaci, digitálně podepisovat uzavřenou dokumentaci.
• Asistent Radiologický – pozice radiologického asistenta, má přístupová práva do MPI, přístup do
10
radiologického modulu v rozsahu odpovídajícím této pracovní pozici, nemůže přistupovat do popisu

nálezu, nemůže uzavřít radiologickou zdravotnickou dokumentaci.
• Anesteziolog Zkušený – lékař se specializovanou způsobilostí, anesteziolog, má přístupová práva do

MPI, přístup do anesteziologické ambulance pro předoperační vyšetření, ordinace léků pro

11 premedikaci, plánování anestezie u pacientů zařazených do operačního programu, přístup na
chirurgickou JIP, ARO, urgentní příjem, má práva pro vystavování žádanek, může definitivně uzavírat

zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

• Anesteziolog Mladý – lékař bez specializované způsobilosti, anesteziolog, má přístupová práva do

12 MPI, přístup do anesteziologické ambulance pro předoperační vyšetření, ordinace léků pro

premedikaci, plánování anestezie u pacientů zařazených do operačního programu, přístup na

chirurgickou JIP, ARO, urgentní příjem, má práva pro vystavování žádanek, nemůže definitivně

uzavírat zdravotnickou dokumentaci.
• Administrativa Kartotéční – nezdravotník, má přístupová práva do Master Patient Indexu (MPI).

Může přidělovat pacienty do front čekajících na konkrétní ambulantní pracoviště. Může zobrazit v KIS

13 zpřístupněnou historii ošetření pacienta, ale nemůže zobrazovat detailní záznamy ve zdravotnické

dokumentaci (např. číst uzavřené ambulantní zprávy nebo závěrečné zprávy z hospitalizace). Může na

pokyn lékaře vyhledávat termíny a objednávat pacienty na ambulantní vyšetření. Má ale přístup k

funkcionalitám pro radiologii, aby mohla zapisovat diktované záznamy.

• Náměstek Lékařský – lékař se specializovanou způsobilostí, zástupce nejvyššího vedení FN HK,

odborností pediatr, má přístupová práva do MPI, může přistupovat na všechna výkonová střediska

14 nemocnice, zobrazovat přehledy lůžkové kapacity jako na OUM, má přístupné i funkce pro oddělení
nemocniční hygieny; má neomezený přístup do zdravotnické dokumentace pacientů pro její čtení,

nikoliv editaci – při zobrazování jejich výsledků musí být jeho vstup logován.

• Náměstkyně Ošetřovatelská – sestra se specializovanou způsobilostí, zástupce nejvyššího vedení FN

15 HK, má přístupová práva do MPI, může přistupovat na všechna výkonová střediska nemocnice,

zobrazovat přehledy lůžkové kapacity jako na OUM, má přístupné i funkce pro oddělení nemocniční

hygieny; má neomezený přístup do zdravotnické dokumentace pacientů pro její čtení, nikoliv editaci

– při zobrazování jejich výsledků musí být jeho vstup logován.
• Dokumentaristka – nezdravotník, má oprávnění vidět uzavřenou zdravotnickou dokumentaci,

zadávat kódy MKN 10 do účtu pro zdravotní pojišťovny i do výkazu pro ÚZIS. Právo vykazovat

zdravotní výkony včetně ZUM a ZULP, vystavovat poukazy, vykazovat účty za hospitalizaci, provést

opravy, provést finální vyúčtování a finální archivaci zdravotnické dokumentace tak, že po splnění

16 podmínky schválení dokumentace lékařem se specializovanou způsobilostí pro kohokoli definitivně
uzavře proti změnám. Má přístup výhradně ke čtení zdravotnické dokumentace ambulantně

ošetřovaných a hospitalizovaných pacientů; tyto typy dokumentů nesmí editovat, mazat a nemá

oprávnění vytvářet nová ambulantní ošetření nebo dokumentačně zahajovat hospitalizace; její

přístup do dokumentace je logován.

• Dokumentaristka – nezdravotník, má oprávnění vidět uzavřenou zdravotnickou dokumentaci,

zadávat kódy MKN 10 do účtu pro zdravotní pojišťovny i do výkazu pro ÚZIS. Právo vykazovat

zdravotní výkony včetně ZUM a ZULP, vystavovat poukazy, vykazovat účty za hospitalizaci, provést

opravy, provést finální vyúčtování a finální archivaci zdravotnické dokumentace tak, že po splnění

17 podmínky schválení dokumentace lékařem se specializovanou způsobilostí pro kohokoli definitivně
uzavře proti změnám. Má přístup výhradně ke čtení zdravotnické dokumentace ambulantně

ošetřovaných a hospitalizovaných pacientů; tyto typy dokumentů nesmí editovat, mazat a nemá

oprávnění vytvářet nová ambulantní ošetření nebo dokumentačně zahajovat hospitalizace; její

přístup do dokumentace je logován.

18 • Sestra Chirurgická – zdravotní sestra s přístupovými právy role zdravotní sestry kdekoli na
chirurgické klinice včetně oddělení centrálních operačních sálů má přístupová práva do MPI.
• Instrumentářka Chirurgická – zdravotní sestra s přístupovými právy role zdravotní sestry na
19 oddělení centrálních operačních sálů.

20 • Sestra Anesteziologická – zdravotní sestra s přístupovými právy role zdravotní sestry na oddělení

centrálních operačních sálů a do anesteziologické ambulance, má přístupová práva do MPI.

• Hygienička Nemocniční – lékařka, přístup na všechna výkonová střediska nemocnice, ale nemá

neomezený přístup do zdravotnické dokumentace pacientů, kdy může zobrazovat a tisknout

21 mikrobiologické, hematologické, biochemické a patologické výsledky, ambulantní zprávy, epikrízy a

závěrečné zprávy z hospitalizací může číst, případně tisknout, nemá oprávnění texty editovat – při

zobrazování jejich výsledků musí být její vstup logován. Má práva k modulu nemocniční hygieny,

zejména pak k historii hospitalizovaných. Má právo nastavovat alert protiepidemických opatření.

• Doktor Akutní – internista, lékař se specializovanou způsobilostí, má přístupová práva do MPI,

kmenově pracuje na urgentním příjmu, kde z pohledu činnosti KIS může vykonávat všechny činnosti,

22 které ambulantnímu pracovišti stacionářového typu přísluší včetně definitivního uzavírání
ambulantních zpráv a vyúčtování poskytnutých zdravotních služeb; má oprávnění nahlížet do

systému volné lůžkové kapacity a je příjemcem informací KIS o obsazenosti lůžkové kapacity v rámci

kontaktního místa poskytovatele vůči záchranné službě.
• Sestra Akutní – zdravotní sestra s přístupovými právy role zdravotní sestry na urgentním příjmu; má

23 přístup do MPI, má oprávnění nahlížet do systému volné lůžkové kapacity a je příjemcem informací
KIS o obsazenosti lůžkové kapacity v rámci kontaktního místa poskytovatele vůči záchranné službě.

• Neurolog Mladý – lékař bez specializované způsobilosti, neurolog, má přístup do MPI, přístup na

24 všechna pracoviště neurologické kliniky – ambulance, lůžka standardní i JIP, může zobrazovat u

rozpracovaného pacienta jeho zdravotnickou dokumentaci tak, jak je specifikováno v ZD, nemá

oprávnění definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou

dokumentaci.
• Neurolog Zkušený – lékař se specializovanou způsobilostí, neurolog, má přístupová práva do MPI,

25 přístup na všechna pracoviště neurologické kliniky – ambulance, lůžka standardní i JIP, má práva pro
vystavování žádanek na všechna vyšetření, může definitivně uzavírat zdravotnickou dokumentaci,

digitálně podepisovat uzavřenou dokumentaci.
• Sestra Jipecká - zdravotní sestra s přístupovými právy role zdravotní sestry na neurologické JIP, má
26 přístupová práva do MPI.
• Neurochirurg Zručný - lékař se specializovanou způsobilostí, neurochirurg, který má v rámci

27 pracoviště přístup na všechny ambulantní pracoviště, operační sály, lůžkové stanice standardní i JIP

neurochirurgické kliniky. Má přístupová práva do MPI, má práva pro vystavování žádanek na všechna

vyšetření, může definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou

dokumentaci.
• Gynekolog Zkušený - lékař se specializovanou způsobilostí, gynekolog, který má v rámci pracoviště

28 přístup na všechny ambulantní pracoviště, operační sály, lůžkové stanice standardní i JIP a trakt

porodních sálů včetně sekčního sálu pro císařské řezy. Má přístupová práva do MPI, má práva pro

vystavování žádanek na všechna vyšetření, může definitivně uzavírat zdravotnickou dokumentaci,

digitálně podepisovat uzavřenou dokumentaci.
• Asistentka Ambulantní – porodní asistentka se specializovanou způsobilostí s přístupem na příjem
29 těhotných, porodní sály, sál pro císařské řezy, má přístupová práva do MPI,

• Gynekolog Mladý – lékař bez specializované způsobilosti, gynekolog, má přístupová práva do MPI,

přístup na všechna pracoviště gynekologické kliniky – ambulance včetně poraden, lůžka standardní i

30 JIP, porodní sály, operační sály gynekologie, může zobrazovat u rozpracovaného pacienta jeho
zdravotnickou dokumentaci tak, jak je specifikováno v ZD, nemá oprávnění definitivně uzavírat

zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

31 • Asistentka Zkušená – porodní asistentka se specializovanou způsobilostí s přístupem na příjem
těhotných, porodní sály, sál pro císařské řezy, má přístupová práva do MPI.
• Gynekolog Nejmladší – lékař bez specializované způsobilosti, gynekolog, má přístupová práva do

MPI, přístup na všechna pracoviště gynekologické kliniky – ambulance včetně poraden, lůžka

32 standardní i JIP, porodní sály, operační sály gynekologie, může zobrazovat u rozpracovaného pacienta
jeho zdravotnickou dokumentaci tak, jak je specifikováno v ZD, nemá oprávnění definitivně uzavírat

zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

• Gynekolog Vedoucí - lékař se specializovanou způsobilostí, gynekolog, který má v rámci pracoviště

33 přístup na všechny ambulantní pracoviště, operační sály, lůžkové stanice standardní i JIP a trakt

porodních sálů včetně sekčního sálu pro císařské řezy. Má přístupová práva do MPI, má práva pro

vystavování žádanek na všechna vyšetření, může definitivně uzavírat zdravotnickou dokumentaci,

digitálně podepisovat uzavřenou dokumentaci.
• Pediatr Zkušený - lékař se specializovanou způsobilostí, pediatr, který má v rámci pracoviště přístup

na neonatologické oddělení porodního sálu, všechna ambulantní pracoviště, lůžkové stanice

34 standardní i JIP pro větší děti i lůžkové stanice standardní i JIP neonatologického oddělení dětské
kliniky. Má přístupová práva do MPI, má práva pro vystavování žádanek na všechna vyšetření, může

definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

35 • Pediatr Mladý- má přístupová práva do MPI, lékař bez specializované způsobilosti, pediatr, který má
v rámci pracoviště přístup na neonatologické oddělení porodního sálu, všechna ambulantní
36 pracoviště, lůžkové stanice standardní i JIP pro větší děti i lůžkové stanice standardní i JIP
neonatologického oddělení dětské kliniky. Má práva pro vystavování žádanek na všechna vyšetření,
37 ale nemůže definitivně uzavírat zdravotnickou dokumentaci.
• Sestra Dětská - má přístupová práva do MPI, přístupová práva na všechna pracoviště neonatologie,
38 AVZ_000
• Neonatolog Vedoucí - lékař se specializovanou způsobilostí, pediatr, který má v rámci pracoviště
39 přístup na neonatologické oddělení porodního sálu, neonatologickou lůžkovou stanici standardní i
neonatologickou resuscitační JIP dětské kliniky. Má přístupová práva do MPI, má práva pro
40 vystavování žádanek na všechna vyšetření, může definitivně uzavírat zdravotnickou dokumentaci,
41 digitálně podepisovat uzavřenou dokumentaci.
42
43 Na úvod do souboru audiovizuálního záznamu č. 000 účastník zaznamená (ještě před přihlášením do
44 Scénář 001 - Přidělování přístupových práv KIS) v Nastavení systému Windows nastavení rozlišení monitoru na hodnotu 1280x1024; toto
nastavené rozlišení uchazeč použije pro všechny scénáře, které bude zaznamenávat do jednotlivých
Předvedení kompletního procesu přidělení rolí pro uživatele: samostatných AVZ.
Chirurga Zkušeného Na záznamu uchazeč zaznamená postup přihlášení do KIS ze systému Windows, použije účet s
45 neomezenými právy pro administrátora KIS. V čase, který nepřesáhne 15 min., bude prezentovat
nezbytné informace o fungování KIS. Tím je myšleno:
1. vysvětlit uspořádání formulářů na obrazovce a logiku ovládání,
2. popsat orientačním způsobem ovládání funkcionalit KIS pro vytěžování dat zdravotníky,
personálem využívajícím ekonomicko-výkaznické funkce, které pak budou demonstrovány v průběhu
vlastních scénářů.
V závěru scénáře se účastník odhlásí od KIS; ve všech dalších scénářích bude zachyceno přihlašování i
odhlašování jednotlivých rolí do/z KIS.

U Chirurga Zkušeného v rámci scénáře níže předvede uchazeč kompletní proces přidělení rolí nikoliv
de novo, ale právě přenosem od jiných v systému již existujících a oprávněných lékařů, vymezení
rozsahu přístupových práv na konkrétní pracoviště nemocnice a jiné zpřístupněné funkce, které jsou
k problematice relevantní. U Chirurga Zkušeného přístupová práva jiného chirurga, od kterého bude
„dědit“ svá přístupová práva, nezahrnují urgentní příjem.

Chirurg Zkušený – lékař se specializovanou způsobilostí, chirurg, má Jiný chirurg, jehož dosavadní práva budou použita jako vzor pro přidělení práv Chirurgovi Zkušenému,

přístupová práva do Master Patient Indexu (MPI), přístup na standardní již má v KIS přidělena následující oprávnění: lékař se specializovanou způsobilostí, chirurg, má

oddělení, operační sály, chirurgickou JIP, chirurgickou ambulanci, přístupová práva do Master Patient Indexu (MPI), přístup na standardní oddělení, operační sály,

urgentní příjem, má pravomoci primáře ve smyslu plánování operací chirurgickou JIP, chirurgickou ambulanci, má pravomoci pro plánování operací jménem chirurgického

46 jménem chirurgického oddělení výhradně mimo řádnou pracovní dobu oddělení výhradně mimo řádnou pracovní dobu od 15:00-7:00 ve všední dny, má práva pro

od 15:00-7:00 ve všední dny, má práva pro vystavování žádanek na vystavování žádanek na magnetickou rezonanci, může definitivně uzavírat zdravotnickou

magnetickou rezonanci, může definitivně uzavírat zdravotnickou dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

dokumentaci, digitálně podepisovat uzavřenou dokumentaci.

Uchazeč de novo přidá přístupová práva na urgentní příjem fiktivní
nemocnice (bude mít právo pracovat s dokumentací na urgentním
47 příjmu včetně přístupu do MPI, práva uzavírat dokumentaci, digitálně ji
podepisovat a nahlížet na systém zobrazování lůžkové kapacity v
souladu se specifikací v ZD).
Chirurg Zkušený získá také práva ke spravování lůžkového fondu

48 chirurgického standardního oddělení, může přidělovat lůžkům a na nich
uloženým pacientům atributy, pomocí nich i uzavřít část kapacity

lůžkového oddělení.
49 Scénář 002 - Scénář práce s pacientem na vstupu k vyšetření v kartotéce a v ambulanci včetně kontextové nápovědy

Administrativa Kartotéční v rámci centrální recepce zadá pacienta do

50 Master Patient Indexu s kompletním přehledem všech požadovaných
položek.

51 Pracoviště má 5 chirurgických ambulancí.

52 Marod Zažívací není objednán, ale žádanku z gastroenterologie má.
Není označen jako akutní pacient.
Po kontrole údajů jej nejsnazším postupem, který KIS umožňuje, zařadí
53 do fronty objednaných pacientů na ošetření na ambulantní pracoviště

chirurgie.
Administrativa Kartotéční co nejjednodušším postupem přidělí pacienta Uchazeč kromě našeho vzorového pacienta bude mít připraveno alespoň 7 dalších testovacích

54 z fronty objednaných do fronty čekajících v chirurgické ambulanci č. 3. pacientů čekajících na ošetření v chirurgické ambulanci č. 3, z toho 3 pacienti budou akutní bez
předchozího objednání či doporučení.

Sestra Chirurgická po přihlášení do KIS zvolí jako své pracoviště Na obrazovce sestry uchazeč postupně ukazatelem myši zobrazí ve směru zleva do prava a seshora

chirurgickou ambulanci č. 3, sleduje pracovní plochu a frontu čekajících dolů všechny ikony KIS umístěné v horizontálním ovládacím panelu na horním okraji pracovní plochy

55 pacientů na chirurgické ambulanci č. 3. tak, aby KIS zobrazil kontextovou nápovědu, každá nápověda bude zobrazena alespoň 2 s. Pokud jsou

některé ovládací prvky zastoupené ikonami v ovládacím a informačním panelu umístěném i podél

levého, pravého i dolního okraje pracovní plochy, provede pohyb a zobrazení kontextových nápověd

analogicky. Pracovní obrazovku pouze prohlíží - nerozbaluje žádné menu, nespouští žádnou akci.

Sestra Chirurgická předvede možnosti řazení čekajících pacientů pomocí Uchazeč ukáže řazení alespoň podle:

56 názvů sloupců • příjmení,

• data narození či rodného čísla,

• času registrace,

57 • ne-/objednané
Je-li možné frontu pacientů i filtrovat podle libovolných kritérií, uchazeč ukáže a okomentuje všechny

v tuto chvíli dostupné možnosti filtrování zobrazených informací při práci s frontou pacientů

zařazených k vyšetření.
58 Scénář 003 - Scénář práce lékaře s pacientem při vyšetření v ambulanci, vystavování žádanek na zobrazovací vyšetření

Pacient v minulosti v nemocnici už byl 5x hospitalizován na ORL, mezi jednotlivými hospitalizacemi byl

opakovaně ambulantně vyšetřen na interně (1x), neurologii (2x), očním (5x v různých termínech) a

gastroenterologii, každá hospitalizace byla s rtg nebo CT vyšetřením, při každé ambulantní návštěvě

59 byl odběr biochemie a krevního obrazu – veškeré související dokumenty byly pořízeny v

předváděném KIS.

Pacient nesouhlasí s přítomností mediků a účastí na výuce - je již nastaven neveřejný alert.

Při hospitalizaci na ORL v minulosti byl do Rodinné anamnézy zaznamenán následující údaj:

„Otec + 77 let na 3. infarkt myokardu, léčil se s cukrovkou. Matka žije, narozena 1936, je po cévní

mozkové příhodě. Bratr pacienta žije, je zdráv.“
Chirurg Mladý si vybere Maroda Zažívacího na vyšetření do ambulance.

Ve zdravotnické dokumentaci v anamnéze zobrazí text z

60 gastroenterologické poradny a převezme jej do své ambulantní zprávy k
další editaci.

Chirurg Mladý zjistí anamnesticky alergii na jód – ekzém a provede
61 záznam do ambulantní dokumentace.

Chirurg Mladý doplní do ambulantní zprávy objektivní nález vyšetření. V systému jsou pomocí funkce vkládání předdefinovaných textů připraveny položky pro výběr pro

Texty dodané pomocí Lupy upraví - do „nálezu na břiše“ zapíše toto okno volného textu, které umožní zapsat alespoň „stav vědomí“, „nález na hrudníku“, „nález na
62 následující text: „hmatná rezistence v levém dolním kvadrantu“.
břiše“.

63 Text nálezu na břiše vložený v předchozím bodu do okna volného textu ambulantní zprávy uchazeč

zvýrazní tučným písmem a změnou fontu na jakýkoli jiný, než jakým je zapsán předchozí text.

64 Uchazeč v tomto okně volného textu ukáže i možnosti měnit velikost písma u "stavu vědomí" na

velikost 18 tiskových bodů, poté text "nálezu na hrudníku" zmenší na nejmenší dostupnou velikost

textu v souladu se zadávací dokumentací.
Uchazeč v tomto okně volného textu ukáže i možnosti použití klávesových zkratek u "stavu vědomí"

následovně: Ukazatel myší umístí do okna volného textu tak, aby bylo okno aktivní. Poté ukazatel

myši bez kliknutí přemístí mimo toto okno na pracovní ploše tak, aby ukazatel zůstal zobrazený.

65 Pomocí klávesnice uchazeč označí text "nálezu na hrudníku", nadiktuje/zobrazí v AVZ klávesovou

zkratku a text pomocí klávesové zkratky vyjme. Umístí kurzor do okna pro záznam volného textu

rodinné anamnézy a opět ukazatel myši umístí mimo toto okno, aby ukazatel zůstal zobrazený.

Šipkami najede na začátek textu v okně rodinné anamnézy, nadiktuje/zobrazí v AVZ klávesovou

zkratku a pomocí klávesové zkratky text vloží.

V rámci objektivního nálezu Chirurg Mladý zadá výšku pacienta 185 cm,
66 hmotnost pacienta 100 kg, TK 135/80, TF 68/min, DF 16/min

Chirurg Mladý vystaví žádanku na CT břicha s kontrastem. Uchazeč postupně okomentuje přenesení v KIS dostupných informací o pacientovi do žádanky na
zobrazovací vyšetření a vyplní povinné položky dle požadavků zadavatele. Chirurg zobrazí plánovací
67 Na žádance na CT bude uveden následující text: „Pacient s údajem kalendář CT radiologie, ale nebude mít oprávnění přímo obsadit konkrétní termín.
občasného krvácení vzhledu enterorhagie z konečníku.“

Chirurg Mladý vystaví žádanku na rtg srdce a plic vstoje zadopřední (PA) Uchazeč postupně okomentuje přenesení v KIS dostupných informací o pacientovi do žádanky na

68 + L bočný. zobrazovací vyšetření a vyplní povinné položky dle požadavků zadavatele. Chirurg zobrazí plánovací
kalendář skiagrafie a bude mít oprávnění přímo obsadit jakýkoli termín.
Chirurg Mladý vystaví žádanku na ultrazvuk břicha. Zobrazení plánovacích kalendářů pro CT, skiagrafii a UZ najednou, termín pro UZ musí být buď v jiný
Na žádance bude uveden následující text: „Žádám o předoperační UZ den než CT, nebo mu musí ve stejném dnu předcházet. Uchazeč postupně okomentuje přenesení v
břicha v následujícím týdnu kvůli plánování operace.“ KIS dostupných informací o pacientovi do žádanky na zobrazovací vyšetření a vyplní povinné položky
69 dle požadavků zadavatele. Chirurg uvidí plánovací kalendář UZ radiologie a bude mít pro chirurgické
pracoviště vyhrazené časy s možností přímo obsadit konkrétní termín.

70 Radiolog Zkušený provede a zapíše pouze nález UZ vyšetření břicha,
který uzavře jako definitivní a vykáže zdravotní pojišťovně.
Chirurg Mladý si zobrazí přehledovou tabulku o naplánovaných a Provede posun po jednotlivých položkách v tabulce na nejstarší vyšetření či hospitalizaci směrem do
71 uskutečněných vyšetřeních pacienta.
minulosti. Uchazeč předvede a popíše co nejrychlejší v KIS dostupný způsob rychlého návratu k

vyšetřením s aktuálním datem.
Chirurg Mladý zapíše nález a objedná pacienta na další kontrolu v Do okna volného texu nálezu ambulantní zprávy vloží libovolné texty, třeba i s použitím lupy, ale s
72 chirurgické ambulanci s výsledky všech objednaných vyšetření.
tím, že text zprávy bude (včetně vkládání konce odstavců) dosahovat alespon 20 řádků pod sebe, aby

Chirurg Mladý provede zápis do ambulantní dokumentace. Zapíše bylo patrné chování okna pro záznam volného textu.

diagnózu C18.7 a text "Karcinom tlustého střeva v sigmoideu" bez

ohledu na to, jaký text dodal KIS. V ambulantní zprávě vyplní i
73 parametrická pole pro klasifikaci zhoubných nádorů T1N0M0. Pacientovi

objednává další návštěvu v chirurgické ambulanci s odstupem 10 dnů.

Současně s dokončením zprávy provede za podpory KIS vyúčtování
74 komplexního vyšetření chirurgem, ale vědomě nevykáže kód „poplatku

09543-signální výkon“. Účastník nejdříve popíše všechny možné způsoby uzavření zprávy a vyřazení pacienta z fronty
Chirurg Zkušený uzavírá návštěvu pacienta a vyřazuje jej z fronty

rozpracovaných. rozpracovaných. Účastník následně okomentuje a poté předvede uzavření zprávy a vyřazení pacienta

z fronty nejrychlejším možným způsobem. Pokud uchazeč může použít jednu klávesovou zkratku pro

současné uzavření zprávy a vyřazení pacienta z fronty, následuje popis klávesové zkratky a ukazatel

75 myši na na pracovní ploše v tento okamžik zůstává v klidu, stiskem klávesové zkratky uchazeč zprávu
uzavře a pacienta vyřadí. Pokud taková klávesová zkratka neexistuje, uchazeč demonstruje

požadovanou činnost s použitím myši. Pokud uchazeč sdruženou funkci pro uzavření zprávy a

vyřazení pacienta z fronty v KIS nemá, oznámí to a uzavření návštěvy a vyřazení pacienta z fronty

rozpracovaných provede nejrychlejším způsobem postupným použitím ovládacích tlačítek/ikon.

76 Scénář 004 - Scénář práce sestry se žádankami a zobrazování výsledků

Sestra Chirurgická po přihlášení do KIS zvolí jako své pracoviště

77 chirurgickou ambulanci č. 3, sleduje pracovní plochu a frontu čekajících
pacientů na chirurgické ambulanci č. 3.

78 Sestra Chirurgická si pro další práci zvolí Maroda Zažívacího.

Sestra Chirurgická vystaví žádanku na laboratorní vyšetření: Protože neexistuje integrované propojení s laboratorním komplementem FN HK, uchazeč si v KIS

krevního obrazu, předem připraví soubor hodnot požadovaných laboratorních vyšetření (bude jimi simulovat dodání

vyšetření moče chemicky a sediment, výsledků laboratorním informačním systémem směrem do KIS). Archiv výsledků Maroda Zažívacího v

79 biochemické vyšetření séra – urea, krea, urikémie, Na, K, Cl, bil celkový, KIS nebude prázdný – navíc bude u každého z aktuálně požadovaných typů laboratorních vyšetření (s
bil konjugovaný, ALT, AST, LDH, ALP, glu, celkový protein, albumin, CRP, výjimkou krevní skupiny) obsahovat minimálně tři další hodnoty z minulosti - viz scénář výše.

INR, poměru APTT, fibrinogenu,

vyšetření krevní skupiny.

80 Scénář 005 - Scénář plánování operace z ambulantního provozu

81 U Maroda Zažívacího jsou v KIS k dispozici výsledky všech výše objednaných laboratorních i
zobrazovacích vyšetření ze scénářů uvedených výše.
82 Datum v KIS se posunulo o 10 dnů dopředu oproti předchozí ambulantní návštěvě.

Pacient se dostaví na recepci jako objednaný pacient na chirurgickou

83 ambulanci. Administrativa Kartotéční jej vybere z fronty plánovaných
pacientů do stejné chirurgické ambulance č. 3.

Chirurg Zkušený zobrazí svou pracovní obrazovku pacientů zařazených k
84 vyšetření do ambulance č. 3. Vybere si k práci Maroda Zažívacího.

Chirurg Zkušený si zobrazí tabulku plánovaných a již provedených
85 vyšetření, z ní přejde k textovým popisům UZ břicha a CT břicha - oba

zobrazí a výsledky zkopíruje do nálezu své ambulantní zprávy.
Z ambulance provede plánování termínu hospitalizace a předběžné
86 zařazení pacienta do fronty plánovaných pro operační řešení.

87 Chirurg Zkušený vystaví žádanku do anesteziologické ambulance pro
předanestetické vyšetření na konkrétní termín.
Anesteziolog Mladý najde pro pacienta náhradní termín ve stejný čas, Pacientovi není možné v objednaném termínu provést anesteziologické konzilium z důvodu chybění
88 ale následující den a provede jeho přeobjednání. volné kapacity anesteziologů.

Pacient má anamnézu „velmi obtížné intubace“, proto Anesteziolog
89 Mladý provede aktivaci veřejného alertu pro ostatní kolegy.

Anesteziolog Mladý provede vyúčtování anesteziologického konzilia vůči
90 zdravotní pojišťovně.

91 Scénář 006 - Scénář přijetí k hospitalizaci Datum v KIS se posunulo o 14 dnů dopředu oproti předchozí ambulantní návštěvě.
92
Uchazeč pro účely ukázky připraví následující situaci:

Chirurgická klinika má standardní oddělení s následující strukturou a obsazeností:

Pokoj .č 1 a 2 je jednolůžkový, na jednom z pokojů bude hospitalizovaný pacient, který bude mít

izolační režim, druhý pokoj bude obsazený pacientem bez zvláštního atributu; pokoje jsou v systému

považovány jako bez rozlišení pohlaví hospitalizovaných.

Pokoje č. 3-6 jsou dvojlůžkové. Na pokoji č. 5 je přijata žena v izolačním režimu, druhé lůžko na pokoji

93 je neobsazené. Pokoj č. 3 je plně obsazen. Pokoj č. 6 je volný a je na něm umístěna 1 přistýlka. Na

pokoji č. 4, lůžku č. 1 je již hospitalizován mužský pacient Pepa Tuberkulózní, který byl na chirurgii

přeložen den před přijetím Maroda Zažívacího z plicního oddělení, kde byl hospitalizován celkem 4

dny na trojlůžkovém pokoji s dalšími 2 pacienty – Karlem Dýchavičným a Frantou Cyanotickým.

Pokoje č. 7 a 8 jsou trojlůžkové, na pokoji č. 7 jsou hospitalizováni dva muži.

Chirurgická klinika má JIP o 6 lůžkách, 5 z nich je obsazených, 2 pacienti mají zavedený izolační režim;

lůžka nerozlišují pohlaví hospitalizovaných. Dospávací pokoj má 4 lůžka; lůžka nerozlišují pohlaví

hospitalizovaných.

Sestra Chirurgická na své pracovní obrazovce zobrazí přehled Uchazeč ukáže a okomentuje postupně všechny dostupné pohledy na standardní oddělení chirurgie -
standardního chirurgického oddělení. nejdříve tabelární, následně grafické. U každé z variant vždy okomentuje způsob zobrazení informací
94 o hospitalizovaných pacientech včetně největšího dosažitelného informačního detailu, které lze při
zobrazení oddělení jako celku o pacientech podat, pro tento účel nebude otvírat informace o
95 Sestra Chirurgická přijímá pacienta na pokoj č. 4, lůžko č. 2. pacientech jednotlivě. U každé z variant také okomentuje způsob zobrazení atributů pacientů anebo
jednotlivých neobsazených lůžek.
Uchazeč akci předvede nejrychlejším z výše předvedených způsobů.

Sestra Chirurgická provede ošetřovatelský příjem. Pacienta zváží - 98 kg,

změří - 185 cm, změří i TK 138/88 a TF 74/min, DF 16/min. Zaznamená v

96 rámci ošetřovatelských kategorií normu s výjimkou vyprazdňování, kde
uvede i průjem a občasnou inkontinenci stolice.

Chirurg Mladý provede kompletní lékařský příjem. Anamnézu v Do všech oken pro volný text vloží vždy nějaké uchazečem připravené texty z číselníku textů (mohou

maximálním možném rozsahu přebere z dostupných informací v KIS, v být i významově nesmyslné ve vztahu ke konkrétnímu případu); pouze v oddíle osobní anamnéza

anamnéze nynějšího onemocnění napíše: "Pro anamnézu střídání zácpy budou ty texty alespoň 3 a každý z nich bude alespoň na 3 řádky.

a průjmu a občasného výskytu krve na stolici podrobně vyšetřen se Uchazeč předvede funkci historie v oknech pro záznam volného textu – jako optimální místo pro

závěrem podezření na zhoubný novotvar tračníku. Přichází k plánované ukázku využije rodinnou anamnézu.

operaci."

97 Farmakologická anamnéza, kde chirurg zadá následující léky:
• Atoris 20 mg p. os. 1-0-0,

• Furon 40 mg p. os 1-1-0,

• Ibuprofen AL 400 mg p. os 1-0-1 při bolesti,

• Volteren gel lokálně dle potřeby na P koleno

• Lantus Solostar inzulín s.c. 6-0-16 j.s.c.

• Oční kapky – název si nepamatuje – do OPL 1-0-1, poté zápis uloží a

uCzhairvuřreg. Mladý provede objektivní vyšetření s podporou KIS, alespoň 1 z Vkládání textů pro jednotlivé tělesné krajiny (alespoň 2 z nich) z šablon předdefinovaných textů.

nich jakkoli upraví (slovo umaže nebo slovo vloží). Po každém vložení

98 popisu pro konkrétní tělesnou krajinu záznam průběžně uloží. Nakonec
uloží finální objektivní vyšetření a uzavře jej.

Chirurg Mladý vyplní příjmovou Epikrízu. Do Plánu další péče bude
zapsáno: „Naplánována standardní příprava před operací, premedikace
dle ordinace anesteziologa.“ Pacient bude mít standardní hygienický
99 režim, žádnou umělou plicní ventilaci. Po dokončení Epikrízu uzamkne
proti editaci (tj. v případě aktualizace Epikrízy ve stejném kalendářním
dnu vznikne její nová varianta), uloží a uzavře.

Chirurg Mladý v návaznosti vytvoří lékařský dekurz. Zadavatel pro účely hodnocení vzorku vyžaduje tu variantu dekurzu, kde všechny položky dekurzu

• Bude ordinovat dietu 0s – čajovou podle zadávací dokumentace včetně ordinace léčivých přípravků budou na jednom listu.

• Režim pohybu po oddělení „C“

• Hygienický režim „S“ – standardní

• Do záznamu vizity napíše: „Přijat a vyšetřen k plánované operaci.“

• Přistoupí k ordinaci léků.

• Oční kapky neznámého názvu smaže a nahradí ordinací – napíše

přesně řetězec „dorzolamidum“, pokud KIS začne nabízet léčivé
100 přípravky, zvolí Trusopt 1-0-1 OPL. Pokud KIS nebude reagovat na název

generika, začne psát obchodní název „Trusopt“. Jedná se o N-položku!

• Inzulín Lantus vysadí a nahradí ordinací Humulin R 4-4-4 j.s.c.

• Začne psát přesně řetězec „Trit“. Nabídne-li se seznam preparátů s

obsahem látky, zvolí Tritace 2,5 mg 1-0-0.

Na obrazovce lékaře sloužící k vytvoření dekurzu uchazeč postupně ukazatelem myši zobrazí ve

směru zleva do prava a seshora dolů všechny ikony KIS umístěné v horizontálním ovládacím panelu

101 na horním okraji pracovní plochy tak, aby KIS zobrazil kontextovou nápovědu, každá nápověda bude

zobrazena alespoň 2 s. Pokud jsou některé ovládací prvky zastoupené ikonami v ovládacím a

informačním panelu umístěném i podél levého, pravého i dolního okraje pracovní plochy, provede

pohyb a zobrazení kontextových nápověd analogicky. Pracovní obrazovku pouze prohlíží - nerozbaluje

Hotový dekurz uloží a zobrazí náhled před tiskem. žádné menu, nespouští žádnou akci.
Rozměr zobrazovaného náhledu uchazeč nastaví tak, aby byla maximálním možným způsobem

102 využita šířka dostupné pracovní plochy a list A4 náhledu při tisku svými okraji dosahoval co nejblíže
okrajům pracovní plochy, uchazeč pak bude text pomalu rolovat shora dolů tak, aby byl list A4

Chirurg Zkušený se právě dozvěděl o nedostatku sester – trojlůžkový postupně celý zobrazen na pracovní ploše.
pokoj č. 8 uzavírá z personálních důvodů.
103

104 Scénář 007 - Scénář správy operačních sálů, plánování a uskutečnění operací
Operatér Centrální předvádí správu společného traktu 6 operačních sálů Operatér Centrální spravuje trakt 6 operačních sálů, na kterých nejsou před soutěžní ukázkou vzorku
105 dle instrukce.
provedena žádná další nastavení.

106 Uchazeč předvede administraci operačních sálů, kterou má Operatér Centrální k dispozici:

• Pro potřeby chirurgické kliniky vyčlení sály 1-3 na celou pracovní dobu
107 7:00-15:00. Na sále č. 4 vyčlení kapacitu pro chirurgii od 7:00 do 11:00

každý den.
• Ve středu Operatér Centrální na sále č. 2 nařídí sanitární den a uzavře
108 jej pro plánovaný provoz.

109 • Operatér Centrální nastaví délku technologické pauzy mezi výkony na
20 min.
Operatér Centrální pomocí nástroje obecného dotazu zobrazí počet Uchazeč má v databázi KIS připravenou situaci, kdy pro každý sál je vyčleněný alespoň 1 sanitární den

sanitárních dnů na jednotlivých operačních sálech v traktu operačních v intervalu zhruba 2 měsíců.
110 sálů za poslední kalendářní rok. Selektivně ze seznamu pomocí funkce

řazení vybere ty dny, kdy byl sanitární den na sále č. 1.

Chirurg Zkušený přijatého pacienta naplánuje k výkonu na středu, zapíše Uchazeč předvede a okomentuje všechny dostupné způsoby, kterými je chirurg při plánování operací

veškeré údaje – operační tým lékařů, požadavek na speciální upozorněn na překročení řádné pracovní doby operačních sálů, předvede a okomentuje funkcionality

instrumentárium, které za chirurgické pracoviště má vyplňovat do bránící naplánování takového výkonu.

podrobného plánu operací na sál č. 3, výkon laparoskopicky asistovaný,

délka plánována na 180 min. Nejdříve zkusí operaci naplánovat na sál č.
111 1. Operační program pro sál č. 1 je již téměř zaplněn jinými operacemi,

do konce pracovní doby zbývá pouze 120 min. čistého času a KIS jej

minimálně na tuto časovou kolizi upozorní. Chirurg Zkušený si proto ve

finále vybere sál č. 3 zpřístupněný chirurgické klinice. Tím se Marod

Zažívací dostane do operačního programu.

Operatér Centrální si zobrazí plánovací kalendář sálů včetně detailů Očekáváme ukázku a komentář všech možností KIS, jak se k takové situaci systém může zachovat - od

jednotlivých, už naplánovaných výkonů. U operace Maroda Zažívacího upozornění (jeho forma?), nabídku přeuspořádání výkonů na sálech dle plánované délky až po

112 provede přeplánování výkonu na sál č. 1 jako druhý výkon, dobu trvání zablokování takové změny - a nabídku možností, jak se může chovat osoba s oprávněním primáře
výkonu zachová. Tím nastane situace, kdy dosud plánovaný program operačních sálů.

začne přesahovat řádnou pracovní dobu a je na to systémem

upozorněn.
Operatér Centrální prohlíží náhled na všechny operační sály pro dnešní Je den před dnem operace (D-1). Uchazeč má na tento den připravené pacienty a obsazené funkční

den (D-1), sleduje výkony již provedené, výkony již probíhající a operační sály jednotlivými operacemi tak, že původní plán u sálů 1, 2, 3, 5 a 6 kompletně vyčerpal

případný posun dosud neprovedených plánovaných operací oproti standardní pracovní dobu od 7:00 do 15:00 hod. Volná kapacita zůstává jen na sále č. 4 od 11:30 hod.

původnímu plánu (zejména ve vztahu ke konci řádné pracovní doby). V
113 plánu operací uvidí další časové posunutí výkonů na sále č. 1, a proto se

rozhodne poslední plánovaný výkon ze sálu č. 1 přesunout na dosud

neobsazený sál č. 4 do dopoledních hodin.

Operatér Centrální ve 12 hod. uzavře plán operací pro požadavky ze Uchazeč připraví alespoň 3 další naplánované operace na různé sály a mohou být i pro různé obory,
stran operačních oborů. U Maroda Zažívacího stanoví, že instrumentuje kde ukáže a okomentuje škálu detailů, které je možné k operacím v KIS zadat.
Instrumentářka Chirurgická, obíhací sestrou bude Sestra Chirurgická.
114 Operatér centrální si prohlédne kompletní plán operací na následující
den, otevře 1 další plánovanou operaci.

Hotový plán operačních výkonů dostane k dispozici Anesteziolog Uchazeč zobrazí a okomentuje způsob upozornění na alergii pacienta a na riziko obtížné intubace.
Zkušený, aby mohl zaplánovat anesteziologický servis pro oddělení Je den operace (D).
centrálních operačních sálů.
115 U Maroda Zažívacího si všimne údaje o plném zajištění pacienta 3
vstupy a upozornění na alergii a obtížnou intubaci.
Anestézii bude podávat Anesteziolog Zkušený se Sestrou
Anesteziologickou.

116

Sestra Chirurgická předá Sestře Anesteziologické pacienta – je

117 zaznamenán čas předání pacienta na operační sál v rámci Oddělení
operačních sálů.

Anesteziolog Zkušený zahájí svou práci – zaznamená se čas začátku – a
118 za 15 minut je pacient kompletně připraven k zahájení operace.

Přichází oba Chirurgové a zahajují svou práci – záznam času zahájení

119 práce chirurgického týmu.
Zaznamená se čas řezu.

Operace je úspěšně skončena, zaznamená se čas ukončení operace.
120

Anesteziolog Zkušený extuboval pacienta a připravil jej na předání na
121 pooperační pokoj. Je zaznamenán čas ukončení práce anesteziologa.

Anesteziolog Zkušený stanovil sledování po operaci v délce 120 min.
122

Po převezení pacienta na pooperační pokoj, tj. ambulantní pracoviště
stacionářového typu, je zaznamenán čas předání pacienta z operačního
123 sálu. Současně s tímto okamžikem začíná práce Chirurga Mladého na
operačním protokolu.
PC2 - Chirurgovi Mladému při zahájení editace OP se nabídne Rozměr zobrazovaného náhledu uchazeč nastaví tak, aby byla maximálním možným způsobem

předvyplněný formulář operačního protokolu s přenesenými využita šířka dostupné pracovní plochy a list A4 náhledu při tisku svými okraji dosahoval co nejblíže

parametrickými údaji, které byly nashromážděny prostřednictvím KIS v okrajům pracovní plochy, uchazeč pak bude text pomalu rolovat shora dolů tak, aby byl list A4
124 předešlém čase a mají vztah k operaci. Automaticky přenesené položky postupně celý zobrazen na pracovní ploše.

lze editovat - uchazeč předvede při úpravě načtených zdravotnických

prostředků. Dokončený operační protokol Chirurg Mladý zobrazí jako

náhled před tiskem. Uchazeč ukáže a okomentuje tvorbu výkazu pro účely vyúčtování péče, okomentuje kontroly a
Po dokončení operačního protokolu Anesteziolog Mladý provede

125 kompletní vykázání operačního výkonu včetně anestézie (zahrnuje i automatické funkce, kterými je tvorba výkazu v KIS vybavena.
výkaznictví ZUM, ZULP). Výkaz ponechá otevřený.

Na obrazovce lékaře sloužící k vyúčtování péče na operačním sálu uchazeč postupně ukazatelem myši

zobrazí ve směru zleva do prava a seshora dolů všechny ikony KIS umístěné v horizontálním

ovládacím panelu na horním okraji pracovní plochy tak, aby KIS zobrazil kontextovou nápovědu,

126 každá nápověda bude zobrazena alespoň 2 s. Pokud jsou některé ovládací prvky zastoupené ikonami
v ovládacím a informačním panelu umístěném i podél levého, pravého i dolního okraje pracovní

plochy, provede pohyb a zobrazení kontextových nápověd analogicky. Pracovní obrazovku pouze

prohlíží - nerozbaluje žádné menu, nespouští žádnou akci.

Chirurg Mladý 2. den po operaci propouští Maroda Zažívacího domů a V době psaní zprávy jsou k dispozici všechny výsledky vyšetření, o kterých se ve výše uvedených

vytváří kompletně všechnu listinnou agendu k tomu nutnou podle scénářích jednalo. Uchazeč tedy předvede způsob výběru výsledků vyšetření z laboratorního

požadavků zadavatele: komplementu i ostatních typů vyšetření a konzilií, předvede a okomentuje způsob jejich vložení do

• Statistické hlášení o hospitalizaci včetně všech kódů požadovaných závěrečné zprávy, její editaci včetně plného rejstříku grafických úprav textu pomocí textového
127 ÚZIS.
editoru KIS v souladu se zadávací dokumentací. Uchazeč do sekce Doporučení vloží dvě různé položky

• Závěrečnou propouštěcí zprávu se všemi náležitostmi dle požadavků výběrem z dostupného uživatelského číselníku textů. Uchazeč okomentuje a ukáže omezení Chirurga

zadavatele. Mladého, které mu neumožní uzavřít zprávu jako definitivní.

V průběhu editace závěrečné zprávy si Chirurg Mladý text několikrát

průběžně uloží. Rozměr zobrazovaného náhledu uchazeč nastaví tak, aby byla maximálním možným způsobem
Chirurg Zkušený zkontroluje dokumentaci vytvořenou Chirurgem

128 Mladým. Závěrečnou zprávu uzavře jako definitivní a zobrazí náhled využita šířka dostupné pracovní plochy a list A4 náhledu při tisku svými okraji dosahoval co nejblíže
před tiskem. okrajům pracovní plochy, uchazeč pak bude text pomalu rolovat shora dolů tak, aby byl list A4

Náměstek Lékařský v rámci stížnostní agendy na dlouhé čekací lhůty na postupně celý zobrazen na pracovní ploše.

operaci si prohlíží seznam hospitalizovaných na Chirurgické klinice v

posledním měsíci a namátkou si vybere Maroda Zažívacího, aby se

129 podíval na oprávněnost relativně akutní indikace k operaci. Zobrazí
poslední ambulantní vyšetření z chirurgické ambulance a kompletní

příjmovou dokumentaci z hospitalizace.

130 Scénář 008 - Scénář obecného dotazu zdravotnických pracovníků

Ve vzorku pacientů připravených pro soutěžní ukázky má uchazeč zavedeno minimálně 15 pacientů s

131 diagnózou C18.- léčených na kterémkoli pracovišti fiktivní nemocnice. Z těchto 15 pacientů bylo 10
vyšetřeno v posledním roce na chirurgii. V posledním roce bylo operováno 8 pacientů, 2 z nich už

zemřeli.
Chirurg Mladý spustí formulář pro zadání obecného dotazu a za poslední Prezentující osoba spustí požadovaný nástroj pro zadání obecného dotazu k vytěžení informací z KIS,

kalendářní rok vyhledává sestavu pacientů, u kterých byla pouze na který je určen pro běžného uživatele v souladu se zadávací dokumentací, tj. nepotřebuje znát

132 pracovištích chirurgie zadána diagnóza C18.-, tzn. různé lokalizace specifický jazyk pro vytěžování dat z databáze. Názorně provede a okomentuje zadání
karcinomu tlustého střeva. specifikovaných parametrů pro vyhledávání, které charakterizují množinu hledaných případů a spustí

provedení zadaného dotazu tak, aby získal výpis pacientů splňujících kritéria vyhledávání.

133 Vrácený seznam pacientů řadí dle záhlaví sloupců a namátkou si dva z
těchto pacientů vybere.
Přejde do archivované zdravotnické dokumentace v KIS u pacientů Uchazeč předvede a okomentuje jím zvolený přístup k odůvodnění nahlížení na zdravotní záznamy

134 zvolených v předchozím kroku, jako důvod nahlédnutí zadá či zvolí z osob, u kterých aktuálně nedochází k poskytování zdravotních služeb.
rolovacího seznamu (záleží na způsobu řešení funkce uchazečem)

"doplňování údajů do registrů".
Jeden z pacientů ze seznamu získaného v předchozím bodu již zemřel -
135 uchazeč jej zvolí a předvede, jakým způsobem je úmrtí pacienta v KIS

zaznamenáno.
Chirurg Mladý opět spustí formulář pro zadání obecného dotazu,

136 vyhledá bez časového omezení do minulosti všechny pacienty s kódem
C18.- na kterémkoli pracovišti libovolné fiktivní nemocnice a seřadí je

dle data ošetření a dle pracoviště ošetření.
Chirurg Mladý se pokusí některý z obdržených záznamů z jiného
137 pracoviště než chirurgie otevřít pro potřeby nahlédnutí pro vědecké

účely.
138 Scénář 009 - Scénář porodu dvojčat

Uchazeč připraví do souboru pacientů pacientku Rodičku Rizikovou, aktuálně jí je 35 let. Jedná se o

ženu, která má v anamnéze 1x spontánní potrat a 2 předchozí porody. První porod byl fyziologický

záhlavím, narodil se chlapec. Druhý porod před 2 lety od soutěžní ukázky byl císařským řezem pro

patologii plodu, narodilo se děvče. Pacientka mezi 18.-20. rokem života užívala hormonální

antikoncepci. Je vdaná, manželovi je 37 let a v osobní a rodinné anamnéze není žádná známá

geneticky přenášená choroba. Manžel je zdravý. Rodička Riziková po spontánním potratu trpěla

významnou úzkostí a byla vyšetřována na psychiatrické klinice fiktivní nemocnice, kam docházela 1

139 rok na celkem 4 kontroly. Rodička Riziková je diabetička na inzulínu, užívala Humulin R 16-12-12-0

j.s.c., Lantus Solostar 0-0-0-8 j. s.c. Neužívá pravidelně jiné léky. Nemá žádnou známou alergii.

Gynekolog Zkušený je lékař se specializovanou způsobilostí, který má v rámci pracoviště přístup na

všechny ambulantní pracoviště, operační sály, lůžkové stanice standardní i JIP a trakt porodních sálů

včetně sekčního sálu pro císařské řezy.

Rodička Riziková chodila do rizikové poradny na gynekologickou kliniku zadavatele už před 2.

porodem – její ambulantní i porodnická dokumentace je tedy v KIS dostupná.

Oddělení fyziologických novorozenců má 3 dvoulůžkové pokoje ve fyzické struktuře lůžkového fondu.

Neonatologická JIP má 4 inkubátorová lůžka pro novorozence.
Dětská klinika má pro matky k dispozici 4 dvoulůžkové pokoje pro hospitalizaci doprovodů.

V prezentovaném scénáři Rodička Riziková absolvovala primotrimestrální screening u svého

140 registrujícího gynekologa. V té době nebyly zaznamenány žádné patologické jevy. Ve 30. týdnu

těhotenství ji registrující gynekolog odesílá do rizikové poradny gynekologické kliniky jen pro jistotu,

těhotenství stále probíhá jako fyziologické.

Gynekolog Zkušený ji přebírá do péče rizikové poradny. Zadá datum

primotrimestrinálního screeningu do KIS pro stanovení intervalů dalších

ambulantních kontrol rodičky a s podporou KIS objedná alespoň

141 následnou kontrolu. Rodička Riziková má bichoriální – biamniální
dvojčata, na kterých není zjevná žádná patologie. Provede zápis všech

dostupných informací včetně využívání funkce historie pro okna volného

textu. Zkontroluje předchozí historii všech vyšetření v nemocnici.

Zkontroluje automaticky přenesené parametrické údaje, které
zaktualizuje. Humulin R má nyní v dávkování 14-14-14-0 j. s.c. a Lantus
142 Solostar v dávce 0-0-0-10 j.s.c. Ambulantní vyšetření uzavře a provede
vykázání pojišťovně s maximální mírou automatizace výkaznictví.

V 38+3 – je to všední den - se začnou objevovat porodní bolesti v 10 hod. dopoledne. Postupně

143 začnou být pravidelné s odstupem mezi kontrakcemi 10 min. Protože si je Rodička vědoma rizik u
porodu dvojčat a nechutná jí jíst, z obav z možné hypoglykémie přijíždí na příjem rodiček

Gynekolog Mladý provede veškeré lékařské úkony nezbytné u příjmu gynekologické kliniky ve 13 hod. odpoledne.

144 rodičky včetně provedení vyšetření glykémie. V průběhu příjmu Rodičce
Rizikové odtéká plodová voda – porod začal a Gynekolog Mladý zakládá

porodopis.
Gynekolog Mladý prohlédne porodopis a zaměří se na všechny údaje, Na obrazovce lékaře sloužící k vedení porodopisu uchazeč postupně ukazatelem myši zobrazí ve

které KIS do porodopisu přenesl z předchozí zdravotnické dokumentace směru zleva do prava a seshora dolů všechny ikony KIS umístěné v horizontálním ovládacím panelu

145 historicky dostupné v rámci KIS. na horním okraji pracovní plochy tak, aby KIS zobrazil kontextovou nápovědu, každá nápověda bude

zobrazena alespoň 2 s. Pokud jsou některé ovládací prvky zastoupené ikonami v ovládacím a

informačním panelu umístěném i podél levého, pravého i dolního okraje pracovní plochy, provede

pohyb a zobrazení kontextových nápověd analogicky. Pracovní obrazovku pouze prohlíží - nerozbaluje

žádné menu, nespouští žádnou akci.
Až následující den v 02:00 hod ráno začne porod 1. dítěte. Porod je zcela Pro účely AVZ nebudeme dokumentovat porod 2. dítěte.

146 nekomplikovaný, narodí se děvče. Gynekolog Nejmladší založí
dokumentaci pro Dorotku Rizikovou a získá pro ni náhradní identifikátor.

147 Pediatr Zkušený a začne psát první informace do Záznamu o
novorozenci pro Dorotku Rizikovou.

Dorotka Riziková i Rodička Riziková mohou být propuštěny 5. den po Rozměr zobrazovaného náhledu uchazeč nastaví tak, aby byla maximálním možným způsobem

148 porodu z hospitalizace těhotné a novorozence. Po skončení všech dějů využita šířka dostupné pracovní plochy a list A4 náhledu při tisku svými okraji dosahoval co nejblíže
je vyroben definitivní porodopis a zobrazen náhled před tiskem okrajům pracovní plochy, uchazeč pak bude text pomalu rolovat shora dolů tak, aby byl list A4

postupně celý zobrazen na pracovní ploše.
Je vytvořena zpráva o novorozenci pro Dorotku Rizikovou, je zobrazen Rozměr zobrazovaného náhledu uchazeč nastaví tak, aby byla maximálním možným způsobem

149 náhled před tiskem. využita šířka dostupné pracovní plochy a list A4 náhledu při tisku svými okraji dosahoval co nejblíže
okrajům pracovní plochy, uchazeč pak bude text pomalu rolovat shora dolů tak, aby byl list A4

postupně celý zobrazen na pracovní ploše.
Matrika sděluje za 4 dny definitivní rodné číslo Dorotky Rizikové a je možné provést úpravu
150 identifikátoru v KIS.

Pediatr Zkušený předvede odložený přenos informací mezi porodopisem

a zprávou o novorozenci, včetně změny náhradního identifikátoru

151 novorozence na číslo pojištěnce přidělenézdravotní pojišťovnou.
Následuje vyúčtování poskytnutých zdravotních služeb a archivace

dokumentace novorozenecké dokumentace.

Pediatr zkušený si prohlédne zpětně dokumentaci Dorotky Rizikové, u Uchazeč předvede a okomentuje obě požadované varianty vyhledávání včetně umístění náhradního

152 kterých měnil identifikátor – konkrétně ji bude prohledávat podle identifikátoru v KIS poté, kdy je už známé definitivní rodné číslo.

náhradního identifikátoru i podle skutečného čísla pojištěnce či rodného

čísla.
153 Scénář 010 - Scénář akutní pacientky neznámé totožnosti na urgentním příjmu

154 Uchazeč připraví seznam alespoň 15 různých rozpracovaných pacientů se známými jmény a rodnými
čísly, kteří budou mít následující rozdělení triage:
155 • 1 bude mít naléhavost 2
156
157 • 6 bude mít naléhavost 3
• 6 bude mít naléhavost 4
158 • 2 budou mít naléhavost 5.

V databázi fiktivních pacientů v KIS je pro účely ukázky připravena i pacientka Marie Ochablá, rozená

159 Ducháčková, která byla v nemocnici vyšetřována ještě pod svým rodným příjmením Ducháčková před
10 lety v kardiologické ambulanci (3 návštěvy) pro arteriální hypertenzi a má známou alergii na

Amoksiklav – kožní ekzém.
Na urgentní příjem nemocnice je avizovaný příjezd posádky ZZS s pacientkou neznámé totožnosti s

160 odhadovaným stářím mezi 60-65 lety. V anamnéze je náhle vzniklá porucha řeči, zmatenost a

zvracení ve vestibulu obchodního domu, kabelka s doklady byla v této situaci ukradena a totožnost

není známá. Při příjezdu ZZS klinický stav vypadá jako možná cévní mozková příhoda a jako taková je

pacientka ohlášena na urgentní příjem.
Doktor Akutní aktivizuje Radiologa Zkušeného a Neurologa Mladého, aby byli připraveni na možný
161
akutní zásah na urgentním příjmu (odehrává se telefonicky, KIS není zapojený do procesu).

162 ZZS přijíždí s pacientkou, která kromě expresivní afázie postupně začíná trpět i levostrannou

hemiparézou, více vyjádřenou na dolní končetině. Má zavedený periferní žilní katétr G20 do pravé

Sestra Akutní zakládá ambulantní dokumentaci na urgentním příjmu pro kubitální žíly.

Pacientku Neznámou s náhradním rodným číslem, které získá
163 prostřednictvím funkce KIS, přiděluje jí Manchester triage naléhavost 2.
164 Doktor Akutní se dívá na seznam všech pacientů na urgentním příjmu,
který má stále otevřený na svém počítači.

Doktor Akutní nachází Pacientku Neznámou v seznamu ošetřovaných,
165 vybere si ji.

Doktor Akutní vystaví žádanku (STATIM) na neurologické konzilium a
pověřuje Sestru Akutní, aby co nejrychleji připravila žádanky STATIM a
odebrala materiál v rámci standardu pro laboratorní vyšetření v rámci
akutního iktu, který v sobě zahrnuje:
166 • KO
• INR, APTT
• glu, mineralogram, vyšetření funkce ledvin, jaterní testy, CRP,
• krevní plyny

Doktor Akutní pro Pacientku Neznámou okamžitě vyrábí dokumentaci Uchazeč připraví dokumentaci stacionáře připravenou pro sledování životních funkcí v délce 120 min

167 ambulantního pracoviště typu stacionáře - dokument pro sledování v intervalech po 15 min.
životních funkcí a ordinace léčby (obdobu dekurzu lůžkového oddělení

pro ambulantní pracoviště).
Doktor Akutní provádí první záznamy do ambulantní dokumentace o Uchazeč zapíše 2 věty, využije informace z úvodu scénáře.
168 okolnostech příjezdu pacientky a o dosavadním vývoji zdraví.

Sestra Akutní nejrychlejším možným způsobem, jakým je toho KIS Uchazeč okomentuje a předvede nejrychlejší možný způsob vystavení požadovaných žádanek.

169 schopen, vystavuje žádanky na KO, INR, APTT (tedy do hematologické
laboratoře), sleduje počty a typy odběrových zkumavek, do kterých

musí získat doporučené objemy krve.

Sestra Akutní nejrychlejším možným způsobem, jakým je toho KIS Až po vyplnění žádanky na obrazovce sestry sloužící k vystavení žádanky na laboratorní

schopen, vystavuje žádanky do biochemické laboratoře, sleduje počty a komplementární vyšetření uchazeč postupně ukazatelem myši zobrazí ve směru zleva do prava a

typy odběrových zkumavek, do kterých musí získat doporučené objemy seshora dolů všechny ikony KIS umístěné v horizontálním ovládacím panelu na horním okraji pracovní

170 krve. Vytvořenou žádanku s volbou požadovaných vyšetření nechá plochy tak, aby KIS zobrazil kontextovou nápovědu, každá nápověda bude zobrazena alespoň 2 s.
zobrazenou na obrazovce. Pokud jsou některé ovládací prvky zastoupené ikonami v ovládacím a informačním panelu umístěném

i podél levého, pravého i dolního okraje pracovní plochy, provede pohyb a zobrazení kontextových

nápověd analogicky. Pracovní obrazovku pouze prohlíží - nerozbaluje žádné menu, nespouští žádnou

Doktor Akutní mezitím otevře dokumentaci jiného pacienta z fronty akci.
Doktor Akutní zprávu průběžně uloží, ale neuzavírá. Po uložení zprávy se vrátí do přehledu fronty

171 ošetřovaných na urgentním příjmu. Do ambulantního nálezu napíše dvě pacientů ošetřovaných na urgentním příjmu.
slova.

Sestra Akutní provedla s jedním z čekajících pacientů po určité době

172 řízený rozhovor a změnila stupeň naléhavosti podle Manchester triage
ze 4 na stupeň 2; přidává symptom dušnost, do detailního popisu píše

"cyanóza rtů, DF 30/min".

Doktor Akutní dokončí ambulantní dokumentaci Pacientky Neznámé a
173 odesílá ji na ARO. Stanoví diagnózu „I63.4 Mozkový infarkt způsobený

embolií mozkových tepen“.
Anesteziolog Mladý provede hlášení pneumonie prostřednictvím KIS do

174 hygienického systému nemocnice a zároveň vyplní Hlášení infekční
nemoci, mikrob byl určen jako „Pseudomonas aeruginosa“.

175 Scénář 011 - Scénář kontrolních funkcí prostřednictvím Log KIS

176 V návaznosti na předchozí scénáře uchazeč zobrazí log událostí u Maroda Zažívacího. Zobrazí a

okomentuje záznamy vstupů do dokumentace s přesnou lokalizací v čase. Zobrazí zejména činnost

Náměstka Lékařského v plném detailu dostupných informací.
Uchazeč zobrazí a okomentuje všechny dostupné náležitosti ze záznamů o obecných dotazech
177
provedených Chirurgem Mladým včetně záznamů o činnostech, které se zpřístupněnou dokumentací

z jiného oddělení včetně zápisu důvodu nahlížení do dokumentace, provedl.
Náměstek Lékařský šetří stížnosti na urgentní příjem. Zobrazí v logu den, Uchazeč předvede orientaci v logu a vyhledání událostí na konkrétních pracovištích, konkrétních

kdy byla přijata Marie Ochablá a zobrazí si jednotlivé pacienty z datech, vyhledávání činností konkrétních osob nebo zobrazování akcí prováděných se záznamy

178 urgentního příjmu včetně stupně naléhavosti triage, jejich změn – kdo, konkrétního pacienta. Pozornost zaměří na údaj o stanoveném stupni triage a předvede způsob
kdy, jak. Zobrazí činnosti Doktora Akutního v daném dni přijetí Marie dokumentace její změny v logu.

Ochablé.

179 Scénář 012 - Scénář funkcionalit KIS pro Výkaznictví
180
Hospitalizační oblast a DRG
Ve všech níže uvedených úkolech bude uchazeč v rámci AVZ komentovat funkcionality KIS, upozorní
181
na použité automatizované a kontrolní funkce, které se uplatňují při pořizování, kontrole a přípravě

Bude předveden pohled na hospitalizační případ Maroda Zažívacího přes výkazů k odeslání dávek do zdravotní pojišťovny.
DRG.
182

Bude předveden přenos diagnóz klinické části do účtu i promítnutí úprav

183 v diagnózách v průběhu hospitalizace - změna hlavní a vedlejších
diagnóz.

184 Bude předvedena možnost nastavení stupně kontrol a na konkrétních případech bude prezentováno

185 Upozornění – na situaci: je vykázán účet anestezie, chybí účet s
operačním výkonem.

Účet lze pořídit, ale nelze vykázat pojišťovně – na situaci: je pořízen účet

186 (doklad 06) s ambulantním žadatelem a s výkonem s omezením pouze
na ambulanci. V době pořízení tohoto účtu ale bude pacient

hospitalizován.

Na vzorku minimálně deseti dokladů dopravy bude prezentováno

187 sestavení do dávky dle registrační značky a data. Po té bude dávka
rozpuštěna a bude sestavena znovu, doklady budou tentokráte řazeny

nejprve dle data a pak dle registrační značky.
Dojde k pokusu pořídit účet s neexistujícím externím žadatelem. Bude

předveden možný postup opravy - vstup do číselníku externích žadatelů,

188 možnost vyhledávání dle známých kritérií - alespoň podle jména lékaře -
"MUDr. Umlauf" a podle sídla poskytovatele ambulantního kardiologa

(odbornost 107) v Hradci Králové, uchazeč ale může předvést i jiná

kritéria pro vyhledání externího žadatele.

Bude předvedena hromadná změna hodnot nad vícero účtů – bude

189 provedena oprava výkonu 11021 za výkon 11022 a bude do historie
těchto účtů vložena poznámka s důvodem změny „vykázané komplexní

vyšetření změněno na cílené“.
Bude předvedeno sestavení dávek na vybrané číslo pojištěnce z EU –

pacient bude mít vykázány účty za hospitalizační péči,
190 komplementárních vyšetření a dopravu. Dále bude mít vykázanou

ambulantní návštěvu, která bude mimo interval hospitalizace.

Následně bude provedeno vystavení faktury za péči pro tohoto Uchazeč zobrazí náhled před tiskem, který zobrazí způsobem popsaným ve výše uvedených
191 pojištěnce. scénářích.

Konec specifikace scénářů

10 000+

2020-22

600+

rok 2020 zdarma

Textová podoba smlouvy Smlouva č. 11580504: Servisní smlouva - STAPRO - modernizace IT FNHK

Příloha s0188ea.pdf

Přehledy

K-IndexIndex klíčových rizik úřadů

Žebříčky K-Indexu

Platy v nejdůležitějších úřadech

Firmy / subjekty

Speciální reporty

Rady pro uživatele Registru smluv

Statistiky smluv

Speciální reporty

Smlouvy uveřejněné konkrétní den

Zakázky podle oborů

Zakázky podle zadavatelů

10 000+

2020-22

600+

rok 2020 zdarma

Hlídač státu

Podpořte nás!

Textová podoba smlouvy Smlouva č. 11580504: Servisní smlouva - STAPRO - modernizace IT FNHK

Příloha s0188ea.pdf

K-Index
Index klíčových rizik úřadů