EJBI - European Journal for Biomedical Informatics :: Sémantická interoperabilita v prostredí českého zdravotníctva podporovaná HL7 v3

V modernej dobe majú lekári široké možnosti využívania rôznych diagnostických vyšetrení, liečebných procedúr a liekov. Pri mnohých z týchto činností vzniká veľké množstvo dát, ktoré musia byť spracované a posúdené kvalifikovaným odborníkom a ich výsledky musia byť prenesené k ošetrujúcemu lekárovi, na oddelenie, prípadne do iného zdravotníckeho zariadenia. Niekedy môže aj najmenšia drobnosť rozhodnúť o vhodnosti výberu ďalšej liečby. Možnosť lekára pristupovať k relevantným informáciám o pacientovi v primeranej forme, v správny čas a na správnom mieste, môže byť rozhodujúca pre dobro pacientov.

Po prijatí nových členov do Európskej únie sa ľudia začali viac sťahovať v porovnaní s minulosťou, a preto vznikla potreba cezhraničného prístupu k informáciám a ich integrácia. Problém je, že české zdravotníctvo nemá štandardný spôsob výmeny štruktúrovaných dát so zreteľom na medzinárodnú spoluprácu. Táto situácia predstavuje prekážku pre zahraničných pacientov, „medicínskych turistov", ako aj pre dodávateľov zdravotníckych informačných systémov, ktorí plánujú vstúpiť na český trh. Viac informácií o využití informačných a komunikačných technológií v rámci komunikácie medzi zdravotníckymi organizáciami možno nájsť v [1].

Uvedenému problému sa venoval národný výskumných projekt programu „Informačná spoločnosť" Akadémie vied Českej republiky (AV ČR) s názvom „Informačné technológie pre rozvoj kontinuálnej zdieľanej zdravotnej starostlivosti" (2004-2008). Projektový tím pozostával z Oddelenia medicínskej informatiky (OMI) Ústavu informatiky AV ČR, dvoch spoločnosti zaoberajúcimi sa vývojom softvéru a Mestskej nemocnice v Čáslavi.

V tomto príspevku predkladáme čiastkové výsledky tohto projektu z oblasti interoperability a skúsenosti z procesu pilotného zavádzania prostriedkov komunikácie medzi nemocničné informačné systémy. Sekcia 2 popisuje problematiku na pozadí spomínaného projektu a súbor požiadaviek kladených na výsledky tohto projektu. V oddieloch 3 a 4 zhrnieme použité metódy a stručne predstavíme systémy EZZ (sEZZ) podieľajúce sa na našom riešení. Návrh platformy pre sémantickú interoperabilitu (PSI), jej časti a niektoré príklady komunikačných správ sú uvedené v sekcii 5. Výsledky nášho projektu sú popísané v oddiele 6 a budúce aktivity zamerané na širšie využitie HL7 v3 v Českej republike v sekcii 7.

2 Pozadie problematiky

Súčasné nemocničné informačné systémy (NIS) v českých zdravotníckych zariadeniach sú skôr zamerané na riadenie inštitúcie, než na samotnú zdravotnú starostlivosť. sEZZ sú často založené na voľných textových správach a poskytujú len veľmi obmedzené funkcie pre inteligentné spracovanie uložených dát. Ďalším problémom je, že české NIS-y sú väčšinou koncipované ako monolitické systémy, a preto zdravotnícke zariadenia nemôžu kombinovať komponenty od rôznych dodávateľov.

V prostredí českého zdravotníctva je zdieľanie dát a ich opätovné využívanie na dosť nízkej úrovni. Väčšina NIS-ov v Českej republike komunikuje medzi sebou prostredníctvom národného komunikačného štandardu DASTA [2], ktorý je založený na národnej nomenklatúre tzv. Národnom číselníku laboratórnych položiek (NČLP) [2]. Tento štandard je vyvíjaný a spravovaný inštitúciami zaoberajúcimi sa vývojom zdravotníckych informačných systémov, medzi ktoré patria špecializované firmy, univerzity a výskumné inštitúcie v Českej republike. Vývoj tohto štandardu bol podporený najmä Ministerstvom zdravotníctva ČR. DASTA sa špecializuje predovšetkým na zasielanie žiadostí a výsledkov laboratórnych analýz. Aktuálna verzia DASTA je založená na XML a poskytuje aj funkcie pre odosielanie štatistických údajov do Ústavu zdravotníckych informácií a štatistiky Českej republiky a obmedzenú funkcionalitu pre výmenu klinických informácií vo forme voľného textu. Bohužiaľ, DASTA nemá takmer žiadny vzťah k medzinárodným komunikačným štandardom ako HL7 [3] alebo európskym normám, ako je EN13606 [4].

Použitie medzinárodných štandardov, ako HL7 vo verzii 2 alebo DICOM [5], je zapríčinené najmä požiadavkami v zdravotníckych zariadeniach, ktoré ich využívajú primárne pre komunikáciu s modernými prístrojmi. Bohužiaľ, takéto použitie predstavuje len malú časť celkového využívania mezinárodných komunikačných štandardov v českom zdravotníctve.

Jednou z dobre známych aktivít v Českej republike v rámci e-zdravia je projekt IZIP [6]. Hlavnou myšlienkou IZIP-u je, že občania by mali mať prístup k centralizovanej kópii svojej zdravotnej dokumentácie (k tzv. „internetovej zdravotnej knižke") a mali by byť schopní povoliť prístup k tomuto „skladu" informácií svojmu praktickému alebo inému ošetrujúcemu lekárovi. Tento projekt zaviedol istý stupeň sémantickej interoperability realizovaný ľuďmi avšak nie strojmi. Hlavnou prekážkou v dosiahnutí sémantickej interoperability medzi strojmi [7] bola predovšetkým orientácia IZIP-u na dáta v podobe textových dokumentov.

Hlavným cieľom nášho projektu bolo navrhnúť platformu pre výmenu údajov o zdravotnej starostlivosti v štruktúrovanej podobe s ohľadom na národnú a cezhraničnú komunikáciu. V tejto súvislosti bol formulovaný súbor požiadaviek:

3 Materiály

V našom pilotnom projekte, ktorý je primárne demonštráciou možností, nebolo možné pokryť celú oblasť medicíny ako domény pre interoperabilitu. Hlavný riešiteľ projektu, OMI ÚI AV ČR, má dlhú históriu v interdisciplinárnom výskume orientovanom na kardiológiu. Preto bola vybraná ako doména pre pilotnú realizáciu PSI. Z týchto dôvodov bol pripravený Minimálny Dátový Model pre Kardiológiu (MDMK) [8] zástupcami Českej kardiologickej spoločnosti v spolupráci so štatistikmi špecializujúcimi sa na spracovávanie medicínskych dát. Je to množina dôležitých lekárskych pojmov v oblasti kardiológie, ktorá poslúžila ako základ pre informačné modely dvoch sEZZ použitých v našom riešení.

WinMedicalc 2000 (WMC) [9] je stredne veľký komerčný modulárny nemocničný informačný systém, ktorý uprednostňuje využitie štruktúrovanej elektronickej zdravotnej dokumentácie pred voľným textom. WMC sa používa ako nemocničný informačný systém v Mestskej nemocnici v Čáslavi.

ADAMEKj je sEZZ vyvinutý na OMI ÚI AV ČR s cieľom zhromaždiť genetické a klinické dáta kardiologického pacienta. Doménový model aplikácie je založený na MDMK. Užívateľské rozhranie je inšpirované predošlou aplikáciou ADAMEK [10]. Hlavný dôraz bol kladený na prijatie programu užívateľmi, preto boli lekári úzko zapojení do celého procesu vývoja, ktorý je detailnejšie popísaný v [11].

HL7 v3 je všeobecne uznávaný štandard pre elektronickú výmenu zdravotníckych informácií. Tento štandard sa okrem množstva artefaktov skladá najmä z Referenčného Informačného Modelu (RIM), pojmových slovníkov, zjemnených modelov (D-MIM, R-MIM), scenárov udalostí a špecifikácií implementácie. RIM je popísaný v [12] takto: „RIM je informačný model, ktorý zahŕňa oblasti záujmu HL7 ako celok. Je to koherentný, zdieľaný informačný model, ktorý je zdrojom štruktúr pre dátový obsah všetkých HL7 správ. Ako taký poskytuje konzistentné údaje a koncepty znovu použiteľné vo viacerých informačných štruktúrach, vrátane správ."

Popri definíciách statických štruktúr je definícia dynamiky systému veľmi dôležitá. HL7 v3 prináša pojem „scenár udalostí", čo je popis udalostí relevantných k zdravotnej starostlivosti definovaný ako postupnosť interakcií alebo prípadov použitia [13]. Scenáre udalostí sú v HL7 analógiami diagramov chovania z UML (diagramu prípadov použitia, stavového diagramu a sekvenčného diagramu).

Štandard HL7 v3 poskytuje špecifikáciu implementačnej technológie (ITS) pre XML. XML ITS špecifikuje spôsob kódovania správ, pravidlá pre vytváranie spojení a prenosov, a procedúry na spracovanie chýb.

4 Metódy

Podrobnú prácu na tému sémantickej interoperability možno nájsť v [14], kde je popísaný vývojový rámec (nie samotná realizácia) pre vývoj sémanticky interoperabilných zdravotníckych informačných systémov. Avšak my sa zameriavame skôr na realizáciu PSI a na identifikáciu prekážok v prostredí českého zdravotníctva.

V [7] autor popisuje rozdiel medzi sémantickou interoperabilitou medzi ľuďmi a sémantickú interoperabilitou medzi počítačmi (CSI - computable semantic interoperability), a uvádza štyri nutné, ale nie postačujúce podmienky („Štyri piliere") pre dosiahnutie CSI:

Autor uvádza, že bez splnenia „Štyroch pilierov" nie je CSI prakticky možné konzistentným spôsobom dosiahnuť a taktiež ukazuje, že štandard HL7 v3 je v súlade s týmito podmienkami.

Našou úlohou bolo nájsť cestu k interoperabilite a zdieľaniu informácií medzi českými zdravotníckymi zariadeniami a medzinárodnými inštitúciami. Na začiatku projektu (polovica roku 2004) bol uskutočnený prvotný výskum v oblasti komunikačných štandardov v zdravotníctve (viď sekciu 6). Štandard HL7 v3 bol vybraný z pomedzi kandidátov ako HL7, DICOM, openEHR [15] a ENV 13606 [16]. Naša prototypová implementácia spája WMC s EZZ ADAMEKj a je založená práve na štandarde HL7 v3. Keďže sa táto norma v tej dobe ešte stále vyvíjala a nebola k dispozícii žiadna normatívna verzia (publikovaná až v roku 2005), nebolo ani veľa implementácií tohto štandardu, ktorými by sme sa mohli inšpirovať. Avšak, v priebehu času sa niektoré skúsenosti z procesu implementácie objavili v [17], [18] a [19].

Aby sme splnili podmienky sémantickej interoperability (1.-4.) vykonali sme nasledujúce kroky:

Prvá podmienka poukazuje na používanie spoločného modelu. „Svet HL7" prichádza s modelom RIM. V našom riešení sme modelovali informácie uložené v použitých sEZZ vytvorením Lokálnych Informačných Modelov (LIM) (príklad je na Obr. 1). Triedy LIM-u sú odvodené od základných tried RIM. Tento prístup predstavuje mierny odklon od zaužívaného postupu vývoja správ v HL7 v3, ku ktorému sa ešte vrátime neskôr.
Druhá podmienka bola splnená použitím dátových typov definovaných HL7 v3 pre všetky atribúty v modeli LIM. Dôležitú úlohu zohral dátový typ „kódované s ekvivalentmi" (CE – coded with equivalents) a jeho odvodené podtypy, ktoré nám umožnili spojiť pojmy z nášho modelu s konceptmi z číselníkov.
Tretia podmienka vyžaduje používanie pojmového slovníka. Preto sme museli namapovať pojmy z modelov LIM (založené na MDMK) na číselníky, ktoré sú podporované HL7. Kódovací systém LOINC (Logical Observation Identifier Names and Codes) [20] bol použitý ako preferovaný, pretože obsahoval veľkú podmnožinu pojmov používaných v modeloch LIM. Zvyšné koncepty boli kódované pomocou SNOMED Clinical Terms (SNOMED CT) [21] a MKN-10 [22].
Posledná podmienka vyžaduje použitie prísnej metodiky. Štandard HL7 v3 poskytuje metodiky pre definovanie štruktúr na výmenu dát s použitím prvkov len z RIM. Po vytvorení LIM modelov a ich naviazaní na kódovacie systémy, sme ako ďalší krok v procese definície správy z nich museli odvodiť stromové štruktúry, tzv. LIM šablóny. Každá LIM šablóna predstavuje jednu ucelenú časť EZZ, ktorú LIM popisuje, napr. fyzikálne vyšetrenie, predpísané lieky a EKG. HL7 HMD [13] a LIM šablóny slúžia rovnakému účelu, t.j. definovať hierarchiu, poradie a voliteľnosť tried v R-MIM (Refined Message Information Model) resp. LIM.

Obr. 1. Časť LIM modelu v systéme ADAMEKj.

Po aplikácii všetkých vyššie uvedených metód, sme museli pripraviť prostredie na otestovanie našej implementácie. Testovacie prostredie bolo tvorené vygenerovanými dátami fiktívnych pacientov z každého sEZZ, rozšírenými verziami klientských aplikácií sEZZ, HTTPS spojeniami cez Internet a pilotnou realizáciou PSI pozostávajúcou z tzv. HL7 v3 brokerov.

5 Výsledky

MDMK je minimálny súbor atribútov potrebných na zistenie, či je pacient rizikový, alebo trpí aterosklerotickým srdcovo-cievnym ochorením.

Na nájdenie vhodného mapovania klinických pojmov z MDMK na medzinárodné terminológie bol použitý UMLS vedomostný server (UMLS Knowledge Source Server) [23]. Niektoré príklady tohto mapovania sú uvedené v tabuľke 1.

Pri analýze sme zistili, že približne 85 % všetkých pojmov MDMK bolo zahrnutých aspoň v jednom klasifikačnom systéme. Podarilo sa nám namapovať väčšinu klinických pojmov z MDMK do LOINC a SNOMED CT. Počas mapovania sme museli vyriešiť niektoré problémy s pojmami s príliš malou alebo veľkou granularitou, s pojmami, ktoré boli synonymá avšak použité s mierne odlišným významom, či koncepty, ktoré nebolo možné nájsť v žiadnom dostupnom klasifikačnom systéme [24]. Proces mapovania je zhrnutý v tabuľke 2.

Primárny výsledok nášho projektu bol návrh PSI založenej na medzinárodnom komunikačnom štandarde, ktorý je uvedený na Obr. 2.

Obr. 2. Návrh platformy pre sémantickú interoperabilitu založenej na medzinárodných komunikačných štandardoch.

Tento návrh sa skladá z modulov „LIM filler", HL7 v3 brokerov (skrátene HL7 broker) a pôvodných sEZZ. Všetka komunikácia je bez-stavová a realizovaná zabezpečene. Čísla na Obr. 2 ukazujú tok dát v modelovej situácii, kedy sEZZ (EHR-S1) pošle odpoveď na otázku položenú systémom EHR-S2.

Najskôr sa získajú potrebné dáta z EHR-S1 za pomoci modulu LIM filler, ktorý má prístup k úložisku EHR-S1. Ďalej sa vyberie príslušná LIM šablóna, ktorá obsahuje správne koncepty na prenos údajov. Modul LIM filler vyplní hodnoty určitým atribútom tried v LIM šablóne (transformácia Dáta-LIM), čím sa vytvorí LIM správa. HL7 broker dostane LIM správu od LIM filler-a pomocou protokolu SOAP. Ďalej sa vykonáva ďalšia transformácia (LIM-HL7), v ktorej HL7 broker vytvára vhodné inštancie HL7 správ, ktoré sú odosielané zabezpečeným spôsobom ďalšiemu HL7 brokeru (prijímajúcemu). V tej chvíli prebieha proces transformácie dát v obrátenom poradí. HL7 broker prislúchajúci k EHR-S2 vytvára LIM správy (HL7-LIM transformácia) prijateľné pre modul LIM fillera systému EHR-S2, a odosiela ich cez SOAP. Prijímajúci modul LIM filler rozpozná prichádzajúcu LIM správu a vyextrahuje z nej údaje (LIM-dáta transformácia) vo forme vhodnej pre skladovanie v databáze EHR-S2. Nakoniec sa údaje natrvalo uložia v EHR-S2. V tomto príklade sme vynechali mechanizmy žiadostí a potvrdení z dôvodov jednoduchosti.

Modul LIM filler a HL7 broker budú podrobnejšie popísané v nasledujúcom texte.

Prenášané dáta sú prevádzané medzi formátom lokálneho úložiska EZZ a formátom LIM správ, ktoré sú inštanciami LIM šablón z oboch strán komunikácie. Túto činnosť vykonáva modul s názvom LIM filler. Modul LIM filler je prispôsobený pre lokálny sEZZ k tvorbe LIM správ v súlade so štruktúrami v danom EZZ.

LIM filler môže byť buď implementovaný ako zásuvný modul sEZZ alebo ako samostatná aplikácia. Pracuje v dvoch režimoch: odosielanie a prijímanie. V režime odosielania dát, vytvára LIM správy podľa požiadaviek užívateľov a posiela ich HL7 broker-u. V druhom režime sa cyklicky pýta HL7 brokera či neobsahuje nové relevantné správy pre LIM filler. V prípade, že je stiahnutá nová správa, vyextrahuje z nej dáta a ďalej postupuje v súlade s konkrétnym scenárom udalostí alebo len uloží údaje pacienta v miestnom EZZ.

LIM filler musí dodržiavať bezpečnostné aspekty komunikačného protokolu. Komunikuje s HL7 broker-om prostredníctvom zabezpečeného HTTP kanála pomocou protokolu SOAP. LIM správy musia byť digitálne podpísané oboma zúčastnenými stranami a podpisy musia byť pred prevodom údajov z LIM správy overené.

Hoci sú na trhu dostupné niektoré HL7 v2 broker-y (napr. MergeCOM-3^TM, Interfaceware Chameleon^TM) v počiatočnej fáze projektu (v roku 2005) sme však nenašli žiadne broker-y pre verziu 3. Toto bol dôvod vytvorenia vlastného brokera pre náš projekt. HL7 broker je ťažiskovou súčasťou nášho riešenia. Pre zúčastnené sEZZ slúži HL7 broker ako brána do sveta HL7 v3 a oddeľuje ich od podrobností štandardu HL7. Situácia je znázornená na Obr. 3. Výrobcovia sEZZ musia iba špecifikovať LIM šablóny založené na ich LIM modeloch, ktoré popisujú štruktúru ich databázy a stačí keď implementujú jednoduchý SOAP klient na odosielanie a prijímanie LIM správ na/od HL7 broker-a. Okrem LIM šablón musia výrobcovia poskytnúť všetky interne používané číselníky s vhodným popisom nášmu on-line nástroju na medzi-slovníkové mapovanie.

HL7 broker rozkladá implementačné úsilie na výrobcov sEZZ ako aj na výrobcov HL7 broker-a. Čím ľahšie sú transformácie na strane sEZZ, tým viac práce je potrebné urobiť na strane HL7 broker-a. HL7 broker je potrebné nastaviť osobitne pre príslušný sEZZ. Je treba nahrať všetky LIM šablóny definované výrobcom EZZ (vo forme XSD schém všetkých správ LIM). Pre každý scenár udalostí vyžaduje HL7 broker inštrukcie na spracovanie dát (t.j. čo robiť, keď príde určitá LIM správa, keď je vyvolaná nejaká aplikačná úloha alebo čo robiť pri chybe). Je tiež potrebné namapovať číselníky v EZZ na pojmový slovník HL7 alebo na iné číselníky.

Jadro HL7 broker-a je zodpovedné za prepis informácií z LIM do HL7, a naopak. To je realizované spracovávaním inštrukcií v jazyku XML pomocnou triedou.

Komunikácia medzi sEZZ a HL7 broker-om je realizovaná pomocou webových služieb, ktoré využívajú SOAP cez protokol HTTPS. HL7 broker poskytuje iba tri metódy (sendLimMsg(), getLimMsg(), ackLimMsg()) na prenos dát vo forme LIM správy.

Zaviedli sme jednoduché schémy komunikácie „odosielanie na broker" a „pravidelné pýtanie sa brokera", ktoré umožňujú implementáciu SOAP servera len na strane broker-a a SOAP klienta iba na strane sEZZ. SOAP klient je typicky implementovaný jednoduchšie a lacnejšie ako SOAP server. Ako je znázornené na Obr. 3, vývojári môžu tiež monitorovať všetku komunikáciu medzi sEZZ a HL7 broker-om pomocou špeciálnej aplikácie napísanej v jazyku Java. Ukázalo sa to byť veľmi užitočné, najmä na začiatku implementácie SOAP klienta v sEZZ. Spolu s prenášanou LIM správou odosielame a potvrdzujeme kryptograficky podpísaný výťah (digest) zo správy za účelom potvrdenia pravosti prenosu pre každú stranu. HL7 broker môže byť vyvolaný zo strany sEZZ alebo ďalším HL7 v3 broker-om. Podľa typu LIM správy alebo identifikátora HL7 interakcie kombinovaným s identifikátorom LIM relácie prípadne identifikátorom odpovede na HL7 správu sa bude broker rozhodovať či sa nachádza na začiatku novej relácie (a ktorým scenárom začať), alebo či už daná relácia beží. Následne je vybraná vhodná akcia (napr. zostavovanie správy alebo vyvolá výnimku).

Jadro broker-a používa počas prepisu informácie z prijatej správy do novej pomocnú triedu a súvisiace mapovanie číselníkov. Popis procesu transkripcie je uchovaný v protokole a výsledok prepisu môže byť prenesený späť odosielateľovi (ako kontrolná správa alebo HL7 LIM potvrdenie).

Transport HL7 v3 správ je založený na jednoduchej imitácii MLLP (Minimal Lower Layer Protocol) nad SOAP. HL7 správy sú serializované podľa XML IDS R1.

Dotazovanie je v našom riešení založené na HL7 scenároch udalostí. Napríklad môžeme spomenúť scenár z domény „Správa Pacienta (Patient Administration)" s názvom „Register pacientov – nájsť kandidátov – dotaz (Patient Registry Find Candidates Query)" (kód artefaktu PRPA_ST201305), ktorý bol implementovaný za účelom hľadania pacientových administratívnych údajov. Sekvenčný diagram UML na Obr. 4 predstavuje činnosti vykonávané v súlade so scenárom „dotaz na pacienta" s prídavkom dotazu ADAMEKj a odpovedi WMC.

Obr. 4. Sekvenčný diagram dotazu „Patient Registry Find Candidates Query".

Dotazy vytvorené sEZZ a predané HL7 broker-u sa skladajú z „prázdnej" LIM šablóny, v ktorej sú vyplnené len niektoré atribúty a tie slúžia ako parametre dotazu.

Naše riešenie umožňuje vytváranie dotazov na všetky oblasti, ktoré sú pokryté LIM šablónami. HL7 broker vykoná príslušný scenár udalostí, ktorý vedie k získaniu údajov požadovaných dotazujúcim sa modulom LIM filler.

Aby sa zlepšil čitateľov prehľad o HL7 správach a dotazoch popísaných v predchádzajúcom texte, uvádzame príklad správy zodpovedajúcej interakcii "Patient Registry Find Candidates Response" (kód artefaktu PRPA_IN201306) v podobe XML (Obr. 6) a dve pridružené LIM správy. Prvá (viď Obr. 5 vľavo) slúži ako zdroj údajov pre LIM-HL7 transformáciu na strane odosielateľa (napr. WMC EZZ), a druhá (viď Obr. 5 vpravo) je určená dátam vytvoreným počas HL7-LIM transformácie na strane príjemcu (napr. ADAMEKj). Predložené správy obsahujú údaje o administratívnych dátach pána John-a Smith-a, ktorý bol predmetom dotazu podaného systémom ADAMEKj.

Obr. 6. Výpis z komunikácie podľa scenáru udalostí PRPA_ST201305 – XML reprezentácia odpovedi typu „Patient Registry Find Candidates Response".

6 Diskusia

V tejto sekcii zopakujeme požiadavky naformulované v sekcii 2 a budeme diskutovať o stupni ich naplnenia v našom systéme.

Výmena dát pacientov medzi rôznymi zdravotníckymi zariadeniami v Českej republike je realizovaná väčšinou pomocou národnej normy DASTA s obmedzenou úplnosťou a s malým zreteľom na medzinárodné úsilie (štandardy a číselníky). Vzhľadom k jej postupnému vývoju zdola nahor, neobsahuje vhodný informačný model a má malé pokrytie domén zdravotnej starostlivosti (s výnimkou laboratórnych vyšetrení).

Kandidátmi na primárny komunikačný štandard pre PSI boli openEHR, ENV 13606 (EN 13606 ešte nebol v roku 2004 k dispozícii), DICOM a HL7 v3. OpenEHR je vhodnejší pre budovanie samotného sEZZ [25] než správ a navyše nebol tak vyzretý ako je dnes. Vzťah medzi špecifikáciami od openEHR a HL7 v3 je popísaný v [26]. ENV 13606 mala príliš málo reálnych implementácií a nachádzala sa v postupnom procese revízií, ktoré vyústili v mierne odlišnú EN 13606, ktorá ale nebola v tej dobe ešte dokončená. DICOM je zameraný predovšetkým na oblasť obrazových dát a nebol vhodný na nami plánované použitie. Ako najlepšie a najperspektívnejšie riešenie bol zvolený štandard HL7 v3 vďaka svojej širokej medzinárodnej akceptácii, prepracovaným metodikám [13] a dlhej a úspešnej histórii jeho predchádzajúcej verzie. Toto rozhodnutie viedlo k uspokojeniu prvého kritéria – použitie medzinárodného komunikačného štandardu a číselníkov.

Obr. 2 ukazuje, že oba sEZZ komunikujú bez akéhokoľvek ľudského zásahu. Sú riadené otázkami kladenými užívatelom sEZZ, ktorý začína komunikáciu. Z tohto pohľadu spĺňame aj druhé kritérium – automatizované interakcie medzi systémami.

Dôležitou črtou nášho riešenia je zavedenie LIM modelov a LIM šablón (viď sekcia 4.2). HL7 broker umožňuje vytváranie dotazov zo všetkých oblastí, ktoré pokrývajú LIM šablóny. Všetky potrebné informácie o danej klinickej doméne sa nachádzajú v konfiguračnom súbore HL7 broker-a. Týmto sú splnené požiadavky nezávislosti na klinickej doméne a konfigurovateľnosti.

Rozšíriteľnosť riešenia bola dosiahnutá použitím medzinárodného komunikačného štandardu a zavedenie HL7 brokera. Komunikujúce systémy nemusia nič vedieť o dátových štruktúrach ich náprotivnej strany. Nový komunikujúci sEZZ je možné pridať po vykonaní nasledujúcich krokov: vytvorenie LIM modelu popisujúceho informácie uložené v EZZ, odvodenie LIM šablón z LIM modelu, implementácia transformačného modulu (napr. LIM filler) pre dátové konverzie medzi databázou EZZ a LIM šablónami, a nakoniec vytvorenie HL7 brokera resp. definičného súboru špecifického pre nový sEZZ. Otvorenosť nášho riešenia bola dosiahnutá poskytnutím našich výsledkov všetkým zainteresovaným stranám.

7 Záver

Proces vývoja správ odporúčaný HL7 v3 (viď Obr. 7) bol zmenený rozdelením pracovného úsilia medzi implemntátorov sEZZ a štandardu HL7. Tento nový prístup by mohol vývojárom pomôcť prekonať počiatočnú frustráciu, ktorá by mohla byť spôsobená ohromujúcou veľkosťou štandardu HL7 (RIM, množstvo artefaktov atď.). Vývoj jednotlivých LIM modelov úzko súvisiacich s vnútornou štruktúrou informácií v konkrétnom EZZ, jednoduchého komunikačného rozhrania medzi sEZZ a HL7 broker-om založenom na LIM správach, SOAP a webových službách, sa zdá byť ľahšie realizovateľný menšími vývojárskymi tímami ako implementácia celého štandardu HL7 v3. Toto tvrdenie je podporované skúsenosťami dvoch nezávislých vývojárskych tímov zúčastnených na našom projekte. Tento prístup môže ušetriť finančné aj personálne zdroje ak sa použije outsourcing HL7-špecifických úloh príslušným tímom vývojárov, ktorí sú skúsení v implementácii HL7 v3 štandardu.

Obr. 7. Vpravo proces vývoja správ doporučený štandardom HL7 v3 a vľavo naše riešenie.

V priebehu realizácie PSI bolo potrebné použiť simulované údaje o pacientoch, keďže reálne dáta pacientov nemohli byť využité na tieto účely z legislatívnych dôvodov. Výsledky vykonaných testov (napr. položenie dotazu na hľadanie administratívnych dát pacienta) neboli ovplyvnené tým, že údaje boli simulované a sú tiež platné pre skutočné údaje pacientov.

Použitie LIM modelov a LIM filler-a má za následok, že naše riešenie je univerzálne a nie je závislé na žiadnom konkrétnom komunikačnom štandarde (s výnimkou HL7 broker-a), aj keď LIM vychádza RIM HL7 v3. Súčasné moderné komunikačné štandardy majú niektoré dôležité charakteristiky spoločné: základný referenčný model, užívateľsky definované modely odvodené z tohto referenčného modelu pomocou striktnej metodiky, a napokon taktiež istý druh šablóny pomáhajúcich pri vytváraní novej správy alebo dokumentu. Porovnanie súčasných komunikačných štandardov možno nájsť v [27], [28] a [29].

Po vyhodnotení výsledkov projektu „Informačné technológie pre rozvoj kontinuálnej zdieľanej zdravotnej starostlivosti" môžeme povedať, že HL7 v3 má mierne obmedzenú použiteľnosť v prostredí českého zdravotníctva (z dôvodu absencie českej meny v slovníkoch HL7). V súčasnej dobe nie je podporovaný vládnymi inštitúciami a len obmedzená podpora pochádza od výrobcov softvéru. Hlavným krokom k širšiemu využívaniu HL7 v3 v Českej republike by mal byť preklad a včlenenie NČLP medzi kódovacie systémy podporované štandardom HL7, alebo namapovanie NČLP na nejakú zavedenú medzinárodnú nomenklatúru akou je SNOMED CT. Ďalší zásadným krokom by bolo preloženie medzinárodných nomenklatúr do češtiny.

Tento článok bol podporený projektom 1ET200300413 Akadémie vied ČR a projektom 1M06014 Ministerstva školstva ČR.