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
Příloha č. 1: Projektová a technická dokumentace
V této příloze jsou uvedeny výchozí podmínky a požadavky na dodávku v rámci této veřejné zakázky.
Obsah
Obsah....................................................................................................................................................... 1
Seznam příloh .......................................................................................................................................... 3
Seznam zkratek a pojmů ......................................................................................................................... 3
1 Předmět plnění ............................................................................................................................... 7
2 Členění dokumentu ........................................................................................................................ 8
3 Požadavky na dodávky a související služby .................................................................................... 9
3.1 Předmět a rozsah dodávky .................................................................................................. 9
3.2 Východiska......................................................................................................................... 11
3.3 Dodávky ............................................................................................................................. 12
3.3.1 Koncept/architektura požadovaného řešení ................................................................. 12
3.3.2 Obecné požadavky ......................................................................................................... 21
3.3.3 Strukturovaná zdravotnická dokumentace (SZD) .......................................................... 24
3.3.4 Operační sály .................................................................................................................. 28
3.3.5 Hospitalizační provoz (evidence hospitalizovaných, lůžkové oddělení) ........................ 32
3.3.6 Ambulantní provoz (ambulance).................................................................................... 36
3.3.7 Ošetřovatelská dokumentace ........................................................................................ 38
3.3.8 Další specializovaná pracoviště v rámci strukturované zdravotnické dokumentace..... 40
3.3.9 Elektronická strukturovaná medikace, preskripce a eRecepty ...................................... 44
3.3.10 Výkaznictví...................................................................................................................... 45
3.3.11 Statistiky ......................................................................................................................... 57
3.3.12 Centrální registr pacientů............................................................................................... 58
3.3.13 Porodnice ....................................................................................................................... 58
3.3.14 Radiodiagnostika ............................................................................................................ 59
3.3.15 Rehabilitace.................................................................................................................... 61
3.3.16 Laboratorní systém (LIS)................................................................................................. 63
3.3.17 EZD – elektronická zdravotní dokumentace .................................................................. 65
3.3.18 Medikace ........................................................................................................................ 66
3.3.19 Logistika a příruční (klinické) sklady SZM a LP ............................................................... 68
3.3.20 Distribuce zdravotnických dat ........................................................................................ 70
3.3.21 Registrační autorita a kvalifikovaný elektronický podpis ............................................... 71
3.3.22 Databáze NIS .................................................................................................................. 72
3.3.23 Správa systému .............................................................................................................. 72
Strana 1 / 127
3.3.24 Auditní služby ................................................................................................................. 73
3.3.25 Napojení NIS ONP na eHealth systém kraje ................................................................... 73
3.3.26 Portál pacienta ............................................................................................................... 73
3.3.27 PACS + modality worklist................................................................................................ 76
3.3.28 Manažerský informační systém (MIS) ............................................................................ 83
3.3.29 Dodávka nezbytné HW infrastruktury a nezbytného systémového SW
pro modernizovaný NIS a jeho nové části/funkcionality ............................................... 84
3.3.30 Tiskárny náramků s čárovými kódy ................................................................................ 86
3.3.31 Čtečky čárových a QR kódů ............................................................................................ 86
3.3.32 Tablety pro personál ...................................................................................................... 86
3.3.33 Integrace na další systémy ............................................................................................. 87
3.3.34 Bezpečnostní požadavky ................................................................................................ 92
3.3.35 Implementační a provozní požadavky............................................................................ 95
3.4 Požadavky na služby..........................................................................................................96
3.4.1 Realizace předmětu plnění............................................................................................. 96
3.4.2 Seznámení s funkcionalitami, obsluhou dodávaného systému ..................................... 99
3.5 Záruky .............................................................................................................................. 100
4 Harmonogram............................................................................................................................. 101
5 Místa plnění ................................................................................................................................ 102
6 Výchozí stav ................................................................................................................................ 103
6.1 Zadavatel: Oblastní nemocnice Příbram, a.s...................................................................103
6.2 Legislativa ........................................................................................................................ 103
6.2.1 Ochrana osobních údajů .............................................................................................. 103
6.2.2 Legislativa specifická pro zdravotnická zařízení ........................................................... 103
6.2.3 Bezpečnost informací ................................................................................................... 104
6.2.4 Ostatní .......................................................................................................................... 104
6.2.5 Připravovaná legislativa: .............................................................................................. 104
6.2.6 Dokumentace projektu ................................................................................................ 105
6.3 Počty a množství zpracovávaných dat ............................................................................ 105
6.3.1 Množství zpracovávaných dat ...................................................................................... 105
6.3.2 Uživatelé....................................................................................................................... 105
6.3.3 Organizační struktura, primariáty a nákladová střediska ............................................ 105
6.4 Specifické údaje vybraných klinik....................................................................................111
6.4.1 Rehabilitace.................................................................................................................. 111
6.4.2 Analyzátory................................................................................................................... 111
6.4.3 Diagnostické přístroje .................................................................................................. 113
Strana 2 / 127
6.4.4 Klinické systémy ........................................................................................................... 114
6.5 Informační systémy, infrastruktura a technologie .......................................................... 114
6.5.1 Současný stav informačních a komunikačních technologií .......................................... 114
6.5.2 Informační systémy, které budou dotčeny projektem ................................................ 116
6.5.3 Komunikační infrastruktura.......................................................................................... 123
6.5.4 Datová centra, HW infrastruktura a technologie ......................................................... 123
6.5.5 Technologie využívané objednatelem.......................................................................... 126
Konec základní části dokumentu......................................................................................................... 127
Seznam příloh
Nejsou.
Seznam zkratek a pojmů
V následující tabulce je uveden seznam použitých zkratek a pojmů:
Zkratka/pojem Význam
365x7x24, Poskytování služeb 365 dní v roce, 24 hodiny denně, 7 dnů v týdnu
24x7x365
AD Active directory – správa uživatelů a jejich přístupů
ARO Anesteziologicko-resuscitační oddělení
ASA Anestesiologické riziko
AZD Archiv elektronické zdravotnické dokumentace
B2B Integrační rozhraní VZP
CA Certifikační autorita
CRP Centrální registr pacientů
CSV Jednoduchý souborový formát určený pro výměnu tabulkových dat. Soubor ve
formátu CSV sestává z řádků, ve kterých jsou jednotlivé položky odděleny znakem
čárka (,).
CT Počítačová tomografie
CÚ (SÚKL) Centrální úložiště SÚKL pro eRecept
Časová dotace Doba trvání příslušné aktivity
ČR Česká republika
DASTA Otevřený český národní standard pro výměnu informací ve zdravotnictví
Strana 3 / 127
Zkratka/pojem Význam
DB Databáze
DC Datové centrum
DICOM Mezinárodní standard pro zobrazování, distribuci, skladování a tisk medicínských
dat pořízených snímacími metodami jako jsou CT, MRI či ultrazvuk.
DR Datové rozhraní
DRG Diagnosis Related Group
DZD Distribuce zdravotnických dat
EEG Elektroencefalogram
EH Evidence hospitalizovaných
eH NCP Národní kontaktní místo pro eHealth
EKG Elektrokardiogram
EP Elektronická preskripce
ERP Podnikový informační systém
EU Evropská unie
EZD Elektronická zdravotnická dokumentace
GDPR Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016
o ochraně fyzických osob (GDPR – General data protection regulation) v souvislosti
se zpracováním osobních údajů a o volném pohybu těchto údajů.
GUI Grafické uživatelské rozhraní
HL7 Standard pro přenos informací ve zdravotnictví si v celosvětovém měřítku
HW Hardware
ICT Informační a komunikační technologie
IČP Identifikační číslo provozovny
IČZ Identifikační číslo zařízení
IOP Integrovaný operační program
IROP Integrovaný regionální operační program
IS Informační systém
IS ZR Informační systém základních registrů
JIP Jednotka intenzivní péče
KCK Krajské komunikační centrum (eHealth)
Strana 4 / 127
Zkratka/pojem Význam
KIS Klinický informační systém
KLK Číselník léčivých přípravků registrovaných v ČR
ks Počet kusů
LIS Laboratorní systém
LO Lůžkové oddělení
LP Léčivý prostředek
MIS Manažerský informační systém
MKN 10 Mezinárodní klasifikace nemocí a přidružených zdravotních problémů, 10. revize
MR / MRI Magnetická rezonance
MS Microsoft
MZd Ministerstvo zdravotnictví ČR
NIA Národní bod pro identifikaci a autentizaci nebo též Národní identitní autorita
zajišťující státem garantovanou službu identifikace a autentizace.
NIS Nemocniční informační systém
NIX ZD Projekt zavedení přeshraniční služeb eHealth v České republice
NLZP Nelékařský zdravotnický personál
NS Nákladové středisko
NZIS Národní zdravotnický informační systém
ONP Oblastní nemocnice Příbram, a.s.
OS Operační systém nebo operační sály (dle kontextu)
OSSZ Okresní správa sociálního zabezpečení
PACS Systém pro správu, ukládání (archivaci), distribuci a zobrazení zdravotnické
obrazové dokumentace (tj. obrazových vyšetření z modalit – RTG, MR a dalších
zdrojů)
PD Projektová dokumentace
PDF Formát dokumentů
POJ Zdravotní pojišťovny
PZT Prostředky zdravotní techniky
RA Registrační autorita
RDG Radiologie
Strana 5 / 127
Zkratka/pojem Význam
RIS Radiodiagnostika
ROB Registr obyvatel
RTG Rentgen
SčK Středočeský kraj
SLA Úroveň a podmínky poskytování služeb technické a technologické podpory.
SMS Krátká textová zpráva
SQL Označení DB nebo jazyka pro práci s relačními databázemi (dle kontextu)
SSO Single Sign On – podpora pro jednotné přihlášení
SÚKL Státní ústav pro kontrolu léčiv
SW Software
SZD Strukturovaná zdravotnická dokumentace
SZM Speciální zdravotnický materiál
ÚPS Ústavní pohotovostní služba
ÚZIS Ústav zdravotnických informací a statistiky České republiky
VZ Veřejná zakázka
VZP Všeobecná zdravotní pojišťovna
XLS Formát MS Excel
XML Výměnný formát a formát struktury dat
ZD Zadávací dokumentace nebo zdravotnická dokumentace (dle kontextu)
ZP Zdravotní pojišťovna/y
ZUM Zvlášť účtovaný materiál
ZULP Zvlášť účtované léčivé prostředky
ZZ Zdravotnické zařízení
Tabulka 1: Seznam zkratek a pojmů
Strana 6 / 127
1 Předmět plnění
Předmětem projektu a této veřejné zakázky je modernizace, rozvoj a pořízení nových částí do stávajícího
vnitřního nemocničního informačního systému (NIS) žadatele, kterým je Oblastní nemocnice Příbram,
a.s. (ONP), včetně připojení NIS na krajský systém pro výměnu a sdílení zdravotnické dokumentace mezi
zdravotnickými zařízeními (eHealth SčK) s tím, že zdravotnická dokumentace musí být strukturována a
standardizována tak, aby mohla jak s tímto systémem, tak s národními zdravotnickými registry a
pacienty komunikovat bez nutnosti dalších převodníků.
Předmětem dodávky je modernizace (výměna stávajícího systému za nový) a rozšíření funkcionalit
nemocničního informačního systému (NIS) v oblasti elektronizace procesů (např. v oblasti elektronické
zdravotnické dokumentace, objednávání pacientů na vyšetření, zpracování dat v PACS apod.),
dlouhodobá elektronická archivace zdravotnické dokumentace, podpora nových procesů v rámci
nemocnice a jejich elektronizace a možnost jejich realizace nejen v nemocnici, ale i vzdáleně a nové
funkce v existujícím NIS.
Jedná se o modernizaci a rozvoj vnitřního informačního systému žadatele pro řízení, podporu činností a
provoz nemocnice zakládané Středočeským krajem. Součástí je napojení dalších vnitřních informačních
systémů žadatele a na externí systémy pro výměnu zdravotnické dokumentace. Prostřednictvím eHealth
systému kraje bude zajištěno napojení na další systémy výměny zdravotnické dokumentace, např. NIX
ZD, Národní kontaktní místo pro eHealth (eH NCP) a eHealth systémy dalších krajů.
Dále je součástí dodávky i nezbytná HW a SW infrastruktura a koncová HW zařízení (tiskárny náramků s
čárovými kódy, čtečky čárových a QR kódů, tablety pro personál) pro provoz modernizovaného NIS.
Předmět plnění je tedy následující:
1. Zavedení elektronické zdravotnické dokumentace (EZD) vč. elektronického archivu.
2. Registrační autorita
3. NIS - elektronizace vizity
4. NIS - rozvoj PACS
5. NIS - portál pro elektronické objednávání pacientů na vyšetření
6. Napojení NIS na eHealth systém kraje
7. Rozšíření funkcionalit nemocničního informačního systému (NIS) nad rámec již uvedených
funkcionalit
8. Modernizace stávajícího nemocničního informačního systému (NIS) - stávající funkcionality
9. Dodávka nezbytné HW a SW infrastruktury pro modernizovaný IS a jeho nové části/funkcionality
10. Tiskárny náramků s čárovými kódy
11. Čtečky čárových a QR kódů
12. Tablety pro personál
Požadavky na servisní služby k tomuto Dílu jsou definovány v samostatném dokumentu, který v rámci
VZ je přílohou ZD a současně se stane přílohou Servisní smlouvy.
Strana 7 / 127
2 Členění dokumentu
Tento dokument obsahuje jen a pouze požadavky na dodávku a související služby (Dílo) a je členěn
následovně:
• Kapitola 3 – Požadavky na dodávky a související služby – kapitola obsahuje požadavky na
dodávky a služby (Dílo), které musí zhotovitel splnit ve svém řešení a ve své nabídce. Kapitola
obsahuje základní koncept řešení, legislativní požadavky, konkrétní funkční a technické
požadavky na řešení předmětu plnění v rámci VZ.
• Kapitola 4 - Harmonogram – kapitola obsahuje harmonogram realizace předmětu plnění VZ.
• Kapitola 5 – Místa plnění – kapitola obsahuje místa plnění v rámci realizace předmětu plnění
VZ.
• Kapitola 6 – Výchozí stav – kapitola obsahuje popis výchozího stavu pro realizaci předmětu VZ,
tj. uvedení seznamu dotčených subjektů, jejich vztah k předmětu VZ, informační
a komunikační technologie a vybavení, kterými subjekty disponují nebo které budou k dispozici
pro realizaci VZ, případně další organizační a technické podmínky, které jsou důležité pro
realizaci VZ.
Uvedené kapitoly a jejich obsah jsou uvedeny dále v tomto dokumentu.
Požadavky na servisní služby k tomuto Dílu jsou definovány v samostatném dokumentu, který v rámci
VZ je přílohou ZD a současně se stane přílohou Servisní smlouvy.
Strana 8 / 127
3 Požadavky na dodávky a související služby
V této kapitole jsou uvedeny požadavky na dodávky a související služby v rámci této VZ.
3.1 Předmět a rozsah dodávky
Jedná se o modernizaci (výměnu stávajícího systému za nový) a rozšíření funkcionalit nemocničního
informačního systému (NIS) v oblasti elektronizace procesů (např. v oblasti elektronické zdravotnické
dokumentace, objednávání pacientů na vyšetření, zpracování dat v PACS apod.), dlouhodobá
elektronická archivace zdravotnické dokumentace, podpora nových procesů v rámci nemocnice a jejich
elektronizace a možnost jejich realizace nejen v nemocnici, ale i vzdáleně a nové funkce v existujícím
NIS.
Jedná se o modernizaci a rozvoj vnitřního informačního systému žadatele pro řízení, podporu činností a
provoz nemocnice zakládané Středočeským krajem. Součástí je napojení dalších vnitřních informačních
systémů žadatele a na externí systémy pro výměnu zdravotnické dokumentace (eHealth, jen napojení
na tento systém SčK, nikoliv dodávka nebo modernizace tohoto systému). Prostřednictvím eHealth
systému kraje (KKC SčK) bude zajištěno napojení na další systémy výměny zdravotnické dokumentace,
např. NIX ZD, Národní kontaktní místo pro eHealth (eH NCP) a eHealth systémy dalších krajů.
Součástí modernizace NIS je i nezbytná HW infrastruktura, systémový SW, síťová infrastruktura a
koncová HW zařízení koncových uživatelů.
Rozsah modernizace NIS:
Ozn. Položka rozpočtu Jednotka Jednotka Stručný popis položky
1 Zavedení soubor 1
elektronické Zavedení elektronické zdravotnické dokumentace (EZD) minimálně
zdravotnické soubor 1 v rozsahu dekurz, teplotka, propouštěcí zpráva, laboratorní výsledek
dokumentace soubor 1 a všechny formuláře s těmito zprávami související, zajištění
(EZD) vč. soubor 1 technologického, aplikačního a procesního prostředí pro vedení a
elektronického soubor 1 archivaci zdravotnické dokumentace pacientů v NIS a LIS v čistě
archivu. elektronické podobě v souladu s legislativou (elektronický archiv).
Archiv pro ukládání elektronické zdravotnické dokumentace bude
2 Registrační sloužit také pro ukládání dokumentace z jiných agend, které obsahují
autorita zdravotnické údaje pacienta (elektronicky podepsaná obrazová
vyšetření uložená v PACS a podepsané dokumenty spisové služby).
3 NIS - Vybudování registrační autority pro vydávání a správu certifikátů pro
elektronizace podepisování elektronické dokumentace.
vizity Součástí provozu budou i náklady na certifikáty a tokeny personálu.
Zajištění aplikace do mobilních zařízení personálu (tablety) pro
4 NIS - rozvoj PACS zpřístupnění dat z NIS v rámci vizity a možnost elektronicky tato data
upravovat a doplňovat v rámci vizity. Zpracování dat ve formě
5 NIS - portál pro elektronické zdravotnické dokumentace.
elektronické Modernizace řešení PACS umožňující diagnostiku a klinický náhled,
objednávání správu a práci s obrazovou dokumentací na libovolném koncovém
pacientů na zařízení (vč. možnosti vzdáleného popisování a vzdálených konzultací
vyšetření obrazové dokumentace), zařazení do zdravotnické dokumentace.
Internetový objednávkový systém, prostřednictvím kterého mohou
6 Napojení NIS na uživatelé zadávat objednávky přímo do ambulantních diářů
eHealth systém nemocničního informačního systému, návaznost na NIS.
kraje
soubor 1 Napojení na eHealth systém kraje, který byl realizován v rámci IOP, v.
č. 23 v roce 2015. Jedná se o výměnu informací o pacientech mezi
zdravotnickými zařízeními a ZZS kraje.
Strana 9 / 127
Ozn. Položka rozpočtu Jednotka Jednotka Stručný popis položky
7 Rozšíření soubor 1 Rozšíření funkcionalit nemocničního informačního systému (NIS) o
funkcionalit napojení na elektronickou preskripci (e-recept), vedení
nemocničního 1 ošetřovatelské dokumentace, evidence nežádoucích událostí,
informačního evidence použitých přístrojů v rámci vyšetření a sběr dat z těchto
systému (NIS) nad 1 přístrojů, napojení na elektronickou zdravotnickou dokumentaci a její
rámec již zpracování v koncových zařízeních, a to jak mobilních, tak
uvedených 17 stacionárních, rehabilitaci s plánováním léčebných procedur,
funkcionalit 30 odesílání dat pro OSSZ (e*neschopenka), vedení strukturované
30 ordinace medikace s návazností příručních skladů a výdejem léků na
8 Modernizace soubor identifikovaného pacienta, funkce centrálního výkaznictví s
stávajícího napojením na portály zdravotních pojišťoven a statistických hlášení
nemocničního pro online vykazování, identifikaci pacientů pomocí čárového kódu,
informačního vytváření elektronických žádanek do laboratoří, podporu
systému (NIS) - manažerského řízení apod.
stávající Modernizace stávajícího nemocničního informačního systému (NIS) v
funkcionality rozsahu stávajících funkcionalit. Všechny stávající funkcionality, které
nejsou explicitně vyloučeny, budou převedeny do nového NIS, vč.
9 Dodávka Soubor jejich nezbytných úprav souvisejících se zavedením elektronické
zdravotnické dokumentace a elektronického archivu.
nezbytné HW a Dodávka, implementace IS, migrace dat, přepojení stávajících
integrací a uvedení do provozu.
SW infrastruktury Dle podmínek výzvy se jedná o nezpůsobilé výdaje.
Dodávka nezbytné HW a SW infrastruktury pro běh
pro modernizovaného NIS a nových modulů/funkcionalit NIS. Jedná se o
servery, disková úložiště, síťové prvky, systémový SW (OS, DB,
modernizovaný IS licence) apod., které jsou nezbytné pro dodávku a provoz IS.
a jeho nové Tiskárny náramků s čárovými kódy.
části/funkcionality Čtečky čárových a QR kódů.
10 Tiskárny náramků ks Tablety pro personál.
s čárovými kódy
11 Čtečky čárových a Ks
QR kódů
12 Tablety pro ks
personál
Tabulka 2: Rozsah modernizace NIS
Součástí dodávky jsou dále následující služby a náležitosti:
1. Projektové řízení dodávky řešení.
2. Zpracování analýzy a návrhu řešení – konkretizace implementačního postupu, přesné
konfigurace a instalačního a montážního návrhu řešení z nabídky.
3. Dodávka, implementace, instalace, konfigurace HW a SW infrastruktury.
4. Vývoj informačního systému a jeho součástí.
5. Implementace informačního systému a jeho součástí.
6. Výchozí import datových zdrojů a metadat do systému (migrace dat).
7. Ověření funkčnosti dodaného systému a jeho částí.
8. Dodávka dokumentace dodaného systému a jeho částí (min. uživatelská dokumentace,
dokumentace skutečného provedení, systémová dokumentace, projektová dokumentace).
9. Zaškolení uživatelů a administrátorů – seznámení s funkcionalitami, obsluhou dodávaného
systému a jeho budoucím provozem.
10. Asistence pracovníků dodavatele uživatelům při náběhu provozu.
11. Zařazení do provozního prostředí objednatele (dohled, zálohování apod.)
Strana 10 / 127
12. Provedení zkušebního provozu.
13. Poskytnutí záruky 5 let na informační systém a 3 roky na HW a SW infrastrukturu.
Všechny dodávky a převzetí plnění/řešení (i částečného) bude vždy stvrzeno písemně
(akceptačním/předávacím protokolem nebo dodacím listem).
Doplňující požadavky na implementaci:
1. Zajištění kontinuity provozu zdravotnického zařízení. Po stránce nepřetržitého provozu
předpokládá pouze plánovanou odstávku pouze na nezbytnou dobu.
2. Požaduje se kontinuita nastavených parametrů, všech číselníků, definic, tiskových sestav,
definice organizační struktury a jiných aspektů provozu. Nepředpokládá investici do opětovného
zadávání a pořizování těchto údajů.
Předmětem dodávky není:
1. Zajištění komunikační infrastruktury (sítě apod.) mezi jednotlivými prvky systému.
2. Infrastruktura, HW a systémový SW poskytovaný Objednatelem uvedený ve výchozím stavu.
3. Spotřební materiál využívaný v následném provozu informačního systému.
Koncept řešení, principy a požadavky na dodávky a služby jsou uvedeny dále v tomto dokumentu.
3.2 Východiska
Systém umožní, aby Objednatel vedl minimálně výše uvedenou zdravotnickou dokumentaci jako čistě
elektronickou, tj. v jen elektronické podobě. Z uvedeného plyne, že dokumentace se bude pořizovat,
zpracovávat a ukládat elektronicky to včetně archivace.
Elektronické verze dokumentů ze zdravotnické dokumentace budou podepsány kvalifikovaným
elektronickým podpisem, pokud se bude jednat o pracovníka Objednatele a nebude vyžadován podpis
další osoby (ověření pravosti dokumentu pracovníkem). Pokud bude vyžadován podpis jiné osoby (např.
pacienta bez elektronického podpisu), bude dokument vytištěn a podepsán touto osobou na vytištěném
dokumentu nebo podepsán viditelným digitálním podpisem na zařízení a následně vytištěn. Takový
dokument bude k elektronické dokumentaci zařazen následně pracovníkem objednatele, který provede
konverzi do elektronické formy a elektronicky podepíše. Uvedené platí i pro podpisy více osob na jednom
dokumentu a to jak elektronicky, tak případně v písemné formě.
Objednatel v rámci tohoto projektu bude pořizovat i archiv elektronické dokumentace v souladu
s požadavky legislativy na vedení a archivaci plně elektronické zdravotnické dokumentace.
Strana 11 / 127
3.3 Dodávky
V této kapitole je uveden koncept požadovaného řešení a požadavky na dodávky.
3.3.1 Koncept/architektura požadovaného řešení
Na následujícím schématu je uveden koncept/architektura řešení NIS ONP:
Obrázek 1: Koncept/architektura požadovaného řešení
Stručný popis konceptu/architektury řešení na úrovni aplikací/modulů, komponent, funkcí a
integrovaných systémů je na následující straně.
Strana 12 / 127
V následující tabulce je stručný popis konceptu/architektury řešení na úrovni aplikací/modulů, komponent, funkcí a integrovaných systémů:
# Zkratka Název Účel Současný stav Modernizace/rozvoj Popis modernizace/rozvoje
1 NIS Provozní systém nemocnice. Modernizace
Nemocniční Systém je zastaralý, poslední Nahrazení stávajícího systému v plném
2 NIS-CRP informační modernizace proběhla v roce 2004, Modernizace současném rozsahu, rozšíření o nové
systém nyní probíhají jen legislativní úpravy, funkcionality ve vybraných oblastech,
3 NIS-EH dodavatel již tento systém nerozvíjí, zajištění dlouhodobé kontinuity systému
4 NIS-LO rozvíjí nový, modernější systém. pro fungování nemocnice.
Ukončení podpory výrobce by ohrozilo Zavedení elektronické zdravotnické
fungování nemocnice. dokumentace do celého systému, tj. do
všech modulů, možnost zavedení procesů
NIS - Centrální Centrální registr pacientů v Součást stávajícího NIS, jedná se o s návaznými úkoly a vytváření formulářů.
registr pacientů nemocnici a agenda kolem něj. základní registr nemocnice, data se při Převod úplného registru do nového
Ostatní moduly, případně změnách synchronizují do ostatních systému.
NIS - Evidence ostatní systémy čerpají data z modulů a systémů v rámci nemocnice. Identifikace pacientů pomocí čárového
hospitalizovaných tohoto registru. NIC-CRP poskytuje integrační rozhraní, kódu, zavedení EZD.
NIS - Lůžkové Jedná se o vnitřní evidenci přes které probíhá zabezpečená V případě zpřístupnění IS ZR (ROB), bude
oddělení pacientů v nemocnici, nejedná výměna dat s externími systémy. zajištěna návaznost na tento registr.
se o registr využívaný žádným
dalším subjektem. Součást stávajícího NIS, jedná se o Rozvoj Převod funkčností do nového systému.
Administrativní agenda základní funkčnost nezbytnou pro Rozvoj Identifikace pacientů pomocí čárového
spojená s evidencí fungování nemocnice. kódu, zavedení EZD.
hospitalizovaných pacientů. Součást stávajícího NIS, jedná se o Převod funkčností do nového systému.
Vedení specifické agendy základní funkčnost nezbytnou pro Rozšíření o elektronickou vizitu v rámci
hospitalizovaných pacientů a fungování nemocnice. mobilních zařízeních (tabletech), vedení
zdravotnické dokumentace. ošetřovatelské dokumentace,
nežádoucích událostí, evidence použitých
přístrojů v rámci vyšetření a sběr dat z
těchto přístrojů (včetně podpory agendy
JIP a Anesteziologie), odesílání dat pro
OSSZ (e*neschopenka), vedení
strukturované ordinace medikace, včetně
příručních skladů a výdeje léků na
identifikovaného pacienta, identifikace
pacientů pomocí čárového kódu,
vytváření elektronických žádanek do
Strana 13 / 127
# Zkratka Název Účel Současný stav Modernizace/rozvoj Popis modernizace/rozvoje
5 NIS-A Rozvoj laboratoří, podpora manažerského řízení,
6 NIS-P NIS - Ambulance Vedení specifické agendy Součást stávajícího NIS, jedná se o Rozvoj plánování léčebných procedur,
7 NIS-VC ambulantních pacientů a základní funkčnost nezbytnou pro identifikace pacientů pomocí čárového
NIS - Porodnice zdravotnické dokumentace. fungování nemocnice. kódu, napojení na elektronickou
8 NIS-S NIS - Výkaznictví preskripci (e-recept), zavedení EZD.
9 NIS-SS Vedení specifické agendy Součást stávajícího NIS, jedná se o Převod funkčností do nového systému.
10 NIS-OS NIS - Statistiky porodnice a zdravotnické základní funkčnost nezbytnou pro Rozšíření o odesílání dat pro OSSZ
(NZIS) dokumentace rodiček a fungování nemocnice. (e*neschopenka), plánování léčebných
narozených dětí. procedur, identifikace pacientů pomocí
NIS - Správa Zpracování dat na lokální Součást stávajícího NIS, jedná se o čárového kódu, napojení na elektronickou
systému úrovni nemocnice pro účely základní funkčnost nezbytnou pro preskripci (e-recept), zavedení EZD.
NIS - Operační vykazování péče plátcům péče fungování nemocnice. Převod funkčností do nového systému.
sály (pojišťovnám). Rozšíření o identifikace pacientů pomocí
Součástí je vytváření a V současné době je zde vytvářena čárového kódu, zavedení EZD .
elektronické předávání k-dávek hlavně statistika NZIS a některé
zdravotním pojišťovnám. základní statistiky. Statistiky je třeba Rozvoj Převod funkčností do nového systému.
Vytváření základních statistik v rozšířit tak, aby byl komplexní přehled Rozšíření o napojení na portály
rámci NIS o poskytované péči a nad poskytovanou péčí a fungováním zdravotních pojišťoven a statistických
dalších ukazatelích. Mimo to nemocnice. hlášení pro online vykazování.
jsou zde vytvářeny statistiky Funkčnost se využívá.
pro externí subjekty, např. Modernizace Součástí řešení musí být rozšíření statistik
NZIS. Propojení NIS a modulů pro operační nad NISem tak, aby byl komplexní přehled
Funkce pro správu NIS - sály se nyní využívá. Modernizace nad poskytovanou péčí a fungování
uživatelů, rolí, pracovišť, Rozvoj nemocnice.
číselníků, parametrů apod.
Vedení specifické agendy na Převod funkčností do nového systému.
operačních sálech k Nové funkčnosti se nepředpokládají.
prováděným operacím a
zdravotnické dokumentace Převod funkčností do nového systému.
pacienta. Zavedení EZD.
Strana 14 / 127
# Zkratka Název Účel Současný stav Modernizace/rozvoj Popis modernizace/rozvoje
11 NIS-IK Navazuje na moduly Operační
12 NIS-MAIL NIS - Informační sály a operační management, Funkčnost se nevyužívá, příjem probíhá Ne Zrušení funkčnosti pro nadbytečnost.
13 RIS kancelář primárním systémem pro přes ambulanci urgentního příjmu.
NIS - Vnitřní vedení zdravotnické Funkčnost se moc nevyužívá. Ne Zrušení funkčnosti pro nadbytečnost.
14 REH pošta dokumentace je NIS.
15 LIS Příjem pacientů a poskytování Produkt je využíván pro pracoviště Modernizace Převod funkčností do nového systému.
Radiodiagnostika informací pacientům. zobrazovacích metod v plném rozsahu Nové funkčnosti se nepředpokládají.
Zajištění komunikace mezi (RTG, CT, magn. rezonance).
Rehabilitace lékaři a zdravotnickým Rozvoj Požaduje se zavedení nového modulu pro
Laboratorní personálem k vyšetřením a Produkt není součástí NIS a není tedy Rozvoj rehabilitace a plánování léčebných
systém důvěrným informacím využíván. procedur, zavedení EZD.
vztahujícím se k pacientům v Funkčnost se využívá, výměna dat Převod současné funkčnost do nového
rámci NIS. (žádanky, výsledky) s NIS probíhá systému.
Systém pro pracoviště prostřednictvím formátu DASTA přes Doplnění vytváření elektronických
zobrazovacích metod (RTG, CT, sdílenou složku, komunikace s žádanek do laboratoří, zavedení EZD,
magn. rezonance). Přebírá laboratorními přístroji/analyzátory. elektronického podepisování výsledků,
žádanky z NIS a předává elektronické distribuce výsledků do NIS,
informace (výsledky) do NIS, archivu a elektronická distribuce dat přes
modalit a PACS pro následné systém distribuce zdravotnických dat
zpracování a zařazení do (DZD) dalším subjektům (např. praktickým
zdravotnické dokumentace. lékařům).
Informační podpora procesů a
plánování procedur pro oblast
rehabilitací.
Zajištění laboratorních
vyšetření: biochemie,
hematologie, mikrobiologie
(bakteriologie, sérologie),
transfúze, přebírání dat z
laboratorních přístrojů,
zpracovávání žádanek na
vyšetření z NIS a distribuce
výsledků vyšetření do NIS.
Strana 15 / 127
# Zkratka Název Účel Současný stav Modernizace/rozvoj Popis modernizace/rozvoje
16 - Laboratorní Elektronické předávání V současnosti se používá více než 18 Ne Zachování podpory stávajících typů
přístroje výsledků z laboratorních typů laboratorních přístrojů, které přístrojů (analyzátory) v rámci LIS,
17 PACS přístrojů do laboratorního předávají data do LIS. Rozvoj případně rozšíření o podporu dalších typů
18 - PACS + Modality systému (LIS). Ne (např. bedside monitory, kardiotokografy,
19 DZD worklist Produkt je využíván pro diagnostiku, Ne glukomentry atd.). Výčet bude upřesněn
20 OSOM Systém pro elektronickou klinický náhled, správu, archivaci a Ne v rámci ZD.
Modality správu obrazových dat distribuci obrazové dokumentace (RTG, Stávající systém zůstane zachován, bude
21 OSFV v medicíně. CT, MR). Ne rozšířen o webový DICOM prohlížeč a
22 SS Distribuce Připojeny v současné době využívané Ne webový portál pro správu obrazové
zdravotnických Zařízení generující obrazová přístroje. dokumentace uložené v PACS.
dat data a připojují se k PACS Zůstane zachován stávající systém
Operační sály a (např. RTG, CT apod.) Jedná se o samostatný produkt, který je propojení.
operační Zabezpečený přenos/distribuce využíván pro distribuci výsledků
management zdravotnických dat mezi vyšetření a to jak v rámci nemocnice, Systém zůstane zachován, není plánována
informačními systémy tak externím subjektům. jeho modernizace ani rozvoj.
Operační sály – (aplikacemi). Jedná se o samostatný produkt, který je
foto/video Zajišťuje plánování a organizaci využíván pro plánování operací a Systém zůstane zachován, není plánována
Stravovací operací na operačních sálech management operačních sálů. jeho modernizace ani rozvoj.
systém nemocnice. Umožňuje vytvářet Součástí rozvoje NIS musí být vytvoření
přehledy o vytížení sálů a dává Využíváno v rámci operací. Je integračního rozhraní na tento systém a
tak podklady pro jeho propojeno na NIS. zajištění vzájemné výměny dat.
optimalizaci. Monitorování Zajišťuje organizaci stravování v rámci
skutečných nákladů na nemocnice. Pro potřeby stravování Systém zůstane zachován, není plánována
provedené operace, dále je pacientů je napojen na NIS, odkud jeho modernizace ani rozvoj.
součástí například evidence čerpá data o specifických požadavcích Systém zůstane zachován, není plánována
potřebného/použitého jeho modernizace ani rozvoj.
materiálu pro operační provoz
či plán sestavení operačního
týmu.
Zajištění fotografické a
videodokumentace k operacím.
Zajišťuje organizaci stravování
v rámci nemocnice a to jak pro
pacienty, tak pro zaměstnance
nemocnice.
Strana 16 / 127
# Zkratka Název Účel Současný stav Modernizace/rozvoj Popis modernizace/rozvoje
23 EP na stravu (diety). Systém je využíván a
Elektronická Systém pro elektronickou nepředpokládá se jeho změna. Ano Systém zůstane zachován, je plánována
24 IS-L preskripce preskripci z NIS pro uložení Systém je využíván v plném rozsahu.
receptů (záznam ordinované Systém je propojen s NIS a následně na jeho modernizace a rozvoj s cílem
25 ERP Lékárna medikace). Lékárna následně lékárnu (IS-L).
26 PER vyzvedává recepty a zapisuje Systém není napojen na systém e- napojení na systém e-recept SÚKL.
27 PAT Podnikový výdej léků (záznam recept SÚKL pro elektronickou
28 ZS informační dispendované medikace). preskripci. Ne Systém zůstane zachován, není plánována
29 MIS systém Systém pro elektronickou
Personalistika preskripci z NIS pro uložení Systém je využíván v plném rozsahu. jeho modernizace ani rozvoj.
30 A-EZD Patologie receptů (záznam ordinované Systém je propojen s NIS přes
Žádankový medikace). Lékárna následně Elektronickou preskripci (EP). Ne Systém zůstane zachován, není plánována
systém vyzvedává recepty a zapisuje Ne jeho modernizace ani rozvoj.
výdej léků (záznam Systém je využíván v plném rozsahu. Ne
Manažerský dispendované medikace). Systém je propojen s NIS. Ne Systém zůstane zachován, není plánována
informační Ekonomické zajištění fungování Rozvoj jeho modernizace ani rozvoj.
systém nemocnice nad rámec Systém je využíván v plném rozsahu. Systém zůstane zachován, není plánována
poskytování zdravotnické péče. Systém je propojen s NIS. Rozvoj jeho modernizace ani rozvoj.
Archiv Zajištění personální agendy. Systém je využíván v plném rozsahu. Systém zůstane zachován, není plánována
elektronické Systém je propojen s NIS. jeho modernizace ani rozvoj.
Zajištění agendy v oblasti Systém je využíván v plném rozsahu.
patologie. Systém je propojen s NIS. Systém zůstane zachován, bude rozšířen o
Žádankový systém pro zajištění napojení systémů a vyhodnocování dat
potřebného vybavení pro Současný produkt je vyhovující a je z kliniky, logistiky, úhradové vyhlášky,
personál v rámci výkonu své třeba jej zachovat. ekonomiky, personalistiky a lékárny.
práce.
Manažerský informační V současnosti nemocnice nedisponuje Budou rozšířeny stávající systémy o
systém, který zajišťuje systémem pro EZD a archivaci EZD. elektronické podepisování, zpracování a
vytěžování dat z NIS a dalších IS ukládání dokumentace, archivace
a zajišťuje reporting z těchto
dat pro vedení a provoz
nemocnice.
Elektronické zdravotnické
dokumentace (EZD) vč. archivu.
Strana 17 / 127
# Zkratka Název Účel Současný stav Modernizace/rozvoj Popis modernizace/rozvoje
Rozvoj dokumentace, bude vybudován archiv
31 ELO zdravotnické EZD, kam bude dokumentace ukládána.
Archiv pro ukládání elektronické
32 RA dokumentace zdravotnické dokumentace bude sloužit
33 E-CA také pro ukládání dokumentace z jiných
34 Tablet Elektronické Internetový objednávkový V současnosti nemocnice nedisponuje agend, které obsahují zdravotnické údaje
35 Tiskárny objednávání systém, prostřednictvím takovým systémem. pacienta (elektronicky podepsaná
36 Čtečky pacientů na kterého mohou uživatelé obrazová vyšetření uložená v PACS a
vyšetření zadávat objednávky přímo do V současnosti nemocnice nedisponuje podepsané dokumenty spisové služby).
ambulantních diářů takovým systémem. Bude vybudován nový systém pro
Registrační nemocničního informačního elektronické objednávání pacientů na
autorita systému, návaznost na NIS. V současnosti nemocnice nedisponuje vyšetření.
Registrační autorita pro takovým systémem.
Externí vydávání a správu certifikátů V současnosti nemocnice nedisponuje Rozvoj Bude vybudován nový systém pro
certifikační pro podepisování elektronické takovým vybavením. Ne vydávání a správu certifikátů pro
autorita dokumentace. Rozvoj podepisování elektronické dokumentace.
Tablety pro Externí certifikační autorita pro V současnosti nemocnice nedisponuje
personál poskytování certifikátů pro takovým vybavením. Rozvoj Registrační autorita bude napojena na
registrační autoritu. Rozvoj takový systém pro vydávání a správu
Tiskárny náramků Pro elektronické zadávání dat a certifikátů.
s čárovými kódy elektronické provádění úkonů Vybavení bude zakoupeno buď v projektu
při vyšetřeních. Jedná se o (viz rozsah výše) nebo mimo projekt (nad
nutnou podmínku např. pro rámec dodávky) jako předpoklad pro
elektronickou vizitu. zavedení EZD.
Pro tisk náramků s čárovými
kódy pro identifikaci pacientů. Vybavení bude zakoupeno buď v projektu
nebo mimo projekt jako předpoklad pro
Čtečky čárových Čtečky čárových a QR kódů z V současnosti nemocnice nedisponuje zavedení EZD.
a QR kódů náramků a léčiv pro identifikaci takovým vybavením. Vybavení bude zakoupeno buď v projektu
pacientů a léků. nebo mimo projekt jako předpoklad pro
zavedení EZD.
Strana 18 / 127
# Zkratka Název Účel Současný stav Modernizace/rozvoj Popis modernizace/rozvoje
37 ZP Zdravotní Nemocnice vykazuje zdravotní Vykazování probíhá pravidelně každý Ne Rozhraní je standardem, který se nebude
38 ÚZIS pojišťovny péči zdravotním pojišťovnám měsíc z modulu NIS - Výkaznictví. měnit, modernizovaný NIS musí
pro zajištění úhrady péče. Ne respektovat toto rozhraní.
39 EXT Ústav Povinné vykazování o Vykazování probíhá pravidelně každý Rozhraní je standardem, který se nebude
zdravotnických poskytované zdravotní péči. měsíc z modulu NIS - Statistiky (NZIS). měnit, modernizovaný NIS musí
informací a respektovat toto rozhraní.
statistiky České Jedná se např. o praktické Vybrané systémy a moduly touto
republiky lékaře, kterým jsou cestou distribuují data. Ne Zůstane zachován stávající systém
Externí subjekty poskytovány výsledky,
případně další informace ze V současné době je využíván náhradní
zdravotnické dokumentace způsob/systém elektronické preskripce distribuce.
pacientů. na straně SÚKL.
40 e-recept Elektronický Systém SÚKL pro výměnu e- Systém je k dispozici, nicméně NIS nyní Ne Rozhraní je standardem, který se nebude
receptů v rámci elektronické není napojen na tento systém. Ne měnit, modernizovaný NIS musí
recept (e-recept preskripce. Rozvoj respektovat toto rozhraní.
Systém pro elektronické V současnosti nemocnice nedisponuje Rozhraní je standardem, který se nebude
SÚKL) předávání dat o takovým systémem klinických skladů měnit, modernizovaný NIS musí
neschopenkách pro OSSZ. s výdejem na identifikovaného respektovat toto rozhraní.
41 e*neschopenka OSSZ Logistika a systém příručních pacienta. Bude rozšířen NIS o řešení příručních
skladů včetně napojení na Systém bude součástí NIS a přímo skladů, včetně strukturované medikace a
(e*neschopenka) centrální sklad (lékárna). propojen se strukturovanou medikací a výdeje léků na identifikovaného pacienta.
výdejem léků na identifikovaného
42 Logistika Logistika a Elektronická výměna pacienta.
příruční sklady zdravotnické dokumentace se V současnosti nemocnice provozuje
subjekty mimo zdravotnické spisovou službu bez napojení na NIS.
43 SPIS Spisová služba zařízení, kteří nejsou zapojeni Spisová služba není napojena na žádný Ne Součástí rozvoje NIS musí být vytvoření
do jiného způsobu výměny systém výměny zdravotnické
zdravotnické dokumentace dokumentace ani na elektronický integračního rozhraní na tento systém a
(např. soudy, policie apod.) archiv.
zajištění vzájemné výměny dat a ukládání
dat ze spisové služby vztažená
k dokumentaci pacientů do
elektronického archivu – příjem a
odesílání zdravotnické dokumentace,
evidence a vyřizování žádostí o
Strana 19 / 127
# Zkratka Název Účel Současný stav Modernizace/rozvoj Popis modernizace/rozvoje
Ano zdravotnickou dokumentaci o ošetření
44 eHealth eHealth kraje Napojení na eHealth systém V současné době není NIS připojen pacientů, hlášení SÚKL o lécích (stažení,
(NIX ZD, eH NCP) Středočeského kraje pro k žádnému systému výměny špatná šarže atd.)
45 NIA zajištění výměny zdravotnické zdravotnické dokumentace na národní Dodávka konektoru pro připojení
46 IS ZR Národní bod pro dokumentace s dalšími ani nadnárodní úrovni. k eHealth systému kraje a zajištění
identifikaci a poskytovateli zdravotních výměny ZD s tímto systémem a
autentizaci služeb. V současné době není NIS připojen na zapojenými poskytovateli ZS zapojenými
Prostřednictvím tohoto žádný systém zajišťující autentizaci a k tomuto IS.
Informační systému bude NIS napojen do identifikaci pacientů. Napojení na NIX ZD ani na eH NCP není
systém výměny ZD na národní úrovni součástí projektu, toto bude zajištěno
základních (NIX ZD, eHealth systémy NIS není napojen na IS ZR. v rámci rozvoje eHealth systému kraje.
registrů dalších krajů) a systém pro
nadnárodní výměnu ZD (eH Ano Pokud bude systém připraven do doby
NCP) Dle dostupnosti dokončení realizace projektu, je
Zajištění autentizace a předmětem integrace na tento systém,
identifikace pacienta při jinak bude zajištěna v rámci udržitelnosti
přihlášení k portálu pro projektu v rámci legislativních úprav
elektronické objednávání systému.
pacientů na vyšetření a při
ověřování identity pacienta
z eHealth systému.
Napojení na registr obyvatel
pro zajištění validity osobních
údajů.
Tabulka 3: Koncept/architektura požadovaného řešení
Požadavky na funkce požadovaného řešení jsou uvedeny v následujícím textu.
Strana 20 / 127
3.3.2 Obecné požadavky
V této kapitole jsou uvedeny základní (minimální) požadavky na požadované řešení:
# Požadavek
P.1 Řešení bude v souladu s legislativou uvedenou v kapitole 6.2 - Legislativa.
P.2 Dodávaný systém musí svojí architekturou splňovat obecné zásady informační bezpečnosti
v míře, odpovídající charakteru užití a kategorii zpracovávaných dat (GDPR).
P.3 Dodávaný systém musí být přehledný, logicky členěný a srozumitelný (user friendly). Aplikace
musí obsahovat interaktivní nápovědu.
P.4 Tiskové výstupy musí být v souladu a ve formátu předepsaném příslušnou legislativou a
interními akty Objednatele. Vizuální úprava výstupů bude navržena dodavatelem a realizována
buď systémem uživatelských šablon umožňující úpravy Objednatelem, případně úpravy
dodavatelem jako povinná součást provozní podpory.
Moderní dlouhodobě perspektivní komerčně dostupný systém.
P.5 Řešení musí být založené na současných obecně dostupných a moderních technologiích a
standardech s perspektivou rozvoje a podpory min. 10 let.
P.6 Řešení musí být založené na komerčně dostupném a procesně orientovaném systému,
customizace musí být řešena konfiguračně a proveditelná interními správci aplikace.
P.7 Řešení musí podporovat na straně klienta práci na zařízeních ve standardním prostředí MS
Windows. (PC, notebooky, vč. podpory zařízení s dotykovými obrazovkami), v prostředí
mobilních zařízení (tablety, mobily) a práci s dotykovými zařízeními v těch částech řešení, která
jsou určena pro podporu procesů např. u lůžka pacienta.
P.8 Zaručená perspektiva rozvoje a podpory je minimálně po dobu dalších 10 let od uvedení do
provozu v rámci celé ONP.
P.9 Řešení musí být v souladu a podporovat mezinárodní a národní standardy jako např. MKN 10.
Řešení by také mělo dle potřeby umožňovat jednoduchou integraci dalších klasifikací.
P.10 Řešení musí být homogenní z hlediska databázového prostředí, musí použit pouze jeden typ
databáze (např. MS SQL, aj.) pro celé řešení a optimalizovaný licenční model.
Uživatelské prostředí (Grafické prostředí)
P.11 Uživatelské prostředí je jednotné v celém rozsahu a založené na standardech prostředí
Microsoft Windows.
P.12 Systém musí umožnit individuální nastavení pracovní plochy, podporovat práci ve více oknech
současně.
P.13 Pracovní plocha musí být nastavitelná a umožnit změnu velikosti zobrazovaných informací dle
potřeb uživatele.
Strana 21 / 127
# Požadavek
P.14 Uživatelské prostředí umožňuje odlišná nastavení pro různé typy provozů (ambulance,
hospitalizace, odlišné typy lůžkové péče, operační sály).
P.15 Při práci s pacientem musí být na pracovní ploše vždy k dispozici jeho aktuální údaje s možností
jejich editace.
P.16 Prostředí umožňuje práci s více pacienty najednou. U jednotlivého pacienta může být zároveň
editováno více dokumentů/zpráv různých typů.
P.17 Uživatel musí mít možnost dostávat on-line zprávy o definovaných událostech a stanovených
úkolech.
P.18 Podpora pro zavedení standardních léčebných postupů/klinických protokolů. Uživatel má
možnost být veden v péči o pacienta standardním dohodnutým postupem. Systém umožní
správnost postupu kontrolovat.
P.19 Systém umožňuje vytváření grafů z vybraných dat (např. naměřené údaje z přístrojů) a
zobrazování dat v časových osách.
P.20 V textovém editoru umožnit formátování textu (volba písma, podržení, tučnost, kurzíva atd.).
Číselníky
P.21 Sdílení číselníků mezi jednotlivými částmi systému.
P.22 Správa číselníků: Systém musí disponovat aplikací (rozhraním), které umožní aplikačnímu
administrátorovi spravovat jednotlivé číselníky. Veškeré číselníky řešit jako historické. Aplikace
musí aplikačnímu administrátorovi umožnovat delegaci oprávnění pro správu jednotlivých
číselníků nebo určené množiny pro pracovníka, zařazeného do jiné role.
Tiskové výstupy
P.23 Tiskové výstupy musí být individuálně konfigurovatelné a přizpůsobitelné administrátorem:
• Systém bude umožňovat, aby správce nemocnice mohl tvořit vlastní tiskové sestavy
pomocí standardního dotazovacího jazyka SQL
• Bude k dispozici grafický návrh designu tiskových sestav
P.24 Systém obsahuje tiskové předlohy a uživatel má možnost volby z tiskových předloh. Uživatel
bude mít před tiskem možnost výběru z různých formátů zpráv (možnost volby různých předloh
pro tisk).
P.25 Systém musí umožnit před tiskem náhled na vzhled tištěného dokumentu.
P.26 Systém musí mít vestavěnou podporu pro grafický návrh vzhledu tiskových sestav (na úrovni
správce systému).
P.27 Systém musí umožnit tiskový výstup na arch formátu 3 x A4 vedle sebe (nyní používaný na ARO)
a formát A3.
Strana 22 / 127
# Požadavek
Řízení přístupu k aplikaci (přihlášení)
P.28 Navržené řešení musí být propojeno na systém správy uživatelů (MS Active Directory – MS AD)
nemocnice a musí provádět autentizaci uživatelů vůči této externí autoritě pro zajištění
jednoznačné identifikace uživatele (vč. podpory pro jednotné přihlášení (Single Sign On)).
P.29 Možnost volby způsobu autentizace uživatele přes MS AD nebo s využití technologie Single Sign
On.
P.30 Řešení musí umožňovat snadnou „změnu profilu“ a/nebo „změnu uživatele“ bez nutnosti zavřít
a znovu otevřít aplikaci.
P.31 Automatické odhlášení nečinného uživatele.
Řízení přístupů k aplikačním službám
P.32 Požadujeme hierarchické nastavování přístupových práv dle rolí, možnost definovat rozsah
přístupu i stupně oprávnění manipulace se záznamem (čtení / zápis / změna / mazání).
P.33 Možnost definovat uživatelské role (počet, typ) dle potřeb organizace.
P.34 Možnost omezení přístupu pouze na pacienty vybraného pracoviště nebo na konkrétní typ
dokumentace.
Jazyková mutace
P.35 Navržená uživatelská softwarová aplikace komunikuje v jazyce českém.
P.36 Pro práci správců a administrátorů se u definovaných systémových komponent připouští
komunikace v jazyce anglickém.
Legislativa a další normy
P.37 Soulad s legislativou uvedenou v kap. 6.2.2 – Legislativa specifická pro zdravotnická zařízení
P.38 Systém musí splňovat ustanovení vyhlášky č. 98/2012 Vyhláška o zdravotnické dokumentaci v
aktuálním znění
P.39 Soulad s Nařízením Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o
ochraně fyzických osob (GDPR – General data protection regulation) v souvislosti se
zpracováním osobních údajů a o volném pohybu těchto údajů.
P.40 Soulad se Zákonem č. 181/2014 Sb., o kybernetické bezpečnosti v aktuálním znění a vyhláškou
Vyhláška č. 316/2014 Sb., o kybernetické bezpečnosti v aktuálním znění.
P.41 Možnost tisku legislativně požadovaných dokumentů – informovaný souhlas, poučení před
výkonem, záznamy o osobách blízkých, souhlas s poskytováním informací o stavu pacienta
apod.
P.42 Další legislativa je uvedena dále v kapitole 6.2.
Strana 23 / 127
# Požadavek
Elektronická zdravotnická dokumentace
P.43 Řešení musí umožnit vést zdravotnickou dokumentaci v elektronické formě a umožnit
postupný přechod na vedení zdravotnické dokumentace v elektronické podobě.
Sledování nežádoucích událostí
P.44 Možnost záznamu a evidence nežádoucích událostí (pády, dekubity, záměna pacienta, záměna
strany, chybná medikace) včetně zaznamenání údajů o nápravných opatřeních. Statistické
zpracování údajů o nežádoucích událostech. Vše ve vazbě na systém sledování nežádoucích
událostí UZIS s možností přebírání číselníků z tohoto systému.
P.45 Možnost on-line informování odpovědných pracovníků dle závažnosti a místa vzniku nežádoucí
události.
P.46 Možnost evidence nežádoucích událostí, které se netýkají pacienta.
P.47 Evidence a vyhodnocování nozokomiálních infekcí, ve vazbě na výsledky mikrobiologických
vyšetření, s možností automatického zasílání emailu odpovědným osobám při zápisu
nozokomiální infekce.
P.48 Možnost vynucení zadání nozokomiální infekce při propuštění pacienta.
Ostatní obecné požadavky
P.49 Identifikace pacientů čárovým kódem.
P.50 Připojování přístrojů – systém musí mít možnost načítat a strukturovaně ukládat data z
diagnostických přístrojů, data z monitorů vitálních funkcí, EKG a EEG.
P.51 Zajištění jednotného času na všech pracovištích/zařízeních (synchronizace klientů a systému s
time serverem).
P.52 Optimalizace datové zátěže komunikačního prostředí.
P.53 Možnost tisku průvodních identifikačních štítků pro papírovou dokumentaci, biologické vzorky
apod.
P.54 Možnost definice úkolů (s časovými limity) a událostí pro definované skupiny uživatelů.
Tabulka 4: Obecné požadavky
Pro konkrétní oblasti jsou uvedeny specifické požadavky samostatně v dílčích podkapitolách.
3.3.3 Strukturovaná zdravotnická dokumentace (SZD)
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.55 Elektronické sdílení informací – zdravotnické informace musí být na základě oprávnění
dostupné z jakéhokoliv počítače a v jakékoliv lokalitě. Zdravotnická data musí být spravována
v reálném čase.
Strana 24 / 127
# Požadavek
P.56 SZD musí plnit všechny podmínky, aby bylo možné tuto dokumentaci považovat za
důvěryhodnou, elektronicky archivovat v důvěryhodném elektronickém archivu (v rámci
DMS/Spisové služby) a zajistit její distribuci v elektronické podobě při zachování její
důvěryhodnosti.
Podpora pracovního postupu (workflow) a seznam pracovních úkolů
P.57 Podpora pracovního postupu (workflow) a seznam pracovních úkolů.
P.58 Dojde-li k zadání úkolu do systému, měli by všichni, kdo jsou zapojeni do jeho plnění, obdržet
oznámení v reálném čase, k čemuž může dojít v rámci série činností. Informace musí být
sdíleny v reálném čase mezi jednotlivými zařízeními a všemi zúčastněnými (lékaři, sestrami a
dalším nelékařským zdravotnickým personálem, pracovníky kartotéky a dalšími).
P.59 Řešení nabízí kontrolní seznam, který může pomoci při vyplňování relevantních částí
dokumentace v průběhu léčby
Dokumentace
P.60 Řešení musí nabízet lehce přístupnou tabulku nebo obrazovku určenou k prohlížení
elektronické zdravotní dokumentace (EZD) jednotlivých pacientů. Prohlížeč EZD by měl
rovněž uživateli umožňovat přejít na dílčí záznamy v EZD pacienta.
P.61 Systém musí umožňovat jednoduchý pohled na veškerou dokumentaci pacienta přes všechna
oddělení a ambulance v celé její historii.
P.62 V systému bude možné strukturované a parametrizovatelné zadávání údajů s možností sdílení
jednotlivých položek v dalších dokumentech, s možností nastavení jednotlivých položek
(povinný údaj, možné hodnoty) a vlastních číselníků pro jednotlivé položky,
předdefinovaných textů a šablon, možnost nastavení kontrolních funkcí.
P.63 Sdílení jednotlivých položek dokumentace v dalších dokumentech pro vyšší efektivitu práce a
minimalizaci přepisování vložených údajů. Formuláře / zprávy umožňují vzájemný
automatický přenos dat mezi sebou a jinými částmi NIS (např. výsledky vyšetření, přístrojová
data, příruční (klinické) sklady, ošetřovatelská dokumentace).
Příkladem je možnost přenosu obsahu předchozí zprávy do nové zprávy a tím omezení
nutnosti přepisování nebo ručního kopírování dat do nové zprávy. V nové zprávě bude text
upraven uživatelem do konečné podoby nové zprávy.
P.64 Dokumenty/zprávy umožňují výpočty a logické vazby, na základě zadaných / přenesených
údajů, tato „vnitřní logika“ umožňuje okamžité přizpůsobování dokumentu definovaným
způsobem.
P.65 Možnost souběžně pracovat s více otevřenými dokumenty (pacienty) bez nutnosti zavírat
rozepsaný dokument.
Strana 25 / 127
# Požadavek
P.66 Možnost zapisovat k pacientovi významné informace, které budou viditelné i v přehledu
pacientů.
P.67 Koncový uživatel musí mít možnost ovlivnit výčet informací v přehledech pacientů a jejich
pořadí.
P.68 Možnost spravovat pacientova specifická přání (právní dokument) týkající se léčby.
P.69 Možnost fultextového vyhledávání v pacientské dokumentaci a možnost vyhledávání podle
klíčových slov.
P.70 Možnost evidovat a zobrazovat stav dokumentu (rozepsán, dokončen, uzavřen).
P.71 Možnost pozdějšího připojení dočasných záznamů o případu léčby (emergency) ke správným
záznamům, a to i v případě externích systémů.
P.72 Dokumentace umožňuje tvorbu interaktivních záznamů urgentního příjmu,
anesteziologických záznamů anebo denních dekurzů jednotek intenzivní péče včetně
přístrojových dat formou časové osy se záznamem událostí.
P.73 Možnost do dokumentace vkládat multimediální data jako jsou obrázky, video, zvuk,
vykázané výkony a materiál, poplatky. Možnost do obrázků zakreslovat značky, popisky aj. a
celé to ukládat v dokumentaci pacienta. K dispozici jsou nástroje a symboly ke grafickému
znázornění poranění a poškození těla (rány, popáleniny, jizvy, zlomeniny) a používaných
prostředků (invazivní vstupy – katetry, drény). Řešení musí umožnit snadný záznam zranění a
jiných změn na lidském těle prostřednictvím přizpůsobitelných šablon a schémat lidského
těla. Možnost kreslit na ně a pomocí kalkulačky spočítat plochu rány, atd.
P.74 Řešení musí umožnit oprávněným uživatelům vkládat skenované dokumenty do zdravotnické
dokumentace pacienta (dokumenty, které s sebou pacient přinesl) v běžných formátech jako
je PDF, DOC, XLS či JPEG. Musí být zajištěna nezměnitelnost těchto souborů, podpora formátů
archivních PDF (PDF/A).
P.75 Přikládané dokumenty (souborové přílohy k pacientské dokumentaci) musí být ukládány do
databáze NIS.
P.76 Řešení umí u definovaných typů údajů sledovat čas posledního zadání a upozornit
v přednastaveném intervalu na potřebu aktualizace, a to bez ohledu na aktuální typ péče
(ambulantní či hospitalizační). Tento interval může být různý pro různé typy údajů
(onkologická prevence, přehodnocení skórovacích systémů). Tyto záznamy mohou být
součástí různých dokumentů/zpráv v závislosti na typu péče.
P.77 Předávání pacientů – řešení musí obsahovat nástroj pro předávání pacientů
hospitalizovaných i ambulantních, který mohou využít lékaři a sestry při výměně služeb či
v době jejich nepřítomnosti na pracovišti.
P.78 Edukace pacienta – řešení musí obsahovat možnost chronologicky vést dokumentaci edukace
pacienta během hospitalizace i ambulantní péče, tj. zaznamenávat témata a obsah edukace,
Strana 26 / 127
# Požadavek
osvojené návyky, dovednosti, důvody, proč edukaci, nácvik opakovat. Nezbytná je
administrativní podpora – strukturované záznamy, výběr z číselníků a předefinovaných
schémat a textů. Systém by měl upozornit, jaký edukační nebo informační materiál může být
k edukaci použit.
P.79 Dodávka výchozích dokumentů/zpráv je součástí prvotní dodávky. Případná úprava
dokumentů/zpráv je možná administrátorem systému.
P.80 Řešení umožní sběr dat a elektronické vykazování do národních registrů, u kterých v době
dodávky řešení existuje na straně UZIS funkční rozhraní.
P.81 Záznamy i nahlížení do dokumentace musí být auditovatelné.
Vedení elektronické zdravotní dokumentace
P.82 Navržené řešení musí umožnit realizaci vedení zdravotní dokumentace pouze v elektronické
podobě (minimálně v rozsahu uvedeném výše) jako důvěryhodnou elektronickou
dokumentaci (EZD).
P.83 Vedení elektronické zdravotní dokumentace musí vyhovovat předpisům o elektronické
důvěře eIDAS.
P.84 Systém musí umožnit práci s elektronickými identifikátory a využívat vzdálený dlouhodobý
důvěryhodný elektronický archív
P.85 Systém musí umožnit využití biometrického podpisu pro podpis dokumentace pacientem
(např. informovaný souhlas), aby bylo možné vedení dokumentace v elektronické podobě.
Textový editor
P.86 Textový editor musí být vestavěnou součástí dodávané softwarové aplikace.
P.87 Textový editor musí umožnit základní formátování písma a kontrolu pravopisu.
P.88 Zahrnuje tvorbu a používání uživatelem předdefinovaných textů s možností vkládání do
dokumentace pomocí klávesových zkratek. Na předdefinované texty je umožněno navázat
další skutečnosti – pořízení výkonů, ZUM, ZULP a spouštění dalších SQL dotazů s výstupem do
textu.
P.89 Možnost vkládat části dokumentace do psaného textu pomocí drag/drop funkce.
P.90 V textových částech dokumentace je možné vkládání obrázků.
Ostatní požadavky
P.91 Všichni oprávnění zdravotničtí pracovníci by měli mít přístup k informacím o stávající či
předchozí léčbě pacienta. Veškerá léčba musí být ve výchozím režimu zobrazena na časové
ose. Informace o léčbě musí být uspořádány dle druhu, pracovníka, data příjmu a propuštění.
Strana 27 / 127
# Požadavek
P.92 Elektronické diáře – systém umožňuje vést elektronické diáře pro objednávání pacientů a
jednoduchou správu pomocí drag/drop funkcí použití barev a grafiky. Možnost odesílání
elektronických zpráv pacientům (formou SMS nebo e-mailů).
Denní / týdenní / měsíční plánování vyš., automatické zařazování elektron. žádanek do
denního plánu dle objednání, automatická dostupnost žádanek pro daný den na daném
pracovišti.
Tabulka 5: Strukturovaná zdravotnická dokumentace
3.3.4 Operační sály
Tato část NIS ONP je podmnožinou strukturované zdravotnické dokumentace. Nad rámec požadavků na
tuto dokumentaci jsou pro tuto oblast následující požadavky:
# Požadavek
P.93 Řešení musí poskytovat specifický modul, který umožní administraci a správu údajů o
pacientech na operačních sálech. Tento modul musí zahrnovat plán operačních zákroků, který
obsahuje jednotlivé zákroky, časový rozvrh, poznámky, potřebné zdroje a možnost
autorizovaných změn.
Objednávání na operaci
P.94 Řešení musí umožnit objednávání pacientů k plánovaným a neplánovaným operacím na
operačních sálech (s návazností na diáře lékařů) s podporou plánování jednotlivých
operačních sálů (úroveň sál, klinika/oddělení, centrální operační sál, nemocnice) a to i několik
měsíců dopředu, musí být umožněn náhled i editace, vyžaduje se přístup i z míst mimo
nemocnici přes zabezpečené webové rozhraní.
P.95 Možnost náhledu na obsazenost sálů s automatizací vyhledávání volných termínů s podporou
tzv. waiting listů vázaných na druh výkonu a plátce péče, u plánovaných operací spojené s
vyhledáváním termínu přijetí pacienta k hospitalizaci. Možnost automatického či manuálního
výběru termínu operace.
P.96 Vyhledávání primárně na vlastním pracovišti, anebo také v rámci centrálních operačních sálů
a dalších sálů nemocnice, možnost plánovat pacienta k výkonu i na sály jiného pracoviště.
P.97 Odlišení akutních a neakutních operací.
P.98 Řešení musí umožňovat nastavení obvyklé nebo odhadované operační doby u jednotlivých
zákroků za účelem usnadnění plánování operačního rozvrhu. K jednotlivým typům zákroků
lze nastavit i další atributy pro plánování kapacity – požadavek na přístrojové či materiálové
vybavení, tým a typ pooperační péče.
P.99 Řešení musí umožnit vytváření předem definovaných týmů, které obvykle pracují v daném
složení na operačním sále, a také přidělování úkolů a zodpovědností jednotlivým členům
týmu. Řešení musí umožnit zadání pravidelného denního rozpisu lékařů, ÚPS či jejich
nepřítomnosti a přizpůsobit plánovaní.
Strana 28 / 127
# Požadavek
P.100 Musí být umožněno plánování operací jiné odbornosti formou požadavku na operaci, tedy
bez přímého určení plánovaného termínu operace (tento termín si následně stanoví
poptávané pracoviště).
P.101 Možnost opatření operačního dne (ad hoc) poznámkou a/nebo vyhrazeným slotem pro
jakoukoliv odbornost.
P.102 Možnost ad hoc vyblokování sálové kapacity (např. sanitární den, oprava apod.).
P.103 Řešení musí obsahovat přehled objednacích termínů pro jednotlivé typy výkonů.
P.104 Možnost volby rentgen, foto video – při zaškrtnutí se připraví žádanka na dané pracoviště.
Tvorba operačního programu
P.105 Kontrola kolizí vybavení/týmů – např. překryv operací apod. Vytvoření operačního programu
(sál, pořadí pacientů, jméno, příjmení, rok narození pacienta, operace, požadavky – poloha,
antibiotika, krev, JIP, tým). Možnost vytvoření strukturovaného denního rozpisu lékařů (práce
na ambulanci, oddělení, jiné činnosti, nepřítomnosti, ÚPS) kliniky/oddělení na následující
operační den, s těmito údaji následně počítat při kontrolách kolizí (např. lékař na dovolené
nebo na ambulanci nemůže být současně na op. sále).
P.106 Řešení musí umožnit zadat ke každé operaci neomezený počet sledovaných časů, musí být
možnost nastavit některé z těchto časů jako obligatorní a některé jako fakultativní. Musí být
umožněno přidávat a ubírat časy podle potřeb zadavatele bez znehodnocení statistik.
P.107 Uzavření a schválení operačního programu. Možnost vygenerování a odeslání operačního
programu emailem (např. v PDF dokumentu).
Řízení operačního dne
P.108 Řešení musí obsahovat specifický přehled, který zobrazí globální přehled sálů včetně všech
plánovaných operačních zákroků na daný den, přidělení operačního sálu, stavu operačního
sálu a jeho dostupnosti a informace, v jaké fázi je daný operační zákrok a jaký je stav pacienta
(přebírá údaje ze záznamů z operačního sálu až po předání pacienta na pooperační pokoj, a
to včetně celkové délky operace a nařízených úkonů). Všechny operační zákroky musí být
aktualizovány v reálném čase.
P.109 Možnost přesunu či vyřazení pacientů v rámci aktuálního dne s uvedením důvodu změny.
Možnost přidání akutních pacientů.
Dokumentace
P.110 Řešení musí umožnit zadokumentování celého operačního zákroku prostřednictvím
formulářů s údaji, jejichž formát odpovídá požadavkům daného zařízení, operačnímu zákroku
a profilu. Jde především o časovou dokumentaci jednotlivých kroků operace, řešení musí
umožnit automatizovanou evidenci časů.
Strana 29 / 127
# Požadavek
P.111 Zápis operačního protokolu (záznamu o výkonu) a anesteziologického protokolu dle
definovaných pravidel. Součástí jsou podklady pro vykázání výkonů a materiálů plátci péče a
UZIS.
Předoperační úkony
P.112 Řešení musí poskytnout část vyhrazenou pro údaje o předoperační péči, kde mohou uživatelé
zadokumentovat:
1. Polohování - uživatelé musí mít možnost nařídit a zadokumentovat způsob polohování
pacienta (např. polohu těla a končetin, předepsané masáže a použití ochranných
pomůcek).
2. Vyhodnocení ošetřovatelské péče - zdravotní sestry (střední zdravotnický personál) musí
mít možnost zadokumentovat informace o fyzickém, psychickém, sociálním a
emocionálním stavu pacienta a zadat do systému poznámky.
3. Rezervy – řešení musí umožňovat, aby si uživatelé zvolili navíc k předefinovaným
sestavám různé druhy zdrojů pro budoucí použití, jako např. krev a krevní deriváty,
nástroje a jiné vybavení.
4. Výsledky předoperačního vyšetření
P.113 Dokumentace perioperačního bezpečnostního procesu, včetně vyplnění verifikačního
protokolu.
P.114 Předávání pacienta v rámci přípravy operace, během operace a po operaci – zahájení na
lůžkovém oddělení, předat na anesteziologii, sestry na sále a ukončí sestry na lůžkovém odd.
po ukončení kritického období pacienta.
Údaje o průběhu operace
P.115 Řešení musí poskytnout část vyhrazenou pro údaje o operačním zákroku, kde mohou
uživatelé zadokumentovat veškeré údaje o průběhu operačního zákroku dle následujících
bodů:
1. vedení záznamu perioperačních sester
2. evidence spotřeby sterilizovaného materiálu na pacienta
3. evidence zdravotnických prostředků na pacienta
4. evidence veškerého spotřebovaného materiálu na pacienta
5. zadání všech provedených výkonů, ZUM, ZULP, použitých přístrojů
6. evidence definovaných časů k operaci (typy časů a povinnost jejich zadávání jsou
přístupné administrátorovi systému)
V rámci integrace budou využívána data ze stávajícího systému Doctis.
Přehledy
P.116 Možnost statistického zpracování údajů o operaci (pro vedení nemocnice i pro odborné
účely).
Strana 30 / 127
# Požadavek
P.117 Vytváření uživatelsky definovatelných sad statistik a přehledů ze strukturovaných dat o
operaci zadaných do systému.
Tvorba anesteziologického protokolu
P.118 Možnost záznamu o předanestetickém vyšetření, anestezii, zápis anesteziologického
protokolu dle definovaných pravidel.
P.119 Všechny předoperační údaje včetně výsledků předoperačních vyšetření. Tato část musí
zahrnovat následující údaje:
1 Předoperační diagnóza - uživatelé musí mít přístup k seznamu nejčastějších diagnóz, aby
mohli zadat konkrétní a obecné informace k operaci. Musí zde být uvedeny všechny
diagnózy, které byly posuzovány při předchozí léčbě.
2 Posouzení výsledků předoperačního vyšetření - řešení musí zahrnovat několik vzorů a
volných textových polí pro různá hodnocení výsledků předoperačního vyšetření, jako
např. kontrolu fungování hlavních soustav těla a předoperační vyšetření anesteziologa
v den provedení zákroku (včetně skóre dle stupnice ASA).
3 Operační postup - uživatelé musí mít možnost zadokumentovat v systému popis průběhu
operace a evidovat tým, který zákrok prováděl.
P.120 Anesteziologický protokol:
1 Vyhodnocení průběhu operace - tato část musí zahrnovat min. vyhodnocení údaje o
poslední kontrole před podáním anestetik a o uvedení pacienta do umělého spánku.
2 Záznam o zákroku - uživatelé musí mít možnost uložit zprávu anesteziologického týmu,
která zahrnuje i záznam nepříznivých reakcí pacienta v průběhu operace.
3 Záznam musí umožnit načtení přístrojových dat na časové ose se záznamem událostí
4 Záznam musí umožnit zadávat data ke sledování kvality anesteziologické péče
5 Vyhodnocení ošetřovatelské péče - během operace musí mít ošetřovatelský tým
možnost zadávat do systému údaje o stavu pacienta
6 Možnost stanovení způsobu pooperační péče a způsobu pooperačního sledování
Údaje o pooperačním stavu
P.121 Uživatelé musí mít možnost zadávat do systému hodnocení pooperačního stavu pacienta, a
to včetně údajů o zdravotním stavu, zákrocích, výsledků pozorování stavu pacienta a údajů o
léčbě během pooperační rekonvalescence/fáze vysoké závislosti na péči druhých osob.
Záznam musí umožnit i načtení přístrojových dat na časové ose se záznamem událostí.
Ostatní požadavky
P.122 Protokoly – v systému musí být k dispozici seznam operačních protokolů. Protokoly stanovují
úkony, které mají být provedeny.
Strana 31 / 127
# Požadavek
P.123 Vytváření operačních a hospitalizačních procesů – systém musí obsahovat funkci, která
odbornému zdravotnickému pracovníkovi umožní odeslat pacienta podle potřeby na další
léčbu.
P.124 Integrace na operační sály a operační management operačních sálů: přenos ZUM/ZULP, diářů,
identifikace pacienta, operatéra apod.
Viz kap. 6.5.2 – Informační systémy, které budou dotčeny projektem.
P.125 Možnost evidence zdravotnických (i jednorázových) materiálů – zajištění vedení příručního
(klinického) skladu, podpora objednávání zdravotnického materiálu a léčiv na základě
evidence vydaných položek – vše v návaznosti na systém logistiky ONP (v i mimo NIS ONP).
Návaznost na systém logistiky a příručních skladů – viz kap. 3.3.19 – Logistika a příruční
(klinické) sklady SZM a LP.
Spotřebované ZUM/ZULP musí být vykázány k výkonům a pacientovi v rámci NIS.
P.126 Monitoring – řešení musí umožňovat sledování základních životních funkcí; musí umožňovat
oprávněným zdravotníkům vyžádat kontinuální sledování a kontrolu základních životních
funkcí a určit, které z funkcí monitorovat a v jakém časovém intervalu.
P.127 Možnost popisování snímků a prohlížení ambulantní i lůžkové dokumentace v jediném
programu.
Tabulka 6: Operační sály
3.3.5 Hospitalizační provoz (evidence hospitalizovaných, lůžkové oddělení)
Tato část NIS je podmnožinou strukturované zdravotnické dokumentace. Nad rámec požadavků na tuto
dokumentaci jsou pro tuto oblast následující požadavky:
# Požadavek
P.128 Podpora administrativy a organizace práce na lůžkovém oddělení, pro vedení pacientské
dokumentace, zajištění nezbytných statistik a vyhodnocení základních parametrů oddělení.
Řešení musí umožňovat vedle pořizování záznamu psaným textem i datový záznam pomocí
diktování a převodu mluveného slova na text.
P.129 Možnost definovat příjmový proces s kroky, které vykonává sestra, lékař a administrativní
pracovník: vyhledání/zadání pacienta z/do registru, zadání dat o pacientovi, o hospitalizaci, o
pojištění, uložení na lůžko, anamnéza, trvalá medikace, lékařská příjmová zpráva, diagnózy,
vstupní vyšetření, ošetřovatelská anamnéza včetně rizik a ošetřovatelský plán péče. Systém
musí umožnit hlídání neprovedených kroků tohoto procesu a úkolování uživatele/role.
Možnost vyhodnocování doby vzniku dokumentace (dle akreditačních požadavků) a on-line
upozorňování na blížící se termín.
P.130 Možnost sdílení dokumentace pacienta mezi lékařem a sestrou při zachování práv čtení a
zápisu.
Strana 32 / 127
# Požadavek
P.131 Zabezpečení administrativních úkonů v průběhu hospitalizace pacienta – překlady,
propuštění. Podpora správného vykazování, kontrola všech povinných údajů, potřebná
hlášení za stanici, oddělení.
P.132 Plánování a řízení obsazenosti lůžek – řešení musí poskytovat nástroj, který odborným
zdravotnickým pracovníkům umožní získat přehled o lůžkách, pokojích a odděleních ve vztahu
k jejich obsazenosti a stavu lůžek. Je také nutné, aby bylo možné přidělovat pacientům
konkrétní lůžko v okamžiku jejich hospitalizace nebo blokovat lůžka pro plánované pacienty
k hospitalizaci.
P.133 Přiřazování lůžek – zdravotnický pracovník musí být schopen přidělit pacientovi konkrétní
lůžko výběrem ze seznamu, který bude sestaven na základě aktuálních údajů o odděleních,
jednotkách a lůžkách v daném zdravotnickém zařízení. Kromě přidělení lůžka musí systém
umožnit přidělení definovaných typů lůžek: antidekubitní matrace dle rizika vzniku dekubitů,
elektricky ovládaného lůžka, sníženého lůžka, polohovacího lůžka na ARO a JIP např.
s možností pronační polohy.
P.134 Úplná anamnéza pacienta – uživatel má možnost zadokumentovat pacientovu anamnézu a
kdykoli znovu zobrazit a získat dříve zadané údaje.
P.135 Zpráva o přijetí pacienta k hospitalizaci – lékař má možnost zadokumentovat stav pacienta
v okamžiku jeho přijetí k hospitalizaci.
P.136 Diagnóza – systém umožní zvolit několik diagnóz či vyhledávat ve skupinách diagnóz na
základě mezinárodní klasifikace chorob a onemocnění MKN 10.
P.137 Dieta – v rámci řešení musí být možné operativně objednat, měnit a rušit přidělenou dietu i
s ohledem na příjem, propouštění či naplánovaný zákrok s omezením stravy, přidělovat
konkrétní diety pacientům a tisknout dietní plány.
P.138 Polohování – uživatel má možnost označit jednotlivé polohovací techniky, určit pořadí poloh,
nastavit intervaly otáčení pacientů a indikovat potřebu případných dalších ošetřovatelských
postupů – dechové rehabilitace, atd.
P.139 Monitoring – určení kontinuálního sledování a kontroly základních životních funkcí s
požadovaným časovým intervalem (viz také P.119). Řešení dále musí umožnit záznam
základních životních funkcí a ostatních ukazatelů. Tyto hodnoty musí být k dispozici pro účely
analýzy a musí být zobrazeny v mřížkách spolu s informacemi o vývoji hodnot. Uživatel musí
být schopen sledovat vývoj hodnot základních životních funkcí pomocí grafů.
P.140 Přeložení pacienta na jiné oddělení – systém musí umožňovat předávání péče o pacienty a
zodpovědnosti za ně mezi jednotlivými odděleními. Odborný zdravotnický pracovník by měl
být schopen vybrat v systému cílové oddělení (pracoviště), uvést důvod pro přeložení
pacienta a vyžádat si potvrzení o převzetí pacienta z oddělení, kam je pacient překládán.
Strana 33 / 127
# Požadavek
P.141 Vytváření operačních a hospitalizačních procesů – systém musí umožnit vytvářet a plánovat
operační a hospitalizační procesy.
P.142 Konzultace – systém musí umožnit požádat o konzultaci ostatní lékaře a sjednat pacientovi
návštěvu na jiném specializovaném oddělení či vytvořit žádanku.
P.143 Záznamy JIP – systém musí umožňovat tvorbu interaktivních záznamů urgentního příjmu
anebo denních dekurzů jednotek intenzivní péče včetně přístrojových dat formou časové osy
se záznamem událostí.
P.144 Plánování a řízení obsazenosti lůžek – systém musí umožnit plánování propouštění pacientů.
Označení nemocných určených k dimisi k určitému datu. Systém musí poskytovat
funkcionalitu, ve které pracovníci zdravotnického zařízení mohou zaznamenat informace o
plánech na následnou péči o pacienta, instrukce k propuštění pacienta z péče, a také
doporučení ohledně následné péče. Pracovníci musí být schopni zadat informace, jako je
konečná diagnóza, předepsané léky, instrukce k propuštění pacienta, termíny dalších návštěv
zařízení a poznámky pro kolegy.
P.145 Upozornění – řešení musí obsahovat systém upozornění uživatelů, jako např. upozornění na:
1. předchozí a aktuální medikaci včetně interakcí mezi léky;
2. alergie;
3. choroby;
4. infekční onemocnění;
5. výsledky laboratorních testů či zobrazovacích vyšetření;
6. vzorky, které by měly být odebrány;
7. žádosti o konzultace;
8. pacienty, kteří nenavštívili zařízení do předem určené doby;
9. ostatní.
P.146 Řešení společného lůžkového fondu – v případě sdílených lůžkových kapacit mezi několika
odbornostmi systém musí být schopen alokovat konkrétního pacienta na jednu z nich a
následně k ní vázat navázané údaje (výkony, spotřeby léků, materiálu, …). Systém musí být
schopen provádět statistiky využití sdílených kapacit mezi tyto odbornosti.
P.147 Možnost on-line hlášení příchozího statimového nálezu.
P.148 Informování koncového uživatele o vyžádaném konziliu.
P.149 Možnost pohledu do historické dokumentace pacienta.
P.150 Žádanky na ostatní oddělení elektronicky/automaticky na příslušné oddělení bez nutnosti
tisku na žádajícím oddělení.
P.151 Kontrola příjmu léčiv a jejich výdeje.
Vedení dokumentace
Strana 34 / 127
# Požadavek
P.152 Vedení strukturovaného denního dekurzu. Přizpůsobení potřebám standardních oddělení a
pracovištím JIP a ARO.
P.153 Možnost průběžného popisu stavu pacienta s jednoznačnou identifikací kdo a kdy zápis
provedl a přehledné zobrazení jednotlivých zápisů.
P.154 Možnost elektronického vedení teplotky – možnost zobrazit průběžně data pacienta (léky,
pokyny sestře, měřené hodnoty apod. za volitelný počet dnů) – na časové ose, vše na jedné
obrazovce a to v číslech i graficky. Možnost přímo z teplotky zadávat medikace, podávat léky.
P.155 Možnost ordinace potřebných vyšetření a pokynů sestře.
P.156 Zadání TISS protokolu, skórovacích schémat (SOFA, APACHE II, NIHSS).
P.157 Vedení bilance tekutin a měřených údajů.
P.158 Možnost přizpůsobit tisky dekurzu.
P.159 Možnost elektronického vedení medikací a jejich napojení na logistický systém.
P.160 Možnost vedení strukturované sesterské dokumentace (ošetřovatelské anamnézy,
ošetřovatelského plánu s hodnocením, překladové zprávy, screeningová vyšetření sestrou –
riziko pádu, riziko dekubitů, test soběstačnosti, nutriční screening).
P.161 Systém musí umožňovat elektronické posílání žádanek na různé druhy vyšetření (laboratoř,
RTG, patologie atd.) a elektronický přenos nálezů zpět na žádající pracoviště.
P.162 Přehledné zobrazení výsledků vyšetření laboratorních, RTG, konzilií, možnost jejich
jednoduchého přenosu do vytvářených dokumentů.
P.163 Lékařské propuštění pacienta z oddělení – tvorba propouštěcí dokumentace (propouštěcí
zpráva, předběžná propouštěcí zpráva, list o prohlídce mrtvého, průvodní list k pitvě aj.).
P.164 Propouštěcí zpráva se generuje automaticky dle předem dohodnutých pravidel z dosud
pořízené dokumentace.
P.165 Zabezpečení administrativních procesů při propuštění pacienta z oddělení – kontrola úplnosti
a validnosti všech povinných údajů, možnost jejich doplnění při propouštění pacienta. Důraz
na ergonomické chování systému při kontrole chybějících údajů.
P.166 Možnost vedení strukturovaných údajů specifických pro jednotlivé odbornosti s možností
přímého vykazování do národních registrů (onkologie: NOR, Kardiologie: NRKI, NKCHR).
Přehledy a statistiky
P.167 Systém zajistí vytvoření všech výstupů potřebných pro denní hlášení na stanici pro měsíční
hlášení pro ÚZIS.
P.168 Výkonové statistiky - o počtech pacientů, obložnosti, pohybu pacientů, podaných lécích,
provedených výkonech, zadaných ZUM.
Strana 35 / 127
# Požadavek
P.169 Uživatel (správce NIS) musí mít možnost jednoduše vytvořit další potřebné statistiky nad daty
strukturovaně zadanými do NIS, s možností exportu statistických výstupů do MS Excel, MS
WORD, PDF. Možnost vytvářet aktivní sestavy s přímým využitím záznamu (dokumentace
pacienta), který je výsledkem vytvořené sestavy.
P.170 Přehledy u obsazenosti lůžek dle kategorie pacientů.
Tabulka 7: Hospitalizační provoz (evidence hospitalizovaných, lůžkové oddělení)
3.3.6 Ambulantní provoz (ambulance)
Tato část NIS je podmnožinou strukturované zdravotnické dokumentace. Nad rámec požadavků na tuto
dokumentaci jsou pro tuto oblast následující požadavky:
# Požadavek
P.171 Podpora administrativy a organizace práce v ambulanci, pro vedení ambulantní pacientské
dokumentace, zajištění nezbytných statistik a výsledných základních parametrů ambulance.
Systém musí umožňovat pořizování textových dat i pomocí diktování a převodu mluveného
slova na text.
P.172 Řešení musí uživateli umožňovat přístup k souhrnným informacím o návštěvách pacienta ve
zdravotnickém zařízení . Musí být možné získat zprávy o všech souvisejících minulých
událostech. Měly by být k dispozici také další podrobné údaje, jako např. parametry vitálních
funkcí, diagnózy, výsledky vyšetření zobrazovacími metodami, záznamy o užívaných lécích a
vystavené recepty.
Organizace ambulantního provozu
P.173 Možnost definice struktury ambulancí dle organizačního uspořádání – centrální kartotéka pro
více ambulancí, jednotlivé samostatné ambulance. Možnost práce na úrovni ambulantní
kartotéky je nepodkročitelná.
P.174 Zabezpečení procesu příchodu pacienta do ambulanci s definicí work-flow pro dané
pracoviště (zadání/vyhledání v kartotéce, zadání do čekárny, zadání údajů sestrou, vyšetření
pacienta lékařem, objednání pacienta k další návštěvě/na vyšetření, tisk potřebné
dokumentace), možnost automatického vyvolávání jednotlivých funkcí dle nastavení.
P.175 Zadávání údajů o operativních zákrocích a hospitalizaci pacienta – řešení musí poskytnout
uživateli/odbornému zdravotnickému pracovníkovi možnost naplánovat operační zákrok a
hospitalizaci pacienta a zadat údaje o těchto skutečnostech z ambulantního prostředí.
Možnost převedení pacienta z ambulance na hospitalizaci (včetně zadané dokumentace).
P.176 Možnost sledování časů čekání v čekárně, délky vyšetření
P.177 Přehled čekajících pacientů, ošetřených pacientů.
P.178 Možnost výběru pacienta z čekárny k ošetření a automatického otevření příslušné zprávy s
předdefinovanými údaji (text, výkony, materiál, přístroje apod. pro daný typ vyšetření.
Strana 36 / 127
# Požadavek
Lékařská dokumentace na ambulanci
P.179 Důvod návštěvy ambulantního zařízení – lékař by měl být schopen zadokumentovat všechny
symptomy, poruchy, požadavky či obavy, které pacient uvedl jako důvod pro vyhledání
ošetření.
P.180 Možnost zadání minimálně: anamnézy, stavu pacienta, diagnóz, žádanky na potřebná
vyšetření, recepty, poukazy, objednání na další návštěvu.
P.181 Veškeré tisky potřebné dokumentace.
P.182 Všechny potřebné úkony umožnit vykonávat rovnou při zápisu ambulantního vyšetření
P.183 Zadání receptu, výkonů, žádanek a dalších povinných dokumentů.
P.184 Přehledná historie ambulantních zápisů
P.185 Možnost sdílení dokumentace pacienta mezi lékařem a sestrou.
P.186 Možnost současné práce s jedním pacientem pro sestru a lékaře
P.187 Zadávání receptů:
i. on-line informace o preskripci
ii. možnost práce s pozitivním listem
iii. možnost zadání magistra liter
iv. k dispozici on-line informace o lékových interakcích (databáze bude zajištěna
zadavatelem)
v. systém umí evidovat objem preskripce na měsíční (týdenní) bázi pro konkrétní pracoviště,
při předepisování léků a pomůcek na poukaz zobrazuje aktuální cenu předpisu a limit
nastaveného období
vi. eRecept – předávání do eReceptů (viz elektronická preskripce)
P.188 Možnost zařazení pacienta do dispenzárních skupin a práce nad pacienty dispenzární skupiny.
Plánovač
P.189 Komplexní řešení objednávání pacientů k vyšetření v ambulancích, lůžkové části a jiných
specializovaných pracovištích – na konkrétní datum a čas, na druh vyšetření, ke konkrétnímu
lékaři, na dané pracoviště, na operaci.
P.190 řešení musí poskytovat přístup k informacím o různých plánech zavedených během celého
procesu poskytování péče.
P.191 řešení musí poskytovat plánovač s intuitivní funkcionalitou, která umožní uživatelům snadno
identifikovat termíny, na které lze pacienta objednat.
Musí být možné:
1 naplánovat termíny vyšetření, diagnostických testů, operací, sledu procedur (např.
rehabilitačních, v rámci klinického postupu);
Strana 37 / 127
# Požadavek
2 aplikovat filtry v plánovači umožňující sledovat termíny vyšetření z různých úhlů pohledu
(např. všechna vyšetření, pouze první vyšetření, vyšetření u ostatních lékařů a v jiných
specializovaných odděleních);
3 objednat, přeobjednat či zrušit termín vyšetření či testu a také řešit situace, kdy termíny
pro objednání pacientů chybí.
4 Informovat ze systému automaticky prostřednictvím SMS, mailu apod. pacienta o
blížícím se termínu návštěvy lékaře nebo o zrušení či změně termínu
P.192 Kalendář – zobrazení měsíčních či týdenních kalendářů dle potřeb uživatele Kalendář slouží
k zobrazení plánovaných aktivit uživatelů, jako např. schůzek s objednanými pacienty,
operační program apod.)
P.193 Plánování pohotovostí – musí se plánovat personální zajištění služeb stejně jako třeba u
operačních týmů. Službu pohotovosti zajišťují i externí lékaři, kteří musí mít možnost vzdáleně
nahlížet do plánu služeb pohotovostí.
P.194 Možnost vkládat do nálezu obrazové informace, videosekvence či další multimediální
soubory.
P.195 Možnost upozornění systému na definovanou skutečnost (např. pacienti čekající déle než
2 hodiny v čekárně apod.).
P.196 Automatické generování pacientů, kteří nebyli víc než 5 let v ambulanci a nejsou
dispenzarizovaní.
Přehledy a statistiky
P.197 Přehledy minimálně v rozsahu: ambulantní kniha, předepsané recepty, provedené výkony,
zadané ZUM.
P.198 Možnost tvorby ročních ambulantních statistik sledovaných ÚZIS z údajů, které jsou dostupné
v NIS.
Tabulka 8: Ambulantní provoz
3.3.7 Ošetřovatelská dokumentace
Tato část NIS je podmnožinou strukturované dokumentace. Nad rámec požadavků na tuto dokumentaci
jsou pro tuto oblast následující požadavky:
# Požadavek
P.199 Kompletní vedení ošetřovatelské dokumentace dle znění zákona – počet dnů zavedení
P.200 drénů, kanyl atp., koupele, převazy, hodnocení péče a kvality vstupů a kanyl, druhy krytí
invazivních vstupů, hodnocení bolesti, polohování, vertikalizace, edukace atd.
Systém musí podporovat modul ošetřovatelské péče, ve kterém zdravotničtí pracovníci
mohou získat přístup k informacím týkajícím se ošetřovatelské péče a možnost dokumentace
této péče v souladu s oprávněními vyplývajícími z uživatelských profilů – obsahovat záznamy
Strana 38 / 127
# Požadavek
P.201
P.202 ošetřovatelské anamnézy, hodnocení rizik, plánu ošetřovatelské péče, realizace, hodnocení
P.203 péče a edukace pacienta.
P.204
Systém musí automaticky dotahovat všechny již známé skutečnosti v NIS do ošetřovatelské
P.205 dokumentace (např. příbuzný, výška, váha, věk apod.)
P.206 Do plánu péče se automaticky předvyplní ošetřovatelské diagnózy, které odpovídají údajům
P.207 zadaným do anamnézy a hodnotám rizik - Zajistit provázanost dokumentů: z rizik a
P.208 anamnézy generovat ošetřovatelské dg do plánu péče.
P.209
Informace musí být řazeny dle typu léčby a také v chronologickém pořadí. Měly by být
k dispozici i souhrnné informace k ošetřovatelské péči.
Hodnocení rizik – systém musí nabízet lékaři anebo sestře (NLZP) podporu posouzení rizik
jako je např. riziko vzniku dekubitů nebo riziko pádu. Při posuzování jednotlivých rizik musí
řešení nabízet nástroje, které lze použít k určení stupně rizika a možnost jejich přehodnocení
v časovém intervalu, či změně zdravotního stavu pacienta, možnost vytvořit statistické
přehledy a tabulky.
Nástroje k hodnocení stavu pacienta – systém poskytuje nástroje pro hodnocení pacientů
dle zdravotnických a ošetřovatelských parametrů. Tyto nástroje zahrnují např. Barthelův test
základních všedních činností, hodnocení soběstačnosti dle Marečkové, GCS, RASS a další
nástroje. Důležitou součástí je hodnocení a monitorace bolesti pacienta dle VAS a obličejové
škály.
Nástroje k hodnocení stavu pacienta – systém musí podporovat hodnocení stavu nutrice
pacienta včetně historie, záznamy nutričních terapeutů, fyzioterapeutů, ergoterapeutů a
dalších nelékařských odborností.
Kalkulačky – řešení musí nabídnout nástroje, jako např. kalkulačky, které jsou zapotřebí
k výpočtu APGAR skóre, indexu BMI, . Podle potřeby bude možné přidat i další kalkulačky.
Biometrická data – dokumentace biometrických dat pacienta, jako je výška, váha a obvod
hlavy. Tyto hodnoty by se měly využít k automatickým výpočtům, jako je např. BMI.
Ošetření obvazovým materiálem – lékař bude mít možnost objednat ošetření obvazovým
materiálem zdravotní sestrou. Tato objednávka musí obsahovat informace týkající se:
1. místa poranění;
2. datum a souvislosti vzniku poranění;
3. datum prvního ošetření obvazovým materiálem a časový interval, v jakém má být
obvazový materiál měněn;
4. charakteristika poranění (kůže, bolest, velikost poranění a množství exsudátu);
5. frekvence ošetření obvazovým materiálem;
6. Ošetření chronických/nehojících se ran vlhkou terapií a ošetření stomií včetně
dokumentace provádí samostatně sestra se zvláštní odbornou způsobilostí, bez indikace
lékaře;
Strana 39 / 127
# Požadavek
P.210 Ošetřovatelská praxe – ošetřovatelský personál musí být schopen dokumentovat svá
hodnocení týkající se pacienta, zadávat žádanky na ošetřovatelské služby, stanovovat
ošetřovatelské diagnózy a plánovat a vyhodnocovat ošetřovatelskou péči. Musí být možné
kdykoli tyto informace upravovat, dále plánovat propuštění, možnost vyplnění překladové
ošetřovatelské zprávy, řešení sociální situace pacienta po propuštění a řadit pacienty do
fronty zdravotně sociální pracovnice nemocnice do čekárny.
P.211 Bilance příjmu a výdeje tekutin – v rámci prostoru pro hodnocení ošetřovatelské péče musí
být možné průběžně počítat bilanci příjmu a výdeje tekutin.
P.212 Strava pacientů – v rámci záznamu pro hodnocení ošetřovatelské péče musí být možné
průběžně sledovat množství stravy formou zakreslení/zadání velikosti porce pacienta. Díky
propojení se stravovacím systémem je dle zadané diety a množství stravy poskytována
informace o energetickém příjmu a jeho složkách, sledování příjmu energie a živin na
denní/týdenní/měsíční bázi, vedení příjmu potravy včetně její bilance za 24hod.
P.213 Domácí péče – zajištění zápisů z domácí péče.
P.214 Zobrazování a aktivní upozorňování (alarm) na rizikové informace k pacientovi – statimové
výsledky s abnormálníma kritickýma hodnotami.
P.215 Upozornění na denní činnosti v rámci denního plánu v dokumentaci (dnes ráno tlak,
vyhodnotit škálu, zvážit, převaz). Dokud nebude intervence provedena, stále se bude na u
pacienta nabízet/upozorňovat.
P.216 Propouštěcí zpráva sestry – automaticky stahovat do zprávy problémy a plán.
P.217 Anamnéza sester při přijmu – automaticky se vyhodnotí problémy a plán péče.
P.218 Zdravotnické prostředky stahovat pomocí čtečky do dokumentace pacienta.
P.219 Podávání léku přes čtečku.
P.220 Zpracování anamnézy a vytvoření zprávy:
• Lůžkové oddělení na ARO: do 12 hod.
• Ostatní: do 24 hod.
P.221 Zaznamenávat automaticky časy a datumy intervencí.
P.222 Automatické stahovaní informací do propouštěcích a překladových zpráv.
P.223 Možnost záznamu sociální anamnézy (rodina).
P.224 Vedení dokumentace pro paliativní péči.
Tabulka 9: Ošetřovatelská dokumentace
3.3.8 Další specializovaná pracoviště v rámci strukturované zdravotnické dokumentace
Tato část NIS je podmnožinou strukturované dokumentace. Nad rámec požadavků na tuto dokumentaci
jsou pro tuto oblast následující požadavky:
Strana 40 / 127
# Požadavek
Radiodiagnostika / Radiologický modul (včetně dalších zobrazovacích modalit)
P.225 Systém musí obsahovat radiologický modul, do nějž se zapisují záznamy o vyšetřeních, nálezy,
automaticky se do něj převádějí relevantní údaje o pacientech – biometrické údaje, rizikové
faktory, evidence dávek ozáření (historie, kumulace). Systém musí být plně integrován s PACS
– předávání žádanek, přebírání výsledků (strukturovaných popisů) a dávek ionizujícího záření.
P.226 Funkcionality potřebné pro radiologická pracoviště – RTG, sonografie, CT, MR atp.
P.227 Podpora činností pro kartotéku, příjem, popisovnu a vyšetřovnu.
P.228 Možnost nastavení automatického sledu činností, tj. požadavek, aby systém kopíroval práci
koncového uživatele.
P.229 Systém strukturované dokumentace umožňuje vytvářet žádanky na jednotlivá vyšetření /
soubory vyšetření. Do žádanek jsou automaticky doplňovány známé údaje (hmotnost, alergie,
výsledky laboratorních vyšetření, infekční onemocnění, …).
P.230 Nelze odeslat klinikem žádanku bez všech vyplněných / legislativou požadovaných údajů.
P.231 Možnost automatického příjmu žádanek z klinických oddělení nebo zápis žádanky na
vyšetření přímo na RDG oddělení.
P.232 Sledování stavu žádanky (k vyšetření, vyšetřen, k popisu, popsán, vyúčtován apod.) a
filtrování nad stavy. Uchování historie stavu žádanky.
P.233 Možnost nahlížet do dokumentace pacienta při zápisu nálezu.
P.234 Sledování pacienta, kde se nachází a v jaké fázi je zpracování požadavku klinika. Klinika má
možnost vidět jasnou identifikací, že již bylo vyšetření (např. RTG) provedeno, dále možnost
mít otevřené podokno požadavků, kde je mu signalizováno, že má pacient již snímek nebo
laboratoř hotovou.
P.235 Záznam časů a událostí slouží k vytváření reportů.
P.236 Možnost evidence použitých přístrojů, expozic.
P.237 Možnost sledování dávky ionizujícího záření – a to ze všech vyšetření, která pacient prodělal,
ručním zadáním obdržené dávky.
P.238 Automatické vyúčtování výkonů a zadaného materiálu dle provedeného vyšetření.
P.239 Možnost diktovat nález a hlasový záznam automaticky převádět na psaný text do
dokumentace pacienta (funkčnost dostupná v celém systému).
P.240 Možnost uložení zvukového záznamu k nálezu pacienta.
P.241 Použití standardního editoru s možností používání předdefinovaných textů – možnost
strukturovaného popisu, předdefinované texty, výběry z číselníků. Dále víceúrovňové
Strana 41 / 127
# Požadavek
schvalování nálezů, možnost 2. čtení, tedy druhého „uzavření“ popisu, možnost připojit
poznámku, která je relativně stranou popisu.
P.242 Pro popisujícího specialistu možnost náhledů všech vyšetření, epikrízy apod.
P.243 Možnost zobrazení snímků z PACSu dle klinik v různé fázi popisu vyšetření.
P.244 Odeslání nálezu žadateli.
P.245 Objednávkový systém – možnost objednávání pacientů na vyšetření.
P.246 Statistiky provedených vyšetření, výkonů, spotřebovaného materiálu apod., možnost exportu
dat.
P.247 Sledování snímků a expozic.
Rehabilitační lékařství
P.248 Vedení pacientské dokumentace v elektronické podobě na rehabilitačním oddělení a zároveň
systém pro plánování procedur jako integrální součást systému s návazností na centrální
registr pacientů.
P.249 Ucelené řešení pro fyzioterapie – provázanost lékařské dokumentace, naplánování procedur,
zápisů fyzioterapeutů. Systém umožní uživateli zadat strukturovaně ordinované procedury s
vyznačením pořadí, četnosti a opakování s vazbou pro plánování procedur.
P.250 Řešení musí poskytovat možnost zobrazit pacienty, kteří docházejí na denní rehabilitační
cvičení a procedury. Údaje o pacientech musí obsahovat druh procedury či cvičení,
doporučení lékaře a datum další procedury.
P.251 Při plánování procedur systém musí:
1. umožnit hromadné objednání, svázání objednávek
2. možnost nastavení standardních skupin procedur
3. kontrola frekvence
4. umožnit přihlédnout k přání pacienta, kdy chce procedury absolvovat
5. jednoduché změny v naplánovaných procedurách s evidencí důvodu změny (nemoc
pacienta apod.).
P.252 Systém umožní pracovat s pacientem ambulantním i hospitalizovaným.
P.253 Přehledně zobrazovat vytíženost pracovišť a strojů pro rehabilitaci.
P.254 Umožnit automatické vykázání potřebných výkonů po odcvičení.
1. Statistiky a přehledy: umožnit statisticky vyhodnocovat počty pacientů, vytíženost
pracovišť a množství vykázaných výkonů. Přehledy o docházce pacienta a přehled
procedur, které nebyly vykázány pojišťovně, resp. zaplaceny pacientem.
2. Tisk potřebných dokumentů – rozpis pro pacienta, přehled plánovaných pacientů
objednaných na dané pracoviště, zdravotní dokumentace – zápisy lékařů, fyzioterapeutů.
3. Umožnit statisticky sledovat vykázané výkony, resp. platby pacientů.
Strana 42 / 127
# Požadavek
4. Jednoduchá správa nastavení: možnost zadání kapacity pracoviště a přístroje, pracovní
doby pracoviště, uzavření pracoviště: sanitární den, nemoc apod.
Komunikace s PACS
P.255 Zajištění plné integrace NIS se stávajícím PACS systémem, a to prostřednictvím HL7, DASTA
nebo webových služeb.
P.256 Umožnění přenosu informací mezi NIS a PACS min. v rozsahu:
• textové popisy vyšetření,
• žádanky,
• předání informací z registru pacientů v NIS,
• opravy demografických dat pacientů,
• příjem informací o stavu zpracování studie (MPPS)
P.257 Automatické sestavení „worklistu“ na základě žádanky v NIS/RIS a jeho odeslání v
požadovaném formátu na server.
P.258 Textový popis vyšetření bude vytvářen v NIS/RIS a ukládán do databáze NIS/RIS.
P.259 Spuštění prohlížeče snímků z NIS s předáním parametrů pro vyhledání konkrétní obrazové
studie nebo všech studií pacienta.
Ostatní požadavky
P.260 Ambulantní laboratorní výsledky a vyšetření propojené s NIS, možnost stažení laboratorních
výsledků do denního záznamu JIP.
P.261 Propojení lůžkových pacientských monitorů a glukometrů s NIS.
P.262 Elektronická evidence zdravotnických prostředků podléhajících evidenci (II b a III třídy) –
čtečkou odečíst inventární číslo, čárový kód.
P.263 Vizity na JIP tištěné, včetně epikrízy – ordinace medikace, infuzních roztoků, laboratorní
vyšetření, stav vědomí, bolesti, operační rány, léčebný plán, informace příbuzným.
Tabulka 10: Další specializovaná pracoviště v rámci strukturované zdravotnické dokumentace
Strana 43 / 127
3.3.9 Elektronická strukturovaná medikace, preskripce a eRecepty
Požadavky na tuto část NIS jsou následující:
# Požadavek
P.264 Systém musí nabídnout ucelený pohled na medikaci. Medikace bude obsahovat informace o
lécích zaznamenaných v systému zdravotnického zařízení a o lécích předepsaných v rámci
současné i minulé léčby. Systému musí nabídnout možnost celkově posoudit medikaci
pacienta.
P.265 Umožnit evidenci činností klinického farmaceuta dle platných metodik (zhodnocení
rizikovosti pacienta stran polékových komplikací, stanovení plánu racionalizace
farmakoterapie a ověření účinnosti provedených změn).
P.266 Možnost editace/nastavení, jaké interakce se budou zobrazovat a jaké ne (např. dle stupně
klinické závažnosti).
P.267 Při správě předepsaných léků musí systém nabídnout možnost upozornění na vzájemné
působení léků, alergie a kontraindikace (s možností nastavení délky sledované historie).
Možnost zobrazení aktuálního stavu skladu lékárny a aktuálního doplatku.
P.268 Doporučení klinického farmaceuta k aktuální medikaci by se mělo lékaři viditelně zobrazit při
otevření dokumentace pacienta a lékař by měl mít možnost na něj elektronickou formou
reagovat.
P.269 Záznamy o medikaci – uživatel by měl být schopen zdokumentovat a kontrolovat medikaci,
kterou pacient v dané době užívá či užíval dříve. Měl by být schopen uvést druh léku,
instrukce k užívání, poslední dávku a současný stav.
P.270 Možnost vkládání předdefinovaných ordinací (sada léků včetně dávek) do medikačního listu.
P.271 Předepisování léků pro lékárnu pro veřejnost – musí být možné tisknout recepty na léky
a/nebo posílat je elektronicky do centralizovaného národního řešení / úložiště (eRecept).
P.272 Rozšíření NIS o zapojení kvalifikovaného elektronického podpisu do procesů preskripce a do
komunikace s Centrálním úložištěm SÚKL prostřednictvím elektronických receptů (eRecept).
Implementace kvalifikovaného elektronického podpisu v oblasti vydávání elektronických
receptů.
P.273 Systém umí evidovat objem preskripce na měsíční (týdenní) bázi pro konkrétní pracoviště,
při předepisování léků a pomůcek na poukaz zobrazuje aktuální cenu předpisu a limit
nastaveného období.
P.274 Systém podporuje pozitivní listy, je možné vést oddělené pozitivní listy pro ústavní a
komerční lékárnu. Správa pozitivních listů je možná oprávněným uživatelem.
P.275 Uživatelé by měli být schopni volit z nabídky léků, které jsou v dané lékárně aktuálně
k dispozici. Na základě integrace s lékárenským systémem je lékař schopen zjistit dispozici
léčivého přípravku i aktuální výši doplatku za léčivo.
Strana 44 / 127
# Požadavek
P.276 Systém je schopen sledovat retenci receptů v lékárně dle pacienta / lékaře / ambulance.
Systém sleduje dodržování preskripčních omezení časových i odborností.
P.277 Samostatný tisk eReceptu podle jiné předlohy než běžný papírový recept.
P.278 Možnost poslání eReceptu emailem.
Požadavky na komunikaci s CÚ SÚKL (eRecept)
P.279 K současnému způsobu vytváření „papírových“ receptů pro výdej léčivých přípravků přibývá
možnost vytvářet tzv. eRecepty a ty odesílat na centrální uložiště SUKL.
P.280 Možnost komunikovat s CÚ SÚKL dle požadavků legislativy.
P.281 Elektronická preskripce bude sloužit k vystavení lékařského předpisu z klinického
informačního systému v elektronické podobě (tzv. eRecept) dle platné legislativy a pravidel
v době realizace systému.
P.282 Vytvoření elektronické podoby receptu (eRecept) ve struktuře požadované SUKL.
P.283 Podpis vytvořeného elektronického receptu pomocí kvalifikovaného elektronického
podpisu.
P.284 Odeslání podepsaného elektronického receptu na centrální uložiště receptů (dále CU) SÚKL.
P.285 Příjem elektronických identifikačních znaků receptu a jednotlivých položek na receptu z CU
SÚKL.
P.286 Oprava dříve uloženého eReceptu v CU SÚKL.
P.287 Stornování dříve uloženého eReceptu v CU SÚKL.
P.288 Využití veřejné datové sítě (Internetu) pro komunikaci s kryptovaným přenosem.
Tabulka 11: Elektronická preskripce a eRecepty
3.3.10 Výkaznictví
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.289 Vykazování výkonů dle platné výkonové vyhlášky.
P.290 Agenda vykazování je plně integrována do systému a umožňuje optimalizaci vykazování již v
průběhu poskytování léčebné péče.
P.291 Řešení musí podporovat klasifikační systém DRG:
1. Sestavení případu DRG v průběhu hospitalizace dle aktuálně známých informací o délce
případu, kritických výkonech a diagnózách pacienta a vykázaných ZUM/ZULP.
2. Případ DRG musí zobrazovat informace o výnosovém (dle indexu) i nákladovém
ohodnocení (v členění na hotelové služby, zdravotní služby, operace, léky a materiál).
Strana 45 / 127
# Požadavek
3. Aparát pro podporu DRG musí obsahovat funkce schvalovacího procesu nezávisle pro
kodéry na oddělení a superkodéra nemocnice. Schválení musí být podmínkou pro
uvolnění dokladů případu k vykázání plátci zdravotní péče.
4. Kontrolní funkce nad případem DRG musí umožňovat automatické promítnutí změn
souvisejících s výběrem optimálního pořadí Dg do dokladů.
P.292 Řešení musí podporovat implementaci rozsáhlých kontrolních mechanismů:
1. Systém umožní nastavitelnost sémantických a syntaktických kontrol správnosti
výkaznických dat pomocí konfiguračního nástroje pro správce výkaznictví – aplikace musí
umožňovat rozdílné nastavení stejných kontrol pro různé plátce, IČZ, IČP, uzly
organizační struktury a různé události práce s daty (pořízení, přepočty, importy,
sestavení dávek apod.).
2. Nastavení kontroly musí umožňovat volit různou tvrdost provedení kontrol – kontrola se
neprovádí, kontrola pouze oznamuje problém, kontrola umožní pořídit, ale zamezí
zařadit do dávek, kontrola neumožní ani pořídit a evidovat chybný údaj.
3. Výstupem provedení kontrol v souladu s konfigurací kontrol, je chybová sestava, která
má vazbu jak na příslušnou událost tak konkrétní doklad – chyby dokladu jsou zobrazeny
v každém dokladu tak, aby byla umožněna jejich selektivní oprava.
P.293 Řešení musí podporovat všechny používané národní standardy pro vykazování léčebné péče.
P.294 Systém bude obsahovat kontrolu na povinné kombinace výkonů s automatickým nabídnutím
druhého kódu při pořízení prvního.
P.295 Řešení musí být schopné zadat rozsah nasmlouvané péče k jednotlivým pracovištím a
odbornostem s možností uvedení platnosti jednotlivých výkonů, a to samostatně u každé
pojišťovny. Také musí upozornit uživatele, v případě, že plánovaná péče není se zdravotní
pojišťovnou pacienta nasmlouvána a nebude kryta.
P.296 Řešení musí umožňovat kapitovat pojištěnce u praktických lékařů, stomatologů a
gynekologů, vytvářet kapitační a výkonové dávky pro zdravotní pojišťovny podle pravidel
úhrad PL.
P.297 Systém musí umožnit nastavení dle popisu struktury zdravotnického zařízení tak, aby bylo
možno získaná data použít pro výkaz ZP a manažerské účetnictví – tzn. IČZ, IČP, lékař, ÚZIS,
odbornosti, nákladová střediska, zkratka oddělení).
P.298 Ruční import nebo automatický import z Portálu číselníků VZP a ZZP včetně číselníků NLEKY.
Sledování změn, úpravy číselníků – možnost upravovat názvy jednotlivých datových celků
(střediska, názvy IČP) stejně jako jejich tvorba, nebo ukončení s evidencí změny (datum,
identifikace).
P.299 Správa Centrálního registru pojištěnců, aktualizace na „průběh pojištění“, B2B.
Strana 46 / 127
# Požadavek
P.300 Pro pořízení z klinické dokumentace umožnit pořízení způsobem zaklikávání
z přednastaveného seznamu obvyklých kódů (včetně mnemotechnických přejmenování
kódů).
P.301 Pořizovací dialog umožnit jako součástí formuláře pro psaní dokumentace pacienta
bez nutnosti odskakování do jiného formuláře/dialogu/okna.
P.302 Umožnit komentovat doklad a případ DRG poznámkou. Udržování historie poznámek.
P.303 Možnost filtrování dokladů pomocí definice obecného dotazu SQL vytvářeného uživatelem
nebo správcem. Ukládání definovaných filtrů pro další použití uživatelem.
P.304 Dopravní služby – podpora výkazu pro ZP, ve vazbě na žádanku.
P.305 Podpora evidence čerpání nadstandardních služeb (např. lůžek).
P.306 Podpora závěrečného účtu pacienta – včetně nadstandardních služeb a plateb – sběr nebo
poskytnutí dat pro závěrečný účet pacienta včetně čerpání služeb neevidovaných v NIS
(strava, Internet).
P.307 Řešení a evidence sociálních hospitalizací – vybrané hospitalizace budou moci být označeny
jako sociální. Poté budou mít jiný režim vykazování pro ZP, nebudou ovlivňovat statistiky
využití lůžkového fondu jak vnitřní tak pro ÚZIS. Budou mít své vlastní statistické hodnocení.
P.308 Ambulantní poplatky – automatické generování a výpočet poplatků, zápis do dat pro ZP, tisk
dokladu, sestavy. Kontrola návaznosti na klinické vyšetření.
P.309 Podpora řešení hospitalizace doprovodů vykazovaných i nevykazovaných ZP – návaznost na
vyúčtování pro ZP, statistiky využití lůžkového fondu, účtování nadstandardních služeb.
P.310 Generování statistických výstupů pro ÚZIS (včetně klinického farmaceuta).
P.311 Integrovaná kontrola dat pro registry při jejich pořizování – kontrola správnosti a úplnosti
dat pro registry bude možná i při jejich pořizování.
P.312 Zpracování dokladů pro vykázání péče pro plátce všech typů – plně v souladu s legislativou,
a metodikami. Tvorba výstupních souborů s daty.
P.313 Rozlišení samoplátců – různí samoplátci mohou mít různou cenu za stejnou péči.
P.314 Podpora zpracování dat pro ZP pro jinou organizaci – lze načíst data (k-dávky) pro zpracování
a vykázání.
P.315 Zpracování opravných dokladů, chybových protokolů a revizních zpráv od ZP – systém musí
umět jednoduchým způsobem zpracovat chybové a revizní protokoly ze ZP. Import v případu
el. rozhraní. Spárování s dříve vykázanými daty, duplicita a následná oprava dokladů.
Možnost vytvořit opravnou (schváleného čísla dokladů) i schválenou dávku (nová čísla
dokladů) z důvodu revizí.
Strana 47 / 127
# Požadavek
P.316 Automatické kontroly a opravy dat – automatizované kontrolní mechanismy. Např. korekce
ošetřovatelských dnů na základě dat o hospitalizaci.
P.317 Uchování historie všech oprav dokladu a řádku – kompletní historie dat, dostupná z
upravovaného záznamu. Informace o tom kdo a kdy změnu provedl.
P.318 Kontrola vykazovaných dat proti nasmlouvaným parametrům (nasmlouvané výkony) – vazba
na Přílohu č. 2 – nasmlouvané výkony (pasport), dodatky ke smlouvám, vyhlášky (platný SZV)
– frekvence, místo, kombinace výkonů, kontrola vazby výkonů a ZUM/ZULP, výkony
agregované do ošetřovacího dne, platnost zadávaných kódů (Dg, výkony, ZUM/ZULP),
kontrola lůžkodnů /TISS dle odbornosti oddělení, při implementaci nastavení dle aktuální
legislativy.
P.319 Hromadný zápis výkonů.
P.320 U hospitalizovaného pacienta automaticky upozornit na dosažení finančního limitu –
automatické upozornění na nákladné pacienty – přímo v klinické části. Hranice bude
definovatelná v rámci celé nemocnice.
P.321 Řešení případů vykázání dat pacienta špatné pojišťovně, včetně korekce navázaných
importovaných dat (komplement).
P.322 Automatické generování rutinních opakovaných výkonů (rozlišení hospitalizace, ošetřovací
dny, sestupné sazby, …) na základě dat z klinické části (hospitalizace).
P.323 Kontrola dat proti číselníku žadatelů – kontrola poskytnuté vyžádané péče proti seznamu IČP
dodávaných VZP.
P.324 Možnost vykázat vybranou část péče v extra dávce – část péče zdravotnického zařízení (např.
mamograf) je vykazována extra mimo standardní dávku zbytku nemocnice.
P.325 Provozní přehledy exportovatelné minimálně do MS Excelu.
P.326 Možnost nastavit vybrané kontroly na vstup dat – vybrané kontroly mohou být aplikovány
již při vstupu dat a neumožní zadat chybná data. Např. kontroly proti číselníkům.
P.327 Při zobrazení účtu zobrazit i jeho aktuální zařazení do DRG skupiny – i u neukončených
hospitalizací. Průběžné grupování dat. Možno řešit dávkově v noci.
P.328 Podpora číselníku N-léků – paralelní číselníky léků od ZP. Ve vazbě na konkrétní pojišťovnu.
Automatické číslování dokladů a dávek podle požadavků pojišťoven. V DR KDAVKY řadit
dávky a doklady vzestupně.
P.329 Regulační poplatky – nutná podpora funkce regulačních poplatků dle aktuálně platné
legislativy.
P.330 Číselníky NIS – pro ZUM a ZULP – možnost importu cen a nastavení vykazování v pořizovací
hodnotě, pokud je nižší jak cena maximální. Možnost doplnění nových přípravků (nový ZULP
– 999999x) a práce s nimi.
Strana 48 / 127
# Požadavek
P.331 Správcovské kontroly – možnost samostatného nakonfigurování vlastní kontroly, např.
vyřazení konkrétního výkonu, odbornosti, IČP z dávky dle aktuálních potřeb. Nezávislost
na přednastavených kontrolách a na dodavateli NIS.
P.332 Umožnit evidovat u pacienta souběžně několik pojistných smluv (pojištění) a více různých
plátců péče pro stejné období.
P.333 K-dávky – možnost odmítnutí účtu před odesláním do pojišťovny dle různých parametrů
(např. za celé IČP, za celou odbornost atd.).
P.334 Kontroly před vyúčtováním – systém musí umět spustit kontroly před vyúčtováním takto
(výkony v P2, výkony dle omezení úhrady – hospitalizační, ambulantní a intenzivní péče,
výkony s kategorií úhrady Z, agregované výkony, frekvence výkonů, Q výkony, kombinace
výkonů, dle limitu úhrady, u hospitalizací na číselník NLEKY, zda ZUM a ZULP ano nebo ne,
platnosti diagnózy, platnosti čísla externího žadatele dle číselníku, zda jsou vyúčtovány
všechny ukončené hospitalizace).
P.335 Možnost připojení (importu v daném DR) a odděleného zpracování externích dat –
extramurální péče – NIS umožňuje evidovat data extramurální péče včetně identifikace
příslušného poskytovatele vyžádané péče ke konkrétnímu úkonu. Pokud budou k dispozici,
systém musí umět spojit vlastní data s externím zdrojem a s výsledkem dále pracovat
(případně zobrazit) odděleně i společně (extramurální péče).
P.336 Kontrolní sestava chyb na uživatele – systém by měl umožnit individuální nastavení
kontrolních sestav pro jednotlivé "povolené" uživatele (přiřadit kontrolní sestavy na
konkrétní uživatelem).
P.337 Vykazování a zpracování dávek z LIS bude řešeno centrálně v nemocnici mimo LIS – tzn., že
NIS bude zajišťovat zpracování a vykázání dat z LIS.
P.338 Z centrálního pracoviště výkaznictví přímý přístup do souvisejících agend – do centrálního
registru, evidence hospitalizovaných, DRG modulu, zdravotnické dokumentace B2B portálu
VZP (ověření RČ), agendy sestav, vystavení osobního účtu.
P.339 Zajištění přímého přístupu do databáze NIS na úrovni čtení dat prostřednictvím SQL
konektoru.
P.340 Systém bude obsahovat funkce pro vedení kont pacientů (kreditní i debetní) pro
samopláteckou úhradu péče. Funkcionalita musí obsahovat řešení pro různé měny včetně
kurzovního přepočtu, evidenci pohybů na kontě pacienta.
P.341 Systém bude obsahovat nástroje pro snížení administrativní zátěže vedení a příprav příloh
č.2 - tzn. možnost importu hotové přílohy od ZP se synchronizací na pasport výkonů. Možnost
napojení na personální evidenci a evidenci přístrojů. Součástí agendy EP2 požadujeme
křížové kontroly mezi osobami-výkony-přístroji jako např. celkový úvazek, nedostatečnost
kvalifikace pro výkon apod.
Strana 49 / 127
# Požadavek
Uzávěrky
P.342 Pro účely přehlednosti uzávěrky umožní aplikace seskupovat výkaznická data do
pojmenovaných uzávěrkových množin, nad kterými následně probíhají všechny činnosti
uzávěrky (přepočty, kontroly, dávkování apod. včetně zpracování revizí a oprav.
P.343 Provádění lokálních uzávěrek (přepočty, kontroly, dávkování) – aplikace musí umožnit na
libovolném podstromu organizační struktury provedení lokálních uzávěrek.
P.344 Zobrazení a kvantifikace dokladů vybraných k sestavení do dávek ještě před samotným
sestavením; včetně možnosti manuálního výběru konkrétního (množiny) dokladů pro
sestavení.
P.345 Modul pro centrální zpracování výkaznických dat musí obsahovat nástroje pro hromadné
opravy při uzávěrce. Takto provedené transformace musí podléhat kontrolnímu aparátu
konfigurace kontrol tak, aby nebylo možno tímto způsobem znehodnotit evidované doklady.
P.346 Součástí výkaznického modulu je podpora pro vytváření podkladů pro fakturaci ze
sestavených k-dávek a vytváření faktur v DR – FDAVKY.
P.347 Výkaznický modul musí být navázán na procesní podporu systému tak, aby bylo umožněno
graficky modelovat a následně podle definice spouštět automatickou uzávěrku jako
workflow definovaného výkaznického procesu (činnosti přepočtů, kontrol, sestavení dávek,
sestavení sestav a fakturace).
P.348 Možnost vytvoření nové správcovské kontroly (SQL procedury) nad doklady.
P.349 Pro vytváření statistik nad doklady ZP mít také možnost definovat statistiku pomocí
uživatelského dialogu, ve kterém si uživatel vybírá rozsah počítaných dat a strukturu výstupu
(rozdělení sestavy, počítané hodnoty). Umožnit výstup do tabulky, grafu či XLS.
P.350 Výpočet ceny a vystavení účtu pro samoplátce za poskytnutou péči. Kontrola úhrady
poskytnuté péče samoplátcům a přímo hrazené péče.
Ostatní požadavky
P.351 Řešení musí umožnit zpracování úloh na serveru (tzv. „vzdálené úlohy“ zpracování
v naplánovaném čase).
P.352 Export dat ve formě XML souborů ve struktuře uvedené za touto tabulkou pro import do
externího systému a následné zpracování externím systémem.
Tabulka 12: Výkaznictví
Strana 50 / 127
3.3.10.1 Struktura dat pro export pro externí systém
V této podkapitole je uvedena struktura dat pro export pro externí systém dle požadavku v předchozí
tabulce.
Typy položek:
• A=Account
• H=ExternalHead
• D=AccountDiagnose
• I=AccountItem
• C=Capitation
• F=Fee
Formát dat dokladů, poplatků a kapitace (XML – typy struktury dat):
• Univerzální hlavička dokladu (obsahuje strukturu všech hlaviček dokladů)
• Ostatní diagnózy dokladu
• Univerzální řádek dokladu (obsahuje strukturu všech řádků dokladů)
• Poplatek
• Kapitace
Doklady – hlavička:
Kód položky Název položky Typ Povinná Poznámka Typ
položky
položka
Strana 51 / 127
Kód položky Název položky Typ Povinná Poznámka Typ
položky
položka
Strana 52 / 127
Kód položky Název položky Typ Povinná Poznámka Typ
položky
položka
Tabulka 13: Formát dat dokladů, poplatků a kapitace – hlavička
Pozn.: Povinná položka - V= u všech dokladů, popř. výpis typů dokladů, u kterých je povinná
Strana 53 / 127
Druh výkazu: Typ dávky (VZP) Číselný typ
dokladu (VZP)
Kód Název
Tabulka 14: Druh výkazu
Doklady – ostatní diagnózy:
Kód položky Název položky Typ Povinná položka Poznámka Typ položky
Tabulka 15: Doklady – ostatní diagnózy
Doklady – řádky: Název položky Typ Povinná Poznámka Typ
položka položky
Kód položky
Strana 54 / 127
Kód položky Název položky Typ Povinná Poznámka Typ
položka položky
Strana 55 / 127
Kód položky Název položky Typ Povinná Poznámka Typ
položka položky
Tabulka 16: Doklady – řádky Název položky Typ Povinná Poznámka Typ
položky
Kapitace:
Kód položky
položka
(X=povinná)
Strana 56 / 127
Kód položky Název položky Typ Povinná Poznámka Typ
položky
položka
(X=povinná)
Tabulka 17: Kapitace
3.3.11 Statistiky
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.353 Systém musí umožňovat tvorbu operativních statistik a přehledů v požadovaných formátech
a struktuře.
P.354 Tyto přehledy a jejich výsledná grafická podoba mohou být definovány administrátorem
systému
P.355 Možnost sběru dat a elektronického vykazování do národních registrů – integrace proběhne
jen na registry s existujícím rozhraním, do kterých má ONP povinnost poskytovat data.
P.356 Statistiky nad vykazováním pojišťovně – min. výkony, parametry DRG, léky, recepty, materiál.
P.357 Statistiky pro denní administrativu na ambulanci a lůžkách.
P.358 Systém obsahuje nástroje k podpoře tvorby takových přehledů a výstupů.
Možnost sběru dat a elektronického vykazování pro ÚZIS
P.359 Vykazování hospitalizačních statistik pro ÚZIS.
P.360 Vykazování ročních ambulantních statistik pro ÚZIS pro jednotlivé odbornosti z údajů, které
jsou dostupné v NIS.
Uživatelské statistiky
P.361 Uživatel (správce NIS) musí mít možnost jednoduše dodělávat další potřebné statistiky nad
daty strukturovaně zadanými do NIS.
P.362 Tyto statistiky zpřístupnit koncovému uživateli přímo v NIS.
P.363 Možnost exportu statistických výstupů do MS Excel, MS WORD.
P.364 Možnost vytvářet aktivní sestavy s přímým vstupem uživatele do záznamu (dokumentace
pacienta), který je výsledkem vytvořené sestavy
Tabulka 18: Statistiky
Další statistiky jsou součástí MIS (viz kap. 3.3.28 – Manažerský informační systém (MIS)).
Strana 57 / 127
3.3.12 Centrální registr pacientů
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.365 Systém podporuje automatickou kontrolu identity a pojištění pacienta v průběhu příjmu k
hospitalizaci / ambulantnímu ošetření v příslušném státním či pojišťovenském registru dle
aktuálních legislativních a technických možností v době realizace projektu.
P.366 Řešení podporuje identifikaci pacientů pomocí fotografií a čárových a QR kódů (s možností
tisku na náramky).
P.367 Řešení musí umožnit vyhledávání pacientů pomocí různých kritérií, jako je RČ, jméno, věk,
pohlaví, ošetřující lékař, datum registrace atd. V rámci vyhledávání musí být k dispozici filtry,
jako např. aktivní pacienti, neaktivní pacienti, objednaní pacienti atd.
P.368 Možnost zapisovat k pacientovi významné informace, které budou součástí kmenových dat
(např. alergie, předem vyslovené přání, …)
P.369 U jednotlivých pacientů vedení údajů o praktickém lékaři a odborných lékařích pacienta s
jejich centrálně vedeným číselníkem.
P.370 U jednotlivých pacientů vedení údajů o kontaktech (telefonní, mailový, …), osobách blízkých.
P.371 Možnost využití kontaktních údajů v plánovačích.
P.372 Generování náhradního rodného čísla, možnost identifikace cizince.
P.373 Pokud bude zaveden bezvýznamový identifikátor, zavedení bezvýznamového identifikátoru
pacienta do systému a ověřování identifikace vůči IS ZR.
P.374 Možnost sloučení chybně evidovaných pacientů.
P.375 Hlášení na matriku (narození, úmrtí).
Tabulka 19: Centrální registr pacientů
3.3.13 Porodnice
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.376 Vedení pacientské dokumentace na gynekologicko-porodnickém oddělení v návaznosti na
oddělení novorozenecké včetně elektronického vedení porodopisů a zpráv o rodičce a
novorozenci.
P.377 Vedení dokumentace o rodičce (matce), vedení porodopisu se všemi potřebnými
informacemi.
P.378 Vedení potřebné dokumentace k vyšetření a hospitalizaci těhotné ženy, průběhu těhotenství,
anamnézu rodičky, popis předporodních vyšetření, průběh a záznamy z porodu, stavu matky
po porodu.
Strana 58 / 127
# Požadavek
P.379 Podpora sady žádanek, klinických postupů a protokolů týkajících se těhotenství, jež definují
posloupnost rozličných hodnocení a léčebných postupů. Veškerá péče v těhotenství a o
novorozené dítě musí být v systému zdokumentována (např. ultrazvuková vyšetření a
výsledky laboratorních testů).
P.380 Partogram – řešení musí nabízet možnost využití partogramu, který umožňuje
zdravotnickému personálu okamžitě detekovat jakékoli abnormální hodnoty a okamžitě
poskytnout pomoc matce i dítěti během porodu.
P.381 Vedení dokumentace o novorozenci, popis předporodních vyšetření, průběh a záznamy z
porodu, stavu novorozence po porodu.
P.382 Možnost jednoduše (přímo z porodopisu) založit novorozence jako pacienta do registru a
uložit na novorozeneckou stanici.
P.383 Přenos potřebných údajů mezi dokumentací rodičky a novorozence s vyloučením duplicit
zadávání.
P.384 Možnost svázat dokumentaci rodičky s dokumentací novorozence.
P.385 Možnost zadání více novorozenců k rodičce.
P.386 Přehledné hlídání povinných údajů v dokumentaci.
P.387 Elektronické vykazování potřebných výkazů pro ÚZIS (Zpráva o rodičce, Zpráva o novorozenci,
Hlášení vývojové vady) a tisk údajů do formuláře Hlášení o narození.
P.388 Statistiky a tisky z porodnické a novorozenecké dokumentace přizpůsobit zvyklostem
oddělení.
P.389 Přenos porodnické a novorozenecké dokumentace do propouštěcí zprávy.
P.390 Hlášení na matriku (rodička, novorozenec).
P.391 Evidence potratů, mrtvých plodů.
P.392 Kalmetizace, screening, vývojové vady.
P.393 Fyziologičtí a intermediální novorozenci.
P.394 Babybox
Tabulka 20: Porodnice
3.3.14 Radiodiagnostika
Radiodiagnostika provádí diagnostické činnosti na základě vyšetření na zdravotnických přístrojích, tzv.
modalitách, které poskytují obrazovou dokumentaci (CT, rentgeny, ultrazvuky apod.).
Strana 59 / 127
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.395 Radiologický modul, do nějž se zapisují záznamy o vyšetřeních, nálezy, automaticky se do něj
převádějí relevantní údaje o pacientech – biometrické údaje, rizikové faktory, evidence dávek
ozáření (historie, kumulace). Integrace s PACS – předávání žádanek, přebírání výsledků
(strukturovaných popisů), dávek ionizujícího záření, atd.
P.396 Funkcionality potřebné pro radiologická pracoviště – RTG, sonografie, CT, MR, nukleární
medicína atd.
P.397 Funkcionalita potřebná pro plánování denního provozu.
P.398 Podpora činností pro kartotéku: objednávání na vyšetření, příjem, popisovnu a vyšetřovnu.
P.399 Systém strukturované dokumentace umožňuje vytvářet žádanky na jednotlivá vyšetření /
soubory vyšetření. Do žádanek jsou automaticky doplňovány známé údaje (hmotnost, alergie,
výsledky laboratorních vyšetření, infekční onemocnění, …).
P.400 Nelze odeslat klinikem žádanku bez všech vyplněných / legislativou požadovaných údajů.
P.401 Možnost automatického příjmu žádanek z klinických oddělení. Možnost zápisu žádanky na
vyšetření přímo na RDG oddělení (opisem z papíru)
P.402 Možnost tvorby strukturované žádanky s označením povinných polí – např. kontraindikace
(kardiostimulátor apod.)
P.403 Sledování stavu žádanky (k vyšetření, vyšetřen, k popisu, popsán, vyúčtován apod.) a
filtrování nad stavy. Uchování historie stavu žádanky.
P.404 Možnost nahlížet do dokumentace pacienta (traumaplán atd.) při zápisu nálezu.
P.405 Náhled a záznam na nežádoucí události.
P.406 Vhodné nastavení funkcí, seznamů a zobrazovaných informací pro jednotlivé role uživatelů
(administrativní pracovník, laborant, lékař, primář apod.)
P.407 Možnost nastavení automatického sledu činností – aby systém kopíroval práci koncového
uživatele.
P.408 Možnost evidence použitých přístrojů, expozic.
P.409 Možnost sledování dávky ionizujícího záření – a to ze všech vyšetření, která pacient prodělal,
automatického získání dat z PACSu nebo možnost ručního vkládání obdržené dávky.
P.410 Možnost zobrazení snímků z PACSu v různé fázi popisu vyšetření.
P.411 Archivace snímků.
P.412 Automatické proúčtování výkonů a zadaného materiálu dle metody.
P.413 Použití standardního editoru (RTF) s možností používání předdefinovaných textů
Strana 60 / 127
# Požadavek
P.414 Možnost prohlížení historických RDG nálezů při popisu snímků
P.415 Možnost prohlížení relevantní klinické pacientské dokumentace při popisu snímků
P.416 Možnost nastavit potvrzování nálezů erudovanějším lékařem (druhé čtení)
P.417 Odeslání nálezu žadateli
P.418 Objednávkový systém – možnost objednávání pacientů na vyšetření.
P.419 Statistiky provedených vyšetření, výkonů, spotřebovaného materiálu apod., možnost exportu
dat
P.420 Sledování snímků a expozic
P.421 Komunikace s PACS (a modalitami) formou vytváření pracovních listů (worklistů) modality.
P.422 Automatické otevírání popisovaného snímku na diagnostické stanici (diagnostický popis
obrazové dokumentace/snímků).
P.423 Při popisu snímků možnost pro radiologa náhledu do klinických dat pacienta.
P.424 Možnost diktovat nález a hlasový záznam automaticky převádět na psaný text do
dokumentace pacienta.
P.425 Možnost zvukového záznamu k nálezu.
P.426 Použití standardního editoru s možností používání předdefinovaných textů – možnost
strukturovaného popisu, předdefinované texty, výběry z číselníků, …
Víceúrovňové schvalování nálezů, možnost 2. čtení, tedy druhého „uzavření“ popisu, možnost
připojit poznámku, která je relativně stranou popisu.
P.427 Odeslání nálezu žadateli.
P.428 Vykazování, statistiky, tisky. Statistiky provedených vyšetření, výkonů, spotřebovaného
materiálu apod., možnost exportu dat.
Tabulka 21: Radiodiagnostika
3.3.15 Rehabilitace
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.429 Vedení pacientské dokumentace na rehabilitačním oddělení a zároveň systém pro plánování
procedur jako integrální součást systému s návazností na centrální registr pacientů.
P.430 Ucelené řešení pro fyzioterapie – provázanost lékařské dokumentace, naplánování procedur,
zápisů fyzioterapeutů. Umožnit lékaři zadat strukturovaně ordinované procedury s
vyznačením pořadí, četnosti, opakování s vazbou pro plánování procedur.
P.431 Systém musí zahrnovat významné úkony rehabilitační medicíny pro účely:
Strana 61 / 127
# Požadavek
1. vytváření léčebných plánů a objednání termínů jednotlivých procedur
2. přiřazení zdravotních problémů k příslušným procedurám a cvičením
3. zobrazení jednotlivých procedur léčebného plánu v dvou samostatných mřížkách
4. realizace kroků týkajících se procedur dle profilu a povolených kroků a charakteru daného
rehabilitačního úkonu
5. odeslání pacienta z ambulantní rehabilitační terapie buď do zdravotnického zařízení
s denní péčí, nebo k hospitalizaci na lůžkovém oddělení.
P.432 Při plánování procedur: umožnit hromadné objednání; možnost nastavení standardních
skupin procedur; kontrola možné četnosti dle metodiky VZP; umožnit přihlédnout k přání
pacienta, kdy chce procedury absolvovat, efektivní naplánování rehabilitačních procedur
pacienta za pomoci grafické vizualizace v diáři, barevné odlišení jednotlivých procedur,
jednotlivé procedury se nesmí překrývat.
P.433 Rehabilitační plán: uživatel (přímo lékař nebo časovač/ka) zadá typy a počty procedur, kterých
se má pacient účastnit. Následně časovač/ka v diáři naplánuje termíny pro jednotlivé
procedury. Je možné rozplánovat buď všechny procedury (najedou nebo postupně) nebo
naplánovat časy procedur na první týden a ty se potom ve stejném časovém rozložení
rozkopírují na následující týdny.
P.434 Časování s týdenním rozpisem a automatickým rozplánováním:
1. Tisk rozpisu procedur pro pacienta
2. Vlastní časování
3. Možnost konfigurace diáře a šablon
P.435 Požadavky na objednávací systém:
1. Po zadání konkrétních procedur, dnů v týdnu kdy bude pacient docházet a orientačního
času bude systémem vyhledán nejbližší vhodný termín.
2. Systém je schopen kombinovat cvičebnu pro individuální terapii s ostatními procedurami
a nabízet nejbližší vhodný termín.
P.436 Možnost zobrazit pacienty, kteří docházejí na denní rehabilitační cvičení a procedury. Údaje
o pacientech musí obsahovat druh procedury či cvičení, doporučení lékaře a datum další
procedury.
P.437 Možnost pracovat s pacientem ambulantním i hospitalizovaným.
P.438 Přehledně zobrazovat vytíženost pracovišť, strojů, fyzioterapeutů.
P.439 Umožnit automatické vykázání potřebných výkonů po odcvičení.
P.440 Statistiky a přehledy: umožnit statisticky vyhodnocovat počty pacientů, vytíženost pracovišť,
množství vykázaných výkonů. Přehledy o docházce pacienta, přehled procedur, které nebyly
vykázány pojišťovně, resp. zaplaceny pacientem
Strana 62 / 127
# Požadavek
P.441 Tisk potřebných dokumentů – rozpis pro pacienta, přehled plánovaných pacientů
objednaných na dané pracoviště, zdravotní dokumentace – zápisy lékařů, fyzioterapeutů
P.442 Umožnit statisticky sledovat vykázané výkony, resp. platby pacientů
P.443 Jednoduchá správa nastavení: možnost zadání kapacity pracoviště a přístroje, pracovní doby
pracoviště, uzavření pracoviště: sanitární den, nemoc apod.
P.444 Jednoduché změny v naplánovaných procedurách s evidencí důvodu změny (nemoc pacienta
apod.)
P.445 Připravenost systému a nastavení pro rehabilitační pracoviště uvedená v kap. 6.4.1 –
Rehabilitace.
Tabulka 22: Rehabilitace
3.3.16 Laboratorní systém (LIS)
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.446 Plná integrace s laboratorními systémy, možnost spolupráce s různými LIS podle lokality a
odbornosti (hematologie, biochemie, mikrobiologie, genetika, …)
Zajištění komunikace NIS se stávajícím laboratorním informačním systémem
P.447 Export laboratorních elektronických žádanek ve formátu DASTA
P.448 Import laboratorních výsledků ve formátu DASTA
P.449 Import výkonů ve formátu K-dávek
P.450 On-line zpřístupnění výkonů provedených laboratoří do výkaznictví pro účely vyúčtování
samoplátců
Rozšířená komunikace se stávajícím laboratorním informačním systémem
P.451 Jednosměrná synchronizace registru pacientů laboratoře (Slave) s registrem pacientů NIS
(Master) tak, že změny v registru NIS jsou okamžitě promítány do registru laboratoře.
P.452 On-line synchronizace základních číselníků laboratoří s číselníky NIS, a to
1. ve směru z laboratoře do NIS (např. číselník metod apod.) a
2. ve směru z NIS do laboratoří (např. číselník žadatelů).
P.453 Možnost využít i postupného uvolňování výsledků jednotlivých metod.
P.454 On-line distribuce výkonů provedených v laboratoři do centrálního zpracování výkaznictví,
tj. okamžitě po uvolnění výsledků budou do NIS zapisovány i podklady pro vykázání zdravotní
péče.
Strana 63 / 127
# Požadavek
P.455 Přenos výsledků vyšetření z LIS do NIS, označení patologických hodnot. Výsledky jsou
přenášeny ve strukturované podobě a zobrazovány v přehledné tabulce s časovou osou,
možnost tvorby grafů.
Žádanky
P.456 Systém strukturované dokumentace umožňuje vytvářet žádanky na jednotlivá vyšetření /
soubory vyšetření. Do žádanek jsou automaticky doplňovány známé potřebné údaje
(hmotnost, …)
P.457 Nelze odeslat klinikem žádanku bez všech vyplněných / legislativou požadovaných údajů.
P.458 Je-li požadováno vytvoření více žádanek, systém umožní uživateli zadání v jednom kroku a
rozdělení do potřebných žádanek zajistí sám na pozadí. Dle požadovaných výkonů u
laboratorních testů vytvoří informaci pro uživatele s požadavky na způsob odběru (např.
počet, typy zkumavek, minimální množství materiálu, apod.).
P.459 Systém má vytvořeny elektronické žádanky ve standardním tvaru, který je možné upravit.
P.460 Dokumentace seznámení se odpovědného zdravotnického pracovníka s výsledkem vyšetření
P.461 LIS musí umožnit migraci historických dat z původního LISu do nového LISu
P.462 LIS bude dodán včetně modulů pro akreditační nadstavbu:
1. Operativní skladová evidence IVD diagnostik
2. Integrovaná řízená dokumentace v LISu
3. Plánování činností
4. QC – quality control
P.463 LIS musí umožňovat provedení "Vertikálního auditu".
Žádanky externích uživatelů
P.464 Modul poskytuje jednoduchou formou zabezpečený přístup k laboratorním výsledkům pro
externí uživatele.
Modul je určen především pro ambulantní lékaře. Lze jej však využít i pracovníky laboratoře
nebo nemocnice pro rychlý přístup k výsledkům v případě, že jsou mimo zařízení a mají k
dispozici internetové připojení.
P.465 Modul nevyžaduje žádnou instalaci na počítači uživatele. Je spustitelný v běžném
internetovém prohlížeči, jedná se internetovou aplikaci, která pracuje přímo s databází
laboratoře.
P.466 Identifikační údaje pacienta se kontrolují podle registru pacientů laboratoře. Pro nové
pacienty lze provést on-line kontrolu rodného čísla (nebo jiné identifikace) pacienta podle
registru plátců péče.
Strana 64 / 127
# Požadavek
P.467 V modulu je možné vytvářet elektronické žádanky na laboratorní vyšetření a sledovat jejich
stav.
P.468 Modul umožňuje připravit žádankové formuláře přesně podle potřeby konkrétního lékaře
včetně předdefinovaných palet vyšetření. Vyšetření lze seskupovat podle materiálu do
funkčních celků na samostatné záložky. Na základě navolených vyšetření je následně
zobrazen potřebný odběrový materiál.
P.469 Modul informuje v okamžiku tvorby žádanky o nadbytečných požadavcích na vyšetření a tak
lze předejít zbytečným odběrům.
P.470 Požadavky na vyšetření je možné doplňovat až do okamžiku převzetí materiálu laboratoří.
Tedy ještě po celou dobu transportu materiálu na příjem laboratoře.
P.471 Pro jednoznačnou vazbu materiálu s elektronickou žádankou je použit čárový kód.
P.472 Za skupinu odebraných materiálů lze vytisknout souhrnnou papírovou žádanku.
P.473 V modulu je možné sledovat výsledky laboratorních vyšetření. Výsledky lze zobrazovat
průběžně od okamžiku, kdy jsou uvolněny laboratoří (validovavé výsledky).
P.474 Aktuálně uvolněné výsledky laboratoří jsou indikovány v seznamu pacientů. Je možné
zobrazit jednoduchý denní přehled výsledků pacienta nebo kumulativní nález s kompletní
historií výsledků v čase.
P.475 Výsledkový nález lze přímo z prostředí aplikace vytisknout nebo exportovat ve formátu MZ
DASTA.
P.476 Uživatel má k dispozici statistiku vyžádaných výkonů včetně možnosti porovnání zvolených
časových období mezi sebou.
P.477 Modul je zabezpečen přístupovými právy. Lékař tak může zobrazit pouze „své“ pacienty a
výsledky vyšetření, která po laboratoři požadoval. Přístupová práva lze individuálně
upravovat a přístup k výsledkům lze pro konkrétního lékaře rozšířit. Veškeré akce s daty jsou
zapisovány do deníku v laboratoři včetně pasivních přístupů k pacientským údajům.
Zabezpečení musí být v souladu s ostatními principy a požadavky, tj. např. GDRP apod.
Tabulka 23: Komunikace s laboratorními IS
3.3.17 EZD – elektronická zdravotní dokumentace
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.478 Možnost vedení dokumentace v čistě elektronické podobě s využitím kvalifikovaného
elektronického podpisu.
P.479 Zajištění vazby na externí certifikační autoritu.
Strana 65 / 127
# Požadavek
P.480 Možnost podepisování dokumentace kvalifikovaným elektronickým podpisem.
P.481 Využívání časových razítek pro dokumentaci.
P.482 Předávání dokumentace do DMS a spisové služby (důvěryhodného dokumentového archivu).
Tabulka 24: EZD – elektronická zdravotní dokumentace
3.3.18 Medikace
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.483 Podání léků a evidence spotřeby až na pacienta s automatickým vykázáním plátci, vydání léků
ze skladů (sledování nákladů na pacienta) a dle metodiky je automaticky zapisovat do dokladu
pro plátce péče.
P.484 Uživatelům musí být umožněno předepisovat léky (možnost strukturované medikace), které
budou dále spravovány v rámci místního zdravotnického zařízení. Řešení musí také umožnit
výběr specifických informací, jako např. název léku, cesta, počet dávek, dávkování a
frekvence. Strukturovaný předpis léků probíhá ve vazbě na číselník SUKL/ZP/individuální,
možnost zadat lék mimo číselník. Systém umožňuje vazbu na příruční (klinický) sklad oddělení
- přehledné označení léků, které jsou skladem při ordinaci léků. Možnost přímého vstupu na
informace o léku ze SUKL.
P.485 Možnost výpočtu potřebného množství účinné látky dle biometrických údajů pacienta (váha,
tělesný povrch).
P.486 Systém musí umět strukturovaně zadanou medikaci přenést do jiných formulářů / zpráv
(např. příjmová, překladová, propouštěcí zpráva, podklady pro automatizovaný výdej v
lékárně). Vazba mezi aktuální medikací a trvalými léky (snadné přenesení).
P.487 Systém umožní objednávat léky a materiál.
P.488 Systém musí umožnit zefektivnit činnosti s výdejem ze skladu (zahrnutím do spotřeby)
takovým způsobem, aby bylo léčivo přeneseno do účtu pacienta s aktuální cenou
P.489 Nitrožilní tekutiny – mělo by být možné strukturovaně ordinovat nitrožilní tekutiny (ve formě
původní směsi či příměsi k ostatní medikaci). Uživatelé by měli být schopni definovat roztok,
kvantitu, dávku a poměr, čas anebo rychlost podání.
P.490 Kontrola medikace – měl by být k dispozici nástroj k posouzení medikace umožňující
oprávněným uživatelům kdykoli přístup k informacím o všech lécích, které pacient užívá.
Medikace musí být zobrazena nezávisle na tom, ve které části aplikace byla
zadokumentována,
P.491 Upozornění týkající se medikace – systém musí vždy vydat upozornění v případech, že:
Strana 66 / 127
# Požadavek
1. předepsané léky se navzájem ovlivňují - on-line hlášení lékových interakcí
(vyhodnocované z ordinovaných léků i z léků zadaných na recept).;
2. je k dispozici jiná, ekvivalentní a levnější medikace, snadný výběr alternativ z ATC skupiny.
P.492 Výživové doplňky a léky míchané dle individuálních potřeb pacienta – nabízené řešení musí
fungovat se správou či předepisováním výživových doplňků a léků míchaných dle
individuálních potřeb pacienta (magistra liter).
P.493 Uživatelé musí prioritně volit z nabídky schváleného pozitivního listu léků, které jsou v dané
lékárně (příručním/klinickém skladu) k dispozici.
P.494 Systém umožní efektivní evidenci kontrolovaného podání léčiva u lůžka pacienta
prostřednictvím práce s jednoznačnou identifikací pacienta i léčiva. Možnost elektronického
označení podání léku – jednotlivě pro daného pacienta i hromadně pro pacienty stanice.
P.495 Systém umí sledovat náklady na pacienta.
P.496 Systém umožní ordinování tzv. kontinuálních infúzí a při jejich podání umožní evidovat změnu
rychlosti podání.
P.497 Ordinované léky je možné zobrazit přehledně na časové ose
P.498 Systém umožní elektronicky evidovat podání léků.
P.499 Systém eviduje stav léků (ordinované, podané, vysazené). Stavy léků jsou graficky odlišeny.
P.500 Systém umožní elektronickou evidenci podání léků on-line přímo u lůžka pacienta. Sestra
pracuje s mobilní aplikací se čtečkou čárových a QR kódů. Načte pacienta (jeho jednoznačný
čárový nebo a QR kód z náramku), zobrazí se seznam ordinovaných léků. Sestra načítá
jednotlivé čárové a QR kódy z krabiček léků a eviduje podání.
P.501 Podané léky se vyskladňují z příručního (klinického) skladu. Je přesná evidence léků konkrétní
šarže na pacienta.
P.502 Léky, které lze vykazovat jako ZULP se automaticky zapisují do dokladu pro plátce péče.
P.503 Systém poskytuje podklady pro statistiku spotřebovaných léků.
Tabulka 25: Medikace
Strana 67 / 127
3.3.19 Logistika a příruční (klinické) sklady SZM a LP
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.504 Centrální sklady léků a zdravotnického materiálu jsou v různých systémech (lékárna, ERP),
bez důležitých vazeb na NIS, musí proto plně komunikovat s klinickými sklady NIS ONP.
Systém proto musí podporovat:
1. komunikaci se sklady zdravotnického materiálu mimo NIS (integrace na sklady v ERP),
případně
2. komunikaci se systémem smluvního dodavatele léků (přes ústavní lékárnu) nebo jen
načítání z elektronických dodacích listů, pokud bude externí systém umožňovat
komunikaci přes komunikační rozhraní nebo generovat elektronické dodací listy.
P.505 Systém musí umět načítat do spotřeby přímo ze skladu SZM nebo přes klinické (příruční)
sklady oddělení (realizace těchto příručních/klinických skladů je součástí tohoto projektu).
Musí být zajištěna synchronizace číselníku zboží SZM. Určeno pro evidenci a vykázání nákladů
na pacienta nebo na výkon (např. operační) jako součást celkových nákladů. Číselník je
součástí systému.
P.506 Uživatelé musí být schopni předepisovat SZM a LP, které budou dále spravovány v rámci
místního zdravotnického zařízení. Řešení musí také umožnit výběr specifických informací,
jako např. název prostředku. Strukturovaný předpis probíhá ve vazbě na číselník
SUKL/ZP/individuální, umožňuje vazbu na příruční/klinický sklad oddělení.
P.507 Systém umí strukturovaně zadané SZM a LP přenést do jiných formulářů / zpráv.
P.508 Uživatelé by měli být schopni volit z nabídky SZM a LP, které jsou v daném
příručním/klinickém skladu k dispozici. Uživatelé musí mít informace o tom, na kterém
příručním či centrálním skladu se případně nachází daný SZP nebo LP.
P.509 Žádanky z oddělení na SZM, MTZ a služby budou řešeny integrací funkcionality žádanek
v systému ERP (např. vyvoláním funkcionality z prostředí NIS).
Žádanky z oddělení na LP
P.510 Žádanky z oddělení na LP budou řešeny novou funkcionalitou umožňující zadávání požadavků
na LP do externího systému, kde proběhne vícestupňové schvalování žádanek a komunikaci
a zajištění LP.
P.511 Systém obsahuje podporu zadávání a schvalování žádanek k dodávkám komodit pro potřeby
oddělení.
P.512 Možnost vytvořit žádanku dle ordinované léčby (předgenerace žádanky na základě
strukturované medikace).
P.513 Možnost třídit žádanky pro různé typy komodit – na základě zařazení komodit do skupin
léčiva, antibiotika, PZT a další.
Strana 68 / 127
# Požadavek
P.514 Musí umožnit vytvoření šablon (pro oddělení nebo uživatele) nebo zkopírovat již vytvořenou
žádanku.
P.515 Systém obsahuje parametr urgentnosti vyřízení žádanky.
P.516 Vytvářet žádanky ze standardizovaných produktových katalogů, označit a odlišit položky
zařazené na pozitivní list.
P.517 Produktový katalog plnit číselníky od dodavatelů, číselníků SÚKL (Seznam hrazených LP, KLK),
číselníkem VZP (PZT).
P.518 Využívat společné číselníky s klinickým informačním systémem (centrální registr, nákladová
střediska atd.)
P.519 Využívat regulace na pozitivní list – pro celé zdravotnické zařízení nebo pro jednotlivé
oddělení. V případě odchylky od pozitivního listu nutno zaznamenat důvod odchylky.
P.520 Nastavení rozpočtů (limitů na objednávání) pro nákladová střediska a možnosti editace pro
určené správce. Možnost rozlišení rozpočtů dle kategorií nakupovaného materiálu a období.
P.521 Musí umožnit nadefinovat konfigurovatelný vícestupňový schvalovací proces.
P.522 Zajištění předání žádanky v elektronické podobě do integrovaného systému nebo zaslání
dodavateli.
Číselníky
P.523 Katalog partnerů, NS, katalog léčiv a zdravotnického materiálu a prostředků zdravotní
techniky, účetní členění skladových položek, zařazení skladových položek do skupin,
uživatelské jednotky pro příjem a výdej (rozdílné) apod.
Doklady pohybů
P.524 Požadavky pro dané oddělení – sepsání požadavků před objednáním, sestavení požadavků
dle ordinovaných léků
P.525 Centralizace žádanek z oddělení
P.526 Schválení žádanky oprávněnou osobou
P.527 Převod do jiného skladu – přeskladnění zboží – 1. fáze: vyskladnění, možnost vytvořit dle
požadavku
P.528 Převod z jiného skladu – přeskladnění zboží – 2. fáze: naskladnění, automatické naskladnění,
ruční naskladnění
P.529 Příjem / zaevidování pacientem donesených léčivých přípravků (s provázáním s ordinovanou
léčbou)
P.530 Výdej:
Strana 69 / 127
# Požadavek
1. Možnost nastavení a následně dle nastavení metodou FIFO (first-in-first-out) nebo FEFO
(first-expirated-first-out)
2. Výdeje na nákladové středisko (NS) bez specifikace pacienta.
3. Výdeje na NS vázané na daného pacienta dle ordinovaných léků a plánované spotřeby
materiálu.
4. Výdeje exspirovaného a znehodnoceného zboží.
5. Výdeje / vrácení donesených léků pacientovi.
Podpora činností ve skladu na oddělení
P.531 Evidence stavu a pohybu léků, zdravotnického materiálu, prostředků zdravotní techniky a
dalšího zboží
P.532 Sledování exspirací
P.533 Komunikace s ekonomickými systémy
P.534 Využívání čárového kódu pro příjem, výdej a inventuru
Inventarizace zboží
P.535 Možnost zobrazit inventární rozdíly ve skladě k určitému datu. Zobrazení položek na
skladových kartách ke zvolenému datu inventury. K vypočtenému stavu skladu možnost
dopsat pro každou kartu skutečný stav a následně vytvořit výdejku nebo příjemku na tyto
rozdíly.
Výstupy
P.536 Provozní sestavy
Tabulka 26: Logistika a příruční/Klinické sklady SZM a LP
3.3.20 Distribuce zdravotnických dat
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.537 Výměna elektronické zdravotnické dokumentace prostřednictvím eHealth SčK s dalšími
subjekty a systémy (ZZ, NIX ZD a eH NCP)
1. Předmětem dodávky je Integrace (připojení) NIS zdravotnického zařízení na KCK (komunikační
centrum SČK) bude realizován v plné šíři tj. komunikace se ZZS SČK, komunikace s ostatními ZZ
SČK (případně jinými ZZ, pokud to KCK umožní), komunikace s pacienty v rozsahu předání
zprávy a možnosti přenesení potřebných dat pro Patient Summary (pokud je tato služba
podporována KCK) Datové rozhraní pro předávání dat mezi NIS a KCK bude v datovém
standardu DASTA (verze 3 nebo 4). Výměna dat bude probíhat online nebo asynchronně podle
služeb KCK Podporované musí být následující případy užití:
a. Vyhledání a poskytnutí životních údajů pacienta (demografické údaje, trvalé diagnózy,
alergie, rizikové faktory, trvalé medikace, přehled ambulantních a hospitalizačních
případů) (online)
Strana 70 / 127
# Požadavek
b. Vyhledání a poskytnutí pacientského souhrnu pro eH NCP (demografické údaje, trvalé
diagnózy, alergie, rizikové faktory, trvalé medikace, přehled ambulantních a
hospitalizačních případů) (online)
c. Vyhledání a poskytnutí vyžádané ambulantní a propouštěcí zprávy (online)
d. Poskytnutí údajů o volných lůžkových kapacitách (online)
e. Příjem a import výjezdové zprávy ZZS (asynchronně)
f. Příjem a import ambulantní a propouštěcí zprávy (asynchronně)
g. Příjem a import výsledků z vyšetření ambulantního typu (asynchronně)
h. Export a předání ambulantní a propouštěcí zprávy (asynchronně)
i. Export a předání žádanky ambulantního typu (asynchronně)
2. Součástí integrace s KCK bude také integrace (provolání) webového prohlížeče, který je
součástí KCK, umožňujícího náhled na životní údaje pacienta u jiných poskytovatelů.
V rámci NIS musí být zajištěna oprávněnost pro vyvolání této funkce na základě splnění
podmínek vycházejících z legislativy o přístupu k informacím ze zdravotnické
dokumentace jiného poskytovatele zdravotních služeb (uživatel poskytuje pacientovi
lékařskou službu a je oprávněn k nahlížení z důvodu kontinuity lékařské péče).
P.538 Schopnost předávat výsledky vyšetření a zprávy praktickým lékařům a ambulantním
specialistům dalšími způsoby – MISE, MedicalNet, atp. Tam kde je to možné, umožnit zadávání
žádanek na vyšetření z ambulantních systémů, před převzetím žádanky kontrola úplnosti
údajů v žádankách dle požadavků pracoviště či legislativy (především u RTG vyšetření).
1. Export výsledků vyšetření a lékařských zpráv ve formátu DASTA ve verzi podporované
příjemcem (předpokládá se maximálně verze 3 a 4) do definovaných adresářů s možností
určování adresáře dle příjemce
2. Import žádanek na vyšetření ve formátu DASTA ve verzi podporované odesilatelem
(předpokládá se maximálně verze 3 a 4) z definovaných adresářů s možností určování
adresáře dle odesilatele
Tabulka 27: Distribuce zdravotnických dat
3.3.21 Registrační autorita a kvalifikovaný elektronický podpis
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.539 Dodávka registrační autority, integrace této autority na externí certifikační autoritu a
přebírání elektronických podpisů z RA do NIS pro podepisování EZD.
P.540 Rozšíření NIS o zapojení kvalifikovaného elektronického podpisu do procesů zpracování EZD.
P.541 Evidence podpisových certifikátů pro jednotlivé uživatele informačního systému tak, aby bylo
možné realizovat kontroly oprávněnosti použití certifikátu při podepisování. Jde o jeden z
nástrojů autentizace elektronického dokumentu.
P.542 Implementace kvalifikovaného elektronického podpisu v oblasti podepisování EZD.
Strana 71 / 127
# Požadavek
P.543 Nástroje pro podporu evidence, správy a obnovy podpisových certifikátů jednotlivých
uživatelů
Tabulka 28: Registrační autorita a kvalifikovaný elektronický podpis
3.3.22 Databáze NIS
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.544 Řešení musí být homogenní z hlediska databázového prostředí, musí použit pouze jeden typ
databáze (např. MS SQL, aj.) pro celé řešení a optimalizovaný licenční model.
Technologie musí respektovat prostředí zadavatele – viz kap. 6.5.5 – Technologie využívané
objednatelem.
P.545 Databáze musí být zabezpečena tak, aby systém plnil požadavky uvedené v kapitole 3.3.34
Tabulka 29: Databáze NIS
3.3.23 Správa systému
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.546 Správa systému na úrovni uživatelů, struktury pracovišť, certifikátů, oprávnění apod.
P.547 Možnost vytváření vlastních statistik (správcem, klíčovým uživatelem) ze strukturovaných dat
o operaci zadaných do systému.
P.548 Systém umožní nastavitelnost sémantických a syntaktických kontrol správnosti výkaznických
dat pomocí konfiguračního nástroje pro správce výkaznictví – aplikace musí umožňovat
rozdílné nastavení stejných kontrol pro různé plátce, IČZ, IČP, uzly organizační struktury a
různé události práce s daty (pořízení, přepočty, importy, sestavení dávek apod.).
P.549 Možnost vytvoření nové správcovské kontroly (SQL procedury) nad doklady a zařazení do
aplikace bez nutnosti zásahu dodavatele a verzování aplikace.
P.550 Uživatel (správce NIS) musí mít možnost jednoduše dodělávat další potřebné statistiky nad
daty strukturovaně zadanými do NIS.
P.551 Správa rolí systému: Systém musí umožnit aplikačnímu administrátorovi průběžnou změnu
definice jednotlivých rolí (přidávání a odebírání, aktualizace zpřístupněných dat atd.) na
úrovni odpovídající požadovanému stupni informační bezpečnosti (omezení na úrovni
zobrazení, editace, validace logické množiny dat). Toto realizovat min. v rozsahu množin
odpovídající tabulce rolí (viz dále).
Tabulka 30: Správa systému
Strana 72 / 127
3.3.24 Auditní služby
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.552 Navržená softwarová aplikace umožní provádět audity užití na základě interních logů
aplikace, které zaznamenávají a ukládají údaje o změnách či nahlížení do pacientské
dokumentace podle identity uživatelů.
P.553 Řešení umožní poskytovat auditní reporty o přístupech uživatelů (kdo, kdy, období, kam) na
základě parametrizace prováděné pověřeným auditorem.
P.554 Auditní (logovací) aparát je nezávislý a dostupný pouze určené roli (auditor). Není dostupný
a manipulovatelný uživateli, administrátory ani správci.
P.555 Systém musí umožnit automatizované i manuální vystoupení logových záznamů do externích
systémů pro správu logů (log management, SIEM) a do tabulek MS Excel (.csv, .xlsx)
P.556 Auditní systém musí být v souladu s nařízení EU o ochraně osobních dat (GDPR).
Tabulka 31: Auditní služby
3.3.25 Napojení NIS ONP na eHealth systém kraje
Součástí projektu je napojení na eHealth systém Středočeského kraje v následujícím rozsahu
funkcionalit:
# Požadavek
P.557 Vyhledání životních údajů pacienta (Emergency card – EC).
P.558 Předání výjezdové zprávy ZZS do nemocnice.
P.559 Náhled na propouštěcí a ambulantní zprávy při výjezdu ZZS.
P.560 Sdílení informací o dostupnosti volných lůžek pro urgentní příjem.
P.561 Výměna dat mezi zdravotnickými zařízeními včetně dokumentů zdravotnické dokumentace
vedené v elektronické formě.
P.562 Sdílení dat o zdravotní péči mezi zdravotnickými zařízeními.
Tabulka 32: Napojení NIS ONP na eHealth systém kraje
3.3.26 Portál pacienta
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.563 Řešení musí umožnit pacientům vzdálené objednání termínu a času zdravotní služby a dále
umožnit zabezpečený vzdálený autorizovaný přístup k vybraným informacím a ze
zdravotnické dokumentace o jim poskytnutých zdravotních službách a jejich výsledcích.
Strana 73 / 127
# Požadavek
P.564 Řešení musí zahrnovat jednoduché a dynamické uživatelské rozhraní, které nevyžaduje žádné
proškolení uživatelů a je dostupné zabezpečeným způsobem přes internet prostřednictvím
běžných webových prohlížečů (Firefox, Internet Explorer, Google Chrome, Safari) ve verzi
dostupné v době implementace. Design uživatelského rozhraní bude navržen tak, aby v
případě použití dotykového zařízení a prohlížeče podporujícího ovládání pomocí dotykového
zařízení bylo ovládání ergonomické (usnadňovalo ovládání dotykem). Uživatelské rozhraní
bude umožňovat rozpoznání velikosti obrazovky a přizpůsobí zobrazení velikosti této
obrazovky, aby bylo použitelné i pro menší rozlišení.
P.565 Domovská stránka musí po přihlášení uživatele (pacienta) zobrazovat relevantní údaje o
pacientovi, jako např. jeho demografické údaje a aktivní upozornění na plánovaná vyšetření
a prohlídky a odkazy na další sekce s aktuálními informacemi z poskytnutých zdravotních
služeb.
Přihlášení k účtu uživatele (uživatelskému profilu), tzn. proces identifikace a autentizace
uživatele, bude podporovat i alternativní metody přihlášení, konkrétně využití služeb NIA,
pokud to v době realizace dodávky bude legislativně a technicky možné.
Pro zvýšení bezpečnosti přístupu k údajům ze zdravotnické dokumentace je požadována
• více faktorová autentizace (např. zadáním kódu doručeného v SMS),
• fyzické ověření elektronické identity uživatele pověřeným pracovníkem ONP před
aktivací oprávněnosti přístupu (jako náhrada dosud neexistující infrastruktury
důvěryhodné externí identity).
Více faktorová autentizace a ověření identity nejsou vyžadovány, pokud uživatel bude
využívat pouze službu online objednání, která navíc může být dostupná i pro neregistrované
a nepřihlášené uživatele – v tomto případě s omezením jen na funkci odeslání objednávky
s rezervací termínu a času.
Veškeré přístupy, zejména ke zdravotnickým informacím, musí být logovány a zaznamenány
do auditního logu.
P.566 Komunikace s NIS musí probíhat online. Portál nebude perzistentně ukládat kopie dat z NIS.
P.567 Webové uživatelské prostředí musí obsahovat hlavní navigační menu, které pacientům
poskytne rychlý přístup do hlavních oblastí, jako např.:
1. přehled poskytnutých zdravotních služeb,
2. osobní data a nastavení,
3. souhrnný elektronický zdravotní záznam pacienta vybraných údajů ze zdravotnické
dokumentace
4. přehled plánované péče a upozornění na aktuální naplánovaná vyšetření a prohlídky,
5. online objednání zdravotní služby a rezervace termínu a času u těch služeb, které
umožňují plánování termínů.
P.568 Souhrnný elektronický zdravotní záznam pacienta musí obsahovat údaje vedené o pacientovi
v rozsahu
Strana 74 / 127
# Požadavek
• osobní, demografické a kontaktní údaje,
• emergentní údaje (anamnézy, alergie, rizikové faktory, akutní diagnózy, akutní
medikace),
• přehled ambulantních a hospitalizačních případů s možností zobrazení výstupních
lékařských zpráv z poskytnutých zdravotních služeb (v případě existence dokumentu
ve formě EZD také přístup k této formě dokumentu),
• pacientský souhrn (v případě, že v době realizace projektu bude vydán metodický
pokyn MZd pro vedení tzv. „elektronického pacientského souhrnu“).
P.569 Řešení musí nabízet funkci automatického zasílání upozornění pacientům formou e-
mailových zpráv anebo SMS zpráv. Seznam všech archivovaných upozornění a varování musí
být také součástí řešení. Vlastní doručování e-mailových zpráv a SMS zpráv není předmětem
plnění a bude zajištěno zadavatelem separátně. Předmětem plnění je jen integrace na
poskytnutá rozhraní systémů nebo služeb pro distribuci.
P.570 Řešení musí umožnit uživateli zaznamenat a měnit osobní údaje.
P.571 Internetové objednávání bude podporovat následující funkce:
1. Výměna dat musí probíhat zabezpečeným způsobem s využitím šifrovacích mechanismů.
2. Volné termíny, nastavení vlastností objednávacích diářů apod. se přebírají z NIS.
3. Objednávky se odesílají a ukládají přímo do diáře lékaře na příslušném pracovišti v NIS.
4. Objednávku za pacienta může provést i externí lékař.
5. Řešení musí umožnit vyhledání pracoviště poskytující danou zdravotní službu.
6. Vystavení objednávky bude možné dle nastavení vlastností diářů v NIS s rezervací termínu
a času, jen s rezervací termínu, bez rezervace.
7. Uživatel bude mít možnost zapsat poznámku do objednávky.
8. Po odeslání objednávky do NIS bude ze strany rozhraní NIS vráceno potvrzení o
zpracování objednávky, které se zobrazí bezprostředně na obrazovce, bude odesláno na
e-mailem pacienta s možností automatického vložení doplňujících informací k
objednanému vyšetření, nebo stručné potvrzení formou SMS.
9. Bude možné provést storno objednávky ze strany pacienta.
10. O provedení storna nebo změny objednávky ze strany personálu nemocnice v NIS bude
pacient informován prostřednictvím e-mailu a SMS.
11. Řešení bude umožňovat automatické upozorňování na blížící se termín vyšetření e-
mailem a SMS.
Tabulka 33: Portál pacienta
Strana 75 / 127
3.3.27 PACS + modality worklist
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.572 Systém musí umožnit zpracování pracovních listů modalit (MWL, modality worklist) na
základě informací z žádanky na vyšetření.
P.573 Systém musí přijímat a zpracovávat informace o stavu procedur na modalitách.
P.574 Systém musí být schopen z prostředí NIS otevřít DICOM prohlížeč a zobrazení konkrétních
vyšetření z PACS voláním dotazu dle definovaných parametrů (např. Accession Number, ID
pacienta) a umožnit jejich popis v NIS.
Obecné požadavky
P.575 Uživatelské prostředí musí být moderní, intuitivní a uživatelsky přívětivé,
P.576 Všechny části systému musí být integrované a modulárně koncipované,
P.577 Administrativní a uživatelská náročnost na obsluhu systému/aplikací a doba reakce
systému/aplikací na jednotlivé uživatelské úkony a zpracování dat musí být minimální,
P.578 Uchazeč musí zajistit na vlastní náklady úpravu systému/aplikací tak, aby odpovídaly dále
uvedeným požadavkům a případným požadavkům zadavatele na snížení administrativní
zátěže a uživatelské náročnosti (snadná obsluha, přizpůsobení uživatelského prostředí apod.).
V případě, že bude uchazeč pro tyto požadavky potřebovat dodávku jiného SW/HW vybavení,
než je součástí požadavků zadavatele, uchazeč je povinen na své náklady dodat takovéto
SW/HW vybavení.
P.579 Veškeré nabízené SW i HW prvky musí být plně kompatibilní se stávajícím systémem PACS
(MARIE PACS, dodavatel OR-CZ spol. s r.o.). Součástí implementace musí být i veškeré
potřebné licence a služby dodavatele PACS.
P.580 Soubor dodaného aplikačního programového vybavení, tzn. všechny nabízené SW moduly,
musí být certifikován jako „Zdravotnický prostředek třídy IIa nebo vyšší“ v souladu se
zákonem č. 268/2014 Sb., o zdravotnických prostředcích, nařízením EU MDD 93/42/EEC a
nařízením vlády č. 54/2015 Sb.
Nástroj pro administraci a správu zdravotnické obrazové dokumentace
P.581 Pro správu zdravotnické obrazové dokumentace je požadován webový portál, který zajistí
řízený a logovaný přístup uživatelů pouze k obrazovým datům, na která mají oprávnění.
P.582 Webový portál bude možné spustit nezávisle na specializovaných pracovních stanicích pouze
z prostředí běžného internetového prohlížeče.
P.583 Portál bude bez omezení počtu uživatelů (multilicence).
P.584 Seznam vyšetření uložených v PACS, vč. možnosti zobrazení detailu vyšetření, zobrazení
vlastního vyšetření ve webovém diagnostickém a klinickém DICOM prohlížeči a využití dále
definovaných funkcí z detailu vyšetření, vyhledávání musí být možné min. podle následujících
Strana 76 / 127
# Požadavek
parametrů: jméno pacienta, ID pacienta, číslo žádanky, typ modality, datum narození, od/do
data vytvoření vyšetření.
P.585 Import DICOM dat s výběrem DICOM archivu, do kterého se importují data.
P.586 Import ne-DICOM dat (min. JPG, PDF) s výběrem DICOM archivu, do kterého se importují
data.
P.587 Při importu ne-DICOM dat vazba na centrální registr pacientů v NIS, ze kterého budou
přebírány údaje o pacientovi, nebo možnost vazby na worklist a vytvoření importu na základě
tohoto worklistu.
P.588 Export vyšetření min. do následujících formátů:
1. formát JPG – v komprimované či nekomprimované podobě na úrovni snímek, série,
studie
2. formát MP4 – v komprimované či nekomprimované podobě s možností nastavení
FPS na úrovni snímek, série, studie
3. formát DICOM – na úrovni snímek, série, studie
P.589 Vypalování dat na CD/DVD vč. prohlížeče (vzhledem k zabezpečení webových prohlížečů lze
pro tuto funkci využít instalace doplňkového modulu nebo s využitím samostatného SW),
P.590 Oprava demografických dat pacientů (min. jméno pacienta, ID pacienta, číslo žádanky, datum
narození, pohlaví, datum vytvoření vyšetření, čas vytvoření vyšetření),
P.591 Rozdělování, přeskupení a slučování vyšetření – přesun vybraných sérií mezi různými
vyšetřeními, rozdělení vyšetření a přenesení vybraných sérií do nového vyšetření.
P.592 Přesun dat mezi různými (připojenými) DICOM uzly – možnost přesunu nebo kopírování
vyšetření nebo pouze jednotlivých sérií mezi připojenými DICOM uzly – tato funkce slouží
např. pro přesun dat z odděleného obrazového archivu do centrálního PACS,
P.593 Vkládání komentářů k jednotlivým vyšetřením vč. údajů o času vytvoření komentáře a jeho
autorovi,
P.594 Možnost vytváření žádanek na provedení vyšetření v rámci nemocnice i mimo ni, v případě
interní potřeby možnost vazby na modality worklist, Součástí žádanky musí být možné vyplnit
min. následující údaje: jméno a příjmení pacienta, ID pacienta, datum narození, pohlaví, kód
zdravotní pojišťovny, datum žádosti, odbornost, urgentnost a typ požadovaného vyšetření.
P.595 Možnost výběru vyšetření pro zachování ve vybraném připojeném DICOM archivu, který má
nastavené automatické odmazávání (např. uchování dat v odděleném obrazovém archivu),
P.596 Možnost odesílání dat přes ePACS, ReDiMed vč. výběru sítě, přes kterou se data posílají a
možností rychlého hledání v seznamu příjemců,
P.597 Zobrazení statistik zaplnění úložiště provozovaného systému (roční/měsíční přehled
uložených dat v TB),
Strana 77 / 127
# Požadavek
P.598 Zobrazení statistik počtu vyšetření za vybrané období dle konkrétní modality,
P.599 Možnost centrální správy přístupových práv uživatelů (dle rolí) a vytváření uživatelských
skupin pro přístup k jednotlivým funkcím uvedeným výše,
P.600 Možnost autentizace uživatelů při spouštění prostřednictvím Active Directory / LDAP a řízení
oprávnění na úrovni role a pracoviště uživatele,
P.601 Logování veškerých činností uživatelů vč. možnosti prohlížení logů a jejich filtrace (uživatel,
datum apod.), a možnost exportu logů,
P.602 Technologie, která nevyžaduje instalaci doplňkových modulů do webového prohlížeče
(například HTML5),
P.603 Responsivní vzhled pro použití na jakémkoliv koncovém zařízení (tablet, chytrý telefon,
stanice, atd.),
P.604 Součástí portálu bude i integrace odděleného PACS archivu pro práci s daty z externích zdrojů
(USB, CD/DVD, ePACS, ReDiMed), který již Zadavatel provozuje. Ke snímkům v odděleném
archivu se bude přistupovat prostřednictvím webové portálu, ale také prostřednictvím
diagnostické i klinické verze webového prohlížeče,
P.605 Všechny požadované funkce, které jsou součástí portálu budou dostupné pro všechny
připojené DICOM archivy,
P.606 Integrovaný webový diagnostický i klinický DICOM prohlížeč s funkcionalitou uvedenou v
následujícím bodě technické specifikace. Na základě role uživatele musí systém umožňovat
spuštění diagnostické nebo klinické verze webového DICOM prohlížeče, který je součástí
dodávky.
Centrální DICOM prohlížeč – obecné vlastnosti centrálního DICOM prohlížeče
P.607 Zadavatel požaduje dodávku multimodalitního centrálního prohlížeče určeného pro
diagnostické i klinické použití s architekturou server-klient.
P.608 Provoz klientské části nezávisle na operačním systému pracovní stanice pouze v prostředí
standardního webového prohlížeče/browseru bez nutnosti instalace dalšího SW (aplikací,
modulů, appletů či knihoven), tedy bez použití např. ORACLE Java, Microsoft .NET
FrameWork, Adobe Flash apod.,
P.609 Ověřená kompatibilita s nejrozšířenějšími webovými prohlížeči/browsery – minimálně s MS
Internet Explorer (v. 11 a vyšší), Mozilla Firefox, Apple Safari, a to na 32bit i 64bit platformě,
P.610 Podpora zobrazení na různých koncových zařízeních zařízení – PC, notebook, tablet, smart
phone apod.,
P.611 Serverová část SW musí být nativní 64-bit. aplikací (tedy že aplikace nelze provozovat na 32-
bit. nebo starší platformě), klientskou část musí být možné provozovat na 32-bit. i 64-bit.
platformě,
Strana 78 / 127
# Požadavek
P.612 Kompatibilita se standardem DICOM verze 3.0,
P.613 Podpora DICOM služeb: Query/Retrieve, Store,
P.614 Podpora připojení neomezeného počtu různých zdrojů obrazových dat (např. možnost
přímého odesílání obrazových dat z modalit do centrálního prohlížeče, napojení libovolného
počtu DICOM archivů různých výrobců),
P.615 Možnost zabezpečeného přístupu přes síť Internet odkudkoliv i mimo areál nemocnice
(podpora HTTPS certifikátu),
P.616 Centrální prohlížeč musí umožňovat centrální správu uživatelských účtů a nastavení
jednotlivých uživatelských profilů nebo skupin,
P.617 Centrální prohlížeč musí umožňovat autentizaci uživatelů při spouštění prostřednictvím
Active Directory a řízení oprávnění na úrovni role a pracoviště uživatele,
P.618 Napojení na stávající NIS minimálně v rozsahu:
1. spuštění prohlížeče z prostředí NIS pomocí šifrovaného URL odkazu s parametrem
Accession Number, případně podle dalších parametrů (např. ID pacienta), tak aby
zobrazil vyšetření příslušející k dané žádance,
2. zobrazení textového popisu vyšetření v prostředí prohlížeče (vždy je načítán aktuální
textový popis z NIS a tento textový popis se neukládá do PACS), komunikaci, formát
přenášených dat a další služby je povinen zajistit uchazeč v rámci zajištění součinnosti
dodavatele NIS,
P.619 Systém musí umožňovat zpětné dohledání přístupu konkrétního uživatele k dané obrazové
dokumentaci nebo pacientským datům po celou dobu životního cyklu řešení, tato
funkcionalita musí být zákaznicky dostupná prostřednictvím přehledného nastavení (např.
přes HTML formulář),
P.620 Podpora uživatelsky editovatelných klávesových zkratek, tlačítek myši,
P.621 Funkce pro zobrazení všech vyšetření pacienta, ze všech připojených zdrojů dat, na časové
ose, možnost filtrace zobrazovaných vyšetření na časové ose,
P.622 Podpora zobrazení DICOM SR (Structured Report),
P.623 Podpora zobrazení medicínských zpráv v jiných formátech (např. *.pdf),
P.624 Podpora zobrazení MPEG-4 přímo v prostředí prohlížeče bez spouštění SW třetích stran,
P.625 Možnost rychlé volby pro zobrazení/skrytí DICOM atributů (volby pro skrytí údajů o
pacientovi /vyšetření, orientace snímku, anotace, referenční čáry, apod.),
P.626 Možnost rozdělení obrazovky horizontálně i vertikálně pro zobrazení více snímků na jednom
monitoru v rámci jednoho vyšetření a pro porovnání vícero vyšetření,
P.627 Možnost ručního propojení sérií pro synchronní zobrazení dvou a více sérií.
Strana 79 / 127
# Požadavek
Centrální DICOM prohlížeč – požadovaná funkcionalita diagnostické verze centrálního DICOM
prohlížeče
P.628 Základní měření: denzita, pravítko, tříbodový úhel, poměr, kalibrace,
P.629 Manipulace s dvourozměrnými, i 3D snímky (nastavení W/L, nastavení LUT, zvětšení,
posouvání, lupa, rotace…),
P.630 Možnost rozdělení obrazovky,
P.631 Video smyčka,
P.632 Možnost vkládání anotací,
P.633 Podpora manuální a automatické synchronizace snímků, sérií a vyšetření,
P.634 Vytvoření klíčových snímků dle standardu DICOM (Key objects) vč. jejich zobrazení a možnosti
uložení jako nové série vyšetření
P.635 Možnost porovnání vyšetření různých pacientů,
P.636 MPR, 3D (objemová rekonstrukce, MIP, průměr), 3D kurzor.
P.637 Fúze pro neomezené množství modalit (min. ze 3 modalit – PET CT, MR, CT),
P.638 Pokročilé měření: elipsa, obrys, kruh, čtverec, obdélník, mnohoúhelník, ROI, Cobbův úhel,
zakřivení, zobrazení statistiky v ROI – max., průměr, směrodatná odchylka, gamma korekce
P.639 Možnost práce s EKG signály generovanými ve formátu DICOM min. v rozsahu:
1. zobrazení 12-svodového záznamu,
2. možnost zobrazit pouze vybraný svod/vybrané svody,
3. možnost daný signál zvětšovat a posouvat v průběhu signálu,
4. možnost porovnávat dva a více různých signálů,
5. zobrazení základních informací o signálu,
6. měření amplitud a period,
7. tisk signálu v odpovídajícím měřítku včetně cejchu,
P.640 Závěsné (hanging) protokoly – možnost pokročilé definice hanging protokolů a kombinace
pravidel pro zobrazení vyšetření. Musí být možné definovat min. rozložení obrazu (rozdělení
obrazovky/obrazovek) dle typu vyšetření, počet diagnostických monitorů a nastavení
zobrazení na každém z nich vč. nastavení zobrazení na tabletu či telefonu, automatické
porovnání aktuálního a předchozích vyšetření, definice nastavení výchozí hodnot jako je např.
WL, zoom, nastavení pozice otevření vyšetření, MPR, 3D rekonstrukce, apod. Všechna tato
pravidla musí být možné kombinovat. Uživatelé musí mít také možnost uložit aktuální
nastavení prohlížeče při práci s vyšetřením jako hanging protokol.
Strana 80 / 127
# Požadavek
P.641 Centrální prohlížeč musí umožňovat správu rozvržení panelu nástrojů na pracovní ploše
prohlížeče.
P.642 Možnost přednastavení šablon pro různé typy vyšetření. Šablony umožňují přednastavení
hodnot window level, případně další parametry,
P.643 Uživatelské přednastavení šablon pro různé typy vyšetření. Šablony umožňují přednastavení
hodnot window level, případně další parametry,
P.644 Centrální prohlížeč musí umožňovat uživatelské nastavení viditelnosti konkrétních DICOM
tagů na obrazovce prohlížeče dle typu modality – musí být možné zobrazit libovolný DICOM
tag
P.645 Indikátor aktuálně otevřené série,
P.646 Automatické dočítání otevřených nedokončených/rozpracovaných vyšetření,
P.647 Možnost uložení rozpracovaného stavu vyšetření na server pro následné použití (po
přihlášení z jiného koncového zařízení, musí být možné zobrazit vyšetření v uloženém
rozpracovaném stavu včetně komentářů, měření, rozložené obrazu, W/L apod.),
P.648 Integrovaná, zabezpečená online vzdálená konzultace více uživatelů s následujícími
vlastnostmi:
1. sdílení pohledu v reálném čase na stejná dynamická obrazová data,
2. v rámci konzultace musí být umožněno každému účastníkovi konzultace pracovat
individuálně s vyšetřením, aniž by úpravy vyšetření vytvořené uživatelem viděli
ostatní účastníci konzultace a zároveň musí mít každý účastník možnost provedené
úpravy vyšetření zobrazit ostatním účastníkům konzultace. Sdílení provedených
úprav vyšetření musí být provedeno formou přenesení pouze příkazů, aniž by se
přenášela vlastní obrazová data (z důvodu rychlosti komunikace a zabránění zatížení
sítě přenosem obrazových dat),
3. vkládání značek a textových poznámek,
4. neomezený počet současně spolupracujících uživatelů nad jedním vyšetřením,
5. neomezený počet současně aktivních konzultací,
6. podpora přizvání hostů, kteří nemají vytvořený účet pro přístup do systému, k on-line
konzultaci (podpora externích spolupracovníků),
P.649 Možnost vytvoření a odeslání odkazu na vyšetření vč. možnosti odeslání odkazu na
rozpracované vyšetření (např. pro konzultaci vyšetření, apod.),
P.650 Podpora pro přehrávání smyček z ultrazvuku, angiografie, laparoskopie apod., možnost
nastavení rychlosti a rozsahu přehrávání,
P.651 Tvorba složek a pracovních seznamů,
P.652 Import DICOM a non-DICOM souborů,
Strana 81 / 127
# Požadavek
P.653 Export vyšetření/snímků ve formátu DICOM, MP4, JPG, PNG s možností anonymizace dat pro
publikační a prezentační účely,
P.654 Pro zpracování 3D rekonstrukcí možnost využití výkonu grafických karet v diagnostických
stanicích a na serveru pro sdílení jejich výkonu pro více koncových zařízení – možnost definice
priorit využití graf. karet na základě IP adres, apod.
Centrální DICOM prohlížeč – požadovaná funkcionalita klinické verze centrálního DICOM prohlížeče
P.655 Základní měření: densita (bod, elipsa, obdélník), pravítko, tříbodový úhel, Cobbův úhel
manipulace s dvourozměrnými snímky (W/L, zoom, lupa, posouvání, rotace, inverze atd.),
P.656 Video smyčka,
P.657 Podpora manuální a automatické synchronizace snímků, sérií a vyšetření,
P.658 Stejné uživatelské prostředí jako v diagnostické verzi
Propojení PACS – NIS a oprava demografických dat
P.659 Zajištění komunikace PACS s NIS pomocí mezinárodních standardů: DICOM, IHE, HL7, atd.
P.660 Konfigurace a zprovoznění komunikace, nastavení datových toků vč. konfigurace funkcí pre-
fetch.
P.661 Podpora komunikace s NIS pomocí web services,
P.662 Komunikace s NIS přes mezinárodní standard HL7
P.663 Příjem nebo načtení textových popisů vyšetření uložených v NIS a jejich zobrazení v DICOM
prohlížečích,
P.664 Otevření DICOM prohlížeče a zobrazení konkrétních snímků z prostředí NIS voláním dotazu
dle definovaných parametrů (např. Accession Number, ID pacienta),
P.665 Příjem podkladů pro sestavení MWL (pracovní seznam modality) a jejich distribuce
modalitám na základě žádanky vystavené v NIS,
P.666 Možnost automatické opravy dat uložených v centrálním PACS na základě informace předané
z NIS - rozšíření funkcionality stávajícího PACS o modul zajišťující automatickou
změnu/opravu demografických dat pacientů uložených v PACS na základě změny dat
provedených v NIS,
P.667 Informace o stavu zpracování studie (MPPS) a předání informace do NIS,
P.668 Vazba na centrální registr pacientů v NIS pro využití této funkce při importu dat či provádění
oprav v prostředí nástroje pro administraci a správu zdravotnické obrazové dokumentace,
který je předmětem veřejné zakázky.
Strana 82 / 127
# Požadavek
Licence a vyloučení omezení
P.669 10x licence (pro současně pracující uživatele) webového diagnostického DICOM prohlížeče,
P.670 neomezená multilicence webového klinického DICOM prohlížeče,
P.671 neomezená multilicence nástroje pro správu obrazové dokumentace,
P.672 Zadavatel požaduje kompletní dodávku potřebných licencí, které zaručují odstranění
veškerých případných limitů na funkcionality centrálního prohlížeče.
P.673 Nabízení řešení nesmí pro svůj provoz vyžadovat přítomnost bezpečnostních předmětů
souvisejících s licenční ochranou dodávaného aplikačního software na straně serveru ani na
straně klienta (např. použití hardwarových licenčních tokenů, aj.).
P.674 Součástí nabídky, resp. nabídkové ceny bude technický popis realizace a případná dodávka
nebo zápůjčka potřebných HW a SW nástrojů (např. migračního kontroléru s obslužným SW
nebo dočasného datového úložiště pro případnou migraci dat),
P.675 Součástí projektu je i případná instalace a implementace stávajících SW licencí jádra PACS
na nově dodaný HW a napojení všech stávajících modalit s DICOM výstupem.
P.676 v rámci implementace musí dodavatel zajistit plnohodnotný provoz dodávaného řešení
současně s provozem stávajících systémů. To vše bez jakéhokoliv omezení provozu. Uchazeč
do nabídky popíše postup přechodu systémů. Uchazeč je povinen přizpůsobit realizaci
předmětu zakázky podmínkám zadavatele.
Tabulka 34: PACS + modality worklist
3.3.28 Manažerský informační systém (MIS)
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.677 Sestavy a statistiky musí umožnit členění min. dle období, IČP (provázané na NS),
poskytovatele, ZP, primariátů atd.
P.678 Minimální požadavky na sestavy a statistiky:
1. Sledování produkce v souladu s DRG
2. Přehled lůžkového fondu
3. Ambulantní vyšetření
4. Počty operací
5. Počty porodů
6. Nákladný pacient
7. Extramurální péče
8. Léková preskripce ZP, za jednotlivé primariáty s rozpadem na jednotlivá NS - na
jednotlivé lékaře, na jednotlivé léky.
Strana 83 / 127
# Požadavek
9. Sestavy na záchyt receptů vydaných v lékárně v porovnání s předepsanými léky za
zadané období (porovnání dle primariátu – rozpad na NS, na jednotlivé léky) zadáme
lék, období a zobrazí se sestava, kde budou uvedeni lékaři a počet předepsaného léku
10. Sestava nevydaných ZUM, ZULP z meziskladů na odd.
11. ZULP, ZUM a cena VZP MAX (číselník VZP) a k těmto kódům budou přiřazeny kódy
a ceny léků na žádanku z lékárny případně ze skladů zdravotního materiálu (Konsig.
sklady, centrální sklad SZM).
12. Sledování evidence obsazenosti nadstandartních lůžek a lůžek se zvláštním režimem
– např. Izolace.
Všechny sestavy lze porovnat v rámci 3 zadaných období.
P.679 Možnost tvorby vlastních/běžných statistik ze strany zadavatele (bez nutnosti objednávat u
dodavatele) na základě předdefinovaných struktur dat z DB NIS.
V rámci dodávky budou dodavatelem předdefinované struktury dat pro zajištění možnosti
tvorby vlastních/běžných statistik ze strany zadavatele.
Tabulka 35: Manažerský informační systém
3.3.29 Dodávka nezbytné HW infrastruktury a nezbytného systémového SW
pro modernizovaný NIS a jeho nové části/funkcionality
V této kapitole jsou uvedeny požadavky na vybavení DC, tj. dodávky nezbytné HW infrastruktury a
nezbytného systémového SW pro NIS ONP.
Objednatel nepředepisuje technologii, jen principy a požadavky na řešení. Technologie bude navržena
dodavatelem v nabídce v rámci veřejné zakázky s respektováním limitních podmínek.
HW a SW infrastrukturu lze specifikovat jen v rozsahu minimálního rozšíření stávající technologie (viz
kap. 6.5.4). Není možné specifikovat další potřeby technologií jednotlivých uchazečů, protože jsou
závislé na zvolené technologii v rámci řešení konkrétního uchazeče.
Požadavky na technické vybavení vycházejí z prostředí Objednatele uvedeného v kap. 6.5 – Informační
systémy, infrastruktura a technologie. Požadavky slouží pro rozšíření stávajícího prostředí Objednatele
tak, aby bylo využito maximum existujícího prostředí Objednatele a doplněno jen částmi, které jsou
nezbytné pro funkčnost dodávaného systému.
Konkrétní požadavky na vybrané technologie vyplývají z ochrany investic, kompatibility se současným
prostředím Objednatele a z provozních potřeb Objednatele, kdy je nutno zajistit provoz, dohled a správu
těchto zařízení pracovníky, kteří jsou k tomu již vyškoleni a disponují potřebnými technickými znalostmi.
# Požadavek
P.680 Využití existujících serverů uvedených v kap. 6.5.4 – Datová centra, HW infrastruktura a
P.681 technologie.
Pokud dodavatele nehodlá využít existující servery, dodá vlastní servery a v nabídce popíše
nabízenou konfiguraci serverů.
Do každého ze serverů (viz kap. 6.5.4) doplnění paměti min v následujícím rozsahu:
Strana 84 / 127
# Požadavek
• Servery PE R430: doplnění min. 64 GB paměti do každého ze serverů.
• Servery PE R530: doplnění min. 64 GB paměti do každého ze serverů.
Požadavky jsou minimální, tj. pokud dodavatel požaduje pro své řešení další navýšení
paměti, dodá do serverů vyšší kapacitu a uvede to ve své nabídce.
P.682 Do každého ze serverů PE R530 doplnění komunikačního rozhraní: Emulex LPE 16002, Dual
Port 16Gb Fibre Channel HBA - Kit (406-10549) vč. CUS,ADPT,SFP,FC16,16G,TRIBES [2X SFP,
FC16, 16GB, Customer Kit]
P.683 Využití existujícího diskového pole uvedeného v kap. 6.5.4 – Datová centra, HW
infrastruktura a technologie.
Pokud dodavatele nehodlá využít existující diskové pole, dodá vlastní diskové pole a
v nabídce popíše nabízenou konfiguraci diskového pole.
P.684 Rozšíření stávajícího diskového pole (viz kap. 6.5.4) o kapacitu min. 10 TB a o rozšiřující polici
pro umístění disků.
Požadavky jsou minimální, tj. pokud dodavatel požaduje pro své řešení další navýšení diskové
kapacity, dodá vyšší diskovou kapacitu a uvede to ve své nabídce.
P.685 Kompatibilita se stávajícími technologiemi Objednatele uvedené v kap. 6.5 – Informační
systémy, infrastruktura a technologie.
PACS (specifické požadavky)
P.686 2x Datové úložiště typu NAS, každé datové úložiště s celkovou kapacitou min. 32 TB
pro archivaci zdravotnické obrazové dokumentace. Minimální konfigurace každého
datového úložiště:
1. CPU o výkonu min. 10000 bodů Passmark CPU Mark (dle
http://www.cpubenchmark.net/ ke dni 4.1.2018),
2. 16 GB RAM,
3. 2x 1Gbit LAN,
4. 2x 500 GB HDD SATA,
5. datová kapacita 32TB (disky určené pro provoz 24x7),
6. zálohovaný HW řadič,
7. redundantní zdroj napájení,
8. integrovaný modul pro vzdálenou správu,
9. potřebný operační systém pro běh SW licencí.
Tabulka 36: Dodávka nezbytné HW infrastruktury a nezbytného systémového SW pro modernizovaný NIS a jeho nové
části/funkcionality
Strana 85 / 127
3.3.30 Tiskárny náramků s čárovými kódy
Požadované minimální parametry tiskáren náramků s čárovými kódy jsou:
# Požadavek
P.687 Tiskárna pro tisk identifikačních náramků pro pacienty pro následnou identifikaci.
P.688 Napojeny/kompatibilní s NIS a realizace tisk z NIS.
P.689 Vhodné do nemocničního provozu – vodě odolné, odolné proti znečištění apod.
P.690 Připojení prostřednictvím USB nebo síťového připojení
P.691 Komunikace s obsluhou a dokumentace v českém jazyce.
Tabulka 37: Tiskárny náramků s čárovými kódy
3.3.31 Čtečky čárových a QR kódů
Požadované minimální parametry čteček čárových a QR kódů jsou:
# Požadavek
P.692 Čtečka čárových kódů a QR kódů.
P.693 Bezdrátová čtečka.
P.694 Vhodná do zdravotnického prostředí – vodě odolné, odolné proti znečištění, odolnost proti
čištění dezinfekčními prostředky používanými běžně ve zdravotnictví, odolnost
vůči opakovanému pádu apod.
P.695 Napojeny/kompatibilní s NIS a přenos dat do NIS (identifikace pacienta).
P.696 Podpora nabíjení baterie snímače při umístění v základně.
P.697 Ergonomické provedení vhodné pro intenzivní používání.
Tabulka 38: Čtečky čárových a QR kódů
3.3.32 Tablety pro personál
Požadované minimální parametry tabletů pro personál jsou:
# Požadavek
P.698 Dotykový tablet min. 10“
P.699 Vhodné do zdravotnického prostředí – vodě odolné, odolné proti znečištění, odolnost proti
čištění dezinfekčními prostředky používanými běžně ve zdravotnictví, odolnost
vůči opakovanému pádu apod.
P.700 Kompatibilní s NIS a aplikací NIS provozovanou v tabletu.
P.701 Přenos dat z tabletu do NIS prostřednictvím WiFi.
P.702 Podpora podepisování zdravotnické dokumentace v souladu s eIDAS.
Tabulka 39: Tablety pro personál
Strana 86 / 127
3.3.33 Integrace na další systémy
Požadavky na tuto část NIS ONP jsou následující:
# Požadavek
P.703 Systém musí podporovat základní datové standardy. Komunikační datové standardy HL7
(EU) a DASTA (ČR). HL7 bude primární komunikační standard, DASTA pouze v případech, kdy
systém nepodporuje jiný standard.
P.704 Součástí dodávky je realizace všech požadovaných a zde uvedených integrací. U vybraných
systémů Zadavatel zajistil rovné podmínky.
ERP
P.705 Systém musí podporovat komunikaci s centrálními sklady LP a SZM v ERP a zajistit návaznost
a aktualizaci dat vůči příručním (klinickým) skladům.
P.706 Musí umět načítat do spotřeby přímo ze skladu SZM nebo přes klinické (příruční) sklady
oddělení (realizace těchto klinických skladů je součástí tohoto projektu).
P.707 Musí být zajištěna synchronizace číselníku zboží SZM.
P.708 Určeno pro evidenci a vykázání nákladů na pacienta nebo na výkon (např. operační) jako
součást celkových nákladů.
P.709 Přenos dat z vyúčtování poskytnuté péče zdravotním pojišťovnám do ERP.
P.710 Přebírání subjektů (např. dodavatelů) z ERP do NIS.
P.711 Integrace na existující systém při zachování stávajícího způsobu integrace – viz kap. 6.5.2 –
Informační systémy, které budou dotčeny projektem.
Zadavatel nepředpokládá změny integračního rozhraní, případné změny integračního
rozhraní půjdou k tíži dodavatele.
Operační sály – foto/video
P.712 Systém musí podporovat komunikaci se systémy používanými na operačních sálech, čerpat
data z těchto systémů, vč. foto/video záznamů a umožnit je popisovat – viz kap. 6.5.2 –
Informační systémy, které budou dotčeny projektem.
P.713 V rámci plánování operací v NIS je požadovaná možnost zvolení požadavku na foto/video
z tohoto systému a následný automatický přenos dat o pacientovi do tohoto systému jako
vstupy pro provedení vyšetření.
P.714 Přenos dat o pacientovi do systému formou worklistu (DICOM, HL7) nebo DASTA.
P.715 Automatický přenos foto/video z tohoto systému do PACS.
P.716 Automatický přenos výsledků z tohoto systému do NIS a provázanost na foto/video v PACS.
Patologie
Strana 87 / 127
# Požadavek
P.717 Systém musí podporovat komunikaci s existujícím modulem Patologie – viz kap. 6.5.2 –
Informační systémy, které budou dotčeny projektem.
P.718 Sdílení dat o pacientech mezi NIS a modulem Patologie (registr pacientů).
P.719 Předávání žádanek z NIS.
P.720 Přebírání výsledků do NIS a ukládání do strukturované zdravotnické dokumentace.
Laboratorní přístroje
P.721 Systém musí umožnit napojení laboratorních přístrojů k modulu Laboratorní systém.
P.722 Podpora min. přístrojů uvedených v kap. 6.4.2 - Analyzátory.
P.723 Podpora standardních protokolů pro připojení přístrojů tak, aby bylo možné připojit i další
přístroje využívající standardizované protokoly.
Diagnostické přístroje, modality, klinické systémy
P.724 Systém musí podporovat komunikaci modalit se systémem pro práci s obrazovou informací
(PACS) přes standard HL7.
P.725 Podpora napojení diagnostických přístrojů prostřednictvím integračních rozhraní/způsobů
integrace uvedených v kap. 6.4.3 – Diagnostické přístroje.
P.726 Podpora napojení klinických přístrojů prostřednictvím integračních rozhraní/způsobů
integrace uvedených v kap. 6.4.4 – Klinické systémy.
Ostatní přístroje
P.727 Systém musí podporovat komunikaci se stroji na dávkování a balení léků pro pacienty dle
v dokumentaci předepsané medikace.
Stravovací systém
P.728 Objednávání diet pacienta.
P.729 Vedení evidence diet na pacienta.
P.730 Předávání nutričních hodnot jednotlivých jídel dle diet zpět do NIS.
P.731 Přehledy diet po odděleních / stanicích.
P.732 Komunikace se stravovacím provozem – předávání dat z klinického systému
• Počty strávníků
• Struktura jednotlivých diet
P.733 Respektování časů daných provozem stravovacího oddělení.
Strana 88 / 127
# Požadavek
Žádankový systém
P.734 Integrace NIS na Žádankový systém (externí žádanky) – princip je uveden v kapitole 6.5.2.1
– Žádankový systém (externí žádanky). Princip zůstane zachován.
P.735 Zpracování žádanek a vyšetření ve formátech DASTA v. 3, v. 4 a HL7.
Elektronická preskripce (předávání do lékárny)
P.736 Integrace na elektronickou preskripci a předávání preskripce do ústavní lékárny.
P.737 Další požadavky uvedené v předchozím textu vztahujících se k elektronické preskripci.
Distribuce zdravotnických dat
P.738 Systém musí podporovat ruční a automatické zasílání zpráv a výsledků praktickým lékařům
a specialistům.
P.739 Provázanost služby B2B kapitace na identifikační údaje (příjmení, jméno, IČP, adresa, aj.)
praktického lékaře/specialisty v NIS a možnosti odesílat zprávy a výsledky.
P.740 Dodržení principu distribuce dat uvedený v kap. 6.5.2.3 – Distribuce zdravotnických
dat/externí subjekty.
Komunikace se záchrannou službou (eHealth SčK)
P.741 Systém musí podporovat oboustrannou komunikaci se ZZS formou příjmu informace o
výjezdu a zasláním vyžádaných zdravotnických informací pacienta (prostřednictvím eHealth
SčK).
Popis systému je uveden v kap. 6.5.2.12 – eHealth SčK (Krajský komunikační systém pro
výměnu zdravotnické dokumentace).
Komunikace na externí zdravotnická zařízení (eHealth SčK)
P.742 Systém musí podporovat výměnu dat s ostatními zdravotnickými zařízeními a dalšími
externími systémy dle budoucích požadavků státní strategie eHealth.
P.743 Systém musí využít standardy, které budou ze strany státního eHealth určeny pro výměnu
dat, výměna bude probíhat prostřednictvím eHealth SčK.
Popis systému je uveden v kap. 6.5.2.12 – eHealth SčK (Krajský komunikační systém pro
výměnu zdravotnické dokumentace).
Zdravotní pojišťovny
P.744 Systém musí podporovat komunikaci s pojišťovnami v rozsahu potřebném pro správné a
úplné vykázání práce pojišťovnám, např. export/import k-dávek, přístup na portály
pojišťoven, komunikaci s B2B službami aj.
Strana 89 / 127
# Požadavek
Elektronická spisová služba
P.745 Systém musí zajistit komunikaci a možnost ukládání dat z elektronické spisové služby
vztahující se k poskytované péči do důvěryhodného elektronického archívu v NIS.
P.746 Možnost posílat zprávy (výsledky, zprávy apod.) na vybrané subjekty z NIS přes spisovou
službu.
P.747 Identifikaci subjektů pro potřeby odesílání čerpat z ERP.
Komunikace na UZIS
P.748 Systém musí zajistit maximálně automatizovanou komunikaci a předávání dat na UZIS, resp.
do registrů NZIS, minimálně v rozsahu požadavků daných legislativou, případně zajistit
export dat pro UZIS.
P.749 Konfigurace a nastavení komunikace musí být realizovatelná zaškolenými pracovníky
nemocnice.
Komunikace na SUKL
P.750 Systém musí zajistit komunikaci na SUKL v rozsahu komunikace nutné pro práci s eReceptem.
P.751 Dále budou využívány následující IS, pro které je vyžadována integrace:
• RLPO – registr pro léčebné přípravky s omezením
• CDNU – centrální databáze nežádoucích účinků
• CÚER – centrální úložiště elektronických receptů
OSSZ (e*neschopenka)
P.752 Systém musí zajistit komunikaci na OSSZ v rozsahu komunikace nutné pro práci s
eNeschopenkou.
Lékárna
P.753 Informační systém veřejných lékáren provozovaných v rámci nemocnice ONP.
Součástí projektu je integrace NIS ONP na tento IS prostřednictvím elektronické preskripce.
P.754 Výdej léků na identifikovaného pacienta z ústavní lékárny.
P.755 Výdej léků do příručních skladů.
P.756 Záchyt receptů v lékárně.
P.757 Další požadavky uvedené v předchozím textu vyžadujících výměnu dat s lékárnou.
Personalistika
P.758 Přebírání údajů o zaměstnancích ONP pro potřeby řízení přístupů a oprávnění pracovníků.
Součástí projektu je integrace NIS ONP na Personalistiku.
Strana 90 / 127
# Požadavek
P.759 Přebírání min. následujících údajů: osobní číslo, identifikace, jméno, příjmení, funkce,
organizační struktura, nákladové středisko, začátek/konec pracovního poměru. Rozsah
dalších údajů bude upřesněn v rámci implementační analýzy.
P.760 Automatické ukončení přístupu do NIS ke dni ukončení pracovního poměru.
P.761 Aktualizace dat v NIS min. 1x denně, případně na vyžádání správcem.
IdM
P.762 Řízení přístupů (autentizace) uživatelů NIS ONP na základě oprávnění definovaných v IdM a
propagovaných do adresářové databáze MS AD.
Součástí projektu je integrace NIS ONP na AD ONP.
NIA
P.763 Národní bod pro identifikaci a autentizaci nebo též Národní identitní autorita zajišťující
identifikační a autentizační služby garantované státem.
Pokud tento systém bude během realizace dodávky projektu, musí zajistit napojení na NIA.
V případě, že bude zajištěn v období udržitelnosti, bude integrace realizována v rámci
servisní smlouvy.
eHealth SčK
P.764 Systém výměny zdravotnické dokumentace mezi poskytovateli zdravotních služeb na území
Středočeského kraje realizovaný v rámci IOP, výzvy č. 23.
Popis systému je uveden v kap.6.5.2.12 – eHealth SčK (Krajský komunikační systém pro
výměnu zdravotnické dokumentace).
Prostřednictvím tohoto IS bude NIS ONP napojen na NIX ZD, eMeDocS, eH NCP a na IS dalších
ZZ pro zajištění výměny zdravotnické dokumentace.
Požadavky na integraci jsou uvedeny v kap. 3.3.25 – Napojení NIS ONP na eHealth systém
kraje.
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í.
Pokud nebude integrace provedena v rámci realizace projektu a připravenost těchto IS bude
zajištěna během udržitelnosti, zajistí příjemce realizaci uvedených integrací v rámci
udržitelnosti projektu.
IS ZR
P.765 Bude využito pro získání AIFO z ROB.*
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í.
Strana 91 / 127
# Požadavek
Pokud nebude integrace provedena v rámci realizace projektu a připravenost těchto IS bude
zajištěna během udržitelnosti, zajistí příjemce realizaci uvedených integrací v rámci
udržitelnosti projektu.
Registry MZ
P.766 Ministerstvo zdravotnictví připravuje Informační datové resortní rozhraní (IDRR) pro přístup
ke zdravotnickým registrům.
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í.
Pokud nebude integrace provedena v rámci realizace projektu a připravenost těchto IS bude
zajištěna během udržitelnosti, zajistí příjemce realizaci uvedených integrací v rámci
udržitelnosti projektu.
Externí certifikační autorita
P.767 Součástí projektu je integrace na externí certifikační autoritu pro vydávání certifikátů,
agendy související s vydáváním certifikátů (Registrační místo CA) a se správou a
obnovováním certifikátů apod. a přenos do RA, resp. NIS, kde budou certifikáty využívány.
Tabulka 40: Integrace na další systémy
3.3.34 Bezpečnostní požadavky
V následující tabulce je seznam požadavků na tuto část dodávky:
# Požadavek
P.768 Řešení bude pracovat s identifikací pacienta v souladu s legislativou a prováděcími předpisy
platnými ke dni dokončení realizace řešení, vč. zajištění připravenosti na postupné opuštění
rodných čísel jako jediného a výměnného identifikátoru a zavedení bezvýznamových
identifikátorů během doby udržitelnosti, pokud nebude možné tento přechod realizovat
během realizace projektu.
P.769 Systém bude chránit osobní údaje pacientů a bude v souladu s Nařízením Evropského
parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob (GDPR)
v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů.
P.770 Systém bude v souladu se zákonem č. 181/2014 Sb., o kybernetické bezpečnosti, v platném
znění a navazujícími právními předpisy (zákony a vyhláškami, viz kap. 6.2 - Legislativa).
P.771 Uživatelé systému jsou zavedeni v IdM (Active Directory) Objednatele (výchozí stav). Přístup
do systému (zařazení do relevantní role) je poskytován s využitím aplikace pro správu
přístupů.
Strana 92 / 127
# Požadavek
Všichni uživatelé 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 potřeby uchování
historie.
P.772 Identifikace, autentizace a autorizace bude řešena pomocí interních mechanismů
informačního systému spolu s napojením na služby IdM, které jsou již nyní využívány.
P.773 Autorizace: Poskytnutí přístupu autentizovaného uživatele k aktivu systému (data, aplikace),
odpovídající pracovnímu zařazení uživatele a přidělené roli (rolím) v systému.
Systém umožní řídit přístupová oprávnění jednotlivých subjektů jen k údajům, ke kterým mají
a mohou mít přístup.
Systém umožní hierarchické 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í.
P.774 Ří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ů – zadáním počátečního a koncového
data přidělení role a umožnění přístupu jen v tomto intervalu.
3. Zabránění vstupu neautorizovaného subjektu do systému – zamezení možnosti přístupu
neoprávněného subjektu.
P.775 Zajištění konfiguračního managementu a správy systému s eliminací rizika ovlivnění chodu
systému změnou aplikací 3. stran (unifikace konfigurací pracovních stanic, tabletů, řízený
patch management).
P.776 Dostupnost:
1. Zajištění dostupnosti systému jako celku (společné služby – servery, databáze,
aplikační servery) v režimu 24x7x365 s maximální celkovou dobou neplánovaného
výpadku podle požadavků v servisní smlouvě.
2. Odpovídající HW a SW architektura řešení pro zajištění této dostupnosti.
3. Dekompozice SLA na jednotlivá aktiva podle kategorizace jejich důležitosti/dopadu
na dostupnost systému
P.777 Výměna dat:
1. Zajištění šifrované komunikace koncových stanic v odděleném síťovém prostředí
2. Zajištění výhradní komunikace mobilního prostředku pro zadávání dat s datovým
centrem prostřednictvím broadbandovým 4G připojením přes privátní síť APN (eliminace
jiného druhu datového připojení – Wi-Fi, BT apod.)
P.778 Dodání a zavedení aplikace pro správce přístupů s následujícími funkcemi:
1. Import uživatelů z AD
Strana 93 / 127
# Požadavek
2. Zařadit/změnit uživatele do konkrétní role, případně více rolí
3. Povolit / zablokovat přístup danému uživateli do systému
4. Zobrazit konec platnosti certifikátů
5. Zobrazení data/času zařazení uživatele do role
6. Zobrazení data/času posledního přihlášení uživatele
7. Třídění/filtrování podle všech atributů
8. Reporty do formátu PDF/A
P.779 Dodání a zavedení aplikace pro správce certifikátů s následujícími funkcemi:
1. Import uživatelů z AD,
2. Přiřadit/odebrat konkrétnímu uživateli certifikáty (komerční i kvalifikovaný) - veřejné
části těchto certifikátů,
3. Zobrazit konec platnosti certifikátů,
4. Třídění/filtrování podle všech atributů,
5. Reporty do formátu PDF/A
Zákaznický portál pro správu certifikátů je samostatný od této aplikace.
P.780 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 mobilních
zařízeních. Umožnit administrátorsky vzdáleně smazat data z tabletu (např.
ztráta/krádež/servis tabletu).
P.781 Automatická aktualizace seznamu uživatelů, certifikátů a rolí mezi jednotlivými částmi
systému, případně integrovanými systémy min. 1x-2x denně.
P.782 Evidence přístupů všech uživatelů do systému (logování) včetně časových údajů a identifikace
místa přístupu (zařízení).
P.783 Evidence veškerých datových změn na úrovni DB položky (položky datasetu). Atributy: kdo,
kdy, původní hodnota, nová hodnota.
P.784 NIS ONP bude obsahovat nezávislý auditní systém, který bude zajišťovat veškeré potřebné
auditní služby.
P.785 Veškeré přístupy k datům a aktivita uživatelů v NIS ONP budou logovány tak, aby byly zřejmé
přístupy k jednotlivým údajům a zpětná kontrola těchto údajů. V systému bude evidována
jednoznačná identifikace kdo, kdy provedl zápis do systému nebo provedl náhled
do dokumentace. Tyto logy budou zabezpečeny proti změnám.
P.786 Veškerá externí komunikace (mimo LAN) bude zajišťována prostřednictvím zabezpečených
(šifrovaných kanálů). V případech, kdy to bude možné, bude komunikace probíhat přes KIVS
nebo přes krajskou datovou síť.
P.787 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
Strana 94 / 127
# Požadavek
anti-X řešení. Standardní ochrana serverů pomocí firewallů/UTM. Přístup do prostor s
fyzickými servery bude řízen a umožněn jen oprávněným osobám.
Tabulka 41: Bezpečnostní požadavky
3.3.35 Implementační a provozní požadavky
V následující tabulce je seznam požadavků na tuto část dodávky:
# Požadavek
P.788 Systém musí být připraven na provoz 24x7x365 (non-stop).
P.789 Instalace do prostředí objednatele na OS Windows (preferovaná platforma – viz kap. 6.5.5)
nebo Linux. Limitní podmínky pro dostupný výkon a max. dostupnou kapacitu jsou uvedeny
v kapitole 6.5.4 - Datová centra, HW infrastruktura a technologie.
P.790 Dodávka OS na servery, včetně instalace do prostředí objednatele, vč. potřebných licencí.
P.791 Dodávka DB SW, včetně instalace a konfigurace pro dodávané řešení, vč. potřebných licencí.
DB SW musí umožňovat min. readonly přístup pro dotazování/analýzy/exporty dat i mimo
aplikaci běžně dostupnými nástroji (nástroje musí být zdarma) nebo zhotovitel musí dodat
příslušený SW jako součást DB SW pro tento přístup k DB.
P.792 Instalace OS Windows a zprovoznění NIS na terminálových serverech zákazníka (4 servery).
P.793 Všechny součástí systému (OS, DB, IS, klientské aplikace) musí logovat svou činnost do logů
s možností nastavit úroveň logování pro potřeby diagnostiky.
P.794 Zálohování – systém (OS) a DB musí být schopny a připraveny na zálohování přes zálohovací
systém objednatele, tj. pro OS a DB musí existovat agent pro zálohovací systém objednatele.
Informace k zálohovacímu systému objednatele jsou uvedeny v kapitole 6.5.4 - Datová centra,
HW infrastruktura a technologie.
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í.
P.795 Zajištění administrátorských aplikací, konzolí pro všechny součástí systému (OS, DB, IS, …) pro
zajištění konfiguračního managementu systému anebo jeho součástí, zajištění konfigurace na
jednom místě s případnou vnitřní distribucí nastavení do jednotlivých částí systému.
P.796 Dohled – systém musí předávat informace o svém stavu (stavu služeb apod.) na žádosti SNMP
GET. Zhotovitel poskytne parametry, podmínky a součinnost při nastavení dohledu dodaného
řešení.
P.797 Architektura řešení celého systému musí korespondovat s požadavky na jeho dostupnost,
uvedenými v servisní smlouvě.
Strana 95 / 127
# Požadavek
P.798 Synchronizace času všech zařízení s time serverem nebo zprostředkovaně přes centrální
systém.
Tabulka 42: Provozní požadavky
3.4 Požadavky na služby
3.4.1 Realizace předmětu plnění
Součástí předmětu plnění je zajištění služeb souvisejících s realizací předmětu plnění minimálně
v následujícím rozsahu:
1) Objednatel požaduje před zahájením implementačních prací zpracování Implementační analýzy
včetně návrhu řešení (konkretizace implementačního postupu, přesné konfigurace
a instalačního a montážního návrhu řešení z nabídky), která bude zahrnovat informace pro
všechny aktivity potřebné pro řádné zajištění implementace předmětu plnění. Implementační
analýza včetně návrhu řešení musí být před zahájením prací schválena objednatelem.
Implementační analýza včetně návrhu řešení musí zohlednit podmínky stávajícího stavu,
požadavky cílového stavu a musí obsahovat minimálně tyto části:
a) Implementační analýza – zjištění týkající se prostředí objednatele, bude obsahovat alespoň
následující:
i) Seznam technologií objednatele, které mají vliv/dopad na dodávku
ii) Identifikace zdrojů dat využitých pro dodávku
iii) Evaluace bezpečnosti systému a rizikových faktorů
iv) Implementační upřesnění specifikace požadavků
v) Výstupy z analýzy okolí – sběr a analýza informací vztahujících se k dodávce (např.
součinnosti apod.)
b) Detailní popis cílového stavu (instalační a montážní upřesnění návrhu řešení z nabídky)
Popis bude obsahovat alespoň:
i) Rozpracování návrhu řešení z nabídky zhotovitele z pohledu instalací a montáže dle
informací z implementační analýzy
ii) Upřesnění rozhraní pro integraci na IS a technologie třetích stran (v případě nutnosti)
iii) Způsob zajištění projektového řízení na straně zhotovitele pro realizaci předmětu plnění
(harmonogram, projektový tým, koordinační mechanismy apod.)
iv) Detailní návrh a popis postupu implementace, instalace a montáže předmětu plnění
v) Detailní popis zajištění bezpečnosti systému a informací
Detailní harmonogram projektu včetně uvedení kritických milníků. Kritické milníky jsou
termíny dosažení určitých fází projektu, které jsou pro naplnění cílů projektu klíčové.
Kritické milníky budou obsahovat minimálně aktivity vedené v kapitole 4 -
Harmonogram, s uvedením konkrétních termínů, zhotovitel vhodným způsobem může
rozšířit kritické milníky o další aktivity, které mohou být pro projekt klíčové.
vi) Detailní popis navrhovaného seznámení s funkcionalitami, obsluhou dodávaného
zařízení a budoucím provozem
Strana 96 / 127
2) Zajištění projektového vedení realizace předmětu plnění ze strany zhotovitele a jeho
případných subdodavatelů.
3) Vývoj, implementace a nastavení informačních a komunikačních technologií odpovídající
schválenému návrhu řešení uvedenému v Implementační analýze a příprava pro ověření
ze strany objednatele, alespoň v následujícím rozsahu:
a) Vývoj na straně zhotovitele – vývoj jednotlivých systémů, úpravy existujících produktů, jejich
parametrizace a nastavení, vývoj a ověřování integračních rozhraní, součinnost se třetími
stranami v souvisejících oblastech.
b) Instalace a implementace do prostředí objednatele v testovacím režimu.
c) Interní ověření na straně zhotovitele a příprava podkladů pro ověření na straně objednatele
(dokumentace, organizace testování a další).
d) Příprava a naplnění základních dat – z integračních úloh, číselníky, uživatelé a další.
Provedením těchto činností bude zajištěna připravenost pro ověření ze strany objednatele.
4) Dodávka předmětu plnění. Součástí dodávky musí být instalace, upgrade a sestavení předmětu
zakázky včetně:
a) Instalace, upgrade a zahoření HW na místě,
b) Instalace a nastavení HW a SW budou provedeny kvalifikovanými osobami pro dané typy
zařízení
c) Nastavení HW a aplikací
5) Zajištění instalace všech součástí dodávky v určených lokalitách a prostorách objednatele
6) Zajištění instalace a připojení k zařízením a technickým prostředkům zajištěným objednatelem.
7) Realizace pilotního provozu k ověření funkčnosti systému na menším obejmu dat, s menším
počtem uživatelů a na menším počtu zařízení.
8) Převedení systémů do zkušebního provozu a plná podpora uživatelů v rámci zkušebního
provozu včetně technické podpory. V této etapě budou realizována požadovaná seznámení
s funkcionalitami, obsluhou dodávaného zařízení a budoucím provozem.
9) Zpracování dokumentace skutečného provedení, systémové a provozní dokumentace –
součástí předmětu plnění je zajištění systémové a provozní dokumentace související s realizací
předmětu plnění minimálně v následujícím rozsahu:
Název Popis
Uživatelská Bude popisovat konkrétní funkčnost z pohledu uživatele tak, aby
dokumentace 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.
Strana 97 / 127
Název Popis
Dokumentace Obsahuje popis informačního systému (rozhraní a služby) včetně
skutečného provedení a popisu správy informačního systému, definování uživatelů, jejich
systémová/provozní oprávnění a povinností a detailní popis údržby systému.
dokumentace
Bezpečnostní Účelem bezpečnostní dokumentace je definovat závazná pravidla
dokumentace 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.)
Disaster & Recovery Plan Plán řešení situací v případě výpadků a obnovy funkčnosti
systému.
Součástí je plán a způsob provádění zálohy a případného způsobu
obnovy a obnovy funkčnosti i v případě jiných technických
výpadků.
Dokument bude vytvářen v součinnosti s objednatelem.
Projektová dokumentace Smluvní dokumentace, harmonogram realizace projektu, analýzy
a prováděcí projekty, zápisy z jednání, protokoly (předávací,
akceptační)
Tabulka 43: Dokumentace – požadavky na zpracování
Dokumentace bude dodána v relevantním rozsahu na všechna místa plnění projektu.
Dokumentace bude v souladu se zákonem č. 365/2000 Sb. o informačních systémech veřejné
správy a prováděcích právních předpisů, v platném znění.
Dokumenty budou zpracovávány v následujících programech elektronicky a uloženy
v následujících formátech:
• MS Office 2010 (MS Word 2010, MS Excel 2010, MS PowerPoint 2010)
• MS Project 2010
• WinZip (formát .zip)
• Portable Document Format (formát .pdf).
Preferovaná forma předávaných dokumentů, které nebudou vyžadovat podpisy konkrétních
osob je elektronicky a to na elektronických nosičích (CD, DVD, flash disk, atp.). K předávání
a k archivaci souborů se používají média s možností pouze zápisu, nikoliv přepisovatelná.
Veškerá dokumentace bude podléhat schvalování (akceptaci) při převzetí ze strany objednatele.
Strana 98 / 127
Veškerá dokumentace musí být zhotovena výhradně v českém jazyce, bude dodána ve 2x kopiích
v elektronické formě ve standartních formátech (MS Office a PDF) používaných objednatelem
na datovém nosiči a 1x kopii v papírové formě.
10) Provedení akceptačních testů. Zhotovitel je povinen kompletně připravit podklady pro
akceptaci dodaného řešení. Součástí akceptace bude akceptační protokol a kompletní předávací
dokumentace.
11) Uvedení systému do produkčního provozu, zajištění potřebných nastavení a přístupů pro
všechny pracovníky objednatele, minimalizace dopadů na provoz objednatele při přechodu
a zvýšená podpora bezprostředně po přechodu do produkčního provozu.
12) Zhotovitel dle svého uvážení doplní v nabídce další služby, které jsou dle jeho názoru nezbytné
pro úspěšnou realizaci zakázky.
13) Veškeré náklady na zajištění služeb souvisejících s realizací předmětu plnění musí být zahrnuty
v ceně odpovídající části předmětu dodávky.
3.4.2 Seznámení s funkcionalitami, obsluhou dodávaného systému
V této kapitole jsou uvedeny požadavky na seznámení s funkcionalitami, obsluhou dodávaného zařízení
a jeho budoucím provozem:
1) Zhotovitel proškolí pracovníky objednatele se všemi typy dodaných zařízení a aplikací a
problematikou jejich užití, provozu a obsluhy. Zhotovitel se zavazuje poskytnout informace
minimálně k následujícím tématům v dostatečném detailu pro porozumění činnosti zařízení a
způsobu provozu:
a) Základní produktové seznámení s jednotlivými dílčími technologickými celky.
b) Celkové schéma součinnosti jednotlivých zařízení a jejich návaznosti.
c) Obsluha jednotlivých dílčích modulů, aplikací a technologických celků
d) Použitá nastavení zařízení, detailnější rozbor použitých konfigurací.
e) Základní kroky správy, diagnostiky a elementární postupy pro řešení problémů.
2) Poskytnuté informace zajistí seznámení pracovníků objednatele se všemi podstatnými částmi
dodávky v rozsahu potřebném pro obsluhu, provoz, údržbu a identifikaci nestandartních stavů
systému a jejich příčin.
3) Konkrétní požadavky na seznámení jednotlivých skupin uživatelů je následující:
Pracovníci Počet Rozsah
Tabulka 44: Seznámení uživatelů s funkcionalitami, obsluhou dodávaného systému
4) Vše uvedené bude probíhat v prostorách objednatele s využitím vybavení dodaného v rámci
této veřejné zakázky, případně zajištěné ze strany objednatele.
5) Konkrétní termíny určí objednatel dle postupu v rámci realizace projektu a dostupnosti
zainteresovaných osob.
Strana 99 / 127
Veškeré náklady na zajištění těchto činností musí být zahrnuty v ceně odpovídající části předmětu
dodávky.
3.5 Záruky
V této kapitole jsou uvedeny požadavky na záruky dodávky jako celku, případně specificky dílčích částí
dodávky.
Objednatel požaduje záruku na veškeré dodané technologie včetně nezbytných provozních a servisních
služeb v délce trvání minimálně:
a) 60 měsíců na informační systém(y), aplikace a služby spojené s realizací projektu,
b) 36 měsíců – u HW infrastruktury a systémového SW,
c) 12 měsíců na spotřební materiál, případně drobné vybavení podléhající rychlému opotřebení.
Případný spotřební materiál musí být explicitně označen v nabídce a smlouvě a musí být
prokázáno, že splňuje tento charakter.
Záruka začíná běžet od okamžiku předání do ostrého (produkčního) provozu. Veškeré opravy po dobu
záruky budou bez dalších nákladů pro provozovatele (objednatele). Veškeré komponenty, náhradní díly
a práce budou poskytnuty bezplatně v rámci záruky. Zhotovitel ve své nabídce výslovně uvede všechny
podmínky záruk.
a) Po dobu záruky na části dodávky musí zhotovitel nebo výrobce všech zařízení garantovat běžnou
dostupnost náhradních komponentů a dostupnost servisu.
b) Součástí záruky je i shoda dodávaných systémů s platnou legislativou.
c) Max. doba na odstranění vady díla je 30 dnů od prokazatelného oznámení dodavateli.
d) Zhotovitel uvede provozní služby požadovaného předmětu plnění veřejné zakázky včetně
parametrů, které budou předmětem dodávek v rámci záruky systému a v rámci poskytování
servisních služeb.
Poskytovatel zajistí HelpDesk pro hlášení vad.
Strana 100 / 127
4 Harmonogram
Následující tabulka obsahuje požadovaný časový harmonogram realizace dodávky (T ~ datum účinnosti
smlouvy o dílo):
# Fáze Doba trvání Doplňující informace
od zahájení
Tabulka 45: Harmonogram
Doplňující informace:
• Pod pojmem „den“ je míněn kalendářní den.
• Zhotovitel má možnost definovat kratší termíny plnění (v rámci dodávky)
Strana 101 / 127
5 Místa plnění
Realizace předmětu plnění bude probíhat v následujících místech plnění:
Místo Adresa Předmět realizace
Areál I, sídlo Gen. R. Tesaříka 80, Dodávka a umístění modernizovaných informačních
žadatele 261 01, Příbram I systémů a technologií, související vybavení.
Využívání vybavení pro potřeby výkonu činností
příjemce.
Areál II Podbrdská 269, 261 Využívání vybavení pro potřeby výkonu činností
95, Příbram V – příjemce, tj. příjemce zajistí dostupnost technologií i
Zdaboř v tomto místě.
Tabulka 46: Místa plnění
Strana 102 / 127
6 Výchozí stav
V této kapitole je uveden výchozí stav a výchozí podmínky pro dodávku předmětu plnění.
6.1 Zadavatel: Oblastní nemocnice Příbram, a.s.
Oblastní nemocnice Příbram, a.s. (ONP) je nestátním zdravotnickým zařízením založeným Středočeským
krajem, který je jediným akcionářem. Oblastní nemocnice Příbram, a.s. je páteřní spádové zdravotnické
zařízení Středočeského kraje, poskytující zdravotní péči, lékárenskou péči a dopravní zdravotní službu
na spádovém území.
ONP poskytuje kvalitní komplexní zdravotní péči nejen pacientům na spádovém území Příbramska, ale
také dalším pacientům z jiných regionů, kteří o ně projevují zájem. Důraz je kladen na kvalitu
poskytované zdravotní péče a bezpečí pacientů. Kvalita zdravotní péče se zvyšuje např. vybavením
moderními technologiemi, a to jak zdravotnickými, tak i jinými (např. informačními).
Mimo poskytování kvalitní zdravotní péče je prioritou produktivita a efektivita činností, které je třeba
podpořit moderními nástroji, a to i v oblasti informačních a komunikačních technologií, jak pro personál,
tak pro pacienty.
6.2 Legislativa
Na požadované řešení a provoz zadavatele se vztahuje legislativa uvedená v této kapitole.
Řešení musí být v souladu s platnou legislativou ke dni uvedení NIS ONP do provozu.
6.2.1 Ochrana osobních údajů
1. Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých dalších zákonů, ve znění
pozdějších předpisů
2. Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně
fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o
zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů)
6.2.2 Legislativa specifická pro zdravotnická zařízení
3. Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, ve znění
pozdějších předpisů
4. Zákon č. 378/2007 Sb. o léčivech, ve znění pozdějších předpisů
5. 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ů
6. 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í
7. Vyhláška č. 62/2015 Sb., o provedení některých ustanovení zákona o zdravotnických
prostředcích, v platném znění
8. Zákon č. 48/1997 Sb., o veřejném zdravotním pojištění, v platném znění
9. Vyhláška č. 98/2012 Sb., o zdravotnické dokumentaci, v platném znění
10. Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního
systému, v platném znění
Strana 103 / 127
6.2.3 Bezpečnost informací
11. Zákon č. 181/2014 Sb., o kybernetické bezpečnosti, v platném znění
12. Vyhláška č. 316/2014 SB., o kybernetické bezpečnosti, v platném znění
6.2.4 Ostatní
13. Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce
14. Zákon č. 499/2008Sb., o archivnictví a spisové službě, v platném znění
6.2.5 Připravovaná legislativa:
1. Legislativa specifická pro zdravotnická zařízení
a. Návrh zákona, kterým se mění zákon č. 378/2007 Sb., o léčivech a o změnách některých
souvisejících zákonů (zákon o léčivech), ve znění pozdějších předpisů
b. Návrh zákona, kterým se mění zákon č. 95/2004 Sb., o podmínkách získávání a uznávání
odborné způsobilosti a specializované způsobilosti k výkonu zdravotnického povolání
lékaře, zubního lékaře a farmaceuta, ve znění pozdějších předpisů
c. Návrh zákona, kterým se mění zákon č. 592/1992 Sb., o pojistném na veřejné zdravotní
pojištění, ve znění pozdějších předpisů (valorizace platby státu za státní pojištěnce)
d. Návrh zákona, kterým se mění zákon č. 96/2004 Sb., o podmínkách získávání a uznávání
způsobilosti k výkonu nelékařských zdravotnických povolání a k výkonu činností
souvisejících s poskytováním zdravotní péče a o změně některých souvisejících zákonů
(zákon o nelékařských zdravotnických povoláních, ve znění pozdějších předpisů
e. Návrh zákona, kterým se mění zákon č. 285/2002 Sb., o darování, odběrech a
transplantacích tkání a orgánů, ve znění pozdějších předpisů
f. Návrh zákona, kterým se mění zákon č. 373/2011 Sb., o specifických zdravotních
službách, ve znění pozdějších předpisů
g. Návrh zákona, kterým se mění zákon č. 592/1992 Sb., o pojistném na veřejné zdravotní
pojištění, ve znění pozdějších předpisů (valorizace platby státu za státní pojištěnce)
h. Návrh vyhlášky, kterou se mění vyhláška č. 306/2012 Sb., o podmínkách předcházení
vzniku a šíření infekčních onemocnění a o hygienických požadavcích na provoz
zdravotnických zařízení a ústavů sociální péče, ve znění pozdějších předpisů
i. Návrh vyhlášky, kterou se mění vyhláška č. 102/2012 Sb., o hodnocení kvality a bezpečí
lůžkové zdravotní péče, ve znění pozdějších předpisů
j. Návrh vyhlášky, kterou se mění vyhláška č. 187/2009 Sb., o minimálních požadavcích na
studijní programy všeobecné lékařství, zubní lékařství, farmacie a na vzdělávací program
všeobecné praktické lékařství, ve znění pozdějších předpisů
k. Návrh vyhlášky, kterou se mění vyhláška č. 70/2012 Sb., o preventivních prohlídkách, ve
znění pozdějších předpisů
l. Návrh vyhlášky, kterou se mění vyhláška č. 306/2012 Sb., o podmínkách předcházení
vzniku a šíření infekčních onemocnění a o hygienických požadavcích na provoz
zdravotnických zařízení a ústavů sociální péče, ve znění pozdějších předpisů
Strana 104 / 127
6.2.6 Dokumentace projektu
Dokumentace bude v souladu se Zákonem č. 365/2000 Sb., o informačních systémech veřejné správy,
včetně prováděcích právních předpisů v platném znění.
6.3 Počty a množství zpracovávaných dat
6.3.1 Množství zpracovávaných dat Množství / kalendářní rok
V této kapitole je uvedeno množství zpracovávaných dat:
Oblast
Hospitalizační zprávy 100 tis.
Ambulantní zprávy 350 tis.
Laboratorní výsledky 400 tis.
Obrazová dokumentace ve formátu DICOM 100 tis.
Primariáty
25
Tabulka 47: Množství zpracovávaných dat
6.3.2 Uživatelé
Systém musí umožnit využívání následujícími minimální objemy uživatelů:
Kategorie Celkový počet Počet současně
pracujících
Tabulka 48: Uživatelé
V případě rostoucí provozní potřeby musí být možno počet uživatelů navýšit i za cenu rozšíření HW a SW
infrastruktury.
6.3.3 Organizační struktura, primariáty a nákladová střediska
V následující tabulce je organizační struktura, primariáty a nákladová střediska:
Primariát Nákladové Název IČP Odbornost
zkratka středisko
Strana 105 / 127
Primariát Nákladové Název IČP Odbornost
zkratka středisko
Strana 106 / 127
Primariát Nákladové Název IČP Odbornost
zkratka středisko
Strana 107 / 127
Primariát Nákladové Název IČP Odbornost
zkratka středisko
Strana 108 / 127
Primariát Nákladové Název IČP Odbornost
zkratka středisko
Strana 109 / 127
Primariát Nákladové Název IČP Odbornost
zkratka středisko
Tabulka 49: Organizační struktura, primariáty a nákladová střediska
Strana 110 / 127
6.4 Specifické údaje vybraných klinik
V této kapitole jsou uvedeny specifické údaje vybraných klinik.
6.4.1 Rehabilitace
V rámci rehabilitací jsou provozovány následující pracoviště:
Pracoviště Popis Režim práce/objednávání
Tabulka 50: Specifické údaje vybraných klinik: Rehabilitace
6.4.2 Analyzátory
V následující tabulce jsou uvedeny analyzátory, které v současnosti ONP využívá:
Název Typ Název umístění Výrobce
Strana 111 / 127
Název Typ Název umístění Výrobce
Strana 112 / 127
Název Typ Název umístění Výrobce
Tabulka 51: Analyzátory
6.4.3 Diagnostické přístroje
V následující tabulce jsou uvedeny kategorie diagnostických přístrojů relevantních pro dodávku:
Kategorie Příklady Rozhraní Přenos do NIS/PACS
Tabulka 52: Diagnostické přístroje
Strana 113 / 127
6.4.4 Klinické systémy
Subsystémy, které generují klinická data na různé úrovni jsou uvedeny v následující tabulce:
Kategorie Příklady Rozhraní Přenos do NIS/PACS
Tabulka 53: Klinické systémy
6.5 Informační systémy, infrastruktura a technologie
V této kapitole jsou uvedeny informační systémy, infrastruktura a technologie, které objednatel využívá
a případně je poskytne zhotoviteli v rámci dodávky předmětu plnění.
6.5.1 Současný stav informačních a komunikačních technologií
V této kapitole je uveden současný stav informačních a komunikačních technologií ONP:
Technologie Stav
Nemocniční ONP provozuje nemocniční informační systém jako soubor více modulů, které
informační systém jsou vzájemně provázány a tvoří jeden celek. Systém je stabilizovaný a
(NIS) udržovaný, nicméně vyžaduje modernizaci a rozvoj.
Jednotlivé části IS jsou různého stáří, od různých dodavatelů, nicméně většina
z nich je za horizontem životnosti a technologie, na kterých jsou části
vybudovány, jsou zastaralé. Nemocniční informační systém je technologicky
zastaralý, nyní probíhají jen nutné legislativní úpravy, dodavatel již tento
systém nerozvíjí.
Tento stav s sebou nese základní rizika a problémy, a to ohledně dalšího
rozvoje tohoto NIS, protože řadu nových funkcionalit již na zastaralých
technologiích buď nelze realizovat, nebo je nelze dlouhodobě udržet, a to i
z důvodu, že dodavatelé částí NISu již tyto služby nechtějí poskytovat.
V rámci NIS chybí potřebná struktura zdravotních záznamů a možnost
elektronického podepisování dokumentů (zavedení kvalifikovaného el.
podpisu) a dále chybí podpora některých procesů jako např. elektronická
Strana 114 / 127
Technologie Stav
vizita, elektronická preskripce (napojení na e-recept), možnosti popisování
obrazových dat i mimo ONP (např. pro potřeby odborných konzultací od
odborníků mimo ONP), elektronické objednávání pacientů na vyšetření,
plánování léčebných procedur a napojení na systémy výměny zdravotnické
dokumentace s jinými zařízeními (eHealth), vedení ošetřovatelské
dokumentace, evidence nežádoucích událostí, evidence použitých přístrojů v
rámci vyšetření a sběr dat z těchto přístrojů, napojení na elektronickou
zdravotnickou dokumentaci a její zpracování v koncových zařízeních (v
mobilních i stacionárních), vedení strukturované ordinace medikace, včetně
příručních skladů a výdeje léků na identifikovaného pacienta, podpora řízení
operačních sálů, funkce centrální pojišťovny a jejich napojení na portály
zdravotních pojišťoven a statistických hlášení pro online vykazování, odesílání
dat pro OSSZ (e*neschopenka), identifikace pacientů pomocí čárového kódu,
vytváření elektronických žádanek do laboratoří, podpora manažerského řízení
apod.
Stav jednotlivých součástí (modulů) je uveden v tabulce v kap. 3.3.1 –
Koncept/architektura požadovaného řešení.
Datové centrum a ONP disponuje datovým centrem, kde provozuje využívané technologie. Řada
infrastruktura HW a SW infrastruktury je taktéž zastaralá, protože odpovídá době dodávek,
resp. posledním modernizacím příslušných částí NIS.
Současné technologie v DC není možné využít pro modernizovaný NIS ani
nově zvažované funkcionality, protože jsou již za svou životností, nebo jejich
životnost skončí mnohem dříve, než by byla udržitelnost modernizovaného a
inovovaného NIS.
Mobilní zařízení ONP nevyužívá žádná koncová HW zařízení pro využití s NIS, resp. jeho funkcí.
(koncová HW Personál musí využívat stacionární počítače na svých pracovištích s přístupem
zařízení) k NISu.
Zdravotnické Část zdravotnických přístrojů je již připojena k IS a data předávána do NISu,
přístroje (analyzátory) nicméně se jedná o menší množství a řada nových přístrojů
připojena k NISu není (bedside monitory, kardiotokografy, glukomentry atd.)
a údaje je třeba odečítat a přepisovat do NIS personálem.
Detailní informace jsou uvedeny v kap. 6.4 – Specifické údaje vybraných klinik.
Elektronická ONP vede zdravotnickou dokumentaci sice v NISu, ale tato dokumentace
zdravotnická nesplňuje podmínky na vedení plně elektronické zdravotnické dokumentace.
dokumentace Z tohoto důvodu se veškerá dokumentace tiskne a zakládá (archivuje)
v papírové podobě.
Strana 115 / 127
Technologie Stav
Elektronická ONP nedisponuje žádnou službou ani technologií, která by zajistila služby
identita a služby řízení identit podle nařízení eIDAS o elektronické identitě a službách
vytvářející důvěru vytvářejících důvěru. Tyto služby jsou podmínkou nutnou pro zavedení
elektronické zdravotnické dokumentace v souladu s legislativou a následnou
archivaci této dokumentace v elektronické podobě.
Tabulka 54: Současný stav informačních a komunikačních technologií
6.5.2 Informační systémy, které budou dotčeny projektem
V následující tabulce jsou informační systémy, které budou dotčeny projektem:
Systém Název Dodavatel Doplňující informace Modernizace
produktu s převodem dat
Náhrada
bez převodu dat
Integrace
stávajícího řešení
Strana 116 / 127
Systém Název Dodavatel Doplňující informace Modernizace
produktu s převodem dat
Náhrada
bez převodu dat
Integrace
stávajícího řešení
Tabulka 55: Informační systémy, které budou dotčeny projektem
Strana 117 / 127
6.5.2.1 Žádankový systém (externí žádanky)
Žádankový systém pro externí žádanky je určen pro externí subjekty žádající o vyšetření. Jedná se např.
o jiná zdravotnická zařízení, praktické lékaře apod.
Externí subjekty mají přístup na sdílené úložiště ONP, které je na technologii FTP. V rámci sdíleného
úložiště má každý subjekt vlastní složku, do které jsou vkládány žádanky a odkud jsou vyzvedávány
výsledky vyšetření, případně dalších úkonů.
Žádanky a výsledky (dále jen „zprávy“) jsou předávány ve formě soubory ve formátu DASTA, v 3 a vyšší,
případně je HL7. Žádanky a výsledky jsou šifrovány certifikátem, kterým je zajištěna konzistence dat a
zabezpečení citlivých (případně osobních dat) v rámci zpráv.
NIS v pravidelných intervalech zpracovává nové žádanky, dešifruje je a zpracuje dále jako vnitřní žádanky
na požadované úkony (vyšetření).
Po provedení úkonů NIS vytvoří zprávu s výsledky a po zašifrování je vloží do sdíleného úložiště, do složky
žádajícího subjektu, který si výsledky vyzvedne a zpracuje.
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.2 Žádankový systém na LP a SZM
Žádankový systém na LP a SZM slouží pro řízení požadavků na LP a SZM v rámci ONP.
V NIS se vygeneruje hromadná žádanka za nákladové středisko (z předepsané medikace, ručním
zadáváním atd.), která se rozdělí na skupiny (např. vázaná ATB, opiáty a ostatní) a ta bude odcházet
do žádanek systému Doctis jako rozpracovaná, kde proběhne proces schvalování a následně zajištění LP
a SZM (na centrální sklad).
Přenos bude probíhat v určitých časových intervalech automaticky.
Přenášená data – min.: ID číslo dokladu, datum vystavení, kdo vytvořil, nákladové středisko, kód léku,
název léku, množství, ATC.
6.5.2.3 Distribuce zdravotnických dat/externí subjekty
Distribuce zdravotnických dat pro externí subjekty využívá stejný princip a technologie jako Žádankový
systém v předchozí kapitole, tj. sdílené úložiště pro externí subjekty, kterým jsou do vyhrazených složek
vkládána zašifrovaná data ve formátech DASTA a HL7, odkud externí subjekty data čerpají.
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.4 ERP
Stávající integrace probíhá formou výměny souborů s daty ve formátu CSV (textový soubor
s oddělovačem atributů).
Popis struktury integračního rozhraní bude poskytnut v rámci implementační analýzy. Rozsah dat ve
vyměňovaných souborech je možné měnit v rozsahu dat, která jsou v ERP uložena.
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změny integračního rozhraní nad rámec dat již datových struktur se nepředpokládají.
Strana 118 / 127
V rámci realizace bude provedeno výchozí načtení dat (např. z centrálního skladu, dodavatelů) do NIS.
6.5.2.5 Operační sály – foto/video
Jedná se o produkt ENDOBASE dodaný společností Olympus Czech Group, s.r.o.
Předmětem projektu je přenos dat o pacientovi z NIS do tohoto systému a zpětně přenos foto/video a
výsledků do PACS a NIS.
Komunikace probíhá formou worklistů (DICOM, HL7) a DASTA.
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.6 Operační sály a operační management
V rámci integrace probíhá výměna dat vztahující se k ZUM/ZULP a diářům operačních sálů.
Stávající integrační rozhraní jsou:
• SQL pohled DB – pro operativní náhled (pouze ke čtení)
• export/import CSV – pro výměnu dat
Stručný popis integračního rozhraní mezi NIS a DoctIS:
A. Přenos operací z NIS
request:
datum
kód sálu
response:
surgeryid v NIS
patientid v NIS
patientname - pacient textove
plandate - den operace
planorder - poradi operace v dany den
roomid - id sálu
team - operační tým textově
intervention - zákrok textově
domain - dodatek k zákroku textově
diagnosis - diagnoza textově
anesthesia - anestézie textově
note - poznámka
B. Přenos pacientů z NIS
request:
patientId v NIS
response:
patientid - v NIS
Strana 119 / 127
firstname
lastname
personalid - RČ
birthdate
insurancenumber - číslo pojištěnce
insurancecomp - kód pojišťovny
sex
C. Přenos perioperačního záznamu do NIS
request:
vlastnosti:
patient-position - poloha
heating-mat-present - vyhrivana podlozka foley-catheter-present -
katetr neutral-electrode-present - Elektroda Ano/Ne neutral-
electrode-location - Elektroda popis wound-covering - Osetreni
rany rinse-and-contrast-media - Proplach text tourniquet-present
- Turniket Ano/Ne tourniquet-use-duration - TurniketMin
tamponade-present - Tamponáda Ano/Ne drains-present - Dren Ano/Ne
drains-count - Dren pocet intervention - zákrok poznámka
operační tým:
operatér
obíhající sestra 1 a 2
instrumentářka 1 a 2
sanitář 1 a 2
ostatní role
tabulka použitého materiálu:
počet
název produktu
tabulka použitých nástrojů:
počet
název nástroje
tabulka sterilizace:
počet
název nástroje (nebo produktu)
D. přenos operačních událostí
celkem odesíláme 4 události:
ROOMIN - příjezd na sál
SURGERY_START - zahájení operace
Strana 120 / 127
SURGERY_FINISH - konec operace
ROOMOUT - opuštění sálu
request:
Customid - id operace v DoctIS
surgeryDate - datum operace
roomId - kód sálu
surgeryEvent - kód události
eventTime - datum a čas události
patientName - jméno pacienta
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.7 Elektronická preskripce/lékárna
V rámci integrace probíhá výměna dat vztahující se k lékům a léčivým prostředkům.
Stávající integrační rozhraní jsou:
• SQL pohled DB – pro operativní náhled (pouze ke čtení)
• export/import CSV – pro výměnu dat
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.8 Patologie
Stávající integrační rozhraní jsou:
• SQL pohled DB – pro operativní náhled (pouze ke čtení)
• export/import CSV – pro výměnu dat
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.9 Stravovací systém
Stávající integrační rozhraní jsou:
• SQL pohled DB – pro operativní náhled (pouze ke čtení)
• export/import CSV – pro výměnu dat
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.10 Personalistika
Stávající integrační rozhraní jsou:
• SQL pohled DB – pro operativní náhled (pouze ke čtení)
• export/import CSV – pro výměnu dat
Strana 121 / 127
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.11 Spisová služba
Stávající integrační rozhraní jsou:
• SQL pohled DB – pro operativní náhled (pouze ke čtení)
• export/import CSV – pro výměnu dat
Detailní popis a nastavení integračního rozhraní budou poskytnuty v rámci implementační analýzy.
Změna integračního rozhraní se nepředpokládá.
6.5.2.12 eHealth SčK (Krajský komunikační systém pro výměnu zdravotnické dokumentace)
Strana 122 / 127
6.5.3 Komunikační infrastruktura
Objednatel disponuje následující komunikační infastrukturou:
1. Objednatel zajistí nezbytnou komunikační infrastrukturu v rámci datového centra mezi
dodávanými, ostatními součástmi dodávky v rámci této VZ, integrovanými IS a klienty.
2. Objednatel zajistí připojení k internetu min. pro účely registrační autority.
6.5.4 Datová centra, HW infrastruktura a technologie
V této kapitole je uvedena infrastruktura, do které je požadováno integrovat poptávaný systém.
Potřebné HW a SW kapacity jsou předmětem dodávky systému.
ONP disponuje datovým centrem, kde provozuje využívané technologie. Řada HW a SW infrastruktury
je taktéž zastaralá, protože odpovídá době dodávek příslušných IS.
Objednatel v datovém centru disponuje následující infrastrukturou a technologiemi:
Technologie Popis stavu
Strana 123 / 127
Technologie Popis stavu
Strana 124 / 127
Technologie Popis stavu
Strana 125 / 127
Technologie Popis stavu
Tabulka 57: Infrastruktura a technologie v datovém centru
Adresa datového centra je uvedena v kapitole 5 – Místa plnění.
6.5.5 Technologie využívané objednatelem
Strana 126 / 127
Objednatel využívá následující technologie. Ve vybraných případech tyto technologie definují prostředí,
pro které je dodávka díla požadována.
Oblast Technologie Doplňující informace
Tabulka 58: Technologie
V případě neuvedení oblasti objednatel nespecifikuje technologii, případně podmínky pro její použití.
Konec základní části dokumentu
Strana 127 / 127
