5, Brno

JIHOMORAVSKÝ KRAJ Žerotínovo nám. 3/5, 601 82 Brno

Váš dopis zn.: Ze dne: Č. j.: Sp. zn.: Vyřizuje: Telefon: Počet listů: Počet příloh/listů : Datum:

JMK 137295/2014 S-JMK Megová 541 651 338 6 0/0 4. 12. 2014

Dodatečné informace č. III. k zadávacím podmínkám k veřejné zakázce na dodávky: „Rozvoj eHealth“

Zadavatel: Sídlo: IČ:

Jihomoravský kraj Žerotínovo nám. 3/5, 601 82 Brno 70888337

Informace o veřejné zakázce: Název veřejné zakázky: Druh veřejné zakázky: Forma zadávacího řízení:

Rozvoj eHealth veřejná zakázka na dodávky nadlimitní veřejná zakázka na dodávky dle ustanovení § 27 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „zákon o VZ“)

Zadavatel Vám v souladu s ustanovením § 49 zákona o VZ poskytuje na základě dotazu jednoho z uchazečů následující dodatečné informace k zadávacím podmínkám:

Dotaz č. 1 (ze dne 1.12.2014): V příloze č. 1, tabulka 1. je uveden sloupec Zapojení do projektu ePACS. Prosím, popište exaktně význam jednotlivých hodnot ve sloupci ve vztahu k současnému stavu i k požadovanému stavu. Odpověď zadavatele na dotaz č. 1: Komunikační uzel ePACS musí být dodán pro tato zdravotnická zařízení:  Vojenská nemocnice Brno  Nemocnice Blansko

IČ 708 88 337

DIČ CZ70888337

Telefon 541 651 111

Fax 541 651 209

E-mail [email protected]

Internet www.kr-jihomoravsky.cz

  

Nemocnice Tišnov Nemocnice Vyškov Nemocnice Znojmo

Dotaz č. 2 (ze dne 1.12.2014): V příloze č. 1, tabulka 1. je uveden sloupec Zapojení do projektu ePACS. Jestli je význam hodnoty ve sloupci - Komunikační uzel pro PACS není součástí nabídky komunikačního uzlu, protože to už bylo realizováno: Má být součástí dodávky komunikačního uzlu i propojení na stávající komunikační uzel ePACS? Propojení je potřebné pro načtení dat poskytovaných pro WEB rozhraní. Odpověď zadavatele na dotaz č. 2: Viz předchozí odpověď. Na stávající uzly ePACS v jiných zdravotnických zařízení není třeba dodat žádné napojení.

Dotaz č. 3 (ze dne 1.12.2014): Zadávací dokumentace definuje, že implementace připojení do NIS je součástí dodávky a zároveň využívá IT infrastrukturu NIS, je teda součástí NIS. Budoucí dodavatel eHealth JMK je povinen implementovat propojení v 18 specifikovaných zdravotnických zařízeních. Prosím, popište detailně, jakou součinnost zadavatel poskytne dodavateli pro splnění tohoto požadavku? A to zejména ve vztahu ke každému dotčenému zdravotnickému zařízení, a přes něj případně ke transparentní a rovné součinnosti výrobce NIS. Prosím, popište detailně, jak Zadavatel zajistil transparentní, rovné a nediskriminační podmínky v soutěži pro všechny uchazeče v oblasti nacenění požadavku propojení s NIS?

Odpověď zadavatele na dotaz č. 3: Dodavatel musí zajistit plnění dodávky v celém požadovaném rozsahu. V případě napojení na nemocniční informační systémy (dále také NIS) v jednotlivých zdravotnických zařízeních musí dodavatel zajistit doplnění NIS o nezbytné software úpravy a implementační práce (v zadávací dokumentaci označeno jako "adapter NIS ") od dodavatelů těchto nemocničních systémů formou subdodávky. Cena za propojení s NIS stejně jako všechny ostatní subdodávky je věcí dohody uchazeče a subdodavatele. Dotaz č. 4 (ze dne 1.12.2014): V zadávací dokumentaci je vícekrát zmíněno "centrum výměny zpráv". Prosíme definujte uceleně všechny služby, které poskytuje "centrum výměny zpráv" pro požadovaný komunikační uzel. Odpověď zadavatele na dotaz č. 4: Centrum výměny zpráv zajišťuje následující služby:  Pro každé připojené zdravotnické zařízení jsou vytvořeny fronty zpráv, ze kterých může číst zprávy pouze komunikační uzel reprezentující toto zdravotnické zařízení  Zprávy do front mohou zapisovat všechny autentizované a autorizované komunikační uzly, které reprezentují zapojená zdravotnická zařízení  Centrum umožňuje vytvoření dočasných front to podporu komunikace typu dotaz - odpověď  Každý komunikační uzel přistupuje k centru protokolem OpenWire, transportním protokolem je TCP + SSL/TLS se serverovým certifikátem. Každý komunikační uzel se vůči centru autorizuje s použitím uživatelského jména a hesla. Autorizace komunikačního uzlu je dána konfiguračně centrem výměny zpráv, a to zařazením do odpovídajících skupin.

2

Dotaz č. 5 (ze dne 1.12.2014): V zadávací dokumentaci je požadována asynchronní komunikace výměny správ ve formátu DASTA v.3 pomocí protokolu OpenWire se šifrováním SSL/TLS. Pro autentifikaci musí být použito login/heslo nebo klientský certifikát. Musí uchazeč implementovat oba způsoby nebo postačí jeden z uvedených? Odpověď zadavatele na dotaz č. 5: Ano, oba. Protokoly SSL/TLS se používají pro šifrování obsahu komunikace a využívají serverový certifikát vydaný pro centrum výměny zpráv. Pro autentizaci a následnou autorizaci se využívá kombinace uživatelského jména a hesla.

Dotaz č. 6 (ze dne 1.12.2014): V zadávací dokumentaci je požadován protokol pro synchronizaci času. Prosím, specifikujte jaký? NTP = Network Time Protocol? Odpověď zadavatele na dotaz č. 6: Ano. Předpokládáme využití protokolu NTP. Případně uchazeč může navrhnout i jiný způsob synchronizace času centra a komunikačních uzlů, pokud prokáže dostatečnost řešení pro potřeby výměny zpráv.

Dotaz č. 7 (ze dne 1.12.2014): V zadávací dokumentaci je požadována centrální auditní databáze. Prosím, specifikujte jaký formát mají mít auditní zprávy. Jedná se o auditní (akci je možno vykonat jenom v případě, že byl potvrzen zápis do centrální auditní databáze) nebo logovací záznamy (bez ohledu na to, zda zápis do auditní DB byl úspěšný nebo ne)? Odpověď zadavatele na dotaz č. 7: Auditní záznamy musí obsahovat minimálně tyto informace:  jednoznačný identifikátor auditního záznamu  jednoznačná identifikace subjektu, který záznam odeslal (identifikátor, název zařízení, DN)  jednoznačná identifikace uživatele, který vyvolal klinickou událost (identifikátor, celé jméno, DN)  typ klinické či systémové události  typ zprávy  úroveň hlášení  text hlášení  datum a čas vytvoření hlášení Záznamy v auditní databázi mají charakter informace o uskutečněné události, ať již klinické nebo systémové. Slouží ke zpětné kontrole realizované komunikace a identifikaci případných problémů. Text hlášení nesmí obsahovat osobní citlivé údaje pacienta.

Dotaz č. 8 (ze dne 1.12.2014): V zadávací dokumentaci je požadován vzdálený dohled z centra. Jaké protokoly jsou požadované směrem z centra na monitorování komunikačního uzlu? Odpověď zadavatele na dotaz č. 8: Je úkolem dodavatele, aby navrhl, jakým způsobem bude možné sledovat funkčnost jim navržených komunikačních uzlů a jednotlivých služeb na těchto uzlech provozovaných. Současně je také na dodavateli řešení, aby specifikoval, jaké komunikační protokoly jsou nezbytné pro toto sledování.

3

Dotaz č. 9 (ze dne 1.12.2014): Je v zadávací dokumentaci definováno jsou-li v centru výměny zpráv pro Komunikační uzly k dispozici služby: * PKCS infrastruktura pro zprávu používaných certifikátů pro SSL/TLS * Centrální zpráva konfigurace např. seznam připojených nemocnic/adresátů zpráv přiřazení certifikátů k nemocnicím

Odpověď zadavatele na dotaz č. 9: Požadované řešení nepředpokládá využití PKCS infrastruktury a certifikátů pro jednotlivá zdravotnická zařízení. Pokud uchazeč přesto navrhne v rámci svého řešení použití certifikátů pro zdravotnická zařízení, musí zajistit také jejich vydávání a správu.

Dotaz č. 10 (ze dne 1.12.2014): V zadávací dokumentaci je uvedeno, že má být použit protokol OpenWire. Protokol OpenWire je hlavním protokolem Apache ActiveMQ (implementace Message Queue). Umožňuje centrum výměny zpráv připojení dalších ActiveMQ brokerů (z každé nemocnice jednoho), t.j. konfigurace spojení na úrovni ActiveMQ, nebo je striktně vyžadováno použití protokolu OpenWire? Odpověď zadavatele na dotaz č. 10: Požadované řešení předpokládá napojení na Centrum výměny zpráv projektu eMeDocS Kraje Vysočina. Předpokládáme přímé napojení komunikačních uzlů na toto centrum bez dalších brokerů na úrovni jednotlivých nemocnic.

Dotaz č. 11 (ze dne 1.12.2014): V zadávací dokumentaci je uvedeno, že webové uživatelské rozhraní musí podporovat autentifikaci vůči lokální DB nebo Active Directory nebo LDAP. Postačuje jeden z uvedených způsobů, nebo je nutno implementovat všechny? O jakou lokální DB se jedná? Má být součástí komunikačního uzlu nebo je součástí NIS? Kde je umístěna databáze Active Directory/LDAP, kterou má komunikační uzel používat? Na centru výměny zpráv/na komunikačním uzlu/v infrastruktuře nemocnice? V případě, že se jedná o lokální DB/ActiveDirectory/LDAP provozovány v infrastruktuře nemocnice a tedy komunikační uzel musí umožnit připojení na různé DB-struktury a různé konfigurace ActiveDirectory a LDAP v závislosti od dotčené nemocnice. Prosím, potvrďte toto tvrzení. Odpověď zadavatele na dotaz č. 11: Nabízené řešení pro komunikační uzly musí zajistit ověření identity uživatele a jeho autorizaci v kontextu daného zdravotnického zařízení, a to následujícím způsobem: a. Pokud zdravotnické zařízení vede svou správu identit v rámci ActiveDirectory nebo LDAP, pak řešení pro komunikační uzly musí využívat pro ověření identity a nastavení přístupových práv tuto správu identit. b. V případě, že zdravotnické zařízení nevede správu identit v rámci AD/LDAP, pak řešení pro komunikační uzly musí poskytovat možnost vytvoření uživatelských účtů a skupin v rámci tohoto komunikačního uzlu (lokální databáze uživatelských účtů) a jejich správu. Vzhledem k tomu, že není možné dopředu stanovit, která varianta autentizace a autorizace bude použita v konkrétním zdravotnickém zařízení, je nezbytné, aby nabízené řešení zahrnovalo obě možnosti.

4

Dotaz č. 12 (ze dne 1.12.2014): Komunikační uzel ukládá všechny informace do lokální auditní DB. Lokální auditní DB musí být v infrastruktuře nemocnice. Má být tato databáze součástí nabídky a má být provozována na nabízeném HW komunikačního uzlu, nebo je potřebné komunikační uzel propojit na stávající auditní DB v nemocnici? Jestli ano, o jakou DB v jednotlivých nemocnicích jde, jaké jsou její DB struktury? Odpověď zadavatele na dotaz č. 12: Požadované řešení předpokládá vytvoření lokální auditní databáze v rámci komunikačního uzlu, na kterém bude i provozována. Řešení tohoto požadavku musí být součástí nabídky.

Dotaz č. 13 (ze dne 1.12.2014): V zadávací dokumentaci je uvedeno, že výměna zpráv je realizována pomocí DASTA v.3 (validace vůči DTD), v ukázkách jsou však použity zprávy dle DASTA v.4 (validace vůči XSD). Která verze DASTA je teda požadována?

Odpověď zadavatele na dotaz č. 13: V případě rozhraní pro předávání ambulantních, hospitalizačních a výjezdových zpráv se jedná o DASTA ver.3. V případě rozhraní pro předávání životních údajů pacienta je možné využít komunikaci sadou SQL příkazů nebo formou DASTA ver.4 zpráv.

Dotaz č. 14 (ze dne 1.12.2014): V zadávací dokumentaci je doporučeno použití HW s pasivním chlazením a poměrně nízkým výkonem. Současně je tam požadavek zakazující licenční omezení vzhledem na počet zpráv nebo počet zpracovaných dotazů. Prosíme o specifikaci: * odhadovaný počet asynchronních zpráv za den * odhadovaný počet asynchronních zpráv za hodinu v pracovní době (8-15) * odhadovaná velikost asynchronních zpráv * odhadovaný počet synchronních dotazů za hodinu * odhadovaná velikost synchronních dotazů (request/response) * odhadovaný maximální počet uživatelů přistupujících přes WEB rozhraní na jeden komunikační uzel * odhadovaný průměrný počet uživatelů přistupujících přes WEB rozhraní na jeden komunikační uzel Odpověď zadavatele na dotaz č. 14: V rámci zadávací dokumentace je uvedeno doporučení ohledně hardware parametrů komunikačních uzlů. Uchazeč může nabídnout řešení v intencích tohoto doporučení případně lepší. Uvádíme orientační odhad pro jednotlivé typy komunikace v rámci jednoho zdravotnického zařízení: 1. Předpokládaný průměrný počet přijatých/odeslaných zpráv za jeden den: 2. Předpokládaný průměrný počet dotazů na životní údaje pacienta za jeden den: 3. Předpokládaný průměrný počet odpovědí na životní údaje pacienta za jeden den:

50 10 200

Dotaz č. 15 (ze dne 1.12.2014): Pro "Vyhledání životních dat pacienta pro ZZS/ZZ" je požadován "dotaz na životní data se odesílá všem spolupracujícím zdravotnickým zařízením". Jedná se o komunikaci typu a) každý-s-každým/peer-to-peer, t.j. komunikační uzel přímo osloví všechny komunikační uzly v seznamu

5

b) nebo o komunikaci přes centrální uzel, t.j. komunikační uzel přímo osloví centrum výměny zpráv a to osloví všechny komunikační uzly Vzhledem na vybudovanou komunikační infrastrukturu se jeví, že zprávy mohou být posílány do dalšího komunikačního uzlu bez komunikace s centrem. Jestli se jedná o komunikaci každý-s-každým, jaký je smysl využití "centra výměny zpráv"? Odpověď zadavatele na dotaz č. 15: Požadujeme řešení, kdy komunikační uzly mezi sebou komunikují pouze a výhradně formou předávání zpráv přes komunikační centrum. V případě vyhledávání životních údajů pacienta dotazující zdravotnické zařízení odešle dotaz do všech zapojených zdravotnických zařízení prostřednictvím jejich fronty zpráv v centru. Dále očekává odpovědi od všech zdravotnických zařízení ve vlastní frontě zpráv. Jedná se tedy o typ komunikace "každý s každým", kdy technicky je tato komunikace zajištěna právě centrem výměny zpráv.

Dodatečná informace zadavatele: Zadavatel předpokládá, že firma, která se bude ucházet o veřejnou zakázku, bude působit, jako systémový integrátor a bude mít dostatek zkušeností na to, aby si buď sama, nebo prostřednictvím svých subdodavatelů opatřila potřebné informace pro plné zapojení do těchto dvou již fungujících projektů a potřebné informace od jednotlivých dodavatelů NIS. Projekt ePACS - informace a kontakty http://www.epacs.cz/faces/pages/index.xhtml Projekt eMeDOcS - informace a kontakty http://emedocs.cz/

S pozdravem Otisk razítka

JUDr. Věra Vojáčková, MPA ředitelka Krajského úřadu Jihomoravského kraje na základě pověření hejtmana Jihomoravského kraje ze dne 17. 12. 2012 č. j. JMK 140 297/2012

6