Vstupní brány ZDRAVELGate, ZDRAVELCheck a ZDRAVELView

Transkript

1 Vstupní brány ZDRAVELGate, ZDRAVELCheck a ZDRAVELView Technická specifikace pro DASTA platnost od: 10. listopadu 2016 verze 1.0

2 Obsah 1. Úvod Obecná doporučení Práce s XML a logování odesílání Reakce na chybové stavy a chování fronty zápisů Spolupráce při implementaci a dalším vývoji Základní funkcionality a doporučení jejich užití ZDRAVELGate Obecné informace Přihlašovací údaje Limit velikostí souborů XML a příloh Kódování češtiny Pojmenovávání XML dle DS Formát komunikace HTTP transakce HTTP požadavek Datový standard DS3 a přijímané výkony Element <dasta> Element <is> Element <ip> Anamnéza Očkování Předepsané léky Výdej léků Ambulantní vyšetření a hospitalizace Laboratorní výsledky Urgentní informace <u> Přílohy Odpověď ZDRAVELGate Příklady odpovědí...20 Verze:

3 Seznam chyb dle DS Přehled chybových návratových kódů HTTP odpovědi Přehled návratových kódů ZDRAVEL Metodika reakce na návratové kódy a opakované odesílání Reakce na chybové návratové kódy HTTP odpovědi Reakce na návratové kódy ZDRAVEL Formát času a data v DS Pokud DASTA definuje formát V blocích DS je používáno Jako atribut bloků DS je používáno Formát údaje Odkazy Produkční server: Testovací server: ZDRAVELCheck Komunikace s ZDRAVELCheck Přihlašovací údaje Limit velikostí souborů XML a příloh Pojmenovávání XML - dle DS HTTP transakce HTTP požadavek Identifikace odesílatele Dotaz na ZDRAVELCheck Odpověď ZDRAVELCheck XML ATR XML TAG CSV Odkazy Produkční server Testovací server ZDRAVELView...41 Verze:

4 5.1. Komunikace s ZDRAVELView Přihlašovací údaje HTTP transakce HTTP požadavek Odkazy Produkční server Testovací server Přílohy dokumentu...42 Verze:

5 1. Úvod Tento dokument je určen pro vývojáře softwarů zasílajících zdravotní data do systému ZDRAVEL. Obsahuje podrobné informace ke vstupním branám ZDRAVELGate, ZDRAVELCheck a ZDRAVELView. 2. Obecná doporučení 2.1. Práce s XML a logování odesílání Logování kompletní odpovědi serveru Pro snadné hledání a diagnostiku chyb při komunikaci doporučujeme umožnit zobrazit nebo logovat kompletní XML odpověď serveru. Export XML Ze stejných důvodů jako u logování kompletní odpovědi serveru doporučujeme umožnit export, případně zpětnou rekonstrukci (i hromadně) záznamů ve formátu XML. Tyto pak mohou být pohodlně analyzovány. Hromadné odesílání Záznamy je možné odesílat jednotlivě, tj. 1 záznam = 1 XML soubor, nebo zapsat více záznamů do jediného XML. POZOR, v tomto případě je nutné zabránit generování nadměrných XML, vhodná velikost je do cca 400kB /XML, což odpovídá asi zprávám (blokům <z> ). Identifikace XML V XML vždy zasílejte řádnou identifikaci - název společnosti, název SW, verze SW, umožníte tím efektivnější zpracování dat na straně ZDRAVEL a snadnější diagnostiku případných problémů v komunikaci. Odesílání komprimovaných XML Brána ZDRAVELCheck i ZDRAVELGate umí přijímat komprimovaná XML ve formátu ZIP (případně RAR). Komunikační modul i knihovna s touto funkcionalitou počítají. Komprimaci XML doporučujeme nasadit u XML souborů o velikosti 50kB a větších. Ověření validnosti XML souborů Ověření lze provést na následující adrese: Verze:

6 Nejčastější chyby při generování XML souborů: Chyba v cestě DTD: Cesta k DTD v xml je relativní a měla by být definována takto: <!DOCTYPE dasta SYSTEM "ds dtd" > Nikdy ne tímto způsobem: <!DOCTYPE dasta SYSTEM " Chyba v souslednosti dat_vb a dat_du: dat_vb je vždy nejstarší datum v XML. Podrobnosti jsou obsaženy v sekci Formát času a datumu v DS Reakce na chybové stavy a chování fronty zápisů Doporučujeme korektně přistupovat k návratovým kódům a zodpovědně rozhodovat, které záznamy nechávat ve frontě k odeslání. Okamžité nebo hromadné odesílání Doporučujeme umožnit odesílání záznamů do systému ZDRAVEL jak okamžitě, tak i možnost jejich uložení pro pozdější hromadné i jednotlivé odeslání. Přehled o odeslaných záznamech SW by měl umožnit zobrazení přehledu odeslaných záznamů s informací o výsledku importu (např. v logu, nebo seznamu). Již odeslané záznamy (tj. s výsledkem importu 20000, OK) se ve frontě záznamů k odeslání již dále nezobrazují. Je však vhodné umožnit samostatné zobrazení jejich přehledu. Přebírání a zobrazování odpovědi ZDRAVELGate Doporučujeme provádět korektní přebírání a zobrazování odpovědí (chybových hlášení) brány ZDRAVELGate, viz. dokumentace odpověď ZDRAVELGate. Umožní to snažší identifikaci často i banální chyby a urychlí řešení potíží s odesíláním. Verze:

7 Při výskytu chyby Pacient neznámý nebo s omezeným přístupem - doporučujeme, ponechat tento záznam ve frontě k opakovanému odeslání následující 4 týdny od prvního pokusu. Pokud ani po této době pokusy o odeslání úspěšné nejsou, je možné vyřadit tento záznam z fronty určené k odeslání Spolupráce při implementaci a dalším vývoji Společnost ZDRAVEL nabízí bezplatně podporu a poradenství při implementaci a dalším vývoji IS umožňujících komunikaci se systémem. V rámci zasílaných přístupových údajů získáte přístup k testovacímu prostředí, dokumentaci veškerých funkcionalit systému ZDRAVEL a návodům na jejich implementaci včetně poskytovaného komunikačního modulu (.exe nebo.dll) Základní funkcionality a doporučení jejich užití Dvoufázová komunikace v DS3 Doporučujeme vždy využívat pouze dvoufázové komunikace se systémem ZDRAVEL tj. ZDRAVELCheck - ZDRAVELGate. Při odesílání dat tedy nejprve doporučujeme provést hromadné ověření registrací klientů pomocí ZDRAVELCheck a dle odpovědi provést odeslání dat pouze těm klientům, kteří jsou v systému registrovaní a mají aktivní EZK. Lékař (systém) tak komunikuje pouze data pacientů, kteří k tomu dali souhlas zřízením zdravotní knížky. Rozšířená identifikace ZZ Identifikace zdravotnického zařízení byla rozšířena o nepovinný třímístný číselný atribut PČZ. Všechna zdravotnická zařízení jsou nyní v systému identifikována unikátní kombinací IČO PČZ. Automatické odesílaní U lékárenských, nemocničních a laboratorních IS je často vyžadováno automatizované odesílání dat (např. v nočních hodinách). Pro tyto subjekty doporučujeme umožnit nastavení plánovaného odesílání (den, čas, opakování v případě neúspěchu). U automatického odesílání doporučujeme též věnovat pozornost práci s frontou záznamů, blíže viz odstavec Práce s odesíláním, chování fronty záznamů. ZDRAVELCheck a kartotéka, hlídání aktivací Doporučujeme umožnit nasazení ZDRAVELCheck na hromadné ověření celé kartotéky pacientů lékaře s následným zobrazením statutu pacienta (neregistrován / registrován). Tímto je lékaři dána možnost hlídání aktivací a celkového přehledu o registrovaných pacientech. Verze:

8 Odesílání dle jednotlivých oddělení ZZ U IS pro velká zdravotnická zařízení doporučujeme umožnit postupné zapínání odesílání dle jednotlivých oddělení (pokud není nastaveno globální ano a neřídí se odesílání pouze vyplněním příst. kódů zdravotnického pracovníka). Rychlé nahlížení IZIVIEW s využitím komponenty TWebBrowser Funkce ZDRAVELView umožňuje rychlý vstup do knížky pacienta přímo z kartotéky lékaře. Rychlé nahlížení řeší jinak zdlouhavou cestu k informacím uloženým v EZK pacienta, kdy je nutné projít několik přihlašovacích dialogů. Přihlašovací stránka ZDRAVELView očekává všechny potřebné údaje najednou a může být volána z otevřené karty pacienta. Návod na implementaci a další informace naleznete v dokumentaci ZDRAVELView. 3. ZDRAVELGate Přijímací brána ZDRAVELGate slouží pro příjem informací do zdravotních knížek. Uvedené informace se přijímají ve formátu plně kompatibilním s datovým standardem Ministerstva zdravotnictví ČR verze (dále jen DS3) Obecné informace Přihlašovací údaje Přihlašovací údaje na testovací server jsou po vyplnění žádosti automaticky zaslány na registrovanou ovou adresu. Před prvním odesíláním dat do systému ZDRAVEL je nezbytné, aby lékař (testovací lékař) provedl aktivaci účtu dle zaslaných pokynů přes webové rozhraní. Certifikáty k testovacímu serveru naleznete v příloze ca_internal_root.cer a ca_internal_sub.cer Limit velikostí souborů XML a příloh Velikost každého jednotlivého souboru nesmí přesáhnout 2MB Celková velikost kolekce POST nesmí přesáhnout 8MB Pokud bude XML soubor zasílán komprimovaně, pak nesmí velikost původního (nekomprimovaného) souboru přesáhnout 2MB. Verze:

9 Kódování češtiny Kódování češtiny použité v XML souboru je nutné specifikovat na prvním řádku XML souboru a to například následovně: <?xml version="1.0" encoding="windows-1250" standalone="no"?> V datovém standardu se připouští následující kódování češtiny s těmito názvy: utf-8 IBM852 ISO Windows Pojmenovávání XML dle DS3 Odesílatel zajistí vytváření jmen souborů, které nebudou po určitou vhodnou dobu duplicitní. Jméno datového souboru má strukturu: UTTXXXXX.KKK pro soubory "pakované"* UTTXXXXX.xml pro soubory "nepakované" Jednotlivé znaky mají následující význam: U vyjadřuje určení = typ přenášených dat a v případě dat pacientů také urgentnost - viz "ur" v hlavním bloku dasta TT určuje typ odesílajícího místa - viz "typ_odesm" v hlavním bloku dasta a viz číselník [TAB_TO] XXXXX pokud není soubor zasílán ÚZIS, pak libovolný řetězec neobsahující mezery, který je sestavený z číslic a běžných písmen anglické abecedy viz "ozn_soub" v hlavním bloku dasta (označení souboru), jinak viz dále KKK určuje program, kterým bylo zapakováno* Formát komunikace HTTP transakce Transakce probíhá ve 4 krocích: ustavení tcp/ip spojení odeslání http požadavku Verze:

10 obdržení odezvy ukončení spojení HTTP požadavek Požadavek se skládá z hlavičky a těla. Hlavička From: lekar@nemocnice.cz Host: cil_server:port Content-Length: 1427 Content-Type: multipart/form-data; boundary=7d1a Parametr "from" by měl obsahovat ovou adresu odesílatele, parametr "Host" musí obsahovat cílovou adresu serveru. Pro bezchybnou komunikaci je zde potřeba správně nastavit zejména hodnotu parametru Content-Length, která má význam délky následujícího těla v bytech. Parametr Content-Type obsahuje kromě pevného nastavení typu multipart/form-data důležitý údaj boundary. Tento údaj obsahuje textový řetězec, který se nesmí vyskytovat ve vlastních přenášených datech. Obsah boundary nastavuje klient. Tělo --7d1a Content-Disposition: form-data; name="typ_imp" 9 --7d1a Content-Disposition: form-data; name="idc_zp" d1a Content-Disposition: form-data; name="prist_heslo" dff1649a... (MD5 hodnota přístupového hesla) --7d1a > Content-Disposition: form-data; name="xmlfile"; filename="nazev_souboru.xml" Content-Type: application/octet-stream <?xml version='1.0' encoding='windows-1250' d1a Content-Disposition: form-data; name="attach1"; filename="nazev_souboru.jpg" Content-Type: application/octet-stream bin_data --7d1a Verze:

11 Komunikační modul přidává automaticky typ_imp=2. Pokud implementujete odesílání sami a nepoužíváte komunikační modul, jste povinni použít typ_imp=9. Identifikace odesílatele idc_zp identifikuje odesílatele, který musí být zdravotním pracovníkem registrovaným v systému ZDRAVEL. prist_heslo (přístupové heslo) a se předpokládá zahashované algoritmem MD5 - Hexadecimální číslice se předpokládají malými písmeny. Pozn.: první příloha name=attach1, druhá name=attach2,..., N-tá příloha name=attachn Jak je vidět, musí být boundary příslušné hlavičky opatřeno v těle požadavku navíc prefixem --. Ten samý řetězec je pak přidán i za poslední výskyt boundary v těle. Z ukázky je rovněž zřejmý způsob přenosu jednotlivých údajů. Za uvedením boundary následují řádky s parametry Content-Disposition, případně Content-Type a jeden prázdný řádek, za kterým je uveden obsah údaje. Parametr Content-Disposition obsahuje dispozici údaje, obsahující zejména řetězec formdata a název příslušného údaje. Jednotlivé zde použité elementy jsou navzájem odděleny středníkem. Parametr Content-Type je použit u údajů, jejichž obsahem je samotný obsah datových souborů. V tomto případě má tento parametr hodnotu application/octet-stream. Odpověď server vrací (na rozdíl od předchozí verze brány) ve formátu XML Datový standard DS3 a přijímané výkony Systém ZDRAVEL přijme a uchová jakékoli validní XML ve formátu DS3 celé. Mezi úkony, které poté dokáže zobrazit ve zdravotní knížce pacienta patří anamnéza, očkování, předepsané či vydané léky, ambulantní vyšetření a hospitalizace. Souhrnný balíček s příklady XML souborů s přijímanými úkony naleznete v příloze priklady.zip Element <dasta> Element <dasta> je hlavním blokem. Povinný atribut id_soubor definuje jednoznačnou vnitřní identifikaci souboru v rámci firmy a jejího programu nebo informačního systému. Další atribut verze_ds definuje verzi datového standardu a musí být shodný s verzí použitého DTD. Atribut verze_nclp popisuje verzi použitého NČLP. Není-li NČLP vůbec využíván, zadává se nejnižší Verze:

12 verze Atributy bin_priloha, ur, typ_odesm, ozn_soub jsou povinné, ale nejsou v současnosti nijak využity. Atribut potvrzení určuje úroveň detailu odpovědi viz Odpověď ZDRAVELGate. Element <zdroj_is> je využit k jednoznačnému určení firmy, programu a jeho verze. Element <pm> obsahuje základní informace o příjemci zasílaného souboru. Při přijetí XML je provedena kontrola přítomnosti řetězce " ZDRAVELGate " v elementu <pm> (viz příklad). <pm> </pm> <as typ="i"> <vnitrni>zdravelgate</vnitrni> </as> V případě, že příchozí XML neobsahuje řetězec " ZDRAVELGate ", ZDRAVEL vrátí chybu A Deklarovaným adresátem není ZDRAVEL. Původní řešení je plně podporováno a není nutná úprava (viz. níže). <pm> </pm> <as typ="i"> <vnitrni>izigate</vnitrni> </as> Element <garant_dat> identifikuje odesílatele a tento odesílatel musí být shodný s přihlášeným uživatelem. Přestože se element <garant_dat> může vyskytovat i v jednotlivých výkonech, doporučujeme jeho použití přímo v hlavním bloku <dasta>. Na rozdíl od DS3 je tento element pro komunikaci se systémem ZDRAVEL povinný. Element <dat_vb> obsahuje datum a čas vytvoření bloku a musí obsahovat validní časový údaj. Element <dasta> dále obsahuje jeden či více elementů <is> obsahující základní informace o odesílateli Element <is> Obsahuje atributy ico, icz, icp, icl identifikující odesílatele. Atribut ico je pro komunikaci se Systémem ZDRAVEL povinný. Atribut ico je vždy 8-místný - pokud je IČO kratší, musí být doplněno nulami zleva. Verze:

13 Atribut icz je identifikační číslo ZZ a je vždy 8-místné. Atribut pcz je pořadové číslo pracoviště a je vždy 3-místné. Pro komunikaci se systémem ZDRAVEL je tento atribut nepovinný, je však možné kombinovat ho s atributem ico pro přesnou identifikaci odesílatele. Element <as> obsahuje doplňující blok adres. Element <is> dále obsahuje jeden či více elementů <ip>, který je základním blokem nesoucím data vztažená k jednomu pacientovi Element <ip> Atribut id_pac obsahuje identifikaci pacienta - klienta systému ZDRAVEL. V současné době je touto identifikací číslo pojištěnce pacienta (v praxi téměř vždy stejné jako rodné číslo). Dále obsahuje jeden z bloků, nesoucí vlastní informaci o výkonu/vyšetření viz tabulka: Název Název podle DS3 Element <ip> Anamnéza anamnéza souhrnná neformalizovaná <an> Očkování očkování <oc> Předepsané léky podávané léky!!! <le> Vydané léky léky vydané lékárnou <lek> Ambulantní vyšetření zpráva textová lékařská <z> Hospitalizace zpráva textová lékařská <z> Laboratorní výsledky výsledky vyšetření formalizované laboratorní <v> Urgentní informace urgentní informace o pacientovi neformalizované <u> Anamnéza Anamnéza souhrnná neformalizovaná, volným textem!!! Ve zdravotní knížce pacienta se vždy zobrazuje anamnéza s nejaktuálnějším datem dat_ab. Pokud je potřeba anamnézu aktualizovat, je potřeba mít současný obsah anamnézy v programu lékaře, jinak může dojít ke ztrátě informací!!! Verze:

14 Vlastní text anamnézy - element <ptext> nesmí obsahovat některé vybrané znaky (např. <, &) stejně jako text v HTML. Pokud je třeba, lze text uzavřít do konstrukce: <![CDATA[...vlastní text, kde mohou být <,&,... ]]> V rámci <text> lze podle DS3 specifikovat a přidat přílohu - soubor bude přijat, příloha však nebude zobrazována v současné verzi zdravotních knížek. Element <garant_dat> je povinný, může být v bloku <dasta> nebo v bloku <an> Doporučená maximální délka textu anamnézy je znaků. Příklad XML souboru s anamnézou: viz příloha priklady.zip/anm.xml Očkování Záznam o očkování. K očkování nelze přiložit přílohy. Element <garant_dat> je povinný, může být v bloku <dasta> nebo v bloku <oc>. Na rozdíl od DS3 je element <davka> v <ocz> povinný, protože obsahuje nezbytné <dat_du>. Příklad XML souboru s očkováním: viz příloha priklady.zip/ock.xml Předepsané léky Informace se předává v sekci <le> určené pro podávané léky. Léky předepsané v rámci vyšetření musí být v bloku <ip> pouze s jedním blokem vyšetření <z> a musí být uvedeny před blokem <z>. Pokud budou léky uvedeny s více než jedním <z>, bude zpráva odmítnuta! Předepsané léky lze poslat i samostatně bez vyšetření <z> (v případě, že dané vyšetření není v systému dostupné), ale preferovaný postup je posílat vždy včetně vyšetření (pokud to okolnosti dovolují). V bloku <lez> je povoleno použít atribut poc_bal. Pokud není uveden, je jeho implicitní hodnota 1 balení. Element <dat_od> v bloku <lez> je povinný a určuje datum předepsání léku. Verze:

15 Element <garant_dat> je povinný, může být v bloku <dasta> nebo v souvisejícím bloku <z> Příklad XML souboru s předepsáním léků: viz příloha priklady.zip/predlek.xml Výdej léků Informace o lécích vydaných lékárnou včetně dávkování, ceny aj. Zápis vydaných léků vždy bez příloh. Element <garant_dat> je povinný, může být v bloku <dasta> nebo v bloku <lek> Příklad XML souboru s výdejem léků: viz příloha priklady.zip/vydlek.xml Ambulantní vyšetření a hospitalizace Informace se předává v bloku <z> formou formátovaného textu, viz příklad. Limity - přijímá se neomezeně dlouhý text, je omezeno následné zobrazení. Je-li jedna část zprávy (vyšetření, závěr, či terapie) delší než 500 znaků, zobrazí se pouze prvních 496 znaků a tři tečky, v detailu je posléze možno prohlédnout celý text. Pokud v textu nejsou delimitery rozlišující jednotlivé součásti zprávy, považuje se daný text za závěr. Léky předepsané v rámci vyšetření musí být v bloku <ip> pouze s jedním blokem vyšetření <z>. Element <garant_dat> je povinný, může být v bloku <dasta> nebo v bloku <z> Pokud atribut vznik je "H", jde o hospitalizaci. V ostatních případech (vznik="p/v/a/r/j") se jedná o ambulantní vyšetření. K vyšetření / hospitalizaci možno vkládat více příloh, které budou zobrazeny ve zdravotní knížce. Logika vyhodnocování duplicit v záznamech o hospitalizaci a ambulantním vyšetření: V případě, že se přijímá ambulantní vyšetření, za datum výkonu se považuje výhradně dat_du. Jedná-li se o hospitalizaci, bude se brát jako datum výkonu dat_od a v případě, že nebude uvedeno, uzná se i dat_du. Pokud není uvedeno ani dat_od ani dat_du, systém vrátí chybu A Špatný formát času. Verze:

16 Z atributu oznaceni_o se zjistí označení zprávy v IS odesílatele a ověří se, jestli právě analyzovaný záznam je již v DB uložen. Pokud ano, začne se zjišťovat, jestli se jedná o validní vývoj daného výkonu, nebo o duplicitu. Validním vývojem se rozumí: Nový zápis se stavem (rozuměj atribut stav) K updatuje zápis s původním stavem Z, R, P nebo N. Nový zápis se stavem A updatuje zápis s původním stavem Z, R, P, N nebo K. Nový zápis se stavem D updatuje s jakýmkoli původním stavem zápisu včetně stavu D. Jiné kombinace stavů původního a nového zápisu budou vyhodnoceny jako duplicita. Pokud se jedná o duplicitní záznam, systém vrátí chybu A Tento záznam již existuje v databázi. Příklad XML souboru s vyšetřením: viz příloha priklady.zip/zprava.xml Laboratorní výsledky Laboratorní výsledky jsou sdělovány v bloku <v> (výsledky vyšetření formalizované laboratorní), který obsahuje jeden či více bloků <vr> s vlastním obsahem vyšetření. V bloku <vr> musí být použit jeden a pouze jeden z vnořených bloků VRi, které definují různé způsoby vlastního sdělení dat. Jedná se o: vrn - pro numerické hodnoty (viz příloha priklady.zip/vrn.xml ) vrf - formalizované textové výsledky dle MTV vrs - formalizované strukturované výsledky dle MTV vrx - neformalizovaný textový výsledek - prostý text (viz příloha priklady.zip/vrx.xml ) vrk - formalizované strukturované výsledky mikrobiologické vrb - blok textu vrr - blok textu, sestava (včetně záhlaví a zápatí, viz příloha priklady.zip/vrr.xml ) vrd - pro datum - používá se výjimečně (pro přepisy) vrp prázdné vro - pro obraz - ve zkušebním provozu; pro zvuk a video - zatím nevyužíváno (viz příloha priklady.zip/vro.xml ) vrc - pro interpretace - připravuje se do další verze DS vrg - pro diagnózy - připravuje se do další verze DS Verze:

17 Element <garant_dat> je povinný, může být v bloku <dasta> nebo v bloku <v> Element <dat_du> - v některých případech se může stát, že se do tohoto elementu dostane i datum přijetí do laboratoře. V současném stavu datového standardu je tento element klíčovým pro určení, který z bloků <vr> v elementu <v> patří do jednoho vyšetření. Datum a čas události je: čas odběru vzorku krve (nebo jiného materiálu) čas ukončení sběru materiálu (zaznamenává se interval sběru) čas ukončení bilančního intervalu (pro sledování metabolických bilancí) čas odebrání vzorku pro kultivační vyšetření čas vzniku klinicky významné skutečnosti čas, k němuž jsou připraveny návrhy další terapie vycházející z údajů uvedených výše Atribut klic_nclp - tento klíč sdělované položky určuje obsah každého bloku <vr>. V bloku <v> se mohou objevovat duplicitně stejné bloky <vr>, které však reprezentují tzv. funkční testy a musí být dále rozlišeny obsahem atributu sci (specifikace příslušného sledování v časovém intervalu). Atribut id_lis - tento atribut by se měl stát v budoucnu povinným a mohl by nahradit určování skupin bloků <vr> podle dat_du. V současné verzi je ignorován. Atribut stav_vys patří mezi atributy, podle nichž lze určovat duplicitu příchozího vyšetření. Může nabývat následujících hodnot: R - Rozpracováno (výsledek není dosud kompletní) N - Neautorizovaný předběžný výsledek A - Autorizovaný (plnohodnotný) výsledek D - Autorizovaný výsledek s drobnou kolizí Z - Autorizovaný výsledek se zásadní kolizí K - Autorizovaný výsledek s kolizí blíže nerozlišenou P - Zařazeno do "přepisu" - bude zpracováno později E - Nebude zpracováno (důvod uveden v "kolizi") Protože jsou data zasílaná do systému ZDRAVEL garantována (<garant_dat>), neberou se v úvahu všechny hodnoty. Hodnoty lze dále setřídit do logických skupin - ADZKP; R; E Atribut ind_oprav_sd - ve smyslu určování zda se jedná o opravu či duplicitu je tento atribut důležitý. Může nabývat čtyř základních hodnot: N - Nejedná se o opravné sdělení Verze:

18 M - Doplnění informace z mikrobiologie E - Oprava původně chybně sdělené hodnoty S - Stornovat původně sdělenou chybnou hodnotu! Vzhledem k tomu, že se jedná o nepovinnou položku, tak v případě, že není uvedena, je chápána jako s implicitní hodnotou "N". Při zasílání diagnóz vázaných k laboratornímu vyšetření je nutné, aby blok <v> obsahoval pouze jedno vyšetření, tzn. vr bloky s identickým datem. Pokud toto nebude dodrženo, dojde při zpracování XML k chybě X Nepřípustná konstrukce datové struktury. Element <sci> Specifikuje příslušné sledování v časovém intervalu. Element se skládá z následujících prvků: id_sci_is - Označení konkrétního sledování v časovém intervalu v rámci IS - společná unikátní identifikace k sobě náležících vzorků. Může být použito číslo, text, DTS aj. klic_nclp - Klíč z NČLP slouží k elektronickému objednávání a sdělování příslušného sledování v časovém intervalu. Jsou přípustné pouze položky mající "vznik" = Q viz číselník [NCLPVZNK]. K této položce je vypracován postup, který jednoznačně definuje počátek, průběh a zakončení sledovaného intervalu včetně podrobného popisu jednotlivých kroků. krok - Jednotlivé kroky jsou ve vypracovaném postupu číslovány spojitě a jsou označeny jako povinné nebo fakultativní. Povinné musí být zpracovány vždy, fakultativní nemusí být realizovány. prubeh - Označení počátku a konce sledování v časovém intervalu je povinné. Pokud by konec nebyl vyznačen, je nutné tento kolizní stav řešit individuálně v IS příjemce (poslední průběžná položka bude označena jako "konec" - řeší se ve vazbě na vypracovaný postup) Urgentní informace <u> Přijímají se v bloku <u>. Jde o alergie, rizikové faktory, trvalé medikace, krevní skupinu, poslední očkování proti tetanu. Tyto údaje jsou také použity v emergentních kartách, které jsou určeny zdravotnickým pracovníkům záchranných služeb. V bloku <u> mohou být použity všechny vnořené bloky. Bloky <uks> a <uot> mohou být obsaženy pouze jednou, ostatní je možno použít vícenásobně. Element <garant_dat> je povinný, může být v bloku <dasta> nebo v bloku <u> Verze:

19 Bloky pro přenos urgentních informací: ua alergie (viz příloha ua.xml) urf - rizikové faktory (viz příloha urf.xml) utm - trvalá medikace (viz příloha utm.xml) uks - krevní skupina (viz příloha uks.xml) uot - poslední očkování proti tetanu (viz příloha uot.xml) Bloky <ua> a <urf> mají při komunikaci se ZDRAVELGate oproti definici DS povinné bloky <dat_du>. Pro bloky <utm> a <uks> jsou pak povinné bloky <dat_ab>. Blok <uks> dovoluje zaslat krevní skupinu buďto číselníkovou hodnotou v elementu <ks_rh> nebo volným textem v elementech <krevskup> a <rh>. V případě přítomnosti obou možností upřednostní ZDRAVELGate číselníkovou hodnotu před textovou. Příklad XML souboru s urgentními informacemi: viz příloha priklady.zip/urgent.xml Přílohy K vybraným výkonům lze přiložit přílohu. Pokud se XML odkazuje na stejný soubor dvakrát v různých výkonech, systém vrátí chybu (Chybí příloha). Pokud naopak existuje příloha, kterou nelze přiřadit k žádnému výkonu, systém vrátí chybu (Nalezená příloha nejde přiřadit). UPOZORNĚNÍ: Přestože je následující konstrukce přílohy (např. laboratorního vyšetření) přípustná v rámci DS3, pro příjemce ZDRAVEL je v rozporu s bezpečnostními principy a je zakázaná: <vro> </vro> <priloha zdroj=" typ="picture/jpg"></priloha> 3.4. Odpověď ZDRAVELGate Server vrací odpověď ve formátu XML. Výjimkou je zadání špatného uživatelského jména či hesla resp. nesplnění vstupních podmínek (např. limit velikosti). V takovém případě vrací server HTTP odpověď s hlavičkou 400 resp. 403 a tělem obsahujícím text resp Podle DS3 určuje atribut potvrzeni elementu dasta odesílaného souboru, zda odesílatel požaduje potvrzení přijetí souboru. Implicitní hodnota (pokud se atribut nevyskytuje) je "N" - nepožaduje. Verze:

20 Brána ZDRAVEL vrací odpověď vždy, atribut pouze určuje úroveň detailu Příklady odpovědí Atribut potvrzeni = "N" Příklad odpovědi OK: <?xml version='1.0' encoding='windows-1250' standalone='no'?> <dasta id_soubor="zdravel ZDRAVELGate_ " verze_ds=" " verze_nclp=" " bin_priloha="t" ur="t" typ_odesm="xx" ozn_soub=" " dat_vb=" t12:07:37"> <zdroj_is kod_firmy="zdravel " kod_prog="zdravelgate"/> <pm> <as typ="i"/> </pm> <pd id_soubor="abc0001" stav="a"> <as typ="i">zdravelgate</as> <dat_ps> t12:07:37</dat_ps> </pd> </dasta> Příklad odpovědi ERROR: <?xml version='1.0' encoding='windows-1250' standalone='no'?> <dasta id_soubor="zdravel ZDRAVELGate_ " verze_ds=" " verze_nclp=" " bin_priloha="t" ur="t" typ_odesm="xx" ozn_soub=" " dat_vb=" t12:06:06" > <zdroj_is kod_firmy="zdravel " kod_prog="zdravelgate" /> <pm> <as typ="i" ></as> </pm> <pd id_soubor="abc0001" stav="n" > <as typ="i" >ZDRAVELGate</as> <dat_ps> t12:06:06</dat_ps> </pd> </dasta> Původní řešení je plně podporováno a není nutná úprava (viz. níže). Verze:

21 Příklad odpovědi OK: <?xml version='1.0' encoding='windows-1250' standalone='no'?> <dasta id_soubor="izip IZIGate_ " verze_ds=" " verze_nclp=" " bin_priloha="t" ur="t" typ_odesm="xx" ozn_soub=" " dat_vb=" t12:07:37"> <zdroj_is kod_firmy="izip " kod_prog="izigate"/> <pm> <as typ="i"/> </pm> <pd id_soubor="abc0001" stav="a"> <as typ="i">izigate</as> <dat_ps> t12:07:37</dat_ps> </pd> </dasta> Příklad odpovědi ERROR: <?xml version='1.0' encoding='windows-1250' standalone='no'?> <dasta id_soubor="izip IZIGate_ " verze_ds=" " verze_nclp=" " bin_priloha="t" ur="t" typ_odesm="xx" ozn_soub=" " dat_vb=" t12:06:06" > <zdroj_is kod_firmy="izip " kod_prog="izigate" /> <pm> <as typ="i" ></as> </pm> <pd id_soubor="abc0001" stav="n" > <as typ="i" >IZIGate</as> <dat_ps> t12:06:06</dat_ps> </pd> </dasta> Atribut potvrzeni = "P" Server v tomto případě vrací stavový kód na úrovni jednotlivých výkonů s výjimkami, kdy dojde ke globální chybě vztahující se na celý XML soubor (např. chybějící přílohy), nebo dojde k chybě při zpracování celého bloku ip (např. neznámý pacient). Pokud nedojde ke zmíněným výjimkám, v atributu lokalizace bude rodné číslo pacienta následováno závorkami s názvem bloku, ke kterému se stavový kód vztahuje. U bloků z a v, respektive vr pak bude tento údaj v závorkách rozšířen o identifikaci zprávy v IS odesílatele (oznaceni_o nebo id_lis). Verze:

22 Příklad odpovědi OK: <?xml version='1.0' encoding='windows-1250' standalone='no'?> <dasta id_soubor="zdravel ZDRAVELGate_ " verze_ds=" " verze_nclp=" " bin_priloha="t" ur="t" typ_odesm="xx" ozn_soub=" " dat_vb=" t10:42:37" > <zdroj_is kod_firmy="zdravel " kod_prog="zdravelgate" /> <pm> <as typ="i" ></as> </pm> <pd id_soubor="abc0001" stav="a" > <chyba_pd kod="a00" lokalizace=" (an)" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a00" lokalizace=" (z )" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a00" lokalizace=" (vr-1/30/11/2001)" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a00" lokalizace=" (vr-2/30/11/2001)" osetreni="o" >OK</chyba_pd> <as typ="i" >ZDRAVELGate</as> <dat_ps> t10:42:37</dat_ps> </pd> </dasta> Příklad odpovědi ERROR: <?xml version='1.0' encoding='windows-1250' standalone='no'?> <dasta id_soubor="zdravel ZDRAVELGate_ " verze_ds=" " verze_nclp=" " bin_priloha="t" ur="t" typ_odesm="xx" ozn_soub=" " dat_vb=" t11:12:38" > <zdroj_is kod_firmy="zdravel " kod_prog="zdravelgate" /> <pm> <as typ="i" ></as> </pm> <pd id_soubor="abc0001" stav="n" > <chyba_pd kod="a00" lokalizace=" (an)" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a01" lokalizace=" " osetreni="o" >Pacient neznámý nebo s omezeným přístupem</chyba_pd> <chyba_pd kod="a00" lokalizace=" (z )" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a00" lokalizace=" (vr-1/30/11/2001)" osetreni="o" >OK</chyba_pd> <as typ="i" >ZDRAVELGate</as> <dat_ps> t11:12:38</dat_ps> </pd> </dasta> Původní řešení je plně podporováno a není nutná úprava (viz. níže). Příklad odpovědi OK: Verze:

23 <?xml version='1.0' encoding='windows-1250' standalone='no'?> <dasta id_soubor="izip IZIGate_ " verze_ds=" " verze_nclp=" " bin_priloha="t" ur="t" typ_odesm="xx" ozn_soub=" " dat_vb=" t10:42:37" > <zdroj_is kod_firmy="izip " kod_prog="izigate" /> <pm> <as typ="i" ></as> </pm> <pd id_soubor="abc0001" stav="a" > <chyba_pd kod="a00" lokalizace=" (an)" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a00" lokalizace=" (z )" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a00" lokalizace=" (vr-1/30/11/2001)" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a00" lokalizace=" (vr-2/30/11/2001)" osetreni="o" >OK</chyba_pd> <as typ="i" >IZIGate</as> <dat_ps> t10:42:37</dat_ps> </pd> </dasta> Příklad odpovědi ERROR: <?xml version='1.0' encoding='windows-1250' standalone='no'?> <dasta id_soubor="izip IZIGate_ " verze_ds=" " verze_nclp=" " bin_priloha="t" ur="t" typ_odesm="xx" ozn_soub=" " dat_vb=" t11:12:38" > <zdroj_is kod_firmy="izip " kod_prog="izigate" /> <pm> <as typ="i" ></as> </pm> <pd id_soubor="abc0001" stav="n" > <chyba_pd kod="a00" lokalizace=" (an)" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a01" lokalizace=" " osetreni="o" >Pacient neznámý nebo s omezeným přístupem</chyba_pd> <chyba_pd kod="a00" lokalizace=" (z )" osetreni="o" >OK</chyba_pd> <chyba_pd kod="a00" lokalizace=" (vr-1/30/11/2001)" osetreni="o" >OK</chyba_pd> <as typ="i" >IZIGate</as> <dat_ps> t11:12:38</dat_ps> </pd> </dasta> Seznam chyb dle DS3 I. - chyby nerozlišené Verze:

24 000 Chyba nerozlišená, popis v textu II. - chyby struktury a obsahu XML dokumentu X01 Dokument není "well formed XML" - nepárové značky, nepovolené znaky, aj. X02 Chybí povinná položka. X03 Neznámý atribut. X04 Neznámý element. X05 Nedovolené opakované použití. X99 Jiná/nerozpoznaná III. - chyby obsahu a vazeb údajů DS D01 Nevhodná délka (příliš dlouhé). D02 Neodpovídá povolenému výčtu hodnot. D03 Hodnota mimo přípustný rozsah. D04 Neodpovídá číselníku internímu nebo externímu = chybný kód z číselníku. D99 Jiná/nerozpoznaná IV. chyby obsahu (a vazeb) na úrovni aplikace A01 Chybný/neznámý identifikátor A99 Ostatní Přehled chybových návratových kódů HTTP odpovědi Požadavek neodpovídá základním vstupním podmínkám Chybné uživatelské jméno, heslo nebo přístupový kód Přehled návratových kódů ZDRAVEL A OK X Chybí identifikace zdravotnického zařízení A Zdravotnické zařízení neznámé nebo s omezeným přístupem X Chybí identifikace pacienta A Pacient neznámý nebo s omezeným přístupem X Chybná identifikace zdravotnického pracovníka A Zdravotnický pracovník neznámý nebo s omezeným přístupem X Chybí odbornost zdravotnického pracovníka A Chybná vazba zdravotnické zařízení / pracovník / odbornost A Špatný formát času A SQL chyba při vkládání údaje Verze:

25 A Neočekávaná chyba při vkládání údaje A Tento záznam již existuje v databázi A Tento typ záznamu nelze zapsat s touto odborností D Identifikace odesílatele se neshoduje s identifikací zdr. pracovníka v XML X Nepřípustná konstrukce datové struktury Zpracovaní dotazu odloženo. X Prázdné XML X Chybná struktura XML X Nepodporovaná či nekorektní verze DS nebo NČLP D Chybí příloha D Nalezená příloha nejde přiřadit X Vnitřní chyba při analýze XML A Chyba při uložení souboru D Nalezeny duplicity ve jménech souborů A Deklarovaným adresátem není ZDRAVEL (ZDRAVELGATE) X Nepřípustný čas vzniku XML A Chyba archivu A Příliš velký soubor XML A Příliš velká příloha D Neznámá nebo chybějící znaková sada Chyba na straně serveru Probíhá servisní zásah 3.5. Metodika reakce na návratové kódy a opakované odesílání Reakce na chybové návratové kódy HTTP odpovědi Požadavek neodpovídá základním vstupním podmínkám Opravit! Chybné uživatelské jméno, heslo nebo přístupový kód Opravit! Reakce na návratové kódy ZDRAVEL A OK Žádná reakce (pokud možno, žádná vizualizace v GUI zdrav. pracovníka) X Chybí identifikace zdravotnického zařízení Verze:

26 Opravit! <is ico=" ">... chybí zadané IČO v uvedeném elementu A Zdravotnické zařízení neznámé nebo s omezeným přístupem Zkontrolovat nastavení, případně pokud je nastavení správné, kontaktovat technickou podporu ZDRAVEL. <is ico=" ">... v ičo může být nesprávný počet číslic, případně jiné znaky, nebo ičo není registrováno X Chybí identifikace pacienta Opravit! <ip id_pac=" ">... chybí zadané id pacienta v uvedeném elementu A Pacient neznámý nebo s omezeným přístupem Použít ZDRAVELCheck. Pokud odpoví, že není registrován, zopakovat dotaz každých dní. Může být chyba v <ip id_pac=" ">... v id pacienta může být nesprávný počet číslic, případně jiné znaky X Chybná identifikace zdravotnického pracovníka Zkontrolovat nastavení, případně pokud je nastavení správné, kontaktovat technickou podporu ZDRAVEL a požádat o pomoc. <garant_dat id_garant=" " odbornost="001">... id_garant je prázdný A Zdravotnický pracovník neznámý nebo s omezeným přístupem Lékař musí zkontrolovat nastavení, případně kontaktovat technickou podporu ZDRAVEL. Ověřit zda není v systému zablokovaný. X Chybí odbornost zdravotnického pracovníka Zkontrolovat nastavení. <garant_dat id_garant=" " odbornost="001">... odbornost nevyplněná, nebo chybějící A Chybná vazba zdravotnické zařízení / pracovník / odbornost Zkontrolovat nastavení, případně kontaktovat ZDRAVEL pro doregistrování odbornosti. Verze:

27 Zkontrolovat zda zařízení má zaregistrované všechny odbornosti, zda je má zaregistrované zdravotnický pracovník, případně zda je zdravotnický pracovník zahrnut pod daným IČO. <garant_dat id_garant=" " odbornost="001">... odbornost může být nesprávně vyplněná. A Špatný formát času Opravit! Zkontrolovat formát času v elementech <dat_vb=" t05:07:05"> <dat_dn format="d"> </dat_dn> <an dat_ab="> t10:00:00"> <dat_ak> t05:06:56</dat_ak> Zkontrolovat zda čas vytvoření XML <dat_vb=" t05:07:05"> není starší než některá následující definice času a zda hodnota dat_vb není z budoucnosti A SQL chyba při vkládání údaje Poslat znovu druhý den, upozornit technickou podporu ZDRAVEL. Posílat každý následující den znovu, dokud neprojde. A Neočekávaná chyba při vkládání údaje Poslat znovu druhý den, upozornit technickou podporu ZDRAVEL. Posílat každý následující den znovu, dokud neprojde. A Tento záznam již existuje v databázi Neodesílat znovu! Popřípadě označit ve svém ZIS jako odeslaný. A Tento typ záznamu nelze zapsat s touto odborností Opravit! Chybná vazba odbornosti zdravotnického pracovníka na druh odesílaného záznamu. D Identifikace odesílatele se neshoduje s identifikací zdr. pracovníka v XML Opravit! garant_dat id_garant=" " odbornost="001">... id_garant neodpovídá údajům odesílatele Verze:

28 X Nepřípustná konstrukce datové struktury Opravit! Nemožno na dálku identifikovat, poslat na analýzu k vývojářům. V ostrém provozu se nesmí objevit. X Prázdné XML Byl odeslán prázdný soubor, nebo soubor s jiným obsahem. Případně zkusit znovu a nahlásit na technickou podporu ZDRAVEL. X Chybná struktura XML Opravit! Nemožno na dálku identifikovat chybu, poslat k analýze vývojářům. V ostrém provozu se nesmí taková chyba objevit. X Nepodporovaná či nekorektní verze DS nebo NČLP Opravit! Zkontrolovat... <!DOCTYPE dasta SYSTEM "ds dtd"> Zkontrolovat... příklad verze_ds=" " Zkontrolovat... příklad verze_nclp=" " D Chybí příloha Opravit! Nelze nalézt soubor přílohy deklarovaný v XML. D Nalezená příloha nejde přiřadit Opravit! Příloha není uvedena v XML X Vnitřní chyba při analýze XML Druhý den zkusit znovu a pokud neprojde, ohlásit na technickou podporu ZDRAVEL. Posílat každý následující den znovu, dokud neprojde. A Chyba při uložení souboru Druhý den zkusit znovu a pokud neprojde, ohlásit na technickou podporu ZDRAVEL. Verze:

29 Posílat každý následující den znovu, dokud neprojde. D Nalezeny duplicity ve jménech souborů Opravit! Zkontrolovat zda nejsou stejné názvy přiložených souborů A Deklarovaným adresátem není ZDRAVEL (ZDRAVELGate) Opravit! <vnitrni>zdravelgate</vnitrni>... element musí obsahovat ZDRAVELGate X Nepřípustný čas vzniku XML Opravit! <dat_vb=" t05:07:05">... chybný formát, nebo není deklarován, nebo je datum z budoucnosti A Chyba archivu Opravit! Jedná se o poškozený archiv. A Příliš velký soubor XML Opravit! Velikost souboru neodpovídá povolenému limitu A Příliš velká příloha Opravit! Velikost přílohy neodpovídá povolenému limitu D Neznámá nebo chybějící znaková sada Opravit! Pravděpodobně deklarovaná znaková sada neodpovídá skutečné. Verze:

30 Chyba na straně serveru Druhý den odeslat znovu, ohlásit na technickou podporu ZDRAVEL. Posílat každý následující den znovu, dokud neprojde Probíhá servisní zásah Druhý den odeslat znovu. Pak každý následující den znovu, dokud to neprojde 3.6. Formát času a data v DS3 Pokud se formát data v XML nesděluje, použije se implicitní hodnota DTS. Není-li vlastní sdělovaná hodnota data v tomto formátu, bude datum vyhodnoceno jako chyba A Špatný formát času. Stejnou chybu způsobí i zaslání výkonů, jejichž datum bude mladší než datum uvedené atributem dat_vb v elementu <dasta> Pokud DASTA definuje formát DTS, může být posláno pouze DTS DT, může být posláno DT nebo DTS DT nebo DTS, může být posláno DT nebo DTS D, může být posláno D,DT nebo DTS D nebo DT, může být posláno D,DT nebo DTS MR, může být posláno MR,D,DT nebo DTS R, může být posláno R,MR,D,DT nebo DTS D, MR nebo R, může být posláno R,MR,D,DT nebo DTS V blocích DS je používáno dat_os - odeslání souboru dat_ds - doručení souboru dat_ak - aktualizace elektronické karty dat_od - počátek časového období např. pojištění od dat_do - konec časového období např. pojištěn do dat_du - datum (čas) události - např. zjištění rizikového faktoru, odběr vzorku, datum očkování dat_dn - datum (čas) narození dat_de - datum (čas) úmrtí dat_ds - datum splatnosti dat_or - odečet (čas) reakce očkování dat_po - datum příštího očkování Verze:

31 dat_dv - datum předpokládaného dodání plnohodnotného výsledku (zařazeného do tzv. "přepisu") dat_za - datum (čas) žádosti dat_zt - datum (čas) zahájení transportu vzorku do laboratoře dat_pl - datum (čas) převzetí vzorku laboratoří (a zahájení zpracování) dat_vv - datum (čas) vydání výsledku laboratoří (odeslání výsledku) Jako atribut bloků DS je používáno dat_ab - aktualizace bloku, formát DTS dat_vb - vytvoření bloku, formát DTS Formát údaje D - datum YYYY-MM-DD DT - datum a čas YYYY-MM-DDTHH:MM DTS - datum a čas v sekundách YYYY-MM-DDTHH:MM:SS MR - měsíc a rok (neúplné datum) YYYY-MM R - rok (neúplné datum) YYYY 3.7. Odkazy Produkční server: Přihlašovací stránka: Přijímací brána ZDRAVELGate (datové rozhraní): Původní řešení je plně podporováno a není nutná úprava Testovací server: Přihlašovací stránka: Přijímací brána ZDRAVELGate (datové rozhraní): Verze:

32 Ověřování validnosti XML souborů: *Pro zobrazení návratových kódů je nezbytné vypnout zobrazování podrobných chybových zpráv protokolu HTTP v nastavení Internet Exploreru. 4. ZDRAVELCheck Brána ZDRAVELCheck slouží pro ověření existence klienta v databázi ZDRAVEL. Před vlastním odesláním dat na bránu by mělo předcházet ověření existence klienta pomocí brány ZDRAVELCheck. Tímto by se mělo zamezit odeslání informací o klientech, kteří nemají svou Zdravotní knížku. Komunikace probíhá posláním dotazu ve formátu XML na internetovou adresu popsanou v kapitole Komunikace s ZDRAVELCheck. Na tento dotaz bude bránou sestrojena odpověď buď ve formátu XML nebo CSV (dle požadavku odesílatele dotazu), která obsahuje identifikaci existujících klientů. Také je možné získat informace o počtu vyšetření klienta provedených odesílajícím zdravotnickým pracovníkem (ZP), jinými ZP nebo všemi ZP. IS zdravotnického pracovníka pomocí dotazu zašle požadavek na ověření existence klienta v databázi ZDRAVEL. Odpověď pak bude obsahovat rodná čísla klientů, kteří byli nalezeni v systému ZDRAVEL. Pokud bude v dotazu vznesen požadavek na vrácení počtu vyšetření provedených jednotlivým klientům, budou tyto informace zahrnuty v odpovědi ZDRAVELCheck brány. Na základě ověření existence klienta v databázi ZDRAVEL může IS zdravotnického pracovníka zaslat data na ZDRAVELGate pouze od těch klientů ZP, kteří jsou v systému ZDRAVEL přihlášení. Příklady dotazů a odpovědi naleznete v příloze zdravelcheck.zip. Popisy XML komunikace s bránou ZDRAVELCheck odpovídají konvencím DS Komunikace s ZDRAVELCheck Přihlašovací údaje Přihlašovací údaje na testovací server jsou po vyplnění žádosti automaticky zaslány na registrovanou ovou adresu. Před prvním odesíláním dat do systému ZDRAVEL je nezbytné, aby lékař (testovací lékař) provedl aktivaci účtu dle zaslaných pokynů přes webové rozhraní. Certifikáty k testovacímu serveru naleznete v příloze ca_internal_root.cer a ca_internal_sub.cer Verze:

33 Limit velikostí souborů XML a příloh Velikost každého jednotlivého souboru nesmí přesáhnout 2MB Celková velikost kolekce POST nesmí přesáhnout 8MB Pokud bude XML soubor zasílán komprimovaně, pak nesmí velikost původního (nekomprimovaného) souboru přesáhnout 2MB Pojmenovávání XML - dle DS3 Odesílatel zajistí vytváření jmen souborů, které nebudou po určitou vhodnou dobu duplicitní. Jméno datového souboru má strukturu: UTTXXXXX.KKK pro soubory "pakované" UTTXXXXX.xml pro soubory "nepakované" Jednotlivé znaky mají následující význam: U vyjadřuje určení = typ přenášených dat a v případě dat pacientů také urgentnost - viz "ur" v hlavním bloku dasta TT určuje typ odesílajícího místa - viz "typ_odesm" v hlavním bloku dasta a viz číselník [TAB_TO] XXXXX pokud není soubor zasílán ÚZIS, pak libovolný řetězec neobsahující mezery, který je sestavený z číslic a běžných písmen anglické abecedy viz "ozn_soub" v hlavním bloku dasta (označení souboru), jinak viz dále KKK určuje program, kterým bylo zapakováno*. ZDRAVELCheck podporuje kompresi ZIP a RAR HTTP transakce Transakce probíhá ve 4 krocích: ustavení tcp/ip spojení odeslání http požadavku obdržení odezvy ukončení spojení HTTP požadavek Požadavek se skládá z hlavičky a těla. Verze:

34 Hlavička From: Host: cil_server:port Content-Length: 1427 Content-Type: multipart/form-data; boundary=7d1a Parametr "from" by měl obsahovat ovou adresu odesílatele, parametr "Host" musí obsahovat cílovou adresu serveru. Pro bezchybnou komunikaci je zde potřeba správně nastavit zejména hodnotu parametru Content-Length, která má význam délky následujícího těla v bytech. Parametr Content-Type obsahuje kromě pevného nastavení typu multipart/form-data důležitý údaj boundary. Tento údaj obsahuje textový řetězec, který se nesmí vyskytovat ve vlastních přenášených datech. Obsah boundary nastavuje klient. Tělo --7d1a Content-Disposition: form-data; name="typ_imp" 9 --7d1a Content-Disposition: form-data; name="idc_zp" d1a Content-Disposition: form-data; name="prist_heslo" dff1649a... (MD5 hodnota přístupového hesla) --7d1a Content-Disposition: form-data; name="osobni_heslo" cfa1649a... (MD5 hodnota osobního hesla) --7d1a Content-Disposition: form-data; name="xmlfile"; filename="nazev_souboru.xml" Content-Type: application/octet-stream <?xml version='1.0' encoding='windows-1250' d1a Komunikační modul přidává automaticky typ_imp=2. Pokud implementujete odesílání sami a nepoužíváte komunikační modul, jste povinni použít typ_imp= Identifikace odesílatele idc_zp identifikuje odesílatele, který musí být zdravotním pracovníkem registrovaným v systému ZDRAVEL. Verze:

35 prist_heslo (přístupové heslo) a osobni_heslo (osobní heslo) se předpokládá zahashované algoritmem MD5 - osobní heslo musí být před hashováním v kódové stránce Windows Hexadecimální číslice se předpokládají malými písmeny. Jak je vidět, musí být boundary příslušné hlavičky opatřeno v těle požadavku navíc prefixem --. Ten samý řetězec je pak přidán i za poslední výskyt boundary v těle. Z ukázky je rovněž zřejmý způsob přenosu jednotlivých údajů. Za uvedením boundary následují řádky s parametry Content-Disposition, případně Content-Type a jeden prázdný řádek, za kterým je uveden obsah údaje. Parametr Content-Disposition obsahuje dispozici údaje, obsahující zejména řetězec formdata a název příslušného údaje. Jednotlivé zde použité elementy jsou navzájem odděleny středníkem. Parametr Content-Type je použit u údajů, jejichž obsahem je samotný obsah datových souborů. V tomto případě má tento parametr hodnotu application/octet-stream Dotaz na ZDRAVELCheck 4-1 Element <dotaz> Atribut D V Popis Hodnota Poznámka td Typ dotazu klcheck pro případné rozšíření funkcionality, v současné době je akceptována pouze jedna hodnota idzp identifikační číslo zdravotního pracovníka odesílajícího požadavek řetězec o délce 9 nebo 10 znaků pro účely ZDRAVEL je identifikační číslo shodné s RČ lékaře tv -7? typ vyšetření vsechny, vlastni, cizi pokud není uvedeno, nebude počet vyšetření zahrnut do výsledku - viz pokyny 01 fv - 35? formát výsledku csv, xmltag, xmlatr pokud není známo použije se xmlatr - viz pokyny 02 akt 1? dotaz na status aktivace klienta A viz pokyny 03 Element D V Popis Hodnota Poznámka Verze: