1 EGY ORACLE ELEKTRONIKUS EGÉSZSÉGÜGYI REKORD AN ORACLE ELECTRONIC HEALTH RECORD Sipos Henrietta 1, Veréb Krisztián 2 1 Debreceni Egyetem Egészségügyi...
EGY ORACLE ELEKTRONIKUS EGÉSZSÉGÜGYI REKORD AN ORACLE ELECTRONIC HEALTH RECORD 1
Sipos Henrietta1, Veréb Krisztián2 Debreceni Egyetem Egészségügyi Kar 2 Connexis Kft, Debrecen Összefoglaló
Az elmúlt tíz évben számos erőfeszítés történt már az Elektronikus Egészségügyi Rekordok (EHR) szabványosítása terén, melyek az egészségügyi rendszerek közötti kommunikációt segítenék elő. Az EHR szabvány adatmodellje az objektumorientált technológián alapszik, és az üzenetközvetítés nyelve az XML. Természetesen az üzenetek tárolására is megjelenik a rendszerekben az igény. Hogy ezt lehetővé tegyük, létre kell hoznunk egy olyan adatbázist, mely az ilyen jellegű XML üzenetek tárolásán túl lehetőséget teremt azok lekérdezésére is. Az EHR rendszerekkel szemben számos egyéb követelmény is létezik, ilyenek például az interaktivitás, az interoperábilitás, a biztonság illetve a valós-idejűség. Mivel a tradicionális relációs- és objektumorientált adatbázisrendszerek is rendelkeznek ezekkel a tulajdonságokkal, nyilvánvalóan adódik azok használata az EHR rendszerekben. Ebben az előadásban az EHR szabvány alkalmazásával kapcsolatos teendőkről szeretnék beszélni, illetve egy EHR adatbázis alapjait bemutatni, mely az Oracle eszközrendszerére épül.
Kulcsszavak: EHR, Oracle
Abstract In the past ten years, much effort has been taken to standardize the Electronic Health Records (EHR) to ease messaging between health systems. In the EHR standard, the data model is based on object-oriented technology, and the common language for sending messages is XML. Of course, the need of storing such images also arises. To reach this goal, we have to create a database where such XML messages can be stored and processed, and should give a framework to query them. Lots of requirements have been stated against EHR systems such as to be interactive, interoperable, secure and real-time which are also addressed by traditional relational and object-relational databases so it is straightforward to use such a DBMS for data storage. In this lecture, we will show some of the various tasks to do about using the EHR standard and we will show the foundation of an Electronic Health Database based on the features of Oracle.
Keywords: EHR, Oracle
1
Informatika a felsőoktatásban 2008
1.
Debrecen, 2008. augusztus 27-29.
Bevezetés
Az EHR (Electronic Health Record), azaz egy elektronikus egészségügyi rekord nem más, mint egy olyan egészségügyi adatszerkezet, mely a különféle forrásokból érkező egy adott beteghez tartozó adatokat tartalmazza. Ideális esetben az összes különféle adatot egybefogja, függetlenül attól, az milyen adatszolgáltatótól érkezik. Az egészségügyben kezelt információ igen bonyolult és gyorsan változó struktúrájú, nagy mennyiségű, és általában bizalmas [16]. Ezen a vonalon elindulva tehát egy EHDB (Electronic Health Database), azaz egy elektronikus egészségügyi adatbázis ilyen adatokat tartalmazó, multimédiás adatbázis, melyben megtalálhatjuk a betegek különféle, a legtöbb esetben folyamatosan változó egészségügyi adatait, legyen az Röntgen-kép, CT vagy MR kép, különféle időben vett vérnyomás adatok vagy akár ambuláns lapok összessége. Az EHR egységekből álló dokumentumokat, mappákat (kartonokat) el kell juttatni az egyik adatbázisból a másikba, az egyik orvosi rendszerből a másikba. Az ilyen kartonokat hívjuk üzeneteknek. Sematikusan nézve tehát egy egészségügyi rendszer működése nem más, mint ilyen üzenetek létrejötte, azok letárolása, illetve eljuttatása egyik rendszerből a másikba (egy ideális rendszerben azok megszűnése elképzelhetetlen). Természetesen a fenti alapfogalmakat sokkal mélyebben is definiálhatjuk (pl. a HMSS [6] szerint az EHR egy titkos, valós-idejű, ellátott-centrikus klinikai információs erőforrás.) Az EHR az orvosi döntések elősegítését is szolgálja, ugyanis az EHR rekordok magukon hordozzák az információ tartalmon túl azok keletkezésének helyét, idejét, vagy akár okát is. Az EHR egyszerűsíti a klinikai adatfolyamokat és folyamatokat, rövidre zárja a felesleges körutakat, és mintegy mellékhatásként kiindulási adatokat szolgáltat a klinikai döntéseken túl az orvosi rendszerek egyéb moduljai számára is, mint például a számlázás, minőségbiztosítás, különféle statisztikák készítése vagy akár erőforrás tervezés. Bármelyik oldalról is kezdjük el vizsgálni az egészségügyi rekordokat, azok mind közösek a céljaikban, azaz csökkenteni a papírmunkát, elkerülni a kézi kartotékozást, rendezést, keresést, eliminálni a hiányos riportokat, és legfőképp javítani az ellátás minőségét. 2.
EHR szabványok
A szabványokkal kapcsolatban bővebb összefoglalót olvashatunk a [8]-ban is, de álljon itt most néhány szó, az EHR történetével kapcsolatban. Az első jelentősebb erőfeszítés a CPR (Computer-based Patient Record) létrehozása volt 1991-ben, melyet az IOM (Institute of Medicine) publikált. Ez már kitűnt azzal a megközelítési elvével, hogy különbséget tett a rekordok között. Így például megkülönbözette a páciensre vonatkozó adatokat a többi klinikai vonatkozású adattól. Szintén kiemelkedő volt, hogy az IOM nemcsak az EHR-rel, hanem annak környezetével, azaz az EHR rendszerrel is foglalkozott. Valahol ide datálhatjuk tehát az EH adatbázisok létrejöttét. A következő nagyobb lépés 2001-ben következett be, amikor az ASTM először jelentette ki azt, hogy az EHR az valójában egy dokumentum. Ez nagyon fontos lépés, ugyanis ekkor merült fel először az egészségügyi rekordok dokumentumként való kezelése is (nemcsak kartoték, hanem tárolás és üzenetküldés szintjén is). Ez azt jelenti, hogy felmerült az XML, mint dokumentum-tároló/közlő médium neve a klinikai köztudatban. Szintén kiemelendő,
2
Informatika a felsőoktatásban 2008
Debrecen, 2008. augusztus 27-29.
hogy megjelenik a longitudinális, (bizonyos esetekben hívhatnánk retrospektívnek is) hosszú időszakot átölelő rekordok fogalma, mely már előre vetíti az adatbázisszerű megoldások igényét. Említésre méltó még a 2002-es ISO szabvány is, mely kijelenti, hogy egy üzenet az több EHR rendszerből is származhat, sőt, akár több beteg adatait is összefoglalja, ily módon azt akár nevezhetjük virtuálisnak főképp, ha csak bizonyos adatokat (kivonatokat) vesz át más EHR kivonatokból. Manapság is rengeteg létező szabvány van használatban a klinikai rendszerekben, melyek megpróbálnak igazodni a helyi alkalmazási szokásokhoz, törvényi szabályozásokhoz. Nézzünk ezekre néhány példát. A legelterjedtebb szabvány a HL7 [7], melyet 2001-ben említettek meg először a Standard Insight-ban. A HL7 elsődleges céljának az amerikai elektronikus egészségügyi rekordok szabványos csereformátumának biztosítását tűzte ki maga elé. Rengeteg almodelljét definiálta a létrehozására megalakult EHR SIG csoport, melyek nagyrészt UML-ben készültek el. Íly módon egyértelmű volt, hogy nemcsak az EHR-t magát, hanem a kezeléséhez szükséges rendszert és csatornát is rögzítik. A modell meglehetősen flexibilis, de ahhoz, hogy ezt elérhesse, meglehetősen bonyolultra sikerült, így ez egyik legnagyobb hátránya is (a bevezetésének költségein túl), hogy túlságosan komplex. A HL7 vezeti be a RIM (Referencia Információs Modell) fogalmát is, melyet a legtöbb szabvány átvesz. Az OpenEHR [1] egy nemzetközi nyílt forrású szabvány. Az azt kezelő OpenEHR alapítvány egy nonprofit alapítvány, melynek célja az EHR (mint rendszer), klinikai kutatások és tapasztalatok alapján történő nyílt, és flexibilis megalkotása volt, mely támogatja az interoperábilitást. Alapvetően ő is több modellről beszél, és egyik legfontosabb tulajdonságaként bevezeti az arhetípus rendszert. Az arhetípusok olyan speciális klinikai szabályok, melyek elsődlegesen csak az adott alkalmazási területre jellemzőek. Az arhetípus bevezetésével megnő a rendszer flexibilitása. Az OpenEHR hazai vonatkozásban is fontos, a [16]-ban olvashatunk annak magasszintű hazai adaptációjáról is. Bármelyik szabványt is kezdjük el vizsgálni, azt láthatjuk, hogy mindegyikben van valamilyen törekvés egy univerzális EHR létrehozására. 3.
A dupla modell elv
A dupla modell elv az univerzális EHR alapja. Ez azt jelenti, hogy a szabványnak különbséget kell tennie a kevésbé változó, statikus RIM és a többi, dinamikusan változó, de a RIM-re épülő modell között (ilyen az arhetípus rendszer is). A modelleket jól meg kell fogalmazni valamilyen egyértelmű rendszerben. Erre az UML nyelv a legalkalmasabb. Mindazonáltal kiemelt fontosságú a hordozhatóság is, így az UML-nek nem a teljes eszköztára, csak egy egyszerűsített eszközhalmaza használható. Szintén nagyon fontos a rendszerek közötti interoperábilitás (mely legfőképp heterogén környezetben értendő), így a lehető legjobb mód a kommunikációra, ha az üzenetek realizációjához az XML-t használjuk. Az interoperábilitás szintjeit az 1. ábrán láthatjuk.
3
Informatika a felsőoktatásban 2008
Felhasználó 1
Információs rendszer 1
Elektr. szabványok
Csatorna
Szemantikus interoperábilitás
Funkcionális interoperábilitás
Debrecen, 2008. augusztus 27-29.
Felhasználó 2
Felhasználó 3
Információs rendszer 2
Rekord megjelenítő
Elektr. szabványok
XML
Csatorna
1. ábra, az interoperábilitás szintjei
Az ábrából jól látható az a követelmény, hogy a felhasználók a saját rendszereiken keresztül akarnak kommunikálni, (szemantikus interoperábilitás), azaz őket az entitásokhoz rendelt adatok érdeklik. A funkcionális interoperábilitás az, amely a heterogén rendszerekben a szemantikus adatok szintaktikájával foglalkozik. Ezen a ponton kell az elektronikus szabványokhoz fordulnunk. Mindemellett gyakori, hogy a felhasználó úgymond bele akar hallgatni a kommunikációba, azaz egy üzenetet esetlegesen egy drága egészségügyi rendszer mellőzésével is meg akarhat tekinteni (nem feldolgozni, csak megnézni), tehát egy ilyen rekord megjelenítőt is implementálni kell az EHR-hez. Így jutunk el az MSZE 22800-hoz, mely a fenti elveket szem előtt tartva egy a magyarországi viszonyokhoz is jól illeszkedő EHR modellt próbált meg létrehozni. 4.
A magyar út
Mint ahogy az várható volt, a szabványosítási folyamatok a magyar egészségügyben is elkerülhetetlenné váltak [2][3][12][13]. A támasztott igényeket az alábbiakban sorolhatjuk fel:
Élethossziglan tartó EHR Elsődleges elvárás: klinikusi és beteg interaktivitás Jogi aspektusok, nyomozhatóság, ellenőrizhetőség, követhetőség Az egészségügyi rekordok megosztásának elősegítése Alkalmasság elsődleges és akut ellátásra Másodlagos felhasználásra alkalmasság: oktatás, kutatás, népesség orvoslás Nyitott szabvány: arhetípus Támogassa a klinikai adatstruktúrákat: listák, táblák, időbeliség Interoperábilitás XML használat Kapcsolódás más szabványokhoz (CEN, HL7v, OpenEHR)
Így 2006-ban egy előszabvány került elfogadásra, melynek neve MSZE 22800 [9][10]. Ez egy megközelítőleg univerzális EHR modell, azaz a dupla modell elvre épül. A RIM part neve HRIM az MSZE 22800 szabványban, melynek száma 22800-1. Az üzenetszabvány több részből tevődik össze. Ezek az e-Kórlap (22800-2) az e-Konzílium (22800-3), az e-Lelet (22800-4), az e-Recept (22800-5) és az e-Finanszírozás (22800-6). A 22800-1 itt is egy UML modell, melynek ősosztálya az EHR_Extract. Ennek példányai tárolják a különféle rekordokat. A rekordok Element, Entry és Cluster példányokat tartalmazhatnak.
4
Informatika a felsőoktatásban 2008
Debrecen, 2008. augusztus 27-29.
Az eKórlap olyan adat-együttes, mely széles értelemben vett bármilyen páciens vs. ellátó szervezet közötti esemény (pl. kórházi kezelés kórlapja, ambuláns rendelési ellátás naplója, vagy családorvosi ellátási esemény rögzítése) kapcsán lehetővé teszi a páciens, a szolgáltató, a közöttük fennálló ellátási viszony adminisztratív azonosítását, az eseménnyel kapcsolatos orvosi illetve egészségügyi adatok rögzítését [11]. Meg kell említenünk, hogy a nemzetközi szabványok erősen ajánlják a virtuális egészségügyi rekordok helyett az egy ellátottra vonatkozó rekordok használatát. Ezt amúgy az extract-ban egy attribútum segítségével külön jelezhetjük is. Az 2. ábrán az EHR Extract RIM-jének magját láthatjuk [9] [10] [11]: cd Ex tract Extract_Constraint
Repository::Repository
+co nstraints +repository_i tem
0..1
0..1 -
tim e_period: IVL_T S al l_versions: Boolean m ultim edi a_in cl uded: Bool ean other_ constrai nts: Stri ng archetype_ids: II [0..*]
Ac cess_Policy
Non_Patient_Related_Ex tract
Audit_Info
0..* -
+access_cont rol
EHR_Extract -
ehr_system : II ehr_i d: II ti m e_created: T S hca_au thorisi ng: II rm _id: II = M SZ22800v1.0
e hr_syste m : II ti m e_com m i tted: T S com m i tter: II revisi on_status: CS_REV_ST AT [0..1] reason_for_revision: CV p revious_version : II [0..1 ] contri bution_i d: II [0..1] version_ set_i d: II
Record_Component
+fee der_aud- it 0..1
0..* -
+l inks
nature : CV target: II role: CV foll ow_li nk: Bool ean = true versi on_speci fi c: Boo lean
Content
1
+audi t_tra il
Link
rc_id : II nam e: Strin g m ea ning: CV [0..1] synthesi sed: Bool ean ori g_parent_ ref: II [0..1] sensi ti vi ty: CS_SENSIT IVIT Y poli cy_i d: II [0..*]
+content 0..*
+a ll _versio ns +data
Version 0..*
1 -
+m em bers
Composition
0..*
com poser: II [0..1] Section Entry
Patient_Related_Extract -
+d irectory
0..1
subj ect_of_ca re: II
i nfo_provider: Function al_Rol e [0..1] annotations: CS_ANNOT AT IONS [0..1] act_i d: II [0..1] act_status: CV [0..1]
Clinical_Session
Folder -
-
+cl ini cal _sessi on 0..1
-
com posi ti ons: II [0..*] +sub_ fol ders 0..*
+attestati ons
session_ ti m e: IVL_T S hca_l egal ly_responsibl e_for_care: II [0 ..1] healthcare_faci l ity: II [0..1] service_setti ngs: CV [0..1] terri tory: CS_T ERRIT ORY [0..1 ]
+i tem s
-
0..*
Atte station_ Info -
tim e: T S proof: SignatureT ype [0..1] attested_view: ED [0..1] reason_for_atte station: CS_AT T EST [0..1] target: II [1..*]
+su bject_o f_i nform ati on 0..*
1
Item
+pa rts
Related_ Party
em phasi s: CV ob s_ti m e: IVL_T S i te m _cate gory: CS_IT EM _CAT
-
party: II [0 ..1] rel ationshi p: Stri ng
0..*
+other_parti ci pations +other_p ati ci pations 0..*
0..*
Functional_Role +attester 1 -
functi on: CE pe rform er: II m ode: CV
Cluster -
structure_type: CS_ST RUCT URE_T YPE
Element
DataTy pes::DATA_VALUE
+valu e 0..1
-
n ull Flavor: CS_ NULL_FLAV [0..1]
2. ábra, az EHR RIM (részlet)
Persze ez így nem túl informatív számunkra. Viszont az jól látszik belőle, hogy egy meglehetősen összetett kapcsolatrendszerrel rendelkező modellről van szó, amely viszont egy lebutított UML jelölésrendszert használ, ahol a főbb jellemzők az alábbiak:
Nincsenek interfészek Csak az egyszeres öröklődés támogatott Leggyakoribb reláció a tartalmazás
Egy a fenti modellnek megfelelő lehetséges üzenetre példa, az alábbi: … szisztémás vérnyomás … <emphasis>EMPH0
A fenti példa egy vérnyomás mérés RIM-nek megfelelő XML üzenet alakját mutatja meg. 5.
Egészségügyi adatbázisok
Ahogyan létrejönnek az egészségügyi adatok, úgy azokat tárolnunk is kell, hiszen az EH rekordok hosszú távú adatokat tartalmaznak, nem rövid távú számítások inputjai. Így a létezésük sem más adatok származtatását célozza meg, hanem az önmaguk létezését (az adatrögzítés ténye a fontos, nem pedig a célja, hiszen a rögzítés pillanatában még a cél nem biztos, hogy ismert). Tehát nagy súlyt kell helyezni a rögzítésre is, és ebben a kontextusban merül fel jobban az egészségügyi adatbázisokra az igény. Egy EH adatbázis általánosságban egy olyan multimédiás adatbázis, mely egyszerre tartalmaz szöveges és képi (pl. Röntgen, CT vagy MRI) információt az ellátottról. A tároláson túl az adatbázisnak támogatnia kell az üzenetküldést és magát az RIM-et is.
6
Informatika a felsőoktatásban 2008
Debrecen, 2008. augusztus 27-29.
Manapság már számos adatbáziskezelő rendszer tud RIM adatokat kezelni. A legnagyobb egészségügyi adatbázis beszállító az Oracle. Az Oracle HTB (Healthcare Transaction Base) [5] a HL7-et támogatja és az Oracle E-Business (Oracle Application) platformon alapszik. Az Oracle HTB-nek két szintje van, az egyik a HTB API, a másik pedig a HTB mag. Az első függvények és eljárások specifikációját tartalmazza, a második pedig a tárolt eljárásokat, típusokat, csomagokat, objektumokat és kollekciókat, melyek a fizikai adatokat kezelik. Ebben az esetben nincs alkalmazási réteg, ez valójában csak egy orvosi segédlet, mely az Oracle alapú klinikai rendszerek alappillére lehet. Az Oracle HTB az OHI-t használja (Oracle Health Intelligent) [15], mely a HTB-re épül, s betöltőprogramokat, sémákat, alkalmazásokat, riportkészítőket tartalmaz. Az OHI képezheti a magasabb szintű alkalmazások kiindulási rétegét. Az Oracle HTB-nek több komponense van. Az egyik az Enterprise Object Model (formálisan ez nem más, mint a HL7 RIM), az Enterprise Terminology Services (különféle országok sajátságainak kezelésére), Clinical Services (ez a fő alkalmazási komponens) és egyéb modulok (biztonság, konfiguráció stb.). A HTB ereje, annak funkcionalitásában rejlik. Ezeket az adminisztrációs és klinikai üzleti logika, valamint a Core Application Services biztosítja, ez utóbbi felelős az üzenetküldésekért is. Mindazonáltal az Oracle HTB előnyei mellett számos hátránnyal is rendelkezik. A legnagyobb probléma, mint a HL7 esetében is, a túlzott bonyolultság. Nehezen vezethető be a legtöbb kórházba, rengeteg tréninget igényel és a magyar viszonyokhoz képest meglehetősen drága is. Azt már csak kiegészítésként említjük meg, hogy értelemszerűen nem támogatja MSZE 22800 szabványt. 6.
Egy lehetséges Oracle megoldás
Dr. Horváth Ottó és társai azt írják a [4]-ben, hogy az egészségügyi informatika alkalmazásának módszertani kérdéseit illetően a technikai fejlődésből adódóan alapvető feladat a részrendszerek együttműködése, integrációja, komplex rendszerek kialakítása. Törekedni kell a rendszerek hardvertől történő függetlenítésére (Open Systems) Az egyedi egy felhasználói felülethez alkalmazkodó - rendszerek helyett preferálni kell az általános megoldást nyújtó keretrendszereket. Törekedni kell az intelligens orvosi műszerek és eszközök információrendszerekhez történő illesztésére. Az automatikus jel és képfeldolgozás, képi információk tárolása több célú felhasználása ma a fejlett országokban, az egészségügyi informatika leggyorsabban fejlődő területe. Fel kell készülni ezen technikák fogadására, alkalmazására. Ennek megfelelően próbáltuk a saját rendszerünket és a fentieknek részben eleget tevő MSZE 22800 RIM-et összehangolni. Elsődlegesen az MSZE 22800 üzeneteire kell koncentrálnunk, mely objektum relációs alapokon nyugszik. Így kézenfekvő volt, hogy ORDBMS-ként mi is az Oracle-t [14][15] választottuk. A mi megoldásunkban az eredeti XML üzenetek natívan letárolódnak. Az Oracle beépített XML feldolgozójának köszönhetően tárolt eljárásokkal a natív XML típusokból az adatok kinyerésre kerülnek. Az íly módon megkapott rekordok így már szabványos SQL utasításokkal kezelhetővé válnak. Szintén egy érv, mely az Oracle mellett szól, hogy az orvosi képalkotó rendszerek által szolgáltatott képek nemcsak BLOB-ként tárolhatók, hanem a beépített InterMedia és SQL/MM funkcionalitásnak köszönhetően StillImages, vagy ORDImages formában is. Sőt a Java tárolt eljárásoknak köszönhetően akár orvosi elő-
7
Informatika a felsőoktatásban 2008
Debrecen, 2008. augusztus 27-29.
képfeldolgozási algoritmusok futtatására is lehetőség van. Egy magasszintű leírása ennek a rendszernek a 3. ábrán látható. XML
EHR Java API
EHR RIM
EHR Java Viewer EHR OR Model EHR SQL Viewer
3. ábra, egy Oracle alapú EH rekord környezete
Mint ahogyan az látszik a rendszernek része egy EHR Java Viewer program is, mely az XML üzeneteket feldolgozva képes azok tartalmának megjelenítésére is. A rendszer egyik fontos alapépítő eleme az EHR Java API, mely az XML üzeneteket EHR RIM példányokba menti le. Az EHR RIM és az EHR OR modell között egy speciális leképezés található, mely az UML OO specialitásait OR, illetve tiszta R jellegzetességekké alakítja. 7.
Zárszó
A fentiekben bevezető képet kaphattunk az EHR nemzetközi és hazai fejlődéséről. Elmondhatjuk, hogy meglehetősen gyorsan sikerült alkalmazkodni a kialakult igényekhez, és elkészíteni egy olyan leképezést, mely az MSZE 22800-nak megfelelő XML üzeneteket gyorsan és kényelmesen le tudja tárolni egy Oracle rendszerben. Következő lépésként egy, direkt az egészségügyi rekordok tárolásához létrehozott adatbáziskezelő rendszert szeretnénk jobban górcső alá venni, hogy az alkalmas-e a magyar XML üzenetek tárolására, illetve kezelésére. Irodalomjegyzék [1] Beale, T., Heard, S., Kalra, D., Lloyd, D., The OpenEHR EHR Reference Model, www.openehr.org [2] Dr. Horváth Lajos, Puskás Zsolt Péter, Héja Gergely, Nagy István, A hazai egészségügyi elektronikus adatcsere szabványainak adatmodellje, InfokommunikációeEgészségügy 4(1), 2005, 40-46 [3] Dr. Horváth Lajos, Puskás Zsolt Péter, Héja Gergely, Nagy István, A hazai egészségügyi elektronikus adatcsere üzenetszabványai, InfokommunikációeEgészségügy 4(2), 2005, 45-47 [4] Dr. Horváth Ottó, Dr. Jámbor Attila, Dr. Márkus Katalin, Dr. Skaliczky Zoltán, Egészségügyi informatika oktatása a Széchenyi István Főiskolán, Informatika a Felsőoktatásban 96 - Networkshop 96, Debrecen, 1996. augusztus 27-30. 400-406
8
Informatika a felsőoktatásban 2008
Debrecen, 2008. augusztus 27-29.
[5] Healthcare Transaction Base, http://www.oracle.com/industries/healthcare/ healthcare-transaction-base-datasheet.pdf [6] HIMSS, An analysis of Health Information Standards Development Initiatives, April 2003, HIMSS Standards Insight [7] HL7 V3 Reference Information Model V02-02, www.hl7.org [8] Kollár Lajos, Sipos Henrietta, Veréb Krisztián, Object-relational EH databases, ICAI 2007, Eger [9] MSZE 22800 Magyar Előszabvány, Egészségügyi Informatika, Magyar Szabványügyi Testület, 2004 [10] MSZE 22800 Magyar Előszabvány Enterprise Architect UML model, http://www.euagazat.hu/portal/server.pt/gateway/ PTARGS_0_237_3225_0_0_18/index.htm [11] Nagy István, Az eEgészség program eKórlap elektronikus dokumentum szabvány, 2004. október 21. Budapest, www.euagazat.hu/portal/server.pt/gateway/PTARGS_0_200_1954_0_0_18/ [12] Puskás Zsolt Péter, Dr. Horváth Lajos, Héja Gergely, Nagy István, eSzabványok: Kommunikáció szabványos üzenetekkel, InfokommunikációeEgészségügy 4(3), 2005, 40-42 [13] Puskás Zsolt Péter, Dr. Horváth Lajos, Héja Gergely, Nagy István, eSzabványok: Üzenetek, dokumentumok, adatok, InfokommunikációeEgészségügy 4(4), 2005, 41-43 [14] Oracle Database 10g Enterprise Edition, http://www.oracle.com/technology/ products/database/oracle10g/pdf/ DS_General_Oracleq_Database10gR2_EE_0605.pdf [15] Oracle Healthcare Intelligence, http://www.oracle.com/industries/ healthcare/healthcare-intelligence-datasheet.pdf [16] Vassányi István, Gaál Balázs, Dr Balkányi László, Információs referenciamodellek az egészségügyben, IMEI 2(3), 2003 április, 37-41
