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

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
PACS	Picture Archiving and Communication System. Jedná se o technologii používanou v zobrazování v medicíně
DASTA	otevřený český národní standard pro výměnu informací ve zdravotnictví
DICOM	Digital Imaging and COmmunications in Medicine je univerzálním formátem, který umožňuje prohlížení a sdílení medicínských dat
HL7	(Health Level Seven International) je set standardů

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 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í dílčího plnění a Akceptace dílčího plnění – detalního cílového konceptu.		do 4 týdnů od podpisu Xxxxxxx
03	Dodávka licencí a instalace SW Předání dílčího plnění		do 8 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	4 měsíce po Id 02, 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

Zadavatel v současné době provozuje centrální systém PACS (napojeny všechny modality nemocnice) a další související moduly (komunikace s NIS, worklist, správa systému PACS a obrazových vyšetření), vč. DICOM prohlížečů obrazové dokumentace. Veškerá obrazová vyšetření z jednotlivých modalit jsou ukládána do centrálního systému. Odtud běží centrálně i veškerá komunikace s nemocničním informačním systémem a klinické DICOM prohlížeče. Serverová část systému je provozována ve virtuálním prostředí nemocnice. Veškeré moduly jsou certifikovány jako „Zdravotnický prostředek třídy IIb“.

Vzhledem k použitým technologiím není možný zabezpečený operativní přístup k vyšetřením a sdílení vyšetření v diagnostické kvalitě. Stávající technologie neumožňují online konzultace vyšetření, nebo vytvoření vzdáleného popisu. Veškerá funkcionalita pro práci s vyšetřením je vázána na diagnostické prohlížeče instalované na konkrétních stanicích (funkce pro diagnostiku a popis vyšetření).

Dodávkou SYSTÉMU dojde k rozšíření stávajícího PACS zadavatele všech popisovaných funkcí.
Popis požadovaného rozsahu řešení je specifikován v kapitole 5.2.

v rozsahu:

dodávky licencí;
instalace aplikační a databázové části systému;
iplementačních služeb:

provedení integrací na systémy v prostředí IS Zadavatele;
úpravy dodaného řešení dle potřeb a požadavků dle pokynů Zadavatele;
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í dokumentace.

5.1Společné vlastnosti řešení

Předmětem řešení je dodávka a implementace nových funkcionalit (modulů) systému PACS do virtualizované technologické platformy Zadavatele.

Nová funkcionalita umožní zobrazení obrazové zdravotnické dokumentace v diagnostické kvalitě a dále umožní vytvoření popisu takové obrazové dokumentace pouze v prostředí webového prohlížeče bez nutnosti instalace dodatečného programového vybavení na koncové zařízení. Popis vyšetření bude možné odeslat do NIS.

Součástí rozšířené funkcionality bude možnost sdílení obrazové zdravotnické dokumentace s dalšími zdravotnickými subjekty bez nutnosti odeslání celých vyšetření z archivu nemocnice a online konzultace v reálném čase.

Veškerá komunikace v rámci této rozšířené funkcionality bude šifrována a veškeré akce budou logovány.

Cílem rozšířené funkcionality PACS bude zajištění řízeného zabezpečeného přístupu k obrazové zdravotnické dokumentaci odkudkoliv z internetu a sdílení obrazových dat jak v rámci nemocnice, tak i s externími pracovníky a dalšími odbornými pracovišti v čase potřebném pro poskytnutí kvalitní zdravotní péče.

Nabízené řešení musí obsahovat veškeré požadované funkcionality a musí vyhovovat plně minimálním požadavkům zadavatele. Účastník předvede na základě výzvy zadavatele funkční prototyp nabízeného řešení (minimálně v rozsahu webového DICOM prohlížeče). Účelem předvedení funkčního prototypu a jeho prezentace je ověření funkcionalit nabízeného řešení a způsobu plnění minimálních požadavků zadavatele, tzn. prokázání splnění požadavků zadavatele na funkcionalitu řešení.

Obecné vlastnosti požadovaného rozšíření funkcí systému PACS

ID	Principy a technologické vlastnosti	Splněno
01	Všechny části systému musí být integrované a modulárně koncipované
02	V rámci implementace musí uchazeč zajistit plnohodnotný provoz dodávaného řešení současně s provozem stávajících systémů. To vše bez jakéhokoliv omezení provozu. Xxxxxxx je povinen přizpůsobit realizaci předmětu zakázky podmínkám zadavatele.
03	Aktualizace dodaného řešení bude v souladu s legislativou nejpozději ke dni účinnosti legislativní změny po dobu udržitelnosti v rámci servisní podpory.
04	Veškeré nabízené SW i HW prvky musí být plně kompatibilní se stávajícím systémem PACS (XXXXX PACS).
05	V případě, že uchazeč nabídne řešení, jehož součástí bude náhrada jakékoliv části stávajícího řešení, uchazeč předloží subdodavatelskou smlouvu se servisní organizací stávajícího řešení, která bude zajišťovat potřebnou součinnost při přechodu na nové řešení.
06	Soubor dodaného aplikačního programového vybavení, tzn. všechny nabízené SW moduly, musí být certifikován jako „Zdravotnický prostředek třídy IIa nebo vyšší“ v souladu se zákonem č. 268/2014 Sb., o zdravotnických prostředcích, nařízením EU MDD 93/42/EEC a nařízením vlády č. 54/2015 Sb.,

Diagnostický webový DICOM prohlížeč

Webový prohlížeč elektronické obrazové dokumentace bude obsahovat následující vlastnosti a funkcionality.Uvedené parametry a vlastnosti řešení diagnostického webového DICOM prohlížeče v níže uvedené tabulce znamenají minimální míru plnění dle této ZD.

ID	Principy a technologické vlastnosti	Splněno
01	Architektura server-klient.
02	Provoz klientské části bude nezávislý na operačním systému pracovní stanice pouze v prostředí standardního webového prohlížeče/browseru bez nutnosti instalace dalšího SW (aplikací, modulů, appletů či knihoven), tedy bez použití např. ORACLE Java, Microsoft .NET FrameWork, Adobe Flash, apod.
03	Řešení bude splňovat ověřenou kompatibilitu s nejrozšířenějšími webovými prohlížeči/browsery – minimálně s MS Internet Explorer (v. 11 a vyšší), Mozilla Firefox, Apple Safari, Chrome, a to na 32bit i 64bit platformě.
04	Řešení bude podporovat zobrazení na různých koncových zařízeních zařízení – PC, notebook, tablet, smart phone apod.
05	Serverová část SW musí být nativní 64-bit. aplikací (aplikace nelze provozovat na 32-bit. nebo starší platformě), klientskou část musí být možné provozovat na 32-bit. i 64-bit. platformě.
06	Systém bude kompatibilní se standardem DICOM verze 3.0.
07	Systém bude podporovat DICOM služby: Query/Retrieve, Store.
08	Systém umožní připojení neomezeného počtu různých zdrojů obrazových dat, např. možnost přímého odesílání obrazových dat z modalit do centrálního prohlížeče, napojení libovolného počtu DICOM archivů různých výrobců.
09	Systém umožní zabezpečený přístup přes síť Internet odkudkoliv i mimo areál nemocnice s podporou HTTPS certifikátu.
10	Webový prohlížeč musí umožňovat centrální správu uživatelských účtů a nastavení jednotlivých uživatelských profilů nebo skupin.
12	Centrální prohlížeč musí umožňovat autentizaci uživatelů při spouštění prostřednictvím Active Directory a řízení oprávnění na úrovni role a pracoviště uživatele.
13	Systém bude napojen na stávající NIS minimálně v rozsahu: zobrazení textového popisu vyšetření v prostředí prohlížeče (vždy je načítán aktuální textový popis z NIS a tento textový popis se neukládá do PACS), komunikaci, formát přenášených dat, licence a související implementační služby je povinen zajistit uchazeč v rámci zajištění součinnosti dodavatele NIS FONS Enterprise (dodavatel Stapro s.r.o.).
14	Systém musí umožňovat zpětné dohledání přístupu konkrétního uživatele k dané obrazové dokumentaci nebo pacientským datům po celou dobu životního cyklu řešení, tato funkcionalita musí být zákaznicky dostupná prostřednictvím přehledného nastavení (např. přes HTML formulář).
15	Systém musí obsahovat podporu uživatelsky editovatelných klávesových zkratek, tlačítek myši.
16	Systém musí obsahovat podporu automatického znovunačtení seznamu nalezených vyšetření.
17	Systém musí obsahovat funkce pro zobrazení všech vyšetření pacienta ze všech připojených zdrojů dat na časové ose, možnost filtrace zobrazovaných vyšetření na časové ose min. v rozsahu: volba řazení od nejstaršího/nejmladšího vyšetření, filtrace typu modality, stáří vyšetření, klíčová slova.
18	Systém musí obsahovat podporu pro vytváření a zobrazení DICOM SR (Structured Report).
19	Systém musí obsahovat podporu zobrazení medicínských zpráv v jiných formátech - součástí vyšetření může být i výsledek vyšetření v pdf (dodatečně naimportovaný, „DICOMizovaný“ a připojený k vyšetření ve formátu DICOM).
20	Systém musí obsahovat podporu zobrazení MPEG-4 přímo v prostředí prohlížeče bez spouštění SW třetích stran.
21	Systém musí obsahovat možnost rychlé volby pro zobrazení/skrytí DICOM atributů (volby pro skrytí údajů o pacientovi /vyšetření, orientace snímku, anotace, referenční čáry apod.).
22	Systém musí obsahovat možnost rozdělení obrazovky horizontálně i vertikálně pro zobrazení více snímků na jednom monitoru v rámci jednoho vyšetření a pro porovnání vícero vyšetření.
23	Systém musí obsahovat možnost automatické nebo manuální synchronizace pro zobrazení dvou a více sérií.
24	Systém musí být integrován do stávajícího nástroje pro administraci a správu obrazové dokumentace (XXXXX Xxxxxx, dodavatel OR-CZ, spol. s.r.o.) – umožní spuštění prohlížeče z prostředí XXXXX Xxxxxx tak, aby zobrazil příslušné vyšetření.
25	Systém musí umožnit základní měření: denzita, pravítko, tříbodový úhel, poměr, kalibrace
26	Systém musí obsahovat pokročilé měření: elipsa, obrys, kruh, čtverec, obdélník, mnohoúhelník, ROI, Xxxxxx úhel, zakřivení, zobrazení statistiky v ROI – xxx, průměr, směrodatná odchylka, gamma korekce.
27	Systém musí umožnit manipulace s dvourozměrnými i 3D snímky (nastavení W/L, nastavení LUT, zvětšení, posouvání, lupa, rotace…).
28	Systém musí umožnit spouštění video smyček.
29	Systém musí mít možnost vkládání anotací.
30	Systém musí umožnit vytvoření klíčových snímků dle standardu DICOM (Key objects), včetně jejich zobrazení a možnosti uložení jako nové série vyšetření.
31	Systém musí mít možnost porovnání vyšetření různých pacientů.
32	Systém musí obsahovat funkce pro objemové operace (MPR, objemová rekonstrukce, MIP, průměr), 3D kurzor, fúze pro neomezené množství modalit, pro tyto funkce lze využít instalace doplňkového modulu nebo s využitím samostatného SW.,
33	Systém musí obsahovat závěsné (hanging) protokoly – možnost pokročilé definice hanging protokolů a kombinace pravidel pro zobrazení vyšetření. Musí být možné definovat min. rozložení obrazu (rozdělení obrazovky/obrazovek) dle typu vyšetření, počet diagnostických monitorů a nastavení zobrazení na každém z nich vč. nastavení zobrazení na tabletu či telefonu, automatické porovnání aktuálního a předchozích vyšetření, definice nastavení výchozí hodnot jako je např. WL, zoom, nastavení pozice otevření vyšetření, MPR, 3D rekonstrukce, apod. Všechna tato pravidla musí být možné kombinovat.
34	Centrální prohlížeč musí umožňovat správu rozvržení panelu nástrojů na pracovní ploše prohlížeče.,
35	Systém musí mít možnost přednastavení šablon pro různé typy vyšetření. Šablony umožní přednastavení minálně hodnot window level, zoom, počtu oken pro rozdělení obrazovky, pořadí pro zobrazení vybraných sérií a snímků.
36	Centrální prohlížeč musí umožňovat uživatelské nastavení viditelnosti konkrétních DICOM tagů na obrazovce prohlížeče dle typu modality – musí být možné zobrazit libovolný DICOM tag.
37	Systém musí obsahovat indikátor aktuálně otevřené série.
38	Systém musí umožnit automatické dočítání otevřených nedokončených/rozpracovaných vyšetření.
39	Systém musí obsahovat možnost uložení rozpracovaného stavu vyšetření na server pro následné použití (po přihlášení z jiného koncového zařízení, musí být možné zobrazit vyšetření v uloženém rozpracovaném stavu včetně komentářů, měření, rozložené obrazu, W/L apod.).
40	Systém musí umožňovat integrovanou, zabezpečenou online vzdálenou konzultaci více uživatelů s následujícími vlastnostmi: sdílení pohledu v reálném čase na stejná dynamická obrazová data, v rámci konzultace musí být umožněno každému účastníkovi konzultace pracovat individuálně s vyšetřením, aniž by úpravy vyšetření vytvořené uživatelem viděli ostatní účastníci konzultace a zároveň musí mít každý účastník možnost provedené úpravy vyšetření zobrazit ostatním účastníkům konzultace. Sdílení provedených úprav vyšetření musí být provedeno formou přenesení pouze příkazů, aniž by se přenášela vlastní obrazová data (z důvodu rychlosti komunikace a zabránění zatížení sítě přenosem obrazových dat), vkládání značek a textových poznámek, neomezený počet současně spolupracujících uživatelů nad jedním vyšetřením, neomezený počet současně aktivních konzultací, podpora přizvání hostů, kteří nemají vytvořený účet pro přístup do systému, k on-line konzultaci (podpora externích spolupracovníků).
41	Systém musí obsahovat možnost vytvoření a odeslání odkazu na vyšetření vč. možnosti odeslání odkazu na rozpracované vyšetření (např. pro konzultaci vyšetření, apod.).
42	Systém musí obsahovat podporu pro přehrávání smyček z ultrazvuku, angiografie, laparoskopie apod., možnost nastavení rychlosti a rozsahu přehrávání.
43	Systém musí umožňovat tvorbu složek a pracovních seznamů, možnost sdílení těchto složek a seznamů mezi uživateli.
44	Systém musí obsahovat možnost volání detailu vyšetření ve stávajícím nástroji pro administraci a správu PACS (XXXXX Portal, dodavatel OR-CZ, spol. s.r.o.) pro zapsání popisu k zobrazenému vyšetření.
45	Systém musí obsahovat možnost nastavení přístupu externích uživatelů pouze do konkrétních složek a seznamů, bez přístupu do archivu PACS.
46	Systém musí obsahovat možnost exportu vyšetření/snímků ve formátu DICOM, MPEG4, JPG, PNG s možností anonymizace dat pro publikační a prezentační účely.
47	Systém musí umožnit zpracování 3D rekonstrukcí možnost využití výkonu grafických karet v diagnostických stanicích a na serveru pro sdílení jejich výkonu pro více koncových zařízení – možnost definice priorit využití grafických karet na základě IP adres, apod.

Webový portál

Stávající webový portál pro administraci a správu PACS (XXXXX Portal, dodavatel OR-CZ, spol. s.r.o.) bude rozšířen o funkci pro vzdálený popis vyšetření. Nová funkcionalita musí umožňovat následující vlastnosti a funkcionality.Uvedené parametry a vlastnosti řešení webového portálu v níže uvedené tabulce znamenají minimální míru plnění dle této ZD.

ID	Principy a technologické vlastnosti	Splněno
01	možnost vytvoření žádanky na vzdálený popis vyšetření nebo konzultaci,
02	možnost zapsání popisu vyšetření a jeho odeslání do NIS,
03	možnost přidání komentáře k vyšetření,
04	definice skupin vyšetření a přiřazování vyšetření do těchto skupin,
05	vyhledávání vyšetření dle skupin,
06	integrace s diagnostickým webovým DICOM prohlížečem (volání detailu vyšetření a funkce pro popis vyšetření přímo z prostředí prohlížeče).

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 informační systémy);

návrh řešení postupu a pořadí při nasazování jednotlivých funkcí – 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 Zadavatele;
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í

Zadavatel 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
diagnostický webový DICOM prohlížeč	neomezený	2
webový portál	neomezený	neomezený

Nabízení řešení nesmí pro svůj provoz vyžadovat přítomnost bezpečnostních předmětů souvisejících s licenční ochranou dodávaného aplikačního software na straně serveru ani na straně klienta (např. použití hardwarových licenčních tokenů, aj.).
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 není relevantní, data zůstávají ve stávajícím systému.

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.

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

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 Zadavatele tak, aby na základě dodané dokumentace mohl povolit a nastavit přístup třetí straně samostatně bez součinnosti zhotovitele.

Dokumentaci rozhraní bude povinen Dodavatel 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 Zadavatelem odsouhlasené dokumentace skutečného nasazení bude provedena na hardware a software Zadavatele. 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.

Zadavatel 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

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

NIS Kompatibilita se stávajícím IS Akord:

DASTA (datový standard pro předávání dat mezi informačními systémy zdravotnických zařízení),
HL7 (mezinárodní komunikační standard ve zdravotnictví).

PACS Kompatibilita se stávajícím IS XXXXX XXXX – archiv:

DICOM (standard pro zobrazování, distribuci, skladování a tisk medicínských dat pořízených snímacími metodami).

Kompatibilita se stávajícím IS XXXXX XXXX – portál:

komunikační rozhraní ESB (Enterprise Service Bus) systému XXXXX PACS popsáno v dokumentu XXXXX Xxxxxx – API.pdf.

Kompatibilita se stávajícím IS XXXXX XXXX – certifikace:

soubor dodaného aplikačního programového vybavení, tzn. všechny nabízené SW moduly, musí být certifikován jako „Zdravotnický prostředek třídy IIa nebo vyšší“ v souladu se zákonem č. 268/2014 Sb., o zdravotnických prostředcích, nařízením EU MDD 93/42/EEC a nařízením vlády č. 54/2015 Sb.

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

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 16: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	4 pracovní hodiny	Následující pracovní den	a
B	4 pracovní hodiny	5 pracovních dnů	a, b
C	6 pracovních hodin	20 pracovních dnů	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ždý započatý den 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 2

Document Metadata