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 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
1. 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
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
Felhasználó 1 Felhasználó 2 Felhasználó 3 Információs rendszer 1 Szemantikus interoperábilitás Információs rendszer 2 Rekord megjelenítő Elektr. szabványok Funkcionális interoperábilitás Elektr. szabványok Csatorna 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
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 Extract Repository::Repository +repository_item 0..1 Access_Policy Non_Patient_Related_Extract +access_control EHR_Extract - ehr_system: II - ehr_id: II - time_created: TS +all_versions - hca_authorising: II - rm_id: II = MSZ22800v1.0 Version Extract_Constraint - time_period: IVL_TS 0..1 - all_versions: Boolean +constraints - multimedia_included: Boolean Record_Component - other_constraints: String - rc_id: II Link - archetype_ids: II [] - name: String - nature: CV - meaning: CV [0..1] +links - target: II - synthesised: Boolean - role: CV - orig_parent_ref: II [0..1] - follow_link: Boolean = true Audit_Info - sensitivity: CS_SENSITIVITY - version_specific: Boolean +feeder_audit - policy_id: II [] - ehr_system : II 0..1 - time_committed: TS - committer: II - revision_status: CS_REV_STAT [0..1] - reason_for_revision: CV - previous_version: II [0..1] - contribution_id: II [0..1] - version_set_id: II Content +audit_trail 1 +content +data Composition 1 - composer: II [0..1] Entry +members Section Patient_Related_Extract - subject_of_care: II +directory +cl ini cal _sessi on 0..1 0..1 Folder - compositions: II [] +sub_folders Clinical_Session - session_time: IVL_TS - hca_legally_responsible_for_care: II [0..1] - healthcare_facility: II [0..1] - service_settings: CV [0..1] - territory: CS_TERRITORY [0..1] - info_provider: Functional_Role [0..1] - annotations: CS_ANNOTATIONS [0..1] - act_id: II [0..1] - act_status: CV [0..1] +subject_of_information +items 1 Item Related_Party +attestations - emphasis: CV - obs_time: IVL_TS - item_category: CS_ITEM_CAT - party: II [0..1] - relationship: String Attestation_Info - time: TS - proof: SignatureType [0..1] - attested_view: ED [0..1] - reason_for_attestation: CS_ATTEST [0..1] - target: II [1..*] +parts +other_participations +other_paticipations Functional_Role Cluster +attester - function: CE - structure_type: CS_STRUCTURE_TYPE - perform er: II 1 - mode: CV Element DataTypes::DATA_VALUE +value - nullflavor: CS_NULL_FLAV [0..1] 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: <?xml version="1.0" encoding="utf-8"?> <name>szisztémás vérnyomás</name> <emphasis><displayname>emph0</displayname></emphasis> <obs_time> <high> <time>200801021234</time></high> </obs_time> <item_category> 5
<codevalue>item_catgory 01</codeValue> </item_category> <structure_type> <codevalue>record</codevalue> </structure_type> <parts xsi:type="element"> <rc_id> <extension>0002</extension> </rc_id> <name>systole</name> <meaning> <codevalue>systolicbloodpressure</codevalue> </meaning> <synthesised>false</synthesised> <sensitivity> <codevalue>0</codevalue></sensitivity> <emphasis> <displayname>emph0</displayname> </emphasis> <obs_time> <high> <time>200801021234</time></high> </obs_time> <item_category> <codevalue>item_catgory 01</codeValue> </item_category> <value xsi:type="pq"> <value>120</value> <unit> <codevalue>hgmm</codevalue> </unit> </value> </parts> <parts xsi:type="element"> <rc_id> <extension>0003</extension> </rc_id> <name>diastole</name> <meaning> <codevalue>diastolicbloodpressure</codevalue> </meaning> <synthesised>false</synthesised> <sensitivity> <codevalue>0</codevalue> </sensitivity> <emphasis> <displayname>emph0</displayname> </emphasis> <obs_time> <high> <time>200801021234</time></high> </obs_time> <item_category> <codevalue>item_catgory 01</codeValue> </item_category> <value xsi:type="pq"> <value>80</value> <unit> <codevalue>hgmm</codevalue> </unit> </value> </parts> </Cluster> 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
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
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 SQL Viewer EHR OR Model 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
[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 9