CEN pren konformer Export von medizinischen Daten aus einem Entity-Attribute-Value basierten Informationssystem

Transkript

1 CEN pren konformer Export von medizinischen Daten aus einem Entity-Attribute-Value basierten Informationssystem C. Rinner, G. Duftschmid, T. Wrba Institut für Medizinische Informations- und Auswertesysteme Medizinische Universität Wien, Spitalgasse 23, 1090 Wien In dieser Arbeit wird ein Ansatz zum Export von Daten aus einem Gesundheitsinformationssystem präsentiert, der auf dem europäischen Standard CEN pren basiert. Der Export wird mittels ORACLE PL/SQL und der PL/SQL DOM API umgesetzt, EHR-Extrakte werden mit Hilfe von XML-Schema beschrieben. Die resultierenden EHR- Extrakte werden für den späteren Gebrauch in einem Repository hinterlegt. Weiters wird eine Methode zur strukturellen Repräsentation von EHR-Extrakten mittels XML-Schema dargestellt. Einleitung Das Europäische Komitee für Normung (CEN) arbeitet an einem 5-teiligen Standard (pren [1]), der eine Kommunikationsarchitektur zum Austausch von elektronischen Gesundheitsakten (EHR) festlegt. Dieser Standard beschreibt den semantisch-interoperablen Austausch von EHR-Inhalten zwischen Gesundheitsinformationssystemen (HIS). Er basiert auf dem Zwei-Modell-Ansatz, der Information und Wissen trennt. Im ersten Teil des Standards wird das Referenzmodell beschrieben, dessen Instanzen die sogenannten EHR-Extrakte dazu dienen, jegliche medizinische Information, die in einem EHR gespeichert wurde, unabhängig von deren Ursprung darzustellen. Im zweiten Teil des Standards wird das Konzept der Archetypen [2, 3] und eine Sprache zum Spezifizieren von Archetypen vorgestellt. Archetypen enthalten das medizinische Wissen und dienen als Baupläne für Instanzen des Referenzmodells. Ein Archetyp für eine Blutdruckmessung könnte z.b. vorschreiben, dass ein entsprechendes EHR-Extrakt aus drei RECORD COMPONENTs des Referenzmodells bestehen soll, einem ENTRY als Container und zwei ELEMENTs für den systolischen und den diastolischen Blutdruck. Die Kombination aus Referenzmodell und Archetypen ermöglicht es, Daten voll strukturiert und semantisch eindeutig darzustellen. Das System ArchiMed [4] ist ein HIS, das am Institut für Medizinische Informations- und Auswertesysteme der Medizinischen Universität Wien zum Management klinischer Studien entwickelt wurde. Es ermöglicht Dateneingabe, statistische Auswertung, Patientenrekrutierung und interaktives Design von Case Report Forms (CRFs). ArchiMed basiert auf dem Entity- Attribute-Value (EAV) Design [5], das ein gängiges Datenmodell zur Realisierung eines HIS darstellt. Im Rahmen dieser Arbeit wird die Implementierung eines Exportmechanismus vorgestellt, der unter Anwendung des Vorstandards pren Daten aus dem System ArchiMed in einem Repository als EHR-Extrakte ablegt, wobei diese EHR-Extrakte die Vorgaben eines Archetyps erfüllen. In einer Verteilungsarchitektur wie dem IHE Cross-Enterprise Document Sharing (XDS) könnte der vorgestellte Ansatz für die Ablage von zu exportierenden Daten eines Gesundheitsdatenanbieters in einem Dokumentenrepository eingesetzt werden (siehe Abbildung 1), wobei die Daten in diesem Zuge vom spezifischen Datenformat des exportierenden HIS in das standardisierte Format der pren konvertiert werden.

2 Abbildung 1: Cross-Enterprise Document Sharing Architektur. Der in der vorliegenden Arbeit behandelte Bereich ist hervorgehoben. Im Folgenden bezeichnet der Terminus EHR-Extrakt eine gültige Instanz des pren Referenzmodells, welcher kein Archetyp zugrunde liegt. Als archetypenkonformes EHR-Extrakt wird ein EHR-Extrakt bezeichnet, welches zusätzlich die Vorgaben eines bestehenden Archetyps erfüllt. Ziel der Arbeit Ziel dieser Arbeit war es, die praktische Anwendbarkeit des Vorstandards pren und die Konzepte zum semantisch-interoperablen Austausch von medizinischer Information anhand einer praktischen Umsetzung zu analysieren. In der Literatur können nur wenige Referenzen auf pren Implementierungen gefunden werden. Pangea [6] ist eine Middleware, die es ermöglicht, Daten aus einem HIS zu exportieren und zu importieren, wofür eine eigene Schemasprache entwickelt wurde. Unser Ansatz basiert im Gegensatz dazu auf bestehenden XML-Technologien wie XML-Schema und der Extensible Stylesheet Language Transformation (XSLT), um existierende Tools und das Wissen, welches im Umgang mit XML-Technologien in den letzten Jahren gesammelt wurde, anwenden zu können. In [7] wird ein Dienst präsentiert, der es erlaubt, Daten von Patienten mit chronischen Herzerkrankungen, die sich nicht mehr im Krankenhaus befinden, für die Verlaufskontrolle und das Monitoring ans Krankenhaus zu schicken. Es wird dabei angenommen, dass die Daten bereits im HIS konform zu pren gespeichert werden. In unserer Arbeit wird im Gegensatz dazu von der häufiger vorliegenden Situation ausgegangen, dass die auszutauschenden Daten in einem HIS-spezifischen Datenformat gespeichert sind. Diese Daten sollen auf Basis eines existierenden, unabhängig entwickelten Archetyps konform zu pren exportiert werden. Systembeschreibung Wir unterteilen das Generieren von archetypenkonformen EHR-Extrakten in zwei Schritte (siehe Abbildung 2).

3 Abbildung 2: Generieren von archetypenkonformen EHR-Extrakten Im ersten Schritt werden die relevanten relationalen Daten aus dem System ArchiMed als pren konforme XML-Dokumente (EHR-Extrakte) publiziert. Dabei werden die ArchiMed- Objekte auf die Struktur des Referenzmodells abgebildet. Im zweiten Schritt werden die publizierten EHR-Extrakte in archetypenkonforme EHR-Extrakte transformiert. Archetypenkonforme EHR-Extrakte sind semantisch interoperabel und können ohne zusätzliches Wissen zwischen Informationssystemen ausgetauscht werden. Publizieren von relationalen Daten als EHR-Extrakte Zuerst extrahieren wir die relational gespeicherten medizinischen Daten als EHR-Extrakte ähnlich wie im OACIS-Projekt [8]. Um beliebige Daten, die mittels ArchiMed-Formularen gespeichert wurden, publizieren zu können, wurde eine generische Abbildung zwischen den strukturellen Komponenten der Formulare und den Klassen des Referenzmodells (siehe Tabelle 1) erstellt. Tabelle 1: Abbildung zwischen den Objekten des Systems ArchiMed und den Klassen des Referenzmodells ArchiMed Referenzmodell Formular COMPOSITION Formularblatt SECTION Tabelle CLUSTER Wert ELEMENT Auf Basis dieser Abbildung wurde eine PL/SQL-Prozedur [9] in ArchiMed s Oracle Datenbankengine entwickelt, die es erlaubt, alle Daten, die mittels Formularen eingegeben werden, als EHR-Extrakte zu publizieren. Die Formularstrukturen im System ArchiMed definieren die Struktur der resultierenden EHR-Extrakte, so wie Archetypen die Struktur von archetypenkonformen EHR-Extrakten beschreiben. Unsere PL/SQL-Prozedur verwendet die Structured Query Language (SQL) und die PL/SQL DOM API [10] in Kombination mit der Struktur des Referenzmodells. Das EAV-Design der Datenbank erleichtert die Implementierung des generischen Publizierens, da alle Werte in einer einzigen Tabelle gespeichert sind. Wird die ID eines Dokuments (Instanzen von Formularen werden als Dokumente bezeichnet) an die PL/SQL-Prozedur übergeben, so publiziert diese das Dokument als EHR-Extrakt. Um bereits exportierte EHR-Extrakte und einzelne RECORD COMPONENTs zu ihrem Ursprung in der Datenbank zurückverfolgen zu können, wurde jeder Tabelle des EAV-Designs im System ArchiMed ein eigener Object Identifier (OID) zugewiesen. Mit Hilfe der eindeutigen Schlüssel und der Versions-IDs von ArchiMed s Versionskontrolle wird der Instance Identifier (II) generiert, der in jeder RECORD COMPONENT (Attribut rc_id) benötigt wird.

4 Transformation von EHR-Extrakten in archetypenkonforme EHR-Extrakte Publizierte EHR-Extrakte werden im zweiten Schritt in archetypenkonforme EHR-Extrakte transformiert, wobei beide Extrakte als XML-Dokumente dargestellt werden. Bei der Transformation wird ein XML-Dokument, das durch ein XML-Schema A beschrieben wird, in ein XML-Dokument transformiert, welchem XML-Schema B zugrunde liegt. Die XSLT- Empfehlung des World Wide Web Consortium (W3C) wurde unter anderem für Transformationen dieser Art entwickelt. Für jeden Archetyp, auf dessen Basis Dokumente exportiert werden sollen, wird ein eigenes XSLT-Skript erstellt. Da das manuelle Erzeugen der XSLT-Skripts aufwendig ist, verwenden wir ein Werkzeug [11], das es ermöglicht, die den XML-Dokumenten zugrunde liegenden XML- Schemas visuell aufeinander abzubilden (siehe Abbildung 3). Auf Basis der visuellen Abbildung wird das benötigte XSLT-Skript, das EHR-Extrakte in archetypenkonforme EHR-Extrakte transformiert, automatisch generiert. Abbildung 3: Visuelle Generierung des XSLT-Skripts Die Beschreibung der Struktur eines archetypenkonformen EHR-Extrakts mittels XML- Schema wird durch letzterens unique particle attribution constraint verkompliziert [12]. Diese Regel schreibt vor, dass zwei XML-Elemente auf der gleichen hierarchischen Ebene innerhalb des Schemas nicht den gleichen Namen bei unterschiedlicher Substruktur haben können. Dies würde jedoch beispielsweise bei einem zum Archetyp Blutdruckmessung konformen EHR- Extrakt benötigt, das zwei ELEMENTs auf gleicher Ebene beinhaltet, wobei ein ELEMENT den systolischen Wert und das andere den diastolischen Wert darstellen soll. Wir umgehen dieses Problem, indem wir dem Referenzmodell virtuelle Subklassen, für alle semantischen Komponenten (also z.b. systolischer und diastolischer Blutdruck) die im Archetyp angegeben sind, hinzufügen. Diese Klassen sind insoferne virtuell, als sie nur innerhalb der XML-Schema-Repräsentation verwendet werden. Das fertige archetypenkonforme EHR-Extrakt instanziert dann nur mehr die originalen Klassen des Referenzmodells, genauer gesagt die Superklassen der virtuellen Subklassen.

5 Abbildung 4: Virtuell erweitertes Referenzmodell Der Name einer virtuellen Subklasse wird aus dem Namen ihrer Superklasse und dem Bezeichner der zugehörigen semantischen Komponente im Archetyp zusammengesetzt. Alle Attribute und Beziehungen werden wie gewohnt auf die virtuellen Subklassen vererbt. Ein Beispiel des für einen Archetyp Diabetesdaten virtuell erweiterten Referenzmodells ist in Abbildung 4 zu sehen. Die ursprünglichen Klassen des Referenzmodells sind in Grau dargestellt, die virtuellen Subklassen in Schwarz. Neben dem archetypenkonformen EHR-Extrakt basiert auch das im ersten Schritt erzeugte EHR-Extrakt auf einem virtuell erweiterten Referenzmodell, wobei in diesem Fall die semantischen Komponenten des ArchiMed-Formulars die Basis der virtuellen Subklassen bilden. Während das XML-Schema zur Beschreibung des archetypenkonformen EHR-Extrakts manuell erzeugt wird, kann das XML-Schema zur Beschreibung des EHR-Extrakts automatisch generiert werden. Beide XML-Schemas beinhalten alle obligatorischen Attribute des Referenzmodells (wie rc_id, name, etc.) sowie die im jeweiligen Archetyp oder im Formular vorgeschriebenen semantischen Komponenten und deren Attribute. Aus der visuellen Abbildung zwischen den beiden Schemas (siehe Abbildung 3) wird das XSLT-Skript generiert, welches auf die im ersten Schritt erzeugten EHR-Extrakte angewendet wird. Die im resultierenden, archetypenkonformen EHR-Extrakt noch enthaltenen virtuellen Subklassen werden durch Strippen der entsprechenden XML-Tags (z.b. ELEMENT_systolic ELEMENT) auf die ursprünglichen Klassen des Referenzmodells rückgeführt und so das endgültige archetypenkonforme EHR-Extrakt erzeugt.

6 Strukturen, die sich nicht im Formular wiederfinden, vom Archetyp jedoch für eine zusätzliche Strukturierung vorgegeben sind, können während des visuellen Mappings hinzugefügt werden. Falls die Daten über mehrere Formulare verteilt sind, werden sie in separaten COMPOSITIONs innerhalb desselben EHR-Extraktes publiziert. Das Auswählen der gewünschten Daten erfolgt ebenfalls während der XSLT-Skript-Erzeugung. Diskussion Der beschriebene Ansatz wurde mit Hilfe eines existierenden Archetyps für Diabetesdaten [13] getestet. Der Archetyp besteht aus sechs ENTRYs (Blutdruck, Labor-Glukose, Herz-Puls- Rate, Körpergewicht, Dimensionen und physische Aktivität) und wurde in der Archetype Definition Language (ADL) [1] spezifiziert. Das Konzept des beschriebenen, virtuell erweiterten Referenzmodells ermöglichte es, XML- Schema als Beschreibung für EHR-Extrakte zu verwenden. Dadurch konnte auf existierende Tools und den allgemeinen Erfahrungsschatz in der Anwendung von XML zurückgegriffen werden. Diesem Vorteil steht die Limitation von XML-Schema hinsichtlich der Spezifikation von Relationen zwischen einzelnen Werten eines XML-Dokuments gegenüber. So ist es mit XML- Schema z.b. nicht möglich, Werte, die zur Laufzeit eingegeben werden, miteinander zu vergleichen oder zu überprüfen, ob der systolische Blutdruck kleiner als der diastolische Blutdruck ist. In der ADL kann dies mittels so genannter invariants bewerkstelligt werden. Das XSLT-Skript könnte auch ohne das virtuell erweiterte Referenzmodell generiert werden, letzteres erlaubt es jedoch, das XSLT-Skript ohne Programmierkenntnisse zu erstellen. Das XML-Schema kombiniert die Information aus dem Referenzmodell und das Wissen aus den Archetypen in einem einzelnen Dokument, dies erleichtert die Interpretation eines EHR- Extraktes. Ausblick In dieser Arbeit wurde ein Ansatz präsentiert, mittels dem auf Basis von XML, XML-Schema, XSLT und DOM existierende Daten eines HIS als pren archetypenkonforme EHR- Extrakte publiziert werden können. In diesem Rahmen wurde eine Methode vorgestellt, die es ermöglicht unter Umgehung des unique particle attribution constraints EHR-Extrakte mittels XML-Schema zu beschreiben. Ein nächster, geplanter Schritt wird darin bestehen, den Import von pren konformen EHR-Extrakten zu implementieren.

7 Referenzen [1] CEN/TC 251 WG1 pren Health informatics - Electronic health record communication; 2006 [aufgerufen Oktober 2006]; [2] Beale T. Archetypes and the EHR, in: Blobel B, Pharow P, eds. Advanced Health Telematics and Telemedicine, IOS Press; 2003; pp [3] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems; 2002 [aufgerufen Oktober 2006]; [4] Dorda W, Wrba T, Duftschmid G, Sachs P, Gall W, Rehnelt C, et al. ArchiMed: A Medical Information- and Retrieval System. Methods Inf Med; 1999; 38(1): pp [5] Friedman C, Hripcsak G, Johnson S, Cimino J, Clayton P. A generalized relational schema for an integrated clinical patient database, in: Miller RA, ed. Proceedings of the Annual Symposium on Computer Application in Medical Care; November 1990: Washington, DC: IEEE Computer Society Press; 1990; pp [6] Maldonado Segura JA. Historia Clinica Electronica Federada Basada en la Norma Europea CEN/TC251 EN13606: Dissertation, Universidad Politecnica de Valencia; [7] Munoz A et al. Proof-of-Concept Design and Development of an EN13606-based Electronic Healthcare Record Service. J Am Med Inform Assoc; 2007; 14(1): pp [8] DSTC - Flinders University et al. Final Report: The OACIS-GEHR Transformation Process; [9] Russell J. Oracle9 i, PL/SQL, User s Guide and Reference, Release 2 (9.2), Oracle Corporation; [10] Leyderman R. Oracle9 i, XML API Reference XDK and Oracle XML DB, Release 2 (9.2), Oracle Corporation; [11] Altova GmbH, Mapforce 2007 Enterprise Edition; [12] Tun Z, Bird LJ, Goodchild A. Validating Electronic Health Records Using Archetypes and XML. CRC for Enterprise Distributed Systems: University of Queensland; [13] Prochazkova D. Architekturen der elektronischen, lebensbegleitenden Gesundheitsakte: Ein Vergleich der Archetypansätze von CEN und HL7 am Beispiel des Konzeptes "Diabetes": Diplomarbeit, Medizinische Universität Wien; 2006.