openEHR - Peter L. Reichertz Institut für Medizinische Informatik ...

Fachbeiträge
openEHR
openEHR – Die Geschichte eines
Baukastensystems für eine gemeinsame
Elektronische Gesundheitsakte
Dipl.-Inform.
Joachim Bergmann
Technische Universität
Braunschweig
Institut für Medizinische
Informatik
Mühlenpfordtstr. 23
D-38106 Braunschweig
Tel.: +49(0)531/391-9506
Fax: +49(0)531/391-
9502
E-Mail:
J.Bergmann@
mi.tu-bs.de
http://www.mi.tu-bs.de
Aufgrund einer zunehmend besseren technischen
Infrastruktur bieten sich für die Rechnerunterstützung
der Kooperation von Ärzten und anderen
Leistungserbringern in der Patientenversorgung immer
mehr sinnvolle Szenarien an. Die gemeinsame Elektronische
Gesundheitsakte ist ein zentrales Werkzeug, um allen
an der Versorgung Beteiligten den Zugriff auf notwendige
Informationen zum Patienten zu ermöglichen. Allerdings
wirft die einrichtungs- und fachbereichsübergreifende
elektronische Repräsentation und Kommunikation
medizinischer Begriffe viele Fragen auf. Der vorliegende
Artikel stellt den openEHR-Ansatz vor, der Beiträge zu
diesem Gebiet geleistet und den korrespondierenden europäischen
Standard maßgeblich beeinflusst hat. Die Darstellung
von Geschichte, Architektur und Potenzial des
openEHR-Ansatzes stützt sich auf die online verfügbare
openEHR-Dokumentation [1] sowie Publikationen zu Projekten
und Studien.
Eine gemeinsame elektronische
Gesundheitsakte erfordert ein
gemeinsames Begriffssystem
Für eine effiziente und qualitativ hochwertige Patientenversorgung
ist eine aktuelle und vollständige Dokumentation
zum Patienten von großer Bedeutung. Aufgrund
der sehr arbeitsteiligen Organisation der Gesundheitsversorgung
sind jedoch Informationsdefizite ein häufiges
und zentrales Problem. Mit neuen Versorgungsmodellen
wie Integrated Care oder Shared Care soll eine bessere
Kooperation bei der Behandlung erreicht werden,
jedoch ist hierzu der einrichtungsübergreifende Zugriff
auf medizinische Dokumentation zum Patienten wichtig.
In Anlehnung an den Begriff des Shared Care kann diese
Form der Dokumentation als Shared EHR (Shared Electronic
Health Record) bezeichnet werden [2]. Bei der
Patientenversorgung werden zwar auch zukünftig die
eigenen Aufzeichnungen einer Einrichtung die primäre
Informationsquelle sein, aber mit einer zunehmenden
Bereitstellung relevanter Informationen zum Patienten
durch andere Einrichtungen wird die Bedeutung des
Shared EHR als sekundäre Informationsquelle wachsen
[2]. Zukunftsvision ist ein Virtual EHR, der vor dem Nutzer
vollständig verbirgt, welche Teile der präsentierten
Patientendaten aus der eigenen Datenbank vor Ort stammen
und welche von entfernten Quellen anderer Einrichtungen
abgerufen werden.
Die Verarbeitung medizinischer Daten erfolgt im Kontext
des Wissens, das sich in den Köpfen der Mediziner,
in ihren Aufzeichnungen, in Forschung, Literatur etc. manifestiert.
Eine Abbildung dieses Wissens in ein Computersystem
gehört zu den intensiv beforschten Gebieten der
Medizinischen Informatik und Künstlichen Intelligenz und
ist als ein eher ungelöstes Problem anzusehen, obgleich
viele erfolgreiche Ergebnisse vorliegen (z.B. GALEN [3],
OWL [4], SKIF [5,6]). Innerhalb einer Abteilung oder einer
Einrichtung funktioniert die medizinische Dokumentation
normalerweise gut, da ein lokaler Konsens bzgl. der verwendeten
Datenstrukturen und deren Interpretation vorliegt.
Sobald medizinische Daten über die Fachabteilung
hinaus möglicherweise fachbereichsübergreifend und vielleicht
sogar länderübergreifend auszutauschen sind, wird
das zugrunde liegende Begriffssystem sehr bedeutsam.
Es ist sicherzustellen, dass die Interpretation einer Nachricht
durch den Empfänger in dessen Kontext zur
gewünschten Information führt. Daraus lassen sich leicht
Eigenschaften für einen Shared EHR folgern:
˜ Neben den Nutzdaten müssen die zu ihrer Darstellung
verwendete Symbolik und die Bedeutung dieser
Symbolik elektronisch kommunizierbar sein.
Diese nahe liegende Forderung stellt ein großes
Problem dar.
˜ Die Terminologie des Begriffssystems und auch das
Begriffssystem selbst wandeln sich im Laufe der
Zeit, z.B. durch neue Erkenntnisse der medizinischen
Forschung. Die elektronische Repräsentation
des Begriffssystems muss also anpassbar sein.
˜ Das Wissen über das Begriffssystem liegt bei den
Spezialisten des Fachgebiets vor und sollte also
durch diese wartbar sein. Eine Erweiterung oder
Anpassung der verwendeten Symbolik und die Formulierung
ihrer Bedeutung müssen daher ohne
Änderung der Programme möglich sein.
Die existierenden EHR-Implementierungen können
hinsichtlich der Art, wie eine »Bindung zwischen Datenstruktur
und Begriff« erfolgt, drei Klassen zugeordnet
8 Forum der Medizin_Dokumentation und Medizin_Informatik 1/2005

Fachbeiträge
openEHR
werden [2]. Abbildung 1 illustriert die jeweils resultierende
Datenstruktur am Beispiel.
˜ Unstrukturierte Daten: Der EHR ist eine Sammlung
unstrukturierter oder nicht einheitlich strukturierter
Datencontainer (Blackbox), deren Interpretation
davon abhängt, dass der jeweilige Nutzer mit
den zur Niederschrift verwendeten Konventionen
vertraut ist und dem proprietär kodierten Inhalt
Bedeutung zumessen kann.
˜ Gesamtmodell-Ansatz: Alle verwendbaren
Begriffe, Konzepte und Strukturelemente eines EHR
sind in einem einzigen Klassenmodell definiert und
allen nutzenden Parteien bekannt. Ein solches
Modell kann bereits für kleine Begriffssysteme sehr
groß und damit unhandlich sein. Darüber hinaus
muss das Modell bereits zum Zeitpunkt der Entwicklung
eines rechnergestützten Informationssystems
berücksichtigt und in die Software implementiert
werden, so dass eine spätere Änderung oder
Erweiterung des Modells zu Änderungen an der
Software führen muss.
˜ Instanziierung eines generischen Modells: Ein
generisches Modell definiert nur wenige allgemein
gültige Objektklassen, deren Instanzen sich zu allen
notwendigen Objektmodellen kombinieren lassen.
Je abstrakter das generische Modell bleibt, desto
allgemein gültiger ist es und desto geringer wird
die Wahrscheinlichkeit der Notwendigkeit einer
späteren Änderung. Allerdings steigt mit der
Abstraktion auch der Interpretationsspielraum
bezüglich der in einem Modell enthaltenen Elemente,
wobei im Extremfall der Abstraktion die
bereits vorgestellten unstrukturierten Datencontainer
vorlägen.
Mit der als »openEHR« [7] durch die openEHR Foundation
publizierten Architektur wird der beschriebene
generische Modellansatz um zusätzliche, außerhalb des
Modells formulierte Strukturen zur Definition eines
Begriffssystems erweitert. Dieser Ansatz ist nicht neu,
aufgrund seiner zumindest konzeptuellen Einfachheit
aber bewiesenermaßen realisierbar und nicht zuletzt durch
die Aufmerksamkeit, die ihm aktuell geschenkt wird, relevant.
openEHR realisiert flexible, aber
eindeutig definierte Begriffssysteme
Ziel des openEHR-Ansatzes ist die Entwicklung rechnerbasierter
Informationssysteme, die Informationen korrespondierend
zu einem Begriffssystem speichern können,
ohne dass die Struktur des Begriffssystems fest in
den Programmen kodiert werden muss. Dadurch sollen
die Fachbenutzer vor Ort in der Lage sein, zur Laufzeit
das den verarbeiteten Daten zugrunde liegende Begriffssystem
anpassen zu können. Darüber hinaus müssen die
gespeicherten Informationen einrichtungsübergreifend
kommunizierbar sein. Um dies zu erreichen, ist das grundlegende
Prinzip des openEHR-Ansatzes eine als Trennung
von »Wissen« und »Information« bezeichnete Architektur
[7], die auf den im Folgenden beschriebenen Konzepten
Referenzmodell und Archetyp basiert.
Das Referenzmodell legt den Raum möglicher Objektmodelle
fest, indem verwendbare Objektklassen und deren
Beziehungen zueinander definiert werden. Dadurch werden
im Sinne einer »harten« Definition sowohl der Aufbau
eines jeden Objekts, insbesondere Objektname, Eigenschaften
und Funktionen festgelegt als auch die Kombinationsmöglichkeiten
mit anderen Objekten durch Beziehungstyp,
Multiplizität etc. beschrieben. In diesem schlank
gehaltenen Referenzmodell sind ausdrücklich nur solche
Objektklassen enthalten, die übergreifend gültig sind und
kein fachspezifisches Wissen darstellen, wie z.B. Data-
Value als Container für Informationen oder das Strukturelement
ItemList zur Zusammenfassung von Elementen
Abbildung 1:
Abbildung des Begriffs
Blutdruck auf
Datenstrukturen in
verschiedener Form [2]:
a) Unstrukturierte Daten
b) Gesamtmodell-Ansatz
c) Generisches Modell
Abbildung 2:
Übersicht über die
openEHR-Architektur
Forum der Medizin_Dokumentation und Medizin_Informatik 1/2005
9

Fachbeiträge
openEHR
eine Interessengemeinschaft internationaler Fachleute
weitergeführt werden. Ziel ist es, durch öffentliche, aber
zugleich konsolidierte Aktivitäten den openEHR-Ansatz
gemeinschaftlich auszufeilen und durch OpenSource-Software
allgemein nutzbar zu machen. Ein Online-Repository
ermöglicht Zugriff auf den jeweils aktuellen Stand
von Architektur, Spezifikationsdokumenten und Software,
während Forum und E-Mail-Listen intensiv zur konstruktiven
Diskussion genutzt werden. Aufgrund des (unbezahlten)
Engagements der Beteiligten wurde der Ansatz
in verschiedenen Projekten erprobt und hat wesentlichen
Einfluss auf europäische Standardisierungsaktivitäten
sowie die Planung der Gesundheitstelematikplattform in
Australien.
Abbildung 3:
Screenshot der ADL
Workbench
zu einer Liste. Durch Instanziierung der Klassen des Referenzmodells,
also durch Erstellen konkreter Objekte, Füllen
mit Daten und Verknüpfen von Objekten untereinander,
wird Information kodiert. Nur eine kleine Anzahl der
nach dem Referenzmodell erstellbaren Objektmodelle
ergibt jedoch im klinischen Kontext einen Sinn. Daher
wird mit Hilfe von Archetypen (Urbilder, Grundmuster) in
Form einer »weichen« Definition beschrieben, welche
Objektinhalte und -kombinationen sinnvoll sind. Ein Archetyp
ist eine Menge von Regeln, die für bestimmte Objekte
den Wertebereich ihrer Attribute einschränken und
erlaubte Beziehungen zu anderen Objekten definieren.
Abbildung 2 stellt das Verhältnis zwischen Referenzmodell,
Archetyp und Information grafisch dar.
Für die Beschreibung der Archetypen ist mit der Archetype
Definition Language ADL eine Sprache definiert.
Alternativ können Archetypen als Instanzmodell des Archetype
Object Model AOM dargestellt werden, indem
erlaubte Objektkombinationen modelliert werden, ohne
die Attribute mit Werten zu füllen oder Objektbeziehungen
darzustellen. ADL und AOM sind hinsichtlich ihrer
Mächtigkeit äquivalent.
openEHR im Detail
Mit der Gründung der openEHR Foundation im Jahre
2000 sollten die Forschungsaktivitäten zur Architektur
elektronischer Gesundheitsakten im Umfeld des britischen
Centre for Health Informatics and Multiprofessional Education
(CHIME) am Londoner University College durch
Die bisherigen openEHR-Aktivitäten lassen sich entsprechend
der Organisation des Projekts folgenden Bereichen
zuordnen:
˜ Anforderungsermittlung: Basierend auf den Erfahrungen
aus dem openEHR-Vorläuferprojekt GEHR (s.u.)
sollen Anforderungen an einen verteilten offenen
Standard für elektronische Gesundheitsakten untersucht
und definiert werden. Anhand der online verfügbaren
openEHR-Dokumentation ist zu erkennen,
dass in diesem Arbeitsbereich zuletzt wenig Aktivität
stattgefunden hat.
˜ Spezifikation der Architektur: Im Rahmen dieses
Arbeitsbereichs wird die openEHR-Architektur spezifiziert.
Die Architektur umfasst ein Referenzmodell,
eine Sprache und ein Objektmodell zur Beschreibung
von Archetypen sowie ein System modellierter und
anerkannter Archetypen selbst. Zu jedem Bestandteil
der Architektur liegt ein ausführliches, beschreibendes
Dokument vor. Jüngste Aktivitäten beschäftigen
sich vor allem mit der Spezifikation der Archetype
Definition Language. Der jeweils aktuelle genehmigte
Zustand des Referenzmodells ist auf den openEHR-
Webseiten in Form eines automatisch generierten
HTML-Exports aus der Programmiersprache Eiffel einzusehen.
˜ Realisierung der abstrakten Architekturspezifikationen:
Zur produktiven Nutzung der openEHR-
Konzepte sollen für verschiedene Programmiersprachen
die abstrakten Spezifikationen zu so genannten
Implementation Technology Specifications (ITS)
konkretisiert werden, wie z.B. für Java, XML-Schema,
IDL und Python.
˜ Implementierung: Die bei der Durchführung von Studien
und Pilotprojekten entstehenden Programme und
Werkzeuge werden auf OpenSource-Basis zur Verfügung
gestellt, wie z.B. Programmierschnittstellen für
Java und .NET sowie einige Tools. Die ADL Workbench
10 Forum der Medizin_Dokumentation und Medizin_Informatik 1/2005

Fachbeiträge
openEHR
(siehe Abbildung 3) dient der Exploration vorhandener
Archetyp-Definitionen und unterstützt den Entwickler
durch den Referenz-Parser bei Fehlersuche und Format-Konvertierung.
Ein in ADL vorliegender, geparster
Archetyp kann in XML-, OWL- oder HTML-Form
ausgegeben werden. Der Archetype Editor richtet sich
an die Spezialisten des Fachgebiets und ermöglicht
die Erstellung und Bearbeitung von Archetypen zur
Realisierung einer Terminologie. Das Programm ist
allerdings nicht ganz einfach zu bedienen.
Darüber hinaus ist mit den Werkzeugen eine kleine
Bibliothek von Archetypen verfügbar. Das jüngste Paket
enthält bereits 44 modellierte klinische Konzepte, wie
z.B. Anamnese, Medikation, Pathologiebefund, Schilddrüsen-Laboranalytik
etc.
Referenzmodell
Das openEHR-Referenzmodell stellt eine Weiterentwicklung
des GEHR Object Model GOM dar und befindet
sich in fortlaufender Überarbeitung. Auffallender Unterschied
zum GOM ist die Migration vom Konzept der Transaction
zu Composition zugunsten einer Konformität mit
dem ENV 13606. Hintergrund ist der Wunsch, mit einem
Objekt sowohl transaktionsorientierte Ereignisse als auch
feststehende (longitudinale) Fakten kodieren zu können.
Abbildung 4 zeigt eine Grafik aus der openEHR-Architektur-Spezifikation.
Abgebildet ist mit den Teilmodellen EHR
und Composition der zentrale Part des openEHR-Referenzmodells,
das Reference Information Model, zum besseren
Verständnis ergänzt durch verknüpfte Teilmodelle.
Grundsätzlich werden Datenobjekte (Text, Messwert
etc.) aus dem Teilmodell Data Types unter Verwendung
der Strukturelemente aus dem Teilmodell Data Structures
zu »speicherbaren« Informationseinheiten kombiniert
und fachlich einer Ordnung durch Elemente aus Composition
unterzogen. Welche Kombinationen von Objekten
erlaubt sind, beschreibt ein in ADL oder durch AOM-Klassen
formulierter Archetyp. Die Informationseinheiten werden
durch Gruppierungselemente aus dem Teilmodell EHR
zu einer Gesundheitsakte arrangiert, wobei durch den
zwischengeschalteten Container Versioned Composition
die Verwaltung versionierter Informationseinheiten ermöglicht
wird. Zentrale Teilmodelle des Referenzmodells werden
im Folgenden beschrieben.
EHR Enthält die aggregierenden Strukturen zur Repräsentation
einer openEHR-Gesundheitsakte. Dieses Teilmodell
stellt zusammen mit dem Teilmodell Composition
das EHR Information Model dar. Insbesondere werden in
diesem Modellteil die Folder definiert, um die Informationseinheiten
einer Gesundheitsakte zu gliedern und die
Navigation zu ermöglichen. Eine übliche, bereits im GEHR-
Projekt formulierte Gliederung ist die Zuordnung von
Informationen zu folgenden Ordnern:
˜ Persönliche Daten (Name, Geburtsort, Adresse etc.)
˜ Persistente Daten (Diagnosen, Dauermedikation,
Familienanamnese etc.)
˜ Ereignisse
˜ Episoden
Die Ordner Ereignisse und Episoden stellen dabei keine
disjunkten Mengen dar. Ein Beispiel einer Ordnerstruktur
zeigt die Abbildung 5.
Composition Das Paket definiert die zur Speicherung
von Informationseinheiten erforderlichen Strukturelemente.
Eine Composition ist Bestandteil eines EHR und
stellt die Instanziierung eines Archetypen und damit dessen
Ausprägung zu einer konkreten Informationseinheit
dar. Eine Composition enthält Sections zur logischen Gruppierung,
die weitere Sections oder zur fachlichen Zuordnung
Entrys enthalten können. Dabei werden im Kontext
dieses Teilmodells nur fachliche Aussagen getroffen, während
die Komposition komplexer Datenstrukturen im Teilmodell
Data Structures erfolgt. Composition, Section und
Entry können die Wurzeln eines Archetypen sein und werden
daher als »archetypable« bezeichnet. Beispiel: Der
Archetyp blood pressure measurement ist vom Typ Observation
und damit Unterklasse von Entry.
Data Structures Enthält Strukturen zur Definition
komplexer Datenstrukturen wie z.B. Liste und Tabelle. Ein
Zeit-Konzept (History) ermöglicht die Verknüpfung von
Datenstrukturen mit Ereignissen auf der Zeitachse. Auch
Datenstrukturen sind »archetypable«. Beispiel: Im Arche-
Abbildung 4:
openEHR Reference
Information Model
(Teilmodelle EHR und
Composition) sowie
verknüpfte Teilmodelle.
Forum der Medizin_Dokumentation und Medizin_Informatik 1/2005
11

Fachbeiträge
openEHR
als ADL-Sprachkonstrukt oder als Instanz des AOM vorliegen.
ADL und AOM sind hinsichtlich ihrer Ausdrucksstärke
äquivalent zueinander.
ADL ist in zwei weitere Sprachen dADL sowie cADL für
unterschiedliche Anwendungsfälle aufgeteilt und verbindet
deren Ausdrücke zu einer kompakten Archetypbeschreibung.
Die Sprache dADL dient der Definition einer
konkreten Objektinstanz, während in cADL Regeln bzgl.
Typ und Attributen einer Objektinstanz formuliert werden.
ADL und damit implizit auch eine Instanz des AOM
beschreiben einen Archetyp in den vier Abschnitten Identifikation,
Beschreibung, Definition und Ontologie.
Identifikation Jeder Archetyp wird durch einen
Identifikator eindeutig bestimmt und ggf. von einem
anderen Archetypen abgeleitet. Folgendes Statement
stellt eine eindeutige Benennung des Archetypen blood
pressure dar.
archetype (adl_version=1.2)
openEHR-EHR-OBSERVATION.blood_pressure.v1
Abbildung 5:
Beispiel für eine
Ordnerstruktur, die
durch Objekte aus dem
EHR-Teilmodell realisiert
werden kann.
Die dunkelgrauen
Rechtecke stellen
Instanzen der
Referenzmodell-Klasse
Folder dar und dienen
der nicht notwendigerweise
disjunkten
Einordnung von
Informationseinheiten.
typ blood pressure measurement ist das Messergebnis
blood pressure einem Ereignis (dem Messvorgang baseline
reading) untergeordnet. Aber auch das Messergebnis
selbst ist ein eigenständiger Archetyp.
Data Types Beschreibt grundlegende »fortgeschrittene«
Datentypen wie (kodierbarer) Text, allgemeine Messgröße,
Datum etc. Die verschiedenen Messgrößen sind
detailliert modelliert (z.B. dimensionslose Größe, Wert
mit Maßeinheit, Intervall, Verhältnis etc.). Beispiel: Der
systolische Blutdruck ist eine einfache Messgröße bestehend
aus Messwert und Maßeinheit.
EHR Extract Beschreibt zum EHR-Teilmodell korrespondierende
Klassen, um ein Teilsystem eines EHR zu
einem »Extrakt« zu isolieren und beispielsweise im Rahmen
eines Kommunikationsvorgangs zu versenden.
Archetype Definition Language
und Archetypobjektmodell
Die als openEHR-Spezifikation vorliegende Archetype
Definition Language ADL ist eine formale Sprache zur
Beschreibung von Archetypen. Sie legt fest, wie Klassen
des Referenzmodells zu einem fachlichen Begriff kombiniert
werden müssen und welche elementaren Daten sie
enthalten dürfen. Für jeden Archetyp wird ein ADL-Konstrukt
in Textform angegeben, das analog zu XML/DOM
auch als hierarchische Objektstruktur interpretiert werden
kann. Diese Objektstruktur stellt eine Instanziierung
des Archetypobjektmodells AOM dar, welches ebenfalls als
Spezifikationsdokument vorliegt. Ein Archetyp kann somit
Eine Verbindung des Archetypen mit einem Begriff
wird durch das Concept-Statement hergestellt. Im folgenden
Beispiel wird dazu mit der lokalen Referenz
at0000 auf einen Eintrag im Ontologie-Abschnitt (s.u.)
verwiesen.
concept
[at0000] -- blood pressure
Beschreibung Dieser Abschnitt enthält die Meta-
Daten eines Archetypen und umfasst Details zu Zweck,
Anwendungsgebiet und Ersteller des Archetypen sowie
Informationen zum Revisionsverfahren im Rahmen der
Aufnahme in eine global verfügbare Archetyp-Bibliothek.
Die Beschreibungsdetails können in verschiedenen Sprachen
enthalten sein. Die Beschreibung wird in dADL
kodiert:
description
original_author =
description("de") = <
purpose =
[...]
Definition In Form von Einschränkungsregeln (constraints)
werden erlaubte Objektstrukturen formuliert. Dazu
wird für einen Archetypen im Detail festgelegt, welche
Klassen des Referenzmodells instanziiert werden, wie sie
hierarchisch gruppiert sind und welche Attributwerte bzw.
Assoziationen erlaubt sind. Für jede Instanziierung einer
Referenzmodellklasse muss eine eigene Einschränkungsregel
angegeben werden.
12 Forum der Medizin_Dokumentation und Medizin_Informatik 1/2005

Fachbeiträge
openEHR
Der Definitionsabschnitt wird in der Sprache cADL verfasst.
Das folgende Beispiel zeigt einen Ausdruck für den
diastolischen Blutdruck.
ELEMENT[at00005] matches { -- diastolic blood pressure
value matches {
QUANTITY matches {
magnitude matches {0..1000}
property matches {"pressure"}
units matches {"mm[Hg]"}
}
}
}
Der Ausdruck legt unter Verwendung einer lokal gültigen
ID (archetype term) fest, dass zur Erstellung einer Informationseinheit
für den diastolischen Blutdruck die Klasse
Element aus dem Referenzmodell instanziiert werden
muss und die Assoziation value auf eine weitere Instanz
vom Typ Quantity zeigen muss, für die Einschränkungen
bzgl. der Attribute definiert sind.
Ontologie Der Ontologie-Abschnitt fügt der Objektstruktur
des Archetypen eine Semantik hinzu. Dazu können
für verschiedene Sprachen textuelle Beschreibungen
des Archetypen und der einzelnen Informationseinheiten
hinterlegt werden (term definition) und Verknüpfungen
zu einer Terminologie hergestellt werden (term binding).
Ein in dADL kodiertes Beispiel sieht wie folgt aus:
term_definitions("en") = <
items("at0005") = <
text =
description =
>
>
term_binding("SNOMED-CT") = <
items("at0005") =
>
Der Ontologie-Abschnitt stellt keine Definition einer Ontologie
dar. Vielmehr erfolgt hier die Verknüpfung mit einer
Ontologie (oder mehreren).
Templates
Archetypen beschreiben die Struktur von Informationseinheiten
zur Darstellung von Begriffen im Informationssystem,
nicht jedoch deren Repräsentation oder Nutzungskontext.
Zur Laufzeit ist es aber erforderlich, Archetypen
zu kombinieren, um sie z.B. dem Nutzer in einem Bildschirmformular
zu präsentieren, Archetypen bei der Erzeugung
mit Default-Werten zu versehen oder Archetypen je
nach Anwendungssituation weiter einzuschränken. Dazu
sieht openEHR das Konzept der Templates vor, die zukünftig
mit Hilfe der Sprache tADL beschrieben werden sollen.
Einrichtungen und Beteiligte der openEHR-Initiative
CHIME/UCL
Das Centre for Health Informatics and Multiprofessional
Education am University College London war
federführend im GEHR-Projekt und hat die open-
EHR-Initiative begründet. Sehr aktive Beteiligte
sind David Lloyd (Koordinator des GEHR-Projekts),
Dr. Dipak Kalra und Prof. David Ingram.
http://www.chime.ucl.ac.uk/
Ocean Informatics
Die australische Firma Ocean Informatics entstand
im Rahmen der openEHR-Gründung und möchte
die Konzepte dieses Ansatzes und die OpenSource-
Software kommerziell einsetzen. Bekannt als open-
EHR-Mitbegründer sind Dr. Peter Schloeffel,
Dr. Sam Heard und Thomas Beale.
http://www.oceaninformatics.biz/
DSTC
Das Distributed Systems Technology Centre ist ein
australisches Joint Venture aus Industrie, Regierung
und Forschungseinrichtungen zur Erforschung und
Entwicklung sicherer verteilter Systeme. Langjährig
Erläuterung von Begriffen im openEHR-Kontext
Eine Entität ist ein in der realen Welt eindeutig
identifizierbares Objekt, das entweder materiell
existiert, wie z.B. ein Messgerät, oder ein immaterielles
Konzept darstellt, wie z.B. eine Krankheit. In
der Regel ist eine Klasse hinsichtlich bestimmter
Eigenschaften gleicher Objekte gemeint (z.B. Person)
und nicht eine spezielle
Ausprägung/Instanz dieser Klasse
(z.B. »Herr Meier«).
Begriff meint das gedankliche Konzept eines
möglicherweise komplexen Sachverhalts. Das DIN
definiert Begriff als Denkeinheit, die aus einer
Menge von Gegenständen unter Ermittlung der
diesen Gegenständen gemeinsamen Eigenschaften
mittels Abstraktion gebildet wird. Ein Bezeichner
ist die Repräsentation des Begriffs in einer
Sprache.
Ein Referenzmodell ist ein Modell, das als
idealtypisch für die Klasse der zu modellierenden
Sachverhalte betrachtet werden kann. Im openEHR-
Ansatz beschreibt das Referenzmodell Bausteine,
die instanziiert, mit Daten gefüllt und zu den
eigentlichen Informationseinheiten zusammengesetzt
werden können.
Archetyp bedeutet Urform oder Musterbild und
meint hier die Beschreibung des Aufbaus einer
Informationseinheit. Ein Archetyp legt fest, wie
Objekte des Referenzmodells zur Darstellung eines
Begriffs im Computersystem miteinander kombiniert
und welche Werte darin gespeichert werden
dürfen. Ein Archetyp ist unabhängig von Terminologie
und Sprache, da er den Begriff, das gedankliche
Konzept, repräsentiert. Im Ontologieabschnitt einer
aktiv im openEHR-Projekt sind Dr. Linda Bird und
Dr. Andrew Goodchild.
http://www.dstc.edu.au/
openEHR Foundation
Die openEHR Foundation wurde zur Weiterentwicklung
der GEHR- und CEN EN 13606-Konzepte im
Jahre 2000 gegründet und sieht ihre Arbeit als
unabhängig und nichtkommerziell orientiert. Die
Gründungsmitglieder sind Prof. David Ingram,
Dr. Peter Schloeffel, Dr. Sam Heard, Dr. Dipak Kalra,
David Lloyd und Thomas Beale. Ein Architecture
Review Board unter der Leitung von Thomas Beale
und mit Mitgliedern der Universitäten Aalborg und
Tromsø, der Firma Ocean Informatics, dem CHIME
sowie dem autralischen Department of Health and
Ageing wacht über die openEHR-Architektur.
http://www.openehr.org/
Über die genannten Einrichtungen hinaus haben
viele weitere Beteiligte zur openEHR-Architektur,
der Software und der Archetypen-Bibliothek
beigetragen.
Archetyp-Definition sind Hinweise enthalten, die es
im idealen Fall jedem Nutzer auf der Welt ermöglichen
sollen, mit dem Archetypen einen Begriff zu
verbinden. So könnte ein Archetyp für den Begriff
Blutdruck dort Übersetzungen in verschiedene
Sprachen (z.B. blood pressure, pression artérielle,
pressão arterial) und Codes von Terminologiesystemen
(z.B. MeSH: G09.330.553.400.114) enthalten.
In openEHR werden Archetypen in der
Sprache ADL verfasst.
Eine Terminologie ist die Gesamtheit der in
einem Fachgebiet üblichen Fachwörter und -ausdrücke.
Sie umfasst also eine Menge von Bezeichnern,
mit denen man etwas benennen kann.
Eine Ontologie ist ein formal definiertes System
von Entitäten (Dingen, Konzepten) und ihren
Beziehungen zueinander. Sie beschreibt also, wie
etwas ist.
Mit Semantik ist hier die Bedeutung einer vorliegenden
Dateneinheit für einen Betrachter
gemeint. Kann der Betrachter mit den Zeichenfolgen
der Dateneinheit einen Begriff verbinden, so
haben sie für ihn eine Bedeutung.
Eiffel ist eine objektorientierte Programmiersprache,
die um 1985 entstanden ist. Sie realisiert
fortgeschrittene Merkmale des objektorientierten
Paradigmas wie z.B. multiple Vererbung. Als Erfinder
des »Design by contract«-Prinzips gilt Eiffel als
Entwicklungsmethode für saubere und stabile Software
und wird von den openEHR-Entwicklern für
die Implementierung des Referenzmodells
geschätzt.
Forum der Medizin_Dokumentation und Medizin_Informatik 1/2005
13

Fachbeiträge
openEHR
Ausgewählte
openEHR-Projekte
Archetyp-System
Für den institutionsübergreifenden Informationsaustausch
muss der jeweilige Empfänger eines Datenpakets
(z.B. eines EHR Extracts, siehe Referenzmodell) diese
Daten interpretieren und daher die verwendeten Begriffsstrukturen
kennen. openEHR sieht in Form des Archetype-
Systems den Aufbau einer gemeinsam genutzten und
gemeinsam erweiterbaren globalen Bibliothek von Archetypen
vor, indem Geschäftsprozesse und Schnittstellen
für dieses System spezifiziert werden. Im Authoring Network
wird der Erstellungs- und Revisionsprozess für Archetypen
festgelegt, während im Dissemination Network die
gemeinsame Nutzung dieser Bibliothek beschrieben ist.
Von GEHR über openEHR
zum europäischen Standard
Die openEHR zugrunde liegenden Konzepte wurden im
europäisch geförderten Projekt GEHR (Good European
Health Record, 1992–1995) entwickelt und realisieren
im Wesentlichen den bereits beschriebenen Ansatz des
generischen Modells eines EHR. Im so genannten GEHR
Object Model GOM wird die Gesundheitsakte als eine
Menge erbrachter Leistungen (Transactions) angesehen,
zu jeder Leistung wiederum eine Menge von Ergebnissen
(Observations) gehörend. Die Resultate dieses Projekts
flossen zu einem großen Teil in den europäischen Standard
ENV 12265 Electronic Healthcare Record Architecture
(1995) und damit auch in die Nachfolgerversion ENV
13606 (1999) ein, dort bereits ergänzt um ein Begriffssystem
zum Füllen der generischen Datencontainer. Die
Spezifikation des CEN-Standards wurde begleitet durch
die EHCR-SupA (Electronic Healthcare Record Support
Action, ca. 1997–2000) unter Federführung des CHIME
(Centre for Health Informatics and Multiprofessional Education)
am University College London.
Der ENV 12265 und damit die GEHR-Architektur wurden
in den Synapses/SynEx-Projekten (1996–2000) verwendet,
um klinische Datenbanken zu einem verteilten
System zu vernetzen. GEHR fand auch außerhalb Europas
Interesse und wurde zur Fortführung dieser Arbeiten
insbesondere in Australien in Good Electronic Health
Record umbenannt (1998–2001). Der originale GEHR-
Ansatz eines generischen Modells wurde in Anlehnung
an den ENV 13606 um ein ausgefeiltes Archetypen-Modell
ergänzt und das Referenzmodell in verschiedenen Iterationen
überarbeitet. Das resultierende Konzept stellt eine
Verschmelzung von GEHR, Synapses/SynEx und Teilen des
ENV 13606 von 1999 dar. Die im Jahre 2000 durch Initiative
des CHIME gegründete openEHR Foundation propagiert
dieses Konzept als Open-Source-Ansatz für elektronische
Gesundheitsakten unter dem Namen openEHR.
Der Ansatz hat nicht zuletzt durch das Engagement der
Beteiligten großen Einfluss auf den in Abstimmung befindlichen
neuen CEN-Standard prEN 13606 ausgeübt, der
seit 2001 durch die unter wesentlicher Beteiligung ehemaliger
GEHR-Mitglieder im CEN TC/251 gebildete Task
Force EHRcom fortgeschrieben wird. Im 2nd Working Draft
wird der bisherige Teil 1 Extended Architecture durch
einen überarbeiteten Teil 1 Reference Model ersetzt und
ein neuer Teil 2 Archetype Interchange Specification für
die Archetype Language und das Archetype Model hinzugefügt.
Diskussion
Die openEHR-Architektur ermöglicht es, klinische
Informationen einrichtungsübergreifend austauschbar
zu machen. Ein allen Nutzern zugängliches (und lokal
GEHR
Das EU-Projekt Good European Health Record (1992–
1995) aus dem 3. Rahmenprogramm Advanced Informatics
in Medicine AIM bildete mit seinen Ergebnissen die
Basis für die Weiterentwicklung zum openEHR-Konzept.
Hier entstand das GEHR Object Model als Vorläufer des
openEHR-Referenzmodells.
Synapses/SynEx
Ziel der EU-Projekte Synapses und nachfolgend SynEx
(1996-2000) [9] war Spezifikation und Entwicklung einer
Architektur zur Verbindung klinischer Informationssysteme
zu einem Federated Healthcare Record. Der Synapses-Server
kapselt die so genannten Feeder Systems vergleichbar
einer verteilten Datenbank. Die verwendeten Konzepte
basieren auf dem ENV 12265 und damit auf GEHR. Die
Synapses-Projekte dienten der grundsätzlichen Exploration
der Architektur und realisierten kein produktiv einsetzbares
System.
GPCG-Projekte
In Australien wurden Versuche zum automatischen Export
aus proprietären Informationssystemen in eine Patientenakte
nach GEHR-Struktur durchgeführt [2]. Unter der
Bezeichnung Open Architecture Clinical Information
System (OACIS) wurde ein Informationssystem erprobt, um
medizinische Daten vom Krankenhaus zu niedergelassenen
Ärzten zu kommunizieren. Das GP Software Integration
Project beschäftigte sich mit dem Transfer Diabetesrelvanter
Informationen (Diagnose, Medikation, Therapieplan
etc.) zwischen niedergelassenen Einrichtungen.
HealthConnect
HealthConnect ist die Initiative der australischen Regierung
für eine nationale Gesundheitsplattform. Für jeden
Patienten, der seine Zustimmung zur Teilnahme gegeben
hat, soll ein HealthConnect EHR angelegt werden, dem
durch medizinische Leistungserbringer nach einem
Patientenkontakt eine Zusammenfassung über erbrachte
Leistungen und Ergebnisse (event summary) hinzugefügt
werden kann. Die HealthConnect Business Architecture
nimmt in der aktuellen Version 1.9 Bezug auf das neue
Referenzmodell des prEN 13606 und den Archetypansatz.
Nach einer Vorlaufzeit werden seit 2002 zur Erprobung
verschiedener Technologie-Alternativen in einigen australischen
Provinzen geförderte Pilotstudien durchgeführt,
wobei in der Region Brisbane Southside seit 2004 die
openEHR-Software zum Einsatz kommt und damit erstmalig
einer klinischen Eignungsprüfung unterzogen wird
[10].
Aktuelle Entwicklungsprojekte können auf der openEHR-
Webseite eingesehen werden:
http://www.openehr.org/projects/t_projects.htm
14 Forum der Medizin_Dokumentation und Medizin_Informatik 1/2005

Fachbeiträge
openEHR
erweiterbares) Begriffssystem wird getrennt von den
Nutzdaten verwaltet und kann durch einen gemeinsamen,
kontrollierten Prozess angepasst und erweitert werden,
ohne dass Softwareänderungen nötig sind. Aufgrund
eines langjährigen konsequenten Verbesserungsprozesses,
eines kontinuierlichen Abgleichs mit den relevanten
internationalen Standards und des Engagements
der beteiligten Forscher liegt ein weit fortgeschrittenes
Konzept vor, das den aktuellen prEN 13606 wesentlich
geprägt hat und darüber hinaus Potenzial für einen ISO-
Standard besitzt. Obgleich der openEHR-Ansatz und dessen
Vorläufer im vergangenen Jahrzehnt mehrfach im
klinischen Bereich erprobt wurden, konnte jedoch bisher
eine Eignung für den produktiven Einsatz nicht nachgewiesen,
allerdings auch nicht widerlegt werden. Die
nicht unerhebliche Überarbeitung des ursprünglichen
ENV 13606 in Richtung openEHR-Konzept stellt darüber
hinaus die Abwärtskompatibilität des zukünftigen EN
13606 in Frage.
Die Modellierung von Archetypen und damit die Erstellung
einer gemeinsamen Begriffsbibliothek ist aufwändig.
Der Archetyp für das vergleichsweise einfache Konzept
einer Blutdruckmessung umfasst in der derzeitigen
Form bereits 529 Codezeilen. Eine umfangreiche Archetypen-Bibliothek
ist aber für den produktiven klinischen
Einsatz notwendig und erfordert also zunächst aufwändige
Vorleistungen. Mit openEHR soll allerdings keine
Ontologie erstellt werden. Vielmehr sieht die Architektur
vor, die modellierten Datenstrukturen mit Ontologien zu
verknüpfen.
Vergleicht man openEHR mit dem Ansatz der HL7 Clinical
Document Architecture [8], erscheint Letzterer intuitiv
besser fassbar. Im klinischen Bereich wird seit jeher
dokumentenorientiert gedacht und gearbeitet, während
sich Begriffe und Wissen nur schwer greifbar allein in den
Köpfen manifestieren. Erstellung und Handhabung von
Archetypen durch den Kliniker würde daher ein Umdenken
erfordern, aber möglicherweise auch die Reflexion
über das eigene Begriffssystem anregen und vielleicht
auch dadurch zu einer besseren Dokumentation führen.
Weiterhin muss man sich die Frage stellen, ob Informationen
der Patientenakte wirklich auf internationaler
Ebene austauschbar, ja sogar an jedem Ort der Welt durch
die Verknüpfungen zu Ontologien interpretierbar sein
müssen. Grundsätzliche Fragen zum Informationsaustausch
auf regionaler Ebene, wie z.B. Sicherheit, Patientenvertrag,
eindeutige Patientenidentifikation und klinische
Pfade, werden durch openEHR nur am Rande oder
gar nicht betrachtet. Von der Beantwortung derartiger
Fragen hängt aber der Aufbau einer Informationsinfrastruktur
im Gesundheitswesen zurzeit vorrangig ab. Auch
der angestrebte OpenSource-Charakter des openEHR-
Ansatzes widerspricht der Realität heutiger klinischer
Informationssysteme, deren Landschaft dominiert wird
durch wenige große Firmen, die zwar nicht unbedingt
innovative Lösungen schaffen, dafür aber einen effektiven
Einsatz ihrer Software garantieren.
Die Plattform der openEHR Community bietet jedoch
das Potenzial, auch im Bereich der Gesundheitssoftware
von der Produktivität und dem Engagement eines Open-
Source-Projekts zu profitieren. Schließlich beteiligen sich
über diese Plattform an der Entwicklung viele renommierte
Spezialisten mit langjähriger Erfahrung, und auch
die Nutzer erhalten die Möglichkeit zur Einflussnahme.
Für die Modellierung klinischer Terminologie gibt es keine
bessere Alternative, als sie durch die klinischen Nutzer
selbst durchführen zu lassen und die resultierenden Konzepte
der Gemeinschaft zur Diskussion zu stellen. Es bleibt
allerdings abzuwarten, ob die openEHR-Konzepte einerseits
ausreichen, um in Ansätzen komplexes medizinisches
Wissen auf Datenstrukturen abzubilden und andererseits
einfach genug sind, um implementierbar und
nutzbar zu bleiben.
Literatur
[1] openEHR-Architekturspezifikation: http://www.openehr.org/
[2] Bird L., Goodchild A., Tun Z. Experiences with a Two-Level Modelling
Approach to Electronic Health Records. J Res Prac Inf Tech. 2003; 35:
121–38.
[3] Rogers J, Roberts A, Solomon D, van der Haring E, Wroe C, Zanstra P,
Rector A. GALEN ten years on: tasks and supporting tools. Medinfo. 2001;
10(Pt 1): 256–60.
[4] Dean M, Connolly D, van Harmelen F, Hendler J, Horrocks I, McGuinness
DL, Patel-Schneider PF, Stein LA. OWL Web Ontology Language 1.0
Reference, July 2002. http://www.w3.org/TR/owl-ref/.
[5] Genesereth, M. et. al. (1998), »Knowledge Interchange Format« Draft
proposed American National Standard (dpANS), NCITS.T2/98-004.
[6] Hayes P, Menzel C. A semantics for the knowledge interchange format.
Proceedings of IJCAI 2001 Workshop on the IEEE Standard Upper
Ontology, Aug. 2001.
[7] Beale T. Archetypes and the EHR. Stud Health Technol Inform. 2003;
96: 238–44.
[8] Dolin RH, Alschuler L, Beebe C et al. The HL7 Clinical Document
Architecture. J Am Med Inform Assoc. 2001; 8: 552–69.
[9] Grimson J, Stephens G, Jung B, Grimson W, Berry D, Pardon S. Sharing
Health-Care Records over the Internet. IEEE Internet Computing. 2001;
5: 49–58.
[10] Goodchild A, Gibson K, Anderson L, Bird L. The Brisbane Southside
HealthConnect Trial: Preliminary Results. HIC. 2004.
Forum der Medizin_Dokumentation und Medizin_Informatik 1/2005
15