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

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

Objednatel	Oblastní nemocnice Trutnov a.s.
IČO	260 00 237
se sídlem	Maxima Gorkého 77, Kryblice, 541 01 Trutnov
zastoupen	Xxx. Xxxxxxxx Xxxxxxxxx, Ph.D., předseda představenstva
bankovní spojení
číslo účtu

dále také jako „objednatel“ a

Poskytovatel ICZ a.s.

Obchodní společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze pod spisovou značkou B 4840.

IČO 25145444

DIČ CZ699000372

se sídlem Na hřebenech II 1718/10, 140 00, Praha 4 zastoupen xxxx, předsedou představenstva

bankovní spojení číslo účtu

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, v aktuálním znění (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 Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory, která byla uveřejněna ve Věstníku veřejných zakázek pod evidenčním číslem Z2017-005540 (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“). 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 provedení díla dle této Smlouvy, že 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ě 30.000.000 Kč. Kopii pojistné smlouvy předloží poskytovatel objednateli před podpisem Xxxxxxx.

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é), jejichž zabezpečení servisu 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. Vymezení servisní podpory pro účely této Smlouvy je uvedeno v Příloze č. 2 této Smlouvy.

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 č. 3 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.

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í 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. Objednatel si ve smyslu § 100 odst. 3 zákona o zadávání veřejných zakázek vyhrazuje poskytnutí služeb spočívajících ve školení uživatelů informačního systému dle zadávacích podmínek veřejné zakázky. Služby dle tohoto ustanovení poskytne poskytovatel objednateli na základě písemných objednávek objednatele. Poskytovatel na základě objednávky informuje objednatele o způsobu realizace služeb a časovém harmonogramu jejich provedení. Způsob, rozsah a cena poskytnutých služeb musí být objednatelem dopředu odsouhlaseny.

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

Určení typu servisní podpory a servisního období

1. Poskytovatel se zavazuje poskytovat objednateli typ servisní podpory na vybavení specifikované v příloze č. 1, a to v rozsahu uvedeném v příloze č. 2.

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

3. 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é dne 28. 8. 2019 mezi poskytovatelem a Královéhradeckým krajem, IČO 708 89 546, se sídlem Pivovarské náměstí 1245, Hradec Králové, na základě výsledku zadávacího řízení veřejné zakázky. Servisní období trvá alespoň po dobu 84 měsíců ode dne finančního ukončení projektu dle smlouvy o dílo ve smyslu věty předchozí, přičemž v této době není poskytovatel oprávněn tuto smlouvu vypovědět. Objednatel poskytovatele informuje o konečném termínu finančního ukončení projektu bez zbytečného odkladu ode dne, kdy se o něm dozvěděl.

4. Servisní podpora je poskytována za úplatu, na základě písemné objednávky ze strany objednatele, a to vždy na období jednoho roku.

5. Objednatel si vyhrazuje právo servisní podporu v rozsahu dle odst. 4 nevyužít zcela, nebo jen částečně. To znamená, že bude objednávat rozsah poskytování servisní podpory dle vlastní potřeby.

6. Poskytovatel je povinen písemně vyzvat objednatele k zaslání objednávky na servisní podporu 2 měsíce před plánovaným ukončením zkušebního provozu a následně v době trvání této smlouvy vždy 2 měsíce před uplynutím předcházejícího období.

7. Poskytovatel se způsobem poskytování servisní podpory uvedeným v tomto článku výslovně souhlasí.

8. Po celou dobu poskytování servisní podpory je poskytovatel povinen poskytnout objednateli na jeho vyžádání písemný přehled provedených činností.

Článek 5

Cena

1. Cena za roční poskytování servisní podpory (dále jen „cena“) je stanovena v Příloze č. 2 této Smlouvy - Vymezení rozsahu a cen servisní podpory a je stanovena jako pevná a nejvýše přípustná.

2. Smluvní strany se dohodly, že cenu uhradí objednatel na základě faktur vystavených jednou měsíčně na částku odpovídající vždy 1/12 ceny za roční poskytování servisní podpory se dnem zdanitelného plnění určeným k poslednímu dni příslušného měsíce.

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

7. Smluvní strany se dohodly, že v případě změny zákonných sazeb DPH, nebudou uzavírat písemný dodatek k této Smlouvě o změně výše ceny a DPH bude účtována podle předpisů platných v době uskutečnění zdanitelného plnění.

8. Po uplynutí doby minimálního trvání servisního období dle článku 4 odst. 3 je poskytovatel oprávněn upravit cenu za roční poskytování servisní podpory bez dohody smluvních stran z důvodu a v rozsahu inflace oproti poslednímu roku servisního období dle článku 4 odst. 3. Inflací se rozumí meziroční inflace měřená vzrůstem úhrnného indexu spotřebitelských cen zboží a služeb, kterou udává každým kalendářním rokem Český statistický úřad za rok předcházející vyjádřená v procentech. Výpočet takto upravené ceny provede poskytovatel a v dostatečném předstihu a písemně oznámí objednateli novou výši ceny vč. odůvodnění její výše tak, aby mu umožnil včasnou úhradu.

Č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:

▪ odpovědný pracovník:

▪ odpovědný pracovník:

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 vybavení dle specifikace dle přílohy č. 1 této Smlouvy včas v termínech a v rozsahu předepsaných výrobci tohoto vybavení.

Č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ů. Po nabytí účinnosti 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ů bude 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 dohodnutých termínů poskytovatelem k jednotlivému případu se smluvní strany dohodly na smluvní pokutě ve výši 1.000 Kč za každou i započatou hodinu prodlení s tím, že nejvyšší částka takovéto smluvní pokuty nepřesáhne částku odpovídající smluvní pokutě za pět dní. Tuto smluvní pokutu zaplatí poskytovatel objednateli. V případě, že objednatel neumožní pracovníkům servisního pracoviště poskytovatele zahájit servisní zásah v předem dohodnutém termínu, právo objednatele na smluvní pokutu za prodlení poskytovatele od tohoto okamžiku nevzniká; to se nedotýká práva na smluvní pokutu do tohoto okamžiku.

2. V případě, že poskytovatel neumožní objednateli zadat požadavek na servisní zásah z důvodu nedostupnosti služeb Hot-line ani 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. Poskytovatel je po dobu prodlení objednatele s uhrazením faktury oprávněn pozastavit plnění podle této smlouvy (není povinen poskytovat objednateli služby podle ustanovení této smlouvy). Poskytovatel sdělí písemně kontaktním osobám uvedeným v čl. 6 odst. 4 této smlouvy termín, ke kterému pozastavuje plnění podle této smlouvy. K obnovení plnění pozastaveného dle tohoto ustanovení dojde v den následující po provedení úhrady (připsání na účet poskytovatele). Objednatel bezodkladně po provedení úhrady poskytovatele na tuto skutečnost upozorní. Poskytovatel není a nemůže být po dobu pozastavení plnění v prodlení.

5. Smluvní pokuty a úrok z prodlení jsou splatné do 30 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.

Č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í 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 Smlouva 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é dne 28. 8. 2019 mezi poskytovatelem a Královéhradeckým krajem, IČO 708 89 546, se sídlem Pivovarské náměstí 1245, Hradec Králové, 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 2028. 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í.

7. Smlouva je 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 Xxxxxxx př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í rozsahu a cen servisní podpory

Příloha č. 3 – Vymezení mechanismů servisní podpory a kontaktní údaje

Příloha č. 4 – Vybraná vysvětlení, změny nebo doplnění zadávací dokumentace

Za objednatele Za poskytovatele

………… …………………………

Xxx. Xxxxxxxx Xxxxxxxxx, Ph.D. xxxx

Předseda představenstva Předseda představenstva

Příloha č. 1

Specifikace informačního systému

ZD NIS pro zdravotnická zařízení ZHKHK

FUNKČNÍ SPECIFIKACE

Obsah

1. Popis současného stavu 4

   1. Současný stav ICT 4

   2. Stručná charakteristika jednotlivých systémů 6

      1. Nemocniční informační systémy (NIS) 6

      2. Klinické informační systémy (KIS) 6

      3. Radiologické informační systémy (RIS) 7

      4. Laboratorní informační systém (LIS) 7

      5. Systém pro obrazovou dokumentaci (PACS) 7

      6. ERP systémy 8

      7. Manažerský informační systém (MIS) 9

      8. Systémy pro řízení provozu stravování 9

      9. Jiné systémy 10

   3. Přehled pokrytí stávajících procesů z hlediska IS 11

      1. Hlavní procesy 11 1.3.2 Řídící procesy 17

1.3.3 Podpůrné procesy 20

2. Specifikace rozsahu implementace NIS 26

   1. Licenční ujednání 33

   2. Licence k dílu 34

   3. Licence k aplikační části informačního systému 35

   4. Licence k databázové části informačního systému 35

   5. Licence a vlastnictví dat 35

3. Obecné požadavky na aplikační programové vybavení 36

4. Požadavky na komunikační vazby 37

   1. Komunikace s interními laboratořemi 37

   2. Další požadavky na komunikaci 37

5. Požadavky na převod dat z původních systémů 38

6. Požadované vlastnosti a funkce jednotlivých oblastí 42

   1. Minimální požadavky na klinický informační systém 45 Minimální požadavky na funkcionalitu přístupových práv 50

Minimální požadavky na logovací aparát 51

Další požadované obecné vlastnosti 53

2. Vedení pacientské dokumentace na ambulancích 55

3. Vedení pacientské dokumentace na lůžkových odděleních (standard, JIP) 58

4. Požadavky na řešení pro obrazový komplement 66

5. Požadavky na řešení pro stravovací provoz 68

6. Požadavky na internetové objednávání pacientů s napojením na diáře pracovišť nemocnice 68

7. Zavedení elektronické zdravotnické dokumentace (EZD) včetně zavedení počítačově vedené

ošetřovatelské dokumentace (EOD) 71

8. Zajištění provozu vizity u lůžka pacienta 73

9. Elektronická dokumentace v laboratořích a mezilaboratorní komunikace 74

10. Vedení strukturované ordinace medikace včetně výdeje léků na identifikovaného pacienta 76

11. Zvýšení bezpečí pacienta na JIP a ARO přes napojení přístrojů s urgentními daty do informačního

systému nemocnice 78

12. Konsolidace prohlížečů s možností vzdáleného přístupu a konzultací 79

13. Zajištění elektronické preskripce prostřednictvím napojení na centrální úložiště SÚKL 79

14. Automatizace hlášení pro externí subjekty (UZIS, matrika…) 81

15. Požadavky na procesní řízení 81

1. Požadavky zadavatele na architektury NIS 82

   1. Efektivita projektu – výkonnostní architektura 82

   2. Byznys architektura – poskytování veřejných služeb 84

   3. Architektura informačních systémů 89

   4. Technologická architektura – vrstva IT technologie (HW a SW) 95

   5. Technologická architektura – vrstva komunikační infrastruktury 96

      1. Bezpečnostní architektura 98

   6. Shoda s pravidly 99

   7. Přehled služeb čtyřvrstvé architektury 102

   8. Architektura navrhovaného řešení v kontextu strategické architektury organizace a navazujících

subjektů veřejné správy 105

1. Pozice řešení v byznys architektuře organizace 105

2. Pozice řešení v architektuře informačních systémů organizace 106

3. Pozice řešení v IT technologické architektuře úřadu 107

1.1.1 Pozice řešení v komunikační infrastruktuře úřadu 109

9. Způsob využití sdílených prvků architektury úřadu a eGovernmentu 111

10. Přehled nahrazovaných procesů a technologických prvků a začlenění navrhovaného řešení do

stávajícího prostředí úřadu a eGovernmentu 113

8. Požadavky zadavatele na naplnění cílů a indikátorů projektu 114

   1. Požadavek na doplnění tabulky indikátorů 114

9. Požadavky zadavatele na postup implementace 118

   1. Analýza aplikačního prostředí 118

   2. Tvorba prováděcího plánu projektu 119

   3. Vytvoření testovacího prostředí 119

      1. Migrace testovacích aplikací 119

   4. Vytvoření produkčního prostředí a integrace s prostředím 120

      1. Migrace produkčních aplikací 120

      2. Zátěžové a akceptační testy 120

   5. Tvorba dokumentace 120

   6. Školení správců (administrátorů) 121

10. Požadavky zadavatele na maintenance 121

    1. Stanovení úrovně dodávky služeb realizovaných projektem s dodržením minimálních požadovaných standardů 121

1 POPIS SOUČASNÉHO STAVU

1.1 Současný stav ICT

Současný stav nemocničních informačních systémů a infrastruktury v nemocnicích je charakterizován značnou roztříštěností, která pramení z odlišného historického vývoje. Každá ze 4 samostatných nemocnic provozuje jiný typ NIS na různé technologické úrovni. Obecně však lze shrnout, že s výjimkou Městské nemocnice, a.s. jsou provozovány již morálně zastaralé NIS.

U serverové infrastruktury předpokládá zadavatel obnovu v jednotlivých nemocnicích dle nároků pořizovaného NIS. V rámci realizace veřejné zakázky budou částečně využity stávající servery, a to v čase, kdy bude docházet k implementaci nových serverů do jednotlivých nemocnic. Využití současných serverů pro fungování stávajícího NIS se bude odvíjet od procesu zavádění nového NIS provozovaného na nových serverech do jednotlivých nemocnic, jehož termíny vzejdou z implementační analýzy. Předpoklad využívání stávající serverové infrastruktury pro zajištění chodu NIS je tedy maximálně do konce realizace projektu, a to i vzhledem k jejich současnému technickému stavu.

Z analýzy pokrytí procesů realizovaných nemocnicemi jednotlivými NIS/IS, kterou si nechal zpracovat Královéhradecký kraj, vyplynulo, že v rámci ZH KHK je využíváno mnoho identických informačních systémů. V některých případech jsou pro stejnou oblast používány dva rozdílné systémy v rámci jedné nemocnice (typicky MIS). Velká roztříštěnost byla identifikována i v oblasti stravovacích systémů.

Snaha o centralizaci systémů vyústila v úspěšnou realizaci v rámci laboratorních pracovišť (LIS Open LIMS Stapro) a v systému pro pracoviště zobrazovacích metod (Xxxxx PACS). Stejným způsobem pokračuje centralizace v systémech ERP (Navision, FEIS), MIS (FONS Reports) a technických systémech (FaMa, NeOS). Centralizace řešení přináší jednotnost řešení a lepší kontrolu nad náklady na systémy.

Samotný nemocniční informační systém však zůstává roztříštěný a jeho současný stav je nevyhovující.

Přehled pokrytí zdravotnických procesů jednotlivými informačními systémy (včetně podpůrných manažerských systémů) je patrný z následující tabulky č. 1.

Tabulka 1 Pokrytí procesů IS – přehled

Název procesu Městská Oblastní nemocnice Oblastní Oblastní nemocnic Náchod a.s. nemocnice nemocnice

1.2 Stručná charakteristika jednotlivých systémů

1.2.1 Nemocniční informační systémy (NIS)

FONS Akord (Stapro a.s.)

Informační systém umožňuje vedení zdravotní dokumentace a podporu provozní činnosti na jednotlivých klinických pracovištích. Poskytované moduly: Centrální evidence pacientů, Lůžka a ambulance, Operace, Gynekologie a porodnice, Intenzivní péče, Rehabilitace, Evidence onkologických onemocnění, Efektivní transfuzní terapie, Nežádoucí události, dekubity, pády, nemocniční infekce; Vyvolávací systém pro čekárnu; Evidence podávání léčiv; Informovaný souhlas; Evidence užití přístrojů; Jednoznačná identifikace pacientů; Výkaznictví plátcům; Systém DRG; Radiologie; Patologie; Logistika léků a zdravotnických materiálů; Řešení pro e-Recept - vystavení lékařského předpisu v elektronické podobě; EZD - vedení zdravotnické dokumentace v čistě elektronické podobě, podpora autentizace uživatelů na bázi MS Active Directory. Systém využívá Městská nemocnice a.s.

Stapro Medea (Stapro a.s.)

Starší typ komplexního nemocničního informačního systému Stapro. Vzhledem k tomu, že se jedná o starší modul, dnes již nenabízený k prodeji, nebyly detailní informace o funkcionalitách zjištěny. Systém využívá Oblastní nemocnice Náchod a.s. ve dvou oddělených instalacích, a to v Náchodě a Rychnově nad Kněžnou. Cílem projektu je sjednocení do jedné databáze.

Stapro H (Stapro a.s.)

Starší typ komplexního nemocničního informačního systému Stapro. Vzhledem k tomu, že se jedná o starší modul, dnes již nenabízený k prodeji, nebyly detailní informace o funkcionalitách zjištěny. Systém využívá Oblastní nemocnice Trutnov a.s.

1.2.2 Klinické informační systémy (KIS)

mpa (ICZ a.s.)

Klinický informační systém pro podporu všech typů klinických pracovišť. Součástí řešení jsou speciální moduly pro jednotky intenzivní péče, neonatologii a porodnictví, moduly pro chirurgické obory vč. elektronických operačních protokolů, podpora diet vč. komunikace se stravovacím provozem atd. Součástí systému je rovněž funkcionalita Pexeso, využívaná ke sledování preskripcí. Systém využívá Oblastní nemocnice Jičín a.s.

Nefris (ProDos s.r.o.)

Systém určený pro specifika dialyzační služby. Systém umožňuje komplexní vedení zdravotní dokumentace pacientů, ambulantní a hospitalizační agenda, vykazování výkonů zdravotním pojišťovnám, statistiky. Má databázi oddělenou od NIS. Systém využívají střediska hemodialýzy subjektů Oblastní nemocnice Jičín a.s., Oblastní nemocnice Trutnov a.s. a Oblastní nemocnice Náchod a.s.

1.2.3 Radiologické informační systémy (RIS)

Xxxxxx (Xxxxxxx, s.r.o.)

Modul pro RDG pracoviště navázaný na IS mpa. Detailní informace o funkcionalitách nebyly zjištěny. Systém využívá pouze Oblastní nemocnice Jičín a.s.

Stapro Medea – RDG modul (Stapro a.s.)

Samostatný modul NIS Stapro Medea určený pro provoz pracovišť zobrazovacích metod. Využívá RDG oddělení Oblastní nemocnice Náchod a.s.

1.2.4 Laboratorní informační systém (LIS)

FONS Open LIMS (Stapro a.s.)

FONS Openlims je určen pro všechny typy laboratoří. Podporuje specifické pracovní procesy v odbornostech: biochemie, hematologie, imunologie, sérologie, parazitologie, mykologie, virologie, cytologie, genetika, cytogenetika, bakteriologie, transfuziologie. Součástí FONS Open LIMS je integrovaný laboratorní sklad pro evidenci chemikálií a spotřebního materiálu. FONS Open LIMS má on-line ověřené připojení k 400 typům analyzátorů, umožňuje vytvořit bezpapírovou laboratoř (dokumentace vedena pouze v elektronické podobě), kompletně zajišťuje požadavky legislativy na automatické vytváření podkladů pro plátce péče (dávky pro pojišťovny, fakturace), spolupracuje s portály pojišťoven, připravuje výstupy pro ÚZIS, komunikuje s portálem IZIP a SW praktických lékařů. Dále umí vytvářet elektronickou žádanku a vzdáleně zobrazovat výsledky pro žadatele laboratorních vyšetření pomocí webového rozhraní. Systém využívají všechny laboratoře nemocnic ZH KHK.

Stapro Medea – RDG modul (Stapro a.s.)

Samostatný modul NIS Stapro Medea určený pro provoz histologicko-patologických oddělení. Vzhledem k tomu, že se jedná o starší modul Stapro Medea, dnes již nenabízený k prodeji, nebyly detailní informace o funkcionalitách zjištěny. Využívá histo-patologická laboratoř Oblastní nemocnice Náchod a.s.

1.2.5 Systém pro obrazovou dokumentaci (PACS)

Marie PACS (OR CZ a.s.)

Specializované řešení pro elektronické zpracování, archivaci a distribuci obrazových dat ve zdravotnictví. Různé možnosti nastavení distribuce snímků, v rámci RDG oddělení, celé nemocnice včetně externích a spolupracujících lékařů nebo mezi různými zdravotnickými zařízeními. Možnost propojení s NIS. Podporuje rozšířené datové standardy (DICOM, HL7, DaSta). Systém využívají všechny nemocnice ZH KHK.

V průběhu realizace dodávky NIS může dojít ke změně předmětného systému. V době zahájení zadávacího řízení není znám dodavatel nového systému. Nový systém však bude architekturou obdobný stávajícímu řešení a bude respektovat DICOM standard. Integrace NIS bude provedena se systémy provozovanými v době realizace integrace. Změna systému není důvodem pro změnu ceny realizace dodávky NIS.

1.2.6 ERP systémy

FEIS (Arbes Technologies s.r.o.)

Systém umožňuje správu pohledávek a závazků, evidence majetku, řízení skladové evidence, plánování a rozpočtování, účtování, evidenci DPH, řízení vztahů se zákazníky a výkaznictví včetně manažerských výstupů. Možnost obousměrného napojení na aplikace elektronického bankovnictví, komunikace s Českou poštou, import faktur a účetních dat z externích aplikací a univerzální rozhraní pro obecné napojení externích systémů. Podporu formátu ISDOC pro elektronickou výměnu dokladů a umožňuje posílat partnerům doklady e-mailem nebo je doručovat do datových schránek. Systém využívají všechny nemocnice ZH KHK pro běžné účetní a ekonomické operace.

Microsoft Dynamics NAV; Navision (Webcom)

Podnikový informační systém, poskytuje přehled o dění ve společnosti (reporting). Moduly: Obchod a marketing (CRM), Finanční management a controlling, Řízení a plánování výroby, Projekty a servis, Sklady a zásobování, Technologie. Systém využívají všechny nemocnice ZH KHK pro základní pracovně – právní agendu, personalistiku a mzdy a komunikace s veřejnou správou (zejména ČSSZ).

NeOS (Medisystems a.s.)

Systém pro řízení nákupu, se zaměřením na zdravotnictví. Optimalizace léčiv a SZM, kategorizace a standardizace, zefektivnění logistických procesů, integrace informačních systémů a komunikace s dodavateli. NeOS je otevřený informační systém vhodný pro integraci s dalšími systémy v rámci nemocnice, např. lékárenským a ekonomickým systémem. Umožňuje vedení skladové evidence na jednotlivá nákladová střediska včetně vedení evidence pro konsignační sklady nemocnice. Integrace s ekonomickým informačním systémem nemocnice zajišťuje automatické zaúčtování spotřeby materiálu dle nákladových středisek, kategorií sortimentu apod. Systém využívají všechny nemocnice ZH KHK jako objednávkový systém.

FaMa (TESCO SW a.s.)

Komplexní řízení technickoprovozních podpůrných procesů v nemocnicích. Moduly: Prostorový pasport, Technický pasport, Stavební pasport, Personální pasport (kvalifikace a vzdělávání), Evidence

ZP, Skladové hospodářství, Žádanky, Xxxxxxx, Stěhování, Termínované plánování, Opakované činnosti, Zápůjčky, Energetický management, Externí vztahy, Doprava, Rozpočty, Dokumentace (DMS), Grafická prezentace dat.

Systém je využíván všemi nemocnicemi ZH KHK pro evidenci zdravotnické techniky, jejího provozu a údržby (modul Evidence ZP). Dále je Městskou nemocnicí a.s. využíván modul Help Desk.

1.2.7 Manažerský informační systém (MIS)

FONS Reports (Stapro a.s.)

Manažerský informační systém FONS Reports umožňuje čerpání a zpracování dat z různých provozních systémů. Pomocí FONS Reports lze sledovat reportingy systémem včasného varování, provádět okamžitou analýzu problémových dat a zjišťovat příčiny odchylek a neshod. V oblasti controllingu výkaznictví je modulem soustava přepočtů a reportingů dle nové úhradové vyhlášky. Tento modul umožní detailní analýzu parametrů a finančních aspektů vykázané péče. Dále poskytuje finanční hodnocení pro nové (aktuální) období a dokáže jej srovnat s referenčním období. Systém je využíván všemi nemocnicemi ZH KHK jako nástroj controllingu pro vedení holdingu.

AMIS*MIS (ICZ a.s.)

Manažerský informační systém, který umožňuje generovat přehledy a statistiky: produkce, DRG, výnosy, preskripce, ekonomika, tarify, logistika, kvalita, benchmarking s předchozím obdobím/jinými subjekty. V současné době využívaný pouze v rámci Oblastní nemocnice Jičín a.s. pro interní controlling.

HiMIS (původně HiComp systems CZ – nyní Stapro a.s.)

Systém využívaný pro interní controlling Oblastní nemocnicí Trutnov a.s. Vzhledem k tomu, že se jedná o starší modul dnes již nenabízený k prodeji, detailní informace o funkcionalitách IS nebyly zjištěny.

1.2.8 Systémy pro řízení provozu stravování

Stapro H stravovací modul (Stapro a.s.)

Stravovací modul, který je součástí NIS Stapro H, lze jej však využívat i samostatně bez návaznosti na NIS. Vzhledem k tomu, že se jedná o starší modul, dnes již společností Stapro a.s. nenabízený k prodeji, detailní informace o funkcionalitách nebyly zjištěny. V současné době Stapro a.s. zajišťuje legislativní podporu, ale další rozvoj už jen omezeně. Systém využívá Oblastní nemocnice Trutnov a.s.

Stapro Gurmed (Stapro a.s.)

Stravovací modul, který je součástí NIS Stapro Medea. Vzhledem k tomu, že se jedná o starší modul, dnes již nenabízený k prodeji detailní informace o funkcionalitách zjištěny nebyly. Systém využívá Oblastní nemocnice Náchod a.s. v provozech nemocnice Rychnov nad Kněžnou.

Kredit (Anete s.r.o.)

Systém umožňuje automatizované objednávání a výdej jídel, prodej jídel, zboží a služeb. Systém využívá pouze Oblastní nemocnice Jičín a.s.

Astris (EFG spol. s r.o.)

Stravovací systém je určen k řízení ve stravovacích provozech s charakterem závodního nebo pacientského stravování. Systém je naprogramován modulárně v technologii klient - server. Mezi funkcionality stravovacího nástroje patří: burza jídel, normování surovin a řízení zásob skladu, optimální skladbu stravy pro pacienty nemocnic, léčeben, domovů důchodců a jiných zařízení, optimalizace denních dávek živin pro strávníka, včetně sestavení individuálního jídelníčku, tvorba jídelníčků s využitím archivní knihovny již ověřenými jídelníčky, kalkulace cen a stanovování finančních norem spotřeby surovin optimalizující hospodaření stravovacího provozu, kategorizace strávníka, pokladní modul (prodej doplňkového sortimentu, prodej hlavního jídla), vyúčtování stravy. Systém využívá Oblastní nemocnice Náchod a.s v lokalitě Náchod.

Xxxxxxxxx x Xxxxxxxxx (Láf Elektronic)

Systém Kasiopeja je moderním stravovacím systémem, který podporuje: evidenci strávníků, evidence přihlášek za jednotlivá jídla, evidence plateb, možnost výběru z více menu (na týden až 1 měsíc dopředu); přehled o vydaných a nevydaných jídlech, evidence denních odběrů jídel, homebanking (přenosy dat do různých bank), napojení na automatizovaný objednávkový systém jídel, napojení na internetové objednávání jídel, návaznost na program Xxxxxxxxx, který podporuje spotřební koš, finanční sledování. Systém využívá Oblastní nemocnice Náchod a.s. v subjektu Nemocnice Broumov.

1.2.9 Jiné systémy

HelpDesk (Stapro a.s.)

Detailní informace o funkcionalitách systému nebyly zjištěny. Modul využívá Oblastní nemocnice Náchod a.s.

Radix data expert (RADIX SOFTWARE a.s.)

V rámci subjektů využíván především pro získání přehledů o preskripcích (výtěžnost pacientů v Královehradecké lékárně a.s.). Využívají všechny nemocnice vyjma Oblastní nemocnice Jičín a.s.

Mediox (Apatyka servis s.r.o.)

Systém pro komplexní řízení provozu lékárny. Detailní informace o funkcionalitách systému nebyly zjištěny. Jako nástroj pro řízení skladového systému lékárny využívá Oblastní nemocnice Jičín a.s.

AISLP (RNDr. Xxxxxxxx Xxxx, XXx.)

Databáze všech léčivých přípravků povolených v ČR. Databáze obsahuje evidenci humánních, veterinárních a homeopatických léčiv, názvosloví účinných a pomocných látek, složení přípravků na pomocné látky, ceny, úhrady, započitatelné doplatky, preskripční omezení, indikační omezení, zvýšené úhrady apod. dle aktuálního stavu ke dni vydání verze; přehled o cenách a úhradách po čtvrtletí; přehled o 20 000 parafarmaceutik; ceník VZP v oblasti prostředků zdravotnické techniky; spotřeby léčiv za poslední 2 roky a kompendium Infopharm a knižní modul Infopharm. Jako samostatnou databázi využívá v současné době pouze Oblastní nemocnice Náchod a.s. Oblastní nemocnice Trutnov a.s. má AISLP implementován v NIS (Stapro H).

Codexis (ATLAS Consulting spol. s r.o.)

Kompletní právní systém pokrývající problematiku národní legislativy a legislativy EU. Právní IS obsahuje legislativu ČR, EU, judikaturu ČR, judikaturu Soudního dvora EU a další literaturu. Využívá Oblastní nemocnice Náchod a.s.,Oblastní nemocnice Trutnov a.s a Městská nemocnice, a.s..

HEMO (dodavatel: Stapro a.s., Výrobce: Software Project Bratislava)

Systém pro řízení úseku výroby transfuzních přípravků. Detailní informace o funkcionalitách systému nebyly zjištěny. Systém využívají úseky přípravy transfuzních přípravků subjektů Oblastní nemocnice Trutnov a.s. a Oblastní nemocnice Náchod a.s.

1.3 Přehled pokrytí stávajících procesů z hlediska IS

V této kapitole je detailně popsáno pokrytí stávajících procesů informačními systémy, v případě, že jsou IS využívány. Popis je uveden přehledovou tabulkou, doplněnou textovým popisem současného zajištění průběhu procesu se zohledněním specifik jednotlivých nemocnic. V případě, že pro danou činnost není IS (nebo funkcionalita) využívána, je v tabulce uvedeno „N/A“.

1.3.1 Hlavní procesy

Diagnostická a léčebná lůžková péče

Diagnostická a léčebná lůžková péče je jedním z hlavních procesů realizovaných v různém rozsahu odborností jednotlivými subjekty zařazenými do analýzy. Základním atributem všech využívaných NIS (KIS) je centrální registr pacientů. Databáze obsahuje základní nacionále pacienta použitelné pro jeho identifikaci (jméno, příjmení, rodné číslo, adresa/kontaktní údaje, zdravotní pojišťovna, praktický lékař). Rozsah informací se liší dle zvyklostí jednotlivých subjektů. Data do základního registru jsou používána pro tisk štítků a do automatizovaných vzorů žádanek, poukazů k vyšetření/ošetření, informovaných souhlasů a dalších tiskopisů. Data jsou rovněž využívána pro tvorby hlášení pro matriky (v případě subjektů s porodnicí narození, v případě všech subjektů zemřelí).

Hlavní činností procesu diagnostické a léčebné péče, z hlediska funkcionalit NIS (KIS) je pořizování záznamů o diagnostické a léčebné péči o pacienta. Ve všech subjektech je zdravotnická dokumentace vedena v primárně tištěné formě. Dokumentace v elektronické formě je doplňkem tištěné dokumentace. Ve všech subjektech byla v rámci analýz prezentována myšlenka, že přechod na čistě elektronickou dokumentaci (vč. ošetřovatelské dokumentace viz níže) je budoucím cílem managementu všech subjektů. Stav dostupnosti historie pacientské dokumentace se různí dle využívaných NIS. Optimálním řešením se ve všech subjektech jeví neomezená dostupnost pacientské dokumentace v elektronické formě (odpadá nutnost dohledávání papírových chorobopisů v archivech).

Podporu informačního systému pro plánování péče o pacienta využívají pouze Oblastní nemocnice Jičín a.s. a Oblastní nemocnice Trutnov a.s., ani zde však není systém zaveden na všech odděleních. Zda je tato možnost vhodná pro případ lůžkových oddělení, záleží na praxi subjektu, jistě lze funkcionalitu využít pro plánované příjmy.

Operační zákroky jsou ve všech subjektech evidovány v NIS (KIS), současně s operačním protokolem je rovněž vykazován spotřebovaný materiál a náklady na sál a operační tým. Elektronické plánování objednávání kapacity operačních sálů využívá pouze Oblastní nemocnice Jičín a.s. (vyjma gynekologicko-porodnického oddělení).

Všechny NIS (KIS) slouží jako úložiště pro vzory žádanek a informovaných souhlasů. Díky využití pacientské databáze (centrální registr pacientů) jsou do vzorových formulářů generovány nacionále pacienta a tím usnadňují práci zdravotnických pracovníků a snižují chybovost při ručním vpisování dat.

Všechny systémy rovněž umožňují kompilaci příjmových, překladových a propouštěcích zpráv na základě různých částí zdravotnické dokumentace. Pro sestavy zpráv jsou využívány jednoduché šablony, obsahově uzpůsobené jednak požadavkům legislativy a dále zvyklostem subjektu.

Všechny NIS (KIS) umožňují tisk identifikačních štítků pacienta, které slouží pro identifikaci žádanek, poukazů na vyšetření, nádobek pro odběry primárních vzorků apod. V případě Městské nemocnice a.s., Oblastní nemocnice Náchod a.s. a Oblastní nemocnice Jičín a.s. jsou využívány štítky s jedinečným pacientským barcode, v případě Oblastní nemocnice Trutnov a.s. se jedná o štítky s prostou identifikací pacienta, bez barcode. Přechod k jednoznačné identifikaci formou barcode je zamýšleným stavem ve všech subjektech ZH KHK.

Diagnostická a léčebná ambulantní péče

Poskytování ambulantní péče je z hlediska průběhu workflow obdobné s poskytováním péče lůžkové. Primárně jsou využívána data z centrálního registru pacientů. Evidence pacientů konkrétní ambulance je propojena s centrální databází. Systém je obdobný v rámci všech subjektů.

Objednávání pacientů na vyšetření elektronickou prostřednictvím NIS (KIS) využívá pouze Oblastní nemocnice Jičín a.s. (vyjma gynekologicko-porodnické ambulance a OTH). Jedná se o objednávání ze strany ambulance (ne aktivní přístup pacienta) a vedení objednávek v elektronické formě. Z hlediska elektronického objednávání byla se zástupci subjektů diskutována otázka aktivního elektronického objednávání pacientů přímo do ambulancí. V tomto případě pacient volí termín návštěvy z kalendáře na webové stránce ambulance. U ambulance je tato praxe možná, záleží však také na odbornosti ambulance a na rozsahu vyšetření/ošetření. Ne vždy je reálné, aby pacient určil korektní délku návštěvy ambulance na základě vlastního uvážení. Obecně lze konstatovat, že možnost elektronického objednávání (zejména ze strany ambulancí) je žádaným budoucím stavem na všech subjektech, i když pravděpodobně nebude využito ve všech ambulancích (dáno zejména odborností). V současné době je v rámci Oblastní nemocnice Trutnov a.s. nově zprovozněno klientské centrum, které umožňuje elektronické podání požadavku pro objednání pacientů do vybraných ambulancí. Pacient zadá do elektronického formuláře na webu nemocnice své údaje a je zpětně kontaktován pracovníkem kontaktního centra s návrhem vhodného termínu návštěvy.

Systém řízení zdravotnické dokumentace, tvorby zpráv a tiskových sestav vč. štítků je pro proces diagnostická a léčebné ambulantní péče identický s procesem péče lůžkové (viz výše).

Ošetřovatelská péče

Proces ošetřovatelské péče není na žádném ze subjektů ZH KHK řešen elektronickou formou. Dokumentace je vedena v papírové podobě. Management všech subjektů však předpokládá budoucí přechod na elektronickou ošetřovatelskou dokumentaci v plném rozsahu ošetřovatelské dokumentace (dle přílohy č. 1 vyhlášky č. 98/2012 Sb. o zdravotnické dokumentaci). Tomuto kroku však v současné době brání zejména technické a finanční aspekty. Aby byla ošetřovatelská dokumentace pořizována průběžně a korektně a její elektronické řízení přinášelo úsporu času zdravotnických pracovníků, je nutné, aby byla pořizována přímo při péči o pacienta tzv. u lůžka. Je proto nezbytné vybavit personál mobilními zařízeními pro pořizování dokumentace (PDA, tablety).

Porodnická péče

Zdravotnická dokumentace vztahující se k porodnické péči je vše všech subjektech, které provozují porodnici (Oblastní nemocnice Jičín a.s., Oblastní nemocnice Trutnov a.s., Oblastní nemocnice Náchod a.s.) vedena standardně v rámci NIS (KIS). Specifickým aspektem, který je kladen na dokumentaci pro porodnickou péči, je nutnost vzájemné vazby mezi dokumentací rodičky a novorozence. Dokumentaci rodičky vede gynekologicko–porodnické oddělení a obsahuje informace o průběhu těhotenství, anamnézu rodičky, záznamy o předporodních vyšetřeních apod. Z průběhu vlastního porodu je pak doplňován kompletní porodopis. Dokumentace novorozence zakládá a vede pediatrické oddělení. Pro péče o novorozence je nezbytné, aby pediatrické oddělení mělo přístup k vybraným údajům o matce dítěte a průběhu porodu. Z tohoto důvodu je nezbytné propojení dokumentace. Velký důraz by měl být kladen na zajištění důvěrnosti dat a přístupu k nim, tj. pediatr by měl mít náhled do dokumentace rodičky pouze pro údaje nezbytně nutné pro péči o novorozence.

Provoz porodnické péče rovněž přináší subjektu povinnost hlášení do registrů NZIS ¹ a do Národního registru rodiček. V rámci subjektů není v současné využíváno přímé hlášení z NIS (KIS) do registrů.

V souvislosti s poskytování porodnické péče je rovněž nutné upozornit na specifickou oblast, a to dokumentaci o utajeném porodu².

Hemodialyzační služba

Střediska hemodialyzační služby provozují subjekty Oblastní nemocnice Jičín a.s., Oblastní nemocnice Trutnov a.s., Oblastní nemocnice Náchod a.s. Pro řízení provozu hemodialýzy je ve všech subjektech využíván specifický klinický informační systém Nefris. Systém umožňuje komplexní vedení zdravotnické dokumentace o pacientech hemodialýzy vč. záznamů o průběhu vlastní hemodialýzy. Z tohoto pohledu je klinickými uživateli všech subjektů hodnocen jako vysoce vyhovující jejich potřebám.

V současné době není databáze Nefris na žádném ze subjektů propojena s databází NIS. Pacienti jsou do Nefris zadáváni jako do samostatného systému, dále je jejich evidence vedena rovněž v NIS v modulu ambulantní nebo lůžkové péče, veškeré změny je tedy nutno zadávat dvakrát, do Nefris a současně do NIS. Informace o průběhu hemodialýzy jsou rovněž ručně kopírovány do dokumentace pacienta vedené v NIS. Tato oblast je uživateli hodnocena spíše negativně, propojení databází obou systémů by bylo žádoucím aspektem pro optimalizaci provozu. Dle specifikace dodavatele (ProDos s.r.o.) je Nefris vybaven různými možnostmi komunikačních rozhraní pro výměnu dat s dalšími IS vč. datového standardu MZ ČR (DaSta).

Tabulka 2 Pokrytí procesů IS - hlavní procesy

Proces Subproces Činnost Městská Oblastní Oblastní Oblastní

nemocnice a.s. nemocnice nemocnice nemocnice

Náchod a.s. Jičín a.s. Trutnov a.s.

Diag nosti cká a léčeb ná lůžko	Centrální registr pacientů	Evidence základních údajů pacientů	Stapro AKORD	Stapro Medea	mpa	Stapro H
	Údaje pro matriky	Hlášení narozených	N/A	Stapro Medea	mpa	Stapro H
		Hlášení zemřelých	Stapro AKORD	Stapro Medea	mpa	Stapro H

vá péče	Plánování péče		Plánování příjmů/lůžek	Stapro AKORD	N/A	mpa		Stapro H
			Plánování vyšetření/zákroků	Stapro AKORD	N/A	mpa		Stapro H
	Kartotéka chorobopisů		Příjem, překlad, propuštění	Stapro AKORD	Stapro Medea, MS Access (Interní oddělení ) – bude požadováno sjednocení do NIS	mpa		Stapro H, Nefris
			Diagnostické a léčebné výkonyevidence	Stapro AKORD	Stapro Medea	mpa		Stapro H, Nefris
	Lékařská dokumentace		Anamnéza pacienta, diagnostické a léčebné výkony	Stapro AKORD	Stapro Medea	mpa		Stapro H
	Zákroky operace	a	Operační protokol (popis operace, čas, výkony, materiál)	Stapro AKORD	Stapro Medea	mpa		Stapro H
			Objednání operačního sálu	N/A	N/A	mpa GP)	(vyjma	Stapro H
	Sestavy tisky	a	Žádanky	Stapro AKORD (vzory)	Stapro Medea (vzory)	mpa(vzory)		Stapro H (vzory)
			Štítky (tisk)	Stapro AKORD (s barcode)	Stapro Medea (s barcode)	mpa(s barcode)		Stapro H (id.pacienta, s možností barcodu)
			Kompilace zpráv (přijímací, překladové, propouštěcí)	Stapro AKORD	Stapro Medea	mpa		Stapro H
			Informované souhlasy	Stapro AKORD (vzory)	N/A	mpa (vzory)		Stapro H (vzory)

Proces Subproces Činnost

Městská Oblastní Oblastní Oblastní

Diag nosti cká a léčeb ná amb ulant ní péče	Kartotéka pacientů ambulance	Evidence pacientů ambulance	Stapro AKORD	Stapro Medea	mpa	Stapro H
	Plánování péče	Plánování návštěv pacientů	Stapro AKORD	Stapro Medea	Mpa (vyjma GP a OTH)	Stapro H
		Plánování vyšetření/zákrok ů	Stapro AKORD	Stapro Medea	mpa	Dtto
	Lékařská dokumentace	Anamnéza pacienta, diagnostické a léčebné výkony	Stapro AKORD	Stapro Medea	mpa	Stapro H
	Sestavy a tisky	viz Diagnostická a léčebná lůžková péče	Stapro AKORD	dtto	dtto	Dtto
Ošet řovat elská péče	Ošetřovatelská dokumentace	Ošetřovatelská dokumentace	Stapro AKORD	N/A	N/A	N/A
Poro dnick á péče	Rodička	Záznam o předporodních vyšetřeních/hosp italizace	N/A	Stapro Medea	mpa	Stapro H
	Porod	Porodopis	N/A	Stapro Medea	mpa	Stapro H
	Matka a novorozenec	Propojená dokumentace matky/novoroze nce	N/A	Stapro Medea	mpa	Stapro H
		Hlášení ÚZIS	N/A	N/A	N/A	Stapro H

nemocnice a.s. nemocnice nemocnice nemocnice Náchod a.s. Jičín a.s. Trutnov a.s.

1.3.2 Řídící procesy

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

−	Personalistika – proces personálního řízení je ve všech subjektech řešen podporou IS Navision. V systému je řešena základní pracovně-právní agenda tj. evidence zaměstnanců a jejich základních údajů (nacionále, pracovní zařazení, pracovní úvazek a režim, mzdové nároky, evidence pracovní doby). Systém je rovněž určen pro tvorbu mezd. V tomto smyslu je propojen se systémem pro řízení ekonomiky a účetnictví (FEIS). Systém dále umožňuje elektronickou komunikaci se subjekty veřejné správy. Plánování směn ani evidence pracovní doby není na žádném ze subjektů vedena v elektronické formě. V rámci systému personalistiky nejsou řešeny kompetence a kvalifikace pracovníků. V Oblastní nemocnici Trutnov a.s. v současné době probíhá testování systému pro elektronickou pracovně – právní dokumentaci (šablony pracovních smluv, popisů práce). Po zkušebním provozu je plánován přenos do dalších nemocnic.
−	Ekonomika a účetnictví – proces je ve všech subjektech pokryt systémem FEIS. Systém je propojen s NIS (KIS) pro účtování nákladů poskytované péče a dále se systémem FaMa pro evidenci majetku. Další propojení FEIS je do manažerských informačních systémů. Primárně pro FONS Report (společný pro všechny subjekty, určeno pro controlling ze strany ZH KHK), dále pro MIS využívané jednotlivými subjekty pro interní kontrolní činnosti. Problémem, na který bylo v rámci analýzy poukazováno, byla absence propojení FEIS a LIS. Absence této funkcionality komplikuje zejména přípravu účtů pro platby samoplátců. Výkony laboratoří jsou účtovány v měsíčních dávkách. V případě, že vznikne potřeba vystavit účet pro samoplátce je nutno provést samostatné (ruční) vyúčtování služeb laboratoře, protože FEIS není schopen tato data importovat s LIS. Z NIS (KIS) tato možnost existuje, proto je možné účty samoplátce pro výkony účtované v NIS (KIS) provádět bez součinnosti oddělení.
−	Statistiky a výkazy – statistické přehledy a výkaznictví je nedílnou a velmi důležitou součástí managementu zdravotnického zařízení. Pro statistickou a výkaznickou činnost je nezbytná spolupráce NIS (KIS), LIS a ekonomického systému. Data jsou dále shromažďována a vyhodnocována v určeném MIS, ať již pro účely interního controllingu nebo reportování a vykazování směrem k ZHKHK (FONS Reports). Z analýzy vyplynula

poměrně široká škála využívaných MIS. Nicméně vazba k NIS je identifikována pouze na potřebu datových propojení a variabilitu pro statistické hodnocení a reportování. Výkazy pro zdravotní pojišťovny jsou prováděny elektronickými dávkami na portály ZP, v dávkách jsou konsolidována data za všechny výkony.

− Hlášení do registrů – hlášení do registrů³ je nezbytnou součástí provozu zdravotnického zařízení. V současné době probíhá přímý export dat mezi NIS a ÚZIS v případě subjektů Oblastní nemocnice Jičín a.s. a Oblastní nemocnice Trutnov a.s., Oblastní nemocnice Náchod a.s. využívá pro přenos dat samostatnou aplikaci, v současné době plánuje testování přímého exportu na portál. NIS využívaný Městskou nemocnicí a.s. převod dat do portálu ÚZIS nepodporuje.

Kvalita a bezpečí péče

Požadavek na řízení systému kvality a bezpečí péče vychází z požadavku zákona č. 372/2011 Sb., o zdravotních službách, v platném znění. Podle § 47 odst. 3 písm. b) je poskytovatel povinen v rámci zajištění kvality a bezpečí poskytovaných zdravotních služeb zavést interní systém hodnocení kvality a bezpečí. Minimální rozsah indikátorů pak udává Věštník MZ ČR č.5/2012, část 3 pro poskytovatele lůžkové péče, 1.4. Standard: Sledování a vyhodnocování nežádoucích událostí. Všechny subjekty mají v současné době systém sledování nežádoucích událostí zaveden jako samostatnou evidenci oddělenou od NIS. Městská nemocnice a.s., Oblastní nemocnice Jičín a.s., Oblastní nemocnice Náchod a.s. využívají pro řízení nežádoucích událostí systém “HlašeníNU” vyvinutý firmou Instantsolutions pro Institut pro aplikovaný výzkum, edukaci a řízení ve zdravotnictví, o.p.s. (InAVERZ). Oblastní nemocnice Trutnov a.s. využívá stejný systém ve verzi lokální implementace. Pro řízení stížností je využívána miniaplikace v prostředí G Suite.

Řízení dokumentace

Vzhledem k faktu, že nemocnice se v současné době připravují na akreditace v souladu s požadavky § 98 odst. 1 zákona č.372/2011 Sb. je proces řízení dokumentace jedním z klíčových procesů úspěšnosti procesu posouzení souladu. Stav podpory řízení dokumentace je v jednotlivých subjektech na různé úrovni:

− Městská nemocnice a.s. v současné době nevyužívá žádný systém typu DMS.

− Oblastní nemocnice Jičín a.s. využívá komerční systém na platformě MS Sharepoint.

− Oblastní nemocnice Trutnov a.s. využívá vlastní systém Archiv dokumentace. V současné době se připravuje přechod na prostředí G Suite.

− Oblastní nemocnice Náchod a.s. v současné době nevyužívá žádný systém typu DMS, zavedení sharepoint řešení je v přípravě (z tohoto důvodu není zahrnuto do analýzy nákladu na podporu

IS, cena řešení v současné době není vyčíslena).

Tabulka 3 Pokrytí procesů IS - řídící procesy

Proces Subproces Činnost Městská

nemocnice

a.s.

Oblastní Oblastní Oblastní nemocnice nemocnice nemocnice

Náchod a.s. Jičín a.s. Trutnov a.s.

1.3.3 Podpůrné procesy

V následující podkapitole je popsán současný způsob zajištění podpůrných procesů.

Správa zdravotnických prostředků

Pro zprávu zdravotnických prostředků je ve všech nemocnicích využíván IS FaMa. Všechny subjekty využívají modul Evidence ZP, který je propojen s modulem Evidence majetku v IS FEIS. Díky tomu je nový majetek zaveden do FaMa současně se zavedením do inventárního seznamu majetku a v případě vyřazení je rovněž vyřazen z evidence FaMa. V současné době nebylo identifikováno žádné propojení FaMa a NIS.

Řízení léčiv a spotřebního zdravotnického materiálu

Základním aspektem v oblasti řízení léčiv a SZM je výběr ze „schváleného seznamu“ tzv. pozitivního listu. V subjektech Oblastní nemocnice Trutnov a.s. a Oblastní nemocnice Náchod a.s. je pozitivní list součástí NIS. V případě Oblastní nemocnice Náchod a.s. je dále NIS doplněn o databázi schválených léčivých přípravků AISLP. Pro Oblastní nemocnice Jičín a.s. je obdoba pozitivního listu veden v lékárenském systému Mediox (pro léčiva, spravuje lékárna) a v IS NeOS (pro SZM), nejedná se však o standardní pozitivní list. Městská nemocnice a.s. pozitivní list nevede.

V žádné z nemocnic není zaveden centrální sklad léčiv ani SZM, stejně tak nejsou vedeny (elektronickou formou) sklady oddělení nebo stanic. Evidence skladových zásob je vedena v papírové formě, popř. formou separátních evidencí (např. Excel).

Sledování preskripce je využíváno zejména jako kontrolní mechanismus, dále pak pro sledování výtěžnosti pacienta (sledování zda si pacient vyzvedne lék v lékárně nemocnice). Pro evidenci receptů subjektů Městská nemocnice a.s., Oblastní nemocnice Trutnov a.s. a Oblastní nemocnice Náchod a.s. je využíván systém Radix Data Expert. Oblastní nemocnice Jičín a.s. využívá systém Pexeso (součást NIS mpa).

Elektronické recepty v současné době nevyužívá žádná z nemocnic. Žádný z využívaných systémů neumožňuje přímé hlášení nežádoucích lékových reakcí na SÚKL.

Nakupování

Proces nakupování léčiv a SZM je oboustranně z procesem Řízení léčiv a spotřebního zdravotnického materiálu. Proces nakupování lze členit na subprocesy:

− Léčiva a SZM – nakupování resp. objednávání probíhá ve všech subjektech prostřednictvím IS NeOS. Výběr provádí určení pracovníci z katalogu systému NeOS. Pozor katalog systému není identický s pozitivním listem nemocnice (pokud je veden, viz výše). Systém je určen pouze pro objednávání, nejsou přes něj řízeny skladové zásoby.

− Ostatní materiál – objednávání probíhá v systému NeOS (Oblastní nemocnice Jičín a.s. a Oblastní nemocnice Trutnov a.s.), nebo prostřednictvím HelpDesku. V případě Městské nemocnice a.s. je využíván Help Desk FaMa. Oblastní nemocnice Náchod a.s. využívá pro vnitřní požadavky modul Help Desk Stapro a následně jsou objednávky dodavatelům generovány v systému FEIS a rozesílány zpravidla emailem. Systémy jsou, stejně jako v případě léčiv a SZM, určeny pouze pro objednávání, nejsou přes něj řízeny skladové zásoby.

Stravovací provoz

IS podpora stravovacího provozu (objednávky diet pro pacienty) je oblastí s nejširším spektrem využívaných IS. Jediným subjektem, který pro podporu procesu nepoužívá IS je Městská nemocnice a.s., kde jsou objednávky diet realizovány papírovou formou. Oblastní nemocnice Jičín a.s. využívá IS Kredit, Oblastní nemocnice Trutnov a.s. samostatný stravovací modul v rámci NIS Stapro H. Oblastní nemocnice Náchod a.s. využívá celkem tři IS (dáno historickým vývojem postupného připojování jednotlivých subjektů). V Nemocnici Broumov je využíván IS Kasiopeja/Xxxxxxxxx, v Nemocnice Rychnov nad Kněžnou využívá modul Gurmed, který jsou součástí NIS Stapro Medea, v Oblastní nemocnici Náchod a.s. (vč. subjektů Nemocnice Jaroměř a Nemocnice Nové Město nad Metují) je využíván IS Astris.

Epidemiologický režim

V současné době není epidemiologický režim v žádné nemocnici podpořen informačním systémem.

Služby komplementu

Proces služeb komplementu můžeme pro lepší orientaci členit na dva subprocesy, a to proces laboratorních služeb a služeb zobrazovacích technik. V případě obou subprocesů by měl být kladen důraz na propojení databází mezi využívanými systémy a dále na elektronickou komunikaci tj. zadávání požadavků na vyšetření a příjmu výsledků vyšetření. Elektronická komunikace šetří čas a rovněž snižuje riziko chyb, což je velmi významným aspektem při poskytování zdravotní péče.

● Laboratorní služby

Všechny laboratoře nemocnic využívají stejný LIS a to Open LIMS (Stapro). Výjimkou je histopatologická laboratoř Oblast nemocnice Náchod a.s., která využívá „RDG“ modul NIS Stapro Medea, který je určen pro specifika histopatologie.

Žádná z nemocnic nevyužívá pro zadávání požadavků na laboratorní vyšetření elektronické žádanky, žádanky jsou laboratoři předávány v papírové formě, laboratoř tedy musí provádět ruční zadání pacienta i metod do LIS. Oblastní nemocnice Náchod a.s. a Oblastní nemocnice Jičín a.s. využívají skenování papírových žádanek s načtením metod do LIS.

Přechod na elektronickou žádanku je plánovaným stavem ve všech nemocnicích. Přenos výsledků vyšetření je naopak ve všech subjektech zajištěn elektronicky, přesto jsou (v souladu s požadavky na zdravotnickou dokumentaci a požadavky normy ČSN EN ISO/IES 15189:2013, podle níž jsou laboratoře posouzeny ze strany NASKL) dodávány výsledky také v papírově formě (autorizované uvolňující osobou). Přenos výsledků je zajištěn přímým exportem mezi LIS a NIS, případně pomocí aplikace WebLIMS. Výsledky vyšetření jsou dostupné formou přehledu a dále jsou výsledky importovány do dokumentace pacienta. Extramurálním zadavatelům jsou výsledky elektronicky poskytovány formou zabezpečeného přenosu. Jsou využívány aplikace Medidata (využívají všechny laboratoře) a Mise (využívají spolu s Medidata laboratoře Oblastní nemocnice Náchod a.s. a Oblastní nemocnice Jičín a.s.). Důraz je kladen zejména na bezpečnost přenosu dat a včasné dodání výsledků oprávněnému klinickému žadateli. Přenos výsledků nezabezpečenou formou (e-mail) není, dle vyjádření zástupců subjektů přípustné. V případě histo-patologické laboratoře Oblastní nemocnice Náchod a.s. jsou výsledky vyšetření zapisovány přímo do NIS, neboť laboratoř používá samostatný modul NIS Stapro Medea. Extramurálním zadavatelům se výsledky elektronicky poskytují.

● Zobrazovací metody

V případě vyšetření zobrazovacích metod je zajištěno elektronické podání požadavku (žádanka) i elektronický přenos výsledku do NIS (KIS) formou nálezu vyšetření zapsaného oddělením zobrazovacích metod. Obrazová dokumentace vyšetření je klinikovi dostupná prostřednictvím prohlížeče xVision volaného z NIS. Všechny subjekty využívají systém Xxxxx PACS (OR CZ a.s.). V současné době využívaný systém je provozován v 32bitové verzi (kromě ON Náchod a.s., která používá 64bitovou verzi), která již není v současné době dále vyvíjena a je tedy ve svých funkcích výrazně omezena. V budoucnu je v plánu nahradit současný systém Xxxxx XXXX xa nový, přičemž se bude jednat o systém, který bude obdobné architektury respektující DICOM standart.

Oddělení zobrazovacích metod Oblastní nemocnice Náchod a.s. využívají dále RDG modu NIS Stapro Medea. RDG oddělení Oblastní nemocnice Jičín a.s. pak systém Radius, určený pro specifika zobrazovacích metod.

Oblastní nemocnice Náchod a.s. – subjekt Nemocnice Rychnov nad Kněžnou využívá pro radiodiagnostiku externího dodavatele s importem popisů do výsledkového modulu v NIS Medea. Elektronický přenos obrazových dat extramurálním klinikům využívají Oblastní nemocnice Jičín a.s., Oblastní nemocnice Náchod a.s. a Oblastní nemocnice Trutnov a.s., jedná se o zabezpečený export v ePACS.

Varianta přenosu výsledků nezabezpečenou formou (e-mail) není přípustná.

Výroba transfuzních přípravků

Úsek výroby transfuzních přípravků je zřízen v rámci Oblastní nemocnice Náchod a.s. a Oblastní nemocnice Trutnov a.s. Obě nemocnice využívají pro své řízení IS HEMO, který je určen přímo pro problematiku výroby transfuzních přípravků. Propojení s NIS není identifikováno ani relevantní.

Tabulka 4 Pokrytí procesů IS - podpůrné procesy

Proces Subproces Činnost Městská Oblastní Oblastní Oblastní nemocnice nemocnice nemocnice nemocnice

a.s. Náchod a.s. Jičín a.s. Trutnov a.s.

Správ a zdrav otnic kých prost ředků	Evidence ZP	Evidence ZP, plánování BTK, validací, servisů, v případě měřidel ověření/kalibr ací	FaMa (modul Správa ZP)	FaMa	FaMa	FaMa(+EVIS)
	Evidence kontrol/ BTK ZP	Záznamy o zásazích	FaMa (modul Správa ZP)	FaMa	FaMa	FaMa(+EVIS)
	Elektronick é záznamy o kontrolách /BTK	Možnost vložení elektronickéh o dokladu o provedení zásahu, kalibračního listu apod.	N/A	N/A	FaMa	N/A
	Notifikace konce platnosti kontroly/B TK	Upozornění uživatel/správ ce o blížícím se konci platnosti kontroly/BTK	Fama	FaMa	N/A	N/A
Řízen í léčiv a spotř ebníh o zdrav otnic kého mate riálu	Pozitivní listy	Pozitivní list nemocnice	Stapro FONS Akord	Stapro Medea	Mediox (pro léčiva, spravuje lékárna), NeOS (pro SZM)	Stapro H
	Skladová evidence	Centrální sklad SZM	N/A	N/A	N/A	N/A
		Centrální sklad léčiv	N/A	N/A	N/A	N/A
		Lokální sklad SZM oddělení/amb ulance	N/A	N/A	N/A	N/A
		Lokální sklad léčiv oddělení/amb ulance	N/A	N/A	N/A	N/A

Radix data Pexeso Radix

Expert (mpa)

N/A

Epidemi ologický režim NA Sledování činností v epidemiolo gickém režim sálů a oddělení, sterilizační režim N/A N/A N/A N/A

Proces Subproces Činnost Městská Oblastní Oblastní Oblastní nemocnice nemocnice nemocnice nemocnice

a.s. Náchod a.s. Jičín a.s. Trutnov a.s.

Služby komple mentu	Laboratorní vyšetření	Požadavky na vyšetření (E žádanky přímý přenos NIS- LIS)	N/A	N/A	N/A	N/A
		Výsledky (elektronick y přímý přenos LISNIS)	Open LIMS/Stapr o AKORD, Web LIMS(pro uživatele bez přístupu do NIS)	Open LIMS/Mede a, v případě histologické laboratoře pouze Medea (modul pro histopatologicko u laboratoř)	Open LIMS/mpa	Open LIMS/Stapro H
		Výsledky extramurál ním zadavatelů m (elektronick y)	Medidata	Medidata(C ompek) a Mise(Stapr o)	Medidata, Mise (Stapro)	Medidata (Stapro)
	Zobrazovac í metody	Požadavky na vyšetření (E-žádanky - přímý přenos NIS- PACS)	Stapro AKORD/Ma rie PACS	Medea (NIS)/ Medea (RDG) /Xxxxx XXXX	xpa/Radiu s/Xxxxx XXXX	Xtapro H+Xxxxx XXXX

Změna systémů zajištění podpůrných procesů

Dodavatel bere na vědomí, že kterýkoliv ze systémů k zajištění podpůrných procesů, jejichž dodávka není předmětem dodávky NIS, může být v době od uzavření smlouvy do realizace integrace systému s NIS objednatelem změněn. Integrace NIS bude provedena vždy se systémy provozovanými v době realizace integrace. Změna systému není důvodem pro změnu ceny realizace dodávky NIS.

2 SPECIFIKACE ROZSAHU IMPLEMENTACE NIS

Nemocniční informační systém bude v rámci tohoto zadání pokrývat následující oblasti:

• Klinický informační systém zahrnující o Pacientskou administrativu včetně statistik potřebných pro provoz zdravotnického zařízení, zejména vykazování pro ÚZIS

  • Vyúčtování poskytnuté zdravotní péče různým plátcům (minimálně výkaznictví pro zdravotní pojišťovny včetně podpory DRG, samoplátci)

  • Umožňuje vést zdravotnickou dokumentaci v souladu s platnou legislativou v písemné i elektronické formě (po doplnění o dlouhodobý elektronický archiv)

  • Vedení dokumentace na ambulancích

  • Vedení dokumentace na lůžkových odděleních (standard, JIP)

  • Vedení dokumentace k operaci a jejich plánování a objednávání (+ vyhledávání volného termínu)

  • Vedení speciální dokumentace na porodnici a novorozeneckém oddělení o Speciální modul pro JIP (možnost automatizovaného načítání dat z přístrojů a jejich grafické zobrazení)

  • Rehabilitační péče a plánování procedur o Možnost využití hlasového diktování záznamu

• Obrazový komplement o Radiodiagnostické oddělení

  • Požadavek na import histologických vyšetření (DS) o Oddělení nukleární medicíny

• Internetové objednávání pacientů s napojením na diáře pracovišť nemocnice o Ambulance (kardiologická, endokrinologická, gastroenterologická, nefrologická,…) o Specializovaná pracoviště

• Stravovací systém o Pacientská strava

  • Plná integrace s KIS – objednávání stravy (diety) o Normování a sledování zásob – napojení na EIS a MIS

• PACS systém o Centrální uložiště o DICOM prohlížeč

• Webový portál o Přehled o poskytovatelích zdravotních služeb o Přehled o dostupnosti zdravotní péče

  • Přehled o volných kapacitách pro plánované zdravotní výkony o Elektronické objednávání na vybraná zdravotnická pracoviště

• Zajištění interoperability NIS v rámci „ekosystému“ celé ČR o Standardizovaná a automatizována obousměrná komunikace s jinými systémy (LIS, EIS, lékárna, MIS atd.)

  • Standardizovaná a automatizovaná obousměrná komunikace s jinými subjekty (ZZS, externí ambulance, laboratoře, specializovaná zařízení atp.)

  • zajištění interoperability NIS – HL-7, DASTA import/export, možnost automatického generování zprávy pro odeslání např. OL – výsledek vyžádaného vyšetření

  • Automatizovaná komunikace s organizacemi zajišťujícími distribuci číselníků a sběr dat (např. registry ÚZIS, SÚKL, b2b služby VZP)

Je nezbytně nutné zajištění kontinuity provozu zdravotnických zařízení v průběhu implementace NIS. Po stránce nepřetržitého provozu se předpokládají pouze plánované odstávky pouze na nezbytnou dobu.

Dále je požadována kontinuita nastavených parametrů, všech číselníků, definic, tiskových sestav, definice organizační struktury a jiných aspektů provozu. Nepředpokládá investici do opětovného zadávání a pořizování těchto údajů.

Počet pracovišť, uživatelů, pracovních stanic a lůžek za jednotlivé nemocnice vztahujících se k NIS je uveden v tabulkách 5 -8 (stav k 1. 7. 2017).

Tabulka 5 Kapacity Dvůr Králové nad Labem

Klinická oddělení nemocnice Dvůr Králové	Počet lůžek	Počet pracovních stanic	Počet ambulancí	Počet JIP	Počet operačních sálů	Počet lékařů	Počet sester
Interní	49	11	2	1	0	7	16
Chirurgické	52	11	2	1	2	7	20
Urologické	20	11	3	0	1	5	10
Následná péče	50	4	0	0	0	2	13
Gynekologie	0	1	1	0	0	1	0
Endoskopie	0	1	1	0	0	3	2
ARO	0	3	0	0	0	3	4
Dětská LSPP	0	1	1	0	0	1	11
OKBH	0	6	0	0	0	1	9
RTG	0	4	2	0	0	3	5
Ultrazvuk	0	1	1	0	0	5	1
CT	0	1	1	0	0	3	1
Rehabilitace	0	2	2	0	0	0	7

Tabulka 6 Kapacity Jičín

Klinická oddělení nemocnice Jičín	Počet lůžek	Počet pracovních stanic	Počet ambulancí	Počet JIP	Počet operačních sálů	Počet lékařů	Počet sester
Interní Jc	83	40	7	1	0	35	40
Dialýza	7	5	1	0	0	2	12
Interní NB	22	17	7	0	0	9	21
Chirurgické	51	28	4	0	0	20	38
Gynekologickoporodnické	35	14	2	0	0	14	26
Pediatrické (včetně novorozeneckého)	32	13	4	0	0	13	34
ARO	7	10	1	0	0	11	25
ORL	19	12	3	0	0	11	10
Neurologie	22	11	3	0	0	10	12
RKO	20+9stac.	16	4	0	0	7	18
Psychiatrické	21	10	3	0	0	5	12
LDN	158	21	0	0	0	7	47
Plicní	0	8	1	0	0	2	3
LPS	0	6	5	0	0	31	0
Centrum klin. labor.	0	0	0	0	0	0	0
OKB	0	25	1	0	0	2	32
OKM	0	10	0	0	0	2	10
OTH	0	13	1	0	0	3	12
Rehabilitační	35	22	4	0	0	7	44
RDG	0	23	0	0	0	6	18
ONM	0	5	0	0	0	2	5
Lékárna	0	11	0	0	0	0	13
COS	0	5	0	0	3+2 zákrokové	0	14
Stravování	0	9	0	0	0	0	9
DZS	0	4	0	0	0	0	3
CS	0	1	0	0	0	0	2

Tabulka 7 Kapacity Náchod

Klinická oddělení nemocnice Náchod	Počet lůžek	Počet pracovníc h stanic	Počet ambulan cí	Poč et JIP	Počet operačníc h sálů	Počet lékařů	Počet sester
ARO Náchod	6	15	1	0	0	14	39
Dialyzační Náchod	13	5	1	0	0	1	12
Endoskopické centrum Náchod	1stac	13	12	0	0	6	11
Gynekologickoporodnické Náchod	45	19	2	0	2	16	36
Chirurgické Náchod	59	27	9	1	2	16	50
Imunologie Náchod	0	1	1	0	0	2	1
Infekční Náchod	0	2	2	0	0	1	1
Interní Náchod	66	38	7	1	0	23	79
Neurologické Náchod	34	22	4	1	0	15	29
Onkologické Náchod	0	10	4	0	0	4	4
ORL Náchod	5	14	4	0	1	6	14
Ortopedické Náchod	25	17	3	0	2	9	17
Pediatrické Náchod vč. Novorozenců	45	20	10	0	0	14	36
RHB Náchod	34	20	3	0	0	4	35
Urologické Náchod	20	16	4	0	1	12	14

LSPP Náchod (dospělí + děti)	0	3	2	0	0	27	23
Logopedie Náchod	0	2	1	0	0	3	0
Odd. sociální péče Náchod	0	3	1	0	0	3	0
PKBD Náchod	0	21	1	0	0	5	22
PKHTS Náchod	0	21	1	0	0	6	16
MBL Náchod	0	18	1	0	0	7	9
RDG Náchod	0	24	0	0	0	13	17
Patologie Náchod	0	9	0	0	0	4	8
COS Náchod	0	10	0	0	0	1	15
Centrální sterilizace Náchod	0	1	0	0	0	0	3
Psychiatrické Nové Město nad Metují	30	14	2	0	0	8	14
Chirurgické Broumov	0	1	1	0	1	1	2
Interní Broumov	31	14	3	0	0	10	25
LNP Broumov	64	12		0	0	2	23
Multidisciplinární Broumov vč. NIP	10	7	1	0	0	8	14
PKBD Broumov	0	16	1	0	0	5	9
RDG Broumov	0	5	0	0	0	2	5
LDN + LNP Jaroměř	103	17	0	0	0	7	28
PKBD Jaroměř	0	4	0	0	0	0	3
PKDB Opočno	0	3	0	0	0	1	3
PL České Meziříčí	0	2	1	0	0	1	1
ARX Xxxxxxx x.Xx.	5	11	1	0	0	14	31
Gynekologickoporodnické Rychnov x.Xx.	30	14	6	0	1+1 sekční	7	24
Chirurgické Rychnov x.Xx.	54	27	7	1	2	14	51
Interní Rychnov x.Xx.	71	22	5	1	0	19	54
Následná rehabilitační péče Rychnov x.Xx.	40	6	0	0	0	3	14
Onkologické Rychnov x.Xx.	0	4	1	0	0	1	2
Ortopedické Rychnov x.Xx.	25	16	2	0	2	11	15
Pediatrické Rychnov x.Xx. vč. Novorozenců	30	12	4	0	0	12	24
Psychiatrické Rychnov x.Xx.	0	1	1	0	0	1	0
Rehabilitační Rychnov x.Xx.	0	6	3	0	0	1	14
LSPP Rychnov x.Xx. (dospělí + děti)	0	4	2	0	0	28	8
Logopedie Rychnov x.Xx.	0	1	1	0	0	1	0

Odd. sociální péče Rychnov x.Xx.	0	1	1	0	0	2	0
Pracovně-lékařská služba Rychnov x.Xx.	0	1	1	0	0	1	1
PKBD Rychnov x.Xx.	0	15	0	0	0	3	15
PKHTS Rychnov x.Xx.	0	10	1	0	0	2	9
Centrální operační sály Rychnov x.Xx.	0	8	0	0	0	1	14
Centrální sterilizace Rychnov x.Xx.	0	2	0	0	0	0	3
Stravování Rychnov x.Xx.	0	6	0	0	0	0	3
DZS Rychnov x.Xx.	0	1	0	0	0	0	0

Tabulka 8 Kapacity Trutnov

Klinické oddělení	Počet lůžek	Počet pracovní ch stanic	Počet ambula ncí	Poče t JIP	Počet operačních sálů	Počet lékař ů	Počet sester
Interna	60	34	14	0	0	17	37
Interna JIP	6	5	0	1	0
Dialýza	8	3	2	0	0	1	10
Rehabilitace	20	11	17	0	0	4	23
THO	0	22	2	0	0	3	22
Plicní	0	4	3	0	0	1	2
Neurologie	30	18	7	0	0	6	23
Neurologie JIP	4	4	0	1	0
Pediatrie	20	10	10	0	0	6,5	20
Novorozenci	10	2	0	0	0	1	9
Radioterapie	28	11	6	0	0	2,5	13
Dermatologie	0	5	4	0	0	1,5	2
Nukleární medicína	0	9	2	0	0	2	8
Chirurgie	50	17	6	0	2	14	34
Chirurgie JIP	4	2	0	1	0
Gynekologickoporodnické	43	24	15	0	2	9	30
Ortopedie	20	11	5	0	1	6	11
Oční	0	5	2	0	0	2	2
ORL	(zahrnuto v CHIR, jako integrovaná lůžka)	8	4	0	1	2	3
ARO	5	7	1	1	0	6	21
OKB	0	15	3	0	0	1	14
Mikrobiologie	0	26	1	0	0	3	14
RTG	0	30	8	0	0	8	15
COS+CS	0	13	0	0	součet CHIR+ORL+ORTO 4 (plánování operací)	0	16
Externí pracoviště vlastní	0	5	5	0	0	0	0
Osteomed (externí cizí ZZ, smluvně využívající licenci NIS)	0	2	2	0	0	0	0
Externí pracoviště cizí (náhled do zdravotní dokumentace)	0	92	92	0	0	0	0

2.1 Licenční ujednání

Dodavatel v rámci plnění předmětu této smlouvy realizuje pro zadavatele dílo podléhající ochraně podle zákona č. 121/2000 Sb., o právu autorském (autorský zákon), a zákona č. 89/2012 Sb., občanského zákoníku, a tak poskytuje zadavateli licenci, tj. oprávnění k výkonu práva užívat jím vytvořené autorské dílo. Dodavatel poskytuje licenci pro současnou práci na neomezeném počtu pracovních stanic zadavatele či dotčených organizací ve smyslu smlouvy o dílo (tzv. „unlimited licence“).

Dodavatel prohlašuje, že dílo ani jeho části, které jsou autorským dílem dodavatele, nemají žádné právní vady, že nejsou zatíženy právy třetích osob a že je dodavatel zcela oprávněn vykonávat veškerá majetková autorská práva v celém rozsahu, s dílem disponovat a uzavřít se zadavatelem smlouvu na celý rozsah předmětu plnění dle smlouvy o dílo. Dodavatel prohlašuje, že mu k dílu nebo jeho částem náleží veškerá oprávnění, která zadavateli poskytuje, a to v rozsahu práv autorských, práv souvisejících s právem autorským i práv spadajících pod režim ostatních právních předpisů na ochranu duševního vlastnictví a dále v rozsahu práv osobnostních.

Jsou-li součástí díla části nebo produkty jiné osoby (původce software), jsou licence k nim součástí díla a úhrada za jejich užívání je zahrnuta v celkové ceně díla. Dodavatel je povinen doložit zadavateli nejpozději před začátkem implementace, že licence třetích osob k standardnímu software jsou registrovány u jednotlivých původců software na zadavatele jako jejich vlastníka, a že údržba a podpora je registrována na zadavatele u poskytovatele podpory.

Licence k předmětu plnění nebo k jeho části, i licence třetích osob, nesmějí být omezeny počtem uživatelů.

Dodavatel prohlašuje, že nositelům výše uvedených práv nepřísluší a nebude příslušet vůči zadavateli žádné právo na odměnu, či jakékoliv jiné plnění v souvislosti s realizací díla nebo jeho částí. Dodavatel se dále zavazuje, že výsledky své činnosti pro zadavatele, zachycené a předané zadavateli v jakékoliv podobě, neposkytne bez předchozího písemného souhlasu zadavatele třetí straně.

V případě, že se uvedená prohlášení dodavatele nezakládají na pravdě, odpovídá dodavatel zadavateli a dotčeným nemocnicím za z toho vyplývající důsledky v plném rozsahu včetně odpovědnosti za způsobenou škodu. Uplatní-li třetí osoba své právo k dílu nebo jeho části, zavazuje se dodavatel bez zbytečného odkladu na vlastní náklady učinit potřebná opatření k ochraně výkonu práv zadavatele, pokud jej k tomu zadavatel zmocní.

Dodavatel poskytuje zadavateli, jeho právním nástupcům a všem osobám ovládaným zadavatelem na dobu trvání majetkových práv autora k dílu nevýhradní, převoditelnou licenci k výkonu práva dílo a jeho případné další verze užít a modifikovat, a to neomezeně co do místa a množství, času, způsobu a formy. Zadavatel není povinen využít poskytnout licenci ani zčásti.

Oblastní nemocnice Náchod a.s. ve stávajícím stavu sdílí NIS s třetí stranou. Stávající dodavatel NIS poskytl právo užívání programového vybavení třetí osobě - LDN Opočno, a to v rozsahu: aplikační programové vybavení - moduly lůžkové oddělení, ambulance a výkaznictví NIS v rozsahu 5 licencí. V případě Oblastní nemocnice Trutnov a.s. se jedná o subjekt privátní revmatologické a osteologické ambulance Osteomed s.r.o. - moduly ambulance a výkaznictví v rozsahu 2 licencí (1 lékař + 1 sestra; 2 stanice) s možností využití více instancí NIS na každé stanici. Zadavatel požaduje toto právo zachovat i v novém NIS včetně převodu dat.

Zadavatel je oprávněn poskytovat neomezený počet podlicencí ve stejném nebo omezeném rozsahu, ve kterém je dílo oprávněn užívat dle této smlouvy.

Smluvní strany tímto výslovně souhlasí s tím, že veškerá finanční vyrovnání za udělení licenčního oprávnění k užití díla dle této smlouvy jsou již plně zahrnuta v ceně díla.

Dodavatel uděluje zadavateli:

• oprávnění dílo (nebo jeho dílčí část), které podléhá ochraně podle zákona č. 121/2000 Sb. (autorský zákon) a zákona č. 89/2012 Sb., občanského zákoníku, upravovat, zpracovávat, měnit jeho název,

• a oprávnění dílo spojit s dílem jixxxx x dílem dále pracovat za účelem jeho dalšího rozvoje a používání;

• právo realizovat rozhraní díla s jinými, zadavatelem provozovanými softwarovými produkty.

2.2 Licence k dílu

Dílo tedy informační systém a všechny jeho komponenty mimo licencí serverových operačních a databázových systémů bude dodavatelem poskytnut s následujícím rozsahem licenčního oprávnění:

1. licence neomezená způsobem a rozsahem užití pro zadavatele

2. nevýhradní licenci k veškerým známým způsobům užití takového díla, zejména, nixxxxx xšak výlučně k účelu, ke kterému bylo takové dílo dodavatelem vytvořeno v souladu se smlouvou, a to v rozsahu minimálně nezbytném pro řádné užívání díla zadavatelem;

3. licenci neomezenou územním ani množstevním rozsahem a dále neomezenou způsobem nebo rozsahem užití;

4. licenci udělenou na dobu neurčitou;

5. licenci, kterou není zadavatel povinen využít;

Povinnost týkající se licence platí pro dodavatele i v případě zhotovení části díla poddodavatelem.

3. Licence k aplikační části informačního systému

Licence bude poskytnuta v rozsahu, který žádným způsobem neomezí užití díla. Může se jednat o svobodný i uzavřený software.

3. Licence k databázové části informačního systému

Licence bude poskytnuta v rozsahu, který žádným způsobem neomezí užití díla. Může se jednat o svobodný i uzavřený software.

3. Licence a vlastnictví dat

Veškerý datový obsah vytvořený v informačním systému zadavatele, tedy veškerá data, a k nim se vážící licenční práva náleží zadavateli. Zadavatel bude jediným vlastníkem obsahu (dat) zanesených v informačním systému.

Se svými daty objednatel nakládá dle svého uvážení v souladu s platnou legislativou a může je zpracovávat v jakýchkoliv dalších informačních systémech. Data nebudou daty dodavatele. Dodavatel odpovídá za konzistentnost dat a data samotná při jejich zpracování zadavatelem v informačním systému dodavatele, a to v souladu s aktuální dokumentací k tomuto informačnímu systému. Dodavatel neodpovídá za data chybně zadaná zadavatelem a ani za zpracování těchto dat zadavatelem v systémech třetích stran.

Zadavatel v rámci svých pokynů a smluvních ustanovení umožní v omezeném rozsahu výhradně za účelem poskytování dodávek a služeb k informačnímu systému pracovat s těmito daty dodavateli.

3 OBECNÉ POŽADAVKY NA APLIKAČNÍ PROGRAMOVÉ VYBAVENÍ

Zadavatel požaduje implementaci systémů založených na moderních a všeobecně uznávaných technologických standardech s perspektivou rozvoje po dobu minimálně 20 dalších let.

Navrhované systémy musí mít jednotné uživatelské rozhraní se způsobem ovládání respektujícím standardy MS Windows ve všech modulech a funkcionalitách, vyjma odůvodněných případů.

Správa systémů musí být integrální součástí celku s obdobným ovládáním.

Všechny části systémů musí s uživatelem komunikovat česky; pro tvorbu individuálních výstupů, export a import dat a další funkce vyhrazené administrátorům, správcům a vybraným uživatelům se připouští komunikace v angličtině.

Navrhované systémy umožní hierarchizovatelné nastavení přístupových práv se stanovením rozsahu přístupu i stupně oprávnění manipulace se záznamem (čtení / nový záznam / úprava / rušení záznamu). Princip nastavování přístupových práv jednotlivým uživatelům musí vycházet z definice libovolného množství uživatelských rolí, do kterých jsou samotní uživatelé přiřazování.

Všechny tiskové výstupy navrhovaného systému musí být individuálně modifikovatelné z hlediska rozvržení tiskové stránky.

V systému bude možné strukturované a parametrizovatelné zadávání údajů s možností sdílení jednotlivých položek v dalších dokumentech, s možností nastavení jednotlivých položek (povinný údaj, možné hodnoty) a vlastních číselníků pro jednotlivé položky. Systém musí umožňovat import, popř. validaci číselníků dle definovaných vzorů (např. VZP, RÚIAN).

V systému bude evidována jednoznačná identifikace kdo a kdy, jakou změnu v záznamu provedl se zaznamenáním historie změn, v indikovaných případech i historie, kdo do dokumentu nahlédl.

Systém musí být připraven ke kompletnímu vedení čistě elektronické zdravotnické dokumentace. Je požadován popis komunikace s dlouhodobým elektronickým archivem.

Možnost ovládání systému klávesnicí.

4 POŽADAVKY NA KOMUNIKAČNÍ VAZBY

4.1 Komunikace s interními laboratořemi

Zadavatel požaduje zajištění komunikace klinického informačního systému se stávajícím laboratorním informačním systémem Stapro OpenLIMS v tomto rozsahu:

• ynchronizace registru laboratoře s registrem KIS tak, že změny v registru KIS jsou po odsouhlasení promítány do registru laboratoře s upozorněním na případný rozpor mezi KIS a LIS. Výsledkem synchronizace bude tedy generování sestavy zjištěných rozdílů. Rozdíly budou po odsouhlasení a kontrole (např. B2B) zapsány do cílového systému.

• Synchronizace Dg mezi KIS na LIS.

• On-line synchronizace základních číselníků laboratoře s číselníky KIS, a to ve směru z laboratoře do KIS v rozsahu číselník metod včetně všech hodnotících mezí, číselník jednotek, seznam funkčních skupin a skupin metod, matice textových výsledků. Synchronizaci nesmí být pouze na základě rodného čísla nebo čísla pojištěnce, ale musí být shoda jak této položky, tak jména a příjmení.

• Ve směru z KIS do laboratoří bude on-line synchronizován seznam žadatelů, s ošetřením stavu, kdy žadatel nemá aktuální smlouvu s pojišťovnou

• Elektronická žádanka je distribuována z KIS a v laboratoři bude připravena ke zpracování v okamžiku jednoznačného spárování s materiálem. Materiál bude označen čárovým kódem. Při ordinování laboratorních vyšetření sledovat frekvenci a upozornit na její překročení. Upozornit na neshodu mezi Dg. a požadovaným vyšetřením. Upozornit na nemožnost ordinace zakázaných metod pro ambulantní pracoviště.

• Okamžitě po uvolnění výsledků laboratoří budou nálezy včetně interpretací přenášeny do KIS. Možnost využít i postupné uvolňování výsledků jednotlivých metod tak, aby po dokončení procesu byly všechny metody zařazeny pod jednu událost.

• On-line distribuce výkonů provedených v laboratoři do centrálního zpracování výkaznictví, tj.

okamžitě po uvolnění výsledků jsou do KIS zapisovány i podklady pro vykázání zdravotní péče, včetně on-line Dobropisů a stornování chybně vykázané péče

• Pro uživatele v KIS historický přehled výsledků v LIS

• Možnost oboustranné komunikace s jinými zdravotnickými zařízeními

• Možnost zobrazení laboratorního nálezu (výsledkového listu) ve formě podepsaného/označkovaného PDF/A dokumentu v klinickém informačním systému.

4.2 Další požadavky na komunikaci

• NIS komunikuje s eHealth (IS ZZS)

• Systém musí podporovat datová rozhraní pro výměnu dat DS MZČR a HL7 v případech, kdy bude tato komunikace vyžadována, včetně implementace nově vydaných verzí DS MZ.

• Systém bude komunikovat s ostatními IS nemocnice specifikovanými v tabulkách č. 9–12, které jsou uvedeny v následující kapitole.

5 POŽADAVKY NA PŘEVOD DAT Z PŮVODNÍCH SYSTÉMŮ

Zadavatel požaduje převod dat z původních systémů uvedených v tabulkách č. 9–12. Budou převedeny historické pacientské údaje ve dvou rovinách:

1. Budou převedena data pacientů, kteří projdou kontrolou na duplicitu a validitu čísla pojištěnce. Zadavatel poskytne součinnost u případných duplicit.

2. Položky obsahující pacientská data budou převedeny do odpovídajících položek datových struktur navrženého systému tak, aby byla zachována logika jednotlivých události (hospitalizace, ambulantní vyšetření a k tomu náležející komplementární vyšetření). Dodavatel zajistí minimální rozsah převáděných dat v následujícím rozsahu:

   • Stanovení data dle zákonných lhůt archivace

   • Centrální registr pacientů

   • Ambulantní sledování

   • Klinické dokumenty

   • Hospitalizace

   • Laboratorní výsledky

   • Anamnéza – na centrální kartě

   • Diář

   • Rodinné vazby

   • RTG nález

   • Urgentní informace

Tabulka 9 Požadavky na převod dat z původních systémů Dvůr Králové nad Labem

Oblast		Název	Výrobce	Náhr ada s pře vode m dat	Náhra da bez převo du dat	Ponech ání s komu nikací*)	Ponec hání bez komu nikace
Klinický systém výkaznictví	a	FONS AKORD	Stapro	A
PACS		MariePACS	ORCZ			A
Laboratoře		OpenLIMS	Stapro			A
MIS		FonsReports	Stapro			A
EIS		Feis	Arbes			A
PAM		MD NAV	Microsoft			A
Objednávání SZM a léků		Neos	Medisystem s			A
Správná lab. praxe		SLP	SEKK				A
Pom. pro vykaz. diagnoz		PVD	ICZ				A
Adresářové služby		AD	Microsoft			A
Komunikace		ePacs				A
Komunikace		Medidata				A
ZP		portál				A
UZIS		portál				A
Daňová správa		portál				A
ČSSZ		Portál				A
Česká spořitelna		portál				A

Tabulka 10 Požadavky na převod dat z původních systémů Jičín

Oblast		Název	Výrobce	Náhr ada s pře vode m dat	Náhra da bez převo du dat	Ponech ání s komu nikací*)	Ponec hání bez komu nikace
Klinický systém výkaznictví	a	Mpa	ICZ	A
RIS		Xxxxxx	Xxxxxxx	A
Nefrolog. IS		Nefris	ProDos			A
PACS		MariePACS	ORCZ			A
Lékárna		Mediox	ApatykaServ is			A
Laboratoře		OpenLIMS	Stapro			A
Stravovací provoz		Kredit	Anete			A
Sklad léků						A
IS léčivých přípravků		AISLP	Inpharmex			A
MIS		ICZ AMIS*MIS	ICZ		A
MIS		FonsReports	Stapro			A
EIS		Feis	Arbes			A
PAM		MD NAV	Microsoft			A
Objednávání SZM a léků		Neos	Medisystem s			A
Správná lab. Praxe		SLP	SEKK				A
Pom. vykaz. Diagnoz		PVD	ICZ				A
ZákonyČR		ZákonyČR	Arnet On Line				A
Adresářové služby		AD	Microsoft			A
ZZS		ISAC	ICZ			A
DMS		Sharepoint	Techniserv IT				A
Komunikace		ePacs				A
Komunikace		Mise, Medidata				A
ZP		portál				A
UZIS		portál				A

Tabulka 11 Požadavky na převod dat z původních systémů Náchod

Oblast	Název	Výrobce	Náhr ada s pře vode m dat	Náhra da bez převo du dat	Ponech ání s komu nikací*)	Ponec hání bez komu nikace
Klinický a ambulantní IS (lokalita Náchod,Nové Město nad Metují, Jaroměř, Opočno a Broumov)	NIS Medea	Stapro	A
Klinický a ambulantní IS (lokalita Rychnov n.K.)	NIS Medea	Stapro	A
Kartotéka Interního odd.	MS - Access	Vlastní	A
Laboratorní IS	OpenLIMS	Stapro			A
Hematologický IS	HEMO	Xxx. Xxxxxxx			A
Laboratorní komunikace	IPU	Sysmex				A
Nefrologický IS	Nefris	PRODOS			A
PACS	MariePACS	ORCZ			A
Onkologický registr	NOR				A
Stravování Náchod	Astris	EFG			A
Stravování Rychnov n.K.	Gurmet	Stapro			A
Stravování Broumov	Xxxxxxxxx – Kasiopea	Laftrade			A
IS léčivých prostředků	Aislp	Inpharmex			A
Sledování preskripce léků	Radix Data Expert	Medisystem s			A
MIS	FonsReports	Stapro			A
Ekonomický IS	Feis	Arbes			A
Personální IS	Navision	WebCom			A
Objednávání SZM, léky	NeosWEB	Medisystem s			A
Hlášení nežádoucích událostí	Hlášení nežádoucích událostí	Institut pro aplikovaný výzkum, edukaci a řízení ve zdravotnictví				A
Zákony	Codexis	Atlas Consulting				A
DMS	Sharepoint	Helius consulting				A
Helpdesk	Stapro HelpDesk	Stapro				A
Objednávání prádla		Fišer				A
Správa přístrojů	FAMA	Tesco			A
Adresářové služby	AD	Microsoft				A
ZZS	ISAC	ICZ			A
Komunikace PACS	ePACS	ICZ			A
Komunikace výsledky	MISE, Medidata, eZpráva				A
ZP	Portál				A
ÚZIS	Portál				A

Tabulka 12 Požadavky na převod dat z původních systémů Trutnov

Oblast	Název		Výrobce	Náhr ada s pře vode m dat	Náhra da bez převo du dat	Ponech ání s komu nikací*)	Ponec hání bez komu nikace
Klinický informační systém (KIS + RIS)	StaproH (dříve NIS HiComp)		Stapro	A
IS léčivých přípravků - dnes součástí StaproH	AISLP		Inpharmex		A
Stravovací provoz	StaproH (dříve NIS HiComp)		Stapro			A
Groupware (nyní součástí StaproH jako nástěnka, helpdesk, pošta, sklady a další funkce)	StaproH (dříve NIS HiComp)		Stapro			A
Modul výkaznictví	Akord		Stapro	A
Nefrologický IS	Nefris		ProDos			A
PACS	Xxxxx PACS		ORCZ			A
HEMO - program pro evidenci dárců krve	HEMO		Xxx. Xxxxxxx			A
Sledování preskripce léků	RDE		Medisystem s			A
Laboratoře	OpenLIMS		Stapro			A
MIS	FonsReports		Stapro			A
PAM	MD NAV		Microsoft			A
EIS	Feis		Arbes			A
Objednávání SZM a léků	Neos		Medisystem s			A
ZZS (výměna pac. dokumentace)	ISAC		ICZ			A
Komunikace	ePACS RediMed	/	ICZ			A
Komunikace	MISE		Stapro			A
Komunikace	Medidata		Compek			A
ZP	portál		jednotlivé ZP			A
Agenda ÚZIS	portál		ČSÚ, ÚZIS a MZČR			A
Přístupový systém	Skyla		ADI - Skyla			A
Plánovací systém ozařovny ONK	PLANW		ÚJP			A
Monitory životních funkcí			Dle konkrétního dodavatele JIP			A
Monitoring CTG GYPO	CTG ONLINE					A
Ovládací SW pro terapeutický rentgen						A
Adresářové služby	AD		Microsoft			A

^*) Komunikace je řešena prostřednictvím výměny souborů. U jednotlivých systémů označených A se jedná o přenosy základních informací typu – žádanka na vyšetření, požadavek na cenu léku v ústavní lékárně, osobní údaje – lékař sestra, k-dávky apod. V žádném případě se nejedná o export složitých datových struktur včetně celé databáze. Konkrétní specifikace vyměňovaných dat bude předmětem implementační analýzy. Zajištění součinnosti třetích stran při napojení konkrétních systémů zejména formou poskytnutí obsahu a formátu datové věty zejména tam, kde se nejedná o standardizované protokoly, je pak povinností objednatele (zadavatele).

6 POŽADOVANÉ VLASTNOSTI A FUNKCE JEDNOTLIVÝCH OBLASTÍ

Úvodní popis

NIS bude provozován jako čtyři nezávislé instance ve čtyřech nemocnicích.

V každém zdravotnickém zařízení bude NIS provozován ve zdvojeném (redundantním) režimu a to ideálně ve dvou lokalitách (serverovnách), které budou totožné, co se týče výpočetního výkonu dedikovaného pro provoz NIS. Možné řešení je i provoz v jedné serverovně, ale stále v redundantním režimu.

Serverová infrastruktura bude tvořena dvěma fyzickými servery (Hosty), kde v každé lokalitě bude umístěn jeden Host. Oba servery pak dohromady vytvoří základ virtualizačního prostředí pro provoz virtuálních serverů (VM).

V primární lokalitě budou provozovány produkční VM pro NIS.

V sekundární lokalitě musí být schopno nastartovat tzv. stínové kopie těchto VM, tak aby mohly okamžitě převzít funkcionalitu primárních kopií v případě havárie.

Produkční VM budou přistupovat k datům (LUN), které jim zprostředkuje virtualizační vrstva datových úložišť (polí).

V každé lokalitě bude umístěna stejná kopie produkčních dat, kterou zajistí synchronní replikace datových úložišť probíhající na pozadí. V případě havárie jednoho úložiště dojde k okamžitému přepnutí aktivních LUNů na pole sekundární.

Vysoká dostupnost kritických dat bude podpořena duálními kontroléry, kterými budou obě pole osazena a redundancí disků na úrovni RAID.

Nezbytná míra redundance bude zajištěna také na úrovni SAN switchů.

Celá infrastruktura bude připojena do sítě LAN dvěma fyzickými serverovými přepínači, které vytvoří jeden virtuální switch. V případě havárie jednoho přepínače nedojde ke ztrátě dostupnosti serverové infrastruktury.

Funkční specifikace systému bude upřesněna detailní analýzou implementace produktu a detailním projektem implementace produktu.

Ideové schéma a popis infrastruktury pro nový NIS

6.1 Minimální požadavky na klinický informační systém

Minimální požadavky na centrální část NIS včetně požadavků na administraci NIS jsou definovány v následující tabulce.

Požadavky na centrální a administrativní funkce NIS
Centrální registr
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
U jednotlivých pacientů vedení údajů o praktickém lékaři a odborných lékařích pacienta s jejich centrálně vedeným číselníkem. Veškeré adresy (pacient, praktický lékař, zaměstnavatel apod.) budou strukturalizovány dle číselníku RÚIAN tak, že při pořizování budou prováděny výběry. Číselník adres bude validován dle RÚIAN. Požadavek bude považován za splněný i v případě závazku dodavatele, že bude funkcionalita dopracována, až to bude legislativně a technicky možné.	ANO
Generování náhradního rodného čísla, možnost identifikace cizince.	ANO
Možnost sloučení chybně evidovaných pacientů	ANO
Záznam, komu je možné poskytovat informace	ANO
Možnost on-line ověření praktického lékaře pacienta	ANO
Pacientská administrativa včetně statistik
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Kontroly správnosti RČ, čísla pojištěnce, hlídání duplicit, možnost stornování, oprav chybně zadaných dat	ANO
Online kontrola příslušnosti pacienta k dané zdravotní pojišťovně (B2B) a platnost pojištění k danému datu	ANO
Oboustranná synchronizace změn registrů pacientů mezi NIS a spolupracujícími systémy (minimálně laboratorní systém, PACS, MIS). To znamená, že po provedení akcí: nový záznam, oprava, zneplatnění,	ANO

sloučení se vygeneruje rozdílová sestava, kterou je možné zobrazit a do spolupracujícího systému přijmout.
Sběr veškerých údajů nutných pro periodické či jednorázové výkazy ÚZIS, zajištění jejich zpracování a vykázání s možností pořizování do formuláře pro ÚZIS	ANO
Sběr dat v NIS a jejich dávkový přenos do národních registrů, které mají specifikované datové rozhraní Registry UZIS: Národní onkologický registr (NOR) Národní registr hospitalizovaných (NRHOSP) Národní registr reprodukčního zdraví (NRRZ) Národní registr asistované reprodukce (NRAR) Národní registr novorozenců (NRNAR) Národní registr kardiovaskulárních operací a intervencí Národní registr kloubních náhrad (NRKN) Národní registr nemocí z povolání (NRNP) Národní registr léčby uživatelů drog (NRLUD) Národní registr úrazů (NRU) Národní registr osob trvale vyloučených z dárcovství krve (NROVDK) Národní registr pitev a toxikologických vyšetření prováděných na oddělení soudního lékařství (NRPATV) List o prohlídce zemřelého“ (vyhláška č. 297/2012 Sb.) Národní registr osob čekajících na transplantaci orgánů Informační systém tkáňových bank (TISSIS) Integrovaný systém transplantačních registrů	ANO
Výkaznictví pro zdravotní pojišťovny včetně podpory DRG
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Umožnit formalizovanou (dle číselníku) kategorizaci (automatickou) dokladů mimo položky definované metodikou s využitím při statistikách a uzávěrkových činnostech (transformace, modifikace)	ANO
Pro pořízení z klinické dokumentace umožnit pořízení způsobem zaklikávání z přednastaveného seznamu obvyklých kódů (včetně mnemotechnických přejmenování kódů)	ANO

Pořizovací dialog umožnit jako součást formuláře pro psaní dokumentace pacienta bez nutnosti odskakování do jiného formuláře, dialogu nebo okna.	ANO
Pro každý doklad vést vizualizovaný seznam chyb, prostřednictvím kterého je možné kontextově chyby opravovat	ANO
Umožnit komentovat doklad a případ DRG poznámkou (včetně historie poznámek)	ANO
Možnost filtrování dokladů pomocí definice obecného dotazu (např. SQL) vytvářeného uživatelem nebo správcem. Ukládání vytvořených pojmenovaných konfigurací filtru dokladů pro další použití uživatelem	ANO
Umožnit na úrovni správce výkaznictví nastavení každé z kontrol pro operace s doklady (minimálně při pořízení, při importu, při hromadném přepočtu dokladů a při sestavení dávek). Jednotlivé úrovně nastavení pro kontroly požadujeme minimálně jako měkkou kontrolu (dovolí vykázat plátci), tvrdou kontrolu (nedovolí vykázat plátci) a supertvrdou (nedovolí ani uložit při pořízení). Kontrolu je zároveň možné parametrizovat plátcem, IČZ, střediskem	ANO
Systém bude obsahovat kontrolu na povinné kombinace výkonů s automatickým nabídnutím doplnění druhého kódu při pořízení prvního	ANO
Zobrazení a kvantifikace dokladů vybraných k sestavení do dávek ještě před samotným sestavením; včetně možnosti manuálního výběru konkrétního (množiny) dokladů pro sestavení	ANO
Náhled na txt podobu Kdávky ještě před jejím uložením na disk; možnost editace dávky v takovém režimu	ANO
Transformace dat při uzávěrce dle předpisů (= záměna kódů podle pravidel). Možnost napsání, uložení a zařazení obecné procedury do uzávěrky (před a po sestavení dávek) pro práci správce s doklady (opravy a modifikace dokladů, změny výpočtů)	ANO
Možnost na úrovni správce výkaznictví pomocí interního grafického návrháře definovat proces skládající se z jednotlivých kroků uzávěrky (včetně rozhodování a větvení). Tento následně spouštět jako workflow.	ANO

Pro vytváření statistik nad doklady ZP mít také možnost definovat statistiku pomocí uživatelského dialogu, ve kterém si uživatel vybírá rozsah počítaných dat a strukturu výstupu (rozdělení sestavy, počítané hodnoty). Umožnit export sestavy minimálně do XML, XLS, CSV, PDF a DOC. Umožnit výstup sestavy do tabulky nebo do aktivního seznamu v IS, se kterým je možné následně pracovat	ANO
Sestavení případu DRG v průběhu hospitalizace dle aktuálně známých informací o délce případu, kritických výkonech a diagnózách pacienta	ANO
Případ DRG bude zobrazovat informace o výnosovém (dle indexu) i nákladovém ohodnocení (v členění na hotelové služby, zdravotní služby, operace, léky a materiál), včetně možnosti sledovat inlier/outlier pro různé modality. Umožnit v rámci případu zvolit verzi grouperu, kterým jsou údaje zpracovány, resp. požadavek splní i porovnání výsledků alespoň dvou přednastavených verzí grouperů. (nutné pro období zavádění DRG restart, kdy dojde k naprosté změně grouperu)	ANO
Aparát pro podporu DRG bude obsahovat funkce schvalovacího procesu nezávisle pro kodéry na oddělení a superkodéra nemocnice. Schválení musí být podmínkou pro uvolnění dokladů případu k vykázání do Kdávek. Umožnit definovat kritéria pro automatické schválení na každé z úrovní schvalovacího procesu	ANO
Optimalizační funkce nad případem DRG musí umožňovat automatické promítnutí změn souvisejících s výběrem optimálního pořadí Dg. současně jak do dokumentace pacienta tak dokladů	ANO
NIS poskytne v reálném čase kompletní účet za poskytnutou zdravotní péči ve zdravotnickém zařízení (např. samoplátce se započítáním nadstandardu, …) s výstupem do ekonomického systému	ANO
Systém bude obsahovat nástroje pro evidenci elektronických příloh č.2 (export-import jako XML). Na základě evidovaných příloh synchronizovat číselník pasportu výkonů.	ANO
Pro péči nad rámec v.z.p. umožnit vést konto pacienta, ze kterého je možné hradit poskytnutou péči. Konto umožňuje vklad před samotnou péčí anebo následné uhrazení přečerpané částky. Vlastností konta je úplná evidence pohybů na kontě.	ANO

Systém musí obsahovat nástroje pro fakturaci poskytnuté péče plátcům jako součást modulu pro vykazování péče. Sestavené faktury pak umožnit společně s dávkami přímo ze systému odesílat nástroji B2B na portály plátců. Faktury elektronicky přenášet rovněž do ekonomického systému	ANO
Statistické výstupy
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
statistiky nad vykazováním pojišťovně – výkony, léky, recepty, materiál	ANO
vykazování ÚZIS s generováním importních souborů v těch případech, kdy je UZIS akceptuje (např. registr úrazů) s možností manuální korekce výkazů	ANO
statistiky pro denní administrativu na ambulanci a lůžkách	ANO
Uživatel (správce NIS) bude mít možnost jednoduše dodělávat další potřebné statistiky nad daty strukturovaně zadanými do NIS: Tyto statistiky zpřístupnit koncovému uživateli přímo v NIS. Možnost exportu statistických výstupů do MS Excel.	ANO
Možnost vytvářet aktivní sestavy s přímým vstupem uživatele do záznamu (dokumentace pacienta), který je výsledkem vytvořené sestavy – tedy nejen statický report	ANO
Možnost zadat jednotlivým uživatelům požadovaná sledování a jejich automatická hlášení. Např. počty operací, patologické výsledky, návštěvu pacienta na ambulanci ke sledování event. Komplikací.	ANO
Sběr dat pro statistiky ATB střediska a odd. prevence a kontroly infekcí (např. trendy ve spotřebě ATB).	ANO
Tisky
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Systém bude umožňovat, aby správce nemocnice mohl tvořit vlastní tiskové sestavy pomocí standardního dotazovacího jazyka SQL s možností odvození vlastní sestavy z předdefinovaných (firemních).	ANO

Bude k dispozici grafický návrh designu tiskových sestav	ANO
Uživatel bude mít před tiskem možnost výběru z různých formátů zpráv (možnost volby různých předloh pro tisk).	ANO
Před tiskem zadané dokumentace bude mít koncový uživatel možnost náhledu vzhledu tištěného dokumentu	ANO
Systém bude primárně tisknout na výchozí tiskárnu operačního systému pracovní stanice (Windows) s možností uživatelského nastavení jiné konkrétní nainstalované tiskárny.	ANO
Systém musí podporovat tisk samolepících identifikačních štítků po jednom nebo v definovaném počtu na A4 arch s předřezanými štítky definované velikosti.	ANO
Možnost tisku do PDF Možnost připojení elektronického podpisu	ANO
Bude k dispozici grafický editor pro návrh designu tiskových sestav s možností odvození vlastní sestavy z předdefinovaných (firemních). Možnost exportu a importu tiskových sestav.	ANO
Systém musí umožňovat následující metody připojení tiskáren a směrování tiskových úloh: tisk na lokální tiskárnu (připojenou ke koncové stanici), tisk na sdílenou tiskárnu (připojenou k jiné koncové stanici), tisk na tiskárnu “připojenou” k serveru vzdálené plochy (RDP), pokud je stanice provozována službou vzdálené plochy, tisk na síťovou tiskárnu dostupnou systému NIS nebo příslušné službě NIS (tisková služba, aplikační server, apod.). Uživatel musí mít možnost výběru mezi tiskárnami s možností zapamatování volby.	ANO
Minimální požadavky na funkcionalitu přístupových práv
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)

Součástí řešení je komplexní nástroj pro centrální správu uživatelských účtů a řízení přístupů (identity management)	ANO
Integrace a Active Directory při přihlašování uživatele do NIS. Systém musí umožnit variabilitu v ověřování uživatele, a to buď Single sign on pomocí vazby na AD nebo vlastním vnitřním (lokálním) uživatelským účtem.	ANO
Systém bude umožňovat přizpůsobit přístupová práva dle organizačních zvyklostí zadavatele i jednotlivých odborností	ANO
Mechanizmus ošetření práv externího lékaře (náhled do zdravotní dokumentace): umožnit nebo omezit přístup na základě ověření, že pacient je registrován u externího (ošetřujícího) lékaře, nebo na základě rozpoznání, že lékař je žadatelem. možnost ověření registrace automaticky (B2B) umožnit manuálního režimu registrace ošetřujícího lékaře možnost zohlednění vůle pacienta, kdo je/není oprávněn (jaké) údaje vidět	ANO
Možnosti omezení: možnost omezení přístupu na pacienty svých pracovišť, možnost přístupu k historické dokumentaci právě ošetřovaného pacienta dle přidělených práv, možnost přístupu pro uživatele z jiných pracovišť pouze k danému typu dokumentace, možnost omezení přístupu na konkrétní druh dokumentace, která je z hlediska údajů citlivá.	ANO
Minimální požadavky na logovací aparát
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Nový systém bude z hlediska bezpečnosti přístupů evidovat minimálně: kdo, kdy a kde pořídil záznam do NIS, kdo, kdy a kde záznam v NIS změnil,	ANO

kdo, kdy a kde nahlížel do dokumentace s rozlišením “viděl obsah” (nález), ”viděl hlavičku vyšetření” (byly spatřeny údaje identifikace pacienta + oddělení nebo předmět vyšetření nebo diagnóza apod.) kdo, kdy a kde nahlížel na osobní údaje, kdo, kdy, kde a na jaké tiskárně tiskl dokumentaci. Log zaznamenávající výše uvedené údaje nebude nijak uživatelsky editovatelný.
Budou zalogovány veškeré změny osobních údajů, citlivých údajů, záznamů dokumentace pacienta - provedené automatickými importy, synchronizacemi nebo komunikací se spolupracujícími systémy (minimálně změny jako nový záznam, úprava, zneplatnění, slučováni).	ANO
Budou zalogovány veškeré změny osobních údajů, citlivých údajů, záznamů dokumentace pacienta - provedené činností administrátora nebo zásahem servisní podpory/dodavatele, jako např. opravy vč. hromadných, zneplatňování záznamů, časové korekce.	ANO
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
formátování písma dle zvyklostí typických pro RTF pro psaní dokumentace. Možnost nastavení a vyvolání jednotné uživatelské šablony.	ANO
možnost jednoduše vkládat části dokumentace do psaného textu (funkce drag and drop).	ANO
kontrola pravopisu v editorech s možností vypnutí	ANO
tvorba předdefinovaných textů koncovým uživatelem a jejich možnost vkládání na klávesovou zkratku do dokumentace	ANO
s předdefinovaným textem svázat další akce generované na pozadí – dotahování informací z jiné části dokumentace do editoru (i na základě SQL dotazu), možnost generování výkonů do dokladu pojišťovny s explicitním upozorněním, že kromě dotažení předdefinovaného textu budou provedeny i další klíčové změny mimo text (výkony, dg. různé příznaky apod.).	ANO

Možnost vkládání a přiřazování obrazové dokumentace, např. fotodokumentace s nastavením práv k jejich zobrazení.	ANO
Další požadované obecné vlastnosti
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
tvorba nových formulářů (i strukturovaných) do aplikace správcem NIS pro řešení specifických požadavků. Možnost jejich tvorby i na nižší uživatelské úrovni, např. pro potřeby jednotlivých oddělení či stanic	ANO
vytváření strukturovaných formulářů s údaji typu RTF text, číselník, datum, s možností kontroly položek (vazby mezi položkami, povinná pole) pro správce	ANO
vytváření a správy procesů tj. řazení objektů (formulářů, kontrol atp.) podle kroků a rozhodovacích uzlů. Možnost nadefinovat a navázat kontrolu úkolů pro uživatele na kroky v procesu	ANO
možnost napojit rozhodovací uzly na vstup uživatele (otázka) nebo na již známé údaje v NIS (např. při BMI<15)	ANO
přizpůsobení pracovní plochy potřebám koncového uživatele a použitého monitoru, možnost nastavení více aktivních oken (aktivních = s možností zápisu) na obrazovce s informacemi o pacientovi s možností nepovolení možnosti přizpůsobení, tj. vynucení konkrétní skladby plochy pro celý systém, kliniku, oddělení, pracovní stanici, skupinu uživatelů, uživatele.	ANO
Možnost současně pracovat s více pacienty najednou. Např. ambulantní karta jednoho pacienta v modulu ambulance a propouštěcí zpráva jiného pacienta v modulu oddělení s možností nepovolení takové možnosti, resp. vynucení konkrétního chování pro celý systém, kliniku, oddělení, pracovní stanici, skupinu uživatelů, uživatele.	ANO
Ve zdravotnické dokumentaci obecně přístupné vyhledávání přes všechny druhy zápisů fulltextem (např. slovo „mozek“).	ANO
Možnost vkládat obrazovou dokumentaci k pacientovi - fotku, oskenovaný dokument, video, s možností jednoduchého editoru (ořez, popisek, označení oblastí, označení bodů).	ANO
Generování žádanek s automatický vkládáním údajů	ANO
Podpora čárových kódů	ANO
Veškeré tiskové výstupy mající formu samostatné části zdravotnické dokumentace musí mít ekvivalentní výstupy ve formě elektronické zdravotnické dokumentace dle platné legislativy.	ANO

6.2 Vedení pacientské dokumentace na ambulancích

Jedná se o modul pro podporu administrativy a organizace práce na ambulanci, pro vedení ambulantní pacientské dokumentace, zajištění nezbytných statistik a vyhodnocení základních parametrů ambulance.

Minimální požadavky na vedení pacientské dokumentace na ambulancích jsou definovány v následující tabulce.

Požadavky na vedení pacientské dokumentace na ambulancích
Minimální funkcionalita týkající se organizace ambulantního provozu
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Možnost definice struktury ambulancí dle organizačního uspořádání s možností změny identifikátoru (zkratky) a názvu ambulance bez nutnosti vytvářet novou ambulanci. Centrální kartotéka pro více ambulancí, jednotlivé samostatné ambulance. Možnost "podrozdělení" ambulance na pracoviště/dispenzární skupiny/lékaře.	ANO
Zabezpečení procesu příchodu pacienta na ambulanci s definicí workflow pro dané pracoviště (příchod do čekárny, zadání údajů sestrou, vyšetření pacienta lékařem, objednání pacienta k další návštěvě/na vyšetření, tisk potřebné dokumentace), možnost automatického vyvolávání jednotlivých funkcí dle nastavení	ANO
Možnost sledování časů čekání v čekárně, délky vyšetření s možností uvádět tento údaj v ambulantní kartě pacienta (automatické či ruční vložení do textu). Požadavek bude považován za splněný i v případě závazku dodavatele, že bude funkcionalita dopracována, až to bude technicky možné.	ANO
Přehled čekajících pacientů, ošetřených pacientů – možnost výběru pacienta z čekárny k ošetření, možnost výběru z pacientů ošetřených v daném dni	ANO
Minimální funkcionalita týkající se lékařské dokumentace na ambulanci

Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Možnost zadání minimálně: anamnézy, stavu pacienta, diagnóz, žádanky na potřebná vyšetření, recepty, poukazy, výkony pro ZP, objednání na další návštěvu	ANO
Všechny potřebné úkony umožnit vykonávat rovnou při zápisu ambulantního vyšetření (minimálně zadání receptu, výkonů, žádanek)	ANO
Možnost jednoduchého vložení (např. klávesovou zkratkou) formalizovaných zápisů typu: zadané žádanky, diagnózy, předepsané léky a poukazy, trvalé diagnózy aj. přímo do textu ambulantní zprávy	ANO
Možnost fultextového hledání v historických zápisech dle např. klíčových slov, typu dokladu atp.	ANO
Možnost vložení fotodokumentace rovnou při zápisu ambulantního vyšetření	ANO
Přehledná historie ambulantních zápisů s možností vztáhnout přehled k vybranému údaji (např. pacient, ambulance, pracoviště, dispenzární skupinu, lékaře apod.).	ANO
Možnost sdílení dokumentace pacienta mezi lékařem a sestrou	ANO
Zdvojené okno – jedno pro tvorbu aktuální ambulantní karty, druhé pro zobrazení libovolné jiné zprávy či výsledků.	ANO
Možnost vkládání a přiřazování obrazové dokumentace, např. fotodokumentace, s nastavením práv k jejich zobrazení. Případně možnost propojení interaktivním odkazem se serverovým uložištěm s multimediálními materiály (Foto, video, …) také s možností omezení přístupu a zobrazení. Nebo plnohodnotná spolupráce se systémem PACS (tj. DICOM MWL, pořízení foto/video do studie, STORE, QUERY, RETRIEVE)	ANO
Při zadávání receptů:	ANO
● on-line informace o limitech preskripce,	ANO
● možnost práce s pozitivními listy (lékárna, VZP),	ANO

● možnost využít informace o aktuálním stavu zásob lékárny a informace o ceně	ANO
● mít k dispozici on-line informace o lékových interakcích, možnost nastavit závažnost interakce	ANO
● Nástroj pro tvorbu Magistraliter a jejich zařazení do číselníku	ANO
● možnost vidět historii zadaných receptů a vyhodnocení lékových interakcí,	ANO
● zobrazovat informaci o datu dobrání léků automaticky vypočtenou dle balení a dle dávkování (např. Warfarin 3mg 100 tbl. při dávkování 2 tbl. denně vydrží 50 dní)	ANO
● možnost využití napojení na AISLP a SÚKL (možnost ověření stavu u centrových léků).	ANO
● Veškeré tiskové výstupy mající formu samostatné části zdravotnické dokumentace musí mít ekvivalentní výstupy ve formě elektronické zdravotnické dokumentace dle platné legislativy.	ANO
Minimální funkcionalita týkající práce s pacienty
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Možnost zařazení pacienta do dispenzárních skupin a práce nad pacienty dispenzární skupiny	ANO
Možnost převedení pacienta z ambulance na hospitalizaci – včetně zadané dokumentace	ANO
Komplexní řešení objednávání pacientů k vyšetření v ambulancích, lůžkové části a jiných specializovaných pracovištích – na konkrétní datum a čas, na druh vyšetření, ke konkrétnímu lékaři, na dané pracoviště	ANO
Vedení e-Receptu a e-Neschopenky	ANO
Optimalizace komunikace mezi klinickými/ambulantními úseky, extramurálními klinickými pracovišti a komplementem ideálně	ANO
formou elektronického podávání požadavků na vyšetření (E-žádanka) a rovněž elektronického přenosu výsledku vyšetření do NIS
Minimální funkcionalita týkající se přehledů a statistik
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Přehledy minimálně v rozsahu: ambulantní kniha, předepsané recepty, provedené výkony, zadané ZUM, poplatky	ANO
Rozložení počtu ošetřených v čase a rozložení čekacích dob v ambulanci	ANO
Možnost tvorby ročních ambulantních statistik sledovaných ÚZIS z údajů, které jsou dostupné v NIS	ANO

6.3 Vedení pacientské dokumentace na lůžkových odděleních (standard, JIP)

Jedná se o modul pro podporu administrativy a organizace práce na lůžkovém oddělení, pro vedení pacientské dokumentace, zajištění nezbytných statistik a vyhodnocení základních parametrů oddělení.

Minimální požadavky na vedení pacientské dokumentace na lůžkových odděleních jsou definovány v následující tabulce.

Požadavky na vedení pacientské dokumentace na lůžkových odděleních (standard, JIP)
Minimální funkcionalita týkající se organizace práce na lůžkovém oddělení
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Zabezpečení procesu při administrativním příjmu pacienta k hospitalizaci s definicí work-flow pro dané pracoviště (vyhledání/zadání pacienta z/do registru, zadání dat o pacientovi, o hospitalizaci, o pojištění, uložení na lůžko), možnost automatického vyvolávání jednotlivých funkcí dle individuálního nastavení	ANO
Zabezpečení procesu při lékařském příjmu pacienta k hospitalizaci s definicí work-flow pro dané pracoviště při zadávání příjmové dokumentace (anamnéza, příjmová zpráva, diagnózy, vstupní vyšetření),	ANO

možnost automatického vyvolávání jednotlivých funkcí dle individuálního nastavení
strukturovaný zápis farmakologické anamnézy s textovým přenosem do příjmové zprávy, on-line sledování interakcí u FA	ANO
Možnost sdílení dokumentace pacienta mezi lékařem a sestrou	ANO
Možnost on-line hlášení příchozího nálezu	ANO
Informování koncového uživatele vyžádaném konziliu pomocí elektronické informace ze systému	ANO
Sledování indikátorů kvality (hlídání vzniku dokumentace, čekacích dob). On-line upozornění zodpovědného koncového uživatele na blížící se termín	ANO
možnost pohledu do historické dokumentace pacienta na jeden klik	ANO
Zabezpečení administrativních úkonů v průběhu hospitalizace pacienta - překlady, propuštění. Podpora správného vykazování, kontrola všech povinných údajů, potřebná hlášení za stanici, oddělení	ANO
Přístup do NIS pomocí mobilního dotykového klienta (náhled a zápis dokumentace: minimálně prohlížení lab. výsledků, dekurz, vizita)	ANO
Automatické vkládání monitorovaných hodnot z přístrojů (Tlak, puls, saturace, EKG, …)	ANO
Minimální funkcionalita týkající se vedení dokumentace v průběhu hospitalizace
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Vedení strukturovaného denního dekurzu. Přizpůsobení potřebám standardních oddělení a pracovištím JIP a ARO. Možnost vložení multimédií. Při vložení schémat možno ve schématech zakreslit značky (např. označit lokalizace dekubitů, rány, apod.). Možnost editace dekurzu pro potřebu jednotlivého oddělení uživatelem s administrátorským právem pro dané oddělení (primář či jiný pověřený pracovník)	ANO
Možnost průběžného popisu stavu pacienta s jednoznačnou identifikací kdo a kdy zápis provedl a přehledné zobrazení jednotlivých zápisů	ANO

Strukturovaná ordinace léků a infuzí. Zadávání z číselníku léků, možnost zadat lék mimo VZP číselník léků. Možnost provázání se skladem – přehledné označení léků, které jsou skladem při ordinaci léků. Vazba mezi aktuální medikací a trvalými léky (snadné přenesení)	ANO
Při ordinaci infúze složené z více preparátů automaticky dopočítat množství a po zadání začátku a rychlosti aplikace dopočítat konec, případně po zadání začátku a konce dopočítat rychlost aplikace.	ANO
Snadný výběr alternativ z ATC skupiny	ANO
On-line hlášení lékových interakcí (vyhodnocované z ordinovaných léků i z léků zadaných na recept, i u dotykového klienta)	ANO
Možnost přímého využití databáze AISLP	ANO
Možnost ordinace potřebných vyšetření a pokynů sestře s možností sestry potvrdit vykonání ordinace s identifikací sestry a zapsáním data a času splnění ordinace.	ANO
Možnost označení podání/nepodání léku sestrou s povinným zdůvodněním nepodání.	ANO
Přehledně (i graficky) vedený stav jednotlivých dávek léků (např. ordinováno, podáno, odmítnuto, vysazeno apod.)	ANO
Zadání TISS protokolu a dalších skórovacích schémat (SOFA, APACHE II, NIHSS, GCS apod.)	ANO
Možnost vytvoření vlastních skórovacích schémat administrátorem.	ANO
Vedení bilance tekutin	ANO
Důraz na možnost přizpůsobit tisky dekurzu zvyklostem oddělení	ANO
Možnost zadání diety a přídavků pacientovi	ANO
Možnost vedení strukturované sesterské dokumentace (ošetřovatelské anamnézy, ošetřovatelského plánu s hodnocením, překladové zprávy, screeningová vyšetření sestrou – xxxxxx xxxx, riziko dekubitů, test soběstačnosti, nutriční screening). Možnost použití mobilních technologií	ANO
Automaticky dotahovat již známé údaje o pacientovi v NIS do oš. dokumentace.	ANO

Na základě problémů v oš. anamnéze a zhodnocených rizik nastavit automaticky příslušné oš. diagnózy a intervence do plánu péče.	ANO
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
Zdvojené okno – jedno pro tvorbu aktuálního dekurzu či zprávy, druhé pro zobrazení libovolné jiné zprávy či aktuálních výsledků	ANO
Možnost evidence nežádoucích událostí (pády, dekubity, záměna pacienta, záměna strany, chybná medikace,…) včetně zaznamenání údajů o nápravných opatřeních. Statistické zpracování údajů o nežádoucích událostech jako indikátorů kvality. Vedení údajů o dekubitech, o pádu pacienta. Možnost on-line informování odpovědných pracovníků dle závažnosti a místa vzniku nežádoucí události s možností vytvoření importních souborů do ÚZIS	ANO
Možnost evidence obecných nežádoucích událostí, které se netýkají pacienta. Umožnit zadávání bez přístupu do NIS, ale zajistit společné vyhodnocování s pacientskými záznamy. Vést NU na pacienta i NU, které se pacienta netýkají (úraz personálu, technický problém, krádež mezi personálem)	ANO
Evidence a vyhodnocování nozokomiálních infekcí s možností automatického zasílání e-mailu odpovědným osobám při zápisu nozokomiální infekce. Mailem mohou zodpovědní pracovníci dostávat informace o nové nozokomiální nákaze	ANO
Lékařské propuštění pacienta z oddělení – tvorba propouštěcí dokumentace (propouštěcí zpráva, předběžná propouštěcí zpráva, list o prohlídce mrtvého, průvodní list k pitvě aj.)	ANO
Propouštěcí zprávu vygenerovat automaticky dle předem dohodnutých pravidel ze zadané dokumentace (jaká dokumentace, v jakém pořadí, forma výstupu)	ANO
Možnost vkládat do zpráv další informace ze zdravotnické dokumentace v uživatelem definovaném formátu.	ANO
Zabezpečení procesu při administrativním propuštění pacienta z oddělení – kontrola všech povinných údajů, možnost jejich doplnění při propouštění pacienta. Důraz na ergonomické chování systému, na možnost doplnění všech chybějících údajů z jednoho místa	ANO

Možnost vedení strukturovaných údajů specifických pro jednotlivé odbornosti a vykazování do příslušných národních registrů (NOR, NRKI, NKCHR, …). S možností vytvoření importních souborů do národních registrů	ANO
Veškeré tiskové výstupy mající formu samostatné části zdravotnické dokumentace musí mít ekvivalentní výstupy ve formě elektronické zdravotnické dokumentace dle platné legislativy.	ANO
Minimální funkcionalita týkající se přehledů a statistik
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Systém umožní vytvoření všech výstupů potřebných pro denní hlášení na stanici, pro měsíční hlášení pro ÚZIS	ANO
Statistiky o počtech pacientů, obložnosti, pohybu pacientů, podaných lécích, provedených výkonech, zadaných ZUM	ANO
Systém umožní on-line propojení na řešení manažerského systému, které provozuje ZHKHK (data výkaznická, preskripce a klinická data)	ANO
Vedení dokumentace k operaci
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Vedení strukturovaného operačního protokolu – důraz na přehlednost	ANO
V rámci operačního protokolu zadání všech provedených výkonů, ZUM, ZULP, použitých přístrojích, popis operačního výkonu, záznam o anestezii, evidence časů operace, OP týmu, údaje nutné pro ÚZIS, klíčová slova. Možnost strukturovaného popisu operace. U jednotlivých operací možnost zadání všech provedených výkonů, ZUM, ZULP klávesovou zkratkou na základě definice jednotlivých uživatelů.	ANO
V rámci operačního dne možnost sledování uživatelsky definovaných časů (neomezeného počtu) k operaci	ANO
Možnost plánování operací z NIS (jako integrální součást NIS), možnost nalezení prvního volného termínu dle délky operace, možnost jednoduše přesouvat operace mezi sály a mezi dny, grafické znázornění plánu operací.	ANO

Možnost vložení fotodokumentace a videodokumentace k operačnímu protokolu a s tím souvisí i možnost vkládat a archivovat videozáznamy z operací (z laparoskopických věží, kamer ve světlech).	ANO
Možnost plánování operací pomocí webového klienta i z míst mimo nemocnici	ANO
Automatické generování objednávky na materiál při vykázání ZUMu	ANO
Možnost statistického zpracování údajů o operaci – pro vedení nemocnice i pro vědecké účely	ANO
Veškeré tiskové výstupy mající formu samostatné části zdravotnické dokumentace musí mít ekvivalentní výstupy ve formě elektronické zdravotnické dokumentace dle platné legislativy.	ANO
Vedení speciální pacientské dokumentace na gynekologicko-porodnickém oddělení
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Vedení porodopisu se všemi potřebnými informacemi. Vedení potřebné dokumentace k vyšetření a hospitalizaci těhotné ženy, popis předporodních vyšetření, porodu, stavu novorozence a matky po porodu	ANO
Možnost jednoduše (přímo z porodopisu) založit novorozence jako pacienta do registru a uložit na novorozeneckou stanici. Přenos potřebných údajů mezi dokumentací rodičky a novorozence s vyloučením duplicit zadávání.	ANO
Možnost svázat dokumentaci rodičky s dokumentací novorozence	ANO
Možnost zadání více novorozenců k rodičce	ANO
Přehledné hlídání povinných údajů v dokumentaci	ANO
Elektronické vykazování potřebných výkazů pro ÚZIS (Zpráva o rodičce, Zpráva o novorozenci, Hlášení vývojové vady) a tisk údajů do formuláře Hlášení o narození	ANO
Xxxxx z porodnické a novorozenecké dokumentace přizpůsobit zvyklostem oddělení	ANO

Přenos porodnické a novorozenecké dokumentace do propouštěcí zprávy	ANO
Veškeré tiskové výstupy mající formu samostatné části zdravotnické dokumentace musí mít ekvivalentní výstupy ve formě elektronické zdravotnické dokumentace dle platné legislativy.	ANO
Rehabilitační péče a plánování procedur
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Ucelené řešení pro fyzioterapie – provázanost lékařské dokumentace, naplánování procedur, zápisů fyzioterapeutů. Umožnit lékaři zadat strukturovaně ordinované procedury s vyznačením pořadí, četnosti, opakování s vazbou pro plánování procedur	ANO
Při plánování procedur:	ANO
● umožnit hromadné objednání, svázání objednávek	ANO
● možnost nastavení standardních skupin procedur	ANO
● kontrola možné četnosti dle metodiky VZP	ANO
● umožnit přihlédnout k přání pacienta, kdy chce procedury absolvovat	ANO
Možnost pracovat s pacientem ambulantním i hospitalizovaným	ANO
Přehledně zobrazovat vytíženost pracovišť, strojů	ANO
Umožnit automatické vykázání potřebných výkonů po odcvičení	ANO
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
Tisk potřebných dokumentů – rozpis pro pacienta, přehled plánovaných pacientů objednaných na dané pracoviště, zdravotní dokumentace – zápisy lékařů, fyzioterapeutů	ANO
Umožnit statisticky sledovat vykázané výkony, resp. platby pacientů	ANO
Jednoduchá správa nastavení: možnost zadání kapacity pracoviště a přístroje, pracovní doby pracoviště, uzavření pracoviště se zdůvodněním uzavření.	ANO
Jednoduché změny v naplánovaných procedurách s evidencí důvodu změny (nemoc pacienta apod.)	ANO

6.4 Požadavky na řešení pro obrazový komplement

Minimální požadavky na řešení pro obrazový komplement jsou definovány v následující tabulce.

Požadavky řešení pro obrazový komplement
Funkcionality potřebné pro radiologická pracoviště – RTG, sonografie, CT, MR, …:
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Podpora činností pro kartotéku, příjem, popisovnu a vyšetřovnu	ANO
Možnost automatického příjmu žádanek z klinických oddělení nebo zápis žádanky na vyšetření přímo na RDG oddělení	ANO
Možnost tvorby strukturované žádanky s označením povinných polí – např. kontraindikace (kardiostimulátor apod.)	ANO
Přizpůsobení pracovní plochy a seznamů dle rolí (laborant, lékař, primář apod.)	ANO
Možnost nastavení automatického sledu činností – aby systém kopírovat práci koncového uživatele	ANO
Archivace snímků	ANO
Automatické proúčtování výkonů a zadaného materiálu	ANO
Použití standardního editoru (RTF) s možností používání předdefinovaných textů	ANO
Odeslání nálezu žadateli	ANO
Objednávkový systém – možnost objednávání pacientů na vyšetření	ANO
Statistiky provedených vyšetření, výkonů, spotřebovaného materiálu apod., možnost exportu dat	ANO
Sledování snímků a expozic	ANO
Vytváření worklistu pro modality v PACSu	ANO
Možnost filtrování worklistů podle priority provedení a popisu vyšetření, možnost vyznačení priority vyšetření indikujícím (i včetně v internetovém objednávkovém systému) i provádějícím lékařem – například režimy STATIM, hospitalizovaný, nebo jiné kategorie	ANO
Možnost vyžadovat potvrzení přijetí (přečtení zhotoveného popisu) indikujícím lékařem v případě urgentních vyšetření, možnost upozornění na zhotovený urgentní popis na pracovní ploše indikujícího lékaře	ANO
Objednávkový systém pro jednotlivé modality s plně grafickým rozhraním formou kalendáře/ diáře, možnost například barevného označení a odlišení čekajících, prováděných a provedených vyšetření, přeobjednávání funkcí drag and drop, fulltextové vyhledávání v objednávkovém systému	ANO
Možnost integrace diktovacího programu pro popisy nálezů	ANO
Automatické otevírání popisovaného snímku na diagnostické stanici	ANO
Při popisu snímků možnost pro radiologa náhledu do klinických dat pacienta	ANO
Možnost nastavit potvrzování nálezů erudovanějším lékařem (druhé čtení)	ANO
Veškeré tiskové výstupy mající formu samostatné části zdravotnické dokumentace musí mít ekvivalentní výstupy ve formě elektronické zdravotnické dokumentace dle platné legislativy.	ANO

6.5 Požadavky na řešení pro stravovací provoz

Minimální požadavky na řešení pro stravovací provoz jsou definovány v následující tabulce.

Požadavky řešení pro stravovací provoz
Funkcionality potřebné pro řešení stravovacího provozu
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Možnost objednávek diet dle údajů ve zdravotnické dokumentaci pacienta – automatizovaná sestava za oddělení/stanici	ANO
Možnost provádět několikrát denně automatizovaný sběr hlášení z oddělení	ANO
Podpora široké škály diet	ANO

6.6 Požadavky na internetové objednávání pacientů s napojením na diáře pracovišť nemocnice

Současný systém objednávání pacientů k ambulantnímu zdravotnímu výkonu nebo k výkonu v rámci hospitalizace je velmi náročný na čas lékařů, zdravotnického personálu i pacientů. Komunikace mezi aktéry probíhá většinou telefonicky a je tudíž podmíněna jejich přítomností na pracovišti zdravotnického zařízení. Při změnách termínu objednávky způsobené zdravotnickým zařízením nebo pacientem pak může nastat obtížná situace, kdy jedna ze stran není dosažitelná, a tudíž není včas informovaná o změně. V důsledku scházejícího efektivního systému objednávání pak dochází zbytečně k nerovnoměrnému zatížení kapacit zdravotnického zařízení, např. při poskytování preventivních vyšetření pacientů.

Cílové skupiny uživatelů Produktu jsou:

• praktičtí lékaři a lékaři specialisté, kteří mohou objednávat své pacienty ke zdravotním výkonům v nemocnici,

• pacienti registrovaní i neregistrovaní, kteří se mohou sami objednávat ke zdravotním výkonům v nemocnici,

• lékaři nemocnice, kteří mohou objednávat pacienty ke zdravotním výkonům v rámci jedné nemocnice nebo i více nemocnic.

Minimální požadavky na internetové objednávání pacientů jsou definovány v následující tabulce.

Požadavky na internetové objednávání pacientů
Funkcionality potřebné pro internetové objednávání
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Určení formy využití objednávkového systému, tj. kdo, co a kdy si může objednat, stanoví v rámci navrhovaného řešení uživatel	ANO
Systém bude nabízet řešení pro objednávání pacientů prostřednictvím internetu pomocí webových služeb se zajištěnou komunikací s navrhovaným informačním systémem	ANO
Výměna dat bude probíhat zabezpečeným způsobem s využitím šifrovacích mechanismů	ANO
Systém bude zabezpečen proti zranitelnosti z internetu	ANO
umožnit vkládat naskenované kopie parere doporučujícího lékaře	ANO
Pacient objednává vyšetření, objednaný termín (datum a čas) se promítá do diáře lékaře na příslušném pracovišti v navrhovaném informačním systému	ANO
● vyhledání požadovaného pracoviště	ANO
● vyhledání volného termínu (datum a čas)	ANO
● vyhotovení objednávky s možností výběru vyšetření, na které se pacient objednává, případně lékaře a s možností doplnění textové poznámky k objednávce	ANO
● odeslání objednávky do diáře v navrhovaném informačním systému	ANO
● potvrzení doručení objednávky do diáře v navrhovaném informačním systému	ANO
● možnost automatického odeslání informačního mailu pacientovi s poučením k objednanému vyšetření	ANO
● upozornění pacienta na blížící se termín objednávky prostřednictvím SMS zprávy případně emailu	ANO
● možnost stornovat objednávku ze strany pracoviště z prostředí navrhovaného informačního systému	ANO
● možnost změny termínu objednávky ze strany pracoviště z prostřední navrhovaného informačního systému	ANO
● upozornění pacienta na změnu termínu nebo storno objednávky ze strany pracoviště zasláním SMS, případně e-mailu	ANO
Komunikace systému s uživatelem (minimálně upozornění, změna termínů) prostřednictvím SMS1 a mailové komunikace 1) Předmětem dodávky není služba SMS operátora. Předmětem dodávky je napojení na službu/rozhraní SMS operátora zajištěného zadavatelem.	ANO
Možnost registrace uživatele a evidence kontaktních, autentizačních a autorizačních údajů opravňující uživatele k funkcím s omezením.	ANO
Podpora vícejazyčnosti webového uživatelského rozhraní	ANO
Uživatelsky příjemné rozhraní – možnost barevně definovat minimálně typy vyšetření, časy.	ANO

6.7 Zavedení elektronické zdravotnické dokumentace (EZD) včetně zavedení počítačově vedené ošetřovatelské dokumentace (EOD)

Cílem zavedení EZD a EOD je v maximální míře odstranit papírovou administrativu, která vzniká sekundárně opisem (tiskem) elektronicky vedených údajů a to pouze jako právní doklad o provedené péči o pacienty.

Implementace EZD a EOD musí zahrnovat vytvoření technologického, aplikačního a procesního prostředí pro možnost vést zdravotnickou a ošetřovatelskou dokumentaci pacientů v čistě elektronické podobě. Řešení musí vycházet z platné legislativy v aktuálním znění – v úvahu přichází zejména tyto předpisy:

• Zákon č. 101/2000 Sb., o ochraně osobních údajů, ve znění pozdějších předpisů

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

• Nařízení Evropského parlamentu a Rady (EU) č. 910/2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES (eIDAS)

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

• Zákon č. 372/2011 Sb., o zdravotních službách

• Vyhláška č. 98/2012 Sb. o zdravotnické dokumentaci

• Zákon č. 499/2008 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů

• Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů

Zavedení EZD a EOD si neklade za cíl odstranit veškeré papírové dokumenty, nýbrž se týká zejména takových dokumentů, které lze označit za samostatnou část zdravotnické dokumentace pacienta a současně je možno ji vést v čistě elektronické podobě. Přesný rozsah dotčených dokumentů zahrnutých do řešení EZD resp. EOD bude popsáno v analýze, jako součásti implementace. Očekávané přínosy jsou zejména tyto:

• úspory v nákladech na tisk, distribuci a archivaci papírové dokumentace

• usnadnění přístupu a částečné automatizace práce se zdravotními záznamy (EHR)

• snížení chybovosti informací odstraněním ručních zápisů

• využití synergie se systémy a procesy eGovernmentu

Na každou entitu vybranou k aplikace EZD (např. ambulantní nález, konziliární zpráva, atd.), budou aplikovány takové požadavky, které zajistí soulad s nároky legislativy z pohledu možnosti vedení zdravotnické dokumentace v čistě elektronické formě. Jsou to zejména:

• Zápis ve zdravotnické dokumentaci musí být veden průkazně, pravdivě a čitelně.

• Zápis ve zdravotnické dokumentaci musí být opatřen datem zápisu, identifikací a podpisem osoby, která zápis provedla.

• Opravy ve zdravotnické dokumentaci se provádí novým zápisem s uvedením dne opravy, identifikací a podpisem osoby, která opravu provedla. Původní záznam musí zůstat čitelný.

• Technické prostředky pro vedení zdravotnické dokumentace v elektronické podobě musí zaručovat:

• a) zabezpečení výpočetní techniky softwarovými a hardwarovými prostředky před přístupem neoprávněných osob ke zdravotnické dokumentaci a

• b) vedení evidence všech přístupů ke zdravotnické dokumentaci včetně jejich oprav, změn a mazání.

• Elektronická dokumentace musí být archivována a skartována v souladu s požadavky uvedenými v příloze č.2 a č.3 vyhlášky č.98/2012 Sb., o zdravotnické dokumentaci.

• Při ukládání do zabezpečeného archivu je nutné zajistit, aby kdykoli v budoucnu mohla být zajištěna právní validita, tj. umožněna autorizovaná konverze libovolného dokumentu

V rámci tohoto záměru se počítá i se zavedením podpory počítačového vedení ošetřovatelské dokumentace.

Minimální požadavky na zavedení EZD jsou definovány v následující tabulce.

Požadavky na zavedení EZD
Funkcionality potřebné pro EZD
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Nástroj pro sestavení dokumentů ve formátu dokumentace PDF/A, podpora řízení životního cyklu zápisů (podepsání, archivace, stav ověření podpisu a časového razítka, storno, skartace).	ANO
Generování a publikování jednoznačného identifikátoru záznamu do EZD.	ANO
Nástroj pro vytvoření kvalifikovaného elektronického podpisu dle zákona splňující příslušnou technickou normu (PAdES), plná integrace s NIS	ANO
Nástroj pro vytvoření elektronického podpisu pacientem dle zákona, plná integrace s NIS	ANO
Automatické vynucení elektronického podepsání uzavíraného zápisu elektronické zdravotnické dokumentace elektronickým podpisem uživatele	ANO
Předávání elektronicky podepsaných dokumentů do elektronického archivu včetně metadat ve formě OAIS SIP pro dlouhodobou archivaci	ANO
Zajištění správy a evidence kvalifikovaných podpisových certifikátů uživatelů a kvalifikovaných prostředků elektronického podepisování.	ANO
Pořízení el. podpisu musí technicky podporovat lokální i terminálové stanice využívající MS RDP přístup (vzdálená plocha) na Microsoft terminálových serverech.	ANO

6.8 Zajištění provozu vizity u lůžka pacienta

Aplikace pro vizitu zcela zásadně zvyšuje klinickou efektivitu a bezpečí pacientů a to především tím, že „přivádí“ potřebná data k lůžku pacienta a umožňuje je elektronicky (dotykově) editovat.

Požadavkem je pořízení aplikace pro dotyková zařízení, jež je plně kompatibilní s NIS, a díky které má lékař při vizitě v rukou přístup k dokumentaci pacienta bez nutnosti listování v papírové dokumentaci. Řešení je vhodné nasadit jak pro akutní oddělení (vč. JIP) tak i pro oddělení následné péče. Data musí být plně strukturována, tak jak je lékař zná z NIS. Při práci s webovým klientem odpadne přepisování zápisů z papírové dokumentace do NIS, čímž se zvyšuje efektivita a eliminuje řada chyb, které mohou při přepisování vznikat.

Řešení bude postaveno jako webová aplikace, a bude tedy plně nezávislé na operačním systému dotykového zařízení, pracuje stejně u zařízení Android i-OS či MS Windows. Jediným předpokladem pro práci je přístup k internetu (nebo intranetu), tedy WiFi, případně i mobilní operátor (LTE …).

Minimální požadavky na provoz vizity u lůžka pacienta jsou definovány v následující tabulce.

Požadavky na provoz vizity u lůžka pacienta
Funkcionality potřebné pro provoz vizity u lůžka pacienta
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Řešení postaveno jako webová aplikace, a tedy plně nezávislé na operačním systému dotykového zařízení, pracuje stejně u zařízení Android i-OS či MS Windows	ANO
Při vizitě u lůžka pacienta bude mít lékař k dispozici minimálně administrativní údaje pacienta, jeho anamnézy, diagnózy, laboratorní výsledky, zprávy z konzilií, operační protokoly, popisy RTG.	ANO
Součástí řešení bude nejen náhled na aktuální medikace a jejich historii, ale i aktivní zadávání či změna ordinovaných léků, včetně infúzí za respektování interakcí	ANO
Všechna data pořízená dotykovým zařízením budou ukládána přímo do dokumentace pacienta a budou tedy okamžitě přístupná pro další personál	ANO
Možnost vložení multimediálního souboru (fotky, krátkého videa, zvukového záznamu) přímo z dotykového zařízení do dokumentace pacienta a to přímo při provádění vizity.	ANO
Bude přístup do aplikace chráněn autentifikací uživatele	ANO
Ověření pacienta pomocí scanu čárového či QR kód čtečkou v mobilním zařízení	ANO

6.9 Elektronická dokumentace v laboratořích a mezilaboratorní komunikace

Vedení elektronické dokumentace bude řešeno i v rámci laboratorního komplementu.

Výsledkové listy bude možné generovat v elektronické podobě ve formátu PDF/A, označovat kvalifikovanou elektronickou pečetí popř. podepisovat kvalifikovaným elektronickým podpisem a dlouhodobě archivovat.

Export výsledků do NIS bude prováděn ve formátu DASTA. Pokud již bude sestaven výsledkový list v PDF/A souboru, bude s výsledky ve formátu DASTA v zaslaném výsledkovém paketu uložen odkaz na elektronický výsledkový list. V opačném případě musí být odkaz na PDF/A soubor vyexportován v DASTA později. Tento odkaz musí umět NIS zpracovat a nabídnout uživateli. Kliknutím na odkaz se výsledkový list musí uživateli zobrazit přímo v NIS nebo ve zvoleném PDF prohlížeči.

V případě potřeby bude možné nastavit odesílání podepsaných elektronických výsledkových listů externím žadatelům a to zabezpečeným způsobem.

Očekávánými přínosy zavedením EZD v porovnání s papírovou dokumentací jsou především:

• Rychlejší a bezpečnější distribuce výsledkových listů (nálezů) žadatelům.

• Úspora nákladů na papír a spotřební materiál pro tisk výsledkových listů.

• Úspora nákladů na distribuci výsledkových listů poštou.

• Rychlejší vyhledávání historických dokumentů laboratoře (žádanky, výsledkové listy, hlavní kniha).

• Úspora nákladů a prostor při archivaci dokumentů laboratoře.

• Podpora zákonem stanoveného skartačního procesu.

Systém musí umožňovat export elektronické žádanky na laboratorní vyšetření kompatibilní se stávajícími laboratorními IS a jimi používanými laboratorními metodami.

Elektronická žádanka musí umožňovat elektronický podpis. Dále musí NIS podporovat tvorbu šablon pro elektronické žádanky.

Minimální požadavky na funkcionalitu jsou definovány v následující tabulce.

Požadavky ne EZD v LIS
Funkcionality pro tvorbu, předávání a archivaci EZD.
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Nový systém zajistí funkcionalitu do LIS, která umožní předávání žádanek na laboratorní vyšetření (nebo jejich částí) do vlastních i smluvních laboratoří. Výsledky vyšetření budou poté vraceny do původní laboratoře. Pro komunikaci bude využíván formát DASTA v4	ANO
NIS bude připraven přijímat a zpracovávat datový soubor DASTA a importovat výsledky do NIS	ANO
Nástroj pro export výsledkových listů ve formě PDF/A.	ANO
Z uživatelského prostředí klienta NIS bude možné vyvolat zobrazení tohoto PDF/A dokumentu	ANO
Nástroj pro vytvoření kvalifikovaného elektronického podpisu/elektronické pečetě dle zákona splňující příslušnou technickou normu (PAdES), plná integrace s LIS.	ANO
Předávání elektronicky podepsaných dokumentů do elektronického archivu včetně metadat ve formě OAIS SIP pro dlouhodobou archivaci	ANO
Elektronická žádanka s možností elektronického podpisu, kompatibilní se stávajícími laboratorními IS a jimi používanými laboratorními metodami.	ANO

6.10 Vedení strukturované ordinace medikace včetně výdeje léků na identifikovaného pacienta

Funkce ordinace je určena pro vedení denních záznamů při hospitalizaci pacienta. Denní záznam je veden do strukturovaného dekurzu, kde lze popisovat aktuální stav pacienta, strukturovaně ordinovat léky a infuze, zadávat pokyny sestře a další informace.

V první fázi budou implementovány strukturované medikace na odděleních. Medikace budou prováděny bez návaznosti na sklad. Zároveň budou implementovány příruční sklady na odděleních včetně propojení na dodavatele centrálního skladu

V další fázi bude rozběhnuta funkcionalita Evidence podání léků (EPL) ve formě hromadného podání (sestra označuje podané léky hromadně a ze skladu se vyskladňují metodou FIFO) nebo on-line evidencí podání léků (sestra označuji podání léku on-line a tyto léty konkrétní šarže se vyskladní z klinického skladu. Tím bude dosaženo spojení lékového řetězce a evidence spotřeby léků na konkrétního pacienta.

Součástí je zároveň modul lékové interakce v českém jazyce, který bude obsahovat všechny v ČR registrované léky a léčivé přípravky dle SÚKL. Databáze nebude vycházet pouze ze SPC (souhrnu údajů o přípravku), ale ze současného stavu poznání dle odborné literatury.

Minimální požadavky na funkcionalitu jsou definovány v následující tabulce.

Vedení strukturované ordinace medikace
Funkcionality pro vedení strukturované ordinace medikace
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Funkce slouží pro zadání léků. U léků je možno evidovat, zda jsou ordinovány nebo už podány, případně jejich vysazení	ANO
Lze pracovat s pozitivním listem	ANO
Ordinované léky se pro větší přehlednost zobrazují na časové ose, a to včetně měřených hodnot (např. TK, teplota apod.)	ANO
Možnost zadání infuzí	ANO
Lze definovat složení infuze a její množství	ANO
Zavedení „komponenty“ pro příruční sklady	ANO
● Tvorba žádanek a jejich vícestupňové schvalování	ANO
● Příjem komodit na sklad oddělení	ANO
● Výdej komodit do spotřeby	ANO
● nástroje pro uzávěrku skladu a inventuru	ANO
● Nástroj pro tvorbu Magistraliter a jejich zařazení do číselníku	ANO
● Možnost vytvoření požadavku na ředírnu cytostatik dle definovaných požadavků.	ANO
Modul lékové interakce: databáze bude v českém jazyce, databáze bude obsahovat všechny v ČR registrované léky a léčivé přípravky dle SÚKL databáze nebude vycházet pouze ze SPC, ale ze současného stavu poznání dle odborné literatury	ANO

6.11 Zvýšení bezpečí pacienta na JIP a ARO přes napojení přístrojů s urgentními daty do informačního systému nemocnice

Systém bude umožňovat monitoring přístrojů (minimálně monitory vitálních funkcí, ventilátory, monitory srdečního výdeje), automatizovaný přenos dat z těchto přístrojů do NIS a záznam anesteziologické dokumentace. Systém je určen pro všechny druhy akutní péče, včetně intenzivní i perioperační péče. Má zásadní význam pro více oblastí – podstatně zvyšuje efektivitu práce sester, omezuje chybovost při shromažďování dat a zvyšuje kvalitu léčby a bezpečí pacientů.

Minimální požadavky na funkcionalitu jsou definovány v následující tabulce.

Zvýšení bezpečí pacienta na JIP a ARO
Funkcionality pro Zvýšení bezpečí pacienta na JIP a ARO
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Systém umožní napojení na systémy monitoringu životních funkcí	ANO
Systém umožní automatizovaný přenos dat z přístrojů do NIS (u přístrojů se známým datovým rozhraním)	ANO
Zobrazení dat z přístrojů na časové ose s možností uživatelsky definovat frekvenci zobrazovaných dat a zobrazené informace (hodnoty automaticky vyčtené z přístrojů i uživatelem zadávané údaje).	ANO

6.12 Konsolidace prohlížečů s možností vzdáleného přístupu a konzultací

Součástí řešení bude zprovoznění certifikovaného DICOM prohlížeče fungujícího na standardním HTML prohlížeči podporujícím WebGL (Internet Explorer, Edge, Chrome, Firefox)

Minimální požadavky na funkcionalitu jsou definovány v následující tabulce.

DICOM prohlížeč
Funkcionality pro DICOM prohlížeč
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
certifikovanDICOM prohlížeč fungující na standardním HTML prohlížeči podporujícím WebGL (Internet Explorer, Edge, Chrome, Firefox)	ANO
možné provozovat také na jakémkoli mobilním zařízení (tabletu či smartphonu)	ANO
Nezávislost na systémové platformě (Windows, Apple iOS, Linux, Android).	ANO
Prohlížeč bude nezávislý na PACS systémech libovolného dodavatele	ANO
Software bude v souladu s platnými legislativními požadavky, klasifikován a certifikován jako zdravotnický prostředek třídy IIB.	ANO

6.13 Zajištění elektronické preskripce prostřednictvím napojení na centrální úložiště SÚKL

Minimální požadavky na funkcionalitu jsou definovány v následující tabulce.

Zajištění elektronické preskripce prostřednictvím napojení na centrální úložiště SÚKL
Funkcionality pro zajištění elektronické preskripce
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Navrhovaný systém bude obsahovat podporu elektronické preskripce v rozsahu podporovaných funkcí a služeb integračního rozhraní systému eRecept (SÚKL) platného v době podání nabídky	ANO
● Odeslání elektronického receptu do centrálního úložiště	ANO
● Změnu elektronického receptu uloženého v centrálním úložišti	ANO
● Zrušení uloženého elektronického receptu v centrálním úložišti	ANO
● Načtení výdejů léčivých přípravků na elektronický recept	ANO
Navrhovaný systém bude obsahovat podporu elektronické preskripce v rozsahu podporovaných funkcí a služeb integračního rozhraní probíhajícího projektu eRecept (SÚKL)	ANO
● Ověření recentní informace o léčivech předepsaných jinými lékaři	ANO
● Ověření, zda si pacient jím předepsaný lék v lékárně vyzvednul	ANO
● Informace o případné záměně léku lékárníkem při výdeji	ANO
● Vyloučení záměny vydávaného LP prostřednictvím unikátního identifikátoru eReceptu v kombinaci s kontrolou, která proběhne uvnitř CÚ	ANO
Zadání elektronického podpisu musí podporovat terminálový provoz na MS RDP (Vzdálená plocha)	ANO

6.14 Automatizace hlášení pro externí subjekty (UZIS, matrika…)

Minimální požadavky na funkcionalitu jsou definovány v následující tabulce.

Automatizace hlášení pro externí subjekty (UZIS, matrika…)
Funkcionality pro hlášení pro externí subjekty (UZIS, matrika…)
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Systém generuje hlášení pro místně příslušný matriční úřad (hlášení narozených/zemřelých)	ANO
možnost generování a elektronického exportu hlášení do registrů NZIS	ANO
schopnost předávat data v podporovaném datovém standardu (DASTA, HL7)	ANO
Odesílání příkazu k transportu zabezpečenou elektronickou komunikací na příslušnou dopravně-zdravotní službu, Komunikace s revizním lékařem (žádosti o zvýšení úhrady, návrhy na léčebně rehabilitační a lázeňskou péči), s lékařem OSSZ (zpětné uznání DPN).	ANO

6.15 Požadavky na procesní řízení

Systém bude podporovat procesní přístup řízení pro cutomizaci NIS na základě specifik subjektu (jedinečné workflow vlastních procesů subjektu) a rovněž pro účely akreditace subjektů (efektivní řízení, kontrola a vyhodnocování procesů).

• Hlavní procesy - diagnostická a léčebná lůžková péče, diagnostická a léčebná, ambulantní péče, ošetřovatelská péče, porodnická péče, služby komplementu, výroba transfuzních přípravků

• Řídící procesy - management zdravotnického zařízení, kvalita a bezpečí péče, řízení dokumentace

• Podpůrné procesy - správa zdravotnických prostředků, řízení léčiv a spotřebního zdravotnického materiálu, nakupování, stravovací provoz, administrace

Minimální požadavky na funkcionalitu jsou definovány v následující tabulce.

Požadavky na procesní řízení
Minimální požadavky na funkcionalitu	Splňuje ANO/NE (Vyplní dodavatel)
Systém umožňuje definici procesů podle skutečných work-flow na zdravotnických pracovištích a umožňuje kontrolu nastaveného procesu v jeho uzlech	ANO

7 POŽADAVKY ZADAVATELE NA ARCHITEKTURY NIS

Navrhovaný projekt implementace jednotného nemocničního informačního systému je motivován dvěma hlavními aspekty: zajištěním přístupu k bezpečné a vysoce kvalitní péči a zvýšením interoperability jednotlivých systémů. Zavedení jednotného NIS také umožní sdílení a výměnu dat mezi organizacemi KHK.

Implementace NIS směřuje k následujícím strategickým cílům:

• zvýšení přístupnosti a dostupnosti informací,

• zvýšení interoperability mezi organizacemi KHK,

• zvýšení efektivity systému a poskytované péče v rámci KHK,

• zvýšení informační a znalostní podpory zdravotních pracovníků a pacientů KHK,

• zvýšení dostupnosti zdravotní péče v KHK,

• zvyšování kvality a bezpečného poskytování zdravotních služeb v KHK,

• zajištění a rozvoj infrastruktury pro sdílení a poskytování zdravotních služeb v KHK a ● zvýšení přeshraniční spolupráce.

Všechny strategické cíle slouží k naplnění nejen koncepce eHealth v KHK, ale také strategie MZČR.

7.1 Efektivita projektu – výkonnostní architektura

Katalog ukazatelů výkonnosti a kvality spojených s projektem

Ukazatel (PI, KPI)	Měřený prvek	Vysvětlení způsobu měření a interpretace ukazatele
Ukazatel účinnosti
Dostupnost služeb	Přístupové rozhraní	Doba odpovědi systému.
Průměrná doba prostojů	Přístupové rozhraní	Jaká je průměrná doba nedostupnosti systému.
Četnost poruch	Helpdesk	Četnost poruch v běžném provozu.
Propustnost	Serverové rozhraní	Jaký je počet souběžných úloh za určitou jednotku času.
Ukazatel účelnosti
Snížení množství papírové dokumentace	Papírová dokumentace	Statistické údaje.
Zkrácení doby hospitalizace pacienta	Doba hospitalizace	Statistické údaje.
Zvýšení spokojenosti pacientů s léčbou	Odezva pacientů	Zpětná vazba pacientů.
Ukazatel úrovně a kvality služeb
Rychlost řešení problémů s nedostupností služeb	Helpdesk	Doba potřebná pro odstranění nedostupnosti služeb NIS.
Dostupnost služeb NIS	Přístupové rozhraní	Měření charakteristik odezvy systému.
Ukazatele spolehlivosti	Helpdesk	MTBF, MTTF, MTTR metriky.

Katalog výsledků, dopadů a multiplikačních efektů politiky, podpořené předloženým projektem

Efekt politiky	Vysvětlení podmínek dosažení efektů a interpretace podílu projektu na jejich dosažení
Elektronické vedení zdravotnické dokumentace místo papírové	Elektronická dokumentace bude preferována před papírovou, což usnadní práci ošetřovatelskému a lékařskému personálu. Dále to povede ke snížení chybovosti z důvodu přepisu informací mezi systémy. Dojde také ke zvýšení bezpečnosti informací evidovaných o pacientech v informačních systémech. Bude v maximální možné míře oddělena identifikace pacienta a údaje o jeho zdravotním stavu. Systém bude umožňovat identifikaci pacienta pomocí bezvýznamového identifikátoru.
Zkrácení doby hospitalizace	Díky jednotnému místu pro přístup k datům dojde ke zrychlení a zpřehlednění v rozhodování o léčbě a tak ke zkrácení hospitalizace.
Zvýšení bezpečnosti péče	Uložení a přístup k datům o pacientech na jednom místě. Eliminace lidského faktoru při přepisování a vypisování zdravotnické dokumentace. Ověření kompetencí personálu oproti profesním registrům (až bude možné napojit).

Vysvětlení výkonnostní architektury projektu

Předkládaný projekt zpřehlední způsob vedení zdravotnické dokumentace a odstraní nadbytečné přepisování informací člověkem a tím sníží chybovost, zvýší bezpečnost poskytované léčby a ošetřovatelský a lékařský personál tak bude mít více času k činnostem, které souvisí s přímou péčí o pacienty. Díky tomu, že všechny údaje o pacientovi budou na jednom místě v přehledné formě, bude i proces rozhodování o další léčbě urychlen a tím pádem se zkrátí doba hospitalizace pacienta.

7.2 Byznys architektura – poskytování veřejných služeb

Katalog organizačních jednotek, aktérů a rolí

Název objektu	Počet uživatelů IS	Vysvětlení významu objektu
Organizace a organizační jednotky
Lékařské organizace	stovky	Generují a čtou informace o pacientech.
Zdravotní pojišťovny	desítky	Získávají statistiky a výkazy o provedené léčbě.
Kraj	desítky	Používá statistické výstupy informačního systému.
Ministerstvo zdravotnictví	desítky	Používá statistické výstupy informačního systému.
Role aktérů
Lékařský personál	desítky	Xxxxxx a získává informace o pacientech.
Management	desítky	Vyhodnocuje statistické výstupy z informačního systému. Sílí data mezi nemocnicemi.
Občan	statisíce	Prohlíží některé statistické informace z informačního systému. Pomocí webového rozhraní IS se může objednat na vybraná zdravotní pracoviště.
Ošetřovatelský personál	stovky	Xxxxxx a získává informace o pacientech.
Pacient	desetitisíce	Prohlíží některé statistické informace. Získává informace v reálném čase.
Externí organizace
Matrika	jednotky	Získává automatizované hlášení z informačního systému.
Nemocnice	desítky	Sdílejí data o pacientech.
OSSZ	jednotky	Elektronická komunikace pro získávání automatizovaných hlášení z informačního systému – e-neschopenka.
SÚKL	jednotky	Elektronická komunikace pro získávání automatizovaných hlášení z informačního systému – e-preskripce.
Zdravotní pojišťovny	desítky	Získává automatizované hlášení z informačního systému.
ZZS	jednotky	Získávají data pro IS ZZS eHealth.
ÚZIS	jednotky	Elektronická komunikace pro získávání automatizovaných hlášení z informačního systému – registry.
ČSÚ	jednotky	Získává automatizované hlášení z informačního systému.
Ministerstvo zdravotnictví	desítky	Získává a používá statistické výstupy z informačního systému
Typy aktérů
Fyzická osoba	miliony	Pacienti a občani.
Právnická osoba	stovky	Externí organizace – Nemocnice, zdravotní pojišťovny, SÚKL, ÚZIS, OSSZ, …
KÚ KHK	jednotky	Management nemocnic.
Nemocnice ZH KHK	desítky	Nemocnice v holdingu.
ZH KHK	jednotky	Management nemocnic.

Katalog funkcí a procesů veřejné správy

Typ prvku	Název objektu	Vysvětlení významu objektu
proces	Diagnostická a léčebná ambulantní péče	Pořizování záznamů o diagnostické a léčebné péči pacienta v průběhu ambulantní péče.
proces	Diagnostická a léčebná lůžková péče	Pořizování záznamů o diagnostické a léčebné péči pacienta v průběhu lůžkové péče.
proces	Hemodialyzační péče	Vedení záznamů o pacientech hemodialýzy včetně záznamů o průběhu hemodialýzy.
proces	Ošetřovatelská péče	Pořizování záznamů při péči o pacienta tzv. u lůžka.
proces	Porodnická péče	Pořizování záznamů vztahujících se k porodnické péči – vzájemná vazba dokumentace rodičky a novorozence.
proces	Služby komplementu	Elektronické podání požadavku a elektronický přenos výsledku formou nálezu vyšetření ze zobrazovacích metod a laboratorních služeb.
proces	Statistiky a registry	Statistické přehledy a výkaznictví spolu s hlášením do registrů.
proces	Stravovací provoz	Kompletní agenda pro zaměstnaneckou a pacientskou stravu. Vedení skladu a tvorba objednávek.
proces	Výkazy ZP	Statistické přehledy a výkaznictví pro potřeby zdravotních pojišťoven.
proces	Řízení dokumentace	Správa dokumentace po celý její životní cyklus.
proces	Řízení kvality a bezpečí	Vedení interního systému hodnocení kvality a bezpečí.
proces	Řízení léčiv a SZM	Vedení pozitivního listu, vedení skladového hospodářství léčiv, sledování preskripce.

Katalog služeb veřejné správy

Název služby	Kdo poskytuje službu	Kdo je příjemce služby		Použité rozhraní
Diagnostická a léčebná ambulantní péče	NIS	Pacient, Ošetřovatelský personál, Lékařský personál		Webový portál, Tenký/tlustý klient
Diagnostická a léčebná lůžková péče	NIS	Pacient, Ošetřovatelský personál, Lékařský personál		Webový portál, Tenký/tlustý klient
Hemodialyzační péče	NIS	Pacient, Ošetřovatelský personál, Lékařský personál		Webový portál, Tenký/tlustý klient
Ošetřovatelská péče	NIS	Pacient, Ošetřovatelský personál, Lékařský personál		Webový portál, Tenký/tlustý klient
Podpůrné služby	NIS	Pacient, Ošetřovatelský personál, Lékařský personál		Webový portál, Tenký/tlustý klient
Porodnická péče	NIS	Pacient, Ošetřovatelský personál, Lékařský personál		Webový portál, Tenký/tlustý klient
Služby komplementu	NIS	Pacient, Ošetřovatelský personál, Lékařský personál		Webový portál, Tenký/tlustý klient
Řídicí služby	NIS	Pacient, Ošetř personál, personál, organizace, Management	ovatelský Lékařský Externí Občan,	Webový portál, Tenký/tlustý klient, Webové služby

Katalog komunikačních rozhraní a kanálů

Rozhraní	Druh rozhraní	Počet uživatelských přístupů ročně	Popis využití rozhraní v projektu
Tenký/tlustý klient	Off-line	stovky	Rozhraní pro přístup do informačního systému využívané Ošetřovatelským a Lékařským personálem a Managementem.
Webové služby	On-line	statisíce	Rozhraní pro přístup k datům informačního systému pro externí organizace.
Webový portál	On-line	statisíce	Rozhraní pro přístup k informacím informačního systému pro všechny uvažované role.

Obrázek 1 Model byznys architektury – procesní pohled

Obrázek 2 Model byznys architektury – pohled využití business rozhraní

Vysvětlení byznys architektury projektu

Uživatele informačního systému lze rozdělit do několika skupin, kde každá ze skupin má jiné očekávání od informačního systému. Interní uživatelé systému, tedy ošetřovatelský a lékařský personál a řídicí orgány, externí organizace (například SÚKL, ÚZIS, ZP, MZ) a občané, ať již jako pacienti nebo uživatelé hledající zdravotnické informace.

Procesní pohled zachycuje prováděné business služby. Uvažované služby jsou následující:

• Diagnostická a léčebná lůžková péče – zajišťuje správu záznamů pořízených při lůžkové péči,

• Diagnostická a léčebná ambulantní péče – zajišťuje správu záznamů pořízených při ambulantní léčbě,

• Ošetřovatelská péče – zajišťuje správu záznamů při ošetřovatelské péči,

• Porodnická péče – zajišťuje správu záznamů v rámci porodnické péče,

• Hemodialyzační péče – zajišťuje správu záznamů v rámci hemodialyzační péče,

• Řídicí služby – zajišťují řízení dokumentace, řízení kvality a bezpečí, vykazování pro zdravotní pojišťovny a statistiky a komunikaci s registry,

• Podpůrné služby – zajišťují řízení léčiv a spotřebního zdravotnického materiálu a agendu stravovacího provozu,

• Služby komplementu – zajišťují správu záznamů ze zobrazovacích a laboratorních metod. Aktéři budou využívat služby:

• Ošetřovatelský personál využívá všechny služby s ohledem na jejich oprávnění a role v NIS,

• Lékařský personál využívá všechny služby s ohledem na jejich oprávnění a role v NIS,

• Pacient využívá všechny služby s omezením jen na informace o pacientovi vedených a veřejné statistiky,

• Občan využívá pouze statistiky a to jen takové, které jsou vedeny jako veřejné,

• Management využívá služeb řídicích procesů s ohledem na jejich oprávnění a role v NIS,

• Externí organizace využívají služeb statistik a registrů v závislosti na oprávnění a roli v NIS.

Druhý model zachycuje využití business rozhraní:

• Všechny služby budou přístupné pomocí tenkého/tlustého klienta a webového portálu.

• Řídicí služby budou navíc dostupné pomocí webových služeb.

7.3 Architektura informačních systémů

Katalog aplikačních komponent a klíčových aplikačních funkcí

Typ prvku	Aplikační prvek	Vysvětlení významu aplikačních komponent, funkcí a služeb
komponent a	Klinický informační systém	Komponenta zahrnuje následující funkcionalitu (nejenom): vedení pacientské administrativy včetně statistik pro provoz zdravotnického zařízení, vyúčtování poskytnuté zdravotní péče různým plátcům, vedení zdravotnické dokumentace v souladu s platnou legislativou v písemné i elektronické podobě, automatizovaný sběr dat z přístrojů, ● hlasové diktování záznamu. Komponenta také zajišťuje komunikaci s ostatními komponentami.
funkce	Administrace systému	Funkce Klinického informačního systému.
funkce	Ambulantní péče	Funkce Klinického informačního systému.
funkce	Gynekologie a porodnická péče	Funkce Klinického informačního systému.
funkce	Intenzivní péče	Funkce Klinického informačního systému.
funkce	Internetové objednávání pacientů	Funkce Klinického informačního systému.
funkce	Kardiologická a kardiochirurgická péče	Funkce Klinického informačního systému.
funkce	Kvalita a bezpečí péče	Funkce Klinického informačního systému.
funkce	Lůžková péče	Funkce Klinického informačního systému.

funkce	Napojení přístrojů s urgentními daty	Funkce Klinického informačního systému.
funkce	Obrazový komplement	Funkce Klinického informačního systému.
funkce	Onkologická péče	Funkce Klinického informačního systému.
funkce	Operační dokumentace	Funkce Klinického informačního systému.
funkce	Ošetřovatelská dokumentace	Funkce Klinického informačního systému.
funkce	Patologie	Funkce Klinického informačního systému.
funkce	Rehabilitace	Funkce Klinického informačního systému.
funkce	Stomatologie	Funkce Klinického informačního systému.
funkce	Stravovací provoz	Funkce Klinického informačního systému.
funkce	Vedení ordinace medikace	Funkce Klinického informačního systému.
funkce	Vykazování ZP	Funkce Klinického informačního systému.
komponent a	Modul Vedení pacientské dokumentace na ambulancích	Modul pro podporu administrativy a organizace práce na ambulanci, pro vedení ambulantní pacientské dokumentace, zajištění nebytných statistik a vyhodnocení základních parametrů ambulance.
funkce	Organizace ambulantního provozu	Funkce Modulu Vedení pacientské dokumentace na ambulancích.
funkce	Podpora administrativy	Funkce Modulu Vedení pacientské dokumentace na ambulancích.
funkce	Přehledy a statistiky ambulance	Funkce Modulu Vedení pacientské dokumentace na ambulancích.
funkce	Vedení lékařské dokumentace	Funkce Modulu Vedení pacientské dokumentace na ambulancích.
komponent a	Modul Řízení přístupu	Modul spravující uživatele informačního systému. Předpokládá se napojení tohoto modulu na služby Active Directory.
komponent a	Modul Vedení pacientské dokumentace na lůžkových odděleních	Modul pro podporu administrativy a organizace práce na lůžkovém oddělení, pro vedení pacientské dokumentace, zajištění nezbytných statistik a vyhodnocení základních parametrů oddělení.
funkce	Organizace lůžkového oddělení	Funkce Modulu Vedení pacientské dokumentace na lůžkových odděleních.
funkce	Přehledy a statistiky	Funkce Modulu Vedení pacientské dokumentace na lůžkových odděleních.
funkce	Rehabilitační péče a plánování procedur	Funkce Modulu Vedení pacientské dokumentace na lůžkových odděleních.
funkce	Vedení gynekologickoporodnické dokumentace	Funkce Modulu Vedení pacientské dokumentace na lůžkových odděleních.
funkce	Vedení hospitalizační dokumentace	Funkce Modulu Vedení pacientské dokumentace na lůžkových odděleních.
funkce	Vedení operační dokumentace	Funkce Modulu Vedení pacientské dokumentace na lůžkových odděleních.
komponent a	Webový server	Komponenta poskytuje ostatním aplikačním komponentám rozhraní webových stránek a webových služeb.
funkce	Rozhraní webových služeb	Funkce Webového serveru.
funkce	Rozhraní webových stránek	Funkce Webového serveru.
komponent a	Modul Logistika léků a zdravotnického materiálu	Modul pro podporu vedení skladových zásob léčiv, zdravotnického a všeobecného materiálu na koncové úrovni u aplikace pacientovi a vedení dokumentace o jeho aplikaci dle aktuálně platné legislativy
funkce	Podání léků a evidence spotřeby	Funkce Modulu Logistika léků a zdravotnického materiálu.
funkce	Sklady léků a zdravotnického materiálu na odděleních	Funkce Modulu Logistika léků a zdravotnického materiálu.
komponent a	Aplikace zajištění provozu vizity u lůžka pacienta	Aplikace pro mobilní dotyková zařízení umožňující lékaři přístup k dokumentaci pacienta při vizitě.
komponent a	Modul Elektronické podepisování	Modul umožňuje opatřovat dokumenty elektronickým podpisem. Modul také umožňuje zpracovávat dokumenty elektronickým podpisem opatřené.
komponent a	Modul Elektronické zdravotnické dokumentace	Modul pro vedení zdravotní dokumentace pacientů v elektronické podobě.

Katalog aplikačních rozhraní

Aplikační rozhraní	Komponenta A – volající	Komponenta B – odpovídající	Vysvětlení obsahu a významu rozhraní aplikačních komponent
Aplikační rozhraní NIS	Tenký/Tlustý klient NIS	NIS	Rozhraní pro komunikaci tenkého/tlustého klienta s NIS, toto rozhraní bude využito pouze v prostředí nemocnic ZHKHK.
Rozhraní webových služeb NIS	Informační systémy externích organizací	NIS	Rozhraní webových služeb využívané aplikacemi externích organizací, které tak mohou získávat informace uložené v NIS.
Webové rozhraní NIS	Webový prohlížeč	NIS	Webové stránky NIS pro přístup k informacím v informačním systému, přístup je řízen dle oprávnění a rolí v systému.
Rozhraní webových	NIS	IS eRecept	Rozhraní NIS pro komunikaci s IS eRecept.
služeb CÚER
Rozhraní webových služeb pro práci s datovými zprávami	NIS	ISDS	Rozhraní pro příjem a odesílání datových zpráv.
Rozhraní webových služeb IS VZP ČR	NIS	IS VZP ČR	Rozhraní pro komunikaci s IS VZP ČR (Informační systém Všeobecné zdravotní pojišťovny České republiky).
Rozhraní webových služeb ISZR	NIS	ISZR	Rozhraní pro komunikaci s ISZR používané pro ztotožnění pacientů oproti ROB. Dále je v NIS využívána identifikace pacienta pomocí bezvýznamového identifikátoru.

Obrázek 4 Modely aplikační architektury – pohled spolupráce aplikací

Vysvětlení aplikační architektury projektu

Aplikační architektura projektu se skládá z těchto základních aplikačních komponent: ● KIS (klinický informační systém) – zajišťuje následující funkcionalitu (nejenom):

o vedení pacientské administrativy včetně statistik pro provoz zdravotnického zařízení, o vyúčtování poskytnuté zdravotní péče různým plátcům, vedení zdravotnické dokumentace v souladu s platnou legislativou v písemné i elektronické podobě, automatizovaný sběr dat z přístrojů, hlasové diktování záznamu a komunikaci s ostatními částmi nemocničního informačního systému.

• Modul Logistika léků a zdravotnického materiálu – modul pro podporu vedení skladových zásob léčiv, zdravotnického a všeobecného materiálu na koncové úrovni u aplikace pacientovi a vedení dokumentace o jeho aplikaci dle aktuálně platné legislativy,

• Modul Vedení pacientské dokumentace na ambulancích – modul pro správu záznamů o pacientech pořízených při ambulantní léčbě,

• Modul Vedení pacientské dokumentace na lůžkových odděleních – modul pro správu záznamů pořízených během pobytu pacienta na lůžkovém oddělení,

• Modul Elektronické zdravotnické dokumentace – modul sloužící k vedení kompletní zdravotnické dokumentace v elektronické podobě,

• Modul Elektronické podepisování – modul sloužící k elektronickému podepisování dokumentů,

• Aplikace Zajištění provozu vizity u lůžka pacienta – webová aplikace, která umožní přístup k datům uloženým v nemocničním informačním systému z mobilních zařízení,

• Modul Řízení přístupu – modul spravující přístupová práva do nemocničního informačního systému, bude propojen se zdravotnickými profesními registry (Registr zdravotnických profesionálů) – relevantní až budou tyto registry přístupné.

• Webový server – webový portál starající se o webová rozhraní nemocničního informačního systému.

V rámci aplikační architektury jsou použita tato aplikační rozhraní:

• Aplikační rozhraní NIS – slouží pro komunikaci mezi tenkým/tlustým klientem a NIS,

• Rozhraní webových služeb NIS – rozhraní je poskytováno NIS a je součástí webového serveru a slouží k předávání dat mezi NIS a externími organizacemi,

• Webové rozhraní NIS – rozhraní je poskytováno NIS a je součástí webového serveru a slouží k přístupu k informacím v NIS pomocí webového prohlížeče a aplikace Zajištění provozu vizity u lůžka pacienta.

7.4 Technologická architektura – vrstva IT technologie (HW a SW)

Katalog technologických komponent a klíčových funkcí nebo služeb

Typ prvku	Technologický prvek	Vysvětlení významu komponent, funkcí a služeb
Primární lokalita
komponenta	Virtuální servery P		Virtuální servery pro běh aplikačních komponent.
služba	Virtualizační služba		Virtualizační služba pomocí nějaké virtualizační platformy.
komponenta	Fyzické servery P		Fyzické servery, na kterých běží virtualizační platforma.
SW	Virtualizační platforma		Virtualizační platforma (např. VMware, Hyper-V)
komponenta	Diskové pole SAN P		Diskové pole v primární lokalitě.
SW	Aplikační server		Aplikační server pro běh aplikačních komponent NIS.
SW	Databázový server		Databázový server pro podporu aplikačních komponent NIS.
Sekundární lokalita
komponenta	Virtuální servery S		Virtuální servery pro běh aplikačních komponent.
služba	Virtualizační služba		Virtualizační služba pomocí nějaké virtualizační platformy.
komponenta	Fyzické servery S		Fyzické servery, na kterých běží virtualizační platforma.
SW	Virtualizační platforma		Virtualizační platforma (např. VMware, Hyper-V)
komponenta	Diskové pole SAN S		Diskové pole v sekundární lokalitě.
SW	Aplikační server		Aplikační server pro běh aplikačních komponent NIS.
SW	Databázový server		Databázový server pro podporu aplikačních komponent NIS.
komponenta	LTO		Archivní páskové úložiště.

Obrázek 5 Modely technologické architektury – pohled struktury IT technologické architektury

Vysvětlení IT technologické architektury projektu

Informační systém bude provozován ve dvou lokalitách, aby byla zajištěna vysoká dostupnost a bezpečnost.

Pro provoz aplikačních komponent bude využita serverová virtualizace. Ta umožní provoz systému v režimu vysoké dostupnosti (HA). Virtualizační platforma bude provozována na fyzických serverech. Virtualizace bude využita i pro disková pole k zajištění vhodného přidělení prostředků jednotlivým aplikačním komponentám. Pro zajištění bezpečnosti uložených dat bude mimo virtualizace použita i technologie RAID.

7.5 Technologická architektura – vrstva komunikační infrastruktury

Katalog infrastrukturních komunikačních komponent, funkcí a klíčových služeb

Typ prvku	Infrastrukturní prvek	Vysvětlení významu infrastrukturních komponent, funkcí a služeb
Primární lokalita
komponenta	SAN switch P1	Síťový switch zprostředkující spojení se sekundární lokalitou pro synchronizaci dat. Síťový switch zprostředkující spojení fyzických serverů a diskového pole.
komponenta	SAN switch P2	Síťový switch zprostředkující spojení se sekundární lokalitou pro synchronizaci dat. Síťový switch zprostředkující spojení fyzických serverů a diskového pole.
komponenta	Switch P1	Switch umožňuje připojení interní sítě k internetu a propojení obou lokalit. Switch umožňuje připojení fyzických serverů do interní sítě.
komponenta	Switch P2	Switch umožňuje připojení interní sítě k internetu a propojení obou lokalit. Switch umožňuje připojení fyzických serverů do interní sítě.
komponenta	Firewall/UTM P	Firewall řídicí datovou komunikaci z/do internetu.
Sekundární lokalita
komponenta	SAN switch S1	Síťový switch zprostředkující spojení se sekundární lokalitou pro synchronizaci dat. Síťový switch zprostředkující spojení fyzických serverů a diskového pole.
komponenta	SAN switch S2	Síťový switch zprostředkující spojení se sekundární lokalitou pro synchronizaci dat. Síťový switch zprostředkující spojení fyzických serverů a diskového pole.
komponenta	Switch S1	Switch umožňuje připojení interní sítě k internetu a propojení obou lokalit. Switch umožňuje připojení fyzických serverů do interní sítě.
komponenta	Switch S2	Switch umožňuje připojení interní sítě k internetu a propojení obou lokalit. Switch umožňuje připojení fyzických serverů do interní sítě.
komponenta	Firewall/UTM S	Firewall řídicí datovou komunikaci z/do internetu.
Ostatní
Síť	Počítačová síť nemocnice	Interní síť nemocnice.
Síť	SAN datové propojení lokalit	SAN Datové spojení pro spojení diskových polí a synchronizaci dat.
Síť	Internet	Veřejná síť Internet, přes kterou budou s NIS komunikovat externí uživatelé a systémy.

Obrázek 6 Modely technologické architektury – pohled struktury komunikační infrastruktury

Vysvětlení architektury komunikační infrastruktury projektu

Informační systém bude provozován ve dvou lokalitách, aby byla zajištěna vysoká dostupnost a bezpečnost.

Fyzické servery a disková pole budou propojeny do interní sítě nemocnice přes switche k zajištění vzájemné komunikace.

Pro propojení diskových polí v jednotlivých lokalitách bude vyhrazeno datové spojení. Datové spojení bude využíváno pro synchronizaci dat v obou datových polích. Datová síť bude připojena k internetu přes Firewall/UTM k zajištění vyšší bezpečnosti.

7.5.1 Bezpečnostní architektura

Katalog pasivní bezpečnostní architektury projektu

Hrozba/riziko	Ohrožený prvek architektury	Důsledky nutnosti ochrany prvku pro návrh architektury projektu
Krádež / manipulace / zneužití dat	Data uložená v informačním systému	Zabezpečit uložení citlivých a důvěrných dat nejen pacientů, ale i informací například o personálu nebo dodavatelích. Zabezpečení pomocí řízení přístupu k datům, použití šifrování a ostatních kryptografických prostředků. Audit logových záznamů. Ochrana koncových zařízení použitím anti-X řešení. Standardní ochrana serverů pomocí firewallů/UTM. Přístup do prostor s fyzickými servery je řízen.
Útoky odmítnutí služby	Aplikační infrastruktura	Identifikace a vyhodnocení podezřelého datového provozu přes firewall.

Katalog aktivní bezpečnostní architektury projektu

Hrozba/riziko	Bezpečnostní prvek architektury	Vysvětlení způsobu zmírnění hrozby/rizika prvkem architektury
Krádež / manipulace / zneužití dat	Data uložená ve dvou lokalitách	Nastaveny postupy pro zálohování dat – pravidelnost, testování záloh. Data uložená ve dvou nezávislých lokalitách – synchronizace dat.
Útoky odmítnutí služby	Firewall/UTM	Definování pravidel na firewallu, zásah administrátora do datového provozu.

Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích

Identifikace, autentizace a autorizace bude řešena pomocí interních mechanismů informačního systému spolu s napojením na služby Active Directory, které jsou již nyní využívány. Kontrola uživatelů systému bude prováděna prostřednictvím ověřování v registru zdravotnických profesionálů (až bude k dispozici).

Vysvětlení bezpečnostní architektury projektu

Bezpečnostní architektura projektu se sestává z následujících prvků:

• Modul Řízení přístupu – řešeno pomocí interních mechanismů informačního systému a napojením informačního systému na služby Active Directory, kompetence uživatelů propojeny s údaji v profesních registrech (relevantní až budou přístupné).

• Logovací aparát – evidence informací o tom, kdo a kdy pracoval s daty uloženými v informačním systému,

Technologická infrastruktura je provozována ve dvou geograficky oddělených lokalitách – zajištění vysoké dostupnosti a bezpečnosti dat. Pro identifikaci pacienta využit bezvýznamový identifikátor.

7.6 Shoda s pravidly

Katalog předpisů a norem

Předpis / právní norma

Ochrana osobních údajů

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

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

Legislativa specifická pro zdravotnická zařízení

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

• Zákon č. 378/2007 Sb. o léčivech, ve znění pozdějších předpisů

• Vyhláška č. 54/2008 Sb., o způsobu předepisování léčivých přípravků, údajích uváděných na lékařském předpisu a o pravidlech používání lékařských předpisů, ve znění pozdějších předpisů

• Vyhláška č. 84/2008 Sb., o správné lékárenské praxi, bližších podmínkách zacházení s léčivy v lékárnách, zdravotnických zařízení a u dalších provozovatelů a zařízení vydávajících léčivé přípravky, ve znění pozdějších předpisů

• Vyhláška č. 62/2015 Sb., o provedení některých ustanovení zákona o zdravotnických prostředcích, ve znění pozdějších předpisů

• Zákon č. 48/1997 Sb., o veřejném zdravotním pojištění, ve znění pozdějších předpisů

• Vyhláška č. 98/2012 Sb., o zdravotnické dokumentaci, ve znění pozdějších předpisů

• Vyhláška č. 373/2016 Sb., předávání údajů do Národního zdravotnického informačního systému, v platném znění

Bezpečnost informací

• Zákon č. 181/2014 Sb., o kybernetické bezpečnosti, ve znění pozdějších předpisů

• Vyhláška č. 316/2014 Sb., o kybernetické bezpečnosti, ve znění pozdějších předpisů

Ostatní

• Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, ve znění pozdějších předpisů

• Zákon č. 499/2004 Sb., o archivnictví a spisové službě, ve znění pozdějších předpisů

Katalog připravované legislativy

Legislativa specifická pro zdravotnická zařízení
Návrh zákona, kterým se mění zákon č. 378/2007 Sb., o léčivech a o změnách některých souvisejících zákonů (zákon o léčivech), ve znění pozdějších předpisů Návrh zákona, kterým se mění zákon č. 95/2004 Sb., o podmínkách získávání a uznávání odborné způsobilosti a specializované způsobilosti k výkonu zdravotnického povolání lékaře, zubního lékaře a farmaceuta, ve znění pozdějších předpisů Návrh zákona, kterým se mění zákon č. 592/1992 Sb., o pojistném na veřejné zdravotní pojištění, ve znění pozdějších předpisů (valorizace platby státu za státní pojištěnce) Návrh zákona, kterým se mění zákon č. 96/2004 Sb., o podmínkách získávání a uznávání způsobilosti k výkonu nelékařských zdravotnických povolání a k výkonu činností souvisejících s poskytováním zdravotní péče a o změně některých souvisejících zákonů (zákon o nelékařských zdravotnických povoláních, ve znění pozdějších předpisů Návrh zákona, kterým se mění zákon č. 285/2002 Sb., o darování, odběrech a transplantacích tkání a orgánů, ve znění pozdějších předpisů Návrh zákona, kterým se mění zákon č. 373/2011 Sb., o specifických zdravotních službách, ve znění pozdějších předpisů Návrh zákona, kterým se mění zákon č. 592/1992 Sb., o pojistném na veřejné zdravotní pojištění, ve znění pozdějších předpisů (valorizace platby státu za státní pojištěnce)
●	Návrh vyhlášky, kterou se mění vyhláška č. 306/2012 Sb., o podmínkách předcházení vzniku a šíření infekčních onemocnění a o hygienických požadavcích na provoz zdravotnických zařízení a ústavů sociální péče, ve znění pozdějších předpisů
●	Návrh vyhlášky, kterou se mění vyhláška č. 102/2012 Sb., o hodnocení kvality a bezpečí lůžkové zdravotní péče, ve znění pozdějších předpisů
●	Návrh vyhlášky, kterou se mění vyhláška č. 187/2009 Sb., o minimálních požadavcích na studijní programy všeobecné lékařství, zubní lékařství, farmacie a na vzdělávací program všeobecné praktické lékařství, ve znění pozdějších předpisů
●	Návrh vyhlášky, kterou se mění vyhláška č. 70/2012 Sb., o preventivních prohlídkách, ve znění pozdějších předpisů
●	Návrh vyhlášky, kterou se mění vyhláška č. 306/2012 Sb., o podmínkách předcházení vzniku a šíření infekčních onemocnění a o hygienických požadavcích na provoz zdravotnických zařízení a ústavů sociální péče, ve znění pozdějších předpisů

7.7 Přehled služeb čtyřvrstvé architektury

Obrázek 7 Model služeb v čtyřvrstvé vizi architektury veřejné správy

Vysvětlení čtyřvrstvé architektury služeb projektu

V rámci projektu jsou uvažováni aktéři: Pacient, Lékařský a Ošetřovatelský personál, Občan, Management a Externí organizace (Zdravotní pojišťovny, Ministerstvo zdravotnictví, SÚKL a jiné). Těmto aktérů jsou k dispozici tyto služby (dle úrovně jejich autorizace):

• Diagnostická a léčebná lůžková a ambulantní péče – slouží ke správě záznamů, které jsou vytvářeny v průběhu lůžkové respektive ambulantní péče,

• Ošetřovatelská, Porodnická a Hemodialyzační péče – vedení a pořizování záznamů při ošetřovatelské respektive porodnické a hemodialyzační péči, Služby komplementu - slouží ke správě záznamů ze zobrazovacích metod a laboratorních služeb,

• Řídicí služby – umožňují vést data o chodu nemocnice a tato data nabízet dle oprávnění dalším subjektům,

• Podpůrné služby – slouží k řízení léčiv a SZM a stravovacího provozu.

Služby budou realizovány náležitými procesy, které jsou podporovány jednotlivými aplikačními komponentami.

Pro zajištění vysoké dostupnosti a bezpečnosti celého řešení bude řešení provozováno ve dvou oddělených lokalitách.

Pro běh aplikačních komponent bude využito virtualizační platformy, aby byla zajištěna vysoká dostupnost a také vhodné přidělení potřebných výpočetních zdrojů. Virtuální vrstva bude vytvořena nad fyzickými servery a diskovými poli.

Disková pole jsou uvažována jako SAN, bude tedy vytvořena SAN síť, která bude napojena na datovou síť v lokalitě. Datová centra budou propojeny vyhrazenou SAN datovou sítí pro zajištění bezproblémové synchronizace dat.

Připojení celé infrastruktury do sítě internet je provedeno přes Firewall/UTM k zajištění vyšší bezpečnosti a omezení hrozeb přicházejících z této sítě.

7.8 Architektura navrhovaného řešení v kontextu strategické architektury organizace a navazujících subjektů veřejné správy

7.8.1 Pozice řešení v byznys architektuře organizace

Diagram byznys architektury – hledisko funkcí veřejné správy (Mapa)

Vysvětlení architektury projektu v kontextu byznys architektury úřadu

Organizace májí své procesy dokumentované, jelikož jsou akreditovány nebo v přípravě na akreditaci. Procesy jsou popsány v takové formě, že je z nich patrné, co je jejich vstupem a výstupem a kdo je zainteresován v těchto procesech.

V rámci projektu NIS nedochází ke změně žádných procesů organizace. Navrhovaný informační systém NIS však výrazně zjednodušuje a zpřehledňuje všechny dotčené procesy. Nové řešení také významně zvyšuje bezpečnost prováděných procesů.

Prohlášení o jedinečnosti zaváděné byznys architektury

Připravovaná změna řešení neopomenula žádnou příležitost ke sdílení obdobné služby v úřadu, resortu a nezakládá žádnou více násobnost (multiplicitu) komponent nebo služeb v architektuře úřadu, resortu.

7.8.2 Pozice řešení v architektuře informačních systémů organizace

Obrázek 8 Diagram aplikační architektury IS – pohled portfolia aplikačních komponent a funkcí (Mapa)

Vysvětlení architektury projektu v kontextu aplikační architektury organizace

Na diagramu výše jsou zachyceny aplikační komponenty organizace, které komunikují nebo souvisí s řešením NIS. Navrhované řešení NIS bude spolupracovat s následujícími informačními systémy organizace:

• MIS – získává souhrnná data o provedené léčbě,

• LIS – poskytuje data o laboratorních službách,

• RIS – poskytuje data o radiologických službách,

• ERP – získává data o vytíženosti oddělení,

• Nefrologický IS – poskytuje data o hemodialyzačních službách, ● IS lékáren – získává a poskytuje data o lécích.

Oranžová komponenta je předmětem navrhovaného řešení. Azurové komponenty jsou aplikace, u kterých se neočekává změna.

Prohlášení o jedinečnosti zaváděné aplikační architektury IS

Připravovaná změna řešení neopomenula žádnou příležitost ke sdílení obdobné služby v úřadu, resortu a nezakládá žádnou více násobnost (multiplicitu) komponent nebo služeb v architektuře úřadu, resortu.

7.8.3 Pozice řešení v IT technologické architektuře úřadu

Obrázek 9 Diagram technologické architektury – hledisko portfolia IT technologických komponent a funkcí (Mapa)

Obrázek 10 Diagram technologické architektury – tzv. infrastrukturní hledisko IT technologií

Vysvětlení architektury projektu v kontextu IT technologické architektury organizace

Diagramy zachycují současnou technologickou architekturu organizací (mezi jednotlivými nemocnicemi se architektura liší jen v drobných ohledech). Organizace již využívají dvě lokality (mimo jediné organizace) – primární a sekundární. Diagramy zachycují pouze primární lokalitu – sekundární je analogická. Obě lokality jsou propojeny. U části fyzických serverů je již využívána virtualizace. Předkládaný projekt je plánován plně pro běh na virtuálních strojích, které budou provozovány na již používaných technologiích – VMware a/nebo Hyper-V.

Prohlášení o jedinečnosti zaváděné aplikační architektury IS

Navrhované řešení zavádí duplicitní technologické komponenty (dvě geograficky oddělené lokality), ale tato duplicita je však záměrná a to z důvodu zvýšení kybernetické bezpečnosti celého řešení. V případech, kdy to bude možné, budou využity současné hardwarové prostředky.

1.1.1 Pozice řešení v komunikační infrastruktuře úřadu

Obrázek 11 Diagram technologické architektury – pohled portfolia infrastrukturních komunikačních komponent a funkcí (Mapa)

Obrázek 12 Diagram technologické architektury – tzv. infrastrukturní pohled komunikační infrastruktury

Vysvětlení architektury projektu v kontextu IT technologické architektury organizace

Diagramy zachycují současnou komunikační architekturu organizací (mezi jednotlivými nemocnicemi se architektura liší jen v drobných ohledech). Organizace již využívají dvě lokality (mimo jediné organizace) – primární a sekundární. Diagramy zachycují pouze primární lokalitu - sekundární je analogická (firewall pro připojení k internetu je pouze v primární). Obě lokality jsou propojeny.

Prohlášení o jedinečnosti zaváděné aplikační architektury IS

Navrhované řešení zavádí duplicitní komunikační komponenty (redundantní switche), ale tato duplicita je však záměrná, a to z důvodu zvýšení kybernetické bezpečnosti celého řešení.

7.9 Způsob využití sdílených prvků architektury úřadu a eGovernmentu

Využití sdílených služeb veřejné správy

Název	Popis	Použito
RPP	Procesy jsou definovány dle agend v souladu s jejich registrací v RPP	Ne
Identifikace, autentizace	Identifikace osob vstupujících do procesu je řešena v souladu s JIP/XXXX a Národním identitním schématem	Pro identifikaci a subjektů/uživatelů, připraven pro	autentizaci bude NIS komunikaci
		s národním schématem.	identitním

Navržené řešení nevyužívá ve své architektuře sdílené služby veřejné správy. Elektronická identita a výše uvedené nástroje se zatím neplánují. Je nutné provést analýzu ve spolupráci s dodavatelem řešení projektu. Nicméně v budoucnu možnost využití elektronického občanského průkazu nevylučujeme.

Využití sdílených aplikačních služeb veřejné správy

Název	Popis	Použito
ISZR	Pro správu kmenových (referenčních) dat jsou implementovány služby základních registrů	Ano. Použito pro získání AIFO z ROB.*
eGSB	Pro integraci na propojený datový fond jsou implementovány služby eGSB	Ne, navržené řešení však bude umožňovat napojení pomocí rezortní sběrnice.
PVS	Přístup občanů k el. službám úřadu je využita navigace v Portálu veřejné správy	Ano. Bude poskytnut krátký popis služeb a odkázání na webový portál, kde budou tyto služby dostupné.
ISDS	Napojení na Informační systém datových schránek pro off-line podání	Ano Využíváno pro odesílání a příjem datových zpráv.

*Zajištění napojení bude provedeno dle současných technologických možností, tedy úřednickým postupem pomocí datové zprávy. Online ztotožnění s ROB prostřednictvím AIS závisí na ohlašovateli agendy Ministerstvu zdravotnictví České republiky. Navržené řešení však bude umožňovat napojení pomocí rezortní sběrnice.

Navržené řešení využívá ve své architektuře relevantní sdílené aplikační služby veřejné správy. Navrhované řešení bude počítat i se zajištěním kompatibility s eGSB, aby se systém v případě potřeby výměny dat mezi institucemi dal na eGSB připojit.

Využití sdílené technologické infrastruktury

Název	Popis	Použito
NDC	Umístění technologií do Národních datových center CMS	Ne
DC eGOV	Využití centrálních prvků provozního a bezpečnostního monitoringu	Ne

Technologie budou umístěny ve vlastních datových centrech.

Navržené řešení nevyužívá ve své architektuře sdílenou technologickou infrastrukturu.

Využití sdílené komunikační infrastruktury

Název	Popis	Použito
CMS	Pro publikaci a přístup k vytvářeným službám je využito Centrální místo služeb – aplikace jsou publikovány prostřednictvím CMS	Ano.
KIVS	Využití komunikační infrastruktury veřejné správy, tj. fyzického propojení infrastruktury úřadů	Ano.

Navržené řešení nevyužívá ve své architektuře sdílenou komunikační infrastrukturu.

Propojení jednotlivých nemocnic a krajského úřadu bude provedeno pomocí KIVS.

Mimo výše uvedené bude řešení využívat následující sdílené služby veřejné správy:

• IS VZP ČR

• IS SÚKL o RLPO – registr pro léčebné přípravky s omezením o CDNU – centrální databáze nežádoucích účinků o CÚER – centrální úložiště elektronických receptů

• Registry ÚZIS o Národní onkologický registr o Národní registr hospitalizovaných o Národní registr reprodukčního zdraví

• Národní registr kardiovaskulárních operací a intervencí o Národní registr kloubních náhrad o Národní registr nemocí z povolání o Národní registr léčby uživatelů drog o Národní registr úrazů

• Národní registr osob trvale vyloučených z dárcovství krve

• Národní registr pitev a toxikologických vyšetření prováděných na oddělení soudního lékařství

• RZPRO – registr zdravotnických prostředků

• IS ČSSZ

• RUIAN - registr územní identifikace, adres a nemovitostí

7.10 Přehled nahrazovaných procesů a technologických prvků a začlenění navrhovaného řešení do stávajícího prostředí úřadu a eGovernmentu

Pro navrhované řešení jsou relevantní pouze architektonický vzory eGovernmentu pro datové schránky a základní registry. Datové schránky budou využívány jako komunikační kanál pro příjem a odesílání datových zpráv. Základní registry pro ztotožnění pacientů.

Obrázek 13 Diagram aplikační architektury – hledisko spolupráce aplikací

8 POŽADAVKY ZADAVATELE NA NAPLNĚNÍ CÍLŮ A INDIKÁTORŮ PROJEKTU

Toto zadávací řízení zadavatel realizuje v rámci projektu s názvem „Nemocniční informační systém Královéhradeckého kraje“ v rámci 26. výzvy Integrovaného regionálního operačního programu. V rámci dotačního projektu se zadavatel zavázal pořídit informační systém, který bude splňovat funkcionality (indikátory) definované podmínkami výzvy, jež jsou uvedeny v tabulce v následující podkapitole.

8.1 Požadavek na doplnění tabulky indikátorů

Zadavatel požaduje po dodavateli doplnění následující tabulky, ve které specifikuje, které moduly nabízeného informačního systému a jakým způsobem naplňují požadované funkcionality, které jsou indikátory výsledku dotačního projektu.

Indikátory výstupu projektu

Indikátor (funkcionalita č.1) - Samoobslužný proces veřejné správy

Dílčí funkcionalita	Který modul a jakým způsobem naplňuje danou funkcionalitu (doplní dodavatel)
Umožnění bezpečného sdílení informací o poskytnuté zdravotní péči formou zabezpečeného přenosu informací mezi vybranými poskytovateli zdravotní péče v regionu	Komunikace prostřednictvím modulu ISAC a adaptéru AMIS*HD. Bude proveden upgrade ISAC. Komunikace běží pod zabezpečeným protokolem https prostřednictvím restové komunikace).
Zajištění elektronické preskripce prostřednictvím centrálního úložiště SÚKL	AMIS*HD recepty, přímou komunikací se SÚKL
Archiv pro bezpečné ukládání zdravotnické dokumentace.	Produkt ICZ AZD pro bezpečné dlouhodobé ukládání ZD (opatření dokumentů z KIS časovými razítky a bezpečné uložení dle požadavků platné legislativy).
Informační a popularizační program uživatelů elektronického zdravotnictví	Produkt ICZ eHSB portal. Portálové řešení pro seznámení uživatelů s eHealth a řadou dalších služeb.
Podpora standardizace zdravotnické dokumentace a terapeutických postupů	AMIS*HD, všechny moduly. Pomocí zavádění procesů, standardů a šablon v rámci NIS AMIS*HD.
Indikátor (funkcionalita č.2) - Integrace datového fondu orgánu veřejné moci (OVM) a jeho propojení s dalšími orgány, aby bylo možné data sdílet a využívat i v jiných IS veřejné správy
Dílčí funkcionalita	Který modul a jakým způsobem naplňuje danou funkcionalitu (doplní dodavatel)
Poskytování jednotně definovaných relevantních dat zřizovateli pro zpracování v datovém skladu s možností komparace nákladů a zvyšování efektivity poskytované zdravotní péče	Funkcionalita v rámci AMIS*HD. Parametrizovatelné exporty dat ve formě a s obsahem vyhovujícím zřizovateli.
Podpora přijímání a užívání standardů se zaměřením na automatizaci hlášení pro národní autority (UZIS, ČSÚ,…)	Funkcionalita v rámci AMIS*HD. Parametrizovatelný export dat ve formě vyhovující příjemci dat (ÚZIS, ČSÚ, ….).
Sledování nákladů, vytížení a zvýšení efektivity systému poskytovaných zdravotních služeb	Modul AMIS*HD Pojišťovna. Tento modul zajišťuje sledování nákladů (léky, zdravotnický materiál, …) a výkonů poskytované zdravotní péče. Modul umožní export dat do MIS dle požadovaného rozhraní.
Indikátor (funkcionalita č.3) - Interoperabilita na území státu s přesahem v rámci EU

Dílčí funkcionalita	Který modul a jakým způsobem naplňuje danou funkcionalitu (doplní dodavatel)
Spolupráce v rámci EU (Polsko) výměna zdravotnických informací se ZZS	Komunikace prostřednictvím modulu ISAC a adaptéru AMIS*HD. Bude proveden upgrade ISAC. Komunikace běží pod zabezpečeným protokolem https prostřednictvím restové komunikace). Variantně dle standardu Emergency Card nebo dle eropského standardu – definice Patient Summary, definované dle směrnice Evropské komise.
Spolupráce v rámci EU (Polsko) - poskytovaní informací o volných kapacitách v plánovaných zákrocích pro polské pacienty a možnosti jejich využití	Informace tohoto charakteru budou součástí veřejného portálu zadavatele, který je součástí dodávky. Zveřejněním informací na portále.
Podpora a vzdělávání poskytovatelů zdravotních služeb a jejich pracovníků v oblasti elektronizace zdravotních služeb	Tyto služby budou součásti portálu zadavetele formou e-learningových kurzů určených pro jednotlivé skupiny a specializace pracovníků. Redakční systém umožňující zveřejnění elearningových kurzů na portále zadavatele.
Indikátor (funkcionalita č.4) - Zajištění provozní spolehlivosti a bezpečnosti
Dílčí funkcionalita	Který modul a jakým způsobem naplňuje danou funkcionalitu (doplní dodavatel)
Vznik (bezpečné) infrastruktury pro provoz IS včetně umožnění výměny zdravotnických informací na regionální a národní úrovni a infrastruktury služeb elektronického zdravotnictví	Zabezpečení infrastruktury je řešeno komplexní dodávkou všech částí systému a použitím zabezpečené komunikace mezi jeho částmi (https, ssh). Na úrovni komunikace mezi organizacemi zajišťuje bezpečnost modul ISAC.
Autorizace, autentizace a řízení oprávnění poskytovatelů a jednotlivých uživatelů	Zajištěno v Amis*HD i všech dalších částech dodávky, podpora pro přihlašování přes AD.
Řízení souhlasů a přístupů pro definované externí subjekty. Identity management pro řízení přístupu	Zajištěno v Amis*HD i všech dalších částech dodávky, podpora pro přihlašování přes AD. Podpora key shield SSO (vlastní key shield SSO není součástí dodávky).
Indikátor (funkcionalita č.5) - Dostupnost služeb veřejné správy
Dílčí funkcionalita	Který modul a jakým způsobem naplňuje danou funkcionalitu (doplní dodavatel)
Přehled o poskytovatelích zdravotních služeb včetně poskytování informací o zdravotní péči pacientům formou webového portálu, a to minimálně o dostupnosti zdravotní péče a volných kapacitách pro plánované zdravotní výkony	Informace tohoto charakteru budou součástí veřejného portálu zadavatele, který je součástí dodávky. Zveřejněním informací na portále.
Vzdálené elektronické objednávání pacientů na vybraná zdravotnická pracoviště a upozorňování na plánované výkony	Objednávání pacientů AMIS*HD, webová aplikace.
Optimalizace a správa čekacích dob na plánované zákroky formou aktualizace a zveřejňování volných kapacit poskytovatelů s možností el. objednávání (volné kapacity a časová dostupnost pro plánované chirurgické a ortopedické výkony, preventivní péči, následnou péči…)	Optimalizace a správa čekacích dob na plánované zákroky jsou součástí funkcionality nově dodávaného webového portálu. Tento portál umožní také el. objednávání pacientů na tyto zákroky, přičemž zohlední volné kapacity pro definované typy výkonů a pracovišť.

9 POŽADAVKY ZADAVATELE NA POSTUP IMPLEMENTACE

Zadavatel požaduje zajištění kontinuity provozu zdravotnických zařízení. Po stránce nepřetržitého provozu předpokládá pouze plánovanou odstávku pouze na nezbytnou dobu.

Dále požaduje kontinuitu nastavených parametrů, všech číselníků, definic, tiskových sestav, definice organizační struktury a jiných aspektů provozu. Nepředpokládá investici do opětovného zadávání a pořizování těchto údajů.

Systém musí podporovat procesy hlavní, vedlejší i podpůrné.

Realizace díla bude zahájena po podpisu realizační smlouvy analýzou a zpracováním projektu, který se stane výchozím dokumentem pro realizaci díla. Zaškolení správců na úrovni úprav systému (procesy, customizace). Školení správců na úrovni stáží na pracovištích je součástí dodávky a implementace systému. Je požadováno mít zajištěné testovací prostředí!

Zadavatel si vyhrazuje právo v souladu se servisní smlouvou oslovit dodavatele s požadavkem na realizaci zaškolení uživatelů systému ve smyslu článku 3 odst. 2 servisní smlouvy. Realizace školení uživatelů systému je vyhrazenou změnou závazku ve smyslu § 100 odst. 3 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů. Školení bude realizováno v místě plnění, lektorem(y), v celkovém rozsahu 8 hodin pro jednoho uživatele pro maximální počet 2950 uživatelů. Objednatel není povinen využít možnosti poskytnutí nových služeb.

Dále je v rámci implementace systému vyžadována trvalá přítomnost pracovníků technické podpory v pracovní době a dostupnost mimo pracovní dobu min. měsíc od začátku implementace.

9.1 Analýza aplikačního prostředí

Proces implementace systému bude řízen dle mezinárodních metodik projektové řízení implementovaných do interních metodik dodavatele. Konkrétní aplikované techniky a pravidla řízení projektu dodavatel popíše v akceptovaném Prováděcím plánu projektu.

Analýza prostředí bude zahájena neprodleně v termínu stanoveném Rámcovým harmonogramem z platné realizační smlouvy. Analýza naváže a doplní zjištění předložená Zadavatelem v rámci zadávacího řízení.

Před zahájením analýzy bude schváleno řízení a organizace projektu, sestavena komunikační matice a vytvořen základní registr rizik. Stanovit strukturu analýzy / návrhu řešení je v kompetenci dodavatele.

Dodavatel provede analýzu samostatně a postupně po jednotlivých zdravotnických zařízeních Zadavatele. Požadovaná součinnost Zadavatele v rámci analýzy bude dodavatelem předána před zahájením samostatné analýzy.

Dodavatel v rámci analýzy a tvorby návrhu řešení projektu bude respektovat požadavky zadávací dokumentace s cílením na unifikaci implementace a parametrizace dodávaného řešení (NIS) v rámci všech nemocnic Zadavatele.

Návrh řešení vyplývající z uskutečněné analýzy bude ukotven a schválen v rámci Prováděcího plánu projektu.

Z návrhu řešení bude zřejmý detailní popis cílového stavu, příprava, implementace, parametrizace, dodávka a instalace řešení. Převedení díla do testovacího a produkčního prostředí, soupis akceptačních testů včetně vytvoření projektové dokumentace.

9.2 Tvorba prováděcího plánu projektu

Prováděcí plán projektu zrekapituluje a bude minimálně obsahovat:

−	Základní ustanovení
−	Cíle projektu
−	Rozsah a průběh projektu
−	Časový přehled projektu
−	Akceptace
−	Řízení a organizace projektu
−	Řízení rizik
−	Řízení změn
−	Řízení kvality
−	Ostatní včetně požadovaných příloh

Prováděcí plán projektu bude pokrývat všechny fáze životního cyklu projektu, přechod mezi fázemi i upravovat výstupy projektu. Prováděcí plán projektu odsouhlasený ze strany zadavatele bude projektový tým respektovat a udržovat jej aktuální vzhledem k potřebám plnění dodávky díla, a to dohodu obou stran.

9.3 Vytvoření testovacího prostředí

Pro potřebu školení uživatelů na nové vlastnosti IS a testování nově nasazovaných verzí IS je nutné zajistit vytvoření testovacího prostředí.

9.3.1 Migrace testovacích aplikací

Bude zajištěna úvodní migrace dat i potřebných služeb pro testování IS.

Testovací prostředí zajišťuje pravidelnou aktualizaci dat, aby bylo možné v něm provozovat stejná data jako v produkčním prostředí.

V rámci instalace nových verzí IS bude zajištěna možnost pravidelně upgradovat provozovaná data a aplikace.

9.4 Vytvoření produkčního prostředí a integrace s prostředím

Produkční prostředí umožňuje provozovat všechny IS včetně komunikace mezi nimi včetně podpůrných služeb jako například logování, zálohování a monitoring.

9.4.1 Migrace produkčních aplikací

Dodavatel zajistí migraci dat i potřebných služeb pro provoz IS.

V rámci instalace nových verzí IS je zajištěna možnost pravidelně upgradovat provozovaná data a aplikace.

9.4.2 Zátěžové a akceptační testy

Pro akceptaci díla budou vedle naplnění povinných funkčních požadavků potřebné testy vlastní technologické infrastruktury.

Typy testů uvede dodavatel v odsouhlaseném Prováděcím plánu projektu.

Dodavatel je povinen připravit podklady pro akceptaci dodaného řešení. Součástí akceptace bude předávací protokol včetně řádné předávací dokumentace.

9.5 Tvorba dokumentace

Dodavatel v rámci plnění zajistí zpracování dokumentace skutečného provedení, systémové a provozní dokumentace související s předmětem plnění ve schváleném v Prováděcím plánu projektu. Minimální rozsah zpracované dokumentace:

1. Uživatelská dokumentace

2. Dokumentace skutečného provedení a systémová dokumentace

3. Plán zálohování a obnovy

4. Projektová dokumentace

Dokumenty budou zpracovány elektronicky a uloženy ve formátech MS Office, MS Project, Portable Document Format (formát.pdf).

9.6 Školení správců (administrátorů)

Dodavatel předloží návrh četnosti, formy a obsahu školení pracovníků v dostatečném detailu pro porozumění dodávaného díla.

Poskytnuté informace zajistí seznámení pracovníků se všemi podstatnými částmi díla v rozsahu definovaném v návrhu řešení (prováděcím plánu projektu).

Školení bude probíhat v prostorách a s vybavením zajištěným Zadavatelem. Konkrétní termíny budou upřesněny postupem činností dle termínů v Realizačním Harmonogramu.

V rámci implementace bude provedeno vstupní školení administrace systému v nutném rozsahu. Budou se ho účastnit administrátoři systému ze všech nemocnic a správci ICT infrastruktury.

Po nasazení každé funkčně odlišné verze dodávaného IS provede dodavatel rozdílové školení administrátorů. Požadované školení bude realizované v místě Zadavatele (konkrétní nemocnice). Školení bude provádět školitel dodavatele zapojený do implementace v dotčené nemocnici - znalý místní problematiky.

10 POŽADAVKY ZADAVATELE NA MAINTENANCE

Podpora bude zajištěna na základě smluvních vztahů s dodavatelem řešení včetně dohody o úrovni služeb (SLA). Předpokládá se dlouhodobé využití projektu, kdy jeho funkčnost a stabilita bude zajišťována jednak interními zaměstnanci tak i externími dodavateli.

10.1 Stanovení úrovně dodávky služeb realizovaných projektem s dodržením minimálních požadovaných standardů

• Služba zajištění přístupu v rozsahu 24x7 k telefonické lince HotLine pro nahlášení a řešení kritických problémů v provozu NIS

• Služba zajištění dostupnosti uživatelské podpory pro koncové uživatele NIS

• Služba zajištění přístupu v rozsahu 24x7 k aplikaci HelpDesk pro evidenci a sledování řešení požadavků Zadavatele na provoz a údržbu NIS

• Služba preventivních prohlídek provozu NIS minimálně 4x ročně pro každou lokalitu o Náchod

• Trutnov

• Dvůr Králové nad Labem o Jičín

Preventivní prohlídky budou zaměřeny na periodickou kontrolu systémové a provozní části NIS včetně databáze a databázového prostředí. Rozsah parametrů navrhne Účastník na základě svých zkušeností a dle dnešních technologických standardů v této oblasti.

Vzdálený monitoring databázového a aplikačního serveru dodavatelem z důvodu proaktivního zachycení poruch

● Služba konzultační návštěvy - konzultační služby poskytované uživatelům NIS v místě provozu NIS dle lokalit:

o Náchod 12 návštěv ročně o Trutnov 6 návštěv ročně o Dvůr Králové nad Labem 4 návštěvy ročně o Jičín 6 návštěv ročně

Konzultační návštěva bude realizována v rozsahu minimálně 6 hodin a zahrnuje náklady na cestovné a vypracování zápisu, zprávy z návštěvy.

• Poskytování služeb se prioritně předpokládá vzdáleným způsobem prostřednictvím vzdálené správy se zabezpečeným přístupem dodavatele

• 24x7 – parametr nepřetržitého rozsahu času 24 hodin denně, po dobu 7 dní v týdnu

Projekt má vliv na všechny parametry úrovně služby, jelikož implementuje nové řešení, které bude využívat moderních technologií, kterými jsou například plná virtualizace jak výpočetního výkonu, tak i diskových polí. Je uvažováno, že řešení bude provozováno v režimu vysoké dostupnosti (HA).

Uvažované úrovně dodávky služeb jsou stejné jak pro uživatelská rozhraní, tak i pro komunikační rozhraní ostatních informačních systémů.

Příloha č. 2 Vymezení rozsahu a cen servisní podpory

Technická podpora a servis bude poskytována na část díla dle smlouvy uzavřené dne 28. 8. 2019 mezi poskytovatelem a Královéhradeckým krajem, IČO 708 89 546, se sídlem Pivovarské náměstí 1245, Hradec Králové, na základě výsledku zadávacího řízení veřejné zakázky, které bylo ve smyslu této Smlouvy předmětem implementace u objednatele.

Rozsah technické a servisní podpory

1. Průběžné provádění inovace produktu, jeho jednotlivých technologických částí a příslušného software, zejména update a legislativního update, upgrade a legislativního upgrade.

2. Pod pojmem update se rozumí taková verze produktu, u které se oproti předcházející verzi produktu mění jeho funkčnost, a to na základě změny jakékoliv skutečnosti, podle které byla celá funkčnost tohoto produktu vytvořena, ale nemění se struktura dat datového fondu, se kterým tato verze produktu pracuje. V případě, že změna funkčnosti tohoto produktu byla provedena pouze na základě legislativních změn, je nová verze tohoto produktu jeho “legislativním updatem”.

3. Pod pojmem upgrade se rozumí taková verze produktu, u které se oproti předcházející verzi tohoto produktu mění jeho funkčnost, a to na základě změny jakékoliv skutečnosti, podle které byla celá funkčnost produktu vytvořena, a zároveň se mění struktura vět datového fondu, se kterým tato verze produktu pracuje. V případě, že změna funkčnosti tohoto produktu a změna struktury dat datového fondu, se kterým tento produkt pracuje, byla provedena pouze na základě legislativních změn, je nová verze tohoto produktu jeho “legislativním upgradem”.

4. Poskytování update a upgrade produktu, vzniklé legislativními změnami a požadavky objednatele či samostatnou, nevynucenou, inovační činností poskytovatele.

5. Provádění obecných změn produktu v důsledku vývoje HW a SW prostředků.

6. Distribuce nových verzí produktu a bezpečnostních a funkčních oprav (patchů) včetně aktuální dokumentace a popisu změn zpřístupněním pokynů k jeho elektronickému stažení zadavatelem z datového úložiště poskytovatele.

7. Distribuce nových verzí produktu uživatelům elektronicky; dodavatel zajistí takovou funkcionalitu produktu, která umožní jednorázové centrální automatizované provádění instalace nových verzí v rámci infrastruktury objednatele.

8. Distribuce inovovaného produktu za účelem legislativního update nebo legislativního upgrade bude provedena před termínem účinnosti změn příslušných právních předpisů.

9. Aktualizace provozní a bezpečnostní dokumentace.

10. Poskytování přístupu k databázi známých řešených problémů a přístupu k technické podpoře výrobce.

11. Služba Hot-line formou telefonické podpory pro zaměstnance zadavatele pro hlášení požadavků na technickou podporu a servis, poradenství a konzultace.

12. Služba HelpDesk pro zaměstnance zadavatele pro hlášení závad a požadavků na technickou podporu, poradenství a konzultace.

Pod pojmem servis se rozumí:

1. Služby odstraňování vad. Proces odstraňování vad produktu bude probíhat v těchto režimech:

   • Kategorie vady „vysoká“ nebo „havárie“ - vady zabraňující provozu, produkt není použitelný ve svých základních funkcích nebo se vyskytuje funkční závada znemožňující činnost systému. Tento stav může ohrozit běžný provoz objednatele a objednatelem ovládané právnické osoby, ve kterých má objednatel rozhodující vliv na strategické cíle i významná rozhodnutí takto ovládané právnické osoby; k takovému ovládání může docházet i ze strany jiné právnické osoby, která je sama objednatelem ovládána (dále také jako „organizace“) a nelze jej dočasně řešit organizačním opatřením. Nejpozději do 4 hodin po nahlášení vady provede poskytovatel zjištění příčin, které vadu způsobují. Jde-li o vadu způsobenou důvody na straně poskytovatele (oprávněná reklamace) bezodkladně zahájí práce na odstranění vady a zajistí odstranění této vady ve lhůtě do 24 hodin od nahlášení vady, a to i způsobem dočasného provizorního řešení, umožňujícího provoz produktu. Vada bude odstraněna v nejkratší možné lhůtě s ohledem na její povahu a dopad na činnost objednatele. Jde-li o vadu způsobenou důvody na straně objednatele, dohodne s objednatelem další postup.

   • Kategorie vady „střední“ nebo „významná závada“ - vady omezující provoz, funkčnost systému je ve svých funkcích degradována tak, že tento stav omezuje běžný provoz objednatele nebo organizací. Jedná se také o vady způsobující problémy při užívání a provozování produktu nebo jeho části, ale umožňující provoz, jimiž způsobené problémy lze dočasně řešit organizačními opatřeními. Nejpozději do 8 hodin po nahlášení vady provede poskytovatel zjištění příčin, které vadu způsobují. Jde-li o vadu způsobenou důvody na straně poskytovatele (oprávněná reklamace) bezodkladně zahájí práce na odstranění vady a zajistí odstranění této vady ve lhůtě do 2 pracovních dnů od nahlášení vady. Vada bude odstraněna v nejkratší možné lhůtě s ohledem na její povahu a dopad na činnost objednatele. Jde-li o vadu způsobenou důvody na straně objednatele, dohodne s objednatelem další postup.

   • Kategorie vady „nízká“ nebo „chyba“ - vady neomezující provoz, jedná se o drobné vady, které nespadají do kategorií „vysoká“ nebo „střední“. Nejpozději během 2 pracovních dnů po nahlášení vady provede poskytovatel zjištění příčin, které vadu způsobují. Jde-li o vadu způsobenou důvody na straně poskytovatele (oprávněná reklamace) bezodkladně zahájí práce na odstranění vady a zajistí odstranění této vady ve lhůtě do 15 pracovních dnů od nahlášení vady. Vada bude odstraněna v nejkratší možné lhůtě s ohledem na její povahu a dopad na činnost objednatele. Jde-li o vadu způsobenou důvody na straně objednatele, dohodne s objednatelem další postup.

2. Zařazení vady do jednotlivých kategorií určuje objednatel.

3. Vyplyne-li z objektivních skutečností potřeba lhůty delší než je stanovena u jednotlivých kategorií vad, lze písemně dohodnout lhůtu delší. Za objektivní skutečnosti lze považovat zásah vyšší moci, chybnou funkci operačních a databázových platforem, časový rozsah potřebných prací jdoucí nad stanovený rámec.

4. Pro účely smlouvy je pro pracovní dny stanovena pracovní doba od 8:00 do 17:00 hodin.

5. Servis a řešení provozních problémů jednotlivých aplikačních částí díla vzniklých při jejich užití objednatelem a jednotlivými organizacemi.

6. Servis a řešení provozních problémů vzniklých při užití díla na pracovišti objednatele a organizací.

7. Provádění konfiguračních a programátorských prací pro všechny části díla na základě požadavků zadavatele v rozsahu 120 hodin za rok v místě instalace nebo prostřednictvím vzdáleného přístupu.

8. Poskytování služby Hot-line formou telefonické podpory pro hlášení požadavků na technickou podporu a servis, metodickou podporu, poradenství a konzultace (funkčnost systému, návrhy rozvoje, vysvětlení důvodů v zobrazení určitých dat, apod.).

9. Poskytování služby HelpDesk pro hlášení závad a požadavků na servis, metodickou podporu, poradenství a konzultace a jejich řešení.

Cena technické a servisní podpory

Etapy dle článku 5 odst. 2	Nabídková cena v Kč bez DPH
Servisní podpora za 12 měsíců	766.995,00 Kč
Školení v celkovém rozsahu 8 hodin pro jednoho uživatele	493,00 Kč

Příloha č. 3 Vymezení mechanismů servisní podpory a kontaktní údaje

Specifikace komunikačních metod servisní podpory včetně detailních kontaktů obou stran

1. Veškeré požadavky na servisní zásah poskytovatele uplatňují kontaktní osoby objednatele, uvedené v článku VI této Smlouvy, prostřednictvím kontaktního místa, které provozuje poskytovatel v souladu s dále uvedenými pravidly.

2. Dostupnost kontaktního místa je 7x24x365 s garantovanou dobou odezvy do 4 hodin od nahlášení požadavku. Veškeré požadavky budou evidovány v systému HelpDesk servisní podpory poskytovatele.

3. Kontaktní místo umožňuje příjem požadavků na servisní zásah v českém jazyce

▪ na telefonním čísle (Hot-line): v režimu 7x24x365 ▪ systémem servisní podpory (HelpDesk): v režimu 7x24x365

4. Telefonické zadání požadavku bude zajištěno lidskou obsluhou.

5. Požadavek na servisní zásah se považuje za nahlášený okamžikem jeho zapsání na HelpDesk, nebo okamžikem jeho telefonického zadání.

6. Bude zajištěn nepřetržitý přístup do systému servisní podpory (HelpDesk), umožňující objednateli upřesnit nebo doplnit požadavek.

7. Systém servisní podpory musí objednateli poskytovat přehled o aktuálně nahlášených požadavcích, jejich stavu a aktuálním způsobu jejich řešení. Systém bude objednateli zasílat notifikace o změně stavu jeho požadavku (např. zadaný, v řešení, uzavřený atd.) a musí objednateli umožnit schvalování uzavření nahlášeného požadavku.

8. Systém servisní podpory bude poskytovat objednateli přístup i k uzavřeným požadavkům a způsobu jejich řešení, který bude poskytovat podrobné údaje o historii požadavků od jejich nahlášení, po jejich vyřešení.

9. Systém servisní podpory musí umožňovat export dat, včetně obsahu požadavku a způsobu vyřešení. Tato funkcionalita bude poskytovatelem poskytována bezúplatně minimálně na vyžádání objednatele ve formátu minimálně *.xls a *.csv.

10. Objednatel může po vzájemné dohodě umožnit poskytovateli zabezpečený vzdálený přístup do své datové sítě z IP adresy poskytovatele protokolem TCP/IP za účelem plnění části této smlouvy. Objednatel si vyhrazuje právo po předchozím upozornění tento přístup poskytovateli ukončit.

Způsob a podmínky podání žádosti o provedení služby

Požadavky na provedení služeb předává objednatel poskytovateli prostřednictvím služby HelpDesk ICZ některým z těchto způsobů:

1. telefonicky na , nebo

2. přes www formulář na xxxxx://xxxxx.x.xx/; přístup k tomuto formuláři mají pouze oprávněné osoby objednatele na základě platných přístupových práv.

Z důvodu zajištění ochrany dat uložených v systému se objednatel a poskytovatel dohodli, že požadavky na provedení služeb jsou oprávněny za objednatele předávat poskytovateli pouze osoby uvedené v článku 6 odst. 4 smlouvy.

Jakoukoli změnu osoby oprávněné předávat požadavky na provedení služeb stanovené výše je objednatel povinen bezodkladně písemně oznámit poskytovateli. Poskytovatel neodpovídá za vzniklou újmu v případě, kdy objednatel poskytovateli bezodkladně písemně neoznámí změnu osoby oprávněné předávat požadavky na provedení služeb.

Vysvětlení a doplnění zadávací dokumentace č. 2

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení zadávací dokumentace na základě předchozí žádosti dodavatele.

Dotaz č. 1

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 2 SPECIFIKACE ROZSAHU IMPLEMENTACE NIS:

„Obrazový komplement

• Radiodiagnostické oddělení

• Požadavek na import histologických vyšetření (DS) - Oddělení nukleární medicíny“ Není zřejmé, co se požaduje v bodě "- Požadavek na import histologických vyšetření (DS)". Obrazovým komplementem je RDG + Nukleární medicína, ale neznáme pracoviště komplementu s typem provozu " Požadavek na import histologických vyšetření (DS)". Prosíme o upřesnění tohoto bodu.

Odpověď na dotaz č. 1

Histologická vyšetření provádí oddělení patologie. Zadavatel požaduje import textových popisů histologických nálezů.

Dotaz č. 2

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 3 OBECNÉ POŽADAVKY NA APLIKAČNÍ PROGRAMOVÉ VYBAVENÍ:

„Zadavatel požaduje implementaci systémů založených na moderních a všeobecně uznávaných technologických standardech s perspektivou rozvoje po dobu minimálně 20 dalších let.“ Není nám známo, které technologie jsou dnes považovány za "moderní a všeobecně uznávané ". Neexistuje žádná mezinárodně uznávaná definice ani norma specifikující, které technologie jsou považovány za moderní a uznávané. Můžete, prosím, upřesnit, co je výše zmíněným požadavkem přesně myšleno?

Odpověď na dotaz č. 2

Zadavatel požaduje, aby nabídka neobsahovala systém postavený na morálně zastaralých technologiích, které již nejsou (nebo se dá očekávat, že brzy nebudou) podporovány. Jedná se např. o technologie typu “Textové terminály”, neudržované databáze typu DBASE a pod.

Dotaz č. 3

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 3 OBECNÉ POŽADAVKY NA APLIKAČNÍ PROGRAMOVÉ VYBAVENÍ:

„Navrhované systémy musí mít jednotné uživatelské rozhraní se způsobem ovládání respektujícím standardy MS Windows ve všech modulech a funkcionalitách, vyjma odůvodněných případů“

Zadavatel předjímá, že "moderním a všeobecně uznávaným technologickým standardem" jsou aplikace založené pouze na OS WINDOWS a standardech MS WINDOWS. Je všeobecně známo, že v posledních letech probíhá ve vývoji software velmi významný posun k mobilním aplikacím, které nejsou založeny ani na OS WINDOWS ani na jiných standardech MS WINDOWS, ale jsou konstruovány jako nezávislé na jakékoli platformě. Takže již první věta této specifikace vylučuje technologie, které jsou v současném světě považovány za moderní

a upíná se k technologiím, které jsou na ústupu, a nelze s jistotu předpovědět, zda s výhledem 20 let budou vůbec existovat. Existuje objektivní (nediskriminační) důvod, z jakého Zadavatel na výše zmíněném trvá?

Odpověď na dotaz č. 3

Standardy ovládání grafické okenní aplikace, které MS Windows rozšířily mezi uživatele, byly přejaty i na dalších moderních platformách (a drobně upraveny). Účelem uvedení tohoto požadavku je, aby byly základní zvyklosti uživatelů v ovládání aplikace (např. ovládání myší) využity i v novém řešení.

Dotaz č. 4

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 3 OBECNÉ POŽADAVKY NA APLIKAČNÍ PROGRAMOVÉ VYBAVENÍ:

„V systému bude možné strukturované a parametrizovatelné zadávání údajů s možností sdílení jednotlivých položek v dalších dokumentech, s možností nastavení jednotlivých položek (povinný údaj, možné hodnoty) a vlastních číselníků pro jednotlivé položky. Systém musí umožňovat import, popř.

validaci číselníků dle definovaných vzorů (např. VZP, RÚIAN).“

V Příloze 3 ZD není obsažen výčet číselníků, které mají být v dodávaném software implementovány. Co Zadavatel zamýšlí formulací " popř. validaci číselníků "? Je požadovanou funkcionalitou aby software prováděl validaci obsahu importovaných číselníků?

Odpověď na dotaz č. 4

Ano, pokud to bude u konkrétního číselníku možné, je očekávána validace na hodnoty importovaného číselníku dle jeho platnosti, ne validace standardních číselníků při importu.

Dotaz č. 5

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 4.1 Komunikace s interními laboratořemi:

„On-line synchronizace základních číselníků laboratoře s číselníky KIS, a to ve směru z laboratoře do KIS v rozsahu číselník metod včetně všech hodnotících mezí, číselník jednotek, seznam funkčních skupin a skupin metod, matice textových výsledků. Synchronizaci nesmí být pouze na základě rodného čísla nebo čísla pojištěnce, ale musí být shoda jak této položky, tak jména a příjmení.“

Není zřejmé, jakou funkcionalitu KIS zadavatel ve formulaci „Synchronizaci nesmí být pouze na základě rodného čísla nebo čísla pojištěnce, ale musí být shoda jak této položky, tak jména a příjmení.“ požaduje. Prosíme o vysvětlení.

Odpověď na dotaz č. 5

Požadavek „Synchronizaci nesmí být pouze na základě rodného čísla nebo čísla pojištěnce, ale musí být shoda jak této položky, tak jména a příjmení.“ patří do první odrážky bodu 4.1 – týká se synchronizace identifikačních údajů.

Dotaz č. 6

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 4.1 Komunikace s interními laboratořemi:

„Elektronická žádanka je distribuována z KIS a v laboratoři bude připravena ke zpracování v okamžiku jednoznačného spárování s materiálem. Materiál bude označen čárovým kódem. Při ordinování laboratorních vyšetření sledovat frekvenci a upozornit na její překročení. Upozornit na neshodu mezi Dg. a požadovaným vyšetřením. Upozornit na nemožnost ordinace zakázaných metod pro ambulantní pracoviště.“

Zadavatel nespecifikuje:

1. Jakým způsobem bude LIS předávat systému informaci o faktu, že došlo k překročení frekvence objednávaného vyšetření v KIS?

2. Jak má KIS reagovat na zjištění, že objednáním vyšetření dojde k překročení frekvence?

3. Jakým způsobem bude systém z LIS získávat informaci/číselník vyšetření zakázaných pro ambulanci?

4. Jakým způsobem bude KIS získávat informaci/číselník definující seznam povolených vyšetření pro DG?

Odpověď na dotaz č. 6

K písm. a) Překročení frekvenčních omezení zajistí NIS na základě laboratorních výsledků, které má k dispozici, vlastní vyhodnocení frekvenčních omezení zajistí NIS na základě pravidel ve výkaznictví

K písm. b) Upozornění pro uživatele

K písm. c) Uživatelská definice v LIS a export do NIS anebo uživatelská definice v NIS s možností exportu do LIS.

K písm. d) Uživatelská definice v LIS a export do NIS anebo uživatelská definice v NIS s možností exportu do LIS.

Dotaz č. 7

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 4.1 Komunikace s interními laboratořemi:

„On-line distribuce výkonů provedených v laboratoři do centrálního zpracování výkaznictví, tj. okamžitě po uvolnění výsledků jsou do KIS zapisovány i podklady pro vykázání zdravotní péče, včetně on-line Dobropisů a stornování chybně vykázané péče.“

Zadavatel nespecifikuje jakým způsobem/rozhraním budou v okamžiku uvolnění nálezu vyšetření z LIS předávány podklady pro výkaznictví zdravotní péče do KIS. Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 7

Zadavatel odkazuje na bod 4.2 specifikace – funkce bude realizovaná v souladu s datovým standardem MZČR v4.

Dotaz č. 8

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 4.1 Komunikace s interními laboratořemi:

„Pro uživatele v KIS historický přehled výsledků v LIS“

Zadavatel nespecifikuje jakým způsobem/rozhraním budou nálezy evidované v LIS On-Line předávány do KIS. Prosíme o specifikaci.

Odpověď na dotaz č. 8

Zadavatel odkazuje na bod 4.2 specifikace – funkce bude realizovaná v souladu s datovým standardem MZČR v4.

Dotaz č. 9

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 5 POŽADAVKY NA PŘEVOD DAT Z PŮVODNÍCH SYSTÉMŮ:

„2. Položky obsahující pacientská data budou převedeny do odpovídajících položek datových struktur navrženého systému tak, aby byla zachována logika jednotlivých události (hospitalizace, ambulantní vyšetření a k tomu náležející komplementární vyšetření). Dodavatel zajistí minimální rozsah převáděných dat v následujícím rozsahu:

Stanovení data dle zákonných lhůt archivace

Centrální registr pacientů

Ambulantní sledování

Klinické dokumenty Hospitalizace

Laboratorní výsledky

Anamnéza – na centrální kartě

Diář

Rodinné vazby

RTG nález

Urgentní informace“

Zadavatel nespecifikuje, jaký je výčet klinických dokumentů nebo co se rozumí klinickým dokumentem. Výklad termínu klinický dokument nám není znám v kontextu s taxativním výčtem EHR záznamů jiných typů v této sekci zadání. Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 9

Klinickým dokumentem se rozumí jakýkoliv dokument ve zdravotnické dokumentaci pacienta, který popisuje zdravotní stav pacienta. Například: ambulantní nález, příjmová zpráva, propouštěcí zpráva, sesterská, konziliární vyšetření apod. V současných systémech jednotlivých nemocnic se mohou dokumenty nazývat různě a jednotlivá klinická data mohou být pod různými zprávami.

Dotaz č. 10

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 5 POŽADAVKY NA PŘEVOD DAT Z PŮVODNÍCH SYSTÉMŮ:

V tabulkách " Požadavky na převod dat z původních systémů " číslo 9, 10, 11 a 12 je uveden výčet IS s požadavkem na převod dat. První položkou je "Klinický systém a výkaznictví"

Zadavatel nespecifikuje, co přesně se rozumí pojmem "výkaznictví". Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 10

Výkaznictvím se ve smyslu dotazu rozumí vykázaní péče jednotlivým plátcům péče.

Dotaz č. 11

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.1 Minimální požadavky na klinický informační systém v tabulce „Požadavky na centrální a administrativní funkce NIS“:

„Možnost on-line ověření praktického lékaře pacienta“

Není zřejmé, jaká funkcionalita je vyžadována. Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 11

Jde o ověření příslušnosti pacienta k danému praktickému lékaři, u kterého je registrován. Online B2B službou VZP.

Dotaz č. 12

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.1 Minimální požadavky na klinický informační systém v tabulce „Požadavky na centrální a administrativní funkce NIS“:

„Pacientská administrativa včetně statistik“

Není zřejmé, jaké statistiky v rámci pacientské administrativy jsou vyžadovány. Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 12

Jedná se o povinně sestavované statistiky pro ÚZIS – dle metodiky ÚZIS.

Dotaz č. 13

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.1 Minimální požadavky na klinický informační systém v tabulce „Požadavky na centrální a administrativní funkce NIS“:

„Pro pořízení z klinické dokumentace umožnit pořízení způsobem zaklikávání z přednastaveného seznamu obvyklých kódů (včetně mnemotechnických přejmenování kódů)“

Není zřejmé při pořizování jakých typů dat / informací „z klinické dokumentace“ má být v KIS implementována požadovaná funkcionalita. Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 13 Dle zadavatele je obsah požadavku patrný již popisu uvedeného v zadávacích podmínkách. Pro doplnění však zadavatel uvádí: přímo při zápisu klinické dokumentace (nikoliv před zápisem a nikoliv až po zápisu) je nutno zajistit pořizování zdravotních výkonů, ZUM a ZULP popsaným způsobem. (například: od výkonu pro cílené vyšetření, aj.)

Dotaz č. 14

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.1 Minimální požadavky na klinický informační systém v tabulce „Požadavky na centrální a administrativní funkce NIS“:

„Umožnit formalizovanou (dle číselníku) kategorizaci (automatickou) dokladů mimo položky definované metodikou s využitím při statistikách a uzávěrkových činnostech (transformace, modifikace)“

Není zřejmé, co zadavatel zamýšlí:

1. Pojmem automatická kategorizace dle číselníku.

2. Pojmem doklad.

3. Co má být výsledkem této kategorizace?

Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 14

K písm. a) Automatická kategorizace dle číselníku znamená, že požadované řešení musí umožnit vést v číselníku definice vybraných hodnot položek dokladu, při jejichž shodnosti s položkami na dokladu pacienta automaticky tento doklad označí pro další zpracování (změnu kódování, filtrování nebo sestavy)

K písm. b) Pojem doklad je zamýšlen soubor údajů o poskytnuté péči sloužící převážně k uplatnění nároku na proplacení poskytnuté zdravotní péče plátci.

K písm. c) Výsledkem kategorizace je označení dokladu pro další zpracování (viz vysvětlení k písm. a)

Dotaz č. 15

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.1 Minimální požadavky na klinický informační systém v tabulce „Požadavky na centrální a administrativní funkce NIS“:

„Pro každý doklad vést vizualizovaný seznam chyb, prostřednictvím kterého je možné kontextově chyby opravovat“

Není zřejmé, co se rozumí pojmem "doklad". Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 15

Dokladem se rozumí soubor údajů o poskytnuté péči plátci sloužící převážně k uplatnění nároku na proplacení poskytnuté zdravotní péče.

Dotaz č. 16

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.1 Minimální požadavky na klinický informační systém v tabulce „Požadavky na centrální a administrativní funkce NIS“: „Umožnit komentovat doklad a případ DRG poznámkou (včetně historie poznámek)“

Není zřejmé co, se rozumí pojmem "doklad". Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 16

Dokladem se rozumí soubor údajů o poskytnuté péči plátci sloužící převážně k uplatnění nároku na proplacení poskytnuté zdravotní péče.

Dotaz č. 17

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.1 Minimální požadavky na klinický informační systém v tabulce „Požadavky na centrální a administrativní funkce NIS“:

„Možnost filtrování dokladů pomocí definice obecného dotazu (např. SQL) vytvářeného uživatelem nebo správcem. Ukládání vytvořených pojmenovaných konfigurací filtru dokladů pro další použití uživatelem.“

Není zřejmé, co se rozumí pojmem "doklad". Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 17

Dokladem se rozumí soubor údajů o poskytnuté péči plátci sloužící převážně k uplatnění nároku na proplacení poskytnuté zdravotní péče.

Dotaz č. 18

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.8 Zajištění provozu vizity u lůžka pacienta:

„Řešení bude postaveno jako webová aplikace, a bude tedy plně nezávislé na operačním systému dotykového zařízení, pracuje stejně u zařízení Android i-OS či MS Windows. Jediným předpokladem pro práci je přístup k internetu (nebo intranetu), tedy WiFi, případně i mobilní operátor (LTE …).“

Zadavatel předjímá jako platformu WEB aplikace i když ve zbývající části zadání specifikuje, že vlastně požaduje provoz na mobilním zařízení s nezávislostí aplikace na platformě. Tímto předpokladem jsou diskriminováni dodavatelé, kteří mají aplikace vyvinuté např. v prostředí JAVA, které rovněž zaručuje hardwarovou nezávislost a nezávislost na platformě. Prosíme o vysvětlení.

Odpověď na dotaz č. 18

Dle zadavatele se použití aplikace vyvinuté v prostředí JAVA nevylučuje s požadavkem zadavatele stanoveným v zadávacích podmínkách. Zadavatel tedy připouští použití aplikací vyvinutých v prostředí JAVA. Podstatou požadavku je, že celé řešení musí být koncipováno s možností spuštění ve Webovém prohlížeči bez nutnosti instalace jakékoliv aplikace (nezávislost na platformě). A musí být „provozovatelné“ a snadno ovladatelné v mobilním dotykovém zařízení

Dotaz č. 19

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.13 Zajištění elektronické preskripce prostřednictvím napojení na centrální úložiště SÚKL:

„Ověření recentní informace o léčivech předepsaných jinými lékaři“

Zadavatel požaduje funkcionalitu, která není v současných webových službách E-receptu implementována. Aby mohla být funkcionalita implementována, musí zákonodárce přijmout zákonnou normu, která implementaci takovéto funkcionality vůbec umožní. Prosíme o vysvětlení.

Odpověď na dotaz č. 19

Zadavatel v Příloze 3 ZD „Funkční specifikace“ v bodě 6.13 – Zajištění elektronické preskripce prostřednictvím napojení na centrální úložiště SÚKL – především uvádí:

„Navrhovaný systém bude obsahovat podporu elektronické preskripce v rozsahu podporovaných funkcí a služeb integračního rozhraní probíhajícího projektu eRecept (SÚKL)“.

Jako příklad byly dále uvedeny některé z funkcí, které SÚKL uvádí jako plánované funkce, které by měly být benefitem pro lékaře. Zadavatel akceptuje, že pokud v době implementace nebude systém eRecept (SÚKL) tuto funkci integračního rozhraní umožňovat, nemusí být v rámci implementace NIS tato funkce podporována. Pokud tato funkce integračního rozhraní systému eRecept bude v době udržitelnosti projektu umožněna, uchazeč bude mít závazek tuto funkcionalitu dodat v rámci legislativního upgrade.

Dotaz č. 20

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.13 Zajištění elektronické preskripce prostřednictvím napojení na centrální úložiště SÚKL:

„Vyloučení záměny vydávaného LP prostřednictvím unikátního identifikátoru eReceptu v kombinaci s kontrolou, která proběhne uvnitř CÚ.“

Nerozumíme, jakou funkcionalitu zadavatel požaduje. Prosíme o vysvětlení.

Odpověď na dotaz č. 20

Po odeslání údajů o vydaných LP na recept identifikovaný unikátním identifikátorem, dojde na straně CÚ ke kontrole předepsaného a vydaného LP. Dojde-li k nesouhlasu, bude zpět odeslána informace o nesouladu předepsaného a vydaného LP.

Dotaz č. 21

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 6.14 Automatizace hlášení pro externí subjekty (UZIS, matrika…):

„Odesílání příkazu k transportu zabezpečenou elektronickou komunikací na příslušnou dopravnězdravotní službu, Komunikace s revizním lékařem (žádosti o zvýšení úhrady, návrhy na léčebně rehabilitační a lázeňskou péči), s lékařem OSSZ (zpětné uznání DPN).“

1. Zadavatel nespecifikuje v jakém formátu a jakým způsobem požaduje odesílání požadavků k transportu. Dále není specifikováno, jestli požadovaný formát dat a způsob jejich přenosu bude společný pro všechny subjekty nebo každý subjekt může mít odlišný formát a způsob doručení dat. Prosíme o vysvětlení a specifikaci.

2. Není nám znám formát dat ani způsob jejich doručování pro „Komunikace s revizním lékařem (žádosti o zýšení úhrady, návrhy na léčebně rehabilitační a lázeňskou péči)“. Prosíme o vysvětlení a specifikaci.

3. Není nám znám formát dat ani způsob jejich doručování pro „komunikaci s lékařem OSSZ (zpětné uznání DPN)“. Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 21

K písm. a) Zadavatel požaduje připravenost KIS na realizaci zabezpečené elektronické komunikace s DZS webovou službou nebo na bázi DS.

K písm. b) Jedná se o komunikaci dle Datového rozhraní individuálních dokladů VZP.

K písm. c) Jedná se o komunikaci dle aktuálně publikovaného datového rozhraní ČSSZ.

Dotaz č. 22

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 7.3 Architektura informačních systémů - Tabulka Katalog aplikačních rozhraní:

„Rozhraní pro komunikaci s ISZR používané pro ztotožnění pacientů oproti ROB. Dále je v NIS využívána identifikace pacienta pomocí bezvýznamového identifikátoru.“

Domníváme se, že Zadavatel nemůže vyžadovat implementaci ztotožnění pacienta proti ROB, protože neexistuje zákonná norma, která by toto umožňovala. Zdravotnické zařízení v současnosti toto právo nemá zákonodárcem dáno. Prosíme o vysvětlení.

Odpověď na dotaz č. 22

Zadavatel upřesňuje, tento požadavek takto: „Rozhraní na IDRR - Integrované datové rozhraní rezortu, prostřednictvím kterého bude prováděna integrace na ISZR, konkrétně na registr obyvatel (ROB), jakmile bude umožněn přístup a využívání bezvýznamového identifikátoru (AIFO).“ Zadavatel dále akceptuje, že integrace bude součástí dodávky a implementace jen v případě, kdy v době realizace budou tyto systémy připraveny pro integraci, a budou platné legislativní podmínky, 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 doby udržitelnosti projektu, stejně tak legislativní podmínky, zajistí uchazeč realizaci uvedených integrací v rámci legislativního upgrade.

Dotaz č. 23

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 8.1 Požadavek na doplnění tabulky indikátorů:

„Informační a popularizační program uživatelů elektronického zdravotnictví“ Dodavatel nerozumí, co zadavatel požaduje. Prosíme o vysvětlení.

Odpověď na dotaz č. 23

Tento bod odkazuje na „Specifické cíle Strategie eHealth MZČR“, konkrétně na bod „2.3 Informační a znalostní podpora zdravotnických pracovníků a uživatelů elektronického zdravotnictví“. Tento cíl je i jednou ze sledovaných funkcionalit tohoto projektu. Zadavatel požaduje stručný popis, zda a jakým způsobem jeho řešení naplňuje (či přispívá k naplnění) dosažení tohoto cíle.

Dotaz č. 24

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 9 POŽADAVKY ZADAVATELE NA POSTUP IMPLEMENTACE:

„Realizace díla bude zahájena po podpisu realizační smlouvy analýzou a zpracováním projektu, který se stane výchozím dokumentem pro realizaci díla. Zaškolení správců na úrovni úprav systému (procesy, customizace). Školení správců na úrovni stáží na pracovištích je součástí dodávky a implementace systému. Je požadováno mít zajištěné testovací prostředí!“

Zadavatel nespecifikuje, zda je požadováno testovací prostředí pro každou nemocnici zvlášť nebo zda požaduje jedno společné testovací prostředí pro všechny nemocnice. Prosíme o vysvětlení.

Odpověď na dotaz č. 24

Testovací prostředí je požadováno v každé nemocnici zvlášť.

Dotaz č. 25

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 9 POŽADAVKY ZADAVATELE NA POSTUP IMPLEMENTACE:

„Dále je v rámci implementace systému vyžadována trvalá přítomnost pracovníků technické podpory v pracovní době a dostupnost mimo pracovní dobu min. měsíc od začátku implementace.“

Ze zadání není zřejmé:

1. Na kterém místě je vyžadována přítomnost pracovníků technické podpory. Zda v každé nemocnici zvlášť nebo kdekoli v KH kraji nebo na pracovišti helpdesku dodavatele,

2. Není specifikováno, zda je tato přítomnost požadována jako 7x24 nebo je zadání myšleno jinak?

Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 25

Trvalá přítomnost v pracovní době (minimálně 7–15 hod.) je požadována vždy v každé nemocnice, ve které bude systém implementován. Dostupnost mimo pracovní dobu je požadována v rámci podpory přes help desk.

Dotaz č. 26

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 9.1 Analýza aplikačního prostředí:

„Z návrhu řešení bude zřejmý detailní popis cílového stavu, příprava, implementace, parametrizace, dodávka a instalace řešení. Převedení díla do testovacího a produkčního prostředí, soupis akceptačních testů včetně vytvoření projektové dokumentace.“

Zadavatel nespecifikuje, zda je požadováno testovací prostředí pro každou nemocnici zvlášť, nebo zda požaduje jedno společné testovací prostředí pro všechny nemocnice. Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 26

Testovací prostředí je požadováno v každé nemocnici zvlášť.

Dotaz č. 27

Zadavatel uvádí v Příloze 3 ZD „Funkční specifikace“ v bodě 9.3.1 Migrace testovacích aplikací:

„Bude zajištěna úvodní migrace dat i potřebných služeb pro testování IS. Testovací prostředí zajišťuje pravidelnou aktualizaci dat, aby bylo možné v něm provozovat stejná data jako v produkčním

prostředí.“

Zadavatel nespecifikuje, zda je požadováno testovací prostředí pro každou nemocnici zvlášť, nebo zda požaduje jedno společné testovací prostředí pro všechny nemocnice. Prosíme o vysvětlení a specifikaci.

Odpověď na dotaz č. 27

Testovací prostředí je požadováno v každé nemocnici zvlášť.

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek- Lhůta pro podání nabídek nově končí 7. 12. V 10:00. Místo pro podání nabídek se nemění.

Za zadavatele na základě pověření

V Hradci Králové dne 20. 11. 2017

Centrum investic, rozvoje a inovací

Vysvětlení a doplnění zadávací dokumentace č. 3

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení zadávací dokumentace na základě předchozí žádosti dodavatele.

Dotaz č. 1

čl. 4 odst. 8 Smlouvy o dílo uchazeč uvádí, že v případě provedení změn objednatelem dle uvedeného ustanovení bez předchozí konzultace se zhotovitelem nelze po zhotoviteli požadovat, aby nesl v plné míře odpovědnost za důsledky shora uvedené činnosti objednatele, včetně záruky.

Žádáme zadavatele o úpravu uvedeného ustanovení takto:

Objednatel a dotčené nemocnice jsou oprávněny provádět změny HW a SW, nastavení a konfigurace HW a SW, a to tak, aby byl zabezpečen chod produktu a související infrastruktury. Objednatel a dotčené nemocnice jsou povinny zhotovitele předem informovat o plánovaných změnách HW a SW, jakož i o změnách nastavení a konfigurace HW a SW tak, aby zhotovitel mohl vyhodnotit dopady takových změn díla a SLA a stanovit podmínky pro takovou změnu. V opačném případě zhotovitel neodpovídá za jakékoliv vady nebo škodu, které byly způsobeny takovou změnou. Následně objednatel provede potvrzení změny formou záznamu, který bude obsahovat vždy alespoň označení pořadovým číslem, datum vyhotovení, datum podpisu zástupci objednatele, jakož i specifikaci změny HW a SW a změny nastavení a konfigurace HW a SW, která byla provedena a způsob vypořádání připomínek zhotovitele.

Odpověď na dotaz č. 1

Objednatel a dotčené nemocnice jsou oprávněny provádět změny HW a SW, nastavení a konfigurace HW a SW, a to tak, aby byl zabezpečen chod produktu a související infrastruktury.

Objednatel a dotčené nemocnice jsou povinny zhotovitele předem informovat o plánovaných změnách HW a SW, jakož i o změnách nastavení a konfigurace HW a SW tak, aby zhotovitel mohl vyhodnotit dopady takových změn díla a SLA a stanovit podmínky pro takovou změnu. V opačném případě zhotovitel neodpovídá za jakékoliv vady nebo škodu, které byly způsobeny takovou změnou. Zhotovitel musí vyhodnotit dopady a stanovit podmínky pro změnu nejpozději do 8 hodin, pokud tak neučiní, považují se navržené změny za akceptované. Následně objednatel provede potvrzení změny formou záznamu, který bude obsahovat vždy alespoň označení pořadovým číslem, datum vyhotovení, datum podpisu zástupci objednatele, jakož i specifikaci změny HW a SW a změny nastavení a konfigurace HW a SW, která byla provedena a způsob vypořádání připomínek zhotovitele.

Dotaz č. 2

Dle čl. 5 odst. 2 Smlouvy o dílo budou termíny plnění jednotlivých etap stanoveny vždy ve výzvě objednatele.

Žádáme zadavatele o bližší specifikaci termínů plnění jednotlivých etap, např. stanovením minimální doby.

Odpověď na dotaz č. 2

Konkrétní dílčí termíny plnění budou stanoveny se souhlasem zadavatele prostřednictvím prováděcího harmonogramu zpracovaného zhotovitelem v rámci plnění dle článku 5 odst. 2 písm. b) návrhu smlouvy o dílo. V rámci zadávacích podmínek byly dodavatelům poskytnuty všechny informace, které jsou s ohledem na podmínky kvalifikace v rámci tohoto zadávacího řízení dostatečné ke stanovení předpokládaného časového rozsahu jednotlivých etap pro potřeby zpracování nabídky.

Dotaz č. 3

Dle čl. 16 odst. 7 Smlouvy o dílo: V případě ukončení smlouvy, a to i jejím splněním, je zhotovitel povinen objednateli na své náklady bezodkladně poskytnout veškerou součinnost k řádné migraci dat do jiného informačního systému dle zadání objednatele. Tato součinnost bude spočívat především v poskytnutí všech objednatelem požadovaných dat v objednatelem určeném formátu a struktuře.

S ohledem na skutečnost, že uvedený požadavek má zásadní dopad na tvorbu nabídkové ceny, žádáme zadavatele o přesnou specifikaci předávaných dat a současně přesnou specifikaci jejich formátu a struktury.

Odpověď na dotaz č. 3

Předmětná data jsou vždy ve vlastnictví zadavatele. Bez ohledu na vnitřní strukturu musí být zadavateli umožněn přístup k těmto datům při ev. ukončení smlouvy ve smyslu dotazu.

Přístupem se pak rozumí:

1. zpřístupnění databáze v dešifrované podobě a s jasným popisem struktury a vazeb tak aby bylo možné tato data importovat do následného systému;

2. export dat v DASTA pro jednotlivé typy záznamů a uložení do definovaného úložiště.

Zhotovitel poskytne součinnost v takovém rozsahu, aby mohl být takový export úspěšně dokončen.

Dotaz č. 4

Vymezení rozsahu a cen servisní podpory je přílohou č. 2 Servisní smlouvy, přílohou č. 3 je pak vymezení mechanismů servisní podpory a kontaktní údaje. Součástí Funkční specifikace (Přílohy č. 3 ZD) jsou v čl. 10 Požadavky zadavatele na maintenance, obsahující mimo jiné požadavek na službu preventivních prohlídek provozu NIS minimálně 4x ročně pro každou lokalitu, přičemž tento požadavek se v Servisní smlouvě neobjevuje.

Žádáme zadavatele o vysvětlení čl. 10 Funkční specifikace (Požadavky zadavatele na maintenance).

Mají být požadavky dle tohoto článku součástí servisní smlouvy? V případě, že ano, prosíme zadavatele o úpravu Servisní smlouvy tak, aby požadavky stanovené v příloze č. 2 smlouvy, příloze č.

3 smlouvy a požadavky stanovené v čl. 10 Funkční specifikace nebyly ve vzájemném rozporu.

Odpověď na dotaz č. 4

Přílohou č. 1 servisní smlouvy je specifikace informačního systému, která odpovídá funkční specifikaci dle přílohy č. 3 zadávacích podmínek. Článek 10 funkční specifikace je tak součástí servisní smlouvy, kterou je definován obsah servisní podpory, přílohou č. 2 servisní smlouvy je definován její rozsah a přílohou č. 3 je stanoven mechanismus plnění povinností vztahujících se k servisní podpoře.

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek- Lhůta pro podání nabídek nově končí 8. 12. v 10:00. Místo pro podání nabídek se nemění.

Za zadavatele na základě pověření

V Hradci Králové dne 22. 11. 2017

Centrum investic, rozvoje a inovací

Vysvětlení a doplnění zadávací dokumentace č. 4

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení zadávací dokumentace na základě předchozí žádosti dodavatele.

Dotaz č. 1

Zadavatel v části 2.1 ZD Licenční ujednání požaduje poskytnutí oprávnění k užití SW třetím stranám – viz str. 34 Přílohy č. 3, kde se uvádí, že stávající SW je některými nemocnicemi SW sdílen s třetími stranami (soukromými zdravotnickými zařízeními), přičemž toto oprávnění požaduje zadavatel zachovat i pro nově dodaný SW.

Chápeme správně, že hlavní účel práva užití třetí stranou je vykazování do NIS a sdílení informací s nestátními zdravotnickými zařízeními a nikoliv instalace či užití NIS pro provozní činnost nestátního zdravotnického zařízení? Je přípustné takto případně koncipovat licenční pravidla? Případně prosíme o vysvětlení, v jakém rozsahu mají tyto třetí strany právo SW užívat, pokud shora uvedené není přesné či úplné a doplnění informace o možném omezení licence na specifikovaný účel užití.

Odpověď na dotaz č. 1

Hlavním účelem předmětného práva užití třetí stranou je vykazování do NIS a sdílení informací s třetí stranou. Účelem tohoto práva není umožnit instalaci či užití NIS pro provozní činnost třetí strany.

Zadavatel pro upřesnění dodává, že v případě LDN Opočno je modul této třetí osoby včetně veškeré zdravotnické dokumentace součástí NIS Oblastní nemocnice Náchod.

Zadavatel tak trvá na svém požadavku poskytnutí práva užití programového vybavení třetí osobě v novém NIS včetně převodu dat, tak jak je stanoveno v Příloze č. 3 zadávacích podmínek - Funkční specifikace v části 2.1 - Licenčního ujednání.

Dotaz č. 2

Zadavatel v části 2.1. ZD požaduje právo poskytovat neomezený počet podlicencí v rozsahu licence udělené dodavatelem zadavateli, přičemž cena za veškerá tato oprávnění zadavatele by již měla být zahrnuta v ceně za veřejnou zakázku (dodávku a implementaci SW).

Takové oprávnění zadavatele v podstatě znamená, že je oprávněn bez souhlasu dodavatele SW dále neomezeně šířit (není vyloučeno ani šíření za úplatu), přičemž dodavatel by v takovém případě již neměl nárok na jakoukoliv další odměnu. Dodavatel se tímto v podstatě vzdává svého výhradního práva šířit svůj SW, resp. si tímto vytváří významnou konkurenci v osobě zadavatele. V této souvislosti je rovněž třeba výslovně zmínit, že součástí licence má být dokonce oprávnění zadavatele SW upravovat a dále rozvíjet a měnit jeho název.

Prosíme o vysvětlení záměru zadavatele, byť to zřejmě není účelem licenčních podmínek, resp. smlouvy o dílo jako takové, jsou podmínky koncipovány tak široce, obecně a nejednoznačně, že takový krajní případ popsaný výše není vyloučen. Z praxe víme, že poskytování sublicence má mnohdy význam poskytnutí licence pro příspěvkovou organizaci, dceřinou společnost apod., tedy osobu, u níž je dopředu známé právní postavení a propojení se zadavatelem. Jde i v tomto případě o snahu postihnout tyto skutečnosti?

Pokud ano, je přípustné definovat sublicenci jako předem definovanou opci, která může být součástí základní licence nebo být dokoupena v případě poskytnutí sublicence za předem jasně definovaných podmínek? Kolik takových sublicencí zadavatel fakticky zvažuje?

Odpověď na dotaz č. 2

Jak je uvedeno přímo v článku 2 odst. 2.1 zadávacích podmínek, udělení podlicencí je omezeno na okruh subjektů definovaných jako “zadavatel, zadavatelem zřízené a zakládané organizace, případně subjekty zakládanými či zřizovanými těmito organizacemi, souhrnně také nazývané jako podřízené organizace”. Předmětné ustanovení zadávacích podmínek se dále odkazuje na článek 2 odst. 2.1 přílohy č. 3 zadávacích podmínek - Licenční ujednání. I v tomto ustanovení je zakotveno omezení užití licencí pouze na pracovní stanice zadavatele či dotčených organizací.

Zadávací podmínky tak neumožňují výklad, který by umožnil šíření SW způsobem uvedeným dodavatelem v rámci dotazu. Z tohoto důvodu zadavatel trvá na stávajícím znění licenčních ujednání.

Dotaz č. 3

Zadavatel v části ZD 2.2 Licence k dílu požaduje v bodě 3. licenci neomezenou územním ani množstevním rozsahem a dále neomezenou způsobem nebo rozsahem užití;

Prosíme o vysvětlení požadavku na licenci neomezenou územím, je záměrem dodavatele poskytovat nabytý SW mimo území ČR?

Odpověď na dotaz č. 3

Účelem tohoto ustanovení je zajistit možnost přístupu k NIS pracovníkům zadavatele či dotčených organizací i ze zahraničí. Nejedná se o poskytování licence či podlicence zahraničnímu subjektu.

Dotaz č. 4

V zadávacích podmínkách bod 7 – Technické podmínky požaduje zadavatel prokázání splnění technických podmínek jednotlivými účastníky předvedením funkcionalit nabízeného NIS. V bodě 5 je požadováno předvedení komunikace s laboratorním systémem vč. synchronizace registrů a výkaznictví (do NISu s lab. výsledky i pojišťovna), vytvoření a přenos žádanky, příjem výsledkového listu. Pro předvedení požadované synchronizace je nutné použít registr LIS OpenLIMS.

Prosíme proto zadavatele o poskytnutí tohoto registru v dostatečném časovém předstihu pro potřeby naplnění technických podmínek.

Odpověď na dotaz č. 4

V čl. 7 - Technické podmínky zadávací dokumentace v bodě 5 zadavatel požaduje předvedení funkcionalit nabízeného NIS, konkrétně komunikaci s laboratorním systémem vč.

synchronizace registrů a výkaznictví (do NISu s lab. výsledky i pojišťovna), vytvoření a přenos žádanky, příjem výsledkového listu.

Zadavatel v rámci tohoto bodu předvedení funkcionalit požaduje předvedení synchronizace jednotlivých položek nikoli celé databáze.

Pro upřesnění zadavatel dodává, že v rámci dotčeného bodu čl. 7 zadávacích podmínek požaduje:

• předvedení načtení paketu DASTA v4 do NIS a na základě údajů v něm založení identifikačních údajů v NIS, pokud ještě NIS ID neobsahuje;

• předvedení, že podle údajů v DASTA v4 budou v NIS vytvořeny podklady pro vyúčtování;

• předvedení vytvoření elektronické žádanky v DASTA v4 v NIS;

• předvedení načtení výsledkového listu ve formátu DASTA v4 do NIS.

K předvedení synchronizace jednotlivých položek není potřeba užití registru LIS OpenLIMS.

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 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“). Lhůta pro podání nabídek nově končí

11. 12. 2017 v 10:00 hod. Místo pro podání nabídek se nemění.

Zadavatel dále upozorňuje, že v průběhu tvorby tohoto dokumentu obdržel další žádosti o vysvětlení zadávací dokumentace dle § 98 zákona, přičemž na tyto bude odpovězeno následujícím/následujícími vysvětlením/vysvětleními zadávací dokumentace v souladu s § 98 a násl. zákona.

Za zadavatele na základě pověření

V Hradci Králové dne 24. 11. 2017

Centrum investic, rozvoje a inovací

Vysvětlení a změna zadávací dokumentace č. 5

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení zadávací dokumentace a mění zadávací podmínky veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1

Zadavatel uvádí v Zadávacích podmínkách v bodě 2.3: „Zadavatel zajistí vybranému dodavateli součinnost provozovatelů stávajících NIS a souvisejících systémů spočívající v zajištění všech požadovaných dat ve struktuře určené vybraným dodavatelem.“

Znamená to tedy, že dodavatel popíše datové struktury, které požaduje pro migraci a stávající provozovatel NIS vytvoří? Kdo ponese náklady vzniklé na straně provozovatelů NIS a souvisejících systémů? Kdo garantuje a určuje termíny dodání potřebných dat ze strany provozovatelů NIS?

Odpověď na dotaz č. 1

Ano. Dále k dotazu dodavatele zadavatel uvádí, že náklady ponese zadavatel. Termíny garantuje zadavatel.

Dotaz č. 2

Zadavatel uvádí v Zadávacích podmínkách v bodě 2.4: „V rámci zkušebního provozu dojde k ověření splnění funkčních požadavků zadavatele a k ověření migrace a komplexnosti převodu dat.“

Jakým způsobem se bude ověřovat splnění funkčních požadavků? Jaký se bude postupovat v případě rozporu mezi dodavatelem a objednavatelem?

Odpověď na dotaz č. 2

Postupy budou specifikovány v plánu projektu.

Dotaz č. 3

„...Školení bude realizováno v místě plnění, lektorem (y), v celkovém rozsahu 8 hodin pro jednoho uživatele pro maximální počet 2 950 uživatelů. ...“

Jaká je maximální kapacita jednoho sezení (tzn. kolik uživatelů současně může absolvovat školení)?

Jaká je maximální délka jednoho sezení? Kdo zajistí technické vybavení potřebné pro řádné

proškolení (PC)? Kdo zajistí, že všichni uživatelé absolvují povinně školení? Kdo bude nést odpovědnost za uživatele (aby se nechal proškolit, dostavil se na školení atd..).

Odpověď na dotaz č. 3 Maximální kapacita je 15 uživatelů. Maximální délka jednoho sezení jsou 4 hodiny. Technické vybavení zajistí Zadavatel. Odpovědnost za řádné proškolení svých zaměstnanců nese Zadavatel.

Dotaz č. 4

Zadavatel uvádí v Příloze 1 ZD „Smlouva o dílo“ Článek 4 Specifikace díla: „2. Dílo má tyto části: d) Dodávka a implementace produktu a migrace dat včetně ověření migrace a komplexnosti převodu dat v rozsahu dle jednotlivých prováděcích projektů.“

Kdo a kdy bude určovat, jaká data se budou migrovat?

Odpověď na dotaz č. 4

Prováděcí projekty budou akceptovány oběma smluvními stranami.

Dotaz č. 5

Zadavatel uvádí v Příloze 1 ZD „Smlouva o dílo“ Článek 4 Specifikace díla: „3. Součástí díla je rovněž: b) Realizace zátěžových, akceptačních a bezpečnostních testů produktu, a to s nastavením a daty ve stejné podobě, s jakou bude pracovat dílo během rutinního provozu;“

Co je přesně myšleno termínem „zátěžový test“? Co je to akceptační a bezpečnostní test? Prosíme o vysvětlení a podrobnější specifikaci.

Odpověď na dotaz č. 5

Zátěžový test

• Test simulující práci velkého počtu uživatelů v systému nebo vytvářející značný počet akcí v systému

• Test měřící výkonnost aplikace, vztah mezi počtem uživatelů, prodlužujícími se časy odezev a zvyšující utilizací hardwarových komponent serverů

• Na základě analýzy výsledku měření identifikuje problémy související se zátěží, umožňuje opravu těchto problémů nebo optimalizaci systému

Testem bezpečnosti se rozumí test zátěžový, ke kterému je požadován navíc minimálně test Disaster Recovery tzn. test obnovy informačního systému po havárii, který by neměl zahrnovat pouze schopnost obnovit data (např. z páskové mechaniky), ale mělo by dojít k plnohodnotnému zprovoznění produkčního prostředí.

Akceptační testem se rozumí test produktu z hlediska naplnění podmínek smlouvy o dílo nutných k řádné akceptaci díla.

Dotaz č. 6

Zadavatel uvádí v Příloze 1 ZD „Smlouva o dílo“ Článek 4 Specifikace díla: „3. Součástí díla je rovněž: f) Převod relevantních dat a nastavení komunikačních vazeb;“

Co je přesně myšleno termínem „převod relevantních dat“? Prosíme o vysvětlení a podrobnější specifikaci.

Odpověď na dotaz č. 6

Podrobnější specifikace je obsažena v dokumentu Funkční specifikace v kapitole č. 5 (příloha č. 3 zadávací dokumentace), kde napsáno:

„Zadavatel požaduje převod dat z původních systémů uvedených v tabulkách č. 9–12. Budou převedeny historické pacientské údaje ve dvou rovinách:

Budou převedena data pacientů, kteří projdou kontrolou na duplicitu a validitu čísla pojištěnce. Zadavatel poskytne součinnost u případných duplicit.

Položky obsahující pacientská data budou převedeny do odpovídajících položek datových struktur navrženého systému tak, aby byla zachována logika jednotlivých události (hospitalizace, ambulantní vyšetření a k tomu náležející komplementární vyšetření). Dodavatel zajistí minimální rozsah převáděných dat v následujícím rozsahu:

• Stanovení data dle zákonných lhůt archivace

• Centrální registr pacientů

• Ambulantní sledování

• Klinické dokumenty

• Hospitalizace

• Laboratorní výsledky včetně vazby na elektronickou dokumentaci, je-li tvořena

• Anamnéza – na centrální kartě

• Diář

• Rodinné vazby

• RTG nález včetně vazby na obrazovou dokumentaci v PACS

• Urgentní informace“

Dotaz č. 7

Zadavatel uvádí v Příloze 1 ZD „Smlouva o dílo“ Článek 4 Specifikace díla: „7. Xxxxxxxxxx se zavazuje provozovat produkt na HW a SW objednatele a dotčených nemocnic dle jejich pokynů.“

Uchazeč nemůže garantovat podobný požadavek bez bližší znalosti HW a SW objednatele. Prosíme o podrobný seznam a specifikaci HW a SW.

Odpověď na dotaz č. 7

Zadavatel mění tuto část ustanovení smlouvy takto: „Zhotovitel se zavazuje provozovat produkt na HW a SW zadavatele a dotčených nemocnic dle jeho pokynů, které zhotovitel poskytne na počátku realizace díla“. Upravený návrh smlouvy o dílo je přílohou tohoto dokumentu jako příloha č. 1 a nahrazuje původní přílohu č. 1 smlouvy o dílo ve znění před uveřejněním tohoto dokumentu.

Dotaz č. 8

Zadavatel uvádí v Příloze 1 ZD „Smlouva o dílo“ Článek 17 Ostatní práva a povinnosti smluvních stran: „11. Minimálně dva členové realizačního týmu zhotovitele se musí zúčastnit pravidelných kontrolních dní v sídle objednatele nebo kterékoliv z dotčených nemocnic dle pokynu objednatele, které budou probíhat minimálně jednou za měsíc ode dne, kdy smlouva nabude účinnosti. Objednatel může dle aktuální potřeby frekvenci konání těchto kontrolních dní upravit.“

Z tohoto bodu vyplývá, že frekvence kontrolních dní je zcela na Objednateli. Existuje nějaké maximální omezení? Popřípadě, kdo bude hradit náklady zhotovitele s tímto spojenými?

Odpověď na dotaz č. 8

Maximální omezení je 1x za 10 pracovních dní. V případě potřeby většího počtu kontrolních dní hradí náklady Zadavatel.

Dotaz č. 9

Zadavatel uvádí v Příloze 1 ZD „Smlouva o dílo“ Článek 17 Ostatní práva a povinnosti smluvních stran: „12. Xxxxxxxxxx je povinen účastnit se na základě pozvánky objednatele všech jednání týkajících se předmětu smlouvy, řídit se při provádění plnění dle této smlouvy jeho pokyny a poskytnout mu požadovanou dokumentaci. Účast na těchto jednáních není považována za technickou podporu, údržbu, poradenství ani konzultaci a zhotoviteli za takové jednání nenáleží odměna.“

Z tohoto bodu vyplývá, že frekvence a množství jednání je zcela na Objednateli. Existuje nějaké maximální omezení? Popřípadě, kdo bude hradit náklady zhotovitele s tímto spojenými?

Odpověď na dotaz č. 9

Maximální omezení neexistuje, samotné množství jednání vyplyne ze samotné realizace předmětu plnění dle potřeb smluvních stran. Předpokládáme v tomto směru maximálně možnou vzájemnou dohodu obou stran. Náklady jsou věcí zhotovitele.

Dotaz č. 10

Zadavatel uvádí v Příloze 2 ZD „Servisní smlouva“ Příloha č. 2 Vymezení rozsahu a cen servisní podpory - Rozsah technické a servisní podpory: „b) Pod pojmem update se rozumí taková verze produktu, u které se oproti předcházející verzi produktu mění jeho funkčnost, a to na základě změny jakékoliv skutečnosti, podle které byla celá funkčnost tohoto produktu vytvořena, ale nemění se struktura dat datového fondu, se kterým tato verze produktu pracuje. V případě, že změna funkčnosti tohoto produktu byla provedena pouze na základě legislativních změn, je nová verze tohoto produktu jeho “legislativním updatem”.“

Co nastane v případě, že vznikne rozpor mezi objednavatelem a dodavatelem? Kdo bude arbitr?

Odpověď na dotaz č. 10

Vztahy vznikající ze smlouvy a v ní výslovně neupravené se řídí Právním řádem ČR, zejména pak příslušnými ustanoveními občanského zákoníku a autorského zákona viz čl. 18 – Závěrečné ustanovení odst. 6 návrhu smlouvy o dílo, který je přílohou č. 1 zadávací dokumentace.

Dotaz č. 11

Obecně k Funkční specifikaci:

Zadavatel požaduje řešení, kdy nejprve vybuduje 4 nezávislé servery s replikací.

Domníváme se, že se jedná o velmi zastaralé a drahé řešení – z jakého důvodu zadavatel neumožňuje mnohem levnější a jednodušší variantu jednoho centrálního datového centra pro všechny nemocnice?

Odpověď na dotaz č. 11

Požadavek vychází z potřeb a možností jednotlivých akciových společností.

Dotaz č. 12

Požadavek zadavatele, kap. 9.4.2

Pro akceptaci díla budou vedle naplnění povinných funkčních požadavků potřebné testy vlastní technologické infrastruktury.

Typy testů uvede dodavatel v odsouhlaseném Prováděcím plánu projektu. Dotaz uchazeče

Předpokládáme správně, že závazek na provedení zátěžových či akceptačních testů a vytvoření související dokumentace v případě řešení technologické infrastruktury bude v rozsahu komponent řešení dodaných a instalovaných jejich dodavatelem?

Odpověď na dotaz č. 12

Ano, závazek provedení testů a vytvoření dokumentace je na dodavateli technologické infrastruktury.

Dotaz č. 13 Požadavek zadavatele, kap. 9.5.

Dodavatel v rámci plnění zajistí zpracování dokumentace skutečného provedení, systémové a provozní dokumentace související s předmětem plnění ve schváleném v Prováděcím plánu projektu Dotaz uchazeče

Předpokládáme správně, že závazek na zpracování dokumentace v případě řešení technologické infrastruktury bude v rozsahu komponent řešení dodaných a instalovaných jejich dodavatelem?

Odpověď na dotaz č. 13

Ano, závazek na zpracování dokumentace v rozsahu komponent dodaných a instalovaných dodavatelem je na dodavateli technologické infrastruktury.

Dotaz č. 14

Požadavek zadavatele, kap. 7

V kapitole 7 zadávací dokumentace - Technické podmínky - je požadavek na prokázání splnění technických podmínek.

Dotaz uchazeče

Je toto prokázání součástí kvalifikačních podmínek/kritérií Zadávací dokumentace?

Odpověď na dotaz č. 14

Technické podmínky v čl. 7 zadávací dokumentace definují technické podmínky veřejné zakázky. Kvalifikační předpoklady veřejné zakázky jsou definovány v čl. 6 zadávací dokumentace.

Dotaz č. 15

V kapitole 7 Technické požadavky Zadavatel v rámci prokázání splnění technických podmínek vyzve k předvedení uvedených funkcionalit nabízeného NIS.

Dotaz uchazeče

Je možné, aby Zadavatel upřesnil funkce uvedené v oblastech – viz body tabulky 1 až 10?

Odpověď na dotaz č. 15

Zadavatel nebude funkce uvedené v bodech 1 až 10 kapitoly 7 Technické požadavky upřesňovat neboť tyto jsou dostatečně podrobně popsány v Příloze č. 3 - Funkční specifikace zadávací dokumentace a to v kapitole 6 POŽADOVANÉ VLASTNOSTI A FUNKCE

JEDNOTLIVÝCH OBLASTÍ (viz podkapitoly 6.1. až 6.15) této přílohy.

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 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“). Lhůta pro podání nabídek nově končí

15. 12. 2017 v 10:00 hod. Místo pro podání nabídek se nemění.

Příloha:

Smlouva o dílo ve znění k 27. 11. 2017

Za zadavatele na základě pověření

V Hradci Králové dne 27. 11. 2017

Centrum investic, rozvoje a inovací

Vysvětlení zadávací dokumentace č. 6

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení zadávací dokumentace veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1

V dokumentu zp_p03_technicka_specifikace.pdf je v kapitole 6.4 Požadavky na řešení pro obrazový komplement uvedena podmínka na Vytváření worklistu pro modality v PACS.

Podotázka č. 1 Chápeme správně, že má zadavatel na mysli standardní workflow, kdy řídící

systém (NIS) řešící problematiku obrazového komplementu má pouze

předávat informace o naplánovaných vyšetřeních do stávajícího PACS, který

bude řešit tvorbu worklistů a jejich distribuci na jednotlivé modality?

Podotázka č. 2 Chápeme správně, že součástí dodávky jsou i úpravy na straně dotčených

systémů (minimálně stávající systém PACS) a součástí nabídkové ceny jsou

případné náklady na straně dodavatelů dotčených systémů?

Odpověď na dotaz č. 1

K podotázce č. 1 Ano

K podotázce č. 2 Ne. U současného PASCS může dojít ke změně v průběhu realizace zakázky (viz strana 8 v dokumentu Funkční specifikace dle přílohy č. 3

zadávacích podmínek). Tuto možnou změnu či jen případné úpravy bude zadavatel financovat z jiných zdrojů.

Dotaz č. 2

V dokumentu zp_p03_technicka_specifikace.pdf je v kapitole 6.1 Minimální požadavky na klinický informační systém uvedena podmínka Obousměrná synchronizace změn registrů pacientů mezi NIS a spolupracujícími systémy (minimálně laboratorní systém, PACS, manažerský systém), včetně přenosu náhradní identifikace cizince. Minimální rozsah navzájem přenášených akcí: nový záznam, oprava, zneplatnění, sloučení.

Podotázka č. 1 Chápeme správně, že NIS je nadřazený všem systémům jako primární EPR systém a všechny ostatní podřízené systémy pak přebírají informace o změnách pacientských údajů?

1

Podotázka č. 2 Chápeme správně, že součástí dodávky jsou i úpravy na straně dotčených systémů (minimálně laboratorní systém, PACS, manažerský systém) a součástí nabídkové ceny i náklady na straně dodavatelů dotčených systémů?

Odpověď na dotaz č. 2

K podotázce č. 1 Ano, obecně je NIS nadřazen ostatním systémům; ve výjimečných

případech, například když údaje o pacientovi vstupují nejdříve do LIS,

budou tyto údaje převzaty do NIS.

K podotázce č. 2 Ne. Případné náklady na straně dodavatelů dotčených systémů nese

zadavatel.

Dotaz č. 3

Ze zadávací dokumentace, konkrétně z kapitoly 6.12 technické specifikace vyplývá požadavek certifikace IIb na požadovaný prohlížeč, což je obvyklé pro diagnostické prohlížeče. Dále je v kapitole

2.1 uveden požadavek na dodávku Unlimited licence.

Chápeme správně, že zadavatel požaduje dodávku neomezené („Unlimited“) licence diagnostického prohlížeče a dodávku neomezené („Unlimited“) licence klinického prohlížeče?

Odpověď na dotaz č. 3

Ne. Zadavatel požaduje dodávku neomezené („Unlimited“) licence klinického prohlížeče. V případě diagnostického prohlížeče stačí vždy jedna licence pro každou nemocnici. Případné doplnění potřebného počtu diagnostických licencí bude realizováno při obměně či modernizaci PACS i v návaznosti na další rozvoj v oblasti práce s obrazovými informacemi.

Místo a lhůta pro podání nabídek

Lhůta pro podání nabídek ani místo podání nabídek se nemění.

Za zadavatele na základě pověření

V Hradci Králové dne 30. 11. 2017

Centrum investic, rozvoje a inovací

2

Vysvětlení a změna zadávací dokumentace č. 7

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení a mění zadávací dokumentaci veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1

Zadavatel v čl. 1 Funkční specifikace (Příloha č. 3 ZD) uvádí popis současného stavu ICT. Z důvodů stanovení přesného rozsahu předmětu dodávky žádá uchazeč zadavatele o doplnění specifikací, zda modul pro stravovací provoz bude dodáván i do Městské nemocnice a.s. neboť z uvedených specifikací v příloze 3 Funkční specifikace to není zcela zřejmé (viz tabulka 1 na straně 5 Funkční specifikace).

Odpověď na dotaz č. 1

Odpověď na dotaz č. 1 Městská nemocnice, a.s. (Dvůr Králové nad Labem), nemá stravovací informační systém, ale uvažuje o jeho zavedení. Do této nemocnice bude ze strany dodavatele NIS provedena příprava na integraci s jedním ze stávajících systémů používaných v dotčených nemocnicích, a to v rámci dodávky NIS. Upřesnění konkrétního systému ze tří aktuálně používaných bude předmětnou nemocnicí provedeno v rámci přípravy prováděcího projektu implementace NIS. V případě, že bude následně Městskou nemocnicí, a.s., zvolen zcela odlišný systém, budou náklady spojené s jeho integrací hrazeny ze strany nemocnice.

V návaznosti na výše uvedené dochází k úpravě přílohy č. 3 zadávacích podmínek - Funkční specifikace - úprava se týká článku 5 - Požadavky na převod dat z původních systémů, konkrétně tabulky č. 11 (Náchod) a tabulky č. 12 (Trutnov). Změna se týká stravovacích systémů, původní požadavek na „náhradu s převodem dat“, byl změněn na požadavek „ponechání s komunikací“. Upravená funkční specifikace je přílohou č. 1 tohoto dokumentu.

Dotaz č. 2

V čl. 1.2.8. Funkční specifikace, kde jsou popsány stávající systémy pro řízení provozu stravování, je zmiňována řada funkcí (např. burzy jídel, homebanking, doplňkové prodeje), přičemž na straně 68 Funkční specifikace jsou stanoveny pouze minimální požadavky na funkcionality, které jsou potřebné pro řešení stravovacího provozu, které jednak zadavateli negarantují dodání výše zmiňovaných funkcí stávajících systémů a zároveň mohou citelně zasáhnout do cenotvorby při dodávce řešení. Z důvodů vyloučení všech pochybností o rozsahu předmětu dodávky a rozsahu požadovaných funkcionalit uchazeč žádá zadavatele o doplnění následujících informací uvedených níže v tabulce. Bez specifikace těchto parametrů nelze vypracovat nabídku a/nebo mohou být nabídky jednotlivých uchazečů neporovnatelné.

Modul	Funkcional ita	Otázka	Městská nemocni ce a.s.	Oblastní nemocni ce Náchod	Oblastní nemocni ce Jičín	Oblastní nemocni ce Trutnov a.s.
Stravova cí systém	Skladová evidence	Jakým způsobem je požadováno vést skladové ceny zásob (průměrovaná cena / fifo / jiný způsob)
Stravova cí systém	Skladová evidence	Jakým způsobem (souborový přenos / webové služby/ db view / jinak) je požadováno napojení na účetnictví? (dle ZD předpokládáme systém FEIS)
Stravova cí systém	Skladová evidence	Je požadováno napojení skladové evidence na automatizované objednávání surovin od dodavatelů?
Stravova cí systém	Dietní systém	Jak probíhá expedice stravy na lůžková oddělení? (tabletový systém / termoporty / kombinace)
Stravova cí systém	Dietní systém	Je požadována ordinace a příprava individuálních diet pro pacienty?
Stravova cí systém	Dietní systém	Je využíván tisk štítků pro označování stravy pacientů? Jakým způsobem? (na tablet se jménem / bez jména / s rozpisem indiv. stravy / jinak)
Stravova cí systém	Dietní systém	Uveďte počty: lůžkových stanic / maximální počet pacientů na lůžkách
Stravova cí systém	Strav. zaměstnanců	Jakým způsobem (souborový přenos / webové služby/ db view / jinak) je požadováno napojení na mzdový systém? (dle ZD předpokládáme systém Navision)
Stravova cí systém	Strav. zaměstnanců	Jakým způsobem je organizováno stravování zaměstnanců? (objednávky předem / samoobslužná jídelna / restaurační s obsluhou / kombinace)
Stravova cí systém	Strav. zaměstnanců	Je realizován rozvoz stravy zam. na oddělení (ano / ne / omezeně - pouze pohotovostní pracoviště, Oper. sály atd.)
Stravova cí systém	Strav. zaměstnanců	Jsou využívány identifikační předměty (karty/čipy/přívěsky)? Uveďte používanou technologii (magnetické / HID / Mifare / EM (unique) / Dallas / jiné)
Stravova cí systém	Strav. zaměstnanců	Uveďte počty: jídelen s výdejem na kartučip / max. počet obědů denně / počet evidovaných karet-čipů
Stravova cí systém	Strav. zaměstnanců	Jsou v systému realizovány pokladní místa pro prodej stravy / rozšířeného sortimentu zboží?
Stravova cí systém	Strav. zaměstnanců	Jsou do systému zapojeny automaty pro výdej nápojů / chlazené stravy / drobného sortimentu?
Stravova cí systém	Strav. zaměstnanců	Je požadována integrace stávajících spec. zařízení (čtečky / objednávkové terminály / výdejní terminály / POS pokladny / jiná zařízení) ?
Stravova cí systém	Strav. zaměstnanců	Uveďte počty: objednacích terminálů / výdejních terminálů / pokladních míst pro prodej stravy / výdejních automatů
Stravova cí systém	Napojení na HACCP	Je požadováno napojení na systém HACCP (řízení správné výrobní praxe a kontrola hygienických požadavků)? Uveďte o jaký sw produkt se jedná.

Odpověď na dotaz č. 2

Funkční specifikace odpovídá předávání dat mezi NIS a SIS, ve kterém jsou hlášeny jednotlivé požadavky diet/přídavků z oddělení. Dále je požadováno sdílení číselníků oddělení a diet.

V případě, že stravovací systém nepodporuje předání dat automaticky, na vyžádání, je požadováno souborové propojení. Tento export proběhne 3-5krát za den v definovaný čas do nastavené složky. V takovém případě zajišťuje přebírání dat a další zpracování zadavatel. Popis exportního souboru zajistí v tomto případě odběratel.

V případě SIS, které jsou dnes propojeny s NIS v režimu “semi-online” nebo výměna dat na vyžádání (např. Gurmed, XxxxxxX), je požadován rovnocenný režim integrace na úrovni předávání dat mezi SIS a novým NIS. Přebírání a další zpracování na straně NIS zajišťuje dodavatel, dodavatel rovněž zajišťuje předávání dat pro SIS v kompatibilním formátu.

Přílohy č. 1 Funkční specifikace platná ke dni 4. 12. 2017

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění a změně zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů.

Lhůta pro podání nabídek nově končí 19. 12. 2017 v 10:00 hod.

Místo pro podání nabídek se nemění.

Za zadavatele na základě pověření

V Hradci Králové dne 4. 12. 2017

Centrum investic, rozvoje a inovací

Vysvětlení, doplnění a změna zadávací dokumentace č. 8

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení, doplňuje a mění zadávací dokumentaci veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1

Ve vysvětlení ZD_03 zadavatel změnil znění čl. 4 odst. 8 Smlouvy o dílo. Změna však nebyla nijak promítnuta do znění smlouvy o dílo, jež je Přílohou č. 1 ZD. Znamená to, že platí původní znění? Pokud ne, prosíme o úpravu Přílohy č. 1 ZD – Smlouva o dílo.

Odpověď na dotaz č. 1

Odpovědí č. 1 v rámci dokumentu vysvětlení a doplnění zadávací dokumentace č. 3 došlo k doplnění ustanovení článku 4 odst. 8 návrhu smlouvy o dílo jakožto přílohy č. 1 zadávacích podmínek. Platí tedy znění dle vysvětlení a doplnění zadávací dokumentace č. 3. Zadavatel pro doplnění v příloze č. 1 tohoto dokumentu poskytuje návrh smlouvy o dílo ve znění uvedeného doplnění.

Dotaz č. 2

V příloze 3. ZD - technická specifikace Zadavatel uvádí v bodě 6.2 „Vedení pacientské dokumentace na ambulancích“ požadavek: „- mít k dispozici on-line informace o lékových interakcích, možnost nastavit závažnost interakce.“ Vlastní zadavatel databázi nebo aplikaci s lékovými interakcemi, kterou může dodavatel použít s dodávaným NIS, nebo je potřeba dodat i licence pro lékové interakce. Pokud je potřeba dodat řešení lékových interakcí, tak jaký počet uživatelů bude lékové interakce používat?

Odpověď na dotaz č. 2

Zadavatel nevlastní databázi lékových interakcí. Řešení je součástí dodávky NIS. Počet licencí je uveden v článku 4 odst. 1 písm. a) návrhu smlouvy o dílo.

Přílohou tohoto dokumentu je dále upravená verze přílohy č. 3 zadávacích podmínek – Funkční specifikace – platná ke dni uveřejnění tohoto dokumentu.

Dotaz č. 3

V příloze 3 ZD Zadavatel uvádí: - v bodě 1.2.5 1.2.5 Systém pro obrazovou dokumentaci (PACS) :

„Specializované řešení pro elektronické zpracování, archivaci a distribuci obrazových dat ve zdravotnictví. Různé možnosti nastavení distribuce snímků, v rámci RDG oddělení, celé nemocnice včetně externích a spolupracujících lékařů nebo mezi různými zdravotnickými zařízeními. Možnost propojení s NIS. Podporuje rozšířené datové standardy (DICOM, HL7, DaSta). Systém využívají všechny nemocnice ZH KHK.

V průběhu realizace dodávky NIS může dojít ke změně předmětného systému. V době zahájení zadávacího řízení není znám dodavatel nového systému. Nový systém však bude architekturou

obdobný stávajícímu řešení a bude respektovat DICOM standard. Integrace NIS bude provedena se systémy provozovanými v době realizace integrace. Změna systému není důvodem pro změnu ceny realizace dodávky NIS“

• v bodě 2 Specifikace rozsahu implementace NIS je uvedeno:

„Nemocniční informační systém bude v rámci tohoto zadání pokrývat následující oblasti: PACS systém

• centrální úložiště

• DICOM prohlížeč“

Prosíme vysvětlit podrobně tyto body - hlavně zda je PACS systém součástí dodávky, co je to centrální úložiště a jaké vlastnosti má mít dodávaný DICOM prohlížeč? Jak to koresponduje s bodem

6.12 Konsolidace prohlížečů s možností vzdáleného přístupu a konzultací?

Odpověď na dotaz č. 3

PACS systém, vč. centrálního úložiště pro PACS data označovaného jako centrální úložiště, není součástí dodávky. PACS systém mají všechny nemocnice k dispozici. Vlastnosti požadovaného DICOM prohlížeče jsou popsány v kapitole 6.12. Konsolidací prohlížečů se rozumí jejich platformní a technologické sjednocení - v průběhu realizace může tedy dojít ke změně současného nemocničního klinického prohlížeče. Na dodávaný NIS jsou požadavky především na možnosti spolupráce s ev. řešením technologicky jiného řešení - např. spouštěním tenkého webového klienta.

Dotaz č. 4

V Příloze č. 3 ZD zadavatel uvádí v bodě 1.1: „Snaha o centralizaci systémů vyústila v úspěšnou realizaci v rámci laboratorních pracovišť (LIS Open LIMS Stapro) a v systému pro pracoviště zobrazovacích metod (Xxxxx PACS). Stejným způsobem pokračuje centralizace v systémech ERP (Navision, FEIS), MIS (FONS Reports) a technických systémech (FaMa, NeOS). Centralizace řešení přináší jednotnost řešení a lepší kontrolu nad náklady na systémy. Samotný nemocniční informační systém však zůstává roztříštěný a jeho současný stav je nevyhovující.“ Dále zadavatel uvádí v bodě 1.2.7 Manažerský informační systém (MIS): „FONS Reports (Stapro a.s.) Manažerský informační systém FONS Reports umožňuje čerpání a zpracování dat z různých provozních systémů. Pomocí FONS Reports lze sledovat reportingy systémem včasného varování, provádět okamžitou analýzu problémových dat a zjišťovat příčiny odchylek a neshod. V oblasti controllingu výkaznictví je modulem soustava přepočtů a reportingů dle nové úhradové vyhlášky. Tento modul umožní detailní analýzu parametrů a finančních aspektů vykázané péče. Dále poskytuje finanční hodnocení pro nové (aktuální) období a dokáže jej srovnat s referenčním období. Systém je využíván všemi nemocnicemi ZH KHK jako nástroj controllingu pro vedení holdingu.“

Dále zadavatel uvádí v bodě 5 POŽADAVKY NA PŘEVOD DAT Z PŮVODNÍCH SYSTÉMŮ v tabulce 10 požadavek náhrady ICZ AMIS*MIS bez převodu dat.

Znamená to, že má dodavatel nahradit v předmětné nemocnici stávající MIS novým (jakýmkoliv) manažerským systémem, nebo je již ICZ AMIS*MIS nahrazen systémem FonsReports, nebo má být dodáno napojení na FonsReports?

Odpověď na dotaz č. 4

Zadavatel v předmětné nemocnici požaduje pouze napojení na FONS Reports.

Dotaz č. 5

V dokumentu „Vysvětlení a doplnění zadávací dokumentace č. 3“, k dotazu č. 1 uchazeče zadavatel upravil znění čl. 4 odst. 8 návrhu Xxxxxxx o dílo, přičemž v novém návrhu Xxxxxxx o dílo, který je přílohou č. 1 dokumentu „Vysvětlení a změna zadávací dokumentace č. 5“ tato úprava nebyla promítnuta. Xxxxxxx žádá zadavatele, aby provedl změnu v čl. 4 odst. 8 přímo v návrhu Xxxxxxx o dílo.

Odpověď na dotaz č. 5

Viz odpověď na dotaz č. 1.

Dotaz č. 6 K „Vysvětlení zadávací dokumentace č. 3“, k dotazu č. 4 má uchazeč následující doplňující dotaz:

Chápe uchazeč správně, že součástí nabídky dle čl. 11.1. odst. 6 ZD má být kompletní Příloha č. 3 ZD

(Funkční specifikace) s vyplněnými částmi? Článek 10 Funkční specifikace (Požadavky zadavatele na maintenance) bude tak součástí Přílohy č. 1 Servisní smlouvy?

Odpověď na dotaz č. 6

Ano, dodavatel v souladu s článkem 11 odst. 11.1 bod 6. zadávacích podmínek vloží do nabídky funkční specifikaci vyplněnou na označených místech. Tuto přílohu vkládá do nabídky pouze jednou. S vybraným dodavatelem pak budou uzavřeny smlouvy, jejichž přílohou bude funkční specifikace předložená dodavatelem v nabídce. Konkrétně ve vztahu k servisní smlouvě bude vyplněná funkční specifikace její přílohou č. 1.

Dotaz č. 7

Je cena maintenance dle čl. 10 Funkční specifikace součástí ceny servisní podpory stanovené v příloze č. 2 Servisní smlouvy?

Odpověď na dotaz č. 7

Ano.

Dotaz č. 8

Předpokládá zadavatel, že součástí díla bude i provedení implementace produktu u dotčených organizací, jak jsou definovány v čl. 2 odst. 3 návrhu Xxxxxxx o dílo ve vazbě na dodávku licencí těmto dotčeným organizacím ve smyslu čl. 5 odst. 2 písm. a) návrhu Xxxxxxx o dílo?

Odpověď na dotaz č. 8

Ne. Jak vyplývá z článku 3 odst. 2 návrhu smlouvy o dílo, implementace proběhne pouze u dotčených nemocnic ve smyslu článku 2 odst. 4 návrhu smlouvy o dílo.

Dotaz č. 9

V kapitole 5 na straně 39 přílohy 3 ZD (Funkční specifikace) uvádí zadavatel v tabulce č.10 „Požadavky na převod dat z původních systémů Jičín“ požadavek na náhradu s převodem dat systému Depozita pacientů. Uchazeč žádá zadavatele o doplnění minimální specifikace vlastností systému Depozita, a to v zájmu nutnosti zachování rovných podmínek pro všechny uchazeče a z důvodů přesné specifikace rozsahu dodávaného předmětu díla, s dopadem na cenu díla.

Odpověď na dotaz č. 9

Program Depozita slouží pro evidenci finančních i věcných depozit pacientů. Pro každého pacienta lze založit libovolný počet finančních depozit. Každé depozito má v programu depozitní kartu pro vedení pohybů. Jednotlivé pohyby lze zadávat přímo do jednotlivých depozitních karet, nebo hromadně pomocí sestavy hromadného zadávání. Program obsahuje nejrůznější výběry a setřídění. Pomocí výstupních sestav pak lze získat různé inventury, příjmové a výdajové doklady, sestavu hromadných pohybů, sestavy hromadného příkazu k úhradě a inkasu. Program také umožňuje měsíční a roční uzávěrky.

Software dále umožňuje evidovat stav pacienta, na jehož základě mu svěřené prostředky jsou či nejsou vydány.

Přílohy č. 1 Návrh smlouvy o dílo platný ke dni 7. 12. 2017

č. 2 Funkční specifikace platná ke dni 7. 12. 2017

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění a změně zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů.

Lhůta pro podání nabídek nově končí 20. 12. 2017 v 10:00 hod.

Místo pro podání nabídek se nemění.

Za zadavatele na základě pověření

V Hradci Králové dne 7. 12. 2017

Centrum investic, rozvoje a inovací

Vysvětlení, doplnění a změna zadávací dokumentace č. 9

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení, doplňuje a mění zadávací dokumentaci veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1 Zadavatel uvádí v Příloze 3 ZD v bodě 2.1 Licenční ujednání mimo jiné:

„Dodavatel v rámci plnění předmětu této smlouvy realizuje pro zadavatele dílo podléhající ochraně podle zákona č. 121/2000 Sb., o právu autorském (autorský zákon), a zákona č. 89/2012 Sb., občanského zákoníku, a tak poskytuje zadavateli licenci, tj. oprávnění k výkonu práva užívat jím vytvořené autorské dílo. Dodavatel poskytuje licenci pro současnou práci na neomezeném počtu pracovních stanic zadavatele či dotčených organizací ve smyslu smlouvy o dílo (tzv. „unlimited

licence“).“

Dále Zadavatel uvádí:

„Licence k předmětu plnění nebo k jeho části, i licence třetích osob, nesmějí být omezeny počtem uživatelů.“

Prosíme o přesnou specifikaci maximálního počtu konkurentě (současně) pracujících uživatelů pro každou nemocnici. Pod pojmem maximální počet konkuretních uživatelů se myslí maximální počet v jeden okamžik připojených (pracujících) uživatelů (klientů) k aplikačnímu serveru dané nemocnice. Požadovaný údaj má zásadní vliv na cenu řešení, jelikož ceny technologie používané uchazečem přímo závisí na počtu současně pracujících uživatelů (počet pracovních stanic nemá vliv).

Odpověď na dotaz č. 1

Maximální počet uživatelů (licencí) není v rámci nemocnice omezen, což vyplývá i z článku 2 odst. 2.1 přílohy č. 3 zadávacích podmínek – Funkční specifikace. Z toho vyplývá, že počet konkurentně pracujících uživatelů je teoreticky roven počtu instalovaných licencí.

Dotaz č. 2

V příloze č. 3 ZD (Funkční specifikace), v kap. 4.1 (Komunikace s interními laboratořemi) zadavatel požaduje zajištění komunikace klinického informačního systému se stávajícím laboratorním informačním systémem Stapro OpenLIMS v tomto rozsahu:

 Možnost zobrazení laboratorního nálezu (výsledkového listu) ve formě podepsaného/označkovaného PDF/A dokumentu v klinickém informačním systému.

Xxxxxxx uvádí, že je zřejmé, že tvorba podepsaného PDF/A dokumentu není požadavek na poptávaný NIS, ale je to požadavek na LISy (laboratorní systémy), které však nejsou předmětem dodávky a požaduje se zachování stávajících LIS. V tom vidí uchazeč rozpor.

Xxxxxxx s ohledem na uvedené skutečnosti žádá zadavatele o vysvětlení:

1. Jedná se pouze o požadavek na zobrazení v NIS s tím předpokladem, že tento PDF/A dokument bude dodávat LIS (není předmětem dodávky) a jedná se tedy "pouze" o integraci pro přenos těchto dokumentů?

2. Pokud se jedná pouze o integraci, uchazeč žádá o dodání technické specifikace integračních rozhraní jednotlivých LIS" pro realizace těchto přenosů.

3. Uchazeč žádá o specifikaci, jakým způsobem budou realizovány součinnosti dodavatelů LISů.

Odpověď na dotaz č. 2

K dotazům dle písm. a) a b) zadavatel uvádí, že požadavkem dle článku 4 odst. 4.1 přílohy č. 3 zadávacích podmínek – Funkční specifikace (Komunikace s interními laboratořemi) je „zobrazení laboratorního nálezu ve formě PDF/A dokumentu v KIS“, nikoliv tvorba výsledkových listů.

Zadavatel požaduje možnost rychlého zobrazení PDF/A dokumentů LIS ze souborového ložiště přímo v dokumentaci pacienta. KIS musí umožnit uživatelskou definici cesty k úložišti PDF/A dokumentů. Odkaz do souborového úložiště bude do KIS předán v datovém rozhraní DASTA společně s formalizovanými výsledky pacienta.

K dotazům dle písm. c) zadavatel uvádí, že součinnost s dodavateli LIS pro komunikaci s interními laboratořemi zadavatel nepředpokládá. Jak vyplývá z odpovědí k dotazům dle písm. a) a b), tato součinnost nebude potřeba.

Dotaz č. 3

V příloze č. 3 ZD (Funkční specifikace), v kap. 6.1 (Minimální požadavky na klinický informační systém) uvádí zadavatel na str. 49 (Tisky) minimální požadavek na funkcionalitu:

 Systém bude umožňovat, aby správce nemocnice mohl tvořit vlastní tiskové sestavy pomocí standardního dotazovacího jazyka SQL s možností odvození vlastní sestavy z předdefinovaných (firemních).

Uchazeč se domnívá, že tento požadavek je v rozporu s obecnými požadavky na architekturu a bezpečnost celého systému. Požadavek na vytváření tiskových šablon pomocí nízko úrovňového SQL je z bezpečnostního pohledu a řízení přístupových práv velmi nebezpečný. Uchazeč žádá zadavatele, aby formulaci na minimální požadavek změnil takto: „Systém bude umožňovat, aby správce nemocnice mohl tvořit vlastní tiskové sestavy s možností odvození vlastní sestavy z předdefinovaných (firemních)“.

Odpověď na dotaz č. 3

Zadavatel trvá na stávajícím znění předmětného požadavku. Zadavatel si je vědom implikací požadovaného řešení.

Dotaz č. 4

V kap. 1.3.2 na straně 17 přílohy č. 3 ZD (Funkční specifikace) zadavatel uvádí, že v rámci analýzy bylo poukazováno na absenci propojení FEIS a LIS.

Uchazeč žádá zadavatele, pro vyloučení všech pochybností, o potvrzení, že tato integrace není součástí plnění veřejné zakázky.

Odpověď na dotaz č. 4

Integrace není součástí plnění veřejné zakázky.

Dotaz č. 5

V kapitole 2 na straně 28 přílohy 3 ZD (Funkční specifikace) uvádí zadavatel následující:

„Dále je požadovaná kontinuita nastavených parametrů, všech číselníků, definic tiskových sestav definice organizační struktury a jiných aspektů provozu. Nepředpokládá investici do opětovného zadávání a pořizování těchto údajů“.

Uchazeč žádá zadavatele, o přesnou specifikaci a výčet jednotlivých výše uvedených parametrů, které jsou předmětem dodávky (stačí v elektronické podobě), a to v zájmu nutnosti zachování rovných podmínek pro všechny uchazeče a z důvodů přesné specifikace rozsahu předmětu díla, s mimořádným dopadem na cenu dodávaného díla.

Odpověď na dotaz č. 5

Uvedené parametry budou upřesněný v rámci realizace zakázky individuálně vždy pro každou nemocnici. Dle zadavatele nemá specifikace parametrů mimořádný či jinak podstatný dopad na cenu dodávaného díla.

Dotaz č. 6

V rámci Vysvětlení a změna zadávací dokumentace č. 5, dotaz č. 2 a odpověď, si pro vyloučení všech pochybností chceme ujasnit, že uchazeč specifikuje v Plánu projektu postup řešení rozporu mezi dodavatelem a objednatelem.

Odpověď na dotaz č. 6

Postup řešení rozporu mezi dodavatelem a objednatelem je již uveden v návrhu jednotlivých smluv. Další podrobnější ujednání mohou být specifikována v Plánu projektu.

Dotaz č. 7

V rámci Vysvětlení a změna zadávací dokumentace č. 7 došlo ke změnám přílohy 3 Funkční specifikace – článku 5. Tato změna však má dopad rovněž na článek 6.5 Požadavky na řešení pro stravovací provoz neboť funkcionality Možnost provádět rozdílové propočty surovin v návaznosti na kolísání počtu klientů během dne, Předávání podkladů pro zúčtování a export do účetních a ekonomických systémů k dalšímu zpracování výsledků v rámci celé nemocnice, Funkcionalita umožňující pružně reagovat na nabídku trhu v souvislosti se sledováním cenové hladiny dodávaných surovin, jsou součástí Modulu stravovací provoz a ten se dle odpovědi č.1 nedodává. Požadujeme tedy vypuštění těchto funkcionalit a úpravu přílohy číslo 3 Funkční specifikace.

Odpověď na dotaz č. 7

Příloha č. 3 zadávacích podmínek - Funkční specifikace - byla upravena v souladu se změnou zadávací dokumentace. Zadavatel k tomu doplňuje, že smyslem článku 6 odst. 6.5 funkční specifikace je zajištění minimální úrovně komunikace dodávaného NIS se stávajícími stravovacími systémy.

Přílohy č. 1 Funkční specifikace platná ke dni 12. 12. 2017

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění a změně zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů.

Lhůta pro podání nabídek nově končí 21. 12. 2017 v 10:00 hod.

Místo pro podání nabídek se nemění.

Za zadavatele na základě pověření

V Hradci Králové dne 12. 12. 2017

Centrum investic, rozvoje a inovací

Vysvětlení zadávací dokumentace č. 10

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení zadávací dokumentaci veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1

V příloze 03 funkční specifikace je v bodě 2. Specifikace rozsahu implementace NIS uvedeno:

 Zajištění interoperability NIS v rámci „ekosystému“ celé ČR o Standardizovaná a automatizována obousměrná komunikace s jinými systémy (LIS, EIS, lékárna, MIS atd.)

o Standardizovaná a automatizovaná obousměrná komunikace s jinými subjekty (ZZS, externí ambulance, laboratoře, specializovaná zařízení atp.) Dále v bodě 4. Požadavky na komunikační vazby:

4.1 Komunikace s interními laboratořemi

Zadavatel požaduje zajištění komunikace klinického informačního systému se stávajícím laboratorním informačním systémem Stapro OpenLIMS v tomto rozsahu:

• Jednosměrná synchronizace registru laboratoře s registrem KIS tak, že změny v registru KIS jsou okamžitě promítány do registru laboratoře s upozorněním na rozpor mezi NIS a LIS.

• Synchronizace Dg mezi KIS na LIS.

• On-line synchronizace základních číselníků laboratoře s číselníky KIS, a to ve směru z laboratoře do KIS v rozsahu číselník metod včetně všech hodnotících mezí, číselník jednotek, seznam funkčních skupin a skupin metod, matice textových výsledků. Synchronizaci nesmí být pouze na základě rodného čísla nebo čísla pojištěnce, ale musí být shoda jak této položky, tak jména a příjmení.

• Ve směru z KIS do laboratoří bude on-line synchronizován seznam žadatelů, s ošetřením stavu, kdy žadatel nemá aktuální smlouvu s pojišťovnou

• Elektronická žádanka je distribuována z KIS a v laboratoři bude připravena ke zpracování v okamžiku jednoznačného spárování s materiálem. Materiál bude označen čárovým kódem. Při ordinování laboratorních vyšetření sledovat frekvenci a upozornit na její překročení. Upozornit na neshodu mezi Dg. a požadovaným vyšetřením. Upozornit na nemožnost ordinace zakázaných metod pro ambulantní pracoviště.

• On-line distribuce výkonů provedených v laboratoři do centrálního zpracování výkaznictví, tj. okamžitě po uvolnění výsledků jsou do KIS zapisovány i podklady pro vykázání zdravotní péče, včetně on-line Dobropisů a stornování chybně vykázané péče

• Možnost oboustranné komunikace s jinými zdravotnickými zařízeními

4.2 Další požadavky na komunikaci

 Systém bude komunikovat s ostatními IS nemocnice specifikovanými v tabulkách č. 9–12, které jsou uvedeny v následující kapitole.

Dotaz na zadavatele

Pro přesnou kalkulaci předmětu dodávky je nutné, aby dodavatel znal pro každý jednotlivý externí informační systém a každou jednotlivou službu, se kterou bude KIS komunikovat, přesnou specifikaci rozhraní a způsobu komunikace. Pokud se nejedná o průmyslové standardy jako je např. DICOM nebo HL7, dodavatel požaduje přesný popis protokolu, formátu datových vět (souborů). Dále u všech standardů nebo rozhraní přesně specifikovat které služby se budou pro který externí IS používat. Jaké verze se budou používat. Doplňte do tabulek č. 9–12 tyto náležitosti. A taky specifikujte všechny externí systémy, se kterými bude KIS komunikovat a nejsou uvedeny v tabulkách 9-12 podle bodu Zajištění interoperability NIS v rámci „ekosystému“ celé ČR.

Pro tento seznam také specifikujte všechny podrobnosti o protokolu, komunikačních službách formátu datových vět a jejich verzích.

Dále pro bod 4.1 komunikace s interními laboratořemi pro každý bod uvedený výše také specifikujte všechny podrobnosti o protokolu, komunikačních službách formátu datových vět a jejich verzích.

Odpověď na dotaz č. 1

Komunikace mezi LIS a NIS bude probíhat ve standartu DASTA 3.

Zajištěním interoperability NIS v rámci „ekosystému“ celé ČR se rozumí schopnost komunikace ve standardech používaných ve zdravotnictví v rámci České republiky. Jedná se o protokoly DASTA 3, ev. DASTA 4, HL7, DICOM. Zadavatel nepožaduje komunikaci nad rámec průmyslových standardů.

Předmětem požadavku je především zajištění komunikace mezi příslušnou nemocnicí, zdravotními pojišťovnami, Státním ústavem pro kontrolu léčiv, Ústavem zdravotnických informací a statistiky České republiky (B2B, e-preskripce, hlášení listu o prohlídce zemřelého, vrozené vady, potraty, onkologický registr atd.) dle aktuálně platné legislativy.

Zadavatel nepožaduje zajištění komunikace se systémy, které nejsou uvedeny v tabulkách 9– 12 v příloze 3 zadávacích podmínek - Funkční specifikace.

Dotaz č. 2

S ohledem na četnost dotazů a vysvětlení zadávací dokumentace, v rámci níž dochází k mnoha parciálním změnám jednotlivých částí ZD včetně návrhu smlouvy, žádáme o uveřejnění závazného konsolidovaného znění zadávací dokumentace včetně příloh se zohledněním všech dosavadních vysvětlení ZD a dále žádáme Zadavatele o adekvátní prodloužení termínu pro podání nabídek.

Odpověď na dotaz č. 2

Zadavatel k žádosti uvádí, že i vysvětlení, doplnění a změny zadávací dokumentace, jakožto samostatné dokumenty, jsou součástí zadávací dokumentace jako celku a jako takové závazně stanovují zadávací podmínky veřejné zakázky. V rámci každého doplnění či změny zadávací dokumentace, pokud to jejich povaha vyžadovala, provedl zadavatel přiměřené prodloužení lhůty pro podání nabídek. V případě přílohy č. 1 zadávacích podmínek – návrhu smlouvy o dílo a v případě přílohy č. 3 zadávacích podmínek – také při změně došlo k uveřejnění konsolidovaného znění těchto příloh.

Na profilu zadavatele a ve Věstníku veřejných zakázek, resp. v Úředním věstníku Evropské unie, uveřejněná zadávací dokumentace je zadávací dokumentací konsolidovanou ve smyslu dotazu a pro řádný průběh zadávacího řízení není potřeba její další úpravy. V souladu s tím je i žádost dodavatele o prodloužení lhůty pro podání nabídek nadbytečná. K přiměřenému prodloužení lhůty pro podání nabídek došlo v každém jednotlivém případě změny či doplnění zadávací dokumentace. Přesto zadavatel tímto uveřejněním přistoupil k prodloužení lhůty pro podání nabídek.

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů.

Lhůta pro podání nabídek nově končí 27. 12. 2017 v 10:00 hod.

Místo pro podání nabídek se nemění.

Za zadavatele na základě pověření

V Hradci Králové dne 15. 12. 2017

Centrum investic, rozvoje a inovací

Vysvětlení, doplnění a změna zadávací dokumentace č. 11

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení, doplnění a změnu zadávací dokumentaci veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1

V příloze č. 3 ZD (Funkční specifikace), v kap. 6.1 (Minimální požadavky na klinický informační systém) uvádí zadavatel minimální požadavek na funkcionalitu:

 Obousměrná synchronizace změn registrů pacientů mezi NIS a spolupracujícími systémy (minimálně laboratorní systém, PACS, manažerský systém), včetně přenosu náhradní identifikace cizince. Minimální rozsah navzájem přenášených akcí: nový záznam, oprava, zneplatnění, sloučení.

Xxxxxxx uvádí, že v kapitole 4 je požadována jednosměrná komunikace registrů mezi NIS a LIS a zde je uveden požadavek na obousměrnou komunikaci registrů. To je zjevný rozpor. Prosíme o přesnou specifikaci, zda je požadována jednosměrná a nebo obousměrná komunikace registrů. V případě obousměrné komunikace požaduje uchazeč jasný popis kompetenčních pravidel spolupráce mezi systémy NIS a LIS. Uchazeč dále uvádí, že požadovaná obousměrná synchronizace bez přesné specifikace předmětu plnění, tzn. připojovaných systémů, může znamenat velké cenové rozdíly při tvorbě návrhu řešení. Žádáme tedy zadavatele o specifikaci předmětu díla tak, aby byl xxx xxxxxxx výčet připojovaných systémů, určení kompetenčních pravidel a dodání přesné technické specifikace jednotlivých rozhraní.

Odpověď na dotaz č. 1

Zadavatel požaduje obousměrnou komunikaci a synchronizaci mezi NIS a LIS. Obousměrná komunikace spočívá zejména v možnosti odesílání žádanek z NIS a přijímání výsledků z LIS, PACS apod. Synchronizace spočívá v porovnání identifikačních údajů pacientů, tj. možnost zobrazení rozdílových sestav s možností opravy, vždy po vzájemném odsouhlaseni personálem. Přílohou tohoto uveřejnění je aktualizovaná příloha č. 3 zadávacích podmínek - funkční specifikace.

Dotaz č. 2

V odpovědi na dotaz číslo 9 Vysvětlení, doplnění a změna zadávací dokumentace č. 8 zadavatel, přes žádost o doplnění, nestanovil do přílohy č. 3 Funkční specifikace minimální specifikace pro systém Depozita. Upozorňujeme, že tato situace může vést k cenově neporovnatelným dodávkám řešení. Zároveň z odpovědi není zřejmé, zda tento systém v rámci dodávky jednotného Nemocničního informačního systému má být dodáván i do ostatních zdravotnických zařízení. Z odpovědi není zřejmé, zda se jedná o modul Nemocničního informačního systému nebo o modul Ekonomického informačního systému, což je z odpovědi pravděpodobnější. Tato skutečnost tedy ovlivňuje rozsah dodávaného řešení a rozšiřuje počet uchazečů o další dodavatele.

Opětovně žádáme zadavatele o Úpravu přílohy číslo 3 Funkční specifikace o následující:

1. Stanovení rozsahu dodávky systému Depozita. (Rozsah dodávky dle jednotlivých nemocnic nebo zadavatel v rámci jednotného Nemocničního systému chce dodávku pouze do Nemocnice Jičín ?), tak aby všichni uchazeči měli rovné podmínky.

2. Doplnění tabulky minimálních vlastností systému Depozita.

3. Pokud není součástí Nemocničního informačního systému, tak vysvětlení vazeb a rozhraní pro účtování a závěrky s ohledem na stávající Ekonomický informační systém, včetně požadované míry integrace.

4. Pokud je součástí Nemocničního informačního systému, tak vysvětlení vazeb a rozhraní pro účtování vzhledem k zdravotním pojišťovnám a úroveň integrace na stávající ekonomický informační systém.

Odpověď na dotaz č. 2

Zadavatel nepožaduje dodávku systému depozita. Z tohoto důvodu jsou další odpovědi na dotazy dodavatele irelevantní. Přílohou tohoto uveřejnění je aktualizovaná příloha č. 3 zadávacích podmínek - funkční specifikace.

Dotaz č. 3

Zadavatel v rámci dodávky NIS požaduje rovněž dodání modulu Lékové interakce, a to v plném rozsahu neomezené multilicence k produktu k užití objednatelem a dotčenými organizacemi. Jedná se o časově neomezenou multilicenci opravňující k neomezenému počtu přístupů objednatele a dotčených organizací ke všem funkcionalitám produktu provozovaného a spravovaného na zařízení objednatele a dotčených organizací.

Vzhledem k tomu, že jediným možným poddodavatelem požadovaného modulu Lékové interakce je v ČR společnost Drug AGENCY a.s., prosíme zadavatele, aby v rámci dodržení pravidel rovné soutěže zajistil všem účastníkům stejné cenové podmínky licencí a servisní podpory tohoto modulu, dále žádáme zadavatele o funkční specifikaci modulu lékové interakce a jejich zveřejnění, a to doplněním Přílohy č.3 ZD Technická specifikace.

Odpověď na dotaz č. 3

Na základě jednání s jediným potenciálním poddodavatelem předmětné databáze zadavatel potvrzuje, že disponuje čestným prohlášením poddodavatele o tom, že poskytne všem potenciálním dodavatelům shodné podmínky pro realizaci požadavků zadavatele ve vztahu k systému lékových interakcí.

Požadavky na modul lékových interakcí byly doplněny v článku 6 odst. 6.10 přílohy č. 3 zadávacích podmínek - Funkční specifikace, jejíž aktuální podoba je přílohou tohoto uveřejnění.

Dotaz č. 4

Zadavatel v Zadávacích podmínkách v rámci prokázání technických podmínek jednotlivými účastníky, vyzve jednotlivé účastníky k předvedení požadovaných funkcionalit nabízeného NIS – viz bod 7. Technické podmínky. Prosíme zadavatele o specifikaci počtu zúčastněných osob za účastníka a návrh detailního postupu pro ukázku např.bod 8. Názorná ukázka mobilní vizity.

Odpověď na dotaz č. 4

Počet osob zúčastněných při předvedení funkcionalit systému za účastníka není omezen. V rámci ukázky č. 8 – názorná ukázka průběhu mobilní vizity, prokazuje účastník naplnění základních požadavků stanovených v článku 6.8 funkční specifikace. Minimálně se jedná o následující úkony:

• zobrazení aplikace na mobilním dotykovém zařízení;

• zobrazení přístupu k dokumentaci pacienta;

• ukázka struktury zobrazovaných dat;

• ukázka zápisu informací do dokumentace pacienta skrze mobilní dotykové zařízení;

• ukázka zápisu multimediálního souboru do fotodokumentace pacienta přímo prostřednictvím mobilního dotykového zařízení;  ukázka ověření pacienta pomocí QR kódu.

Přílohy č. 1 Funkční specifikace (příloha č. 3 zadávacích podmínek)

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění a změně zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů.

Lhůta pro podání nabídek nově končí 2. 1. 2017 v 10:00 hod.

Místo pro podání nabídek se nemění.

Za zadavatele na základě pověření

V Hradci Králové dne 19. 12. 2017

Centrum investic, rozvoje a inovací

Vysvětlení zadávací dokumentace č. 12

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení zadávací dokumentaci veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1

Včera (19. 12. 2017, pozn. zadavatele) byla zadavatelem zveřejněna nová funkční specifikace – přílohač.3.:

Příloha č.3 je ve formátu PDF a nelze v ní provádět úpravy, prosíme zadavatele o zveřejnění přílohy č.3 ve formátu Word.

Odpověď na dotaz č. 1

Zadavatel k dotazu uvádí, že při každé změně přílohy zadávací dokumentace dochází k jejímu uveřejnění jak ve formátu PDF, tak v editovatelné podobě ve formátu DOCX.

Aktualizované přílohy jsou vždy uveřejněny na profilu zadavatele v sekci „Zadávací dokumentace“, tedy stejným způsobem, jako byly uveřejněny jejich původní verze ve smyslu § 99 odst. 1 zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen „zákon“). V popisu každé z příloh zadávací dokumentace je navíc uvedeno, na základě kterého uveřejnění došlo k jejich změně.

Zadavatel pro doplnění přikládá předmětnou přílohu v editovatelné podobě (DOCX) součástí tohoto uveřejnění.

Zadavatel dále upřesňuje odpověď na dotaz č. 4 v rámci vysvětlení, doplnění a změny zadávací dokumentace č. 11 ze dne 19. 12. 2017. Jedná se o stanovení minimálních úkonů názorné ukázky průběhu mobilní vizity (ukázka č. 8 ve smyslu článku 7 zadávacích podmínek).

V rámci ukázky č. 8 – názorná ukázka průběhu mobilní vizity, prokazuje účastník naplnění základních požadavků stanovených v článku 6.8 funkční specifikace. Minimálně se jedná o následující úkony:

• zobrazení aplikace na vlastním mobilním dotykovém zařízení účastníka;

• zobrazení přístupu k dokumentaci pacienta;  ukázka struktury zobrazovaných dat;

1

• ukázka zápisu informací do dokumentace pacienta skrze mobilní dotykové zařízení;

• ukázka zápisu a zobrazení multimediálního souboru do dokumentace pacienta přímo prostřednictvím mobilního dotykového zařízení;  ukázka ověření identifikace pacienta.

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že to povaha výše uvedeného vysvětlení a doplnění zadávací dokumentace ve smyslu § 99 odst. 2 zákona nevyžaduje, místo ani lhůta podání nabídek se nemění.

Zadavatel dále doplňuje, že žádost o vysvětlení byla doručena po lhůtě ve smyslu § 98 odst. 3 zákona. Zadavatel v takovém případě není povinen vysvětlení poskytnout.

Za zadavatele na základě pověření

V Hradci Králové dne 20. 12. 2017

Centrum investic, rozvoje a inovací

2

Vysvětlení a doplnění zadávací dokumentace č. 13

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení a doplnění zadávací dokumentaci veřejné zakázky na základě předchozí žádosti dodavatele.

Dotaz č. 1

Dodavatel zdvořile žádá o doplnění vysvětlení zadávací dokumentace č. 6 ze dne 30. 11. 2017:

V rámci dotazu č. 1 podotázky č. 2 Zadavatel potvrdil, že v rámci Požadavků na řešení pro obrazový komplement - Vytváření worklistu pro modality v PACS součástí dodávky jsou i úpravy na straně dotčených systémů. Zadavatel neodpověděl na otázku, zda jsou tyto náklady na straně dodavatelů dotčených systémů součástí nabídkové ceny (tedy zda za ně odpovídá dodavatel).

V rámci dotazu č. 2, podotázky č. 2 následně Zadavatel specifikoval, že součástí nabídkové ceny NEJSOU náklady na straně dodavatelů dotčených systémů a případné náklady na straně dodavatelů dotčených systémů nese zadavatel.

Může zadavatel potvrdit, že se tato odpověď č. 2 k podotázce č 2 vztahuje i na úpravy na straně dotčeného systému v rámci Vytváření worklistu pro modality v PACS?

Odpověď na dotaz č. 1

Zadavatel ve Vysvětlení zadávací dokumentace č. 6 v odpovědi podotázku č. 2 v rámci dotazu č. 1 zcela jasně potvrdil, že součástí dodávky jsou úpravy na straně dotčených systémů (minimálně stávající systém PACS) a součástí nabídkové ceny jsou případné náklady na straně dodavatelů dotčených systémů. Zadavatel trvá na své odpovědi, která byla zcela srozumitelná.

Odpověď „Ne“ ve Vysvětlení zadávací dokumentace č. 6 na podotázku č. 2 v rámci dotazu č. 2 se nevztahuje na vytváření worklistu pro modality v PACS.

Dotaz č. 2

Dosavadní vysvětlení zadávacích podmínek zásadním způsobem dopadají do cenotvorby a vytváření věcné části nabídky, kdy je nezbytné pro změněné zadávací podmínky vyžadovat nové obchodní nabídky u výrobců, případně provádět aktualizace tržních průzkumů, na což jsou posuny lhůty v řádu nižších jednotek dnů zcela nedostatečné a limitující pro možnost připravit nabídku. Některá vysvětlení potenciálně rozšiřují nebo zužují okruh subjektů, které jsou schopny nabídku podat. S ohledem na charakter dosavadních vysvětlení zadávací dokumentace provedených zadavatelem dodavatel žádá o dostatečné prodloužení lhůty pro podání nabídek za účelem zachování co nejširší hospodářské soutěže.

Odpověď na dotaz č. 2

Zadavatel k dotazu uvádí, že v rámci vysvětlení, doplnění a změn zadávací dokumentace nedošlo k takové změně či doplnění zadávací dokumentace, která by mohla rozšířit okruh možných účastníků zadávacího řízení ve smyslu § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v účinném znění.

Původní konec lhůty pro podání nabídek byl stanoven na 5. 12. 2017 v 10:00. Uveřejněním vysvětlení, doplnění a změny zadávací dokumentace č. 11 dne 19. 12. 2017 došlo k prodloužení lhůty pro podání nabídek do 2. 1. 2017. Zadavatel tak v rámci dosavadního průběhu zadávacího řízení prodloužil lhůtu pro podání nabídek o celých 28 kalendářních dnů.

Charakter jednotlivých dílčích změn či doplnění navíc v žádném z případů neovlivnil předmět veřejné zakázky podstatným způsobem, jelikož šlo zpravidla buďto o vysvětlení nejasného požadavku zadavatele či odstranění vnitřní nekonzistentnosti dílčí zadávací podmínky. Zadavatel si není vědom, a ani nemá informace od ostatních dodavatelů, že by kterékoliv dílčí prodloužení lhůty pro podání nabídek dle § 99 odst. 2 zákona neodpovídalo jeho povaze a mělo kterémukoliv dodavateli znemožnit přípravu řádné nabídky.

Dotaz č. 3

V čl. 11 odst. 5 zadávací dokumentace zadavatel uvádí, že dodavatel vyplní návrh smlouvy dle přílohy č. 1 a přílohy č. 2. Přílohou č. 1 ZD je návrh smlouvy o dílo s vyplněnými identifikačními údaji objednatele s tím, že smlouva může být dodavatelem doplněna pouze na označených místech.

Přílohou č. 2 ZD je návrh servisní smlouvy, která má být uzavřena s každým nemocničním zařízením samostatně a dodavatel je tak povinen do nabídky vložit čtyři návrhy servisní smlouvy. Servisní smlouva může být rovněž dodavatelem doplněna pouze na označených místech.

Ve vzoru servisní smlouvy, která je přílohou ZD jsou identifikační údaje objednatele nevyplněné a jsou označeny modře, tj. jako části smluv, které mají být doplněny zadavatelem.

S ohledem na výše uvedené uchazeč žádá, aby zadavatel uveřejnil závazné vzory servisní smlouvy pro každé nemocniční zařízení samostatně, tj. čtyři návrhy servisní smlouvy s vyplněnými identifikačními údaji jednotlivých nemocničních zařízení - objednatelů.

Odpověď na dotaz č. 3

Zadavatel doplňuje přílohu č. 2 zadávacích podmínek – Návrh servisní smlouvy o varianty s identifikačními údaji všech relevantních zadavatelů dle přílohy.

Místo a lhůta pro podání nabídek

Vzhledem k tomu, že dochází k doplnění zadávací dokumentace, prodlužuje zadavatel lhůtu pro podání nabídek v souladu s § 99 odst. 2 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v účinném znění. Místo podání nabídek se nemění.

Lhůta pro podání nabídek končí 5. 1. 2018 ve 12:00.

Zadavatel dále doplňuje, že žádost o vysvětlení zadávací dokumentace byla doručena po lhůtě ve smyslu § 98 odst. 3 zákona. Zadavatel v takovém případě není povinen vysvětlení poskytnout.

Za zadavatele na základě pověření

V Hradci Králové dne 27. 12. 2017

Centrum investic, rozvoje a inovací

Vysvětlení, doplnění a změna zadávací dokumentace č. 15

Veřejná zakázka Nemocniční informační systém Královéhradeckého kraje – software včetně zajištění podpory

Evidenční číslo VVZ Z2017-005540

Zadavatel jednající za všechny

Královéhradecký kraj, Xxxxxxxxxx xxxxxxx 0000, 000 00 Xxxxxx

zadavatele v rámci společného

Králové, IČO 708 89 546 zadávání

otevřené řízení veřejné zakázky na dodávky v nadlimitním

Způsob zadání režimu

Zadavatel poskytuje vysvětlení, doplňuje a mění zadávací dokumentaci veřejné zakázky bez předchozí žádosti dodavatele.

Zadavatel informuje potenciální dodavatele, že mu dne 27. 12. 2017 byly doručeny námitky proti zadávací dokumentaci ve smyslu § 242 odst. 4 zákona č. 134/2016 Sb., o zadávání veřejných zakázek.

Na základě rozhodnutí o námitkách dochází k doplnění přílohy č. 3 zadávacích podmínek – funkční specifikace (dále také jako „funkční specifikace“). Doplnění se týká tabulek č. 9–12 v článku 5 funkční specifikace, konkrétně pak poznámky ke sloupci „Ponechání s komunikací“. Poznámka (označená v tabulce jako „*)“) se doplňuje o následující text:

Komunikace je řešena prostřednictvím výměny souborů. U jednotlivých systémů označených A se jedná o přenosy základních informací typu – žádanka na vyšetření, požadavek na cenu léku v ústavní lékárně, osobní údaje – lékař sestra, k-dávky apod.

V žádném případě se nejedná o export složitých datových struktur včetně celé databáze.

Konkrétní specifikace vyměňovaných dat bude předmětem implementační analýzy. Dodavatel NIS je povinen zajistit export libovolné datové položky pro tento účel. Zajištění součinnosti třetích stran při napojení konkrétních systémů zejména formou poskytnutí obsahu a formátu datové věty zejména tam, kde se nejedná o standardizované protokoly, je pak povinností objednatele (zadavatele).

Zadavatel dále mění nesprávně uvedený požadavek uvedený v tabulce č. 11 Požadavky na převod dat z původních systémů Náchod v článku 5 funkční specifikace pro oblast „Laboratorní komunikace“. V původní podobě byl u této oblasti pro systém „IPU“ uveden požadavek na „Ponechání s komunikací“. Zadavatel však požaduje „Ponechání bez komunikace“. Tímto uveřejněním dochází k patřičné změně funkční specifikace.

Přílohou tohoto uveřejnění je funkční specifikace platná ke dni 10. 1. 2018.

Místo a lhůta pro podání nabídek

Lhůta pro podání nabídek končí 18. 1. 2018 v 10:00. Místo podání nabídek se nemění.

1

Za zástupce zadavatele na základě pověření

V Hradci Králové dne 10. 1. 2018

Centrum investic, rozvoje a inovací

2

1 Dle požadavků Vyhlášky č.116/2012 Sb. o předávání údajů do Národního zdravotnického informačního systému v § 1 a příloze vyhlášky.

2 Ve smyslu § 37 a § 56 zákona č.372/2011 Sb.

3 Primární definice dle zákona č.372/2011 Sb., o zdravotních službách, v platném znění, specifikace povinných registrů viz vyhláška č.116/2012 Sb. o předávání údajů do NZIS.

strana 1 z 11