A különböző fejlesztésű kórházi informatikai (al)rendszerek és modulok összekapcsolása mindennapos nehézséget okoz. A képalkotó megoldások terén elterjedt DICOM szabvány szerinti kompatibilitás alapján még mélyebb szakismerettel sem dönthető el, hogy az adott berendezés használható lesz-e meglévő informatikai rendszerünkben vagy sem. Erre sokkal inkább alkalmas a mostanság elterjedő IHE kompatibilitás fogalma, de ez is csak akkor ha a teljes informatikai rendszer erre épül.
A regisztrálást követően fogja tudni megtekinteni a cikk tartalmát!
A megadott cikk nem elérhető!
Tisztelt Felhasználónk!
Az Ön által megtekinteni kívánt cikk nem elérhető a rendszerben!
A megadott cikk nem elérhető!
Tisztelt Felhasználónk!
Az Ön által megtekinteni kívánt cikk nem elérhető a rendszerben!
Sikeresen szavazott a cikkre!
Tisztelt Felhasználónk!
Köszönjük a szavazatát!
A szavazás nem sikerült!
Tisztelt Felhasználónk!
Ön már szavazott az adott cikkre!
Cikk megtekintése
Tisztelt Felhasználónk!
A cikk több nyelven is elérhető! Kérjük, adja meg, hogy melyik nyelven kívánja megtekinteni az adott cikket!
Cikk megtekintésének megerősítése!
Tisztelt Felhasználónk!
Az Ön által megtekintetni kívánt cikk tartalma fizetős szolgáltatás.
A megtekinteni kívánt cikket automatikusan hozzáadjuk a könyvespolcához!
A cikket bármikor elérheti a könyvespolcok menüpontról is!
INFOKOMMUNIKÁCIÓ KÉPALKOTÓ RENDSZEREK IHE, avagy az eltérő kórházi informatikai rendszerek integrálhatósága Maróti Tamás, Medimon Kft. A különböző fejlesztésű kórházi informatikai (al)rendszerek és modulok összekapcsolása mindennapos nehézséget okoz. A képalkotó megoldások terén elterjedt DICOM szabvány szerinti kompatibilitás alapján még mélyebb szakismerettel sem dönthető el, hogy az adott berendezés használható lesz-e meglévő informatikai rendszerünkben vagy sem. Erre sokkal inkább alkalmas a mostanság elterjedő IHE kompatibilitás fogalma, de ez is csak akkor ha a teljes informatikai rendszer erre épül. KOMPATIBILITÁSI NEHÉZSÉGEK Ha valaki a kórházi informatikai rendszereket próbálja összekötni, meglehetősen nehéz helyzetben találja magát. A nehézségeket több tényező okozza, vegyük ezeket sorra. Először is az informatikai rendszerek fejlődése folyamán elkülönült információs szigetek alakultak ki. Többnyire kialakult egy kórházi informatikai rendszer (HIS), egy radiológiai informatikai rendszer (RIS), továbbá a különböző modalitások adatrendszerei (MR, CT, külön saját PACS, labor stb.). Az így kialakult szigeteket semmi sem kötötte össze, azaz minden adatot mindig, mindenhol újra be kellet vinni. Figyelembe véve a rohammunkában végzett adatbevitelt, és számos elgépelést a későbbi betegazonosítás nehéz feladattá vált. A második probléma az, hogy a különböző rendszerekhez különböző szabványokat, információs modelleket használtak, például DICOM, HL7, XML, vagy rosszabb esetben valami semmivel sem kompatibilis saját megoldásokat. Harmadrészt, még ha használták is valamelyik szabványt, akkor ezt többnyire saját interpretációjukban tették. Az így kifejlesztett rendszerek ugyan nem mondtak ellent a szabványnak, csak éppen összekötni nem lehetett azokat. Igaz erről maguk a szabványok is tehettek a túlzott „engedékenységükkel”. Végül nem utolsó sorban nemcsak kórházak között, de még egy kórházon belül a különböző osztályok közötti munkafolyamatok is eltérőek. Hogy egy egyszerű példával szemléltessük, a beteg azonosítására a név mellett hol a TAJ szám, hol a születési dátum, hol az egyedi kórházi azonosító, hol valami más adat szolgál. 48 IME II. ÉVFOLYAM 9. SZÁM 2003. DECEMBER Több mint 10 évvel ezelőtt indult útjára a DICOM, ami akkor úgy látszott, hogy megoldja majd a képalkotó eszközök összekötési problémáit. Hogy ez nem így lett, mi sem bizonyítja jobban, mint az, hogy ma már minden DICOM tanfolyamot úgy kezdenek: a DICOM nem „plug and play”. Ez azt jelenti, hogy ha két DICOM kompatibilis eszközt összekötünk, akkor senki sem szavatolja, hogy a két készülék tényleg kommunikálni fog egymással. Ezért a „DICOM kompatibilis” kifejezés félrevezető, és semmiképpen nem szinonimája a „meglévő rendszerükbe illeszthető” vagy a „munkafolyamatunk jobban szervezhető” fogalmaknak. Nézzük meg ezt egy az életből ellesett példával. A kórház új DICOM kompatibilis modalitást vásárol (CT, MR, UH). Amikor megérkezik és tényleg üzembe helyezik az új eszközt, akkor a kiválóan működő szerkezet a képeket – a már előzőleg vásárolt PACS rendszerre – minden hiba nélkül le is tárolja. Mindenki örül, de az első próbálkozások után valakiben felmerül az ötlet: nem lehetne-e összekötni a gépet a radiológiai vagy kórházi információs (RIS, HIS) rendszerünkkel, hogy ne kelljen újra beírni a betegadatokat? Jó esetben a válasz ilyenkor az, hogy lehet, csak X összegért – ahol X többnyire elég nagy szám – meg kell még vásárolni a „Worklist” modult. Rosszabb esetben meg kell elégedniük egy nemmel. Mi tehát az eredménye a nagy értékű beruházásnak? Vagy bosszankodva a zsebükbe nyúlnak, vagy arra kényszerül egy asszisztens, hogy a beteg adatait, amit eddig csak a RIS-be (HIS-be) kellett beírnia, most majd beírja a modalitásba is. új gépet vettek, de kétszer annyit gépelnek, az egész munka lassul egy nagyon drága beruházás eredményeként. A modalitás tehát DICOM kompatibilis, mégse hozta meg a kívánt eredményt. Hogyan lehetséges ez? Úgy, hogy a DICOM nem egyéb, mint kommunikációs sémák gyűjteménye, egy platform, ami azt mondja meg, hogy két gép hogyan beszélgessen egymással, de azt nem, hogy miről. Azaz nincs kötelező érvénnyel megvalósítandó funkció, a fenti példa alapján, nem kötelező a munkalista (“Worklist”) funkciót beépíteni a modalitásba. Azt gondolom, hogy egy orvostól, aki a modalitást kiválasztja (például a képminőség, 3D rekonstrukciós szolgáltatások, vagy egyéb szakmai szempontok alapján), nem várható el, hogy olyan mélységében ismerje a DICOM szabványt, hogy meg tudja ítélni, az új eszköz jól integrálható-e a meglévő rendszerbe. (A gyártók és forgalmazók vajon miért nem teszik ezt meg, az túlmutat e cikk keretein). INFOKOMMUNIKÁCIÓ KÉPALKOTÓ RENDSZEREK AZ IHE BEMUTATÁSA Szerencsére a helyzet ma már nem teljesen reménytelen. A gyártó cégek is felismerték annak a veszélyét, ha berendezésük nem illeszthető a már meglévő rendszerekbe. A radiológiai társaságok szintén úgy érezték, hogy szakmai súlyukkal szorgalmazni akarják az integrálhatóság növelését. Ezért hozták létre 1997-ben az IHE-t, azaz az Integrating the Healthcare Enterprise-t. Mára már létezik az IHE amerikai, európai és ázsiai részlege, sőt Európán belül, már négy nemzeti IHE szervezet is létrejött (angol, francia, olasz, német). 1. ábra Radiológiai munkafolyamat Az IHE a klinikai hatékonyság növelését tűzte zászlajára. Ez alatt értik a radiológiai és kórházi munkafolyamatok, a képek és leletek hozzáférésének javítását, és a gyártógyártó közötti kapcsolat-problémák megszüntetését. A megvalósítás több lépcsőben történik. Az első, hogy nem egy globális megoldással kísérleteznek, hanem célirányos megoldást adnak egy-egy valós problémára. Ezeket „Integration Profile”-oknak nevezik. Jelenleg hét ilyen létezik, de számuk az évek folyamán egyre nő. Minden „Integration Profile” közös jellemzője, hogy az adott feladatot felosztják a feladat megoldásában részvevő logikai egységekre, „Actor”-okra, és az „Actor”-ok közötti kapcsolatokra, azaz „Transaction”-ökre. Talán a legegyszerűbb, ha ezt egy példán ismertetjük. A „Scheduled Workflow” – azaz tervezett munkafolyamat – az egyik első és legfontosabb „Integration Profile” (1. ábra). Az „Actor”-ok kis bekeretezett dobozokban láthatók. Például felül az „ADT” felel a beteg adatok rögzítéséért, alul található a modalitás, középen az „Image Archive, Image Manager” páros felel a képek tárolásáért, míg az „Image Display” a képek megjelenítésé- ért. A dobozok közötti vonalak pedig azt jelzik, hogy melyik „Actor”-t melyik másikkal kell összekötni, és azon milyen DICOM, vagy HL7 üzeneteket kell megvalósítani. Anélkül, hogy a technikai részletekbe túlságosan belemennénk, csak három jellemzőt emelnék ki. Ebben az IHE féle kórházmodellben a betegadatok csak egyszer az ADT nevű egységnél kerülnek rögzítésre, mindenki más onnan veszi. Így elkerülhető, hogy egy páciens több különböző adattal szerepeljen a nyilvántartásban. A másik érdekesség, hogy a leletező munkahely nem a modalitáshoz, hanem az archívumhoz kapcsolódik. Ezért nem lehet leletezni azelőtt, hogy a képek tárolásra kerülnének. Így kerülhető el, hogy a képek elvesszenek, ugyanis ha előbb leleteznek, akkor esetleg elfelejtik átküldeni a képeket. Az IHE kórházmodell ezt a hibalehetőséget már felépítésénél fogva is kizárja. A harmadik jellemző, hogy a modalitás számára kötelezően előírja a „Worklist” megvalósítását is. Így a bevezetőben említett probléma nem állhat fenn, azaz soha nem fordulhat elő, hogy egy IHE-kompatibilis eszköz ne működjön teljesen, ha azt az IHE kórházmodellnek megfelelően integráljuk. Az IHE második lépcsője a „Technical Framework”. Ebben a kiadványban leírják az „Integration Profile”-ok megvalósításának módját. Benne található az „Actor”-ok és a „Transaction”-k pontos leírása. Ez az IHE harmadik évében 250 oldalas volt, mára már 450 oldalas lett. Az egyik legfontosabb amit tudni kell róla, hogy korlátozza és előírja a DICOM és HL7 szabványok használatát. Mivel egységesítésre kényszeríti a gyártókat, megszünteti az összeköttetési nehézségeket. A másik fontos dolog, hogy tisztázza a definíciókat, például hogy kell használni a naplósorszámot, vagy milyen azonosítókat kell feltétlenül kitölteni. Ezáltal a kórházak és osztályok közötti különbségeket korlátozza, ami szintén fontos lépés az integráció felé. A harmadik nagyon fontos lépés a konformitás előírása. A gyártóknak minden egyes eszközre fel kell tüntetniük, hogy az milyen „Actor”, és melyik „Integration Profile”-ban vesz részt. Az IHE harmadik lépcsője az évenkénti ellenőrzés, a Connectathon. (A connection és marathon szavakból alkotott fantázianév.) Minden évben egy hétre a gyártók összegyűlnek, hogy egy független bizottság, többnyire a szervező klinika szakembereinek felügyelete mellett összeköttetési teszteket hajtsanak végre. A legutóbb 2003 márciusában, Aachenben tartott Connectathonon 48 gyártó 86 rendszere működött együtt. Ez alatt az egy hét alatt a gyártóknak lehetőségük van arra, hogy minél több kapcsolatot létesítve más gyártók berendezéseivel a saját hibáikat kiküszöböljék, eltérő szabványértelmezéseiket megszüntessék, vagy esetleg rávilágítsanak a „Technical Framework” esetleges hibáira, pontatlanságaira. Az így letesztelt berendezések aztán a kórházi összekötéseknél már kevés meglepetést produkálnak. A sikeres tesztet követően kerül IME II. ÉVFOLYAM 9. SZÁM 2003. DECEMBER 49 INFOKOMMUNIKÁCIÓ KÉPALKOTÓ RENDSZEREK sor az „Integration Statement” kiadására, ami tulajdonképpen az IHE-kompatibilitást jelenti, de fontos hangsúlyozni, ez csak a tesztelt termékre vonatkozik, és nem az adott cégre. Az IHE negyedik lépcsője a nemzeti demonstrációk. Ezeken már nem tesztelés folyik, hanem „mintakórházak” jönnek létre, és az érdeklődő orvosok részére az IHE szerinti működést mutatják be. Egyelőre csak angol, francia, olasz és német demonstrációk voltak. A nemzeti IHE-k működését Európán belül az indokolja, hogy a nemzeti sajátságokat nincs értelme mindenkire ráerőszakolni. Így például a különböző karakterkészleteket sem, azaz minden ország esetében elegendő, ha az angol karaktereken kívül a saját karaktereit kezelni tudja. Néha az eltérő törvényi szabályozások miatt kell módosítani valamit, például Franciaországban törvény tiltja valakinek az etnikai hovatartozását rögzíteni, hacsak az nem függ össze a betegségével. Ez implementációs szempontból kis módosítással jár. Ezek a kis különbségek azonban eltörpülnek a hasonlóságok mellett. ÖSSZEGZÉS Összefoglalva, a DICOM kompatibilitás fogalma alkalmatlan arra, hogy mélyebb DICOM ismeret nélkül eldöntsük az adott berendezés használható lesz-e meglévő informatikai rendszerünkben vagy sem. Erre sokkal inkább alkalmas az IHE kompatibilitás fogalma, de ez is csak akkor, ha a teljes informatikai rendszer (HIS, RIS, PACS, modalitások) erre épül. Mivel kevés lehetőség van ezek együttes cseréjére, csak az tanácsolható, hogy új beszerzéseknél, vagy felújításoknál ha szakmai szempontok a döntőek, akkor IHE kompatibilis eszközt válasszunk. Tekintve azt, hogy multinacionális cégek az USA-ban és Európa nyugati felén nagy hátszelet biztosítanak az IHE fejlődésének, nem nehéz megjósolni, hogy hamarosan nálunk is terjedni fognak a jól integrálható IHE megoldások. Remélem mindenkit sikerült meggyőznöm, hogy bár a kórházi információs rendszerek nem a leglényegesebb elemei egy kórház működésének, gondos előrelátással, jó alapokra helyezve rengeteg későbbi bosszúságtól és pénzkiadástól kímélhetjük meg magunkat. A SZERZÔ BEMUTATÁSA Maróti Tamás 1985-ben végzett az Eötvös Lóránd Tudományegyetem fizikus szakán. Első munkahelye Központi Fizikai Kutató Intézetben volt, ahol elsősorban számítógépes képfeldolgozással foglalkozott űrkutatási területen. Az orvosi elektronikával a 77 Kft. fejlesztőjeként ismerkedett meg. A General 50 IME II. ÉVFOLYAM 9. SZÁM 2003. DECEMBER Electric Medical Systems munkatársaként érdeklődése a kórházi informatikai rendszerek – elsősorban képalkotó és képtároló berendezések – összekapcsolása felé fordult. Kapcsolatba került az IHE szervezetével és részletes ismereteket szerzett annak működéséről. Jelenleg a Medimon Kft. fejlesztési igazgatója, ahol heterogén (több gyártó által szállított) képalkotó rendszerek összekapcsolásával és az IHE népszerűsítésével foglalkozik.
