Datové a komunikační rozhraní nemocničních informačních systémů

Podobné dokumenty
emedocs veřejné datové rozhraní

PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S.

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5

eneschopenka technické řešení Pavel Borkovec ČSSZ, Křížová 25, Praha Architekt, Asseco Central Europe

Národní registr léčby uživatelů drog

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci

ERP-001, verze 2_10, platnost od

Požadavky pro výběrová řízení TerraBus ESB/G2x

Titul: API klinického informačního systému pro napojení na ISAC Communication Node. Typ dokumentu: Specifikace aplikačního rozhraní

Návrh funkcí webových služeb (WS) pro komunikaci mezi Informačním systémem datových schránek (ISDS) a spisovými službami (SS)

Referenční rozhraní národního konektoru Národního kontaktního místa pro ehealth úloha pacientský souhrn

Popis B2B rozhraní pro elektronickou neschopenku

Datový standard MZ ČR a NČLP v praxi, současný stav a další rozvoj (březen 2008) Miroslav Zámečník Katedra klinické biochemie, IPVZ Praha

CÚeR a RLPO Workshop č SÚKL

KSRZIS. Postup kroků nutných pro napojení nemocničního informačního systému s registrem NSHNU v prostředí registrů resortu zdravotnictví

Vstupní brány ZDRAVELGate, ZDRAVELCheck a ZDRAVELView

Datové úložiště referenčních nemocnic (DÚ RN): Zajištění sběru dat v roce Petr Klika a kol., ÚZIS ČR

POPIS DATOVÉHO ROZHRANNÍ PRO IMPORT DAT DO ASW PRO SLEDOVÁNÍ DEKUBITŮ

Aplikace pro elektronicke odesla nı da vky Listu o prohlı dce zemr ele ho a dals ı ch da vek do NZIS.

emedocs Exchange Medical Document System David Zažímal Petr Pavlinec

POPIS TECHNICKÉHO ŘEŠENÍ INFORMAČNÍHO SYSTÉMU PRO SBĚR DAT V PROJEKTU SLEDOVÁNÍ DEKUBITŮ JAKO INDIKÁTORU KVALITY OŠETŘOVATELSKÉ PÉČE NA NÁRODNÍ ÚROVNI

ADIS Opt-Out rozhraní na okolní systémy. Technický popis rozhraní s pojišťovnami

PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S.

SDÍLENÍ - VÝMĚNA -ARCHIVACE. Petr Siblík

Validace souborů DS3

Koordinační středisko pro resortní zdravotnické informační systémy

TRANSPORTY výbušnin (TranV)

STÁTNÍ ÚSTAV PRO KONTROLU LÉČIV

Výkaznictví sw změny a úpravy 2011

Dokumentace k nevizuálnímu rozhraní aplikace DopisOnline

Metodika sestavení případu hospitalizace 010

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

Dokumentace pro výrobce SW DIS13 - WS

Úvod do Web Services

VZOROVÝ STIPENDIJNÍ TEST Z INFORMAČNÍCH TECHNOLOGIÍ

Chybová hlášení METODIKA MET-01/2014. SZR-56-1/OPICT-2013 počet stran 28 přílohy 0. Nahrazuje:

eneschopenka Pavel Borkovec technické řešení ČSSZ, Křížová 25, Praha Architekt, Asseco Central Europe

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech:

Metodika sestavení případu hospitalizace

emedocs CHYTRÉ regionální ehealth řešení Michal Opatřil ICZ a.s. 1

Platební systém XPAY [

Metodický pokyn k uvedení registru do produkčního provozu

Metodika sestavení případu hospitalizace

7. Aplikační vrstva. Aplikační vrstva. Počítačové sítě I. 1 (5) KST/IPS1. Studijní cíl. Představíme si funkci aplikační vrstvy a jednotlivé protokoly.

Registrační číslo projektu: CZ.1.07/1.5.00/ Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

STÁTNÍ ÚSTAV PRO KONTROLU LÉČIV

Elektronická komunikace s CSÚIS. Jak to řeší Fenix

VYHLÁŠKA. ze dne o provedení některých ustanovení zákona o léčivech týkajících se elektronických receptů

k provedení některých ustanovení zákona o léčivech týkajících se elektronických receptů

Způsob vytváření identifikačních znaků

mbank.cz mtransfer Okamžitá notifikace o mtransferu Dokumentace pro externího partnera

Popis egon služby. E177 - iszrctireklamaci. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

Administrativní data pacienta

VYHLÁŠKA ze dne 30. listopadu 2017 k provedení některých ustanovení zákona o léčivech týkajících se elektronických receptů

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

Přehled služeb CMS. Centrální místo služeb (CMS)

Příloha č. 1: Charakteristika zakázky pro věcnou část zadávací dokumentace

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci

nástroj pro jednoduchou správu a vedení agendy studentských počítačových sítí na kolejích SU OPF Karviná Ing.

PROBLEMATIKA E-RECEPTU Z POHLEDU LÉKAŘE

CO JE NOVÉHO V SYSTÉMECH DUNA DENTA

[ 1 ] Ing. Tomáš Melen náměstek pro informatiku a ekonomiku 2009 Státní ústav pro kontrolu léčiv

Ing. Jitka Dařbujanová. , SSL, News, elektronické konference

Referenční rozhraní. Jiří Kosek. Ministerstvo informatiky ČR. ISSS 25. března 2003

SSL Secure Sockets Layer

3.17 Využívané síťové protokoly

Specifikace softwarového projektu

Příloha č. 4 Obchodní podmínky pro poskytování služby DopisOnline

Bezpečnostní aspekty informačních a komunikačních systémů KS2

Elektronické pacientské dotazníky v ezprávě

Komunikační rozhraní SEP 1.6

Elektronická evidence tržeb. Produkční prostředí Přístupové a provozní informace

StaproFONS. Petr Siblík. Objednávání pacientů

JAK ČÍST ZÁZNAM O VYUŽÍVÁNÍ ÚDAJŮ V REGISTRU OBYVATEL

Postup při registraci (autentizaci) OVM do informačního systému evidence přestupků (ISEP)

Koncept zprovoznění nového řešení

Popis egon služ by. E219 - rppctieditoraovmspuu. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

Národní elektronický nástroj. Import profilu zadavatele do NEN

Stanovit nezbytná pravidla pro tvorbu dokumentace vytvářenou ve SITRONICS centru využitelnou firmou SITRONICS TS.

12. Bezpečnost počítačových sítí

Popis egon služby. E23 - roszapisdatovouschranku. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

Zavedení EZD. a praktické využití sdílení dat mezi ZZ

IS SDSL Dálkový způsob ověření totožnosti a věku osoby žádající o registraci Praha, Martin Prem

Uživatelská příručka Popis postupu nastavení zabezpečené komunikace s CDS pomocí aplikace MS Outlook 2003

Internet Information Services (IIS) 6.0

Zrušení profilu zadavatele

Lékaři léčí, my se staráme

Specifikace požadavků. POHODA Web Interface. Verze 1.0. Datum: Autor: Ondřej Šrámek

Příloha č. 1 Smlouvy o spolupráci B2B rozhraní VZP ČR

1 Pro účely této vyhlášky se rozumí a) základnovou stanicí základnová stanice veřejné komunikační sítě,

MD Comfort. Ambulantní software. Řešení pro praktické a odborné lékaře a pro sítě zdravotnických zařízení

Definice pojmů a přehled rozsahu služby

Popis egon služ by. E218 - rppctizmenyovmspuu. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

RESTful API TAMZ 1. Cvičení 11

Transkript:

Datové a komunikační rozhraní nemocničních informačních systémů verze 1.0 25. září 2012

Historie dokumentu Verze Datum Změnil Popis změn Verze 1.0 Strana 1

OBSAH HISTORIE DOKUMENTU... 1 OBSAH... 2 1 ÚVOD... 3 1.1 SHRNUTÍ... 3 1.2 POUŽITÉ ZKRATKY A TERMINOLOGIE... 3 2 FORMÁT DATOVÉHO OBSAHU ZPRÁV... 4 2.1 METODIKA KONVERZACE MEZI SYSTÉMY... 4 2.2 POPIS STRUKTURY DATOVÉ ZPRÁVY... 5 2.2.1 Elementy zprávy pro předání zdravotních údajů pacienta... 7 2.2.1.1 Urgentní informace... 7 2.2.1.2 Trvalé diagnózy... 7 2.2.1.3 Hospitalizace (reprezentovaná propouštěcí zprávou)... 7 2.2.1.4 Ambulantní vyšetření... 7 2.2.1.5 EKG vyšetření... 7 2.2.2 Správné používání atributů v DS4... 8 2.3 PŘÍKLADY DATOVÝCH ZPRÁV... 8 2.3.1 zadanka_4.07.01.xml... 8 2.3.2 zprava_4.07.01.xml... 9 3 KOMUNIKAČNÍ PROTOKOL A FORMÁT ZPRÁV... 13 3.1 PŘÍKLAD SOAP ZPRÁVY DOTAZ... 13 3.2 PŘÍKLAD SOAP ZPRÁVY ODPOVĚĎ... 13 3.3 POPIS ELEMENTŮ SOAP ZPRÁV... 15 3.4 ROZŠÍŘENÍ FORMÁTU SOAP ZPRÁV... 15 3.4.1 Příklad rozšířené SOAP zprávy... 15 4 ZABEZPEČENÍ KOMUNIKACE... 16 4.1 VPN... 16 4.2 PROTOKOL HTTPS... 16 4.3 OVĚŘENÍ IDENTITY KOMUNIKUJÍCÍCH STRAN... 16 4.4 LOGOVÁNÍ... 16 PŘÍLOHY... 18 Verze 1.0 Strana 2

1 Úvod 1.1 Shrnutí Tento dokument popisuje formáty a zabezpečení zpráv předávaných mezi nemocničním informačním systémem (NIS) a navazujícím externím systémem. Tyto zprávy budou sloužit k vyžádání pacientských dat externím systémem a k jejich přenosu z NIS do externího systému pro potřeby zobrazení v koncových aplikacích. Rozhraní musí garantovat odpověď na dotaz do 6 sekund alespoň v 80 % případů. 1.2 Použité zkratky a terminologie Termín Autentizace Identifikace HTTP HTTPS SOAP Definice Ověření platnosti identifikace s požadovanou mírou záruky, tj. akt zjištění, že proklamovaná identita je pravdivá. Akt ustanovení totožnosti (identity). Hyper Text Transfer Protokol - Aplikační protokol pro distribuované, hypermediální informační systémy. Je to generický, bezstavový, objektově orientovaný protokol, pomocí rozšířených příkazů použitelný pro celou škálu úloh, jako například jmenné servery nebo distribuované administrátorské systémy. Typickou vlastností HTTP je definice a dohoda komunikujících stran o datových reprezentacích, což umožňuje návrh informačních systémů, nezávislý na povaze přenášených dat. Bezpečná verze protokolu HTTP, založená na vrstvě SSL. Simple Object Access Protocol je protokolem pro výměnu zpráv založených na XML přes síť, hlavně pomocí HTTP. Symbol Vysvětlení Symbolizuje upozornění, vysvětlení nebo poznámku. dasta -> pm Tento typ písma symbolizuje zápis zdrojového kódu nebo datového standardu. Verze 1.0 Strana 3

2 Formát datového obsahu zpráv Použitým datovým formátem pro vyžádání pacientských dat externím systémem a jejich odeslání z NIS je český národní datový standard DASTA ve verzi 4. 2.1 Metodika konverzace mezi systémy Externí aplikace posílá dotaz (request) do NISu k poskytnutí údajů. Ve výzvě se předává jeden údaj identifikace pacienta (dále ID_PAC). Citace z definice zvoleného přenosového protokolu DASTA 4: Do položky id_pac je vkládáno (v tomto pořadí): rodné číslo pacienta, pokud toto existuje a je zároveň číslem pojištěnce (v délce 9 nebo 10 znaků bez lomítka a bez koncové mezery u devítimístných čísel) číslo pojištěnce uvedené v IS odesílatele, pokud existuje NIS na tento dotaz reaguje odpovědí (response) v těchto variantách: 1. NIS toto ID_PAC nezná a odpovídá příslušnou chybovou hláškou. 2. NIS toto ID_PAC eviduje jednoznačně a odesílá požadované lékařské údaje plus jméno, příjmení, datum narození a trvalé bydliště pro vyloučení omylu, že je pod tímto ID_PAC evidován v NIS někdo jiný. 3. NIS toto ID_PAC eviduje duplicitně a odesílá bližší identifikaci duplicitních pacientů. Externí aplikace tak může např. prezentovat tyto duplicitní záznamy s rozlišovacími údaji jméno, příjmení, datum narození a trvalé bydliště, a reagovat upřesňujícím dotazem. Poznámka: Logicky, pokud daný NIS nepřipouští svým datovým modelem duplicitu ID_PAC, nemusí jeho NIS konektor řešit část komunikace o konkretizaci pacienta. V komunikaci se jedná o 4 typy souborů DS4: 1. dotaz ext. aplikace -> NIS 2. odpověď NIS -> ext. aplikace s označením chyby (případné) 3. odpověď NIS -> ext. aplikace pouze s identifikací pacientů NIS -> centrála (případné) 4. odpověď NIS -> ext. aplikace s požadovanými zdravotními údaji jednoho pacienta (údaje jsou z pohledu NISu v kompletním tvaru, neuvažuje se posílání dokumentace po částech) Externí aplikace pak zajistí zpracování a případnou prezentaci údajů vhodnou formou. Poznámka: Je požadováno, aby NIS posílal dostupné informace za poslední rok. Protože ale mají některé zprávy větší váhu, je doporučeno, aby některé informace byly v zobrazení protežovány. Doporučená posloupnost priorit zobrazení: 1. identifikace pacienta 2. urgentní blok Verze 1.0 Strana 4

3. trvalé diagnózy (z NISu poskytnuté přímo patřičným prvkem) 4. diagnózy prodělané za poslední rok (vyčtené z KU_Z) 5. anamnéza souhrnná 6. poslední EKG 7. poslední propouštěcí zpráva 8. chronologicky od nejčerstvějšího hospitalizace/prop.zprávy 9. následované amb. vyšetřeními Poznámka: Od 1.7.2012 obsahuje DS4 funkcionalitu žádosti o údaje a odeslání požadovaných údajů. Údaje, které jsou již nyní definicí pojmenovatelné, budou externí aplikací vyžádány označením těchto údajů ve výzvě. Údaje, které jsou v definici DS4 ve fázi schvalování, či úplně chybí, se budou sdělovat na základě domluvy zúčastněných stran. Většina prvků je z důvodu nekladení nepřekonatelných překážek v definici DS4 nepovinná, a staví se na domluvě komunikujících stran, jaká data budou v datové zprávě vyplňována. V rámci této technické dokumentace pro implementaci NIS konektoru jsou požadované prvky v následující kapitole uvedeny a jsou pro tento účel povinné, pokud je daný NIS ve svých datech má začleněny a pokud je daný pacient má vyplněny. 2.2 Popis struktury datové zprávy Všechny uváděné bloky, elementy a atributy jsou uváděny přesným označením prvku v definici DS 4.07.01. Definice je zpracována hypertextově, obsahuje podrobné pokyny a výčty přípustných hodnot s vysvětlením. V současné době je definice dostupná na http://ciselniky.dasta.mzcr.cz/ Všechny typy souborů mají obvyklým způsobem přítomny a vyplněny bloky dasta dasta -> pm dasta -> is Identifikace příjemce i odesílatele bude po domluvě komunikujících stran nastavena v parametrech jednotlivých systémů. Poznámka: Protože se předpokládá, že výzva externí aplikací není směřována konkrétnímu pracovišti nemocnice, ale nemocnici jako celku, doporučujeme zavést fiktivní oddělení, reprezentující celou nemocnici, na které bude výzva směrována. Externí aplikace musí tyto údaje znát. NIS u fiktivního oddělení použije icp = icz, oddel lze využít pro zajištění jednoznačnosti, jedná se o jakýkoli domluvený symbol. Identifikace odesílatele i adresáta je pomocí údajů: dasta -> pm -> icz dasta -> pm -> icp dasta -> pm -> oddel dasta -> is -> icz dasta -> is -> icp dasta -> is -> oddel. Verze 1.0 Strana 5

Výzva i odpověď s nabídkou pacientů si vystačí s vnořeným blokem dasta -> is -> ip, elementy id_pac jmeno prijmeni dat_dn. V případě odpovědi, odpovědi s nabídkou pacientů či konkretizující výzvy se použije i element adres dasta -> is -> ip -> a, podelementy typ = 1.. trvalé bydliště pacienta adr psc mesto Pokud NIS požadované ID_PAC nezná, odpoví chybovým elementem dasta -> pd dasta -> pd -> chyba_pd dasta -> pd -> chyba_pd -> kod Poznámka: V současné době neexistuje kód pro tento účel, je však v metodice DS4 popsáno, že se budou kódy dle potřeby rozšiřovat, takže byl vznesen požadavek na Ing. Zámečníka (koordinátor rozvoje DASTA za MZ ČR). Do zařazení kódu chyby do definice DS4 se použije: kod = 000 popis = nezname id_pac V případě výzvy s konkretizací požadovaných zdravotních údajů bude přítomen blok: dasta -> is -> ip -> ku -> ku_o typku = VYPIS.ZPRAV dasta -> is -> ip -> ku -> ku_o -> ku_o_vypis Časový rozsah a typ dat bude stanoven: dasta -> is -> ip -> ku -> ku_o -> ku_o_vypis -> dat_vypis_od dasta -> is -> ip -> ku -> ku_o -> ku_o_vypis -> dat_vypis_do dasta -> is -> ip -> ku -> ku_o -> ku_o_vypis -> typ_ku Poznámka: V současné době nelze vyžádat maximální nebo minimální počet zpráv, proto předkládáme návrh Ing. Zámečníkovi o zařazení elementů dasta -> is -> ip -> ku -> ku_o -> ku_o_vypis -> min_pocet dasta -> is -> ip -> ku -> ku_o -> ku_o_vypis -> max_pocet čímž se vyřeší požadavek alespoň na jednu propouštěcí zprávu, byť by byla starší jednoho roku. Totéž pro vyšetření EKG. Do zařazení těchto elementů do definice DS4 se bude ctít pravidlo, že se odešle alespoň jedna propouštěcí zpráva a alespoň jedno vyšetření EKG (samozřejmě pokud je v NIS obsaženo). Verze 1.0 Strana 6

Poznámka: V současné verzi DS4 lze žádat vyšetření reprezentovaná klinickou událostí. U r- gentní informace však nejsou řešeny klinickou událostí. Pro účel implementace NIS konektoru bude platit pravidlo, že při jakékoli žádosti o dokumentaci, se rovnou připojí i urgentní údaje. Toto pravidlo bude navrženo k legalizaci do definice DS4. Poznámka: Uživatel (příjemce dat z NIS) má speciální zájem o poslední vyšetření EKG, což je bohužel typ vyšetření, které doposud nemá své TYPKU v DS4, ale je již v seznamu návrhů. Vznášíme požadavek na legalizaci do DS4. Do té doby bude vyšetření EKG v odesílané odpovědi označeno pomocí dasta -> is -> ip -> ku -> ku_z -> typkuspeclok volným textem vysetreni EKG, což využívá záměr tohoto atributu na upřesnění, pokud typku není dostatečně použitelný. Zda vyšetření EKG je možno vyselektovat ze zdrojové databáze NISu je zcela na vlastnostech a možnostech konkrétního NIS. 2.2.1 Elementy zprávy pro předání zdravotních údajů pacienta Odpověď se zdravotními údaji pacienta využívá pro jejich předání elementy: 2.2.1.1 Urgentní informace dasta -> is -> ip -> u, elementy ua... alergie urf... rizikové faktory utm... trvalé medikace uks... krevní skupina (nebylo přímo zmiňováno, ale do urg. patří) uot... očkování proti tetanu (nebylo přímo zmiňováno, ale do urg. patří) 2.2.1.2 Trvalé diagnózy dasta -> is -> ip -> dg 2.2.1.3 Hospitalizace (reprezentovaná propouštěcí zprávou) dasta -> is -> ip -> ku -> ku_z Propouštěcí zpráva má typku=h.propz Pokud bude mít pacient v dokumentaci NIS hospitalizaci bez propouštěcí zprávy (např. pacient na propustce), zašle se příjmová hospitalizační zpráva (typku=h.prijz), aby byla předána informace i o této hospitalizaci. 2.2.1.4 Ambulantní vyšetření dasta -> is -> ip -> ku -> ku_z Ambulantní vyšetření má typku=amb.vys 2.2.1.5 EKG vyšetření (EKG označeno atributem typkuspeclok viz výše) Verze 1.0 Strana 7

2.2.2 Správné používání atributů v DS4 Z pravidel DS upozorňujeme na správné používání atributů dasta -> is -> ip -> ku -> ku_o -> idsub dasta -> is -> ip -> ku -> ku_o -> idku dasta -> is -> ip -> ku -> ku_z -> idsub dasta -> is -> ip -> ku -> ku_z -> idku což jsou vazební prvky mezi žádostí o dokumentaci a dokumentací odesílanou (popsáno v definici DS4). 2.3 Příklady datových zpráv 2.3.1 zadanka_4.07.01.xml <?xml version="1.0" encoding="windows-1250" standalone="no"?> <ds:dasta xmlns:ds="urn:cz-mzcr:ns:dasta:ds4:ds_dasta" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:dsip="urn:czmzcr:ns:dasta:ds4:ds_ip" xsi:schemalocation="urn:cz-mzcr:ns:dasta:ds4:ds_dasta http://ciselniky.dasta.mzcr.cz/xmlschema/ds_dasta-4.03.01.xsd urn:czmzcr:ns:dasta:ds4:ds_ip http://ciselniky.dasta.mzcr.cz/xmlschema/ds_ip-4.04.01.xsd" id_soubor="hicorp LIT999RXX02O4Y2012-09-18T12:39" verze_ds="04.07.01" verze_nclp="02.01.01" bin_priloha="t" ur="r" typ_odesm="xx" ozn_soub="rxx02" potvrzeni="n" dat_vb="2012-09-18t12:39:01"> <ds:zdroj_is kod_firmy="hicorp " kod_prog="lit" verze_prog="999" liccis_prog="001"/> <ds:pm ico="00830488" icz="55021000" icp="55021137" oddel="47a79" pcz="0"> <ds:as poradi="1" typ="t"/> <ds:a typ="p"> <ds:jmeno>konsilia ARO</ds:jmeno> <ds:adr>brno, Žitenická 188</ds:adr> <ds:psc>60200</ds:psc> <ds:as poradi="1" typ="t"/> </ds:a> </ds:pm> <ds:is ico="00830488" icz="55021000" icp="55021953" oddel="20a79"> <ds:as poradi="1" typ="t"/> <ds:a typ="o"> <ds:jmeno>nemocnice LTM</ds:jmeno> <ds:adr>měn LTM, Žitenická 18</ds:adr> <ds:psc>41241</ds:psc> <ds:as poradi="1" typ="t"/> </ds:a> <dsip:ip id_pac="121212121"> <dsip:rodcis>121212121</dsip:rodcis> <dsip:jmeno>pokus</dsip:jmeno> <dsip:prijmeni>pokusník</dsip:prijmeni> <dsip:dat_dn format="d">1912-12-12</dsip:dat_dn> <dsip:ipi_o cis_is="222327"/> <ds:a typ="1"> <ds:jmeno>pokusník Pokus</ds:jmeno> </ds:a> <dsip:pv_pac typ_pv="zp"> <dsip:pv_zp> <dsip:cispoj>121212121</dsip:cispoj> <dsip:kodpoj>999</dsip:kodpoj> </dsip:pv_zp> </dsip:pv_pac> <dsip:ku> <!-- žádost o dokumentaci --> <dsip:ku_o typku="konz" fazespec="or" idku="hicomp.lit.000000000002emo.3333333"> <dsip:dat_poz typ="l">2012-09-18t12:38:00</dsip:dat_poz> <dsip:dat_prov_od typ="l">2011-09-18t12:38</dsip:dat_prov_od> Verze 1.0 Strana 8

<dsip:dat_prov_do typ="l">2012-09-18t12:38</dsip:dat_prov_do> <dsip:z_pracoviste kod_lok="2304 " icz="55021000" icp="55021953" odb="501" ns="a2304"> <dsip:nazev>chirurgie - ambulance konzilia</dsip:nazev> </dsip:z_pracoviste> <dsip:z_pracovnik icl="99999999" id_pracovnik="1"> <dsip:titul_pred>mudr.</dsip:titul_pred> <dsip:jmeno>pavel</dsip:jmeno> <dsip:prijmeni>marek</dsip:prijmeni> </dsip:z_pracovnik> <dsip:text_zadosti> <dsip:ptext xml:space="preserve">![cdata[žádost o dokumentaci]]</dsip:ptext> </dsip:text_zadosti> </dsip:ku_o> </dsip:ku> </dsip:ip> </ds:is> </ds:dasta> XML soubor této zprávy je také přílohou dokumentu. 2.3.2 zprava_4.07.01.xml <?xml version="1.0" encoding="windows-1250" standalone="no"?> <ds:dasta xmlns:ds="urn:cz-mzcr:ns:dasta:ds4:ds_dasta" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:dsip="urn:czmzcr:ns:dasta:ds4:ds_ip" xsi:schemalocation="urn:cz-mzcr:ns:dasta:ds4:ds_dasta http://ciselniky.dasta.mzcr.cz/xmlschema/ds_dasta-4.03.01.xsd urn:czmzcr:ns:dasta:ds4:ds_ip http://ciselniky.dasta.mzcr.cz/xmlschema/ds_ip-4.04.01.xsd" id_soubor="hicorp LIT999RXX02O4Y2012-09-18T12:39" verze_ds="04.07.01" verze_nclp="02.01.01" bin_priloha="t" ur="r" typ_odesm="xx" ozn_soub="rxx02" potvrzeni="n" dat_vb="2012-09-18t12:39:01"> <ds:zdroj_is kod_firmy="hicorp " kod_prog="lit" verze_prog="999" liccis_prog="001"/> <ds:pm ico="00830488" icz="55021000" icp="55021137" oddel="47a79" pcz="0"> <ds:as poradi="1" typ="t"/> <ds:a typ="p"> <ds:jmeno>konsilia ARO</ds:jmeno> <ds:adr>brno, Žitenická 188</ds:adr> <ds:psc>60200</ds:psc> <ds:as poradi="1" typ="t"/> </ds:a> </ds:pm> <ds:is ico="00830488" icz="55021000" icp="55021953" oddel="20a79"> <ds:as poradi="1" typ="t"/> <ds:a typ="o"> <ds:jmeno>nemocnice LTM</ds:jmeno> <ds:adr>měn LTM, Žitenická 18</ds:adr> <ds:psc>41241</ds:psc> <ds:as poradi="1" typ="t"/> </ds:a> <dsip:ip id_pac="121212121"> <dsip:rodcis>121212121</dsip:rodcis> <dsip:jmeno>pokus</dsip:jmeno> <dsip:prijmeni>pokusník</dsip:prijmeni> <dsip:dat_dn format="d">1912-12-12</dsip:dat_dn> <dsip:ipi_o cis_is="222327"/> <ds:a typ="1"> <ds:jmeno> Pokusník Pokus</ds:jmeno> </ds:a> <dsip:pv_pac typ_pv="zp"> <dsip:pv_zp> <dsip:cispoj>121212121</dsip:cispoj> Verze 1.0 Strana 9

<dsip:kodpoj>999</dsip:kodpoj> </dsip:pv_zp> </dsip:pv_pac> <dsip:p ind_oprav_sd="n"> <dsip:cispoj>121212121</dsip:cispoj> <dsip:kodpoj>999</dsip:kodpoj> </dsip:p> <!-- urgentní informace --> <dsip:u> <dsip:garant_dat id_garant="7812082113" odbornost="801">mudr. Jmeno Prijmeni</dsip:garant_dat> <dsip:ua dat_ab="2005-12-01t12:53:12" ind_oprav_sd="n"> <dsip:u_al>ampicilin</dsip:u_al> <dsip:autor>mudr. Jmeno Prijmeni</dsip:autor> <dsip:dat_du format="d" typ="i">1999-09-11</dsip:dat_du> <dsip:dat_ak>2005-08-11t09:15:12</dsip:dat_ak> </dsip:ua> <dsip:urf dat_ab="2005-12-01t12:53:12" ind_oprav_sd="n"> <dsip:u_rf>hyperlipoproteinemie</dsip:u_rf> <dsip:autor>mudr. Jmeno Prijmeni</dsip:autor> <dsip:dat_du format="d" typ="i">1999-09-11</dsip:dat_du> <dsip:dat_ak>2005-08-11t09:15:12</dsip:dat_ak> </dsip:urf> <dsip:utm dat_ab="2005-12-01t12:53:12" ind_oprav_sd="n"> <dsip:u_tm>lipanthyl 1-0-0</dsip:u_tm> <dsip:autor>mudr. Jmeno Prijmeni</dsip:autor> <dsip:dat_ak>2005-08-11t09:15:12</dsip:dat_ak> </dsip:utm> <dsip:uks dat_ab="2005-12-01t12:53:12" ind_oprav_sd="n"> <dsip:ks_rh>ab+</dsip:ks_rh> <dsip:krevskup>ab</dsip:krevskup> <dsip:rh>+</dsip:rh> <dsip:autor>mudr. Jmeno Prijmeni</dsip:autor> <dsip:dat_ak>2005-08-11t09:15:12</dsip:dat_ak> </dsip:uks> <dsip:uot dat_ab="2005-12-01t12:53:12" ind_oprav_sd="n"> <dsip:dat_du format="d" typ="i">1995-04-18</dsip:dat_du> <dsip:autor>mudr. Jmeno Prijmeni</dsip:autor> <dsip:dat_ak>1995-04-18t13:33:12</dsip:dat_ak> </dsip:uot> </dsip:u> <!-- anamnéza souhrnná --> <dsip:an dat_ab="2005-12-05t05:06:56"> <dsip:garant_dat id_garant="7812082113" odbornost="606">mudr. Jmeno Prijmeni</dsip:garant_dat> <dsip:text> <dsip:ptext>ra: bezvýznamná OA: recentně zjištěn vyšší TK u dr. Kramáře /2/02/ cukrovka není CMP 1999 s pravostrannou hemiparesou léčí na osteoporosu 01/02 - odstranění 2 polypů colon /Po Petřínem/ katarakta - operace před 20 a 3 roky na obou očích FA: Inhibace, Biston, Anopyrin, Enelbin, Euphyllin SPA: důchodce Abusus: kouřil do roku 1992 </dsip:ptext> </dsip:text> <dsip:dat_ak>2005-12-05t05:06:56</dsip:dat_ak> </dsip:an> <!-- diagnózy trvalé --> <dsip:dg> <dsip:dgz typ_dg="t" ind_oprav_sd="n"> <dsip:diag poradi="1">i151</dsip:diag> </dsip:dgz> <dsip:dgz typ_dg="t" ind_oprav_sd="n"> <dsip:diag poradi="2">a029</dsip:diag> </dsip:dgz> Verze 1.0 Strana 10

<dsip:dgz typ_dg="t" ind_oprav_sd="n"> <dsip:diag poradi="3">a260</dsip:diag> </dsip:dgz> </dsip:dg> <dsip:ku> <!-- propouštěcí zpráva --> <dsip:ku_z typku="h.propz" fazespec="zf" idku="hicomp.lit.000000000002emo.1111111"> <dsip:dat_prov typ="l">2012-09-18t12:38:00</dsip:dat_prov> <dsip:dat_real_od typ="l">2012-08-18t12:38</dsip:dat_real_od> <dsip:dat_real_do typ="l">2012-09-18t12:38</dsip:dat_real_do> <dsip:dat_vydani typ="l">2012-09-20t11:21:00</dsip:dat_vydani> <dsip:z_pracoviste kod_lok="2304 " icz="55021000" icp="55021953" odb="501" ns="a2304"> <dsip:nazev>chirurgie - ambulance konzilia</dsip:nazev> </dsip:z_pracoviste> <dsip:z_pracovnik icl="99999999" id_pracovnik="1"> <dsip:titul_pred>mudr.</dsip:titul_pred> <dsip:jmeno>pavel</dsip:jmeno> <dsip:prijmeni>marek</dsip:prijmeni> </dsip:z_pracovnik> <dsip:p_pracoviste kod_lok="99010" icz="55021000" icp="55021137" odb="801" ns="l99010"> <dsip:nazev>chirurgie A1</dsip:nazev> </dsip:p_pracoviste> <dsip:p_pracovnik icl="99999998" id_pracovnik="2"> <dsip:titul_pred>mudr.</dsip:titul_pred> <dsip:jmeno>dalibor</dsip:jmeno> <dsip:prijmeni>dvořák</dsip:prijmeni> </dsip:p_pracovnik> <dsip:pv_ku typ_pv="zp"> <dsip:pv_zp> <dsip:cispoj>121212121</dsip:cispoj> <dsip:kodpoj>999</dsip:kodpoj> </dsip:pv_zp> </dsip:pv_ku> <dsip:text> <dsip:ptext xml:space="preserve">![cdata[text propouštěcí zprávy.]]</dsip:ptext> </dsip:text> <dsip:dg_vys typ_dg="p" ind_oprav_sd="n"> <dsip:diag poradi="1">i158</dsip:diag> </dsip:dg_vys> <dsip:dg_vys typ_dg="p" ind_oprav_sd="n"> <dsip:diag poradi="2">i10</dsip:diag> </dsip:dg_vys> </dsip:ku_z> <!-- ambulantní zpráva --> <dsip:ku_z typku="amb.vys" fazespec="zf" idku="hicomp.lit.000000000002emo.2222222"> <dsip:dat_prov typ="l">2012-09-18t12:38:00</dsip:dat_prov> <dsip:dat_vydani typ="l">2012-09-20t11:21:00</dsip:dat_vydani> <dsip:z_pracoviste kod_lok="2304 " icz="55021000" icp="55021953" odb="501" ns="a2304"> <dsip:nazev>chirurgie - ambulance konzilia</dsip:nazev> </dsip:z_pracoviste> <dsip:z_pracovnik icl="99999999" id_pracovnik="1"> <dsip:titul_pred>mudr.</dsip:titul_pred> <dsip:jmeno>pavel</dsip:jmeno> <dsip:prijmeni>marek</dsip:prijmeni> </dsip:z_pracovnik> <dsip:p_pracoviste kod_lok="99010" icz="55021000" icp="55021137" odb="801" ns="l99010"> <dsip:nazev>chirurgie A1</dsip:nazev> Verze 1.0 Strana 11

</dsip:p_pracoviste> <dsip:p_pracovnik icl="99999998" id_pracovnik="2"> <dsip:titul_pred>mudr.</dsip:titul_pred> <dsip:jmeno>dalibor</dsip:jmeno> <dsip:prijmeni>dvořák</dsip:prijmeni> </dsip:p_pracovnik> <dsip:pv_ku typ_pv="zp"> <dsip:pv_zp> <dsip:cispoj>121212121</dsip:cispoj> <dsip:kodpoj>999</dsip:kodpoj> </dsip:pv_zp> </dsip:pv_ku> <dsip:text> <dsip:ptext xml:space="preserve">![cdata[text ambulantní zprávy.]]</dsip:ptext> </dsip:text> <dsip:dg_vys typ_dg="p" ind_oprav_sd="n"> <dsip:diag poradi="1">i158</dsip:diag> </dsip:dg_vys> <dsip:dg_vys typ_dg="p" ind_oprav_sd="n"> <dsip:diag poradi="2">i10</dsip:diag> </dsip:dg_vys> </dsip:ku_z> </dsip:ku> </dsip:ip> </ds:is> </ds:dasta> XML soubor této zprávy je také přílohou dokumentu. Verze 1.0 Strana 12

3 Komunikační protokol a formát zpráv Komunikačním protokolem pro přenos dat mezi externí aplikací a NIS je SOAP. Dotaz (request) na data bude obsahovat element s požadavkem na získání pacientské dokumentace ve formátu DASTA 4. Odpověď (response) bude obsahovat objekt ResultStatus s informací o výsledku volání a případných chybách. Dále bude v odpovědi zahrnut objekt Dasta obsahující pacientské údaje ve formátu DASTA 4, pokud budou v NIS nalezeny požadované informace. Rozhraní musí garantovat odpověď na dotaz do 6 sekund alespoň v 80 % případů. Poznámka: Rychlost odezvy na dotaz je dána řadou faktorů, jako je (ne)garantovaná přenosová rychlost datové linky, proměnná velikost přenášené zprávy, výkonem HW a okamžitým výkonovým zatížením, celkovou velikostí databáze nemocničního IS a počtem záznamů konkrétního pacienta. Z těchto faktorů mají na odezvu největší dopad okamžité zatížení HW NIS serveru, celkový počet záznamů konkrétního pacienta a okamžitá přenosová kapacita datové linky. Tyto faktory jsou neovlivnitelné technickou realizací NIS konektoru. 3.1 Příklad SOAP zprávy dotaz <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:body> <PatientInfo> <PatientInfoRequestData> <Dasta> <![CDATA[<data>xml zpráva ve formátu DASTA 4</data>]]> </Dasta> </PatientInfoRequestData> </PatientInfo> </s:body> </s:envelope> 3.2 Příklad SOAP zprávy odpověď <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:body> <PatientInfoResponse> <PatientInfoResult> <ResultStatus> <ErrorCode/> <ErrorMessage/> <Success>true</Success> <LogEntryId>0e3db168a7f192bc7893a8903ed07624</LogEntryId> </ResultStatus> <Dasta> <![CDATA[<data>xml zpráva ve formátu DASTA 4</data>]]> </Dasta> </PatientInfoResult> Verze 1.0 Strana 13

</PatientInfoResponse> </s:body> </s:envelope> Verze 1.0 Strana 14

3.3 Popis elementů SOAP zpráv Následující tabulka obsahuje popis důležitých elementů SOAP zpráv předávaných mezi EC serverem a webovou službou na straně NIS: Název elementu Popis elementu Dasta Objekt zapouzdřující XML zprávu ve formátu DASTA 4 ResultStatus Zpráva o výsledku zpracování - ErrorCode Kód chyby - ErrorMessage Popis chyby - Success Informace o úspěšném dokončení zpracování (true/false) - LogEntryId Identifikátor záznamu o zpracování v logu NIS serveru 3.4 Rozšíření formátu SOAP zpráv Základní formát zpráv popsaný výše může být pro potřeby jednotlivých NIS rozšířen o doplňující elementy nutné k zajištění funkční komunikace mezi externím systémem a NIS. 3.4.1 Příklad rozšířené SOAP zprávy Následující příklad obsahuje rozšíření dotazu pro NIS Medea, jehož webové služby vyžadují v SOAP zprávě hlavičku obsahují identifikátor aplikačního serveru, který zpracovává dotaz ve vlastní aplikaci NIS. <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:header> <serviceid> <UUID>5646ca652f905877:7ca11578:139de8bcad9:-7fcb;<ce PX- 000001 AO>;Fl38wmsnlyzW9C0PxYCg3g==</UUID> </serviceid> </s:header> <s:body> <PatientInfo> <PatientInfoRequestData> <Dasta> <![CDATA[<data>xml zpráva ve formátu DASTA 4</data>]]> </Dasta> </PatientInfoRequestData> </PatientInfo> </s:body> </s:envelope> Verze 1.0 Strana 15

4 Zabezpečení komunikace 4.1 VPN Pro zabezpečení veškeré komunikace mezi externí aplikací a NIS je doporučeno, aby komunikace probíhala v rámci virtuální privátní sítě (VPN), která propojí tyto systémy pomocí zabezpečeného komunikačního tunelu. Webové služby na straně NIS budou přístupné pouze v rámci této VPN sítě přes port povolený na firewallu. 4.2 Protokol HTTPS Další úrovní zabezpečení bude použití šifrovaného komunikačního protokolu https pro přenos zpráv mezi externí aplikací a webovými službami NIS. Externí systém 4.3 Ověření identity komunikujících stran Identita serveru, na kterém poběží webová služba NIS, i klientské aplikace (externí systém) bude při vzájemné komunikaci oboustranně ověřována za použití serverového a klientského SSL certifikátu. T ato metoda zajišťuje vysokou úroveň věrohodnosti autentizace komunikujících stran. Způsoby ověřování s nižší úrovní zabezpečení (například HTTP Basic Authentication) nebudou podporovány. Kromě oboustranného ověření identity komunikujících stran je také možné řídit přístupová práva, a tedy poskytnutí dat z NIS do externí aplikace, na základě datového obsahu zpráv. Datové zprávy ve formátu DASTA 4 nesou informace o žadateli (osoba, subjekt). Pokud externí aplikace tyto informace bude v dotaze předávat, může NIS konektor, resp. NIS jako takový, na tato data reagovat dle nastavených bezpečnostních politik. Toto je však pouze doporučením, nikoliv podmínkou pro implementaci komunikačního rozhraní NIS konektoru. 4.4 Logování Na straně NIS konektoru, resp. NIS jako takového, se doporučuje implementovat logování komunikace z důvodu monitoringu průběhu komunikace a vytváření prokazatelného a zpětně dohledatelného auditního záznamu o tom, kdy, kdo a co bylo po NIS požadováno a kdy, komu a co bylo z NIS Verze 1.0 Strana 16

poskytnuto (odpovědi jsou generované automaticky, tedy nelze učit kdo data odeslal). Tato funkcionalita je ovšem závislá na možnostech daného software. Verze 1.0 Strana 17

Přílohy 1. zadanka_4.07.01.xml 2. zprava_4.07.01.xml Verze 1.0 Strana 18