Zadávací dokumentace – Příloha č. 3.b Část 1

Zkratky a pojmy užité v ZD jsou uvedeny v Příloze 3.a. ZD, specifické zkratky a pojmy poplatné zejména této části VZ jsou v následující tabulce.
Jedná se o podpůrnou informaci, kterou Zadavatel poskytuje pro zachování jednoznačného výkladu textu dokumentu.

Zkratka	Význam
SYSTÉM	V rámci tohoto dokumentu je pojmem SYSTÉM myšlen Informační systém Portál občana; Centralizace správy organizační struktury a přístupových práv; Aplikace podporující procesní řízení; Rozvoj ekonomického systému; Modernizace spisové služby; BI, manažerské nadstavby, dále také pojmenovaný zkratkou AIS
NIS	Nemocniční informační systém
DCK	Detailní cílový koncept
Fáze A	Implementace SYSTÉMU (nebo také dílo, nebo také projekt) v souladu se Smlouvou
Fáze B	Servisní (technická) podpora SYSTÉMU v souladu se Smlouvou
Smlouva	V rámci tohoto dokumentu je pojmem Xxxxxxx myšlena Příloha č. 4a. ZD
DPH	Daň z přidané hodnoty
IČ	Identifikační číslo
IS	Informační systém
OS	Operační systém
SW	Software
OSSZ	Okresní správa sociálního zabezpečení
ÚZIS	Ústav zdravotnických informací a statistiky ČR
SÚKL	Státní ústav pro kontrolu léčiv
NZIS	Národní zdravotnický informační systém
DASTA	otevřený český národní standard pro výměnu informací ve zdravotnictví
HL7	(Health Level Seven International) je set standardů
VREP	Veřejné rozhraní pro e – Podání na ČSSZ (OSSZ)
EZD	Elektronická zdravotní dokumentace

2Místo plnění

Je sídlo zadavatele: Voldušská 750, 337 22 Rokycany – specifikované v Zadávací dokumentaci

3Doba plnění

Dodávka jednotlivých částí bude zahájena po podpisu smlouvy příslušné části VZ a bude řízena milníky uvedenými v Tabulce 1 níže
Milníky Fáze A dané části VZ (implementace) dle Smlouvy.

Id	Činnosti		Termín
01	Podpis Smlouvy		Zadavatel předpokládá leden-únor/2019
Fáze A – Implementace SYSTÉMU
02	Zpracování a akceptace Detailního cílového konceptu Výstupem bude dokument Detailní cílový koncept Předání a Akceptace Detailního cílového konceptu		do 8 týdnů od podpisu Smlouvy
03	Dodávka licencí a instalace SW Předání dílčího plnění		do 2 týdnů po Id 02
04	Zkušební prostředí a produktivní provoz s podporou	Implementace zkušebního (testovacího) a produkčního prostředí Vytvoření testovací prostředí (vč. požadovaných rozhraní) Vytvoření produkčního prostředí (vč. požadovaných rozhraní) Akceptace Testovacího provozu	6 měsíců po Id 03
05	Zkušební prostředí a produktivní provoz s podporou	Produkční provoz s podporou Vytvoření produkčního prostředí (vč. požadovaných rozhraní) Akceptace produkčního provozu, akceptace Fáze A Ukončení Fáze A,	do 1 měsíce po Id 04

Fáze B – Servisní (technická) podpora SYSTÉMU dle Smlouvy bude zahájena ukončením Fáze A (ukončení projektu akceptací produktivního provozu s podporou).
Termín ukončení se může změnit z objektivních příčin, způsobených třetími stranami nebo jinými okolnostmi, nezávislými na vůli smluvních stran.

4Způsob prokázání splnění požadavků minimálního plnění

Zadavatel požaduje, aby Dodavatelem nabízená dodávka splňovala veškeré dále uvedené požadavky (funkcionality a parametry) a tyto byly zahrnuty v nabídce Dodavatele a v celkové nabídkové ceně.
Dodavatel ve své nabídce jednoznačně deklaruje splnění, popřípadě absenci každého níže uvedených požadavků v tabulkách označených jako „Minimální požadavky …“, a to vyplněním příslušného pole „Splněno“ jedno ze dvou nabízených možností:

„ANO“ v případě že dodávka Dodavatele (Nabídka) minimální požadavek splňuje

nebo „NE“ v případě že dodávka Dodavatele (Nabídka) minimální požadavek nesplňuje

Zadavatel požaduje po Dodavatelích, aby uvedli informaci o skutečné funkcionalitě nabízeného systému, kterou bude možné ověřit v nasazeném systému již v testovacím provozu (Testovací provoz, např. v rámci školení uživatelů a administrátorů).

Nesplnění kteréhokoli ze stanovených minimálních požadavků bude znamenat vyloučení účastníka ze zadávacího řízení.
Zadavatel požaduje, aby Dodavatel, kromě vyplnění tabulek v kapitole 5, podrobně popsal návrh nabízeného řešení v samostatné kapitole.
Tato kapitola 4 platí pro následující kapitoly 5 až 7.

5Požadavky na SYSTÉM

Dodávkou SYSTÉMU dojde k elektronizaci a integraci do stávajícího NIS zadavatele všech popisované funkcí.
Popis požadovaného rozsahu řešení je rozdělen do aktivit 1 a 2 specifikovaných v kapitolách 5.2 a 5.3

Aktivita 1 nové moduly nemocničního informačního systému;

Aktivita 2 stravovací systém;

v rozsahu:

dodávky licencí;
instalace aplikační a databázové části systému včetně vytvoření testovací instance;
iplementačních služeb:

provedení integrací na systémy v prostředí IS objednatele;
migrace dat do dodávaného řešení v aktivitě 2;
úpravy dodaného řešení dle potřeb a požadavků dle pokynů objednatele;
tvorba šablon/vzorů pro nově pořizované produkty;
zaškolení uživatelů a administrártorů;
testování;
podpory v předproduktivním provozu;

dokumentace:

k dodaným informačním systémům v požadovaném rozsahu;
k dodaným integračním rozhraním;
školící dokumentacek dodaným modulům NIS a stravovacího systému.

Zadavatel požaduje vytvoření a provoz dvou prostředí – produkčního a testovacího (školícího) po celou dobu nasazení u objednatele.

Zadavatel požaduje udržení testovacího prostředí po celou dobu udržitelnosti projektu (5 let od akceptace předmětu plnění).

5.1Společné vlastnosti řešení

Uvedené parametry a vlastnosti řešení v níže uvedené tabulce znamenají minimální míru plnění dle této ZD.

ID	Obecné principy a technologické vlastnosti	Splněno
01	Kompletní lokalizace aplikační části (tj. všech produktů z pohledu licencí) v českém jazyce, vč. dokumentace k předmětným licencím.
02	Plně elektronizované řešení, nahrazující v implementovaných oblastech papírový oběh dokumentů.
03	Logování operací – všechny kroky a operace prováděné v systému jsou ukládány, a je možné je zpětně dohledat / vyhledat a za konkrétního uživatele v daném období, tak za danou oblast / modul v daném období.
04	Administrace a konfigurace IS bez nutnosti zásahu zhotovitele a rozšíření licenčního modelu.
05	Vícevrstvá systémová architektura.
06	Řešení bude provozováno na principu tenkého klienta, tj. bez nutnosti instalace aplikace či podpůrného SW na lokálních stanicích uživatelů.
07	Řešení bude připraveno na provoz v rámci terminálového provozu.
08	Transakční zpracování dat v databázi na databázové platformě MS SQL (nutná kvůli kompatibilitě se stávajícími systémy).
09	Integrace mezi jednotlivými součástmi řešení SYSTÉMU bude realizována on‑line / synchronizace v reálném čase.
10	Řešení zajistí individuální nastavení pro uživatele podle jeho zařazení do organizační struktury zadavatele
11	Nativní integrace se systémem MS OFFICE (WORD, EXCEL, OUTLOOK), min verze 2010 a novější
12	Součástí nabídky budou zahrnuty veškeré náklady spojené se součinností stávajících dodavatelů systémů (tj. pořízení licence, součinnosti při implementaci a provozní náklady).
13	Administrátor přiděluje jednotlivým uživatelům přístupová práva. Základní přístupová práva pro uživatele dle jejich pracovního zařazení budou nastavena při implementaci dodavatelem programu. Systém umožní administrátorovi omezit přístupy k datům dle pracovních kompetencí – náhled / práce s daty.
14	Možnost konfigurace periodicky automaticky vytvářených reportů. Na základě žádosti uživatele a zadání vstupních podmínek dle typu sestavy dojde k off-line vygenerování sestavy, která bude následně zaslána uživateli, a to pravidelně za časový úsek daný periodou sestavy.
15	Uchazeč v nabídce podrobně popíše způsob integrace jím nabízených software komponent se systémy, se kterými je požadována integrace, v dostatečném detailu, který umožní posoudit praktickou možnost realizace navrhovaného technického řešení ve stanoveném harmonogramu
16	Nastavení všech parametrů SYSTÉMU bez nutnosti zásahu dodavatele.
17	Možnost vytváření vlastních konfigurovatelných sestav (reportů) ze všech zadávaných datových položek

5.2Aktivita 1 Nové moduly nemocničního informačního systému

NIS je stěžejním softwarovým nástrojem podpory provozu činnosti žadatele. NIS poskytuje výstupy uživatelům a je centrálním bodem sběru podnětů, žádostí a plnění činností ze strany jeho uživatelů.

Je také centrálním informačním systémem zajišťujícím zprostředkování a výměnu informací od žádanek, po elektronické výsledky jednotlivých vyšetření, včetně výstupů specializovaných zdravotnických přístrojů, po ekonomické nástroje sloužící k vykazování poskytnutých služeb žadatelem pojišťovnám s vazbou na ekonomiku organizace.

Nové funkce, respektive nové moduly rozšíří funkčnosti stávajícího informační systému a budou využívat integrační rozhraní stávajícího NIS.

5.2.1Komunikační modul pro výměnu zdravotnických a dalších informací

Komunikační modul zajistí rozšíření funkcionality nemocničního informačního systému o napojení na elektronickou preskripci (e-recept), evidenci použitých přístrojů v rámci vyšetření a sběr dat z těchto přístrojů, napojení na elektronickou zdravotnickou dokumentaci a její zpracování v koncových zařízeních, a to jak mobilních, tak stacionárních, rehabilitace, plánování léčebných procedur, odesílání dat pro OSSZ (e-neschopenka), napojení na portály zdravotních pojišťoven a statistických hlášení pro online vykazování vůči ÚZIS.

Nový modul bude zajišťovat přenos pro systém elektronické preskripce, který podporuje projekt eRecept (napojení na centrální úložiště SÚKL). Propojení na centrální úložiště bude mít následující funkce:

ověření recentní informace o léčivech předepsaných jinými lékaři;
ověření, zda si pacient jím předepsaný lék v lékárně vyzvedl;
informace o případné záměně léku lékárníkem při jeho výdeji;
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ř Centrálního úložiště;
další funkcionality spojené s opakovacím receptem a výpisy z receptů.

Komunikační modul dále zajistí rozšíření funkcionality nemocničního informačního systému o vystavování eNeschopenek. Po vygenerování a elektronickém exportu bude možné zajistit odeslán hlášení do registrů NZIS. Vzhledem k povinnosti poskytovatelů zdravotní péče podávat informace do registrů (NZIS) pouze v elektronické formě (přímým zápisem nebo na elektronickém nosiči), je hlavním požadavkem na nový modul NIS v této oblasti schopnost předávat data v podporovaném datovém standardu (DASTA, HL7) a umožňovat statistiky a třídění dat dle potřeb konkrétního subjektu, které záleží na struktuře poskytované péče. Pro hlášení do registrů (povinných i nepovinných) bude nezbytná spolupráce a součinnost odpovídajících datových rozhraní NIS.

Komunikační modul bude tedy nově zajišťovat nebo modernizuje (rozšíří rozsah předávaných informací) v těchto oblastech:

e Recept;
eNeschopenka;
B2B VZP – příslušnost pacienta ke zdravotní pojišťovně;
B2B VZP – autentizace lékaře;
napojení na ÚZIS – registry, které nemocnice povinně vyplňuje, evidence připojení přístrojů;

Uvedené požadované parametry a vlastnosti komunikačního modulu jsou specifikovány v níže popsané tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkcionality	Splněno
Požadované společné funkcionality komunikačního modulu
01	Výměna komunikačních formátů min. v rozsahu DASTA3, DASTA4, rozhraní ÚZIS, HL7, IHE profily a datové sady Emergency Health Record (EHR) a Pacient Summary (PS).
02	Napojení na eHealth systém Plzeňského kraje, který byl realizován v rámci kraje v prostředí Zdravotnické záchranné služby Plzeňského kraje, (ZZS Pk). Jedná se o výměnu informací o pacientech mezi zdravotnickými zařízeními a ZZS Pk, která bude reagovat na jeho plánovaný rozvoj
Funkcionalita eRecept
Modul 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 v rozsahu funkcí:
01	Odeslání elektronického receptu do centrálního úložiště
02	Změnu elektronického receptu uloženého v centrálním úložišti
03	Zrušení uloženého elektronického receptu v centrálním úložišti
04	Načtení výdejů léčivých přípravků na elektronický recept
Modul 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) v rozsahu funkcí:
05	Ověření recentní informace o léčivech předepsaných jinými lékaři
06	Ověření, zda si pacient jím předepsaný lék v lékárně vyzvednul
07	Informace o případné záměně léku lékárníkem při výdeji
08	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Ú
09	Odeslání elektronického receptu formou SMS a e-mailu
Fukcionalita eNeschopenka
01	Vystavení eNeschopenky v rámci práce v NIS.
02	Systém vytvoří komunikační nástroj (webová služba), který bude provádět přebírání „zásilek“ (šifrovaných dat) z jednotlivých zdravotnických zařízení, jejich odeslání kanálem VREP na ČSSZ a příjem odpovědí.
03	Systém zajistí příchozí „zásilky“ od ČSSZ (odmítnutá podání, chybové zprávy, potvrzení přijetí hlášení). Příchozí „zásilky“ rozšifruje a předá data NIS.
04	Pro řešení eNeschopenky nejsou vyžadovány elektronické podpisy jednotlivých lékařů, kteří eNeschopenky vystavují. Předpokládá se užití jednoho certifikátu společného pro všechny uživatele.
Funkcionalita B2B VZP - příslušnost pacienta ke zdravotní pojišťovně
01	Bude využita pro funkci on-line validace ČP v NIS služba informačního systému VZP
02	On-line validace čísla pojištěnce bude v NIS zapojena všude tam, kde je v praxi obvyklé provádění kontroly pojištění pacienta – jedná se o centrální registr pacientů a doklad pacienta.
03	Kontrola se bude provádět vždy pro konkrétního jednoho pacienta – funkce odešle do informačního systému VZP, který vede registr pojištěnců všech ZP, dotaz na konkrétní číslo pojištěnce
Funkcionalita B2B VZP – autentizace lékaře
01	Funkce pro on-line validaci registrace pacienta do ambulance bude zajišťovat kontrolu registrací jednoho konkrétního pacienta k ambulantním pracovištím, ke kterým je třeba se registrovat (obvodní lékaři, gynekologové apod.).
02	Systém umožní napojení na služby informačního systému VZP (synchronní B2B služby elektronické komunikace s klienty). Konkrétně se jedná o službu „Vyhledávání informace o registraci pojištěnce ke kapitaci“, která vrací informace, zda je pojištěnec se zadaným číslem pojištěnce k datu požadavku zaregistrován v kapitaci u poskytovatele zdravotní péče a u které zdravotní pojišťovny je pojištěn.
03	On-line validace kapitace bude zapojena tam, kde je v praxi obvyklé provádění kontroly registrací pacienta – jedná se především o registr pacientů resp. registr kapitací pacienta, dále pak ve formuláři Centrální evidence, Dokladu ZP a Nález.
04	Kontrola se bude provádět vždy pro konkrétního jednoho pacienta – funkce odešle do informačního systému VZP, který vede registr registrací, dotaz na konkrétní číslo pojištěnce. Následně VZP odpoví informací o příslušnosti pacienta k IČP a obdobím platnosti registrace. Pokud je pacient současně registrován do více ambulancí různých odporností, pak služba předá více informací o registracích. Tyto údaje jsou zobrazeny uživateli, který dotaz odeslal, aby mohl opravit příslušné záznamy v NIS.
Funkcionalita napojení na ÚZIS – registry, které nemocnice povinně vyplňuje, evidence připojení přístrojů
01	Systém generuje hlášení pro místně příslušný matriční úřad (hlášení narozených/zemřelých)
02	Možnost generování a elektronického exportu hlášení do registrů NZIS
03	Schopnost předávat data v podporovaném datovém standardu (DASTA, HL7)
04	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).

5.2.2Modul pro zpracování a výměnu elektronické zdravotní dokumentace

Implementací této funkcionality bude možné odstranit duplicitní listinnou administrativu, která vzniká sekundárně opisem nebo tiskem elektronicky vedených údajů, a to pouze jako právní doklad o provedené péči o pacienty.

Cílem řešení bude eliminace takové listinné dokumentace, kterou lze označit za samostatnou část zdravotní dokumentace pacienta a současně je možno ji vést v čistě elektronické podobě.

Funkcionalita jako modul nemocničního informačního systému umožní na jedné straně evidenci nových údajů u každého uživatele systému (informace o vydaných certifikátech a bezpečnostních předmětech) a na straně druhé sestavení množiny dat pro vytvoření elektronické zdravotnické dokumentace (data pro obsah dokumentu, metadata pro archivaci). Princip vytváření elektronické zdravotnické dokumentace bude uplatněn u takových dokumentů, které je dle platné legislativy jako plnohodnotné (podepsané dokumenty s povinností archivace) žadatel povinen vést.

Na každý takový dokument (např. ambulantní nález, konziliární zpráva apod.) budou aplikovány takové požadavky, které zajistí soulad s požadavky kladenými ze strany platné legislativy na čistě elektronicky vedenou zdravotnickou dokumentaci, tedy zejména následující:

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 zůstává zachován a zůstává čitelný.

Tato funkcionalita bude podporovat i vedení ošetřovatelské dokumentace.

Předpokládaný počet uživatelů v prostředí žadatele je 210 lékařů a sester. Licence pro žadatele co do počtu uživatelů musí být v oblasti elektronické zdravotnické dokumentace neomezená.

Pro nasazení funkcionality bude jako součást dodávky v prostředí žadatele nad systémovými prostředky vytvořen elektronický archiv, jehož licence musí být součástí dodávaného řešení.

Součástí dodávky bude 210 jednotek koncových zařízení pro přenos elektronických certifikátů pro možnost elektronického podepisování dokumentace zaměstnanci. Koncová zařízení budou kompatibilní s již používanými zařízeními popsanými v Příloze 3a „Popis současného stavu“.

Uvedené požadované parametry a vlastnosti modulu pro zpracování a výměnu elektronické zdravotní dokumentace jsou specifikovány v níže popsané tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkcionality	Splněno
01	Funkce 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).
02	Funkce generování a publikování jednoznačného identifikátoru záznamu do EZD.
03	Funkce prro vytvoření kvalifikovaného elektronického podpisu dle zákona splňující příslušnou technickou normu (PAdES), plná integrace s NIS
04	Systém musí mít k dispozici funkcionalitu pro EZD v modulech NIS: ambulance, lůžkové oddělení, radiologie, operační sály, rehabilitace
05	Automatické vynucení elektronického podepsání uzavíraného zápisu elektronické zdravotnické dokumentace elektronickým podpisem uživatele
06	Předávání elektronicky podepsaných dokumentů do elektronického archivu včetně metadat ve formě OAIS SIP pro dlouhodobou archivaci.
07	Zajištění správy a evidence kvalifikovaných podpisových certifikátů uživatelů a kvalifikovaných prostředků elektronického podepisování.
08	Dodání 210 jednotek - koncových zařízení pro přenos elektronických certifikátů
09	Dodávka HW úložiště konstruované pro dlouhodobou archivaci elektronické zdravotnické dokumentace (bezpečný hardwarový archiv) Parametry: - Programově nastavitelné retenční lhůty na archivovaný objekt - Mechanismus interní kontroly konzistence souborů a korekci chyb na bitové úrovni - Automatická relokace vadných datových bloků - Podpora replikací dat do fyzicky jiné lokality v případě existence záložního úložiště - Automatická kontrola stavu svých komponent a schopností zasílání varovných upozornění v případě statisticky významného výskytu závad - Vzdálený monitoring provozního stavu - Počáteční hrubá kapacita úložiště je 4 TB s montáží do 19“ serverového stojanu - Vysoká míra redundance komponent (pevné disky, napájecí zdroje, ventilátory, síťová rozhraní LAN/SAN, řadiče, procesory) - Servisní podpora úložiště je 5 let

5.2.3Modul pro vedení ošetřovatelské dokumentace a podpora procesů v rámci rehabilitace

Implementací této funkcionality dojde k elektronizaci podpory práce v oblasti ošetřovatelské dokumentace. Elektronizace této agendy tak přispěje k úplnosti zdravotnické dokumentace v elektronické podobě vedené v samotném NIS.

Funkcionalita ošetřovatelské dokumentace bude obsahovat funkce, které umožní vést dokumentaci vedenou sestrami při hospitalizaci pacienta. Jde především o možnost zadání potřebných údajů při popisu ošetřovatelské anamnézy pacienta, hodnocení rizik, práci s ošetřovatelským plánem, zadání údajů do propouštěcí, resp. překladové ošetřovatelské zprávy, vedení denních ošetřovatelských záznamů o pacientovi, hodnocení rizik pádů, dekubitů, ADL, test soběstačnosti a nutriční screening u dětí i dospělých.

Dále bude funkcionalita umožňovat vedení pacientské dokumentace na rehabilitačním oddělení a zároveň bude umožňovat systém vedení a plánování procedur jako přímá součást systému s návazností na centrální registr pacientů NIS.

Implementací funkcionality bude vytvořeno ucelené řešení pro fyzioterapie – provázanost lékařské dokumentace, naplánování procedur, zápisy fyzioterapeutů.

Lékař bude moci prostřednictvím funkcionality zadat strukturovaně ordinované procedury s vyznačením jejich pořadí, četnosti a opakování s vazbou pro plánování procedur.

Uvedené požadované parametry a vlastnosti modulu pro vedení ošetřovatelské dokumentace a podporu procesů v rámci rehabilitace jsou specifikovány v níže popsané tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkcionality	Splněno
01	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í.
02	Automaticky dotahovat již známé údaje o pacientovi v NIS do ošetřovatelské dokumentace.
03	Na základě problémů v ošetřovatelské anamnéze a zhodnocených rizik mít možnost nastavit automaticky příslušné ošetřovatelské diagnózy a intervence do plánu péče.
04	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.
05	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.
06	Při plánování procedur systém podpoří: možnost hromadného objednání, svázání objednávek, možnost nastavení standardních skupin procedur, kontrolu možné četnosti dle metodiky VZP, možnost přihlédnout k přání pacienta, kdy chce procedury absolvovat.
07	Systém umožní pracovat s pacientem ambulantním i hospitalizovaným.
08	Systém zajistí přehledné zobrazení vytíženost pracovišť, strojů.
09	Bude umožněno automatické vykázání potřebných výkonů po odcvičení.
10	Systém bude obsahovat statistiky a přehledy: vyhodnocování počtů 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. Systém umožní vytváření vlastních konfigurovatelných sestav (reportů) ze všech zadávaných datových položek.
11	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ů.
12	Systém umožní statisticky sledovat vykázané výkony, resp. platby pacientů.
13	Systém umožní jednoduchou 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í.
14	Budou umožněny jednoduché změny v naplánovaných procedurách s evidencí důvodu změny (nemoc pacienta apod.)

5.2.4Modul mobilní vizita

Funkcionalita zajistí možnost prostřednictvím aplikace z mobilního zařízení (tabletů) přistupovat k datům z NIS v rámci vizity a tato data upravovat a doplňovat. Data budou zpracovávána ve formě elektronické zdravotnické dokumentace.

Tato funkcionalita musí úzce spolupracovat se stávajícím nemocničním informačním systémem – využívat v něm uložené aktuální informace o pacientech při prováděné vizitě.

Při vizitě u lůžka pacienta bude mít lékař prostřednictvím této funkcionality k dispozici administrativní údaje pacienta, jeho anamnézy, diagnózy, laboratorní výsledky, zprávy z konzilií, žádanky a operační protokoly. Součástí funkcionality bude náhled na aktuální informace včetně medikace a jejich historii, ale i aktivní zadávání či změna ordinovaných léků, včetně infuzí. Lékař bude mít proto prostřednictvím této funkcionality v mobilním zařízení plnohodnotný nástroj k provedení vizity, včetně možnosti zápisu denního dekurzu. Veškerá 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. Obdobně každá změna v dokumentaci, nový laboratorní výsledek, zpráva a další budou okamžitě dostupná i v takovém mobilním zařízení prostřednictvím této funkcionality.

Pro užití funkcionality bude využito stávající Wi-Fi sítě žadatele na jednotlivých odděleních organizace.

Požadovaný minimální počet uživatelů pro nasazení u žadatele je 50.

Pro možnost užívání tohoto modulu bude dodáno 20 ks tabletů s požadovanou minimální konfigurací:

ID	Požadavky na funkcionality 20 ks tabletů	Splněno
01	Procesor - Jakýkoliv procesor, který je dostatečný pro plynulý chod operačního systému Windows 10
02	Paměť RAM - min. 2GB
03	Rozlišení -- min.1280x800
04	Display 8“
05	Paměť pro systém - min. 16GB
06	Operační systém - Windows 10
07	Framework - .net Framework 4.0
08	Zařízení pro pohodlné držení tabletu
09	Možnost připojit čtečku chipových karet

Uvedené požadované parametry a vlastnosti modulu mobilní vizita jsou specifikovány v níže popsané tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkcionality	Splněno
01	Veškerá pořízená data pomocí dotykového zařízení budou ukládána přímo do dokumentace pacienta a budou tedy okamžitě přístupná pro další personál.
02	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.
03	V rámci ř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ů, infúzí za podpory databáze lékových interakcí
04	Požaduje se ověření identifikace pacienta pomocí scanu čárového či QR kód čtečkou v mobilním zařízení.
05	Systém umožní 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.
06	Přístup do aplikace bude chráněn autentifikací uživatele.

5.3Aktivita 2 Stravovací systém

V rámci realizované funkcionality bude realizován jeden společný stravovací provoz, v rámci, kterého budou vytvářeny tři samostatné výdejky – pro pacienty, pro zaměstnance a doplňkový prodej.

Stravovací systém bude dodán s požadovaným počtem 5 přístupových licencí a níže popsanými moduly.

Pacientská strava

Funkcionalita informačního systému bude zajišťovat automatické stahování stavů, které jsou zapsány v NIS dvěma způsoby:

celkové počty diet za oddělení
podrobnosti o dietách jednotlivých pacientů.

Hlášené stavy z oddělení si přebere stravovací kancelář. Na základě stažených stavů provede přenormování spotřeby na aktuální stavy a zjištění rozdílů.

Zaměstnanecká strava

Výdej zaměstnanecké stravy bude probíhat na základě objednávek zaměstnanců.

Integrace stravovacího systému

Stravovací systém bude napojen na nemocniční informační systém pro zajištění automatizovaného předávání objednaných jídel dle diet pacientů na jednotlivých odděleních (FONS Enterprise), dále bude napojen pro vykazování vydané strany (nejen zaměstnanců) pro provedení srážek ze mzdy do stávajícího ekonomického systému Helios a stávajícího personálního systému UNICOS. Rozhraní do ekonomického a personálního systému jseu uvedeny v Příloze 3a této ZD.

Uvedené požadované parametry a vlastnosti stravovacího modulu jsou specifikovány v níže popsané tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkcionality	Splněno
01	Možnost objednávek diet dle údajů ve zdravotnické dokumentaci pacienta – automatizovaná sestava za oddělení/stanici.
02	Možnost provádět několikrát denně automatizovaný sběr hlášení z oddělení.
03	Systém zajistí přehled receptur, diet a jídelní lístky. Všechny data bude možné upravovat (změna používaných surovin, cenové výkyvy, apod.) tak, aby byla vždy strava připravována podle představ personálu stravovacího provozu.
04	Systém umožní sledování nutričních ukazatelů stravy, mohou být do systému nahrány suroviny s NU. Nahrané suroviny je možné pak opravit a použít při sestavení receptur.
05	Evidence receptur umožní v členěných provozech nezávislou údržbu bez ovlivňování původních hodnot v jídelníčcích (resp. v normování).
06	Evidence jídelníčků bude podporovat cyklické opakování i neustálou tvorbu nových jídelníčků. Při tvorbě jídelníčku bude k dispozici informace o nejbližším použití receptury v dané dietě.
07	Systém poskytne uživatelům stravovacího provozu přehled o objednaných dietách podle diet a druhů jídla se všemi podrobnostmi až po konkrétní jídla a jejich ceny. Bude možné nastavit si dny, vybrané diety a co uživatele zajímá (objednávky, diety, ceny, výdaje za jídlo, DPH, ceny,...). Ceny receptur, jídel, diet budou rozlišeny na ceny bez DPH a s DPH, bude možné sledovat ceny režie a případně další typy cen. Cena jídla (aktuální) bude vypočtena jako předběžná cena podle aktuálních cen surovin ve skladě.
08	Systém umožní provedení objednávky stravy strávníkem prostřednictvím objednávkového místa nebo webové aplikace. Na objednávkovém místě se strávník identifikuje pomocí „klíče“ v podobě objednávkového ID média (čipová karta), do webové aplikace se strávník přihlásí přihlašovacím jménem a heslem.
09	Objednávky strávníků budou evidovány v samostatné funkcionalitě. Každý strávník bude mít vytvořen samostatný debetní nebo kreditní účet, na který budou zaznamenávány objednávky stravy konkrétního strávníka. Dále bude umožněno na samostatných účtech evidovat příspěvky zaměstnavatele a příspěvky FKSP.
10	Po uplynutí účetního období bude provedena uzávěrka. Výstupem z uzávěrky budou tiskové sestavy odebrané stravy po jednotlivých strávnících za zadané období, přehled vyúčtování zaměstnaneckého příspěvku a FKSP a soubor pro srážku z mezd za stravu v dohodnutém datovém.
11	Skladová evidence stravovacího provozu bude vedena ve vlastním skladu společném pro oba provozy v průměrných cenách bez DPH, výstupy budou uváděny v cenách bez DPH. Příjemky do skladu budou prováděny ruční editací, výdejky pro stravovací provoz budou automaticky generovány na základě požadavků stravovacího provozu.
12	V rámci dodávky budou dodány minimálně následující tiskové sestavy: Havarijní sestava (přehled objednávek strávníků na den pro jídlech), Počet objednávek za období po dnech a jídlech (export do Excelu), Srážky ze mzdy zaměstnanců za stravu, Vyúčtování příspěvků zaměstnavatele a FKSP.
13	Komunikace se mzdovým systémem UNICOS – export srážek ze mzdy za stravu formou umístění exportního souboru dat ve formátu CSV do definovaného exportního dresáře, ze kterého se ručně bude exportní soubor importovat do mzdového systému. Komunikace s ekonomickým systémem HELIOS – export skladové uzávěrky do ekonomického IS. Komunikace s NIS FONS Enterprise – automatické hlášení požadavků stravy z oddělení. Automatický přenos vybraných informací o pacientech (diety, přídavky, poznámka). Automatický přenos jídelníčku do NIS.

6Fáze A – Implementace SYSTÉMU

Implementace SYSTÉMU bude provedena v jednotlivých požadovaných krocích a termínech uvedených v kapitole 3.

Minimální požadavky na Implementaci SYSTÉMU jsou uvedeny v následující tabulce.

Id	Plnění požadavku	Splněno
01	Zpracování Detailního cílového konceptu
02	Dodávka licencí
03	Implementace Zkušebního (Testovacího) prostředí, včetně požadovaných vazeb
04	Školení uživatelů a administrátorů informačního systému
05	Implementace Produkčního prostředí, včetně požadovaných vazeb a realizace Produkčního provoz s podporou

6.1Zpracování a akceptace Detailního cílového konceptu

Dokument Detailní cílový koncept bude obsahovat minimálně:

analýzu současného stavu a bude vycházet z popisu současného stavu, viz Příloha 3.a. ZD;
definici cílového stavu, která bude vycházet z požadavků na budoucí stav, viz tento dokument a bude doplněna Dodavatelem o analýzu současného stavu prováděnou pracovníky Dodavatele v aktuálních podmínkách Zadavatele;
návrh řešení instalace aplikační a databázové části systému (architektura technického řešení) detailní popis nastavení – konfigurace a parametrizace jednotlivých oblastí (společné registry, role a přístupová oprávnění, číselníky, reporty atd.);
návrh technického řešení integračních vazeb (vazby mezi moduly, vazby na aplikace, vazby na zdravotnické registry a informační systémy);

návrh řešení postupu a pořadí při nasazování jednotlivých agend – upřesnění harmonogramu projektu, který bude vycházet z milníků uvedených v kapitole 3 a z Dodavatelem navrženého Harmonogramu projektu;

popis případných organizačních opatření nutných pro implementaci;
rozsah součinnosti ze strany objednatele;
akceptační kritéria cílového stavu
Realizační (prováděcí) projekt - podrobný popis realizace dané části VZ.

Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává dokument Detailní cílový koncept) a Akceptačním protokolem dílčího plnění, kterým Zadavatel akceptuje splnění podmínek této části Fáze A ve Smlouvě.
Dokumentace skutečného nasazení bude připomínkována Zadavatelem a připomínky budou ze strany Dodavatele vypořádány (tj. zapracovány, případně s jasným a konkrétním písemným zdůvodněním odmítnuty jako nevalidní).

6.2Dodávka licencí

Objednatel požaduje v rámci plnění dodávku takového počtu uživatelských licencí, který zajistí legální provoz a využití informačního systému ze strany uživatelů, a to jejich dále uvedeném počtu a skladbě.
Z pohledu licencování bude uchazeč respektovat požadavek, že v případě potřeby či nutnosti využití podpůrných licencí potřebných k provozu předmětu plnění (např. run-time licence), budou takové licence v poměru 1:1 s licencemi samotných produktů.
Uchazeč nesmí v průběhu realizace zakázky či v době udržitelnosti projektu, nebo v případě podepsání nové smlouvy navazující na předmět plnění dle této smlouvy, vůči uchazeči změnit licenční podmínky tak, že by došlo k navýšení či generaci finančního závazku vůči zadavateli.

Část	Dodávka licence minimálně pro počet uživatelů	Max. počet současně pracujících uživatelů
Nové moduly nemocničního informačního systému
Databázové prostředí kompatibilní se stávajícím NIS – MS SQL Verze standard umožňující běh softwarů třetích stran.	Licence pro 3 fyzické virtualní servery, každý se 4 jádry	260
Komunikační modul pro výměnu zdravotnických a dalších informací	5	260
Modul pro zpracování a výměnu elektronické zdravotní dokumentace	1	260
Modul pro vedení ošetřovatelské dokumentace a podpora procesů v rámci rehabilitace	1	260
Bezpečný elektronický archív	1	260
Modul mobilní vizita	50	50
Stravovací systém		5
Modul pacientské stravy	1	-
Modul zaměstnanecké stravy	1	-
Modul komunikace na ekonomický a personální systém	1	-

Bude-li součástí licenčního modelu SYSTÉMU i „run-time“ (běhové prostředí), pak Zadavatel očekává takovou licenční politiku, která bude splňovat minimální požadavky Zadavatele na licenci SYSTÉMU.
Zadavatel vyžaduje splnění licenční politiky u „run-time“ (běhového prostředí) dle bodu 4) potvrzením, prohlášením či jiným osvědčením od autora (vlastníka) těchto licencí v případě, že je vlastník těchto licencí odlišný od Dodavatele.
Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává SW licence SYSTÉMU).

6.3Implementace Testovacího a Produkčního prostředí

Dodavatel vytvoří dvě prostředí:

Testovací prostředí

v rozsahu dle DCK,
které na infrastruktuře Zadavatele připraví Dodavatel,
s využitím testovacích dat a rozhraní.

Testovací prostředí bude sloužit zejména pro testování nastavení, migrací, rozhraní apod. a dále proškolení uživatelů a administrátorů a získávání praxe uživatelů a administrátorů na testovacím prostředí.

Produkční prostředí

v rozsahu dle DCK,
které na infrastruktuře Zadavatele připraví Dodavatel,
s využitím produkčních dat a rozhraní.

Produkční prostředí bude sloužit jednak k Testování a Akceptaci a dále k produkčnímu provozu.

Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává Testovací prostředí a Produkční prostředí) a Akceptačním protokolem dílčího plnění, kterým Zadavatel akceptuje splnění podmínek této oblasti ve Smlouvě.

6.4Produkční provoz s podporou

Implementace Produkčního provozu s podporou bude v rozsahu dle DCK.
Produkční provoz s podporou bude probíhat na produkčním prostředí, a to dle jednotlivých implementovaných celků SYSTÉMU,.
Jeho účelem je zjistit, zda jsou splněny akceptační podmínky uvedené v tomto dokumentu a v DCK, včetně ověření funkčnosti veškerých vazeb se všemi provázanými subsystémy a ověření relevantnosti migrovaných dat v reálném provozu.
V průběhu Produkčního provozu s podporou může docházet k dílčím úpravám SYSTÉMU tak, aby nedocházelo k omezení dané funkcionality.
Pokud dojde v průběhu Produkčního provozu s podporou k závadám, které omezí funkcionality plnění, prodlužuje se doba Produkčního provozu s podporou o stejnou dobu, po kterou nebylo plnění funkční (bez vad).
Formálně bude Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem (Dodavatel předává plnění dle Smlouvy) a Akceptačním protokolem, kterým Zadavatel akceptuje splnění podmínek Fáze A ve Smlouvě.

6.5Předání a převzetí plnění

6.5.1Předání a převzetí dokumentů

Dokumenty, které mají být vypracovány Dodavatelem a které se poskytují Zadavateli jako součást poskytování díla, budou nejdříve předloženy Zadavateli ve formě návrhu k posouzení.
Zadavatel je oprávněn ve lhůtě pěti (5) pracovních dnů od doručení příslušného dokumentu písemně předložit Dodavateli své připomínky k návrhu.

Po diskusi o těchto připomínkách upraví Dodavatel příslušný návrh v souladu s dohodnutými změnami a se zapracováním těchto dohodnutých změn jej předá ve stejné lhůtě pěti (5) pracovních dnů Zadavateli.
V případě, že Zadavatel nemá k předaným dokumentům výhrady, považují se za převzaté k okamžiku doručení jejich konečné verze Zadavateli.
V případě, že Xxxxxxxxx připomínky ve lhůtě pěti (5) dnů nepředloží, má se za to, že s předloženým dokumentem souhlasí a dokument se považuje za řádně převzatý.

Dodaná dokumentace v rámci SYSTÉMU slouží k zachycení a vyhodnocování plánovaných činností a též k dokumentaci skutečného stavu.

Minimální požadavky na dokumentaci SYSTÉMU jsou v níže uvedené tabulce.

Id	Plnění požadavku	Splněno
01	Součástí prací bude vytvoření kompletní a detailní dokumentace.
02	Dokumentace nebude chráněna dle autorského zákona, bude umožněno ji dále upravovat a předávat dalším subjektům, které se podílejí na chodu informačních systémů.
03	Dodavatel předloží plán tvorby dokumentace (jako součást Detailního realizačního projektu).
04	Dokumentace bude v elektronické formě, ve formátu PDF
Detailní cílový koncept
05	Úvodní seznámení s funkcionalitami dodávaného SYSTÉMU pro členy projektového týmu Zadavatele.
06	Kompletní analýza řešení problematiky SYSTÉMU a jeho implementace v prostředí Zadavatele, včetně integračních vazeb na okolní systémy a aplikace.
07	Podrobný popis způsobu a rozsahu implementace SYSTÉMU včetně realizace odpovídajících integračních vazeb.
08	Návrh zátěžových, funkčních, integračních (akceptačních) testů SYSTÉMU.
09	Detailní harmonogram realizace zakázky SYSTÉMU vycházejícího z Milníků uvedených v ZD.
Realizační dokumentace SYSTÉMU
10	Bude zpracována kompletní implementační a provozní dokumentace v písemné i elektronické editovatelné podobě ve formátu MS Office, včetně popisu pravidelné údržby a dokumentace finálního provedení, zahrnující, krom jiného, i detailní popis rozhraní.
11	Bude zpracována dokumentace finálního vyhotovení SYSTÉMU včetně detailního popisu všech rozhraní. Součástí dokumentace bude i detailní popis API rozhraní testovacího i produkčního prostředí SYSTÉMU pro napojení aplikací třetích stran.
12	Pro podporu uživatelů a administrátorů budou zpracovány: uživatelské příručky metodické pokyny popisy procesů administrátorská příručka

6.5.2Předání a převzetí ostatních plnění dle Smlouvy (vyjma služeb)

V případě, že součástí poskytování plnění Dodavatelem dle Xxxxxxx je plnění, které podléhá akceptaci Zadavatelem, musí dojít k podpisu Předávacích protokolů ohledně tohoto plnění v termínech uvedených v harmonogramu, není-li výslovně uvedeno jinak.

Detailní kritéria akceptace a vymezení plnění, která podléhají akceptaci Zadavatelem, jsou uvedena v tomto dokumentu, případně v Detailním realizačním projektu.
Jestliže plnění nebo jeho jednotlivé části splní kritéria akceptačního řízení, považují se za řádně ukončené a Zadavatel je povinen jej převzít.

Akceptační procedury zahrnují porovnání skutečných vlastností plnění se závaznou specifikací předmětu plnění dle Smlouvy.

Akceptační procedura bude zahrnovat akceptační testy, které budou probíhat na základě specifikace akceptačních testů obsahující popis testů, testovací data, příslušné prostředí, pořadí provádění testů a akceptační kritéria.

Nedohodnou-li se smluvní strany jinak, vypracuje specifikaci akceptačních testů Dodavatel a předá Zadavateli k odsouhlasení v termínu pěti (5) pracovních dnů před zahájením akceptační procedury dle harmonogramu.

Odsouhlasení bude provedeno písemnou formou v termínu pěti (5) pracovních dnů před zahájením akceptační procedury. Jestliže se Zadavatel v této lhůtě ke specifikaci akceptačních testů písemně nevyjádří, má se za to, že specifikaci akceptačních testů odsouhlasil.

Jestliže Zadavatel specifikaci akceptačních testů v uvedené lhůtě neodsouhlasil, je povinen Zadavatel v této lhůtě sdělit připomínky k Dodavatelem předložené specifikaci akceptačních testů a poskytnout Dodavateli veškerou potřebnou součinnost k dokončení a odsouhlasení specifikace akceptačních testů.

Lhůta pro provedení akceptačních testů a lhůta pro předání plnění nebo jeho části se prodlužuje o dobu, o kterou se prodloužilo písemné odsouhlasení specifikace akceptačních testů z důvodu připomínek na straně Zadavatele oproti lhůtě stanovené.

Dodavatel bude písemně informovat Xxxxxxxxxx, resp. jeho oprávněné osoby nejméně pět (5) dní předem o termínu zahájení akceptačních testů.

Zadavatel je oprávněn se těchto testů zúčastnit a osvědčit jejich konání, a to formou předávacího protokolu (nebo dílčích předávacích protokolů), podepsaného (podepsaných) oprávněnými osobami obou smluvních stran. Pokud se Zadavatel nedostaví v termínu určeném pro provedení akceptačních testů, ačkoli byl s tímto termínem řádně seznámen, je Dodavatel oprávněn provést příslušné akceptační testy bez jeho přítomnosti.

Takto provedené akceptační testy se považují za provedené v přítomnosti Zadavatele. Kopie veškerých dokumentů vypracovaných v souvislosti s provedením těchto akceptačních testů budou Zadavateli poskytnuty do pěti (5) dnů.

Základním předpokladem pro řádné předání plnění (nebo jeho části) Dodavatelem a převzetí tohoto plnění (nebo jeho části) Zadavatelem, a to formou předávacího protokolu podepsaného oprávněnými osobami obou smluvních stran je skutečnost, že plnění splní kritéria akceptačních testů uvedená v dohodnutých kontrolních specifikacích a bude provedeno v souladu se závaznou specifikací předmětu plnění dle Smlouvy.
Jestliže plnění nebo jeho část splní akceptační kritéria akceptačních testů, Dodavatel se zavazuje v den následující po ukončení akceptačních testů umožnit Zadavateli plnění nebo jeho část převzít a Zadavatel se zavazuje v tomto termínu plnění nebo jeho část převzít.

Pokud Zadavatel plnění nebo jeho část v tomto termínu nepřevezme, ačkoli převzetí plnění nebo jeho části bylo Dodavatelem řádně umožněno, má se za to, že plnění nebo jeho část bylo řádně předáno a Zadavatelem převzato právě v den následující po ukončení akceptačních testů.

Jestliže plnění nesplňuje stanovená akceptační kritéria kteréhokoliv akceptačního testu, budou výsledky akceptačního testu (splněno/nesplněno/s výhradami) spolu s uvedením termínů pro nápravu uvedeny ve vyhodnocení Akceptačního protokolu.

Dodavatel napraví tyto nedostatky a příslušné akceptační testy budou provedeny znovu.

Tento proces testování a následných oprav se bude opakovat, přičemž výše uvedená ustanovení se použijí obdobně.

Proces testování a následných oprav lze opakovat, dokud Dodavatel nesplní veškerá akceptační kritéria pro příslušný akceptační test, nejvýše však natřikrát (3x).

V situaci, kdy by bylo nutné opakovat akceptační testy více jak třikrát (3x) pro konkrétní fázi projektu, je v takovém případě nutný souhlas nadřízeného orgánu projektu – tzn. řídícího výboru nebo ředitelů projektu dle použité metodiky řízení projektu.

Žádný akceptační test se však nebude považovat za nesplněný, jestliže daný nedostatek nebyl způsoben Dodavatelem, nebo byl zjištěn nebo měl být zjištěn Zadavatelem před nebo při předcházejícím akceptačním testu, ale nebyl v té době oznámen Xxxxxxxxxx, nebo byl nepodstatný, tzn., neměl vliv na řádné poskytování funkčnost díla nebo jeho části tak, jak jsou vymezeny ve Smlouvě.
Při převzetí plnění nebo kterékoliv jeho části v souladu s tímto článkem je Zadavatel povinen podepsat potvrzení o přijetí plnění nebo dané části a Zadavatel i Dodavatel se zavazují podepsat příslušný předávací případně akceptační protokol (dílčí předávací případně akceptační protokoly), tj. potvrzení o předání a přijetí (převzetí) plnění nebo jeho určité části.

6.5.3Migrace dat SYSTÉMU

Migrace dat v rámci Akivity 1není relevantní. V rámci Aktivity 2 se požaduje převod základních číselníků a provozních dat.

6.5.4Rozhraní SYSTÉMU

Všechna externí rozhraní informačního systému musejí být vystavěna nad standardizovanými a dokumentovanými službami, které umožní změnu systému na jedné nebo druhé straně rozhraní pouhou změnou konfigurace na systémové úrovni takového rozhraní (nový certifikát a adresa stroje, portu); i v případě datových pump a předávání dat formou strukturovaných dokumentů požaduje objednatel zajištění dokumentace takové výměny dat a její standardizaci (dodržení např. XML nebo standardních databázových řešení).

Součástí realizovaného informačního systému bude i otevřené, co do popisu a způsobu fungování, a dostatečně zabezpečené rozhraní, které umožní přístup a výměnu informací s dalšími informačními systémy (třetích stran).

Prostřednictvím takového rozhraní bude možné přistupovat k celému rozsahu dat zpracovávaných objednatelem jeho prostřednictvím.

Samotné rozhraní bude zdokumentované na úroveň výměny jednotlivých informací, jejich podoby a rozsahu.

Rozhraní bude v rámci informačního systému snadno administrovatelné správcem informačního systému objednatele tak, aby na základě dodané dokumentace mohl povolit a nastavit přístup třetí straně samostatně bez součinnosti zhotovitele.

V rámci administrace rozhraní bude mít dále správce informačního systému objednatele jednoduchým způsobem možnost volit individuálně podle každého konkrétního napojeného systému třetí strany, ke kterým datovým sadám a v jakém konkrétním rozsahu bude mít systém třetí strany přístup.

Součástí dodávky bude i dokumentace tohoto rozhraní, kterou bude objednatel oprávněn předat neomezenému okruhu dalších subjektů, za účelem možnosti napojení na dodávaný informační systém. Dokumentace rozhraní bude natolik podrobná, aby umožnila napojení systému třetí strany administrátorem objednatele a programovými úpravami výhradně v informačním systému třetí strany bez jakékoliv potřeby součinnosti zhotovitele tohoto informačního systému. Popis jednotlivých rozhraní bude muset být zpracován tak detailně, aby umožňoval objednateli jeho předání třetí straně, která na základě popisu bude schopna vytvořit bez jakékoliv součinnosti zhotovitele odpovídající protikus rozhraní v plném rozsahu a jeho spuštění bude odvislé pouze na povolení komunikace ze strany informačního systému. Takový popis rozhraní bude muset obsahovat minimálně technologii, kterou je rozhraní realizováno, popis jednotlivých datových typů a struktur, se kterými rozhraní pracuje, a způsob, kterým má být prostřednictvím rozhraní komunikováno.

Dokumentaci rozhraní bude povinen zhotovitel udržovat aktuální a v rámci ní udržovat platný popis veškerých rozhraní informačního systému a databází, se kterými je provázán. Taková dokumentace bude vedena až na úroveň popisu konkrétního způsobu práce rozhraní s daty a uvedení všech jednotlivých datových typů a jednotlivých položek, se kterými pracuje.

V případě napojení systému třetích stran prostřednictvím těchto konektorů nebude Zadavateli účtována žádná dodatečná licence spojené s investiční či provozní platbou. Rozhraní SYSTÉMU na stávající IS.

6.5.5Technologické prostředí

Instalace SYSTÉMU a jeho nastavení dle objednatele odsouhlasené dokumentace skutečného nasazení bude provedena na hardware a software Objednatele. Z tohoto důvodu bude v rámci předimplementační analýzy definován skutečný rozsah HW/SW podpůrných komponent, na které se bude předmět plnění dle tohoto dokumentu implementovat.

Objednatel požaduje v rámci plnění také instalaci a nastavení testovací (školící) instance, která bude obsahovat iniciální naplnění anonymizovanými / testovacími daty, bude mít nastavena přístupová oprávnění pro uživatele a bude sloužit k ověření funkčnosti řešení a pro možnost školení a testování systému ze strany jeho uživatelů.

6.5.6Integrační vazby na stávající systémy

Objednatel požaduje v rámci plnění realizaci integračních vazeb na okolní prostředí a to min. v níže uvedeném rozsahu.

Uchazeč na své náklady provede komplexní realizaci rozhraní a to včetně nákladů na straně stávajících dodavatelů systému (licence, práce, servisní poplatek).

Předmětná realizace rozhraní bude individuálně projednána v rámci zpracování Realizačního projektu, v rámci kterého budou podrobněji definovány integrační prvky za každý konektor.

Oblast	Vazba do aplikace / systému stávajícího programového vybavení /registru/systému státu	Vazba do aplikace / nově pořizovaného modulu
Komunikační modul pro výměnu zdravotnických a dalších informací	ÚZIS SÚKL VZP B2B kanál Stávající NIS FONS Enterise	Modul pro vedení ošetřovatelské dokumentace a podpora procesů v rámci rehabilitace
Modul pro zpracování a výměnu elektronické zdravotní dokumentace	Stávající NIS FONS Enterise	Modul pro vedení ošetřovatelské dokumentace a podpora procesů v rámci rehabilitace Modul mobilní vizita Bezpečný elektronický archív
Modul pro vedení ošetřovatelské dokumentace a podpora procesů v rámci rehabilitace	Stávající NIS FONS Enterpise – lůžkový modul, centrální registr, pojišťovna, ÚZIS	Modul pro zpracování a výměnu elektronické zdravotní dokumentace Komunikační modul pro výměnu zdravotnických a dalších informací
Modul mobilní vizita	Stávající NIS FONS Enterprise, LIS FONS OpenLIMS	Modul pro zpracování a výměnu elektronické zdravotní dokumentace
Stravovací systém	Stávající NIS FONS Enterprise, EIS Helios, IS UNICOS	Ne

Rozsah jednotlivých rozhraní a jejich prostřednictvím na sebe navazujících funkcionalit jednotlivých systémů budou ve své konkretizaci obsahem dokumentace skutečného provedení viz kapitola Error: Reference source not found.

6.5.7Školení

Dodavatel poskytne školení pro uživatele a administrátory IS tak, aby všichni pracovníci Zadavatele byli schopni řádně užívat, respektive administrovat, instalovaný SYSTÉM.
Dodavatel poskytne školení tak, aby pracovníci Zadavatele získali další znalosti praktického využívání SYSTÉMU jako efektivní podpory procesů u Zadavatele, znalosti související a aktuální legislativou a jejími připravovanými změnami, znalosti metodické, tj. aby došlo k významnému přenosu znalostí a zkušeností z Dodavatele na Zadavatele.

7Fáze B – Servisní podpora SYSTÉMU, SLA

Požadavky, které musí Dodavatel minimálně naplnit na Servisní podporu SYSTÉMU jsou v níže uvedené tabulce.

Id	Plnění požadavku	Splněno
01	Dodavatel zajistí, že veškeré vlastnosti díla, včetně jeho update, legislativního update, upgrade a legislativního upgrade budou po celou dobu účinnosti této smlouvy odpovídat vždy aktuálním obecně platným právním předpisům ČR a platným standardům rozhraní na zdravotnické registry a informační systémy.
02	Úpravy programového vybavení SYSTÉMU (obecné, rozvoj, legislativa apod.) zajistí s dostatečným časovým předstihem před nabytím účinnosti konkrétního právního předpisu, minimálně 5 pracovních dní.
03	V rámci běžného rozvoje jednotlivých modulů SYSTÉMU Dodavatel zajistí poskytnutí aktualizovaných verzí nejpozději do 3 měsíců po uvolnění nové verze k distribuci.
04	Budou poskytovány informace o změnách a nových funkcích v aktualizovaných verzích SYSTÉMU.
05	Bude prováděna průběžná aktualizace dokumentace k programovému vybavení tak, aby u Zadavatele byla vždy aktuální dokumentace k provozovanému SYSTÉMU.
06	Bude poskytována součinnost při zásadním upgrade operačního systému a databázového systému na vyšší verze.
07	Bude zajištěna udržitelnost SW třetích stran, dodaných Dodavatelem v rámci veřejné zakázky.
08	Servisní (Technická) podpora a servis budou poskytovány po celou dobu smluvního vztahu (min 60 měsíců ode dne protokolárního ukončení projektu dle Smlouvy).
09	Technická podpora a servis zařízení SW budou realizovány Dodavatelem, případně prostřednictvím odpovídajícího servisního kanálu výrobce.
10	Technická podpora a servis budou realizovány v místě Zadavatele. Výjimku tvoří činnosti realizované vzdáleným připojením Dodavatele do prostředí Zadavatele.
11	Veškeré požadavky budou evidovány v systému servisní podpory Dodavatele (HelpDesk).
12	Kontaktní místo umožní příjem požadavku na servisní zásah v českém jazyce prostřednictvím služby HelpDesk, popř. služby Hot-line.
13	Služba Hot-Line umožní příjem požadavku na servisní zásah v českém jazyce na telefonním čísle v režimu 5x8 (8 hodin v pracovní dny) v době od 08:00 do 17:00 hod, příjem požadavku bude zajištěn lidskou obsluhou.
14	Služba HelpDesk umožní příjem požadavku na servisní zásah v českém jazyce prostřednictvím webového rozhraní v režimu 7x24 (nepřetržitě vyjma nahlášených servisních zásahů Dodavatele při správě systému HelpDesk).
15	Služba HelpDesk bude Zadavateli poskytovat přehled o aktuálně nahlášených požadavcích, jejich stavu a aktuálním způsobu jejich řešení. Služba HelpDesk bude Zadavateli zasílat notifikace o změně stavu jeho požadavku (např. zadaný, v řešení, uzavřený atd.) a musí Zadavateli umožnit schvalování uzavření nahlášeného požadavku.
16	Služba HelpDesk bude poskytovat Zadavateli přístup i k uzavřeným požadavkům a způsobu jejich řešení, bude poskytovat podrobné údaje o historii požadavků od jejich nahlášení, po jejich vyřešení.

V rámci zajištění podpory a servisu po dobu udržitelnosti projektu platí následující parametry SLA.
Definice stupňů závažnosti incidentů:

Závažnost Závady nebo Chyby		Definice závažnosti Závad a Chyb
A	Kritická chyba	Chyba způsobí, že poskytovaný SYSTÉM nelze zcela provozovat nebo má kritický vliv na provozované aplikace či stav podporovaného systému – vyžaduje okamžité řešení.
B	Urgentní chyba	Chyba výrazně omezuje správnou funkcionalitu SYSTÉMU lze provozovat s omezením nebo po určitou dobu ve formě náhradního řešení.
C	Chyba	Nekritická Chyba SYSTÉMU – provoz je problémem ovlivněn, ale lze provozovat bez výrazného omezení.
D	Námět na vývoj	Námět na vývoj bude předán Dodavateli prostřednictvím nástroje HelpDesk. Dodavatel bude tyto náměty vyhodnocovat a dle plošného přínosu do následujícího sestavení. Dodavatel má právo předmětné náměty odmítnout.

Definice maximální doby nástupů k řešení incidentů podle závažnosti:

Závažnost Chyby	Doba zahájení činnosti (od nahlášení)	Doba odstranění chyby	Řešení
A	2 pracovní hodiny	8 pracovních hodin	a
B	4 pracovní hodiny	12 pracovních hodin	a, b
C	6 pracovních hodin	32 pracovních hodin	a, b
D	podle dohody	podle dohody	c

Řešením se rozumí:

Odstranění Chyby SYSTÉMU. Opravy Chyb bude provádět Dodavatel do Aktualizované verze (kritické chyby ihned).
Poskytnutí přijatelného náhradního řešení problému ze strany Dodavatele.
Poskytnutí informace o akceptování/neakceptování námětu k zapracování do budoucích verzí.

Sankce za nedodržení výše uvedených termínů:

Za každou započatou hodinu překročení mezních termínů chyb v kategoriích A, B, C 500 Kč.

Strana 1

Document Metadata

Table of Contents

Zadávací dokumentace – Příloha č. 3.b Část 1

Document Metadata