Servisní smlouva
Servisní smlouva
uzavřená v souladu § 1746 odst. 2 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů
Smluvní strany
Nemocnice Břeclav, příspěvková organizace
IČO 00390780
se sídlem U Nemocnice 3066/1, 690 02 Břeclav
zastoupená Xxx. Xxxx Xxxxx, ředitel
DIČ: CZ00390780
zapsána v OR Krajského soudu v Brně, oddíl Pr, vložka 1233 číslo účtu 20236651/0100
dále také jako „objednatel“ a
OR-CZ spol. s r. o.
Obchodní společnost zapsaná v obchodním rejstříku vedeném Krajským soudem v Hradci
Králové pod spisovou značkou C 4090
IČO 48168921
DIČ CZ48168921
se sídlem Brněnská 19, Moravská Třebová 571 01
zastoupen Ing. Xxxxxxxx Xxxxxxx, jednatelem
bankovní spojení KB a.s.
číslo účtu 9131560287/0100
dále také jako „poskytovatel“,
objednatel a poskytovatel také společně jako „smluvní strany“
Článek 1
Úvodní ustanovení
1. Závazkový vztah založený touto smlouvou (dále jen „Smlouva“) se řídí zákonem č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „občanský zákoník“), konkrétně pak § 1746 odst. 2 a násl. občanského zákoníku.
2. Tato Smlouva je uzavřena na základě výsledku zadávacího řízení veřejné zakázky s názvem
„Modernizace a rozvoj Nemocničního informačního systému Nemocnice Břeclav“, která byla uveřejněna ve Věstníku veřejných zakázek pod evidenčním číslem zakázky Z2019- 021841 (dále také jako „veřejná zakázka“), to vše ve smyslu zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „zákon o zadávání veřejných zakázek“ nebo rovněž jen „ZZVZ“). Jednotlivá ustanovení této Smlouvy musí být vykládána v souladu se zadávacími podmínkami uvedenými v zadávací dokumentaci veřejné zakázky a v souladu s nabídkou zhotovitele podanou v rámci zadávacího řízení veřejné zakázky.
3. Poskytovatel prohlašuje, že je plně způsobilý k řádnému a včasnému poskytnutí služeb dle této Smlouvy, kdy se detailně seznámil s rozsahem a povahou předmětu smlouvy, a to tak že jsou mu známy veškeré relevantní technické, kvalitativní a jiné podmínky nezbytné k jeho realizaci, a že disponuje takovými kapacitami a odbornými znalostmi, které jsou nezbytné
pro realizaci předmětu smlouvy za dohodnuté maximální smluvní ceny uvedené v této Smlouvě, a to rovněž ve vazbě na jím prokázanou kvalifikaci pro plnění veřejné zakázky. Pověří-li poskytovatel plněním smlouvy jinou osobu, má se za to, že plnění realizuje sám.
4. Poskytovatel dále prohlašuje, že není v úpadku ani ve stavu hrozícího úpadku, a že mu není známo, že by vůči němu bylo zahájeno insolvenční řízení. Rovněž prohlašuje, že vůči němu není v právní moci žádné soudní rozhodnutí, případně rozhodnutí správního, daňového či jiného orgánu na plnění, které by mohlo být důvodem zahájení exekučního řízení na majetek poskytovatele a že takové exekuční řízení nebylo vůči němu zahájeno.
5. Smluvní strany prohlašují, že identifikační údaje uvedené v ustanovení o smluvních stranách této Smlouvy odpovídají aktuálnímu stavu, a že osobami jednajícími při uzavření této smlouvy jsou osoby oprávněné k jednání za smluvní strany. Jakékoliv změny předmětných údajů, jež nastanou v době po uzavření této smlouvy, jsou smluvní strany povinny bez zbytečného odkladu písemně sdělit druhé smluvní straně.
6. V případě, že se kterékoliv prohlášení některé ze smluvních stran podle tohoto článku ukáže býti nepravdivým, odpovídá tato smluvní strana za škodu a nemajetkovou újmu, která nepravdivostí prohlášení nebo v souvislosti s ní druhé smluvní straně vznikla.
7. Poskytovatel prohlašuje a zavazuje se, že po celou dobu platnosti této smlouvy bude mít sjednánu pojistnou smlouvu pro případ způsobení škody objednateli či třetí osobě s limitním plněním na jednu škodnou událost minimálně 10.000.000 Kč. Kopii pojistné smlouvy předloží poskytovatel objednateli nejpozději do 14ti dnů ode dne uzavření smlouvy.
8. Poskytovatel a objednatel se zavazují k vzájemné součinnosti za účelem plnění Smlouvy.
Článek 2
Definice pojmů
1. Informační systém je soubor technického vybavení (servery, komunikační infrastruktura, uživatelská pracoviště a jiné) a programového vybavení (operační systémy, databázové a aplikační programové vybavení a jiné), popsaný v příloze č. 1 zadávací dokumentace veřejné zakázky (dále také jen „zadávací dokumentace“) a v nabídce poskytovatele, podané v zadávacím řízení na výběr dodavatele veřejné zakázky (dále také jen „nabídka“), který je předmětem dodávky v rámci plnění veřejné zakázky, a dále popsaný v příloze č.1 této smlouvy. Zabezpečení servisu Informačního systému je předmětem Smlouvy.
2. Podporované programové vybavení (dále též „SW“) je soubor programů, jejichž funkčnost podporuje servisní pracoviště poskytovatele podle pravidel a zásad určených servisní Smlouvou.
3. Podporované technické vybavení (dále též „HW“) je soubor zařízení, jejichž funkčnost podporuje servisní pracoviště poskytovatele podle pravidel a zásad určených Smlouvou.
4. Aktualizace programového vybavení (Update Service, Maintenance) představuje předávání nových verzí SW modulů programového vybavení s vylepšenými funkcemi tak, jak je výrobce programového vybavení dává k dispozici. Aktualizace programového vybavení zajišťují jeho kompatibilitu s ostatními SW a HW komponenty informačního systému v souvislosti s jejich vývojem.
5. Servisní podpora je služba, která zahrnuje postupně jeden nebo více způsobů podpory provozu informačního systému. Konkrétní vymezení servisní podpory a jejího obsahu pro účely této Smlouvy je uvedeno v Příloze č. 2 zadávací dokumentace veřejné zakázky a v nabídce poskytovatele.
6. Místo instalace je pracoviště, kde je instalováno podporované programové nebo technické vybavení nebo jeho část.
7. Servisní pracoviště poskytovatele provádí všechny servisní úkony směřující k rychlému odstranění zjištěných potíží a k zajištění provozuschopnosti podporovaného programového nebo technického vybavení v rozsahu a způsobem určeném ustanoveními smlouvy.
8. Nahlášení požadavku na servisní podporu je úkon, kterým kontaktní pracovník objednatele sdělí servisnímu pracovišti poskytovatele, že nastaly provozní potíže podporovaného vybavení, které není možné vyřešit silami objednatele, a kterým proto žádá servisní pracoviště poskytovatele o poskytnutí servisní podpory. Vymezení mechanismů servisní podpory a kontaktní údaje jsou uvedeny v příloze č. 2 této Smlouvy.
9. Odezva je první reakce servisního pracoviště poskytovatele na požadavek objednatele na poskytnutí servisní podpory, která směřuje ke zjištění příčin oznámených provozních potíží.
10. Zprovoznění technického vybavení je uvedení technického vybavení do stavu, ve kterém vykazuje provozní vlastnosti specifikované výrobcem a předaným stavem v rámci dodávky.
11. Servisní zásah je označení činností, které směřují k odstranění oznámených provozních potíží podporovaného programového vybavení nebo ke zprovoznění podporovaného technického vybavení a vykonává je pracovník servisního pracoviště poskytovatele buď vzdáleně (vzdáleným přístupem nebo interaktivně po telefonu) nebo osobně (v místě instalace).
Článek 3
Účel a předmět Xxxxxxx
1. Účelem této Smlouvy je určení a definice závazku smluvních stran ve smyslu poskytování servisních služeb v podobě technické servisní podpory (dále také jako „servis nebo
„servisní podpora“) poskytovatelem pro potřeby objednatele, a to zejména časové a věcné vymezení způsobu provádění servisních činností poskytovatelem, stanovení předmětu a rozsahu servisních činností, určení ceny těchto činností a způsobu její úhrady objednatelem a vymezení dalších náležitostí souvisejících s právy a povinnostmi smluvních stran plynoucích z této Smlouvy.
2. Součástí plnění dle této smlouvy je i zajištění služeb spočívajících ve školení uživatelů informačního systému (v rozsahu max. 8 hodin za kalendářní měsíc). Služby dle tohoto ustanovení poskytne poskytovatel objednateli na základě písemných požadavků objednatele, a to vždy nejpozději do 14 dnů od obdržení požadavku, nestanoví-li objednatel termín pozdější. Poskytovatel na základě objednávky informuje objednatele o způsobu realizace služeb a časovém harmonogramu jejich provedení.
3. Smluvní strany souhlasí s touto Smlouvou s vědomím, že její plnění má za cíl zajistit optimální chod informačního systému, a to za předpokladu aktivní a cílevědomé součinnosti obou smluvních stran v intencích pravidel této smlouvy, i vlastní snahy každé ze smluvních stran samostatně minimalizovat případné poruchy, závady a chyby provozu a užití informačního systému.
4. Vymezení informačních systémů pro účely této Smlouvy je uvedeno v příloze č. 1 této
Smlouvy.
Článek 4
Vymezení servisní podpory a servisního období a místa plnění
1. Poskytovatel se zavazuje poskytovat objednateli servisní podporu na softwarové a hardwarové vybavení, specifikované v příloze č. 1 zadávací dokumentace veřejné zakázky a v nabídce poskytovatele, podané v zadávacím řízení na výběr dodavatele veřejné zakázky (dále také jen „nabídka“), které poskytovatel dodá objednateli v rámci plnění veřejné zakázky. Poskytovatel se zavazuje poskytovat objednateli servisní podporu dle této smlouvy minimálně v rozsahu uvedeném v příloze č. 2 zadávací dokumentace veřejné zakázky a dále v rozsahu daném tuto smlouvou a nabídkou poskytovatele. Poskytovatel se zavazuje zejména respektovat minimální požadavky na servisní služby a technickou a technologickou podporu uvedené v kap. 4 přílohy č. 2 zadávací dokumentace veřejné zakázky a dodržovat tam stanovené lhůty k poskytování servisních služeb.
2. Smluvní strany sjednávají, že zařazení vady do jednotlivých kategorií (P1 až P3) uvedených v čl. 4 přílohy č. 2 zadávací dokumentace určuje objednatel. Neodstraní-li poskytovatel uplatněnou vadu, resp. neposkytne-li poskytovatel sjednanou servisní podporu či podporu technickou/technologickou, a to ve smluveném termínu, je objednatel oprávněn odstranit takovou vadu a nedodělek na náklady poskytovatele sám nebo prostřednictvím třetí osoby. Veškeré takto vynaložené nebo s odstraněním vady související náklady uhradí objednateli poskytovatel.
3. Objednatel souhlasí s tím, že poskytovatel může poskytováním servisních služeb nebo jejich částí pověřit třetí osobu. Tímto se poskytovatel nezbavuje jakýchkoli práv, povinností nebo závazků vyplývajících z této Smlouvy a především se nezbavuje odpovědnosti za řádné provedení předmětu této smlouvy pro objednatele.
4. Délka servisního období se stanovuje na dobu neurčitou a počíná běžet dnem následujícím po řádném celkovém předání díla dle smlouvy o dílo uzavřené mezi poskytovatelem a objednatelem, na základě výsledku zadávacího řízení veřejné zakázky. Doba trvání servisní smlouvy se sjednává na dobu neurčitou s tím, že po dobu 60 měsíců ode dne předání řádně zhotoveného předmětu díla dle smlouvy o dílo ve smyslu věty předchozí, nebude Poskytovatel oprávněn tuto smlouvy vypovědět. Výpovědní doba činí 3 měsíce a začne běžet prvním dnem měsíce následujícího po doručení výpovědi druhé smluvní straně.
5. Servisní podpora je poskytována za úplatu sjednanou v rámci této smlouvy.
6. Po celou dobu poskytování servisní podpory je poskytovatel povinen poskytnout
objednateli
na jeho vyžádání písemný přehled provedených činností.
7. Místem plnění se sjednávají následující pracoviště objednatele na adrese U Nemocnice
3066/1, 690 02 Břeclav.
Článek 5
Cena
1. Cena za poskytování kompletních servisních služeb dle této smlouvy po dobu po sobě jdoucích 12ti kalendářních měsíců (dále jen „cena“) byla stranami dohodnuta částkou:
2 255 400,-Kč bez DPH
výše DPH 473 634,- Kč
2 729 034,-Kč včetně DPH
Cena uvedená v této smlouvě je pevná a obsahuje veškeré náklady a zisk zhotovitele, nezbytné pro splnění předmětu této smlouvy v rozsahu, který je dán touto smlouvou (tedy i včetně případných prací a dodávek, které v nabídce poskytovatele uvedeny nejsou, přestože tvoří součást předmětu této smlouvy) a v termínu dle této smlouvy. Způsob stanovení ceny a její výše byl odsouhlasen oběma smluvními stranami.
STANOVENÁ A ODSOUHLASENÁ CENA JE CENOU NEJVÝŠE PŘÍPUSTNOU, tj. pokud jde o
horní limit ceny, poskytovatel nemá právo požadovat bez souhlasu objednatele její zvýšení. V případě, že rozsah předmětu této smlouvy bude ze strany objednatele omezen, případně, pokud v průběhu plnění předmětu plnění dojde ke zjištění, že některé práce a dodávky při zachování rozsahu předmětu této smlouvy (funkčnosti celku) budou dodány v menším rozsahu, množství nebo ceně, pak se celková cena adekvátním způsobem sníží (tzv. méněpráce). V ostatních případech může být cena uvedená v tomto článku změněna pouze písemnou dohodou smluvních stran. Součástí ceny je i odměna poskytovatele za splnění všech ostatních jemu stanovených povinností dle této smlouvy. Smluvní strany se dohodly, že pokud dojde v průběhu plnění této smlouvy ke změně zákonné sazby daně z přidané hodnoty (dále jen „DPH“) stanovené pro příslušné plnění vyplývající z této smlouvy, bude tato sazba promítnuta do všech cen uvedených v této smlouvě s DPH a poskytovatel je od okamžiku nabytí účinnosti změny zákonné sazby DPH povinen účtovat platnou sazbu DPH. O této skutečnosti není nutné uzavírat dodatek k této smlouvě.
2. Smluvní strany se dohodly, že cenu servisní podpory uhradí objednatel na základě faktur vystavených poskytovatelem za příslušný kalendářní měsíc, a to se dnem zdanitelného plnění určeným k poslednímu dni příslušného měsíce, jakožto částku odpovídající vždy 1/12 ceny za roční poskytování servisní podpory, a to na základě objednatelem písemně odsouhlaseného soupisu provedených servisních služeb za dané období. V případě, že servisní služby za dané období nebudou poskytnuty v požadovaném rozsahu, parametrech či kvalitě, bude odměna za dané období odpovídajícím způsobem krácena.
Stejným způsobem bude odměna krácena v případě, že tato smlouva nebude trvat po celý příslušný kalendářní měsíc (počátek trvání smlouvy a konec trvání smlouvy).
3. Splatnost faktury – daňového dokladu je dohodou smluvních stran stanovena na 30 dnů ode dne jejího prokazatelného doručení objednateli. Zaplacením se pro účely této smlouvy rozumí odepsání příslušné částky z účtu objednatele ve prospěch účtu poskytovatele.
4. Faktura musí obsahovat veškeré náležitosti daňového dokladu podle zákona č. 563/1991
Sb.,
o účetnictví, ve znění pozdějších předpisů, a zákona č. 235/2004 Sb., o dani z přidané
hodnoty,
ve znění pozdějších předpisů.
5. Faktura musí kromě zákonem stanovených náležitostí pro daňový doklad obsahovat také:
▪ číslo a datum vystavení faktury;
▪ číslo Smlouvy a datum jejího uzavření, číslo veřejné zakázky;
▪ předmět plnění a jeho přesnou specifikaci ve slovním vyjádření (nestačí pouze
odkaz
na číslo uzavřené Smlouvy);
▪ označení banky a číslo účtu, na který musí být zaplaceno (pokud je číslo účtu odlišné
od čísla uvedeného v této Smlouvě, je poskytovatel povinen o této skutečnosti
informovat objednatele);
▪ číslo a datum příslušných písemných objednávek pro poskytování servisní podpory
v souladu s článkem 4 této Smlouvy;
▪ lhůtu splatnosti faktury;
▪ název, sídlo, IČO a DIČ objednatele a poskytovatele;
▪ jméno a vlastnoruční podpis osoby, která fakturu vystavila, včetně kontaktního
telefonu.
6. Nebude-li faktura obsahovat některou povinnou nebo dohodnutou náležitost včetně přílohy (objednatelem odsouhlasený soupis služeb) nebo bude chybně vyúčtována cena nebo DPH, je objednatel oprávněn fakturu před uplynutím lhůty splatnosti vrátit druhé smluvní straně k provedení opravy s vyznačením důvodu vrácení. Poskytovatel provede opravu vystavením nové faktury. Dnem odeslání vadné faktury poskytovateli přestává běžet původní lhůta splatnosti a nová lhůta splatnosti běží znovu ode dne doručení nové a řádně vystavené faktury objednateli.
Článek 6
Součinnost smluvních stran
1. Poskytovatel se zavazuje, že pracovníci poskytovatele a jeho poddodavatelé budou při plnění závazků, které vyplývají z této Smlouvy, dodržovat veškeré bezpečnostní předpisy,
veškeré zákony a jejich prováděcí vyhlášky, pokud se vztahují k činnosti poskytovatele, bezpečnosti práce, požární ochraně a ochraně životního prostředí. Pokud porušením těchto předpisů poskytovatelem nebo poddodavatelem poskytovatele vznikne škoda, nese náklady poskytovatel. Vzhledem k charakteru objednatele se pracovníci poskytovatele musí při plnění závazků bezpodmínečně řídit také pokyny objednatele.
2. Objednatel se zavazuje vytvářet ze své strany podmínky směřující k minimalizaci případných škod na technickém vybavení objednatele vzniklých v souvislosti s prováděním servisních zásahů, které může ovlivnit výhradně objednatel.
3. Poskytovatel odpovídá za škody na technickém vybavení objednatele, které prokazatelně způsobili pracovníci poskytovatele.
4. Objednatel stanoví jako kontaktní osoby odpovědné pracovníky objednatele. Tyto kontaktní osoby budou oprávněny zastupovat objednatele u poskytovatele při plnění ustanovení této smlouvy. Objednatel se zavazuje v případě změn kontaktních údajů oznámit tyto změny neprodleně v písemné podobě poskytovateli. Odpovědnými pracovníky objednatele jsou:
▪ odpovědný pracovník:
Xxx. Xxxxxx Xxxxxxxx, xxxxxxxx@xxxxx.xx, x000 000000000, 000 000 000
▪ odpovědný pracovník:
Xxx. Xxxxxx Xxxxx, MBA, xxxxx@xxxxx.xx, x000 000000000, 000 000 000
▪ odpovědný pracovník:
Xxx. Xxxxx Xxxxxx, xxxxxx@xxxxx.xx, x000 000000000, 000 000 000
5. Smluvní strany se zavazují, že kontaktní osoby si budou při plnění ustanovení této smlouvy poskytovat vzájemnou co nejúčinnější součinnost po celou dobu od nahlášení požadavku na servisní podporu až do uzavření servisního případu a že budou dodržovat postupy specifikované touto Smlouvou.
6. Objednatel zajistí, aby ze strany objednatele nebyly poskytovateli činěny překážky pro poskytování servisní podpory. K tomu objednatel zejména:
▪ bude poskytovat pracovníkům servisního pracoviště poskytovatele podle jejich pokynů
po celou dobu řešení servisního případu od nahlášení požadavku na servisní podporu až do uzavření servisního případu všechny požadované informace (i datové soubory, kopie obrazovek a výstupy příkazů apod.) a výsledky
doporučených úkonů potřebné k diagnostice příčin a řešení oznámených provozních potíží podporovaného vybavení,
▪ umožní pracovníkům servisního pracoviště poskytovatele vstup na příslušné místo provedení servisního zásahu a dle místních podmínek jim umožní i vjezd do objektu a parkování vozidla po celou dobu trvání servisního zásahu,
▪ zajistí po celou dobu trvání servisního zásahu dosažitelnost (případně fyzickou přítomnost) příslušných kontaktních osob objednatele a případně i dalších potřebných odborných pracovníků v místě instalace podporovaného vybavení a jejich co nejúčinnější součinnost.
7. Poskytovatel se zavazuje k provádění řádné provozní údržby podporovaného technického a softwarového vybavení dle této Smlouvy včas v termínech a v rozsahu předepsaných výrobci tohoto vybavení a přílohou.
8. Pracovníci Objednatele, pokud se tak rozhodnou, jsou oprávněni provádět na informačním systému drobné opravy závad vlastními silami při dodržení všech závazných podmínek a ustanovení, jakož i veškerých pracovních postupů a doporučení stanovených Poskytovatelem.
Článek 7
Důvěrné informace, ochrana osobních údajů
1. V případě, že bude při plnění předmětu Smlouvy docházet ke zpracování osobních údajů, je tato smlouva zároveň smlouvou o zpracování osobních údajů ve smyslu § 6 zákona č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů (dále jen „zákon o ochraně osobních údajů“). Poskytovatel má pro účely ochrany osobních údajů postavení zpracovatele ve smyslu zákona o ochraně osobních údajů. Ve smyslu 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 volném pohybu těchto údajů je poskytovatel považován za zpracovatele ve smyslu tohoto nařízení a je povinen splnit všechny povinnosti z toho vyplývající.
2. Poskytovatel je oprávněn zpracovávat osobní údaje pouze za účelem plnění této Smlouvy.
3. Poskytovatel je oprávněn zpracovávat osobní údaje v rozsahu nezbytně nutném pro plnění této Smlouvy, za tímto účelem je oprávněn osobní údaje zejména ukládat na nosiče informací, upravovat, uchovávat po dobu nezbytnou k uplatnění práv vyplývajících z této smlouvy, předávat zpracované osobních údaje objednateli, osobní údaje likvidovat.
4. Poskytovatel učiní v souladu s platnými právními předpisy dostatečná organizační
a technická opatření zabraňující přístupu neoprávněných osob k osobním údajům
o ochraně osobních údajů.
5. Poskytovatel zajistí, aby jeho zaměstnanci byli v souladu s platnými právními předpisy poučeni o povinnosti mlčenlivosti a o možných následcích pro případ porušení této povinnosti.
6. Poskytovatel zajistí, aby písemnosti a jiné hmotné nosiče informací, které obsahují osobní údaje, byly uchovávány pouze v uzamykatelných místnostech.
7. Poskytovatel zajistí, aby písemnosti a jiné hmotné nosiče informací, které obsahují citlivé údaje, byly uchovávány v uzamykatelných skříních umístěných v uzamykatelných místnostech.
8. Poskytovatel zajistí, aby elektronické datové soubory obsahující osobní údaje byly uchovávány v paměti počítače pouze:
▪ je-li přístup k takovýmto souborům chráněn heslem nebo,
▪ je-li přístup k užívání počítače, v jehož paměti jsou tyto soubory umístěny, chráněn
heslem.
9. Je-li pro účel kontroly správného fungování díla, odstranění vady nebo další vývoj díla nezbytné poskytnout poskytovateli kopii databází, souborů nebo nosičů údajů obsahujících jakékoliv údaje z činnosti objednatele, je poskytovatel povinen s takovými údaji nakládat tak, aby nedošlo k jejich úniku či zneužití.
10. Veškeré skutečnosti obchodní, ekonomické a technické povahy související se smluvními stranami, které nejsou běžně dostupné v obchodních kruzích a se kterými se smluvní strany seznámí při realizaci předmětu Smlouvy nebo v souvislosti s touto Smlouvou, se považují za důvěrné informace.
11. Poskytovatel se zavazuje, že důvěrné informace jiným subjektům nesdělí, nezpřístupní, ani nevyužije pro sebe nebo pro jinou osobu. Zavazuje se zachovat je v přísné tajnosti a sdělit je výlučně těm svým zaměstnancům nebo subdodavatelům, kteří jsou pověřeni plněním Smlouvy a za tímto účelem jsou oprávněni se s těmito informacemi v nezbytném rozsahu seznámit. Poskytovatel se zavazuje zabezpečit, aby i tyto osoby považovaly uvedené informace za důvěrné a zachovávaly o nich mlčenlivost.
12. Povinnost plnit ustanovení tohoto článku smlouvy se nevztahuje na informace, které:
▪ mohou být zveřejněny bez porušení této Smlouvy,
▪ byly písemným souhlasem obou smluvních stran zproštěny těchto omezení,
▪ jsou známé nebo byly zveřejněny jinak, než následkem porušení povinnosti jedné ze smluvních stran,
▪ příjemce je zná dříve, než je sdělí smluvní strana,
▪ jsou vyžádány soudem, státním zastupitelstvím nebo příslušným správním orgánem
na základě zákona, nebo jejichž uveřejnění je stanoveno zákonem,
▪ smluvní strana sdělí osobě vázané zákonnou povinností mlčenlivosti (např. advokátovi nebo daňovému poradci) za účelem uplatňování svých práv.
13. Povinnost ochrany důvěrných informací trvá bez ohledu na ukončení platnosti této
Smlouvy.
14. Smluvní strany se zavazují, že obchodní a technické informace, které jim byly svěřeny druhou stranou, nezpřístupní třetím osobám bez písemného souhlasu druhé strany a nepoužijí tyto informace k jiným účelům, než je k plnění této smlouvy.
15. S datovými nosiči, které obsahují informace označené objednatelem jako důvěrné nebo utajované, musí být v souvislosti s plněním ustanovení smlouvy nakládáno podle pokynů objednatele.
Článek 8
Sankce
1. V případě nedodržení doby odezvy (nebo jiných mezi stranami sjednaných termínů) poskytovatelem k jednotlivému případu se smluvní strany dohodly na smluvní pokutě ve výši 5.000 Kč za každou i započatou hodinu prodlení v případě vad kategorie P1 a P2, a smluvní pokutu ve výši 2.000 Kč za každý i započatý den prodlení v případě vady kategorie P3, a to vždy pro každý případ prodlení. Tuto smluvní pokutu zaplatí poskytovatel objednateli do 15 dnů poté, kdy k tomu bude vyzván.
2. V případě, že poskytovatel neumožní objednateli zadat požadavek na servisní zásah z důvodu nedostupnosti služeb HelpDesk, způsobené výpadkem uvedených služeb na straně poskytovatele, je objednatel oprávněn po poskytovateli požadovat smluvní pokutu ve výši 1.000 Kč za každý jednotlivý případ.
3. V případě, že objednatel je v prodlení s úhradou faktury, je povinen uhradit poskytovateli úrok z prodlení v zákonné výši. V případě, že objednatel je v prodlení s úhradou faktury, poskytovatel na tuto skutečnost upozorní písemným sdělením kontaktní osobu objednatele.
4. Smluvní pokuty a úrok z prodlení jsou splatné do 15 dnů od doručení jejich vyžádání oprávněnou smluvní stranou straně povinné. Platby budou provedeny bezhotovostním bankovním převodem na účet oprávněné smluvní strany. Ujednání o smluvních pokutách se nedotýkají náhrady škody, ke které je poskytovatel povinen v celém rozsahu. Objednatel je případně oprávněn o výši takové smluvní pokuty snížit odměnu poskytovatele za dané období.
Článek 9
Ukončení Smlouvy
1. Kterákoliv ze smluvních stran může od této Smlouvy odstoupit z důvodu podstatného porušení povinností vyplývajících z této Smlouvy. Za podstatné porušení podmínek Smlouvy smluvní strany považují:
▪ neposkytnutí sjednané servisní podpory poskytovatelem po řádném nahlášení požadavku objednatelem,
▪ nedodržení doby odezvy nebo jiných dohodnutých termínů poskytovatelem o více jak 5 pracovních dnů,
▪ bezdůvodné přerušení prací na servisním případu poskytovatelem,
▪ opakované nesplnění závazku objednatele poskytnout poskytovateli součinnost při plnění ustanovení této Smlouvy i přes písemné upozornění doručené objednateli,
▪ opakované prodlení objednatele s placením fakturované částky delší než jeden měsíc ode dne splatnosti příslušného řádně doručeného daňového dokladu.
2. Smluvní strana je oprávněna od Xxxxxxx odstoupit ve lhůtě 30 kalendářních dnů ode dne, kdy se o podstatném porušení povinností dozvěděla, nejpozději však do 6 měsíců ode dne kdy k podstatnému porušení povinností došlo. Odstoupení nabývá účinnosti dnem prokazatelného doručení jeho písemného vyhotovení druhé smluvní straně.
Článek 10 Závěrečná ustanovení
1. Smluvní strany se budou bez zbytečného prodlení vzájemně informovat o všech změnách v adresách, telefonních číslech, číslech faxů, a pod., uvedených v této Smlouvě. Komunikace smluvních stran bude probíhat písemně. Za písemnou formu se považuje i prostá elektronická pošta (e-mail).
2. Tato Xxxxxxx nabývá platnosti dnem podpisu oběma smluvními stranami a účinnosti dnem následujícím po řádném celkovém předání díla dle smlouvy o dílo uzavřené mezi poskytovatelem a objednatelem na základě výsledku zadávacího řízení veřejné zakázky,
3. Doplnit a měnit Smlouvu mohou smluvní strany pouze formou písemných dodatků, které budou vzestupně číslovány, výslovně prohlášeny za dodatek této Smlouvy a podepsány oprávněnými zástupci smluvních stran.
4. Objednatel je povinen ve smyslu zákona o registru smluv a zákona o zadávání veřejných zakázkách uveřejnit text uzavřené Xxxxxxx s poskytovatelem, včetně jejích příloh případných změn a dodatků a dále skutečně uhrazenou cenu, a to zákonem předpokládaným způsobem. Objednatel s uveřejněním souhlasí v plném rozsahu. Souhlas poskytovatele se vztahuje také na uveřejnění předmětných dokumentů a informací
objednatelem podle zákona č. 106/1999 Sb., o svobodném přístupu k informacím,
ve znění pozdějších předpisů.
5. Poskytovatel je podle ustanovení § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů, ve znění pozdějších předpisů, osobou povinou spolupůsobit při výkonu finanční kontroly prováděné v souvislosti s úhradou zboží nebo služeb z veřejných výdajů. Poskytovatel je povinen archivovat originální vyhotovení Smlouvy včetně jejích dodatků, originály účetních dokladů a dalších dokladů vztahujících se k realizaci předmětu této Smlouvy po dobu 10 let od zániku této Smlouvy, minimálně však do roku 2030. Po tuto dobu je poskytovatel povinen umožnit osobám oprávněným k výkonu kontroly projektů provést kontrolu dokladů souvisejících s plněním této smlouvy.
6. Poskytovatel je povinen ve lhůtách dle předchozího odstavce poskytovat požadované informace a dokumentaci související s realizací projektu objednateli, zaměstnancům nebo zmocněncům pověřených orgánů (CRR, MMR ČR, MF ČR, Evropské komise, Evropského účetního dvora, Nejvyššího kontrolního úřadu, příslušného orgánu finanční správy a dalších oprávněných orgánů státní správy) a je povinen vytvořit výše uvedeným osobám podmínky k provedení kontroly vztahující se k realizaci projektu, poskytnout jim při provádění kontroly součinnost a být fyzicky přítomen kontrolám v místě plnění. Spolufinancování realizace díla se předpokládá z fondů Evropské unie prostřednictvím Integrovaného regionálního operačního programu (dále jen „IROP“) v rámci projektu
„Modernizace a rozvoj Nemocničního informačního systému Nemocnice Břeclav“, reg. č. CZ.06.3.05/0.0/0.0/16_044/0006190, který je realizován z výzvy č. 28 Integrovaného regionálního operačního programu s názvem „Specifické informační a komunikační systémy a infrastruktura II.“, prioritní osy PO 3: Dobrá správa území a zefektivnění veřejných institucí, specifického cíle SC 3.2: Zvyšování efektivity a transparentnosti veřejné správy prostřednictvím rozvoje využití a kvality systémů IKT (dále jen „projekt“).
7. Smxxxxx xe vyhotovena ve 4 stejnopisech, které mají platnost originálu, z toho jeden
stejnopis Smlouvy obdrží poskytovatel a tři stejnopisy smlouvy objednatel.
8. Vztahy smluvních stran výslovně touto Smlouvou neupravené se řídí obecně závaznými právními předpisy, zejména ustanoveními občanského zákoníku.
9. Smluvní strany prohlašují, že si Smxxxxx xřečetly, že tato byla sepsána na základě jejich pravé a svobodné vůle, nikoli v tísni a za nápadně nevýhodných podmínek, a na důkaz toho připojují své podpisy.
10. Všechny postupně číslované přílohy Smlouvy jsou její nedílnou součástí. Seznam příloh
Smlouvy:
Příloha č. 1 – Specifikace informačního systému
Příloha č. 2 – Vymezení mechanismů servisní podpory a kontaktní údaje Příloha č. 3 - servisní smlouvy – servisní služby
Za objednatele Za poskytovatele
V Břeclavi V Moravské Třebové
Xxxxx
Digitálně podepsal Xxx. Xxxx Xxxxx
Ing. Xxxx
Datum: 2019.10.15
15:24:25 +02'00'
Xxx. Xxxxxx Xxxxx
Digitálně podepsal Xxx. Xxxxxx Xxxxx Xatum: 2019.10.07
……………………………………………………….………….
13:39:33 +02'00'
………………………………………………………………
Xxx. Xxxx Xxxxx, ředitel Xxx. Xxxxxx Xxxxx, jednatel Nemocnice Břeclav, příspěvková organizace OR-CZ spol. s r. o.
Příloha č. 1 servisní smlouvy
Specifikace Informačního systému,
5 Představení nabídky a nabízeného systému
Uchazeč dle kapitoly 14, odstavce 7 Zadávací dokumentace uvádí pro upřesnění následující:
Dodavatel uvádí, že instalace a provoz předmětu plnění nevyžaduje splnění zvláštních podmínek ze strany zadavatele.
5.1 Cíle zhotovitele
Cílem zhotovitele v případě předkládané nabídky pro Nemocnici Břeclav (dále jen NBv nebo zadavatel) je především:
▪ Modernizace stávajícího klinického informačního systému nemocnice (dále jen KIS) s výhledem minimálně na 10 let dalšího provozu
▪ Rozšíření provozovaných modulů dle funkčních požadavků zadávací dokumentace
▪ Zavedení elektronizace procesů v oblasti zdravotnické dokumentace a jejich dlouhodobá a důvěryhodná archivace
▪ Podpora mobilních zařízení v řadě oblastí (mobilní vizity, elektronického podání léků a ověření osoby pacienta pomocí náramků a čtečky)
▪ Podpora sledování zdravotnických procesů, jejich definice, ověřování a sledování stavu rozpracovanosti
▪ Umožnění elektronické komunikace nejen mezi jednotlivými odděleními a klinikami navzájem, ale i komunikace s externími subjekty (zdravotními pojišťovnami, ÚZIS a dalšími národními registry) a komunikace s externími lékaři a s dalšími zdravotními zařízeními jak na úrovni kraje, tak na úrovni celorepublikové i přeshraniční
▪ Dodávka nezbytné HW infrastruktury a souvisejícího systémového software pro nový KIS a jeho nové části/funkcionality
▪ Dodávka dalšího nezbytného technického vybavení (tablety, případně notebooky pro personál, čtečky čárových kódů a tiskárny náramků s čárovými kódy)
Nabízený systém ICZ AMIS*HD pro oblast nových modulů představuje novou generaci komplexního informačního řešení podporujícího provoz zdravotnických zařízení. Je primárně zaměřen na podporu funkcí klinického provozu, rovněž zabezpečuje informační podporu souvisejících provozních agend.
U tohoto řešení, která bylo vyvinuto pro Evropský trh byl od počátku kladen důraz na:
▪ bezpečnost a ochranu citlivých údajů včetně legislativní kompatibility
▪ nativní podporu multimédií
▪ nativní podporu mobilních zařízení
▪ organické zaměření na healt-share, multidimenzionální spolupráci v léčebném procesu a telemedicínu
▪ UX zaměřené uživatelské rozhraní s technologií tenkého klienta
Řešení ICZ AMIS*HD bylo vyvíjeno jako zcela nové a absorbuje v sobě tak nejnovější trendy jak z pohledu ICT, tak z pohledu přístupů k léčbě pacienta, respektive k nakládání s daty o jeho léčbě. Celé řešení tak vertikálně i horizontálně podporuje principy EHR vedení zdravotnické dokumentace.
Mezi další výjimečné vlastnosti řešení patří mimořádně nízké systémové nároky, především díky pokročilé technologii tenkého webového klienta.
Samotné technologické řešení ICZ AMIS*HD se opírá o jednotný, konzistentní aplikační framework s decentralizovanými, modulárními systémy, které jsou vzájemně provázány datovými konektory s výměnou dat v reálném čase. Principiálně je řešení databázově nezávislé. Koncepce řešení je postavena na integraci programových modulů i externích systémů pomocí architektury SOA (Service Oriented Architecture), podpoře komunikace s externími systémy na bázi standardů (resp. protokolů) DASTA a HL7. Tato architektura je výhodná pro budování rozsáhlých informačních systémů, které zdaleka převyšují poptávaný regionální (krajský) rozsah. Námi použitá architektura zabezpečuje dlouhodobě stabilní, snadno rozšiřitelný a výkonný aparát, s malými nároky na správu i údržbu.
Velká pozornost je od počátku vývoje řešení věnována komunikaci s okolím. Řešení je vybaveno rozhraním schopným odesílat i přijímat příslušná data do externích systémů. Jednotlivé systémy řešení sdílejí stejné technologie, umožňují jednotnou správu a údržbu, ale jejich funkcionalita je specifická v závislosti na typu poskytovaných služeb. Řešení nativně podporuje jak český národní standard DASTA, tak mezinárodní protokol HL7.
Architektura řešení v sobě integruje řadu špičkových technologií zahrnující architekturu SOA, implementaci ESB, workflow procesní řízení, podporu patient case. Vysoký standard bezpečnosti řešení může podporovat například implementace clusteringu, patient security systému, sofistikované řízení a auditovaní přístupů do systému a práci s daty a řada dalších funkcionalit.
Navrhované řešení a jeho implementace garantuje dlouhodobý provoz se včasnými a bezproblémovými reakcemi na případné legislativní změny a požadavky. Je to dáno celkovou logickou koncepcí a architekturou systému, použitím dynamických číselníků a zásadní vlastností systému, kdy veškeré komponenty a chování systému jsou plně nastavitelné.
Implementace všech národních číselníků je součástí dodávky. Metodika jejich centrální aktualizace je součástí školení administrátorů systému.
Řešení poskytuje dostatečné nástroje k navýšení výkonu pro případ výrazného nárůstu počtu uživatelů, rozsahu nabízených služeb nebo objemu přenášených a spravovaných dat, stejně jako pro případ rozšiřování funkcionality a topologie řešení.
Řešení je postaveno jako bezpečné a důvěryhodné z hlediska správy přístupů k datům. Správa přístupů umožňuje nastavovat detailně jednotlivé pravomoci, ale také auditovat přístupy k datům, nezvyklé události (bezpečnosti incidenty). Řešení umožňuje na aplikační úrovni monitorovat a sledovat některé činnosti a změny včetně jejich zpracování na úrovni hlášení, reportů a výstupů. Tyto výstupy je možno zpřístupňovat libovolným uživatelům na základě definice přístupových práv k těmto funkcím.
Samozřejmostí je komplexní řešení zálohování, ochrany proti výpadkům, architektura, která v maximální možné míře zabraňuje paralyzaci celého řešení v důsledku chyby jedné komponenty. Řešení může podporovat clustering pro vysoký stupeň dostupnosti řešení.
Koncepce řešení v oblasti hardware vychází z aktuálních hardwarových standardů velkých organizací jak v oblasti centrálních a infrastrukturních komponent, tak v oblasti HW vybavení koncových pracovišť. Základní kritéria návrhu respektují optimalizaci poměru faktorů cena – výkon s přihlédnutím k očekávanému zdražování cen energií a také odhadovanému významnému růstu kapacitních nároků jak na straně komunikačních cest, tak v oblasti datových úložišť v horizontu příštích 10ti let.
Samostatnými produkty a jejich integrací jsou pak řešeny následující oblasti:
1. Modul Patologie – systém Orpheus (xxxx://xxx.xxxxxxx.xx)
2. Řešení SSO – KeyShield SSO (xxxx://xxx.xxx.xx)
Uvedené systémy jsou plně integrovány s NIS AMIS*H/HD a to jak v oblasti uživatelského ovládání, tak v oblasti používání a synchronizace společně používaných číselníků.
6 Obecná charakteristika KIS
Informační systém AMIS*HD je realizován v současnosti v nejmodernější vícevrstvé škálovatelné architektuře, která využívá nejmodernější současné používané technologie a standardy. Tímto je tento systém na českém trhu výjimečný a zaručuje tak v současnosti nejdelší možnou perspektivu z hlediska rozvoje a to na dobu více než 10 let.
Systém je tvořen následujícími hlavními vrstvami:
Datová vrstva je reprezentována robustním, výkonným SQL serverem, který komunikuje s dalšími částmi (vrstvami) systému JDBC komunikační vrstvou.
Aplikační vrstva je vyvinuta v prostředí aplikačního serveru a zajišťuje realizaci drtivé většiny aplikační logiky. Jedna ze zásadních výhod tohoto řešení je standardizace řešení a jeho bezproblémová výkonnostní škálovatelnost. Celý systém AMIS*HD je realizován jako internetová webově orientovaná aplikace.
Prezentační vrstva řeší vizuální prezentaci dat, které získá od aplikační vrstvy a provádí dílčí akce aplikační logiky. Uživatelé tedy pracují s aplikací prostřednictvím tenkého klienta, kterým je internetový prohlížeč a jedná se tedy o systém, který je na klientských koncových pracovištích (PC) zcela bez instalační, pro provoz je nutný pouze standardní internetový prohlížeč.
Nedílnou součástí řešení je i integrační vrstva AMIS*HD realizovaná jako ESB (Enterprise Service Bus), která umožňuje elegantním způsobem realizovat integrace s externími systémy.
Systém AMIS*HD má jednotné uživatelské grafické prostředí realizované jako WEB aplikace v prostředí internetového prohlížeče (doporučený je Chrome, ale je možné využít i další - MSIE, Mozilla FF…) a je možné je provozovat na standardních pracovních stanicích, ale také na mobilních zařízeních typu tablet, kdy je opět využíváno internetového prohlížeče. Zde je podporována HTML, HTML5 technologie a není nutno pro provoz systému využívat žádných doplňků nebo zásuvných modulů. Systém podporuje činnosti zdravotnického personálů u lůžka pacienta (zejména podpora vizity, medikace, vedení ošetřovatelské dokumentace).
Všechny části systémů s uživatelem komunikují plně česky. Systém navíc podporuje libovolné množství jazyků a uživatel tedy kromě českého jazyka může, při přihlášení do systému zvolit i další jazyky uživatelského prostředí (angličtina, němčina, ruština, ukrajinština, …).
AMIS*HD obsahuje on-line dostupnou podporu ve formě návodu v českém jazyce pro všechny uživatele systému. Obsahuje kontextovou nápovědu a dokumentace je vždy aktuální k provozované verzi systému.
AMIS*HD plně podporuje jednotné řešení systému správy identit uživatelů, včetně autentizace, autorizace a single-sign-on ve všech modulech a funkcionalitách. Přístupová práva v systému AMIS*HD jsou realizována jako hierarchická se stanovením rozsahu přístupu i stupně oprávnění manipulace. Je aplikovány princip nastavování práv na roli uživatele (skupina uživatelů), ale je možné tato nastavení realizovat i na jiných úrovních, od celé organizace až po jednotlivého uživatele.
NIS AMIS*HD je založen na moderním procesně orientovaném přístupu. Umožňuje tak nastavení dle reálně probíhajících procesů na jednotlivých pracovištích a sledování probíhajících procesů a jejich vyhodnocování.
Vedení zdravotních záznamů je realizováno strukturovaně. Je podporováno sdílení záznamů a dokumentů. Je plně podporována možnost nastavení jednotlivých položek (povinný údaj, možné hodnoty) a možnost výběrů z vlastních číselníků pro jednotlivé položky.
Napříč celým systémem je přísně evidována (auditovaná) jednoznačná identifikace kdo, odkud, kdy, nad kterými daty provedl jakou činnost v systému. Systém může podporovat automatickou kompletní historizaci dat s možností náhledu na audit činností a historických dat v administrátorském prostředí s funkcionalitou pro vyhledávání a filtraci dat.
Součástí důvěryhodného elektronického archivu ZD je ukládání dokumentů v podobě PDF/A včetně časového razítka kvalifikované certifikační autority.
Systém je připraven na možnost implementace kompletního vedení čistě elektronické zdravotnické dokumentace (dle aktuálně platné legislativy).
Součástí legislativní podpory je zajištění procesů souvisejících s vedením čistě elektronické dokumentace reflektující vývoj dle platné legislativy (po celou dobu životnosti systému) včetně možnosti přechodu na bezvýznamové identifikátory pacientů (v případě ukončení identifikace rodným číslem).
7 Požadavky na dodávky a související služby - popis vlastností a funkcí jednotlivých oblastí KIS
7.1 Obecné vlastnosti KIS
Nabízené řešení ICZ AMIS*HD je nemocniční informační systém nové generace. Systém je založený na hybridním modelu klinického workflow a statických medicínských a ošetřovatelských souborů dat. Pokrývá klasické klinické činnosti zdravotnického zařízení (ambulance, lůžková pracoviště, stacionáře, operační sály, neonatologie, porodnice atd...) a vybrané komplementární, provozní a manažerské agendy.
ICZ AMIS*HD představuje komplexní, modulární nemocniční informační systém orientovaný na podporu moderních standardů léčebné a preventivní péče, zvyšování bezpečnosti léčebného procesu, efektivitu obsluhy, podporu mobilních periférií, ekonomiku provozu a rychlou implementovatelnost.
Ve srovnání s jinými produkty vyniká snadností nasazení, nebývale širokou podporou klinických funkcí a nízkými systémovými nároky.
Řešení je postaveno v souladu s nejmodernějším přístupem k návrhu architektury robustních podnikových informačních systémů.
Grafické moduly ICZ AMIS*HD jsou vytvořeny ve vícevrstvé architektuře. Datová vrstva je reprezentována relační databází dle výběru zadavatele (řešení je principiálně databázově nezávislé, za podmínky splnění základních technologických podmínek pro danou databázi) a je schopno pracovat s většinou moderních relačních databází.
Aplikační vrstva je vyvinuta v prostředí Google Web Toolkit a na úrovni web serveru zajišťuje realizaci drtivé většiny aplikační logiky. Provoz aplikační vrstvy zajišťuje aplikační server Apache Tomcat nebo JBoss .
Prezentační vrstva řeší vizuální prezentaci dat, které získá od aplikační vrstvy a provádí dílčí akce aplikační logiky.
Uživatelé tedy pracují s aplikací prostřednictvím tenkého klienta, kterým je internetový prohlížeč.
Řešení je navrženo primárně jako vysoce bezpečný systém určený k manipulaci s citlivými údaji. Tomu odpovídá i úroveň zabezpečení. Přístup k veškerým datům je centrálně řízen na základě definovaných etalonů přístupových práv s explicitně utajovanými typy dokumentace nebo pracovišti. Veškeré akce vyvolané uživateli jsou zaznamenávány a zpětně dohledatelné.
Celé řešení je navrženo s vysokým důrazem na bezpečnost na všech úrovních s akcentací důvěryhodnosti poskytovaných dat. Bezpečnost je zajišťována jak na úrovni aplikační vrstvy jednotlivých systémů a jejich modulů, pomocí řízení přístupů, logování, auditovány, tak na úrovni řízení a kontroly správy systémů, sledování výkonu a údržby, bezpečnosti síťové vrstvy, zálohování, zastupitelnosti hardwarových prvků a podobně.
ICZ AMIS*HD vychází ze zkušeností poskytovatele z oblasti regionální a národní interoperability zdravotnických informačních systémů jako je například projekt eMeDocS (výměna zdravotnických informací mezi subjekty kraje Vysočina) a je proto navrhováno tak, aby mohlo být snadno integrováno do regionálních a perspektivně národních interoperabilních projektů. A to jak z hlediska technologického, tak z hlediska procesního. API systému je připraveno na hloubkovou integraci systému třetích stran, minimálně v rozsahu vylistování aktivních ambulancí, časových rozvrhů, zápis, editaci a zrušení objednávky pacienta.
Tam kde je to technologicky přípustné je využito primárně webových technologií, které transformují uživatelské rozhraní do prostředí interpretovaného webovým prohlížečem. Jednotlivé komponenty splňují standardizaci pro webové technologie a nekompilované skripty a mohou být bez potíží interpretovány běžně rozšířenými webovými prohlížeči, které tyto standardy dokáží zpracovat.
Jednotlivé sekce uživatelského prostředí podléhají správě rolí a příslušných workarea – pracovních oblastí. Díky této koncepci uživatelského rozhraní je umožněna cílená distribuce relevantních údajů k rolím a příslušná obsluha není zahlcena irelevantními ovládacími prvky a informacemi.
Řešení je postaveno jako plně modulární systém. Jednotlivé agendy jsou řešeny ve formě samostatných modulů s novým jádrem řešení ADT včetně moderních agend pro výkaznictví. Klinické moduly mohou být nasazovány postupně a to vertikálně (různé typy a šíře funkcionality) i horizontálně (různá klinická pracoviště). Současně je zajištěn souběh se stávajícím řešením.
Pokud je řešení nasazeno v dimenzi multitenantní architektury umožňuje homogenní pohled na zdravotnickou i provozní dokumentaci s podporou simultánní řízené práce nad daty (včetně podpory řešení multi-uživatelské simultánní práce s daty).
Z hlediska koncepce uživatelského rozhraní řešení podporuje simultánní multidimenzionální práci se zdravotnickou dokumentací pacienta v kontextu pracovní rutinní a best-of-practices pro podporu zdravotnických pracovníků. To zahrnuje například podporu současné editace textových dokumentů a práci s laboratorními výsledky, recepty, poukazy, medikací, bez nutnosti vyhledávání pacienta nebo dokumentu. Pokud je s daty pracováno současně více uživateli (i z více pracovišť) je využit situační etalon za účelem zachování konzistence dat a plynulého provozu pracovišť. To umožňuje více uživatelům plynule pracovat s více daty na bází granulární architektury datových zámků.
Uživatel má možnost konfigurovat rozložení a zobrazení dat na obrazovce (skrytí, resp. minimalizace částí obrazovky), filtrace, resp. změna řazení sloupců seznamů (např. dokumentů, žádanek).
Z hlediska celo-ústavních standardů je podstatná funkce nastavitelných povinných položek, resp. povinného rozsahu položek pro libovolné formuláře v celém systému. Po uživateli může být požadováno jak zadání údaje, tak může být automaticky kontrolováno, zda je vkládán údaj odpovídající předpokládané, resp. vyžadované hodnotě. Na problém je uživatel výrazně vizuálně upozorněn.
7.1.1 Hlavní rysy řešení NIS AMIS*HD
Výhody a ojedinělé vlastnosti řešení NIS AMIS*HD spočívají především v následujících rysech:
• Systém je založen na principu implementace semi-procesního přístupu, využívá princip modulárního workflow systému na bázi klinických procesních modelů s elektronickou dokumentací pacientů.
• Systém nativně podporuje procesy klinického rozhodování a implementace klinika pathways v rámci diagnostického i léčebného procesu.
• Systém je plně konfigurovatelný ve všech klíčových oblastech. Pomocí konfiguračních nástrojů s uživatelským rozhraním (ICZ AMIS*HD MediBuilder), který může být součásti dodávky, je možno uživatelsky konfigurovat systém (uživatelsky definované formuláře jak z hlediska obsahu, tak z hlediska vzhledu, přístupových práv, atd. …).
• Systém plně podporuje a respektuje všechna národní specifika a normy České republiky a současně vychází a podporuje požadavky na standardní systém v rámci Evropské unie.
• Systém je vytvořen na bázi nejmodernějších technologických poznatků pro vývoj současných informačních systémů. Je koncipován na principu vícevrstvé architektury (Klient – prezentační vrstva, Aplikační servery – vrstva aplikační logiky a Databáze – vrstva databázového zpracování).
• Systém má standardní nároky na vybavení koncových stanic a podporuje práci na počítačích s operačním systémem Windows ve všech aktuálních verzích, případně pod systémem Android pro části provozované na mobilních zařízeních
• Webová část systému pracuje ve webovém prostředí s podporou HTML5 bez nutnosti instalace dalších přídavných doplňků
• Systém plně akceptuje způsob ovládání podle standardu systému Windows, případně standardu webových aplikací
• Systém plně podporuje integrační standardy a technologické požadavky jako jsou Dasta, HL7, SOA, Web Services
• Všechny části systému komunikují s uživatelem česky a plně podporují CZ kódování a třídění
• Systém obsahuje on-line kontextovou nápovědu v češtině. Obsah nápovědy je vždy platný pro aktuální verzi systému
• Systém obsahuje hierarchicky navržený způsob přidělování přístupových práv, který umožňuje nastavení přístupu do systému a přístupu k jednotlivým částem zdravotní dokumentace pacienta jak skupinově (pro uživatelské role), tak individuálně pro každého uživatele. Počet uživatelských rolí není omezen a záleží pouze na strategii správce systému
• Systém je procesně orientován. Umožňuje vytvoření procesů definovaných správcem systému, zařazení jednotlivých pracovních modulů (pracovních obrazovek) do těchto procesů a následné sledování stavu rozpracovanosti těchto procesů v systému jednotlivými uživateli
• Systém poskytuje široké možnosti kastomizačního nastavení obrazovek, vstupních formulářů a tikových šablon, včetně nastavení povinnosti vyplnění datových položek ve formulářích. Systém také umožňuje správcovským způsobem definovat logické podmínky validace uložení jednotlivých dokumentů a pracovních formulářů vztaženým k ověření jednotlivých vstupních položek (datových polí)
• Systém poskytuje možnost reportingu, jak na úrovni přístupu do systému, tak nad správou dat a jednotlivých částí zdravotní dokumentace pacienta. U každého zápisu nebo změny je možné dohledat - kdo a kdy provedl zápis a poslední změnu záznamu
• Systém je integrován s kompletním důvěryhodným archivem zdravotní dokumentace, který poskytuje široké možnosti řízení dokumentace, ověřování elektronickým podpisem uživatele a sledováním životního cyklu dokumentů (sledování požadované životnosti dokumentů, řízená skartace dokumentů atd.)
7.1.2 Strukrura řešení NIS AMIS*HD
Jádro řešení ICZ AMIS*HD ADT je technologicky orientované na výkon, stabilitu a bezpečnost. Mezi jeho zásadní přednosti patří také nízké systémové nároky. Z hlediska technologie použité při jeho vývoji se jedná o ideální kombinaci nízkých systémových nároků při splnění nejpřísnějších kritérií pro moderní informační řešení. Architektura řešení je postavena na třívrstvém modelu, který plně využívá potenciál webově orientovaných koncových pracovišť postavených na technologii asynchronního přenosu dat AJAX. To znamená nativní podporu mobilních zařízení, otevřenost, multiplatformnost a nízké systémové nároky spolu se snadnou a rychlou implementací i na koncová pracoviště.
Oblast komplexní podpory ambulantního provozu a provozu denních stacionářů podporuje řešení zejména modulem ICZ AMIS*HD Ambulance. Řešení podporuje všeobecnou ambulantní práci s celou paletou potřebných nástrojů. Jedná se o editor nálezů s přístupem ke klíčovým pacientským údajům, žádanky, číselníky. Důležitým prvkem je implementace ambulantního workflow včetně virtuálních waitinglistů (modulární elektronické čekárny), úzce navázané na ICZ AMIS*HD Scheduler (komplexní plánování), podpory práce lékaře i sestry, podpory ambulantních poukazů, výkazů i podpory poloautomatického vykazování pro zdravotní pojišťovny.
Řešení umožňuje obecně vedení zdravotní dokumentace na lůžkovém oddělení. Modul je v přímé návaznosti na modul ICZ AMIS*HD Lůžkový management, díky němuž je možno velmi efektivně přistupovat ke zdravotní dokumentaci pacienta přímo pomocí vizualizované obložnosti pokojů a lůžek. Modul je určen jak lékařům, tak sestrám a pokrývá veškerou agendu lůžkového oddělení, vedené komplexní hospitalizační dokumentace, včetně všech výkazů a statistických agend. Samozřejmou součástí je i podpora standardní lůžkové dokumentace (přijímací zpráva, dekurz, epikríza, podpora vizit, propouštěcí zpráva a další, včetně workflow pro jejich schvalování). Řešení je plně připraveno na provoz s využitím mobilních zařízení na lůžkových odděleních a podporuje funkcionalitu Mobilní vizity. Ve spojení s ICZ AMIS*HD Manažerský dashboarding navíc představuje i silný manažerský nástroj pro řízení provozu lůžkového oddělení z pohledu vedoucích pracovníků.
Oblast plánování a řízení péče zajišťuje modul ICZ AMIS*HD Scheduler. Řešení modulu vychází z nejmodernějších způsobů řízení a organizace práce ve zdravotnických zařízeních. Jeho účelem je plně elektronicky podpořit plánování v rámci provozu zdravotnického zařízení. V plně grafickém prostředí lze snadno plánovat a řídit objednávky pacientů, provoz operačních sálů či dalších oblastí.
ICZ AMIS*HD Scheduler pracuje s různým stupněm uživatelských oprávnění a může být proto lehce přístupný pro uživatele vykonávající různé činnosti ve zdravotnickém zařízení. Řešení umožňuje plánování objednávek pacientů na ambulantních pracovištích, plánování hospitalizací, operační program či plánování alokace přístrojové techniky (např. rehabilitační vybavení).
Webové rozhraní také umožňuje autentizaci uživatelů prostřednictvím identity MojeID (XXX.XX) a také dle standardů eIDAS (nařízení č. 910/2014 Evropského parlamentu a rady o elektronické identifikaci).
Jednotný, rychlý, operativní a jednoduchý (z hlediska uživatelské přívětivosti) pohled na dokumentaci pacienta umožňuje modul ICZ AMIS*HD Přehled dokumentace pacienta. Je navržen v souladu s moderním trendem integrace pacientských dat s důrazem na intuitivní a rychlý přístup zdravotníků k informacím na nichž záleží. V graficky orientovaném a ergonomickém prostředí je možno plynule procházet veškerou pacientskou dokumentaci. Modul umožňuje plošný (všechna pracoviště, zdravotnická zařízení) pohled na dokumentaci, včetně pohledu historického, filtrace, změna řazení, tabulkový (řádkový) pohled, vyhledávání, atd.
Intuitivní přístup a rychlou orientaci v rozsáhlé pacientské dokumentaci usnadňuje možnost hierarchického zobrazení dat - modul může jednoduchým přepnutím mezi záložkami uživateli zobrazit veškerou pacientskou dokumentaci uspořádanou:
• dle jednotlivých ambulantních nebo hospitalizačních případů pacienta (např. ambulantní karty, chorobopisy apod.),
• nebo dle kategorie dokumentace (bez ohledu na původní příslušnost k případu) – např. zobrazení všech anamnéz, diagnóz, výsledků vyšetření (komplementárních, konziliárních atd.), epikríz, přijímacích a propouštěcích zpráv, ambulantních nálezů, operačních a jiných protokolů, vypsaných receptů, pracovních neschopností, žádanek atd.
Multimediální dokumentaci podporuje modul ICZ AMIS*HD Multimediální dokumentace. Řešení umožňuje efektivní a jednoduché připojení jakéhokoli binárního dokumentu (fotografie, video, zvuk, PDF, naskenovaný dokument, …) k pacientské dokumentaci.
Modul umožňuje jak vkládání multimediálních dat k pacientské dokumentaci, tak vyhledávání, katalogizaci, filtrování. Součástí je i multimediální prohlížeč umožňující bleskový náhled většiny běžných multimediálních formátů, což ještě více urychluje orientaci v dokumentech bez zbytečného otevírání externích aplikací.
Oblast provozu operačních sálů (včetně jednodenní chirurgie) podporuje ICZ AMIS*HD Operační sály. Obsahuje plnohodnotnou agendu operačních sálů včetně plánování operativy, elektronického operačního a anesteziologického protokolu, které jsou procesně svázány. Modul implementuje operační workflow, zaměřené na podporu celého procesu operačního zákroku a předávání klíčových dat (předoperační vyšetření, anesteziologický protokol, operační protokol, ZUM, ZULP) příslušným rolím (žádající lékař, operatér, asistenti, anesteziolog, instrumentáři...). Obsahuje i prvky pacientské bezpečnosti (např. evidence nástrojů) a je úzce provázán s výkaznými a ekonomickými funkcemi.
Řešení ICZ AMIS*HD dále disponuje řadou dalších pokročilých funkcí. Mezi zásadní patří podpora elektronické medikace včetně systém pro kontrolu lékových interakcí, podporu sledování trendů užívání antibiotik a kontrolu preskripce. Řešení dále nabízí pokročilý aparát pro práci s laboratorními výsledky včetně vizualizace dat a trendů.
Systém ICZ AMIS*HD splňuje obecné nařízení GDPR na ochranu osobních údajů, včetně potřebných výstupů (správa a logování uživatelů, logování všech činností prováděných nad daty vč. storna, přihlašování a odhlašování ze systému včetně automatického odhlášení).
Nabízené řešení splňuje bez výjimky v plné šíři všechny požadavky uvedené v příloze č.1 Technická specifikace zadávací dokumentace a pod č. P.1 - P.818. Jako potvrzení vkládáme níže tabulky Zadavatele doplněné o sloupec s vyjádřením, zda nabízené řešení splňuje či nesplňuje požadovaný parametr.
7.1.3 Plnění požadavků zadávací dokumentace z hlediska obecných vlastností
Systém NIS AMIS*HD plní požadavky zadávací dokumentace podle následující tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.1 | Řešení bude v souladu s legislativou uvedenou v kapitole 6.2 ZD – Legislativa. | ANO |
P.2 | Modernizovaný 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). | ANO |
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. | ANO |
P.4 | Systém musí obsahovat uživatelskou a administrátorskou příručku v elektronické podobě vždy v aktuální platné verzi s vazbou na aktuální verzi systému. | ANO |
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. | ANO |
P.6 | Řešení musí podporovat na straně klienta práci v maximální míře využití tenkého klienta – využívající internetové prohlížeče a tím dostupnost na různých typech koncových zařízení. | ANO |
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 – viz kap. 6.5.7), 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. | ANO |
P.8 | Zaručená perspektiva rozvoje a podpory je minimálně po dobu dalších 10 let od uvedení do provozu v rámci NBv | ANO |
P.9 | Řešení musí být v souladu a podporovat mezinárodní a národní standardy. | ANO |
Systémové požadavky | ||
P.10 | Moduly klinické části informačního systému musí být realizovány nad centrální relační databází, ve které budou uložena veškerá data o pacientech, včetně multimediálních dat a jejich popisu. | ANO |
P.11 | Musí být realizovány třívrstvou nebo více vrstvou architekturou s tím, že v rámci databázového serveru není přípustná realizace aplikační logiky. Komunikace mezi serverovou a klientskou vrstvou bude probíhat v šifrované podobě (HTTPS) | ANO |
P.12 | Musí disponovat plnohodnotným grafickým uživatelským rozhraním | ANO |
P.13 | Musí být na klientské stanici bez instalační | ANO |
P.14 | Musí být na klientské straně provozován jako lehký klient v internetovém prohlížeči | ANO |
P.15 | Musí umožňovat autentizace uživatele s využití technologie Single Sign On (SSO). | ANO |
P.16 | Musí umožňovat odhlášení uživatele s využití technologie Single LogOut (SLO). | ANO |
P.17 | Řešení musí být v souladu a podporovat mezinárodní a národní standardy jako např. HL7, XXXXX, MKN 10 a další. V případě MKN 10 by řešení mělo dle potřeby umožňovat jednoduchou integraci dalších klasifikací. | ANO |
Uživatelské prostředí (Grafické prostředí) | ||
P.18 | Uživatelské prostředí musí být provozovatelné v prostředí Microsoft Windows (viz výchozí stav uvedený v kap. 6.5.6 ZD – Technologie využívané objednatelem | ANO |
P.19 | Možnost ovládání pomocí klávesových zkratek, minimalizace nutnosti použití myši. | ANO |
P.20 | Systém musí podporovat přerušení práce s pokračováním ve stejném místě. Tj. při odhlášení je k danému uživateli uložen aktuální stav obsahující minimálně pracoviště, na kterém byl uživatel nastaven před odhlášením, modul, ve kterém byl, a pacient, na kterém pracoval. Po přihlášení se musí NIS nastavit na stejné pracoviště, do stejného modulu a vybrat stejného pacienta. | ANO |
P.21 | Systém musí umožnit odhlášení uživatele v rozpracovaném stavu dokumentace ve formě konceptu, což jsou data rozpracovaná ve formuláři, aniž by musel uživatel formulář uložit a tím rozpracovaná data zpřístupnit ostatním uživatelům. Po opětovném přihlášení uživatele i na jiném pracovišti (koncové stanici) je uživateli tento koncept obnoven pro další práci – dopracování a uložení jako platná data nebo zrušení konceptu | ANO |
P.22 | Klinické moduly musí umožňovat jednoduchý pohled na veškerou dokumentaci pacienta – plošně (přes všechna oddělení) i časově (do historie). Pro potřeby náhledu na veškerou dokumentaci pacienta z integrovaných systémů NIS poskytne webovou stránku, která s příslušnými parametry (identifikace pacienta) a identifikací uživatele poskytne náhled pro integrované systémy. | ANO |
P.23 | Klinické moduly musí při práci s pacientem musí být na pracovní ploše vždy k dispozici jeho základní údaje s možností jejich editace. | ANO |
P.24 | Možnost vyhledávání a řazení pacientů, žádanek, výsledků a dalších seznamů dle zvolených údajů (jméno, příjmení, identifikace, diagnózy apod.). | ANO |
P.25 | Fulltextové vyhledávání v systému (ve všech modulech NIS). | ANO |
P.26 | U význačných diagnóz (např. diabetes), možnost grafického zvýraznění pacienta s danou diagnózou, jeho žádanek, výsledků a dalších údajů. Cílem je upozornění personálu na pacienta s takto významnou diagnózou a možnost jeho přednostního ošetření/vyšetření. | ANO |
P.27 | V textovém editoru umožnit formátování textu (volba písma, podtržení, tučnost, kurzíva atd.). | ANO |
P.28 | Textový editor umožňuje a používání uživatelem předdefinovaných textů s možností vkládání pomocí klávesových zkratek. | ANO |
P.29 | Textový editor zdravotnické dokumentace musí umožňovat zkopírování poslední zprávy do nově vytvářených zpráv. | ANO |
P.30 | Možnost ukládání multimediálních dat, jako jsou obrázky, video, zvuk a jiné binární a multimediální přílohy. | ANO |
P.31 | Systém musí umožnit individuální nastavení pracovní plochy: 1. Podporovat práci ve více oknech současně. 2. Možnost změny zobrazených atributů v seznamech (pacientů, žádanek apod.), možnost třídění dle různých zobrazených atributů. | ANO |
P.32 | 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). | ANO |
P.33 | Při práci s pacientem musí být na pracovní ploše vždy k dispozici jeho aktuální údaje, včetně zvlášť významných údajů (CAVE, např. kardiostimulátor, infekčnost, špatný sluch, zrak, imobilní pacient apod.), upozornění apod. s možnost vstupu do úpravy těchto údajů. | ANO |
P.34 | U jednotlivého pacienta může být zároveň editováno více dokumentů/zpráv různých typů bez nutnosti uzavírat rozepsaný dokument (např. při psaní ambulantního nálezu moci současně zadat recept, žádanku atp.).. | ANO |
P.35 | Uživatel musí mít možnost dostávat on-line zprávy o určitých událostech (např. o příchodu nálezu, žádosti o konzilium atd.). Zobrazení zpráv v NIS (nástěnka), případně dle nastavení uživatele notifikace emailem nebo SMS zprávou. Možnost nastavit i více emailů a telefonních čísel, kam budou notifikace odesílány. | ANO |
P.36 | Systém umožňuje vytváření grafů z vybraných dat (např. naměřené údaje z přístrojů a laboratorní hodnoty). | ANO |
P.37 | Možnost vkládání pracovních poznámek, které nebudou součástí zdravotnické dokumentace pacienta. Možnost dodatečného zařazení poznámky do zdravotnické dokumentace pacienta. | ANO |
P.38 | Upozorňování na došlé výsledky a konzilia. | ANO |
P.39 | Všechny části systému musí být dokumentovány (musí být dodán popis jejich fungování a obsluhy včetně návazností na jiné části) Za vhodnou formu považujeme např. Příručku uživatele (vždy daného modulu). Dokumentace systému musí být obsažena i v IS (nápověda). Vše v českém jazyce. | ANO |
Multimediální a textová dokumentace | ||
P.40 | Připojování multimediální a textové dokumentace, tj. jakéhokoli binárního dokumentu (fotografie, video, zvuk, PDF, naskenovaný dokument, …) k pacientské dokumentaci a to včetně datumu vložení do NIS. | ANO |
P.41 | Vkládání multimediálních dat a textové dokumentace k pacientské dokumentaci, včetně vyhledávání, katalogizace a filtrování. | ANO |
P.42 | Multimediální prohlížeč umožňující náhled většiny běžných multimediálních nebo dokumentových formátů – min. • Obrázky: PNP, JPEG, BMP, GIF, TIFF, TGA • Video: AVI, MPEG-2, MP4, MOV, WMV, MKV • Zvukový záznam: MP3, WMA, WAV • Dokumenty: PDF | ANO |
P.43 | Vložení multimediálních a textových příloh k dokumentaci pacienta | ANO |
P.44 | Možnost nastavení omezení přístupu k jednotlivým multimediálním a textovým přílohám. | ANO |
P.45 | Pořízení fotografie z mobilního zařízení a vložení do nálezu nebo dekurzu. | ANO |
P.46 | Možnost zobrazení všech multimediálních a textových příloh k pacientovi. | ANO |
P.47 | Vložení videa do nálezu nebo dekurzu. | ANO |
Tiskové výstupy | ||
P.48 | Tiskové výstupy musí být individuálně konfigurovatelné a přizpůsobitelné administrátorem. Musí umožňovat, aby správce nemocnice mohl tvořit vlastní tiskové sestavy, k dispozici grafický návrh designu tiskových sestav | ANO |
P.49 | 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. | ANO |
P.50 | Systém musí umožnit před tiskem náhled na vzhled tištěného dokumentu. | ANO |
P.51 | Možnost tisku jak na tiskárnu, tak do PDF. | ANO |
P.52 | Systém musí automaticky vybrat z více tiskáren u pracovní stanice v závislosti na tiskové úloze – dokumentace na primární tiskárnu, štítky na tiskárnu čárových kódů. Systém musí umožnit správci nastavení konkrétních tiskáren pro konkrétní účel a následně musí tisknout na určené tiskárny. | ANO |
Řízení přístupu k aplikaci (přihlášení) | ||
P.53 | Navržené řešení musí být propojeno na systém správy uživatelů (Identity Management – IDM) 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)). | ANO |
P.54 | Možnost volby způsobu autentizace uživatele přes IdM nebo s využití technologie Single Sign On. | ANO |
P.55 | Automatické odhlášení nečinného uživatele. Doba nečinnosti musí být nastavitelný parametr. | ANO |
P.56 | Možnost změny hesla pro uživatele. | ANO |
Řízení přístupů k aplikačním službám | ||
P.57 | Požadujeme hierarchické nastavování přístupových práv dle rolí. | ANO |
P.58 | Možnost definovat uživatelské role (počet, typ) dle potřeb organizace. | ANO |
P.59 | Možnost omezení přístupu pouze na pacienty vlastního pracoviště nebo na konkrétní typ dokumentace. | ANO |
Jazyková mutace | ||
P.60 | Uživatelské rozhraní komunikuje v jazyce českém, pro práci správců a administrátorů se u definovaných systémových komponent připouští komunikace v jazyce anglickém. | ANO |
Další významná legislativa a normy | ||
P.61 | Soulad s legislativou uvedenou v kap. 6.2.2 – Legislativa specifická pro zdravotnická zařízení | ANO |
P.62 | Systém musí splňovat ustanovení vyhlášky č. 98/2012 Vyhláška o zdravotnické dokumentaci a její novelizaci, vyhlášku 127/2018 Sb. v aktuálním znění | ANO |
P.63 | 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ů. | ANO |
P.64 | Xxxxxx 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í. | ANO |
P.65 | Možnost tisku legislativně případně nemocnicí požadovaných dokumentů (společné dokumenty) min. v následujícím rozsahu: 1. informovaný souhlas 2. poučení před výkonem 3. záznamy o osobách blízkých 4. souhlas s poskytováním informací o stavu pacienta 5. souhlas s pořízením a použitím obrazových snímků a obrazových a zvukových záznamů 6. souhlas s použitím omezovacích prostředků 7. negativní reverz 8. oznámení o převzetí do péče bez souhlasu pacienta 9. oznámení o omezení způsobilosti řízení motorových vozidel 10. externí žádanka na MR 11. Dále dokumenty uvedené v kap. 6.4.2 – Formuláře využívané v NBv Jednotlivé kliniky a oddělení mohou mít i specifické dokumenty, tyto dokumenty jsou uvedeny v příslušných kapitolách. | ANO |
P.66 | Řešení musí umožnit zadokumentování prohlášení o odmítnutí zdravotního výkonu/hospitalizace prostřednictvím formuláře. | ANO |
Elektronická zdravotnická dokumentace | ||
P.67 | Řešení musí umožnit vést zdravotnickou dokumentaci v elektronické formě v souladu s nařízením eIDAS a umožnit postupný přechod na vedení zdravotnické dokumentace v elektronické podobě. | ANO |
Sledování nežádoucích událostí | ||
P.68 | Možnost záznamu a evidence nežádoucích událostí včetně zaznamenání údajů o nápravných opatřeních. | ANO |
P.69 | Evidence ve zdravotnické dokumentaci pacienta (chorobopis, ambulantní záznam atd.). | ANO |
P.70 | Možnost evidování události v systému v rozsahu min. požadovaném UZIS tak, aby bylo následně možné z NIS automatizovaně předávat do Národního systému hlášení nežádoucích událostí přes Systém hlášení | ANO |
nežádoucích událostí (SHNU). Viz indikátory kvality dle SHNU, Věstník 7/2018 Sledování NU na lokální úrovni. | ||
Infekce spojené se zdravotní péčí (IZP) | ||
P.71 | Evidence a vyhodnocování nozokomiálních infekcí, ve vazbě na výsledky mikrobiologických vyšetření. Zobrazování a výběr podle kritérií: min. dle druhů nákaz, podle typu bakteriálního osídlení té které nákazy, členění dle organizačních jednotek, času. Možnost automatického zasílání emailu odpovědným osobám při zápisu nozokomiální infekce. | ANO |
P.72 | Možnost vynucení zadání nozokomiální infekce při propuštění pacienta. | ANO |
P.73 | Tvorba a možnost tisku následujících dokumentů: 1. Evidenční list nozokomiální infekce – vzor je součástí směrnice, bude předána při zahájení dodávek. 2. Hlášení na Krajskou hygienickou stanici – požadavky vyplývají z legislativy. Dokumenty je nutné zpracovávat plně elektronicky, archivovat s možností tisku. | ANO |
Využití omezovacích prostředků | ||
P.74 | Záznam využití omezovacích prostředků u pacienta, možnost zaznamenat na všech odděleních. | ANO |
P.75 | Evidence využití omezovacích prostředků dle oddělení, možnost vytváření tiskových výstupů a statistik (dle typů, oddělení, za celou nemocnici). | ANO |
Ostatní obecné požadavky | ||
P.76 | Identifikace pacientů čárovým kódem. Tisk čárových kódů z NIS pomocí tiskáren čárových kódů a čtení náramků s čárovými kódy pomocí čteček čárových kódů. Štítek bude nalepen na opětovně použitelný náramek pacienta. | ANO |
P.77 | Možnost tisku nejen čárového kódu, ale i doplňujících informací: 1. u pacienta nebo vzorků pacienta: jméno a příjmení pacienta, případně identifikaci pacienta 2. u léků a materiálu: název, identifikační údaje, případně množství (včetně jednotky) 3. u přístrojů: název a identifikační údaje přístroje | ANO |
P.78 | Možnost tisku průvodních identifikačních štítků pro papírovou dokumentaci. | ANO |
P.79 | Čtení čárových kódů (pacient, ZUM, ZULP) a vyhledání dokumentace pacienta, přiřazování ZUM, ZULP a přístrojů do dokumentace pacienta. | ANO |
P.80 | Systém musí být funkční na min. konfiguraci pracovních stanic uvedených v kap. 6.5.7 – Pracovní stanice uživatelů. | ANO |
P.81 | Systém musí umožňovat integraci systému pro pořizování textových dat i pomocí diktování a převodu mluveného slova na text. | ANO |
P.82 | Možnost změny vyšetřujícího lékaře. | ANO |
P.83 | Možnost pro správce zaslat a zobrazit notifikaci uživatelům o významných událostech/situacích (např. nefunkčnost eRecept apod.). | ANO |
P.84 | Systém musí obsahovat tzv. nástěnku, na které budou zobrazována všechna obdržená upozornění a notifikace. | ANO |
7.2 Elektronická zdravotnická dokumentace (EZD)
Vedení elektronické zdravotní dokumentace je základním požadavkem a vodítkem, které prolíná napříč všemi moduly dodávaného systému.
Systém umožňuje, aby nemocnice vedla veškerou zdravotnickou dokumentaci pacienta jako čistě elektronickou, tj. v jen elektronické podobě.
7.2.1 Struktura zdravotnické dokumentace
Všechny moduly systému pořizují dokumenty strukturovaně a v takové formě formě, která dovoluje připojení elektronického podpisu.
7.2.2 Plnění požadavků zadávací dokumentace pro vedení strukturované dokumentace
Nabízené řešení plní všechny požadované funkcionality podle následující tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.85 | Možnost vedení zdravotnické dokumentace v elektronické podobě s využitím uznávaného elektronického podpisu/pečetě a časových razítek v souladu s nařízením eIDAS. | ANO |
P.86 | Textová EZD musí být ve formátu PDF/A. | ANO |
P.87 | Musí být zajištěno řízení životního cyklu el. dokumentů, tj. od podepsání/pečetění, případně razítkování časovým razítkem, archivace dokumentu včetně evidenčních, popisných a skartačních metadat v návaznosti na archiv zdravotnické dokumentace (viz kapitola 3.3.14 – Dlouhodobý bezpečný archiv elektronické zdravotnické dokumentace (Archiv EZD)), který zajišťuje ověřování podpisů/pečetí a časových razítek, prodlužování platnosti dokumentů, až po řízenou skartaci. | ANO |
P.88 | Musí být zavedeny elektronické identifikátory dokumentů EZD dle platné legislativy | ANO |
P.89 | Dokumenty EZD musí být podepisovány uznávaným elektronickým podpisem, splňujícím příslušnou technickou normu (PAdES). | ANO |
P.90 | Možnost podepisování pacienta prostřednictvím biometrického podpisu na tabletech podporujících biometrický podpis v souladu s legislativou. | ANO |
P.91 | Možnost využívání časových razítek pro osvědčení času podpisu dokumentace. | ANO |
P.92 | Musí být zajištěno zpracování a ukládání dokumentů EZD včetně metadat do dlouhodobého důvěryhodného archivu zdravotnické dokumentace (viz kapitola 3.3.14 – Dlouhodobý bezpečný archiv elektronické zdravotnické dokumentace (Archiv EZD)) | ANO |
P.93 | Podpora procesu elektronizace dokumentace v tištěné podobě. Pokud bude vyžadován podpis jiné osoby (např. pacienta) bez elektronického podpisu a nebude možné využít ani biometrický podpis, 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 zdravotnického zařízení, který provede konverzi do elektronické formy a elektronicky podepíše. Jedná se např. o informovaný souhlas. | ANO |
P.94 | Musí být zajištěno vybavení (načtení) uloženého dokumentu z Archívu EZD a jeho zpřístupnění uživateli v NIS. | ANO |
P.95 | Musí být zajištěna skartace nebo anonymizace primárních dat v NIS, pokud došlo ke skartaci dokumentu v Archívu EZD. | ANO |
P.96 | 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. | ANO |
P.97 | Možnost tvorby diagnostických souhrnů dle hlavních i vedlejších diagnóz. | ANO |
P.98 | Možnost zaslat zprávy (propouštěcí, ambulantní) praktickému lékaři: 1. lékařům, využívajících eMeDocS nebo některý ze systémů pro distribuci elektronické zdravotnické dokumentace, který je propojen s eMeDocS, zasílat zprávy prostřednictvím eMeDocS. 2. Lékařům využívajícím výměnný systém MEDICAL NET, zasílat zprávy prostřednictvím tohoto systému. 3. Možnost exportu vybraných zpráv do adresáře praktického lékaře (volbou z číselníku) na portále nemocnice (adresář na portále nemocnice zajistí objednatel). 4. Ostatním lékařům bude zasíláno jiným kanálem mimo NIS (datové schránky, pošta). | ANO |
7.3 Integrační vrstva (sběrnice ESB)
Integrační vrstva plní funkci vnějšího komunikačního rozhraní KIS se systémy a službami externího prostředí. Jedná se především o komunikaci se službami systému eHealth JMK (eMeDocS), službami IDRR a státem garantovanými identifikační a autentizační metodami NIA. Součástí integrační vrstvy je sběrnice služeb (Enterprise Service Bus – ESB), která zprostředkovává komunikace a interakce mezi službami vnějšího prostředí a službami KIS. V rámci integrační vrstvy je provozován také komunikační uzel projektu eMeDocS, prostřednictvím jehož služeb je realizováno napojení na eHealth systém JMK (eMeDocS).
7.3.1 Plnění požadavků zadávací dokumentace pro integrační vrstvu
Integrační sběrnice bude plnit následující požadavky dle ZD:
# | Požadavek | Splňuje (ANO/NE) |
Obecné požadavky na ESB | ||
P.99 | Systém musí mít jednotné komunikační prostředí pro přenos zpráv, inteligentní routing, orchestraci, logování, zprostředkování služeb. | ANO |
P.100 | Všechny části systému musí být navzájem integrovány a modulárně koncipovány. | ANO |
P.101 | Systém musí být založen na principu aplikačního kontejneru umožňující vývoj, nasazení a provoz služeb dle pravidel architektury orientované na služby (dále také Service Oriented Architecture nebo SOA). | ANO |
P.102 | Systém musí poskytovat služby v následujících oblastech: • Běhové prostředí na úrovni aplikačního kontejneru • Bezpečné a důvěryhodné doručování zpráv mezi komponentami • Vytváření, transformace, směrování a předávání zpráv | ANO |
• Aplikační programové rozhraní | ||
P.103 | Všechny komponenty systému musí být možné provozovat v běhovém prostředí ESB. | ANO |
P.104 | Všechny komponenty systému musí využívat služeb logování a dynamické konfigurace z běhového prostředí ESB. | ANO |
Běhové prostředí ESB | ||
P.105 | Systém musí umožňovat nasazení, modifikaci a odinstalování komponent za běhu systému. | ANO |
P.106 | Systém musí umožnovat dynamickou konfiguraci a modifikaci funkce komponenty za běhu kontejneru i komponenty, které se konfigurace týká. | ANO |
P.107 | Systém musí umožňovat automatickou instalaci komponent a všech jejich závislostí na základě změny konfigurace. | ANO |
P.108 | Součástí systému musí být modul poskytující autentizační a autorizační funkce všem komponentám ESB. | ANO |
P.109 | Součástí systému musí být modul poskytující funkce logování a dynamické konfigurace všem komponentám ESB. | ANO |
Bezpečné a důvěryhodné doručování zpráv mezi komponentami ESB | ||
P.110 | Komponenta systému pro doručování zpráv musí podporovat přechodné nebo stálé doručování zpráv (persistentní ukládání zpráv v případě krátkodobé nedostupnosti klienta), transakční doručování, kontrolu a vynucování TTL zpráv. | ANO |
P.111 | Součástí komponenty pro doručování zpráv musí být administrátorské rozhraní pro lokální i vzdálený dohled. | ANO |
Vytváření, transformace, směrování a předávání zpráv | ||
P.112 | Komponenta systému pro vytváření, transformace, směrování a předávání zpráv musí dodržovat pravidla Enterprise Integration Patterns (EIP). | ANO |
P.113 | Komponenta systému pro vytváření, transformace, směrování a předávání zpráv musí být schopna integrovat komunikační uzel eMeDocS pro připojení k systému pro výměnu zdravotnické dokumentace projektu eMeDocS (viz kap. 3.3.4.1). | ANO |
P.114 | Možnosti nastavit prioritu zpráv individuálně, nebo prostřednictvím fronty. | ANO |
P.115 | Možnost specifikovat u odesílaných zpráv dobu jejich platnosti (time-to- Live), u zpráv, jejichž platnost je neomezená tuto dobu nespecifikovat. | ANO |
P.116 | Možnost šifrování a podepisování zpráv. | ANO |
Aplikační programové rozhraní (API) | ||
P.117 | Komponenta systému API musí podporovat komunikační protokoly SOAP, XML/HTTP, RESTful http. | ANO |
P.118 | Komponenta systému API musí podporovat transportní protokoly HTTP, JMS a JBI. | ANO |
P.119 | Komponenta systému API musí podporovat standardy definované v oblasti webových služeb, a sice SOAP, WS-I Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, WS-Security, WS-SecurityPolicy, WS- SecureConverstation a WS-Trust. | ANO |
P.120 | Komponenta systému API musí obsahovat podporu pro vývoj API na základě definice rozhraní WSDL. | ANO |
P.121 | Komponenta systému API musí umožňovat vytváření API pro binární a proprietární protokoly, které nejsou založeny na standardu XML. | ANO |
Integrace | ||
P.122 | Systém bude zajišťovat napojení NIS NBv na služby systému eHealth JMK, prostřednictvím kterého bude umožněna výměna elektronické zdravotnické dokumentace s dalšími subjekty a systémy ZZ, NIX ZD a NCP v souladu s požadavky v kap. 3.3.4.1 – NIS NBv – napojení na eHealth systém kraje (eMeDocS). | ANO |
P.123 | Systém bude zajišťovat napojení NIS NBv na služby IDRR v souladu s požadavky v kap. 3.3.4.2 - IDRR NIS NBv – napojení na IDRR, pokud bude IDRR v době implementace legislativně a technicky k dispozici. | ANO |
P.124 | Pro zajištění efektivní implementace komunikace mezi NIS NBv a národními systémy „elektronického zdravotnictví“ musí být integrační vrstva připravena podporovat Standardy elektronického zdravotnictví platných v době dodávky a následně bude NIS NBv udržován v souladu s těmito standardy, např. | ANO |
P.125 | • podpora národního datového standardu DASTA ve verzích a v rozsahu komunikačních rozhraní specifikovaných v této zadávací dokumentaci, | ANO |
P.126 | • podpora PIX IHE profilu (Patient Identifier Cross Referencing), a to transakční součásti profilu PIX: Patient Identity Feed, PIX Query, PIX Update Notification v návaznosti na Centrální registr pacientů (viz kap. 3.3.18), | ANO |
P.127 | • podpora XDS IHE profilu (Cross-Enterprise Document Sharing) ve vazbě na Dlouhodobý bezpečný archiv elektronické zdravotnické dokumentace (Archiv EZD) – (viz kap. 3.3.14) poskytující funkce „document registry a dokument repozitory“ dle terminologie IHE XDS), | ANO |
P.128 | • předávání Patient Summary (dle GUIDELINES ON MINIMUM / NONEXHAUSTIVE PATIENT SUMMARY DATASET FOR ELECTRONIC EXCHANGE INACCORDANCE WITH THE CROSS-BORDER DIRECTIVE 2011/24/EU) v dokumentu HL7 CDA nebo DASTA 4 (dle platné vyhlášky Ministerstva zdravotnictví nebo specifikace publikované na xxx.xxxxx.xx). | ANO |
7.4 Napojení na externí systémy
Součástí dodávky NIS AMIS*H/HD je napojení a integrace na řadu externích systémů. V následujících kapitolách jsou tyto požadavky podrobně popsány.
7.4.1 Napojení na eHealth systém kraje (eMeDocS)
Součástí dodávky NIS AMIS*H/HD bude napojení na eHealth systém Jihomoravského kraje (eMeDocS) v následujícím rozsahu funkcionalit:
# | Požadavek | Splňuje (ANO/NE) |
P.129 | Napojení na eHealth systém Jihomoravského kraje (viz kap. 6.5.2.9 – eHealth systém Jihomoravského kraje (eHealth JMK / eMeDocS) | ANO |
P.130 | Vyhledání životních údajů pacienta (z jiného ZZ a ZZS), včetně náhledů do ambulantních a hospitalizačních zpráv (Emergency card – EC). | ANO |
P.131 | Přijetí výjezdové zprávy ZZS do nemocnice. | ANO |
P.132 | Náhled na ambulantní a hospitalizační zprávy (z jiného ZZ a při výjezdu ZZS) | ANO |
P.133 | Sdílení informací o dostupnosti volných lůžek pro urgentní příjem (on-line přehled dostupného lůžkového fondu). | ANO |
P.134 | Předání ambulantní a hospitalizační zprávy do jiných ZZ nebo na ZZS. | ANO |
P.135 | Vyžádání ambulantního vyšetření z jiného ZZ. | ANO |
P.136 | Předání výsledků ambulantního vyšetření do žádajícího ZZ. | ANO |
P.137 | Součástí projektu je dodávka a implementace adapteru NIS zajišťujícího napojení na komunikační uzel projektu eMeDocS v rozsahu uvedených služeb, včetně dodávky komunikačního uzlu projektu eMeDocS. | ANO |
P.138 | V rámci integrace na eHealth JMK musí být splněny následující požadavky napojení vyžadované ze strany eHealth JMK pro napojení na NCP eH a NIX ZD: 1. Poskytování dat do eHealth JMK (eMeDocS) v rozsahu vyžadovaném ze strany NCP eH dle popisu implementace API národního konektoru NCPeH dle specifikace v příloze č. 4 na následující adrese: xxxxx://xxx.xxxxx.xx/xxxxxxxx. 2. Poskytování dat do eHealth JMK (eMeDocS) v souladu s požadavky na vytvoření a ověření vzorového souboru pacientského souhrnu (PS) ve formátu HL7 (CDA L3, ev. CDA L1) – vzory viz xxxxx://xxx.xxxxx.xx/xxxxxxxxxx_xxxxxx. 3. Poskytování dat do eHealth JMK (eMeDocS) v souladu s požadavky na PS CDA L1 a L3. Po splnění uvedených požadavků bude Objednatelem od provozovatele NCP eH vyžádán protokol ověřující správnou realizaci uvedených požadavků a prokazující naplnění funkcionality interoperability dodávaného systému. Oprávněné výhrady provozovatele NCP eH budou vadou systému a budou dodavatelem odstraněny v rámci záruky s tím, že za odstranění bude považováno získání protokolu od provozovatele NCP eH. | ANO |
7.4.2 Napojení na IDRR
Ministerstvo zdravotnicí připravuje Informační datové resortní rozhraní (IDRR), které bude sloužit pro poskytování centrálních služeb v oblasti zdravotnictví (např. zdravotnické registry).
Pokud bude v době realizace projektu připraveno Informační datové resortní rozhraní (IDRR), bude napojení NIS NBv na poskytované služby realizováno přes toto rozhraní.
V každém případě bude dodávaný systém plnit následující požadavky v oblasti napojení na IDRR:
# | Požadavek | Splňuje (ANO/NE) |
P.139 | Součástí dodávky je vybudování komunikačních služeb integrační vrstvy, které budou interním informačním systémům Zadavatele poskytovat služby komunikace se službami garantovaných státem prostřednictvím informačního a datového resortního rozhraní (IDRR) rezortu zdravotnictví. | ANO |
Integrace bude součástí dodávky 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 trvání servisní smlouvy, zavazuje se dodavatel provést realizaci uvedených integrací v rámci servisních služeb. | ||
P.140 | Rozsah podporovaných služeb IDRR (bude-li to legislativně a technicky možné): • využívání informací z registru obyvatel (ROB) • využívání informací z registru územní identifikace, adres a nemovitostí (RÚIAN) • využívání informací z registru poskytovatelů zdravotních služeb (NRPZS) • využívání informací z registru zdravotnických pracovníků (NRZP) | ANO |
7.4.3 Napojení na NIA
Součástí projektu je vytvoření podpory využívání státem garantovaných identifikačních a autentizačních metod Národní identitní autority (NIA). Dodávaný systém bude plnit všechny požadované a níže uvedené funkcionality tohoto napojení:
# | Požadavek | Splňuje (ANO/NE) |
P.141 | Vytvoření podpory využívání státem garantovaných identifikačních a autentizačních metod NIA. Poskytování metod NIA prostřednictvím integrační vrstvy bude součástí projektu jen v případě, kdy v době realizace projektu bude využívání služeb NIA technicky, provozně a legislativně možné pro poskytovatele zdravotních služeb. Podporované funkce jsou následující: | ANO |
P.142 | Získání ověřené identity občana/pacienta na národní úrovni. | ANO |
P.143 | Autentizace uživatele. | ANO |
P.144 | Jednotné místo pro přístup uživatelů (pacientů) prostřednictvím internetu k aplikacím, které mohou být v budoucnu implementovány. | ANO |
7.5 Centrální příjem
7.5.1 Plnění požadavků zadávací dokumentace na Centrální registr pacientů
Nabízené řešení plní požadavky zadávací dokumentace dle níže uvedeného rozsahu požadavků:
# | Požadavek | Splňuje (ANO/NE) |
P.145 | Centrální příjem je v NIS NBv řešen pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.146 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
P.147 | Umožnit vedení samostatných částí zdravotnické dokumentace v čistě elektronické formě, včetně všech nezbytných dokumentů (např. informované souhlasy apod.). | ANO |
P.148 | Při příjmu pacienta od jiného poskytovatele zdravotních nebo sociálních služeb („subjekt“) nebo propuštění pacienta k jinému poskytovateli zdravotních nebo sociálních služeb, zaznamenání tohoto údaje, vytvoření číselníku, ze kterého bude prováděn výběr subjektu s možností přidat nový subjekt v době zadání. | ANO |
P.149 | Při příjmu pacienta zadávání údajů nezbytných pro automatizované vytváření ročního výkazu činnosti poskytovatele ZS. Jedná se min. o kategorizaci úrazů a informace, zda byl pacient pod vlivem alkoholu nebo drog. Údaje musí být zaznamenány do dokumentace pacienta tak, aby bylo možné dle těchto údajů vyhledávat a vytvářet statistiky, výstupy a požadovaného výkazu bez nutnosti úpravy dat uživatelem. Údaje musí být možné doplnit na ambulancích, pokud dojde jejich změně. | ANO |
7.6 Ambulance
7.6.1 Plnění požadavků zadávací dokumentace na ambulanci
Část systému Ambulance plní požadavky zadávací dokumentace dle níže uvedeného rozsahu požadavků:
# | Požadavek | Splňuje (ANO/NE) |
P.150 | Ambulance je v NIS NBv řešen pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.151 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
P.152 | Umožnit vedení samostatných částí zdravotnické dokumentace v čistě elektronické formě, minimálně v rozsahu „ambulantní zpráva“. | ANO |
P.153 | Podpora administrativy a organizace práce v ambulanci, pro vedení ambulantní pacientské dokumentace. | ANO |
P.154 | Ř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. Musí být k dispozici také další podrobné údaje jako např. diagnózy, výsledky vyšetření, záznamy o užívaných lécích a vystavené recepty. | ANO |
Organizace ambulantního provozu | ||
P.155 | Možnost definice struktury ambulancí dle organizačního uspořádání. | ANO |
P.156 | Zadávání údajů o operativních zákrocích a hospitalizování pacienta – řešení musí poskytnout uživateli/odbornému zdravotnickému pracovníkovi možnost naplánovat operativní zákrok a hospitalizaci pacienta a zadat údaje o těchto skutečnostech z ambulantního prostředí. | ANO |
P.157 | Možnost převedení pacienta z ambulance na hospitalizaci (včetně zadané dokumentace). | ANO |
P.158 | Možnost propojení s vyvolávacími systémy a funkční podpora procesů a funkcí vyvolávání pomocí externího vyvolávacího systému. | ANO |
Lékařská dokumentace na ambulanci | ||
P.159 | Využití grafického textového editoru pro ambulantní zprávu s možností formátovacích funkcí v rozsahu – velikost písma, typ fontu, barva písma, kurzíva, odrážky. | ANO |
P.160 | Všechny potřebné úkony umožnit vykonávat rovnou při zápisu ambulantního vyšetření. | ANO |
P.161 | Přehledná historie ambulantních zápisů. | ANO |
P.162 | Zadávání receptů: 1. on-line informace o preskripci 2. možnost práce s pozitivním listem 3. možnost zadání magistraliter 4. k dispozici on-line informace o lékových interakcích 5. napojení na eRecept (viz požadavky dále) | ANO |
P.163 | Poukazy na vyšetření/ošetření a pomůcky: 1. možnost zadání poukazů na vyšetření/ošetření a pomůcky 2. poukazy na ošetřovatelku pro domácí péči 3. poukaz na rehabilitační péči 4. poukaz na léčebnou a ortopedickou pomůcku 5. žádanka o schválení/ povolení – žádost na pojišťovnu k posouzení reviznímu lékaři o schválení úhrady za pomůcku Tato funkčnost musí být dostupná i v rámci hospitalizačního provozu. | ANO |
P.164 | Možnost zařazení pacienta do dispenzárních skupin. | ANO |
P.165 | Možnost vkládat do nálezu obrazové informace, videosekvence či další multimediální soubory. | ANO |
Plánovač | ||
P.166 | Komplexní řešení objednávání pacientů k vyšetření v ambulancích na konkrétní datum a čas, na druh vyšetření, ke konkrétnímu lékaři, na dané pracoviště. | ANO |
P.167 | Možnost pohledů na denní, týdenní, měsíční plán a plán za zvolený časový interval a oddělení nebo jeho část (dle přístroje, procedury, sálu apod.). | ANO |
P.168 | Možnost plánování a objednávání min. na 1 rok do budoucna. | ANO |
P.169 | Možnost naplánovat přijetí a propuštění u konkrétního pacienta na konkrétní den a čas, oddělení, případně jeho část (dle přístroje, procedury, sálu apod.). | ANO |
P.170 | Možnost nastavit kapacitu oddělení a limity pro plánování. Při dosažení uvedených limitů barevně zvýraznit dosažení/překročení limitů. Při dalším objednávání upozornit na překročení limitů s dotazem, zda uživatel skutečně chce provést objednání/zaplánování. Při objednání/zaplánování v rámci překročení limitů provést záznam do plánu, že došlo k překročení limitu a kdo jej provedl. | ANO |
P.171 | 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, apod.). Pro plánovaná vyšetření musí být uveden čas, typ vyšetření. | ANO |
P.172 | Možnost úprav v objednacím kalendáři (na základě dovolených, pracovní neschopnosti, konferencí, omezení počtu objednaných pacientů). | ANO |
P.173 | Zadávání a sledování účasti objednaných pacientů na plánovaných aktivitách, barevné odlišení neúčasti pacienta na plánované aktivitě. | ANO |
P.174 | Sestavy a tiskové výstupy za zvolené období, oddělení nebo jeho část: 1. Seznamu objednaných a plánovaných pacientů/výkonů na každý kalendářní den / oddělení nebo jeho část. 2. Statistiky objednaných a plánovaných pacientů/výkonů na každý kalendářní den / oddělení nebo jeho část. 3. Samostatné výstupy a statistiky s výběrem/rozlišením objednaných pacientů, přítomných, příjmů, propuštění. | ANO |
P.175 | Možnost notifikace pacientům s využitím SMS/emailu v definovaném časovém předstihu (výchozí je 1 den). SMS bránu a SMTP server zajistí Objednatel. | ANO |
Přehledy a statistiky | ||
P.176 | Přehledy minimálně v rozsahu: ambulantní kniha, předepsané recepty | ANO |
7.7 Hospitalizace
7.7.1 Plnění požadavků zadávací dokumentace pro hospitalizaci
Část Hospitalizace systému plní požadavky zadávací dokumentace dle níže uvedeného rozsahu požadavků:
# | Požadavek | Splňuje (ANO/NE) |
P.177 | Hospitalizace je v NIS NBv řešena pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.178 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
P.179 | Využití grafického textového editoru pro hospitalizační zprávy (příjmová, propouštěcí, překladová atd.) s možností formátovacích funkcí v rozsahu – velikost písma, typ fontu, barva písma, kurzíva, odrážky. | ANO |
P.180 | Možnost definovat příjmový proces s kroky, které vykonává sestra, lékař, administrativní pracovník. Hlídání neprovedených kroků tohoto procesu, ú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. | ANO |
P.181 | Vytváření operačních a hospitalizačních procesů – je možné vytvářet a naplánovat operační a hospitalizační procesy. | ANO |
Možnost pohledu do historické dokumentace pacienta. | ANO |
P.182 | ||
P.183 | Vizuální rozlišení standardních pokojů a nadstandardních s možností zobrazení detailní informace o nadstandardních službách na nadstandardních pokojích. | ANO |
P.184 | Plánování hospitalizace: možnost automatického přidělení nejbližšího možného termínu dle kapacity oddělení po zadání přibližného termínu nástupu a předpokládané délky hospitalizace. | ANO |
Práce u lůžka pacienta | ||
P.185 | Dostupnost veškeré dokumentace pacienta v mobilních zařízeních u lůžka pacienta (dekurzy, ordinovaná medikace atd.). | ANO |
Vedení dokumentace | ||
P.186 | Zadání TISS protokolu, skórovacích schémat (SOFA, APACHE II, NIHSS). | ANO |
P.187 | Vedení bilance tekutin a měřených údajů a tlakový profil. | ANO |
P.188 | Možnost přizpůsobit tisky dekurzu. | ANO |
P.189 | Elektronické vedení medikací a jejich napojení na logistický systém. | ANO |
P.190 | Přehledné zobrazení výsledků vyšetření laboratorních, RTG, konzilií, možnost jejich jednoduchého přenosu do vytvářených dokumentů. | ANO |
P.191 | Závěrečné zprávy a propouštěcí dokumentace se generují automaticky dle předem dohodnutých pravidel a obsahu z dosud pořízené dokumentace (ambulantní vyšetření, konziliární vyšetření, včetně všech výsledků z hospitalizace a laboratorních výsledků) a je plně elektronická. | ANO |
Stravování pacientů | ||
P.192 | Dodávka napojení NIS na stravovací provoz, který bude sloužit pro objednávání stravování hospitalizovaných pacientů (diety apod.). | ANO |
P.193 | Objednávání diet pacienta. | ANO |
P.194 | Vedení evidence diet na pacienta. | ANO |
P.195 | Přehledy diet po odděleních / stanicích. | ANO |
P.196 | Přehledy údajů pro stravovací provoz: • Počty jednotlivých diet • Počty strávníků | ANO |
Výstupy | ||
P.197 | Přehled všech hospitalizovaných pacientů, možnost omezení na oddělení. | ANO |
P.198 | Přehled lůžek a jejich obsazenosti, dle oddělení. | ANO |
Detence | ||
P.199 | Při přijetí pacienta v detenci možnost rovnou odeslat detenci na administrativního pracovníka NBv, který pošle na Městský soud Brno prostřednictvím datových schránek. | ANO |
Na administrativního pracovníka bude zaslána potřebná dokumentace emailem a bude proveden záznam do dokumentace pacienta o provedení. | ||
Pracoviště intenzivní medicíny operačních oborů (PIMOO) | ||
P.200 | Náhled a práce s dokumentací pacienta na jednom místě bez ohledu na oddělení operačních oborů, které pacienta na PIMOO (JIP) umístilo. Je požadováno jednotné zadávání žádanek, zapisování vyšetřovacího statusu apod. pod specializací oddělení, které pacienta na PIMOO (JIP) umístilo. Poznámka: jedná o následující oddělení operačních oborů: chirurgie, ortopedie, urologie, gynekologie a porodnice, ORL. | ANO |
P.201 | Sdílení lůžek s uvedenými odděleními operačních oborů. | ANO |
Ostatní požadavky | ||
P.202 | Možnost zadávat čerpání nadstandardních služeb, včetně účtování poplatků za tyto služby. Možnost zpětné kontroly úhrady za nadstandardní služby. | ANO |
P.203 | Příkaz transportu: možnost zadání, kontroly a tisku příkazu k transportu. | ANO |
P.204 | Umožnit tisky legislativně případně nemocnicí požadovaných dokumentů nad rámec společných dokumentů: 1. Edukační záznam 2. Plán prevence péče o dekubity 3. Záznam hodnocení bolesti 4. Protokol o užívání léčivých přípravků V seznamu dokumentů zobrazit nejprve specifické dokumenty a až následně ostatní (společné) dokumenty. | ANO |
7.7.2 Plnění požadavků zadávací dokumentace pro ošetřovatelskou dokumentaci
Rozšíření modulu AMIS*HD Ošetřovatelská dokumentace plní požadavky zadávací dokumentace v souladu s níže uvedeným seznamem požadavků:
# | Požadavek | Splňuje (ANO/NE) |
P.205 | Kompletní vedení ošetřovatelské dokumentace dle znění zákona. | ANO |
P.206 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
Invazivní vstupy | ||
P.207 | Evidence jednotlivých invazivních vstupů s možností konfiguračně přidávat nové typy invazivních vstupů dle potřeb jednotlivých pracovišť. | ANO |
P.208 | Evidence data zavedení invazivního vstupu. | ANO |
P.209 | Evidence počtu dní od zavedení invazivního vstupu. | ANO |
P.210 | Evidence data ošetření / převazu invazivního vstupu. | ANO |
P.211 | Evidence materiálu skutečně použitého k ošetření invazivního vstupu. | ANO |
P.212 | Evidence data (termínu) plánovaného ošetření / převazu/ výměny. Upozornění uživatele na blížící se termín. | ANO |
P.213 | Evidence data odstranění (ex) invazivního vstupu. | ANO |
Hodnocení rizik | ||
P.214 | 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, při změně zdravotního stavu pacienta, možnost vytvořit statistické přehledy a tabulky. | ANO |
P.215 | Hodnocení rizika podle Xxxxxxxxx | ANO |
Péče o rány, defekty a dekubity | ||
P.216 | Při přijetí pacienta nebo vzniku rány, defektů nebo dekubitů záznam lokalizace do obrázku a záznam dalších nezbytných údajů o ráně, defektu nebo dekubitu. | ANO |
P.217 | Zachycení informací o stavu a ošetřování ran, defektů a dekubitů. | ANO |
P.218 | Evidence jednotlivých ran, defektů a dekubitů s možností konfiguračně přidávat nové typy dle potřeb jednotlivých pracovišť. | ANO |
P.219 | Evidence popisu, stavu, stupně a vlastností rány, defektu či dekubitu. | ANO |
P.220 | Možnost změny typu v případě změny. | ANO |
P.221 | Možnost záznamu údajů o ošetření jednotlivých ran, defektů či dekubitů – datum, velikost defektu, způsob realizace ošetření, evidence použitého materiálu, datum dalšího převazu. Údaje aktualizovat na denní bázi, případně po každém zákroku/ošetření. Možnost přikládat fotografický materiál. | ANO |
P.222 | V případě přeložení na jiné oddělení musí být údaje k dispozici a musí být možnost aktualizace údajů na novém oddělení (pokračování v ošetřování bez nutnosti nového zadávání). | ANO |
P.223 | Při ukončení péče (např. z důvodu ukončení hospitalizace), závěrečný záznam o stavu. | ANO |
P.224 | Tiskové výstupy a statistiky (rány, defekty a dekubity): 1. Seznamy pacientů dle typů, období, případně oddělení 2. Detailní přehled ošetření pacienta (souhrnný) | ANO |
7.8 Operační sály
Pro úsek operačních sálů systém NIS AMIS*HD řeší tyto oblasti:
• Plánování operací – jako součást řízení zdravotnického provozu celého zařízení
• Operační dokumentace – jako součást speciální zdravotní dokumentace
7.8.1 Plánování operací
Pro plánování a řízení operací je určena část NIS AMIS*HD, kterou označujeme souhrnně jako Operační sály. Má tyto jednotlivé moduly:
• Objednací kniha
• Operační program
• Na sále
• Dispečer
• Dashboard
7.8.1.1 Operační sály – část Objednací kniha
V rámci plánování operací je k dispozici vícekrokový workflow systém, ve kterém lékaři jednotlivých oddělení mohou vkládat své požadavky do plánu operačního dne. Práce týkající se plánování pro operační provoz je realizována v grafickém prostředí plánu, který se nazývá Objednací kniha.
Objednací kniha slouží pro plánování jak operací, tak operací s hospitalizací či samotných hospitalizací, případně vyšetření. Pro plánování v Objednací knize není nutné znát přesné datum operace ani konkrétní operační sál (pacient je plánován k hospitalizaci a „čeká“ na zařazení do operačního programu), ale v závislosti na potřebách uživatele je možné naopak plánovat i na konkrétní operační sál, den i čas, ke konkrétnímu operatérovi.
Pro práci v objednací knize je možné vytvořit šablonu – rozvrh předem definovaných operací na daný den, u kterých je možné předem nadefinovat také operatéra, pohlaví, operační výkon, typ anestezie; šablona je bez pacienta. Uživatel pak při otevření příslušné objednací knihy může využít šablonu pro různé typy výkonů a pouze doplnit údaje o pacientovi.
Plánovat s pomocí šablony lze s ohledem na časový rozvrh operačních sálů, konkrétní zákrok (na základě vizuálního rozlišení) či pro konkrétního lékaře. Je zde také možnost plánování příjmů na konkrétní oddělení.
Uživatel může prohlížet objednací knihu s možností volby zobrazeného časového období - jeden den, kalendářní týden. Je možné listovat objednací knihou postupně vpřed / vzad po jednotkách zvoleného časového období nebo zobrazit požadované období výběrem z kalendáře; pro zobrazení je možné nastavit na kalendářní týden s možností rozlišení sudých a lichých týdnů. V objednací knize je také možnost filtrovat pro zobrazení pouze požadovaných záznamů podle zadaných kritérií, jako například operační diagnóza, objednávající lékař, typ zákroku, a další.
Uživatel má také možnost vyhledat v objednací knize nejbližší volný termín, a sice dle zadaného operačního výkonu a ve zvoleném časovém období.
Plánování operativy je nedílnou součástí modulu pro účely podpory provozu operačních sálů, proto je velmi těsně spjat s ostatními částmi modulu AMIS*HD Operační sály.
7.8.1.2 Operační sály – část Operační program
Z podkladů v Objednacích knihách je vytvářen návrh operačního programu pro jednotlivé disponibilní operační sály – pokud jsou pacienti objednáváni na konkrétní dny operace, resp. konkrétní operační sály, je možno si předpřipravit operační programy na mnoho dní dopředu (alespoň orientačně). Pokud jsou pacienti objednáváni k hospitalizaci, musí být do operačního programu vkládány zodpovědnou osobou na jednotlivé operační sály „ručně“ ze zásobníku (poolu - jedná se o přijaté pacienty, připravené k operačnímu zákroku).
Součástí plánu operací je i možnost stanovit informace o předpokládaných potřebných prostředcích k operaci (technologie) a upozornění při jejich možných kolizích.
Práce je realizována v grafickém prostředí plánu, který umožňuje zobrazení s možností různých pohledů na plán (například dle operačního sálu) a umožňuje individuální nastavení plánu pro organizační jednotku/pracoviště.
V Operačním programu modulu AMIS*HD Operační sály je možné také plánování operací bez použití Objednací knihy. Zadávají se zde operace bez pomoci šablony, pacienta lze naplánovat od počátku,
a sice na konkrétní den a konkrétní operační sál, nebo pouze na konkrétní datum bez volby operačního sálu. Lze zde ale také pouze doplnit hlavní údaje o operaci, operační tým, výkony a prostředky, a další informace k operaci již vytvořené v objednací knize.
Obrazovka Operačního programu v záhlaví obsahuje souhrnné údaje o konkrétním operačním sále
- pracovní dobu sálu, operační tým pro daný den a sál, vše dle nastavení zobrazení buď na aktuální datum, nebo dle filtru. Obsahuje také kalendář, grafický přehled pro daný den, ve kterém lze jednoduše zvolit den pro sestavení operačního programu. Levá část obrazovky zobrazuje seznam operací pro daný den a jejich pořadí. Při větším počtu operací je zde možnost jednoduché změny pořadí operací přetáhnutím myší - metodou drag & drop. Zobrazené sloupce jsou konfigurovatelné. V obrazovce Operačního programu se zadávají také detaily k operacím. Je zde možnost editace již vytvořených údajů a kromě základních informací o pacientovi a operaci, jako například operační diagnóza či operační výkon, je zde uveden i orientační čas trvání dané operace a doba přípravy, začátek operace, operační tým a další informace
Operační program je možné po vyplnění všech potřebných informací schválit a/nebo uzavřít. Stav operačního programu je zobrazen v hlavičce formuláře. Po schválení je operační program již považován za kompletní, ale je možné v něm ještě provádět změny (například doplňovat údaje k operaci). Po uzavření a schválení nelze již v operačním programu editovat žádná data ani přidávat operace či měnit jejich pořadí.
7.8.1.3 Operační sály – části Dispečer, Na sále, Dashboard
Tyto součásti modulu Operační sály byly vyvinuty pro koordinaci práce na operačních sálech a s tím související jak návaznost jednotlivých operací, tak i optimální využití zdrojů. Umožňují zadávání skutečných časů operací a provádění aktuálních změn v operačním programu, které nastávají v průběhu operačního dne, a tak je možné zobrazovat on-line přehled na operačních sálech.
Pomocí Dispečera je možné v průběhu operačního dne provádět v seznamu plánovaných operací změny dle aktuální situace na operačním sále, např. přidání akutní operace, zrušení či přeplánování operace. Na základě vkládaných informací je pak zobrazen aktuální stav na sálech přiřazených uživateli dle práv, případně dle nastavení filtru.
„Na sále“: Aby bylo možné zobrazovat on-line stav na operačních sálech v části Dashboard, je nejprve nutné pořizovat do systému data, která jsou pro toto zobrazení nezbytná. Pořizování dat musí probíhat on-line, tzn. v reálném čase, nejlépe přímo na operačním sále. Jedná se zejména o zadávání skutečných časů operací a provádění aktuálních změn v plánu operací, které nastávají v průběhu operačního dne. K tomuto účelu slouží obrazovka Na sále - tato obrazovka je navržena pro použití přímo na operačním sále, pro dotykovou obrazovku. Je však možné ovládání také pomocí myši.
Dashboard operačních sálů: jedná se o grafické zobrazení průběhu operačního dne na jednotlivých operačních sálech.
Obsahuje přehled sálů, na které existuje pro aktuální den uzavřený a schválený operační program. Ke každému sálu je zde zobrazena informace o aktuálně probíhající operaci s příslušnými parametry a grafem průběhu, operaci následující, opět s příslušnými parametry, a grafické zobrazení celého dne, ve kterém je zobrazen aktuální stav celého operačního programu pro daný sál. V jednom koláčovém grafu je zde poměr počtu provedených a čekajících operací, ve druhém grafu souhrnný čas provedených operací oproti operacím k provedení. Data v obrazovce se v určitých časových intervalech aktualizují a dynamicky se mění na základě informací z obrazovek Dispečer a Na sále.
Další zpracování, hodnocení a zobrazování informací zadaných v jednotlivých součástech modulu Operační sály je možné pomocí reportovacích a vytěžovacích nástrojů typu Business Objects.
7.8.2 Operační dokumentace – jako součást speciální dokumentace na vybraných provozech
Vedení dokumentace k operaci je obsahem modulu Operační sály – část Operační dokumentace
Modul Operační sály - část Operační dokumentace
Operační dokumentace je součástí modulu Operační sály a navazuje na část Operační program nebo může být provozována i samostatně. Pokud navazuje na Operační program, obsahuje v základním zobrazení operace ze schváleného Operačního programu, po vybrání příslušné operace je možno založit příslušné protokoly (viz dále). Pokud není používán Operační program, musí být každá operace založena nově jako „neplánovaná“ operace.
Ke každé operaci je možno založit a vést tuto dokumentaci:
• Operační protokol (možno i více protokolů při více výkonech, přístupech, operačních týmech apod.)
• Anesteziologický protokol (možno vést jednotlivé součásti: předanesteziologické vyšetření, vlastní anesteziologický protokol, dospávací protokol, event. „stručný“ anesteziologický protokol)
• Bezpečnostní protokol (záznam bezpečnostní procedury může být i součástí předchozích protokolů)
• Další záznamy – např. ošetřovatelská perioperační péče apod.
V každém protokolu mohou být společné informace (identifikace pacienta, operační výkon, operační diagnóza atd.), a specifické informace k danému protokolu – některé položky jsou napevno připraveny (zejména ty, které jsou vázány na číselníky – diagnózy, výkony apod.), některé je možno připravit konfiguračním nastavením. U všech položek je možno nastavit jejich zobrazení a používání nebo jejich potlačení. Je možno konfigurovat strukturu protokolu (jednotlivá políčka – například pro oční operace, katetrizační výkony apod.), nebo psát zápis protokolu textem (s použitím předefinovaných textů a šablon).
V rámci Operační dokumentace jsou evidovány skutečné časy operace (začátek a konec využití sálu, začátek a konec chirurgický, začátek a konec anestezie atd.), součástí je taktéž evidence veškerého personálu podílejícího se na operaci (je možno přidávat další role kromě již definovaných operatérů a asistentů, anesteziologů, anesteziologických sester, instrumentářek atd.) – je předpřipraveno z operačního programu (pokud je používán)
Součástí Operační dokumentace je evidence všech provedených výkonů, spotřebovaného materiálu a léků (včetně ZÚM, ZÚLP), použitých nástrojů, přístrojů apod. pro účely vykazování zdravotním pojišťovnám, nebo pro interní sledování uvnitř zdravotnického zařízení (např. přeúčtovávání nákladů mezi nákladovými středisky apod.)
7.8.3 Plnění požadavků zadávací dokumentace pro operační sály
Modul operační sály AMIS*HD splňuje požadavky zadávací dokumentace v níže uvedeném rozsahu:
# | Požadavek | Splňuje (ANO/NE) |
P.225 | Dodávka modulu pro podporu pro komplexního workflow operačních sálů od plánování operačních výkonů (objednání pacienta k operaci), sestavování a schvalování operačního programu, řízení a sledování průběhu operačního dne a vedení kompletní operační dokumentace pacienta, včetně perioperační a anesteziologické dokumentace. | ANO |
Plánování operačních výkonů |
P.226 | Možnost plánování operací v diáři příslušného operačního sálu, barevné rozlišení objednávky dle typu plánovaného operačního zákroku. | ANO |
P.227 | Zadání všech nezbytných údajů vztahujících se k plánované operaci (stranový protokol, transfuze, nesvéprávný pacient, následné umístění na JIP atd.). | ANO |
P.228 | Na JIP musí být k dispozici seznam plánovaných umístění pacientů. | ANO |
P.229 | Možnost předdefinovat šablony plánu dne pro jednotlivé operační sály. | ANO |
P.230 | Podpora pro vyhledání volného termínu podle sálu, typu zákroku, operačního sálu, operatéra, časového období, potřeby přítomnosti anesteziologa. | ANO |
P.231 | Podpora pro vyhledání termínu již naplánované operace pro daného pacienta . | ANO |
P.232 | Možnost nastavení výjimek v objednací knize pro jednotlivé sály a vybraný den (nestandardní den, sál mimo provoz). | ANO |
P.233 | Možnost objednání pacienta bez operace (operační výkon bude upřesněn později). | ANO |
P.234 | Možnost objednání pacienta mimo předdefinovanou šablonu. | ANO |
P.235 | Možnost naplánování operace bez přiřazení k operačnímu sálu (sál bude upřesněn později). | ANO |
P.236 | Možnost různých pohledů na objednací knihu (denní, týdenní, pracovní týden). | ANO |
P.237 | Zachování historie (zmražení) stavu plánu operací nezávisle na dalších fázích zpracování záznamů o operacích (operační program, operační den). | ANO |
P.238 | Sledování účasti objednaných pacientů na plánovaných operacích, barevné odlišení neúčasti pacienta na plánované operaci. | ANO |
Sestavování a schvalování operačního programu | ||
P.239 | Automatické převzetí plánovaných operací z objednací knihy do návrhu operačního programu | ANO |
P.240 | Možnost zadat stabilní operační tým dne pro jednotlivé operační sály | ANO |
P.241 | Možnost definice operačního dne (začátek první operace, konec poslední operace, začátek práce anesteziologa, …) | ANO |
P.242 | Indikace ukončeného plánování anesteziologem | ANO |
P.243 | Indikace ukončeného plánování perioperační sestrou | ANO |
P.244 | Možnost vícestupňového schvalování operačního programu (uzavření operačního programu, schválení operačního programu). | ANO |
P.245 | Možnost definování pořadí operací v rámci operačního dne. | ANO |
P.246 | Možnost změny pořadí operací formou drag & drop. | ANO |
P.247 | Automatický přepočet časů operací po změně pořadí. | ANO |
P.248 | Možnost vložení neplánované operace do operačního programu. | ANO |
P.249 | Možnost přiřazení plánované operace bez uvedeného operačního sálu na konkrétní operační sál formou drag & drop. | ANO |
P.250 | Zachování historie (zmražení) stavu operačního programu nezávisle na dalších fázích zpracování operačních záznamů (plán v objednací knize, operační den). | ANO |
Řízení a sledování průběhu operačního dne | ||
P.251 | Možnost evidence časů operace dotykovým způsobem na dotykové obrazovce (začátek vytížení, začátek anestezie, začátek operace, konec operace, konec anestezie, konec vytížení) | ANO |
P.252 | On-line přehled stavu operačního dne, přehled všech operací a jejich průběhu a stavu vůči plánu (čekající, čekající zpožděná, probíhající, probíhající ve skluzu, provedená, vyjmutá, zrušená), včetně barevného odlišení operací dle stavu | ANO |
P.253 | Možnost operativních změn v operačním dni dle aktuálních potřeb (vložení neplánované operace, změna pořadí formou drag & drop, přesun na jiný operační sál, úplné zrušení operace, vyjmutí operace z daného operačního dne) | ANO |
P.254 | Grafický pohled na průběh operačního dne formou sloupcových a koláčových grafů, znázornění stavu operačního dne vůči plánu po jednotlivých operačních sálech | ANO |
P.255 | Zachování historie (zmražení) skutečného stavu průběhu operačního dne nezávisle na předchozích fázích zpracování operačních záznamů (plán v objednací knize, operační program) | ANO |
Vedení kompletní operační dokumentace | ||
P.256 | Zápis operačního protokolu (OP) s možností využití předdefinovaných hodnot. | ANO |
P.257 | Automatické předání všech známých informací z plánu a operačního dne do OP. | ANO |
P.258 | Možnost vedení strukturovaného OP dle platné legislativy. | ANO |
P.259 | Možnost evidence sledovaných časů k operaci. | ANO |
P.260 | Podpora pro vykázání operačních výkonů, ZUM a ZULP. | ANO |
P.261 | Kontrola vzájemných vztahů výkonů: • Nutnost zadání výkonů, které jsou prováděny společně • Neumožnit zadat vylučující se výkony | ANO |
P.262 | Podpora pro vedení perioperační dokumentace. | ANO |
P.263 | Podpora pro vedení předanesteziologického protokolu. | ANO |
P.264 | Podpora pro vedení anesteziologického protokolu. | ANO |
P.265 | Podpora pro vedení poanesteziologického protokolu. | ANO |
P.266 | Možnost zaznamenání použitých přístrojů do dokumentace. | ANO |
P.267 | Možnost vícestupňového schvalování operační dokumentace. | ANO |
Ostatní požadavky | ||
P.268 | Řešení umožňuje nahlížet na plánování na operačních sálech na mobilním zařízení (tablet) ve webovém prohlížeči. | ANO |
P.269 | Tiskové sestavy min. v rozsahu: diáře operačních sálů pro jednotlivý den i vybrané období, objednací kniha (denní, týdenní, pracovní týden), historie skutečného využití operačních sálů (včetně účasti/neúčasti pacientů), operační program, stav operačního dne, grafický pohled na stav operačního dne, dokumenty z operační dokumentace. | ANO |
7.9 Porodnice
Modul porodnice bude rozšířen dle následujících požadavků obsažených v zadávací dokumentaci podle této tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.270 | Porodnice je v NIS NBv řešena pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.271 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
P.272 | Umožnit vedení samostatných částí zdravotnické dokumentace v čistě elektronické formě, minimálně v rozsahu „porodopis“. | ANO |
P.273 | Využití grafického textového editoru pro ambulantní zprávu s možností formátovacích funkcí v rozsahu – velikost písma, typ fontu, barva písma, kurzíva, odrážky. | ANO |
P.274 | Možnost jednoduše (přímo z porodopisu) založit novorozence jako pacienta do registru a uložit na novorozeneckou stanici. | ANO |
P.275 | Přenos potřebných údajů mezi dokumentací rodičky a novorozence s vyloučením duplicit zadávání. Současně přenos mezi dokumentací standardní hospitalizace a dokumentací rodičky. Konverze hospitalizační dokumentace na porodopis a zpětně, dle potřeby. | ANO |
P.276 | Možnost svázat dokumentaci rodičky s dokumentací novorozence. | ANO |
P.277 | Možnost zadání více novorozenců k rodičce. Možnost opravy u mylně zadaných vícerčat, automatická konverze jen na jednoho novorozence. | ANO |
P.278 | Přehledné hlídání povinných údajů v dokumentaci. | ANO |
P.279 | Vyváření legislativně vyžadovaných statistik a výstupů. | ANO |
7.10 Patologie
Modul patologie je řešen subdodávkou laboratorního systému Orpheus firmy Xxxxxxx s.r.o. a je plně integrován s NIS a plně nahrazuje původní funkcionalitu stávajícího modulu Patologie a rozšiřuje ho o nové požadavky.
Základní vlastnosti patologie:
• Denní provoz: Systém obsahuje čtyři pracoviště - biopsie, cytologie, gynekologie, nekropsie
• Při založení hlavičky se současně zobrazí přehled všech minulých žádanek pacienta v patologii dle požadavku (např. pro cytologii se zobrazí i žádanky z biopsie)
• Číslo žádanky generuje systém, lze je opravit, nebo se vkládá ručně (nekropsie)
• Po vložení hlavičky se zobrazí okno pro vkládání informací o vzorcích (orgány)
• Vkládání výsledků - Po vložení výsledků se zobrazí okno pro vkládání kódů pojišťovny - pomocí předdefinované tabulky nebo stromu
• Oprava hlavičky žádanky, Výmaz žádanky
• Oprava seznamu vzorků (orgánů)
• Zápis zprávy a dodatku ke zprávě s možností tisku
• Tisk pracovního deníku (dle data nebo čísla žádanky)
• Výpis historie všech pacientů (dle data nebo čísla žádanky) s možností prohlížení zpráv a tisku seznamu žádanek
• Statistika: statistické výstupy dle požadavku, univerzální sestava s volbou z více položek (cca 15 položek), výpis pacientů s možností prohlížení zpráv a tisku
• Diapozitivy, udržování jedné nebo více databází diapozitivů s vazbou na žádanku: Vložení informace o diapozitivu, oprava informace o diapozitivu, výpis podle klíčových slov s možností prohlížet/tisknout příslušnou zprávu, prohlížení databáze s možností hledání a filtrování
• Účty: Oprava položek v účtu, Vkládání a oprava dodatků, Výpis žádanek, které nemají přiřazen žádný kód pojišťovny, Tvorba účtů, výpisy
• Servis, změna lékaře - umožní změnit vyšetřujícího lékaře hromadně pro skupinu založených žádanek, údržba číselníků, parametrů, změna hesla, změna uživatele
Modul Patologie plní požadavky zadávací dokumentace v tomto rozsahu:
# | Požadavek | Splňuje (ANO/NE) |
P.280 | Patologie je v NIS NBv řešena pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.281 | Dodávka modernizace modulů pro agendu patologie. Podpora nových činností pro histologii, cytologii, nekropsii. | ANO |
P.282 | Možnost automatického příjmu žádanek z klinických oddělení (elektronicky) nebo zápis žádanky na vyšetření přímo na patologii (opisem z papíru). | ANO |
P.283 | Možnost tvorby strukturované žádanky s označením povinných polí, aby byla úplná. | ANO |
P.284 | Objednávání vyšetření s možností registrace nového pacienta. | ANO |
P.285 | Automatický vstup potřebných údajů z žádanky resp. ze stávající dokumentace pacienta. | ANO |
P.286 | Možnost zadání dodatečného vyšetření ke stávajícímu požadavku. | ANO |
P.287 | Možnost úpravy/opravy žádanky. | ANO |
P.288 | Možnost zrušení/odmítnutí žádanky včetně odůvodnění akce. V případě elektronického zaslání žádanky, zaslání informace žadateli včetně odůvodnění. | ANO |
P.289 | Vhodné nastavení funkcí, seznamů a zobrazovaných informací pro jednotlivé role uživatelů (administrativní pracovník, laborant, lékař, primář apod.) | ANO |
P.290 | Možnost nastavení automatického sledu činností – aby systém kopírovat práci koncového uživatele. | ANO |
P.291 | Generování pracovních listů, možnost vyhledání a sestavy dle data nebo čísla žádanky. | ANO |
P.292 | Záznam plnění jednotlivých kroků vyšetření konkrétními pracovníky (odpovědnost pracovníků), kontrolní sestavy. | ANO |
P.293 | Použití standardního editoru (RTF) s možností používání předdefinovaných textů. | ANO |
P.294 | Součástí popisu je i zadání příslušných strukturovaných údajů: hodnocení dle klasifikace SNOMED, zadání hmotnosti orgánů pro nekropsii a podobně. | ANO |
P.295 | Možnost vkládání multimediálních dat k popisu/nálezu a jejich popisu. | ANO |
P.296 | Automatické proúčtování výkonů a materiálů na základě provedeného vyšetření | ANO |
P.297 | Možnost prohlížení historických nálezů při zápisu nálezu | ANO |
P.298 | Systém umožňuje zápis údajů o pitvě do Listu o prohlídce zemřelého. | ANO |
P.299 | Možnost prohlížení relevantní klinické pacientské dokumentace při popisu nálezu | ANO |
P.300 | Možnost nastavit potvrzování nálezů erudovanějším lékařem (druhé čtení). | ANO |
P.301 | Možnost zápisu dodatků (bez omezení počtu) k již uvolněnému nálezu, oprava textu a tisk. | ANO |
P.302 | Odeslání nálezu a dodatků žadateli, upozornění žadatele na nález nebo dodatek. | ANO |
P.303 | Archivace odeslaných nálezů a jejich dodatků v odeslaném stavu, možnost náhledu na odeslané verze nálezů a dodatků. | ANO |
P.304 | Využití dat z laboratorního modulu – viz kap. 6.5.2.7 – Laboratorní systém (LIS). | ANO |
P.305 | Využití dat z PACS: možnost vkládání odkazů na obrazovou dokumentaci a výsledků vyšetření (viz integrace s PACS). | ANO |
P.306 | Komplexní systém pro zpracování vzorků užívaný pro biopsii, cytologii a nekropsii. | ANO |
P.307 | Podpora procesů bioptické a cytologické laboratoře a bioptických a cytologických vyšetření: elektronická žádanka, zapsání výsledků a uvolnění výsledků. | ANO |
P.308 | Podpora procesů nekroptické diagnostiky: založení a zapsání pitevního protokolu, komplexní systém pro zpracování požadavku na patologicko- anatomickou pitvu s vazbou na LIS. | ANO |
P.309 | Vytvoření a vyplnění příslušných částí Listu o prohlídce zemřelého, možnost podpisu a tisku. | ANO |
P.310 | Předávání dat pro vykazování pojišťovnám a pro potřeby statistických výstupů nemocnice a ÚZIS/NZIS. | ANO |
P.311 | Tiskové sestavy – min. následující: celé vyšetření nebo každý vzorek samostatně, Průvodní list k histologickému materiálu, Pitevní protokol, List o prohlídce zemřelého, uživatelské formuláře, žádanky a štítky, spotřeba materiálu. | ANO |
P.312 | Elektronické vedení a archivace Pitevního protokolu a Listu o prohlídce zemřelého. | ANO |
P.313 | Statistiky provedených vyšetření, výkonů, spotřebovaného materiálu apod., možnost exportu dat | ANO |
P.314 | Možnost vytvářet další specifické statistické sestavy ze zadávaných dat pro potřeby pracoviště | ANO |
P.315 | Číselníky morfologií a topografií. | ANO |
P.316 | Napojení na příruční sklad včetně vazby na přípravu roztoků podle předdefinovaných položek. | ANO |
P.317 | Evidenci spotřeby spotřebovaného materiálu. | ANO |
P.318 | Možnost využít standardně předdefinovaných textů a šablon pro usnadnění práce uživatele, možnost jejich změny. | ANO |
P.319 | Elektronická evidence těl zemřelých pacientů uložených na oddělení patologie. | ANO |
7.11 Žádanky a výsledky
7.11.1 Plnění zadávací dokumentace pro část Žádanky a Výsledky
Moduly, které řeší část Žádanky a Výsledky, splňují požadované funkční vlastnosti uvedené v zadávací dokumentaci podle následující tabulky:
# | Požadavek | Splňuje (ANO/NE) | |||
P.320 | Žádanky a výsledky jsou v NIS NBv řešeny pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO | |||
P.321 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO | |||
P.322 | Možnost nahrazení tištěných interních žádanek čistě elektronickými s elektronickým podpisem nebo pečetí. | ANO | |||
P.323 | Žádanky na laboratoře musí odpovídat normě ČSN EN ISO 15189:2013 „Zdravotnické laboratoře - Požadavky na kvalitu a způsobilost“ | ANO | |||
Ambulantní vyšetření od jiného poskytovatele zdravotních služeb | |||||
P.324 | Příjem el. žádanky na ambulantní vyšetření prostřednictvím eHealth systému JmK (eMeDocS). | od | jiného | subjektu | ANO |
P.325 | Odeslání el. žádanky na ambulantní vyšetření prostřednictvím eHealth systému JmK (eMeDocS). | do | jiného | subjektu | ANO |
P.326 | Příjem el. výsledku/nálezu z ambulantního vyšetření od jiného poskytovatele zdravotních služeb prostřednictvím eHealth systému JmK (eMeDocS). | ANO | |||
P.327 | Odeslání el. výsledku/nálezu z ambulantního vyšetření jinému poskytovateli zdravotních služeb prostřednictvím eHealth systému JmK (eMeDocS). | ANO | |||
Laboratorní vyšetření | |||||
P.328 | Součástí žádanky na laboratorní vyšetření musí být povinně seznam léků, které pacient aktuálně užívá (např. ATB, warfarin apod.). | ANO | |||
P.329 | U žádanky na laboratorní vyšetření: 1. Komentáře k žádance (např. u odběru) musí umožnit zadat min. 2000 znaků, možnost zadat více komentářů více pracovníky. 2. V případě, že součástí žádanky jsou odběry, umožnit zadat místo odběru. | ANO | |||
P.330 | Možnost zobrazení seznamu žádanek a vyšetření k danému pacientovi na odděleních (aktuální, historických). | ANO | |||
P.331 | Laboratorní výsledky 1. Celkový výsledek musí umožnit zadat min. 2000 znaků. 2. Komentáře k výsledku musí umožnit zadat min. 2000 znaků, možnost zadat více komentářů více pracovníky. | ANO |
3. Zobrazení všech komentářů k výsledku na žádajícím oddělení. | ||
P.332 | Laboratorní výsledky – zobrazení došlých výsledků v přehledné grafické tabulkové podobě. | ANO |
P.333 | Laboratorní výsledky – možnost zobrazení výsledků vybraných laboratorních metod v podobě grafu. | ANO |
P.334 | Laboratorní výsledky – barevné označení patologických hodnot, možnost zobrazení referenčních mezí. | ANO |
P.335 | Laboratorní výsledky – možnost nastavení uživatelských filtrů pro vybrané laboratorní metody/skupiny metod (napříč všemi typy laboratoří). | ANO |
P.336 | Možnost převzetí výsledků z laboratorních vyšetření ze všech laboratoří do zpracovávané dokumentace pacienta (propouštěcí, ambulantní zprávy atd.) | ANO |
P.337 | Výsledky laboratorních vyšetření přebírat z LIS do NIS i ve formě elektronické dokumentace dle zákona (elektronicky podepsané PDF), uložení do NIS, do AZD, možnost opakovaného tisku z předané elektronické formy. | ANO |
P.338 | Do žádanek a výsledků možnost zadat poznámky, případně komentáře, které budou předávány mezi NIS a LIS, nebudou součástí zdravotnické dokumentace, budou určeny jen pro vnitřní potřebu žadatele/příjemce. | ANO |
Transfuzní přípravky (TP) | ||
P.339 | Elektronické zadávání žádanek imunohematologická vyšetření (některá jsou nutná pro výdej TP) a na transfuzní přípravky z krevní banky. | ANO |
P.340 | V rámci NIS vést evidenci podaných transfuzních přípravků u každého pacienta. Celkový počet evidovaných podání transfuzních přípravků u každého pacienta zobrazit žadateli a přenášet do LIS v rámci žádanky na transfuzní přípravky. | ANO |
P.341 | Přebírání výdejek transfuzních přípravků z LIS do NIS a záznam do dokumentace pacienta. | ANO |
P.342 | Při podání transfuzního přípravku pacientovi musí být zaznamenáno (dle výdejky): transfuzní přípravek, přesný čas podání, množství, kdo podal, kdo asistoval, transfuzní set (materiál) a další nezbytné údaje (dle požadavků SÚKL). | ANO |
P.343 | Po výdeji, podání a záznamu všech nezbytných údajů, automaticky dle kódu přípravku ve výdejce před k vyúčtování péče zdravotní pojišťovně (včetně transfuzního setu a kódu podání). | ANO |
P.344 | Záznam informace o potransfuzní reakce (ANO/NE), v případě, že bude potransfuzní reakce, povinně vyžadovat záznam reakce na transfuzi, včetně povinných vyšetření před a po transfuzi (teplota, tlak atd.), případně další relevantní údaje. Přenos informace o potransfuzní reakci do LIS. | ANO |
Externí žádanky | ||
P.345 | Možnost vyplnit externí žádanku na vyšetření, její podpis (elektronický), případně tisk a předání pacientovi. | ANO |
P.346 | Možnost zaslání externí žádanky na vyšetření elektronicky prostřednictvím eHeath JMK na zařízení připojení do systému výměny zdravotnické dokumentace (viz kap. 3.3.4.1). | ANO |
P.347 | Příjem výsledků vyšetření elektronicky prostřednictvím eHeath JMK na zařízení připojení do systému výměny zdravotnické dokumentace (viz kap. 3.3.4.1). | ANO |
P.348 | Pro ostatní subjekty možnost předání elektronicky podepsané žádanky na administrativního pracovníka, který zašle např. prostředkovým datových schránek. | ANO |
P.349 | Seznam pracovišť kam lze zaslat externí žádanku včetně možností využití elektronických kanálů. Při tvorbě externí žádanky možnost výběru pracoviště a následně distribuce dle nastavení pro dané pracoviště. | ANO |
Ostatní požadavky | ||
P.350 | Připravenost el. žádanek a výsledků na zavedení bezvýznamového identifikátoru při komunikaci s externími subjekty, pokud toto bude v době realizace projektu technicky a legislativně připraveno na straně státu. | ANO |
P.351 | Možnost hromadného načtení souboru platných IČP z portálu VZP – externích žadatelů a následné vyhledávání podle IČP. Nyní v AMIS*H probíhá ruční zadávání externích pracovišť a hledání podle odd. IT vymyšlené zkratky pracoviště. | ANO |
P.352 | Automatické generování čísel žádanek dle úseků. Platí i pro žádanky specifické k oddělení. | ANO |
7.12 eNeschopenka
Tento modul je integrální součástí systému AMIS*HD a je připraven na zpracování elektronické neschopenky podle poslední zveřejněné legislativy při dodržení těchto zásad:
• Veškeré komunikace kolem DPN je elektronická
• Systém zajistí generování čísla rozhodnutí
• Systém umožní tisk průkazu pojištěnce
• V případě technické závady systém umožní pozdější odeslání připraveného podání
Modul eNeschopenka, který je součástí NIS AMIS*HD plní požadované funkční vlastnosti dle zadávací dokumentace:
# | Požadavek | Splňuje (ANO/NE) |
P.353 | Agenda eNeschopenka využívána v hospitalizační i ambulantní části. | ANO |
P.354 | NIS NBv musí nově zajistit komunikaci se službou Veřejného rozhraní pro e - Podání (VREP ČSSZ) Hlášení pracovní neschopnosti (dále jen „HPN“), která umožňuje ošetřujícímu lékaři (zdravotnickému zařízení) formou datové věty předávat tento formulář související s dočasnou pracovní neschopností (dále jen „DPN“): I. díl – Hlášení o vzniku DPN. | ANO |
P.355 | NIS NBv musí nově zajistit komunikaci se službou Veřejného rozhraní pro e - Podání (VREP ČSSZ) Hlášení pracovní neschopnosti (dále jen „HPN“), která umožňuje ošetřujícímu lékaři (zdravotnickému zařízení) formou datové věty předávat tento formulář související s dočasnou pracovní neschopností (dále jen „DPN“): II. díl – Ukončení DPN. | ANO |
P.356 | NIS NBv musí nově zajistit komunikaci se službou Veřejného rozhraní pro e - Podání (VREP ČSSZ) Hlášení pracovní neschopnosti (dále jen „HPN“), která umožňuje ošetřujícímu lékaři (zdravotnickému zařízení) formou datové věty předávat tento formulář související s dočasnou pracovní neschopností (dále jen „DPN“): Hlášení ošetřujícího lékaře (je možné zasílat službou e – Podání HPN nebo prostřednictvím ePortálu ČSSZ). | ANO |
7.13 Dlouhodobý bezpečný archiv el. zdravotnické dokumentace (AZD)
Realizace požadavků na dlouhodobý bezpečný elektronický archiv zdravotní dokumentace je řešena nasazením produktu ICZ AZD, který zajišťuje ukládání, distribuci a bezpečnou, dlouhodobou a
důvěryhodnou archivaci veškeré zdravotnické dokumentace a jeho integrací s NIS AMIS*H/HD a dalším dodávanými součástmi.
Řešení ICZ AZD je založené na ověřených a vysoce spolehlivých komponentách. Vysoký důraz je kladen na legislativní soulad, bezpečnost a dostupnost. Řešení umožňuje přechod k plně bezpapírovému provozu zdravotnického zařízení, během něhož je veškerá pacientská zdravotnická dokumentace krátkodobě i dlouhodobě archivována plně elektronicky při současném dodržení veškerých legislativních požadavků.
Součástí pacientsky orientovaného řešení je šifrování, elektronické podepisování s časovým razítkem a dodatečné ověřování důvěryhodnosti zdravotnické dokumentace. Přechodem k bezpapírovému provozu není ohrožena dostupnost informací nebo spolehlivost jejich uchovávání. Naopak se výrazně sníží čas potřebný pro dohledání a zpracování informací a zejména pak bezpečnost i ekonomika archivace zdravotnické dokumentace.
7.13.1 Funkční vlastnosti AZD
Mezi hlavní přednosti řešení ICZ AZD patří:
• Dlouhodobé uchování dokumentů - technologické i legislativní
• Využití převodu do spec. formátu (PDF/A)
• Plná kompatibilita s nejrozšířenějšími standardy (např. HL7, XXXXX, doporučení IHE...)
• Řešení je nezávislé na samotném NIS AMIS*HD
• Elektronické podepisování dokumentů s časovým razítkem včetně dodatečné ověřování důvěryhodnosti dokumentů
• Automatické hlídání životnosti ukládaných dokumentů
• Podpora skartačních mechanismů podle platné legislativy
• Využití mechanismů šifrování a logování
• Řešení je navrženo pro specifika uchovávání ryze zdravotnické dokumentace včetně všech legislativních aspektů
• Komponenty řešení jsou certifikovány jako zdravotnický prostředek
• Řešení ICZ AZD zajišťuje uložení zdravotnické dokumentace podle zákona č. 499/2004 Sb., o archivnictví a spisové službě, Národního standardu pro elektronické systémy spisové služby (NSeSSS) a podle úrovně technického řešení problematiky obvyklého v Evropské unii, vedené v elektronické formě, podle zákona č. 372/2011 Sb., o zdravotních službách, a vyhlášky č. 98/2012 Sb., o zdravotnické dokumentaci a vyhlášky 137/2018 Sb.
7.13.2 Plnění požadavků zadávací dokumentace na AZD
Nabízené řešení ICZ AZD slňuje požadavky zadávací dokumentace na tuto část podle následující tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.357 | Systém musí být plně v souladu s platnou legislativou pro vedení zdravotnické dokumentace v elektronické podobě, tj. se zákonem 372/2011 Sb., o zdravotních službách, zejména s § 55 odstavci a), b), c), e), h), i) a s § 65 vymezujícím nahlížení do zdravotnické dokumentace, pořizování jejích výpisů nebo kopií. | ANO |
P.358 | Systém musí v souladu s platnou vyhláškou č. 98/2012 Sb. a vyhláškou 137/2018 Sb., o zdravotnické dokumentaci, zejména podporovat ukládání a zpřístupňování dokumentace ve formě textových, grafických, | ANO |
audiovizuálních, digitálních nebo jiných obdobných záznamů, a dle přílohy č. 2 a 3 být v souladu se zásadami pro uchovávání zdravotnické dokumentace a postupy při jejím vyřazování a zničení po uplynutí doby uchování (řízený proces skartace). | ||
P.359 | Pro komunikaci s jinými systémy a přístroji produkujícími záznamy, které jsou součástí zdravotnické dokumentace, musí systém podporovat datové standardy pro výměnu zdravotnické dokumentace HL7, DASTA, DICOM, XML a umožňovat komunikaci se zdrojovými systémy elektronické zdravotnické dokumentace (KISy, LIS, RIS, PACS apod.) nebo přístrojovou technikou (přístroje s DICOM rozhraním apod.) prostřednictvím různých typů protokolů jako HL7, DICOM, SOAP, REST apod. | ANO |
P.360 | Univerzální archivační systém umožňující napojení stávajících i v budoucnu pořízených produkčních systémů spravujících a pořizujících zdravotnickou dokumentaci (NIS, LIS, RIS, PACS apod.) nebo přístrojové techniky. | ANO |
P.361 | Systém musí ukládat dokumenty minimálně ve formátech PDF/A, HL7, XXXXX, DICOM, XML. | ANO |
P.362 | Systém musí zajišťovat tyto kroky procesu dlouhodobé archivace dokumentů: 1. kontrola neporušenost kontrolního součtu dokumentu a kontrola platnosti elektronických podpisů připojených k dokumentu na základě platnosti kvalifikovaného certifikátu, 2. připojení metadat: aktuální verze CRL (seznam zneplatněných certifikátů), OCSP odpovědi, případně další, 3. připojení časového razítka tak, aby kontrolní součet chránil nejen samotný dokument, ale i jeho metadata, periodické připojování dalších časových razítek tak, aby každé další bylo připojeno před vypršením platnosti předchozího. | ANO |
P.363 | Systém musí umožňovat fixaci archivovaných dokumentů formou elektronické pečeti a časového razítka. | ANO |
P.364 | Systém musí umožňovat tvorbu archivních balíčků zajišťujících dlouhodobou platnost celé sady dokumentů, což vede k optimalizaci procesu razítkování a přerazítkování dokumentů tak, aby byly minimalizovány náklady na razítka od časové autority. Systém balíčkování musí splňovat minimálně následující vlastnosti: 1. možnost balíčkování dokumentů do jednoho archivního balíčku nezávisle na jejich typu, významu, různých přístupových právech a bez jejich vzájemného vztahu; 2. poskytování důkazních informací k jednotlivým dokumentům bez nutnosti znalosti obsahu ostatních dokumentů ve stejném archivním balíčku; možnost mazat z archivu dokumenty, aniž by byla ovlivněna schopnost prokázání platnosti ostatních dokumentů ošetřených stejným archivním balíčkem. | ANO |
P.365 | Systém musí mít službu autorizované konverze, která by minimálně umožnila konvertovat PDF/A dokument do papírové formy. | ANO |
P.366 | Systém musí umožňovat řízený proces skartace dle platné vyhlášky č. 98/2012 Sb., o zdravotnické dokumentaci v aktuálním znění (viz přílohy č. 2 a 3 této vyhlášky) a vyhlášky 137/2018 Sb., vytvoření skartačního návrhu na základě skartačního plánu, skartačních znaků a skartačních lhůt. | ANO |
P.367 | Systém musí umět dynamicky reagovat na dodatečné informace, které mohou dodatečně ovlivnit a změnit skartační plán a zohlednit tyto změny do skartační lhůty pro konkrétní archivované dokumenty. | ANO |
P.368 | Systém musí vytvářet protokoly o uskutečněných skartacích a na vyžádání poskytovat zdrojovým systémům informace o skartovaných dokumentech. | ANO |
P.369 | Systém musí umět převést zdrojová data ve formátu JPEG do formátu DICOM s využitím předaných metadat nebo na základě ručně zadaných metadat. | ANO |
P.370 | Elektronická zdravotnická dokumentace pacienta (subjekt údajů) uložená v archívu musí být jednoznačně propojena s identitou pacienta v registru unicitních pacientů za účelem vedení centrálního elektronického zdravotního záznamu pacienta (Eletronic Health Record - EHR) v rámci zdravotnického zařízení. | ANO |
P.371 | Registr unicitních pacientů musí být součástí systému. Registr bude pracovat s identifikací 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 výměnného identifikátoru a zavedení bezvýznamového identifikátoru během doby udržitelnosti, pokud nebude možné tento přechod realizovat během realizace projektu. | ANO |
P.372 | Pro podporu komunikace s ostatními interními, ale převážně externími systémy musí mít registr pacientů implementované transakční součásti IHE PIX profilu (Patient Identifier Cross Referencing) a to „Patient Identity Feed“ pro příjem identifikačních a demografických údajů o pacientovi, „Query/Retrieve“ pro vyhledání pacienta a „Update Notification“ pro příjem informací o změně identifikačních a demografických údajů o pacientovi. | ANO |
P.373 | Pro podporu sdílení zdravotnické dokumentace mezi systémy i zdravotnickými subjekty nezávisle na zdrojových systémech musí mít systém implementován IHE XDS profil (Cross-Enterprise Document Sharing), včetně registru dokumentů (document registry) obsahujícím identifikátory záznamů. Systém musí být připraven na poskytování identifikátorů dokumentů do národního indexu zdravotnické dokumentace prostřednictvím IDRR, pokud to v době realizace bude technicky a legislativně možné. | ANO |
P.374 | Systém musí obsahovat uživatelské rozhraní pro přístup k uložené dokumentaci provozované ve webovém prohlížeči bez nutnosti instalovat přídavné moduly či rozšíření. Toto uživatelské prostředí musí umožňovat vyhledávání dle různých vyhledávacích kritérií, např. dle pacienta, klinické události apod. | ANO |
P.375 | Systém musí umožňovat provoz ve dvou synchronizovaných instancích. | ANO |
P.376 | Systém musí být schopen ukládat archivované dokumenty do různých fyzických úložišť s uložením odkazů na dokumenty v těchto úložištích a se schopností předávat informace o skartaci do těchto úložišť. | ANO |
P.377 | 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ů. | ANO |
P.378 | Komunikace s ostatními systémy i přístup prostřednictvím uživatelského prostředí může být zabezpečena prostřednictvím zabezpečených (šifrovaných) kanálů. | ANO |
P.379 | Systém musí podporovat identifikaci, autentizaci a autorizaci jak pomocí interních mechanismů systému, tak s využitím adresářových služeb (LDAP/AD). | ANO |
P.380 | 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. | ANO |
P.381 | Systém povede žurnál logů o všech operacích v archivu s možností exportu logů do externího SIEM systému. Veškeré přístupy k datům a aktivita uživatelů v archivu 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. | ANO |
P.382 | Systém musí být připraven na provoz 24x7x365 (non-stop). | ANO |
P.383 | Systém musí být funkční na min. konfiguraci pracovních stanic uvedených v kap. 6.5.7 – Pracovní stanice uživatelů. | ANO |
P.384 | Archivační systém nesmí být licenčně omezen na počet nebo typ připojených produkčních systémů nebo přístrojů; typ archivované dokumentace; počet uživatelů nebo zobrazovacích stanic | ANO |
P.385 | Systém musí zajistit automatické transformace dokumentů k zajištění dlouhodobé archivace. | ANO |
P.386 | Auditování a logování provozu jednotlivých prvků systému a možnost vyhodnocování min. 5 let zpětně. | ANO |
P.387 | Integrační rozhraní musí být podporovat standard NSeSSS, resp. komunikaci prostřednictvím tohoto standardu. | ANO |
7.14 Elektronický recept
Modul eRecept splňuje požadavky zadávací dokumentace v tomto rozsahu:
# | Požadavek | Splňuje (ANO/NE) |
P.388 | Elektronický recept je v NIS NBv řešen pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.389 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
P.390 | 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. | ANO |
P.391 | Uživatelé musí být schopni volit z nabídky léků, které jsou 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. | ANO |
P.392 | Možnost komunikovat s CÚ SÚKL dle požadavků legislativy. | ANO |
P.393 | 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. | ANO |
P.394 | Vytvoření elektronické podoby receptu nebo poukazu (eRecept) ve struktuře požadované SUKL. | ANO |
P.395 | Podpis vytvořeného elektronického receptu nebo poukazu pomocí kvalifikovaného elektronického podpisu. | ANO |
P.396 | Odeslání podepsaného elektronického receptu nebo poukazu na centrální uložiště receptů (dále CU) SÚKL. | ANO |
P.397 | Příjem elektronických identifikačních znaků receptu nebo poukazu a jednotlivých položek na receptu z CU SÚKL. | ANO |
P.398 | Oprava dříve uloženého eReceptu v CU SÚKL. | ANO |
P.399 | Stornování dříve uloženého eReceptu v CU SÚKL. | ANO |
P.400 | Možnost dotázat se CÚ SÚKL z prostředí klinického systému, zda byl konkrétní eRecept (recept/poukaz) vyzvednut v lékárně. | ANO |
P.401 | Záznam telefonního čísla, na které byl zaslán elektronický recept do dokumentace pacienta a možnost zobrazit toto číslo u receptu. | ANO |
7.15 Pojišťovna (výkaznictví)
7.15.1 Plnění požadavků zadávací dokumentace pro výkaznictví
Tato část plní požadavky zadávací dokumentace pro oblast výkaznictví dle následující tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.402 | Pojišťovna je v NIS NBv řešena pomocí modulu AMIS*H POJ5, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.403 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
P.404 | Evidence výkonů včetně evidence, zda jsou zasmluvněny se zdravotními pojišťovnami. V případě používá nenasmlouvaného výkonu, upozornění uživatele s dotazem, zda chce opravdu výkon vykázat. | ANO |
P.405 | Nasazování veškerých potřebných číselníků – výkony dle platného seznamu zdravotních výkonů s bodovými hodnotami, HVLP, IVLP, ZP a další dle SÚKL a VZP. Uchování historie změn číselníků, včetně zpětného využití. Možnost editace a vkládání dalších položek (např. nových léků bez úhrady z VZP. schválených mimořádně na žádanku apod.) | ANO |
P.406 | Podpora číselníku N-léků VZP (= léky, které lze vykazovat za hospitalizace); paralelní číselníky léků od ostatních ZP. Ve vazbě na konkrétní pojišťovnu. | ANO |
P.407 | Import číselníku IČP od VZP = Číselník externích žadatelů. | ANO |
P.408 | Vykazování výkonů dle platné výkonové vyhlášky (metodiky vyúčtování VZP). | ANO |
P.409 | Ověřování pacientů vůči B2B službám VZP. | ANO |
P.410 | Import do číselníku frekvenčního omezení výkonů. | ANO |
P.411 | Nastavení ceny bodu dle platné legislativy (pro jednotlivé odbornosti, ZP, výkony,…). Prostor pro ruční nastavení ceny bodu ve specifických případech (komerční pojištění, smluvní partneři apod.). | ANO |
P.412 | Číselník nasmlouvaných výkonů (kontrola při zadávání výkonů do účtů), případné propojení s elektronickými přílohami č. 2 (pro jednotlivé ZP); kontrola vykazovaných výkonů na číselník nasmlouvaných výkonů. | ANO |
P.413 | Rozšíření kontroly kombinace položek (výkony, diagnózy, ZUP, markery). | ANO |
P.414 | Kontrola splnění požadavků u vykazování výkonu 09555 Ošetření dítěte do 6 let (věk, odbornost). | ANO |
P.415 | Kontrola splnění požadavků u vykazování výkonu 09563 Výkon ústavní pohotovostní služby (lze vykázat pouze ambulantně, přičítá se u každého pacienta k výkonu prvního klinického vyšetření v rámci jedné lékařské pohotovostní služby u jednoho poskytovatele lůžkové zdravotní péče vždy v rámci pohotovostní služby). | ANO |
P.416 | Kontrola splnění požadavků u výkonu 09543 Signální výkon klinického vyšetření (Vykazuje se u všech věkových kategorií s výkonem klinického vyšetření provedeným pojištěnci při návštěvě klinického psychologa a klinického logopeda a dále s výkonem klinického vyšetření provedeným pojištěnci staršímu 18 let při návštěvě u praktického lékaře, praktického lékaře pro děti a dorost, ženského lékaře, zubního lékaře, ambulantního specialisty a při návštěvní službě poskytnuté praktickým lékařem a praktickým lékařem pro děti a dorost). Tzn. kontrola na věk, odbornost, hospitalizaci atd. Automaticky doplňovat signální výkony 09543 ke klinickému vyšetření a 09544 k ošetřovacímu dni. | ANO |
P.417 | Kontrola na IČP žadatele a poskytovatele u poukazu na ošetření. Pokud je IČP žadatele shodné s IČP poskytovatele, umožnit konverzi (hromadnou) na ambulantní doklad. | ANO |
P.418 | Umožnit pozastavení, následnou kontrolu a případnou opravu těch poukazů na ošetření, které mají interního žadatele s hospitalizační odborností a požadované výkony jsou provedeny již mimo interval hospitalizace. (Poukazy na vyšetření, která jsou provedena mimo interval hospitalizace, musí mít ambulantního žadatele.) | ANO |
P.419 | Kontrola vykázaného množství u ZULP. | ANO |
P.420 | Pořizování cen ZULP dle průměrných/nákupních cen. | ANO |
P.421 | Automatické přebírání účtovaných výkonů z oddělení pro vyúčtování péče. Zamezení přepisování údajů z oddělení pro vyúčtování péče. | ANO |
P.422 | Převod hospitalizačního žadatele na ambulantního. | ANO |
P.423 | Automatické nahrávání k-dávek. | ANO |
P.424 | Koderské centrum – úpravy hospitalizačních účtů. | ANO |
P.425 | Úpravy hospitalizačních případů pro potřeby CZ-DRG. | ANO |
P.426 | Podpora evidence čerpání nadstandardních služeb. | ANO |
P.427 | 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 KIS (strava, Internet, …) | ANO |
P.428 | 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. | ANO |
P.429 | Možnost jednoduchého zobrazení zadaných výkonů pacienta i při náhledu do historické dokumentace pacienta a to přímo z příslušné části dokumentace pacienta, ke které výkony přísluší. | ANO |
7.16 Fakturační modul
Fakturační modul plní požadavky zadávací dokumentace podle dále uvedených bodů:
# | Požadavek | Splňuje (ANO/NE) |
P.430 | Dodávka fakturačního modulu pro zajištění fakturace poskytnuté péče nad rámec veřejného zdravotního pojištění. | ANO |
P.431 | Fakturační modul umožní zpracování podkladů pro vydávání, storna, případně opravy faktur v ekonomickém systému. Bude se jednat o podklady pro vydávání faktur ve všech relevantních sazbách DPH za poskytnutou péči: regulační poplatky, nadstandardy, výkony nehrazené, agregace, samoplátci, hospitalizace atd. | ANO |
P.432 | Tisk účetních dokladů (faktur, potvrzení o přijetí platby). | ANO |
P.433 | Předávání podkladů pro faktury do ekonomického systému (viz integrace). Přenos pokladů pro faktury do účetního systému včetně podkladů pro faktury pro zdravotní pojišťovny – denně (viz integrace). | ANO |
P.434 | Přenos z účetnictví do NIS informace o platbě faktur (o spárování faktury s úhradou) – denně. | ANO |
P.435 | Správa ceníků pro účtování péče. | ANO |
P.436 | Import údajů o ZUM, dle specifikace do účetnictví (do vnitropodnikového dokladu). | ANO |
P.437 | Sestavy s přehledy vystavených faktur a pro potřeby finanční kontroly, dle oddělení/nemocnici, za vybrané období. | ANO |
7.17 Centrální registr pacientů
CRP splňuje požadavky zadávací dokumentace v souladu s následujícími body:
# | Požadavek | Splňuje (ANO/NE) |
P.438 | Centrální registr pacientů je v NIS NBv řešen pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.439 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o nové funkce interního referenčního registru pacientů (dále MPI) v souladu s nařízením eIDAS, který bude referenčním zdrojem identifikačních, demografických a kontaktních údajů a údajů o zdravotním pojištění všech pacientů, kteří jsou vedeni v interních produkčních informačních systémech Zadavatele, zejména v NIS a archívu elektronické zdravotnické dokumentace. | ANO |
P.440 | 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. | ANO |
P.441 | MPI bude ověřovat odpovídající údaje vůči externím autoritativním registrům, např. ARP (IDRR), ROB (IS ZR) nebo registr pojištěnců (VZP), podle toho, co bude v době realizace projektu legislativně platným autoritativním registrem. Komunikace s registry bude probíhat prostřednictvím služeb integrační vrstvy. | ANO |
P.442 | Řešení podporuje identifikaci pacientů pomocí fotografií a čárových kódů (s možností tisku čárových kódů pro nalepení na náramek pacienta) s cílem zajistit jednodušší a bezpečnější identifikaci pacientů a zabránit záměně pacientů. | ANO |
P.443 | Ř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 filtry, jako např. aktivní pacienti, neaktivní pacienti, objednaní pacienti atd. | ANO |
P.444 | Řešení musí poskytovat rozhraní interním produkčním systémům pro registraci nových pacientů, opravy nebo doplňování údajů, slučování duplicit z interních produkčních systémů a grafické uživatelské rozhraní pro manuální správu obsahu registru. | ANO |
P.445 | MPI bude poskytovat napojeným produkčním systémům (notifikované systémy) zprávu o změně v referenčních údajích pacienta a poskytovat rozhraní pro získání aktuálních referenčních údajů. | ANO |
P.446 | MPI bude připraven na zavedení bezvýznamového identifikátoru dle platné legislativy v době realizace a bude referenčním zdrojem tohoto bezvýznamového identifikátoru pro ostatní interní produkční systémy při komunikaci s externími subjekty. | ANO |
P.447 | MPI bude prostřednictvím služeb integrační vrstvy poskytovat informace externím systémům mimo NBv. Rozhraní integrační vrstvy bude podporovat IHE profily PIX a PDQ. | ANO |
P.448 | Možnost zapisovat k pacientovi významné informace, které budou součástí kmenových dat (např. alergie, předem vyslovené přání, …) | ANO |
P.449 | U jednotlivých pacientů vedení údajů o praktickém lékaři a odborných lékařích pacienta. | ANO |
P.450 | U jednotlivých pacientů vedení údajů o kontaktech (telefonní, mailový, …), osobách blízkých. | ANO |
P.451 | Generování náhradního rodného čísla, možnost identifikace cizince. | ANO |
P.452 | Možnost sloučení chybně evidovaných pacientů. | ANO |
P.453 | Kontroly správnosti RČ, čísla pojištěnce, hlídání duplicit, podobností, možnost stornování, oprav chybně zadaných dat. | ANO |
P.454 | MPI bude v souladu s GDPR uchovávat historii změn údajů, včetně autorizace změny. | ANO |
P.455 | Součástí dodávky je i naplnění MPI „vyčištěnými“ referenčními údaji z evidencí interních produkčních systémů, a pokud to bude v době realizace technicky a legislativně možné, tak i verifikovanými vůči autoritativním registrům. | ANO |
P.456 | Přístup k údajům a službám MPI pro ambulantní a hospitalizační provoz. | ANO |
7.18 Radiodiagnostika
7.18.1 Plnění požadavků zadávací dokumentace pro RIS
RIS plní požadavky zadávací dokumentace podle níže uvedené tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.457 | Radiodiagnostika je v NIS NBv řešena pomocí modulu v AMIS*H, který zůstane zachován. V případě, že dodavatel provede náhradu daného modulu, musí dodat všechny funkcionality stávajícího modulu dle dokumentace, realizovat existující integrace a zajistit migraci dat. | ANO |
P.458 | Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
P.459 | Umožnit vedení samostatných částí zdravotnické dokumentace v čistě elektronické formě, minimálně v rozsahu „radiologický nález“. | ANO |
P.460 | Systém musí být plně integrován s PACS – předávání žádanek, předávání nebo přebírání výsledků (strukturovaných popisů) a provolávání DICOM prohlížečů. | ANO |
Žádanky | ||
P.461 | Žádanka obsahuje údaje uvedené v § 3 odst. 2 vyhlášky č. 410/2012 Sb. [16] a minimálně následující údaje: 1. jednoznačnou identifikaci pacienta, 2. výšku, hmotnost a pohlaví pacienta, 3. jasnou specifikaci vyšetření (modalita a oblast), 4. klinickou diagnózu číselným kódem MKN-10, 5. indikaci – očekávaný přínos vyšetření (klinická otázka), 6. V případě, že lze předpokládat podání kontrastní látky, kontraindikace podání kontrastní látky, případně další důležité skutečnosti s tím spojené, 7. informace o graviditě, 8. informace o předchozích aplikacích radionuklidů a ionizujícího záření, které by mohly mít význam pro uvažované vyšetření nebo léčbu, 9. jméno a příjmení, podpis indikujícího lékaře a razítko pracoviště, 10. datum vystavení žádanky, případně datum objednání vyšetření, pokud je objednání k výkonu požadováno. 11. schválení indikace: jméno schvalující osoby a podpis (elektronický) Stávající forma papírové žádanky bude předána v rámci implementační analýzy, je nezbytné zachovat úplný obsah, forma bude předmětem návrhu řešení v rámci dodávky. Systém musí umožnit vytvoření a předání plnohodnotné žádanky pouze elektronicky. | ANO |
P.462 | Při zadávání žádanky automaticky zobrazit žadateli, kdy bylo u pacienta provedeno poslední stejné vyšetření. | ANO |
P.463 | Možnost zápisu žádanky na vyšetření od externích žadatelů přímo na RDG oddělení (opisem z papíru nebo skenem). | ANO |
P.464 | Pokud je u pacienta zjištěna polyvalentní alergie, asthma bronchiale, alergie na JKL automaticky upozornit zadávající osobu na tyto skutečnosti a nabídnout tabulku se speciální přípravou pacienta před vyšetřením – protialergická příprava. Systém musí umožnit správcům nastavit požadované aplikace léčiv a časování pro protialergickou přípravu, která bude nabídnuta zadávající osobě. Konkrétní výchozí požadovaných nastavení aplikací léčiv bude předáno v rámci implementační analýzy. | ANO |
P.465 | Při zadávání žádanek radiologickými asistenty u externích pacientů možnost vyhledávání a řazení pacientů a externích lékařů dle zvolených údajů (jméno, příjmení, identifikace). | ANO |
P.466 | Při vyplňování žádanky nastavit tak, aby indikující lékař nemohl pokračovat, dokud nevyplní požadované povinné údaje (např. indikace vyšetření, přínos vyšetření, co vyšetřením mám zjistit). Přesný výčet povinných údajů bude upřesněn v rámci implementační analýzy. | ANO |
P.467 | Při přijetí žádanky automaticky zobrazit na pracovišti radiodiagnostiky, kdy bylo u pacienta provedeno poslední stejné vyšetření. | ANO |
P.468 | V případě, že se jedná o nového pacienta nebo bylo poslední vyšetření provedeno v minulých letech, tak při přebírání žádanky a plánování | ANO |
provedení výkonů (t.j. přebírání žádanky radiologickým asistentem) automatické vytvoření nového čísla obálky pro aktuální rok. Toto se nevztahuje na případy, kdy již pacient má přiděleno číslo obálky pro aktuální rok. | ||
P.469 | Na žádance automaticky zobrazovat dostupné údaje pacienta – min. alergie na JKL, asthma bronchiale, polyvalentní alergie, chladová alergie, DM, PAD, hodnotu kreatininu, koagulace. | ANO |
P.470 | Při potvrzení přijetí žádanky provést záznam do plánu vyšetření a potvrzení termínu žadateli. | ANO |
Objednávání na vyšetření a plán vyšetření | ||
P.471 | Dodávka plánovacího nástroje pro tvorbu plánu vyšetření. | ANO |
P.472 | Nástroj umožní nastavit limity (počty) vyšetření. | ANO |
P.473 | Nástroj umožní nastavit limity (počty) vyšetření pro jednotlivá oddělení NBv a externí žadatele. Současně umožní tyto limity omezit na vybraná časová období. | ANO |
P.474 | V plánu vyšetření zobrazovat ambulantní a hospitalizované pacienty na jedné obrazovce. | ANO |
P.475 | Možnost přednastavit časy vyšetření po 15 minutách. | ANO |
P.476 | Možnost zablokovat časy pro akutní vyšetření a iktový program, intervence – bez možnosti zadání žádanek na tyto časy z oddělení a ambulancí. | ANO |
P.477 | Parametry plánovače (limity, blokované časy, doby apod.) bude možné nastavovat pracovníky radiologie. | ANO |
P.478 | Možnost náhledu na plán operací na operačních sálech pro potřeby plánování výkonů v rámci operací. | ANO |
P.479 | Možnost zobrazení naplánovaných časů vyšetření k danému pacoentovi z jiných oddělení. | ANO |
Vyšetření / nálezy | ||
P.480 | Umožnit tisky legislativně případně nemocnicí požadovaných dokumentů nad rámec společných dokumentů: 1. souhlas pacienta s ionizujícím zářením 2. souhlas pacienta s aplikací kontrastní látky apod. V seznamu dokumentů zobrazit nejprve specifické dokumenty a až následně ostatní (společné) dokumenty. | ANO |
P.481 | Možnost nahlížet do dokumentace pacienta při zápisu nálezu. | ANO |
P.482 | Možnost přednastavení standardních popisů a jejich kopírování/vkládání do nálezu. | ANO |
P.483 | Možnost prohlížení historických RDG nálezů při popisu snímků a jejich kopírování do nového nálezu. | ANO |
P.484 | Komunikace s PACS (a modalitami) formou vytváření pracovních listů (worklistů) modality. | ANO |
P.485 | Komunikace s PACS – zajištění komunikace nemocničního informačního systému se stávajícím PACS systémem, a to prostřednictvím worklistů. NIS musí umožňovat: 1. automatické sestavení „worklistu“ na základě žádanky v NIS a jeho odeslání v požadovaném formátu na server PACS, 2. textový popis vyšetření bude vytvářen v NIS a ukládán do databáze NIS, následně bude v NIS přenesen do nálezu. 3. spuštění prohlížeče snímků v PACS z NIS s předáním parametrů pro vyhledání konkrétní obrazové studie nebo všech studií pacienta. 4. Zobrazení žádanky a údajů pacienta v NIS ve formě odkazu z PACS. | ANO |
P.486 | Možnost diktovat nález a hlasový záznam automaticky převádět na psaný text do dokumentace pacienta (např. s použitím externího programu). | ANO |
P.487 | Pro popisujícího specialistu možnost náhledů všech vyšetření, epikrízy apod. | ANO |
P.488 | Možnost kontroly nálezu a potvrzení správnosti nálezu, záznam jak zpracovatele nálezu, tak kontrolující osoby. | ANO |
P.489 | Přehled nálezů / vyšetření (popisů) včetně stavu zpracování (rozpracován, dokončen, zkontrolován, potvrzena správnost, uvolněn). | ANO |
Ostatní požadavky | ||
P.490 | Po provedení kontroly a případných úprav seznamu provedených výkonů a materiálu, automatické vyúčtování výkonů a zadaného materiálu dle provedeného vyšetření. | ANO |
P.491 | V případě, že proběhla pitva, možnost zobrazení výsledků pitvy. | ANO |
7.19 Rehabilitační modul
Tento modul je integrální součástí NIS AMIS*HD a umožňuje plnohodnotnou práci rehabilitačního oddělení pro práci s hospitalizovanými i ambulantně přijímanými pacienty, stejně tak jako i pacienty, kteří přicházejí do zdravotnického zařízení s poukazem na rehabilitační ošetření vystaveným externím žadatelem.
7.19.1 Základní funkcionality rehabilitačního modulu
Základními funkcionalitami rehabilitačního modulu je:
• Možnost zpracování ambulantních i hospitalizovaných pacientů ve všech aspektech činností
• Vedení zdravotní dokumentace pacientů s možností vedení v čistě elektronické podobě
• Plánování a časování procedur s vazbou na registr pacientů a na seznam poskytovaných rehabilitačních procedur a dostupného zařízení (strojů)
• Příjem elektronických žádanek z jiných částí NIS AMIS*HD a ručního zadání externě vystavené žádanky s kontrolou povinně požadovaných údajů na žádance
• Možnost využití standardní ambulantní čekárny se všemi jejich funkcionalitami (viz Ambulance – ordinace / čekárna)
• Vedení fyzioterapeutických záznamů pacientů
• Vedení textového nebo strukturovaného záznamu průběhu procedur s možností strukturovaný záznam modifikovat správcem systému bez nutnosti dodavatelského zásahu
• Provozní sestavy potřebné pro práci terapeutů (rozpis pacientů a jejich procedur na den nebo období podle pracoviště, terapeuta, zařízení)
• Sestava plánovaných procedur pro pacienta pro jeho orientaci
• Pokročilé plánování procedur umožňující hromadné objednávání, kopírování na další období, kontrolu vytíženosti jednotlivých zařízení atd.
• Možnost ruční úpravy plánu procedur podle přání pacienta s ohledem na volné kapacity terapeuta a dostupné zařízení
• Podpora automatického vykazování výkonů s vazbou na terapii / pracoviště
• Možnost poskytování a vykazování procedur nad rámec veřejného zdravotního pojištění
• Přehledy vytížení pracovišť, terapeutů nebo zařízení, počtu pacientů, diagnóz apod.
• Tisk potřebných provozních sestav i statistických přehledů
• Převod vykázaných výkonů do modulu pojišťovny, kde je možné jejich sledování a vyhodnocování
7.19.2 Plnění požadavků zadávací dokumentace pro rehabilitaci
Rehabilitační modul plní požadavky zadávací dokumentace uvedené v následující tabulce:
# | Požadavek | Splňuje (ANO/NE) |
P.492 | 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ů. | ANO |
P.493 | Systém umožní pracovat s pacientem ambulantním i hospitalizovaným. | ANO |
P.494 | Přístup ke kompletní dokumentaci pacienta, včetně radiologických výsledků a obrazové dokumentace. | ANO |
P.495 | Možnost vyžádání konzilia rehabilitačního lékaře a záznam konzilia. | ANO |
P.496 | Elektronické zasílání žádanky (procedury, konzilia) z ostatních oddělení nemocnice (ambulance i hospitalizace). Součástí žádanky musí být požadované procedury, informace o místě, času a způsobu poskytnutí (ambulance rehabilitace, lůžkové oddělení). Vnitřní žádanka musí odpovídat vnitřní metodice nemocnice (bude předána v rámci implementační analýzy). | ANO |
P.497 | Možnost zápisu žádanky nebo poukazu od externích žadatelů přímo na oddělení (opisem z papíru nebo skenem). | ANO |
P.498 | Rehabilitace (fyzioterapie x ergoterapie) na lůžcích akutní rehabilitační péče a na lůžkových odděleních ostatních oddělení. Možnost zadávání do dokumentace nejen na oddělení rehabilitace, ale i na ostatních odděleních. | ANO |
P.499 | Zobrazení denní a týdenní objednávky pacientů pro daného fyzioterapeuta nebo ergoterapeuta s možností tisku a poznámky pro další návštěvu např. TEJP. | ANO |
P.500 | Ucelené řešení pro fyzioterapie – provázanost lékařské dokumentace, naplánování procedur, zápisů fyzioterapeutů (denní zápisy), kontrolní vyšetření. 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. | ANO |
P.501 | Systém musí zahrnovat významné úkony rehabilitační medicíny pro účely: 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í. | ANO |
P.502 | Při plánování procedur: 1. umožnit hromadné objednání, svázání objednávek 2. možnost nastavení standardních skupin procedur 3. kontrola možné četnosti dle metodiky VZP 4. umožnit přihlédnout k přání pacienta, kdy chce procedury absolvovat | ANO |
5. efektivní naplánování rehabilitačních procedur pacienta za pomoci grafické vizualizace v diáři 6. barevné odlišení jednotlivých procedur 7. jednotlivé procedury se nesmí překrývat 8. možnost společného objednávání procedur stejného pacienta tak, aby na sebe navazovaly (např. cvičení a elektroléčba). 9. jednoduché změny v naplánovaných procedurách s evidencí důvodu změny (nemoc pacienta apod.). | ||
P.503 | 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. | ANO |
P.504 | Časování s týdenním rozpisem a automatickým rozplánováním: 1. Tisk rozpisu procedur pro pacienta, který musí obsahovat co si má pacient vzít s sebou a podmínky omlouvání a kontaktní telefony, případně email 2. Vlastní časování 3. Možnost konfigurace diáře a šablon | ANO |
P.505 | Požadavky na objednávací systém: 1. Objednání pacientů na vyšetření včetně kontrolního k rehabilitačnímu lékaři. 2. 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. 3. Systém je schopen kombinovat cvičebnu pro individuální terapii s ostatními procedurami a nabízet nejbližší vhodný termín. | ANO |
P.506 | 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. | ANO |
P.507 | Přehledně zobrazovat vytíženost pracovišť, strojů, fyzioterapeutů. | ANO |
P.508 | Umožnit automatické vykázání potřebných výkonů po odcvičení včetně kódů. Možnost zadání a rozlišení pacient omluven/neomluven. | ANO |
P.509 | Rehabilitační dokumentace (denní záznam): použití přednastavených textů, každého fyzioterapeuta a ergoterapeuta. | ANO |
P.510 | Možnost zadání do systému následujících formulářů pro konkrétního pacienta a záznam do zdravotnické dokumentace: • • Index/test Barthelové • • Rozšířený Barthelové test • • Vyšetření celkové hybnosti páteře Součástí je nejen zadávání do NIS, ale i tisky příslušných protokolů/formulářů. Formuláře budou poskytnuty v rámci implementační analýzy. | ANO |
P.511 | Po uzavření záznamu automatické vykazování poskytnuté péče (viz kap. 3.3.16). | ANO |
P.512 | 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 | ANO |
P.513 | Tisk potřebných dokumentů: 1. rozpis pro pacienta 2. Přehled plánovaných pacientů objednaných na dané pracoviště 3. Zdravotní dokumentace a. zápisy lékařů, fyzioterapeutů b. výpis zdravotní dokumentace pro komerční pojišťovny – docházka pacienta a lékařské vyšetření. | ANO |
P.514 | Umožnit tisky legislativně případně nemocnicí požadovaných dokumentů nad rámec společných dokumentů: 1. Poučení o vyšetření / ošetření – vyšetření per rectum, mobilizace per rectum, pir a presura svalstva pánevního dna per rectum palpační vyšetření pánevního dna vaginálně 2. Poučení o vyšetření / ošetření – elektrostimulace a myofeedback – terapie poruch svalstva pánevního dna za použití vaginálních nebo rectálních stimulačních a registračních sond 3. Poučení o vyšetření / ošetření – canisterapie 4. Poučení o vyšetření / ošetření – sportovní fyzioterapie a podologie v rámci prevence a reedukace pohybových stereotypů 5. Kineziologický rozbor – vyšetření pánevního dna 6. Kineziologický rozbor – centrální parézy 7. Svalový test 8. Svalový test obličeje 9. Hodnocení psychického stavu 10. Xxxxxx Hip Function Scale 11. Xxxxxxxxxx bodové skóre 12. XxXxxxxx vyšetřovací spis bederní páteř 13. XxXxxxxx vyšetřovací spis bederní páteř kontrolní 14. XxXxxxxx vyšetřovací spis hrudní páteř 15. XxXxxxxx vyšetřovací spis hrudní páteř kontrolní 16. XxXxxxxx vyšetřovací spis krční páteř 17. XxXxxxxx vyšetřovací spis krční páteř kontrolní 18. Xxxxxxxx dotazník - hodnocení bolesti 19. Bergova funkční škála rovnováhy 20. Borgovo skóre dušnosti 21. Hodnocení pohyblivosti podle X. Xxxxxxx 22. Modifikovaná Ashworthova škála 23. Screenig poruch polykání GUSS V seznamu dokumentů zobrazit nejprve specifické dokumenty a až následně ostatní (společné) dokumenty. Formuláře budou poskytnuty v rámci implementační analýzy. | ANO |
P.515 | Umožnit statisticky sledovat vykázané výkony, resp. platby pacientů | ANO |
P.516 | Jednoduchá správa nastavení: možnost zadání kapacity pracoviště a přístroje, pracovní doby pracoviště, uzavření pracoviště a částečné uzavření pracoviště: sanitární den, nemoc apod. | ANO |
P.517 | Jednoduché změny v naplánovaných procedurách s evidencí důvodu změny: nemoc pacienta, nemoc fyzioterapeuta – odvolání, přeobjednání a objednání na hospitalizaci pacienta apod. Oznámení změny prostřednictvím SMS a emailu. | ANO |
P.518 | Připravenost systému a nastavení pro rehabilitační pracoviště uvedená v kap. 6.4.3 – Rehabilitace. Možnost administrátorského doplnění pracovišť, přístrojů a nastavení časovek a způsobu objednávání. | ANO |
P.519 | Elektronická evidence použití zdravotnických prostředků podléhajících evidenci (II b) – např. elektroléčba. | ANO |
P.520 | Přístup vedoucího k dokumentaci a výkonům podřízených pro provádění kontroly. | ANO |
7.20 Strukturovaná medikace a evidence podaných léků
Podpora medikačního procesu je dána použitím a komunikací či integrací jednotlivých prvků Lékového workflow, do kterého patří mimo jiné moduly Strukturovaná medikace a Evidence podaných léků, ideálně propojených ještě s modulem Příruční sklady a IS Lékárny.
7.20.1 Strukturovaná medikace
Strukturovaná medikace – používání modulu je jedním z předpokladů efektivního využití nástrojů v rámci Lékového workflow (do kterého dále patří moduly Evidence podání léku a Příruční sklady). Přehled základních vlastností modulu:
• Možnost nastavení priority pro zobrazení léků (dle nastavení v číselníku léků), které
vyhovují zadanému řetězci při vyhledávání léku. Je možno nastavit prioritní zobrazení pro hledání z číselníku HVLP dle:
o stavu skladové zásoby na příslušném příručním skladu pracoviště – prioritně se tedy zobrazují ty léky, vyhovující zadanému vyhledávanému řetězci z názvu, které jsou v příručním skladu v nenulové zásobě
o zařazení léku do nemocničního hospitalizačního pozitivního listu – prioritně se tedy zobrazují ty léky, vyhovující zadanému vyhledávanému řetězci z názvu, které jsou zařazeny do nemocničního hospitalizačního pozitivního listu
• Výběr léku dle ATC skupiny – po stisku odpovídajícího tlačítka se zobrazí s léky se stejnou ATC skupinou jako lék, na kterém stojí kurzor, v prvním kroku opět dle výše uvedené nastavené priority (tedy dle stavu skladové zásoby na příručním skladu nebo dle příslušnosti do nemocničního hospitalizačního pozitivního listu), v druhém kroku pak ze všech léků v číselníku HVLP.
• Možnost výběru dle ATC skupiny: po vyhledání určitého léku v číselníku je možno pomocí příslušného tlačítka vyhledat všechny léky, obsahující stejnou účinnou látku podle ATC skupiny (u každého léku je opět signalizována příslušnost k nemocničnímu hospitalizačnímu pozitivnímu listu a stav skladové zásoby léku na příslušejícím příručním skladu).
• Pro ordinaci léků je možno zapnout přímou integraci kontroly lékových interakcí (VIP InfoPharm): po uložení všech léků jsou křížově prověřeny všechny interakce naordinovaných léků a dle nastavené úrovně je v případě zjištěných interakcí převyšujících zvolenou hranici upozorněno varovným hlášením. Kontrolu je možno spustit i kdykoliv dle potřeby „ručně“.
• Podpora nemocničních hospitalizačních pozitivních lékových listů. Tento číselník, umožňuje vytvoření a posléze udržování nemocničního hospitalizačního pozitivního listu, který přednostně při výběru nabízí léky do něj zařazené a v případě použití léku mimo pozitivní list je požadováno zapsání důvodu použití léku mimo pozitivní list ordinujícím lékařem, resp. vybrání důvodu z číselníku.
• Výpočet denního množství naordinovaného léku: při zadání ordinace obvyklým zápisem léku, např. IBALGIN 600 1-1-1 tbl., je dopočítáno a zobrazeno celkové ordinované denní množství léku, tedy 3 tbl.
• Signalizace skladové zásoby ordinovaného léku v příručním skladě příslušného pracoviště v přehledu naordinovaných léků: léky s nenulovou skladovou zásobou jsou označeny symbolem „+“, léky, které nejsou na skladě pak symbolem „-“Pokud příslušné pracoviště není napojeno na příruční sklad, není zobrazen žádný symbol (resp. ve skutečnosti je na daném místě zobrazena mezera). Při vyhledávání léku z číselníku léků z číselníku je analogické zobrazení u vybraných léků ve sloupečku „Sk“. Sloupeček „Poz“ pak signalizuje ty léky z výběru, které jsou zařazeny v nemocničním hospitalizačním pozitivním listu (u zařazených je písmeno „P“). Analogické informace jsou zobrazovány také při prodlužování léků či při vytváření první medikace z farmakologické anamnézy – trvalé medikace pacienta
• Při ordinaci je možno nastavit odkdy – dokdy je ordinace platná – defaultně je to od 24 hod do 24 hod, pokud je nastaveno jinak, je to vyznačeno na obrazovce přehledu ordinovaných léků.
• Možnost označení vnesených léků: léky, které má pacient z vlastních zásob, mohou být označeny jako „vnesené“ a při evidenci jejich podání čtečkou není odečteno příslušné množství ze zásoby příručního skladu. Tyto vnesené léky jsou pak v přehledu medikace označeny písmenem „V“
• Možnost zadání strukturované poznámky k podání (má 3 části - příprava, rozpis, pokyny): pro upřesnění způsobu přípravy léky, jeho rozpisu, zápisu pokynů pro podání byly vytvořeny textové informace, které ordinujícímu lékaři dovolují zadat tato upřesnění. Tyto detailnější informace jsou zadávány i zobrazovány na tlačítko a obsahují také další informace – podmíněné podání – viz dále. Doplňující informace k léku či podmíněné podání jsou signalizovány na obrazovce přehledu léků vykřičníkem.
Možnost strukturovaného zápisu podmíněného podání léku: je možno zadat podmínku, která musí být splněna pro podání léku (lze využít číselník podmínek), dále je možno definovat minimální odstup mezi dvěma podáními a maximální denní dávka léku – při evidenci podávání léku přes čtečku může tak být uživatel upozorněn při nedodržení časového odstupu podání či při překročení maximální denní dávky (viz modul Evidence podaných léků)
7.20.2 Evidence podaných léků
Evidence podaných léků (EPL) – modul, jehož cílem je pomoci při bezpečném podávání léčiv, evidenci a kontrole prostřednictvím NIS AMIS*HD. Má vyloučit chyby při podávání léků, umožnit kontrolu exspirací a časování léčiv. Modul je možno rozdělit na tyto části:
• Evidence podání léků pomocí inteligentní čtečky čárových kódů
• případnou následnou editaci dat o podaném léčivu v části „EPL Editor“ (zpravidla pouze pro privilegované uživatele: staniční a vrchní sestry)
• možnost různých tiskových výstupů o podaných lécích v části „EPL Reporty“
Modul obsahuje tyto funkčnosti:
• načtení identifikace uživatele (možno načíst čárovým kódem nebo ručním zadáním z klávesnice, nutné ještě potvrzení pomocí PIN
• načtení identifikace pacienta (zpravidla čárovým kódem z náramku pacienta)
• zobrazení ordinace pro aktuální časový úsek pro vybraného pacienta (pokud je ordinace vedena strukturovaným způsobem v modulu Strukturovaná medikace)
• evidence podání léku načtením čárového kódu s identifikací léku
• případná oprava množství podaného léku (např. pokud není vedena ordinace ve strukturované podobě)
• aplikace na čtečce upozorňuje personál na případné nesrovnalosti ze strukturované ordinace – např. pokud neodpovídá minimální časový rozestup mezi dvěma podáními, či byla překročena maximální denní dávka (u tzv. podmíněného podání)
• umožňuje podání a evidenci „vnesených“ léků (např. speciálních léků přinesených pacientem)
• umožňuje evidovat „nepodání“ léků a důvody nepodání (pacient zvrací, nepřítomen, apod.)
• umožnuje na čtečce zobrazení přehledu podaných léků
• zobrazení/tisk přehledů (u všech možno zadat období od-do): podané léky pro pacienta, podané léky na pracovišti, sumární spotřeba léků pro pacienta, sumární spotřeba léků na pracovišti
• pokud je modul EPL napojen na modul Příruční sklady, je při evidenci podání daného léku pro pacienta na čtečce automaticky odepsáno příslušné podané množství léku z odpovídajícího Příručního skladu
Součástí modulu Ambulance je část Recepty a poukazy, umožňující vystavení všech druhů a typu receptů a poukazů, včetně hlídání preskripčních a indikačních omezení. Výběr léků HVLP umožňuje nastavení ambulantních pozitivních listů nemocnice či zdravotních pojišťoven. Je podporována taktéž agenda schvalování revizními lékaři (zvýšená úhrada atd.)
7.20.3 Plnění požadavků zadávací dokumentace na strukturovanou medikaci a evidenci podaných léků
Strukturovaná medikace a evidence podaných léků splňují požadavky zadávací dokumentace podle níže uvedené tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.521 | 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. | ANO |
P.522 | Je požadováno napojení na ústavní lékárnu a příruční sklady na lůžkových odděleních, poskytování informací o dostupnosti daného léčiva na skladu a informace o lécích na pozitivním listu. | ANO |
P.523 | Ordinace léčivého přípravku různých ordinačních skupin. | ANO |
P.524 | Preskripční omezení pro léky s preskripčním omezením: 1. umožnit ordinaci léčiv jen lékařům s odbornostmi, které ordinaci daného léčiva mohou provádět. 2. Umožnit ordinaci léčiv jen na indikace, pro které jsou určeny. V případě nesplnění těchto podmínek bude lékaři umožněno předepsání léčiva jen po explicitním zadání důvodu předepsání. | ANO |
P.525 | Ordinace infuzí, automatický výpočet délky podání a rychlosti podání infuze s možností ruční změny parametrů. | ANO |
P.526 | Indikace léků, pomůcek a materiálu, které vyžadují schválení revizním lékařem zdravotní pojišťovny. V případě výběru takového léku dotázání uživatele, zda je zajištěn souhlas revizního lékaře a zda chce tedy předepsat. Následné možnosti dalšího postupu: 1. Nebude předepsáno 2. Možnost vyplnění žádanky o schválení/ povolení – žádost na pojišťovnu k posouzení reviznímu lékaři o schválení úhrady 3. Potvrzení, že byla schválena úhrada pojišťovnou a předepsání Záznam výsledku do dokumentace pacienta, včetně dokumentů. | ANO |
P.527 | Možnost výběru náhradního léku dle ATC skupiny. | ANO |
P.528 | Možnost výběru léků z léků dostupných na oddělení nebo v nemocnici (klinické sklady, lékárna). | ANO |
P.529 | V případě výběru léku mimo pozitivní list, nutnost explicitního odůvodnění výběru tohoto léku. | ANO |
P.530 | Ukončení podávání léků – ex léku. | ANO |
P.531 | Prodloužení platnosti ordinovaných LP na definované období. | ANO |
P.532 | Kontrola a upozornění na lékové interakce – zjišťování lékových interakcí pomocí integrace se systémem „Kontrolní modul lékových interakcí DrugAgency, a.s.“ (Vademecum Infopharm), včetně dodávky tohoto systému a aktualizací. | ANO |
P.533 | Vložení informace o ordinovaných LP do dokumentace pacienta. | ANO |
P.534 | Ordinované medikace budou k dispozici na mobilním zařízení (inteligentní mobilní čtečka), kde v rámci aplikace v mobilním zařízení budou k dispozici veškeré potřebné informace pro sesterský personál, potřebné ke správnému a kompletnímu podání ordinovaných léčiv pacientovi. | ANO |
P.535 | Na základě přečtení identifikace pacienta čárovým kódem aplikace poskytne sestře informace o požadovaných ordinacích v daném čase včetně podmíněného podání, množství, formě, jednotek, informace o vnesených léčivech, maximální denní dávce a doplňujících informacích k podání. | ANO |
P.536 | V případě vyhledávání léčiv možnost zadání jen části názvu s nabídkou léčiv, která odpovídají názvu a možností vybrat. | ANO |
P.537 | Poskytnutí informací o již realizovaných podáních v rámci ordinačního období (platnosti dekurzu). | ANO |
P.538 | Přečtením čárového kódu z balení léku se dané léčivo načte v aktuální šarži, provede se kontrola na expiraci léku a sestra bude vyzvána k potvrzení podání a jeho množství, případně k doplnění informace o nepodání a vyplnění zdůvodnění nepodání. | ANO |
P.539 | Po úspěšném potvrzení podání systém automaticky odepíše podané množství daného léku správné šarže z příručního skladu oddělení a zapíše potvrzení podání do dokumentace v NIS. | ANO |
P.540 | Tisk ordinovaných LP jako součást dekurzu pacienta. | ANO |
P.541 | Možnost vložení předdefinovaných medikací (skupiny léků, složené infúze). | ANO |
P.542 | Podpora vedení trvalé medikace pacienta. | ANO |
P.543 | Systém umožní elektronickou evidenci podání léků on-line pomocí inteligentní mobilní čtečky u lůžka pacienta. Po identifikaci pacienta se na mobilní aplikaci vypíšou ordinované léky a sestra má možnost je načíst čtečkou čárových kódů a evidovat jejich podání až na konkrétní šarži. | ANO |
P.544 | Po načtení identifikace pacienta zobrazí seznam léků k podání v daný čas. | ANO |
P.545 | Po načtení léku zobrazí detail o podávaném léku, předpis podání, informace o již podaném množství z celkového množství k podání, množství k podání v daném okamžiku, informace, zda se jedná o vnesený lék. | ANO |
P.546 | Možnost zadat cílené nepodání léku s uvedením důvodu nepodání. | ANO |
P.547 | Možnost podat nenaordinovaný lék – aplikace upozorní, že se jedná o nenaordinovaný lék. | ANO |
P.548 | Aplikace umožní výpis všech podaných léků pacientovi. | ANO |
P.549 | Možnost vygenerování a vytištění rozpisu léků pacientovi při odchodu z nemocnice pro následné užívání. | ANO |
P.550 | Vedení opiátové knihy v souladu s vyhláškou č. 123/2006 Sb. | ANO |
P.551 | Možnost zadání vnesených léků do dokumentace pacienta z kteréhokoliv přijímajícího pracoviště. | ANO |
P.552 | Možnost načítání číselníků léčiv ze SÚKL i z VZP. | ANO |
P.553 | Možnost zobrazení informací o léčivých přípravcích v NIS z informačního systému léčivých přípravků (AISLP), možnost i odkazem do AISLP. Předplatné AISLP zajistí Objednatel. | ANO |
7.21 Příruční sklady léků
Modul je příruční sklady léků je plně integrován s těmito součástmi:
• Strukturovaná medikace
• Evidence podání léků pacientovi
• Centrální skladová evidence a řízení nákupu léků a SZM
• Lékárna – integrace se sw pro lékárnu dle požadavků zadavatele
Systém přináší dále tyto výhody:
• Automatický odpis léku ze zásob při podání čtečkou
• Automatický příjem na sklad oddělení na základě komunikace s centrálním skladem
• Vystavení žádanky na nákup léků z oddělení
• Přesná skladová evidence zásob
• Výrazné a měřitelné finanční úspory
• Zlepšení vztahů s dodavateli
• Zlepšení lékové politiky celého ZZ
Modul Příruční sklady léků splňuje požadavky zadávací dokumentace podle následující tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.554 | Centrální sklady léků a zdravotnického materiálu v IS Lékárna jsou bez důležitých vazeb na NIS, musí proto plně komunikovat s klinickými sklady v NIS NBv. NIS proto musí podporovat komunikaci se sklady a logistikou zdravotnického materiálu mimo NIS (integrace na IS Lékárna). | ANO |
P.555 | Přebírání vnitřní identifikace LP a SZM z externího systému (IS Lékárna) a využití této identifikace v modulech NIS s pomocí čteček čárových kódů. Upozorňujeme, že čárové kódy bude přidělovat centrální systém pro vedení skladů a logistiky LP a SZM (IS Lékárna) a není možné využít jiný kód. S čárovým kódem bude jednoznačně propojena informace o LP/SZM a jeho atributech (množství, šarže, expirace). | ANO |
P.556 | Systém musí umět vydávat do spotřeby položky evidované jak na skladu SZM, tak na klinických (příručních) skladech oddělení (realizace těchto klinických/příručních skladů je součástí tohoto projektu). Musí být zajištěna synchronizace číselníku zboží SZM. Informace o výdeji musí být využitelná 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. | ANO |
P.557 | 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 dle 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í. | ANO |
P.558 | Záznam předepsaných SZM a LP do dokumentace pacienta. | ANO |
P.559 | Žádanky z oddělení na SZM, MTZ a služby budou řešeny v NIS a po schválení předávány do systému skladů a logistiky SZM a LP mimo NIS, kde budou vyřízeny. | ANO |
Číselníky |
P.560 | 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. | ANO |
Doklady pohybů | ||
P.561 | Požadavky pro dané oddělení – sepsání požadavků před objednáním, sestavení požadavků dle ordinovaných léků | ANO |
P.562 | Centralizace žádanek z oddělení. | ANO |
P.563 | Schválení žádanky oprávněnou osobou | ANO |
P.564 | Převod do jiného skladu – přeskladnění zboží – 1. fáze: vyskladnění, možnost vytvořit dle požadavku | ANO |
P.565 | Převod z jiného skladu – přeskladnění zboží – 2. fáze: naskladnění, automatické naskladnění, ruční naskladnění | ANO |
P.566 | Příjem / zaevidování pacientem donesených léčivých přípravků (s provázáním s ordinovanou léčbou) | ANO |
P.567 | Výdej: 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 expirovaného a znehodnoceného zboží. 5. Výdeje / vrácení donesených léků pacientovi. | ANO |
Podpora činností ve skladu na oddělení | ||
P.568 | Evidence stavu a pohybu léků, zdravotnického materiálu, prostředků zdravotní techniky a dalšího zboží (včetně tzv. neměřitelných přípravků – kapky, masti). | ANO |
P.569 | Sledování expirací, zkracování expirací při otevření přípravku. | ANO |
P.570 | Komunikace s ekonomickými systémy a se systémem Lékárna, včetně aktualizace číselníků položek a elektronického avíza dodávky z centrálního skladu na klinický sklad. | ANO |
P.571 | Využívání čárového kódu pro příjem, výdej a inventuru | ANO |
Inventarizace zboží | ||
P.572 | 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. | ANO |
Výstupy | ||
P.573 | Provozní a ekonomické sestavy. | ANO |
Ostatní požadavky | ||
P.574 | Možnost opravy položek v příručním skladu pro oprávněné uživatele z oddělení. | ANO |
7.22 Registrační autorita a kvalifikovaný elektronický podpis
Implementace kvalifikovaného elektronického podpisu v kombinaci s použitím registrační autority zajistí minimálně tyto funkcionality požadované zadávací dokumentací:
# | Požadavek | Splňuje (ANO/NE) |
P.575 | Integrace NIS na registrační autoritu NBv (RA) a přebírání elektronických podpisů z RA do NIS pro podepisování EZD. | ANO |
P.576 | Rozšíření NIS o zapojení uznávaného elektronického podpisu do procesů zpracování EZD. | ANO |
P.577 | 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. | ANO |
P.578 | Implementace uznávaného elektronického podpisu v oblasti podepisování EZD. | ANO |
7.23 Databáze NIS AMIS*H/HD
Systém AMIS*H/HD je provozován na databází Informix společnosti IBM.
Server Informix podporuje objektově relační model, který společnosti IBM umožnil nabízet rozšíření podporující datové typy, které přesahují standard SQL. Nejrozšířenější z nich jsou časové řady a prostorová rozšíření, která poskytují jak podporu typu dat, tak jazykové rozšíření, které umožňují vysoce výkonné dotazy specifické pro domény a efektivní ukládání datových sad na základě časových řad a prostorových dat.
Databáze Informix provozovaná na serveru linux centos je plně zabezpečené řešení a poskytuje nejvyšší možný stupeň ochrany uživatelských i pacientských dat. Na databázích informix jsou provozovány velké informační systémy v celosvětovém měřítku (např. ekonomický systém SAP).
7.23.1 Plnění požadavků zadávací dokumentace na databázi NIS AMIS*H/HD
V souladu se zadávací dokumentace plní databáze NIS AMIS*H/HD následující požadavky:
# | Požadavek | Splňuje (ANO/NE) |
P.579 | Technologie musí respektovat prostředí zadavatele – viz kap. 6.5.6 – Technologie využívané objednatelem. | ANO |
P.580 | Databáze musí být zabezpečena tak, aby systém plnil požadavky uvedené v příslušné kapitole zadávací dokumentace | ANO |
7.24 Auditování systému
Jednotlivé systémy na aplikační úrovni umožňují monitorovat a sledovat některé činnosti a změny včetně jejich zpracování na úrovni hlášení, reportů a výstupů. Tyto výstupy je možno zpřístupňovat libovolným uživatelům na základě definice přístupových práv k těmto funkcím a po jejich vytvoření jsou chráněny před neoprávněnou manipulací. Řešení podporuje agregaci dat, korelace, alerting a compliance.
V klinické části systému - v rámci transakčního protokolů je zapojeno sledování těchto činností:
• Veškeré změny v registru pacientů v obsahu kdo, kdy a co, včetně vedení historie všech základních údajů o pacientovi v registru;
• Sledování přístupů k lékařské dokumentaci v rozsahu kdo, kdy, co ve struktuře:
• zjištění zda existuje na oddělení dokumentace (zda byl pacient na oddělení hospitalizován nebo ambulantně ošetřen)
• otevření dokumentace k pacientovi
• tisk dokumentu
• Sledování stavu životního cyklu žádanky v rozsahu podání žádanky, přebrání žádanky, vyhotovení výsledku (předběžného, částečného, úplného), přebrání výsledku.
vždy s uvedením příznaků - časový údaj, uživatel, role, pracoviště, pracovní koncové zařízení. Na systémové úrovni jsou sledovány:
• změny v přístupových privilegiích
• změny mechanismů autorizace a autentizace
• změny v jádru systému (systémová integrita)
• jednotlivé relace (přihlášení, odhlášení uživatelů s časem, koncovým zařízením, pracoviště, modul systému).
• události privilegovaných (správcovských účtů), včetně možnosti alertování
• změny uživatelských etalonů přístupových práv
• chybová a varovná hlášení jednotlivých komponent systému (chyba, update, nestabilita, spuštění, zastavení, změna atd.…) včetně volitelného e-mail alertingu.
Kromě těchto aplikačních funkcí je celý systém koncipován tak, že většina záznamů je podepisována služebními údaji v rozsahu, kdo a kdy provedl update záznamu. Tyto údaje jsou ve většině případů přímo viditelné z aplikačních formulářů dané oblasti, a navíc je možné je pak na úrovni správce v plné šíři vyhodnocovat. Uzavřené dokumenty v systému nelze uživatelsky vymazat, běžnými uživateli je možno pouze vkládat upřesňující dodatky. Další možností v rámci monitoringu v místech, která v současnosti nejsou implementována, je kromě aplikačního dopracování využití funkčnosti relační databáze, a to konkrétně aplikací triggerů, které mohou sledovat libovolné databázové operace a spouštět libovolné auditní funkce.
Veškeré údaje je možno exportovat do formátů xls / csv pro další zpracování.
7.24.1 Plnění požadavků zadávací dokumentace na oblast auditování systému
Auditování systému plní požadavky zadávací dokumentace v rozsahu níže uvedené tabulky:
# | Požadavek | Splňuje (ANO/NE) |
P.581 | 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ů. | ANO |
P.582 | Řešení umožní poskytovat auditní reporty o přístupech uživatelů (kdo, kdy, období, kam). | ANO |
P.583 | 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. | ANO |
P.584 | 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. | ANO |
P.585 | Auditní systém musí být v souladu s nařízení EU o ochraně osobních dat (GDPR). | ANO |
7.25 Manažerský informační systém (MIS)
Součástí řešení je modul MIS, který pracuje přímo s daty produkovanými jednotlivými funkčními částmi NIS AMIS*H/HD a poskytuje řadu informací nezbytných pro řízení zdravotnického zařízení.
Manažerský informační systém ICZ pro oblast zdravotnictví reaguje na dlouhodobou potřebu managementu zdravotnických zařízení mít k dispozici důležité údaje pro zajištění maximálních
příjmů organizace při minimalizaci rizik případných ztrát a dále disponovat nástrojem pro efektivní řízení nákladovosti organizace.
MIS nabízí maximálně kvalitní komplexní nástroj pro rutinní vykazování a účtování zdravotní péče. Součástí je reporting zaměřený na maximalizaci výnosů a minimalizaci rizika možných ztrát.
Tento reporting byl doplněn dalšími oblastmi důležitými z pohledu nákladovosti – ekonomickými údaji, přiřazením nákladů metodou Activity Based Costing s možností alokovat další přímé náklady na pacientovi a to včetně zabezpečení procesu přenosu těchto potřebných dat z dalších zdrojových systémů. Další oblastí, kterou naše řešení má je silný benchmarking ve strukturálních i procesních parametrech nemocnice. Celá komponenta reportingu může být používána jako součást řešení pro vyúčtování pojišťovny či mimo něj.
7.25.1 Plnění požadavků zadávací dokumentace na MIS
Manažerský informační systém ICZ plní požadavky zadávací dokumentace v rozsahu daném následující tabulkou:
# | Požadavek | Splňuje (ANO/NE) |
P.586 | V současné době nemocnice využívá Manažerský informační systém ICZ AMIS MIS, který je datově propojen s modulem POJ5 AMIS*H a prezentuje produkční data vzhledem k úhradové vyhlášce. Prezentační vrstva je provozována na Oracle Business Intelligence prohlížečích. V rámci zachování vynaložených investic zadavatel předpokládá zachování stávajícího systému a jeho rozšíření Tento modul bude modernizován tak, aby plnil požadavky nařízení eIDAS a bude rozšířen o dále uvedené nové funkce. | ANO |
P.587 | Manažerský informační systém nyní poskytuje statistiky a výstupy pro zdravotnickou produkci a DRG. Požaduje se jejich zachování nebo převedení do modernizovaného systému. | ANO |
P.588 | Požaduje se rozšíření o následující oblasti: 1. Ekonomika a ekonomické výkazy – požadavky na ekonomiku a ekonomické výkazy jsou uvedeny dále v této kapitole. 2. Preskripce – požadavky na preskripci jsou uvedeny dále v této kapitole. 3. Antibiotika – přehled o spotřebě a druhu antibiotik dle oddělení a za celou nemocnici. 4. Kvalita – požadavky na kvalitu jsou uvedeny dále v této kapitole. 5. Operační sály – požadavky na operační sály jsou uvedeny dále v této kapitole. 6. Logistika a náklady na materiál a léky – požadavky na logistiku a náklady na materiál a léky jsou uvedeny dále v této kapitole. 7. Efektivita – požadavky na efektivitu jsou uvedeny dále v této kapitole. 8. Nákladové ceníky – požadavky na nákladové ceníky jsou součástí požadavků na logistiku a nákladů na materiál a léky a jsou uvedeny dále v této kapitole. | ANO |
P.589 | Všechny oblasti musí umožňovat výběry min. dle časového intervalu (den., měsíc, rok, vybrané období) a dle oddělení, případně za celou nemocnici. | ANO |
Poskytování péče | ||
P.590 | Statistiky výkonů: 1. Denní, případně s výběrem časového období 2. Za oddělení, případně i za více oddělení 3. V případě dalšího členění oddělení na části (operační sály apod.) možnost pro jednotlivé části 4. Dle personálu (osob) provádějící výkon – lékař/i, ošetřující personál. 5. Dle přístroje, na kterém byl prováděn výkon | ANO |
Lze realizovat více samostatnými statistikami umožňujícími uvedené kombinace parametrů. | ||
P.591 | Statistika počtu pacientů ve stejném rozsahu podmínek jako u požadavku P.590. Lze realizovat více samostatnými statistikami umožňujícími uvedené kombinace parametrů. | ANO |
P.592 | Statistika pacientů přijatých od jiného poskytovatele zdravotních nebo sociálních služeb. | ANO |
P.593 | Statistika pacientů propuštěných k jinému poskytovateli zdravotních nebo sociálních služeb, | ANO |
Ekonomika | ||
P.594 | Simulace úhrad dle úhradové vyhlášky (podklad pro sestavení plánu výnosů). | ANO |
P.595 | Výpočet výnosů od zdravotních pojišťoven dle platné úhradové vyhlášky. | ANO |
P.596 | Rozpad výnosů dle struktury: nemocnice, oddělení, stanice, ambulance. | ANO |
P.597 | Celkové náklady v Kč (variabilní volba zobrazení v tis. Kč, v mil. Kč). | ANO |
P.598 | Rozpad nákladů dle struktury: nemocnice, oddělení, stanice, ambulance. | ANO |
P.599 | Rozpad nákladů dle účtů účtové osnovy – všech pozic syntetického i analytického členění. | ANO |
P.600 | Srovnání s nemocničním plánem nákladů. | ANO |
P.601 | Náklady dle jednotlivých účtů účtové osnovy dle jednotlivých pozic, vše v členění na nákladová střediska, propadem na jednotlivé doklady, trendové zobrazení několika let. | ANO |
P.602 | Náklady na personál (minimálně na 1 lékaře, na nákladové středisko atd.). | ANO |
P.603 | Celkové výnosy v Kč (variabilní volba zobrazení v tis. Kč, v mil. Kč). | ANO |
P.604 | Rozpad výnosů dle struktury: nemocnice, oddělení, stanice, ambulance. | ANO |
P.605 | Rozpad výnosů dle účtů účtové osnovy – všech pozic syntetického i analytického členění. | ANO |
P.606 | Srovnání s nemocničním plánem výnosů. | ANO |
P.607 | Výnosy dle jednotlivých účtů účtové osnovy dle jednotlivých pozic, vše v členění na nákladová střediska, propadem na jednotlivé doklady, trendové zobrazení několika let. | ANO |
P.608 | Celkový hospodářský výsledek v Kč (variabilní volba zobrazení v tis. Kč, v mil. Kč). | ANO |
P.609 | Výpočet tržeb od zdravotních pojišťoven dle sjednaných úhradových mechanismů včetně veškerých platných regulací, a to individuálně dle jednotlivých zdravotních pojišťoven a jednotlivých segmentů péče. | ANO |
ABC (Activity Based Costing) | ||
P.610 | Výpočet jednicových nákladů pro přiřazení nákladů na proces dle definované Metodiky. | ANO |
P.611 | Přehled jednicových nákladů dle organizační struktury. | ANO |
P.612 | Detailní přehled jednotlivých vstupních položek - nákladů a výnosů pro výpočet jednicových nákladů dle organizační struktury. | ANO |
P.613 | Trendy jednotlivých jednicových nákladů dle plovoucího roku. | ANO |
P.614 | Porovnání jednicových nákladů s referenčními údaji. | ANO |
Preskripce | ||
P.615 | Návaznost na pozitivní listy. | ANO |
P.616 | Celkový objem preskripce. | ANO |
P.617 | Srovnání na nemocniční list pomůcek. | ANO |
P.618 | Záchytnost léků a materiálu v ústavní lékárně. | ANO |
P.619 | Preskripce dle lékaře, dle léku v návaznosti na plán. | ANO |
P.620 | Sledování trendů preskripce vůči referenčnímu období. | ANO |
Operační sály | ||
P.621 | Sledování a řízení vytíženosti operačních sálů. | ANO |
P.622 | Sledování a řízení procesů souvisejících s operacemi (snímkování času operatéra, efektivita provozu operačních sálů). | ANO |
P.623 | Vnitřní benchmarking operací. | ANO |
P.624 | Zpřesnění přiřazení nákladů na péči a sledování veškerých skutečných nákladů na operace. | ANO |
P.625 | Možnost využití detailních informací o operaci propojených s daty hospitalizačního případu. | ANO |
P.626 | Sledování a řízení vytíženosti operačních sálů. | ANO |
Logistika a náklady na materiál a léky | ||
P.627 | Zpracování údajů o dodavatelích, číselnících položek včetně PDK nomenklatury, nákupu, spotřebě a zásobách, převodních číselnících měrných jednotek pro porovnání vykazovaných a nákupních cen. | ANO |
P.628 | Všechny výstupy musí být v Kč. | ANO |
P.629 | Nákup materiálu a léků: 1. rozpad dle organizační struktury 2. rozpad dle dodavatele a materiálu 3. rozpad dle oborů a dodavatele 4. rozpad dle materiálu od dodavatele v čase 5. rozpad dle materiálu dle oborů v čase | ANO |
P.630 | Spotřeba materiálu a léků: 1. rozpad dle organizační struktury 2. rozpad dle oborů a materiálu 3. rozpad dle materiálu pro NS v čase (vybrané období) | ANO |
P.631 | Stav zásob materiálu a léků: 1. rozpad dle organizační struktury 2. trendy stavu zásob dle organizační struktury 3. trendy stavu zásob dle skupin zásob | ANO |