openEHR - Peter L. Reichertz Institut für Medizinische Informatik ...
openEHR - Peter L. Reichertz Institut für Medizinische Informatik ...
openEHR - Peter L. Reichertz Institut für Medizinische Informatik ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Fachbeiträge<br />
<strong>openEHR</strong><br />
<strong>openEHR</strong> – Die Geschichte eines<br />
Baukastensystems für eine gemeinsame<br />
Elektronische Gesundheitsakte<br />
Dipl.-Inform.<br />
Joachim Bergmann<br />
Technische Universität<br />
Braunschweig<br />
<strong>Institut</strong> für <strong>Medizinische</strong><br />
<strong>Informatik</strong><br />
Mühlenpfordtstr. 23<br />
D-38106 Braunschweig<br />
Tel.: +49(0)531/391-9506<br />
Fax: +49(0)531/391-<br />
9502<br />
E-Mail:<br />
J.Bergmann@<br />
mi.tu-bs.de<br />
http://www.mi.tu-bs.de<br />
Aufgrund einer zunehmend besseren technischen<br />
Infrastruktur bieten sich für die Rechnerunterstützung<br />
der Kooperation von Ärzten und anderen<br />
Leistungserbringern in der Patientenversorgung immer<br />
mehr sinnvolle Szenarien an. Die gemeinsame Elektronische<br />
Gesundheitsakte ist ein zentrales Werkzeug, um allen<br />
an der Versorgung Beteiligten den Zugriff auf notwendige<br />
Informationen zum Patienten zu ermöglichen. Allerdings<br />
wirft die einrichtungs- und fachbereichsübergreifende<br />
elektronische Repräsentation und Kommunikation<br />
medizinischer Begriffe viele Fragen auf. Der vorliegende<br />
Artikel stellt den <strong>openEHR</strong>-Ansatz vor, der Beiträge zu<br />
diesem Gebiet geleistet und den korrespondierenden europäischen<br />
Standard maßgeblich beeinflusst hat. Die Darstellung<br />
von Geschichte, Architektur und Potenzial des<br />
<strong>openEHR</strong>-Ansatzes stützt sich auf die online verfügbare<br />
<strong>openEHR</strong>-Dokumentation [1] sowie Publikationen zu Projekten<br />
und Studien.<br />
Eine gemeinsame elektronische<br />
Gesundheitsakte erfordert ein<br />
gemeinsames Begriffssystem<br />
Für eine effiziente und qualitativ hochwertige Patientenversorgung<br />
ist eine aktuelle und vollständige Dokumentation<br />
zum Patienten von großer Bedeutung. Aufgrund<br />
der sehr arbeitsteiligen Organisation der Gesundheitsversorgung<br />
sind jedoch Informationsdefizite ein häufiges<br />
und zentrales Problem. Mit neuen Versorgungsmodellen<br />
wie Integrated Care oder Shared Care soll eine bessere<br />
Kooperation bei der Behandlung erreicht werden,<br />
jedoch ist hierzu der einrichtungsübergreifende Zugriff<br />
auf medizinische Dokumentation zum Patienten wichtig.<br />
In Anlehnung an den Begriff des Shared Care kann diese<br />
Form der Dokumentation als Shared EHR (Shared Electronic<br />
Health Record) bezeichnet werden [2]. Bei der<br />
Patientenversorgung werden zwar auch zukünftig die<br />
eigenen Aufzeichnungen einer Einrichtung die primäre<br />
Informationsquelle sein, aber mit einer zunehmenden<br />
Bereitstellung relevanter Informationen zum Patienten<br />
durch andere Einrichtungen wird die Bedeutung des<br />
Shared EHR als sekundäre Informationsquelle wachsen<br />
[2]. Zukunftsvision ist ein Virtual EHR, der vor dem Nutzer<br />
vollständig verbirgt, welche Teile der präsentierten<br />
Patientendaten aus der eigenen Datenbank vor Ort stammen<br />
und welche von entfernten Quellen anderer Einrichtungen<br />
abgerufen werden.<br />
Die Verarbeitung medizinischer Daten erfolgt im Kontext<br />
des Wissens, das sich in den Köpfen der Mediziner,<br />
in ihren Aufzeichnungen, in Forschung, Literatur etc. manifestiert.<br />
Eine Abbildung dieses Wissens in ein Computersystem<br />
gehört zu den intensiv beforschten Gebieten der<br />
<strong>Medizinische</strong>n <strong>Informatik</strong> und Künstlichen Intelligenz und<br />
ist als ein eher ungelöstes Problem anzusehen, obgleich<br />
viele erfolgreiche Ergebnisse vorliegen (z.B. GALEN [3],<br />
OWL [4], SKIF [5,6]). Innerhalb einer Abteilung oder einer<br />
Einrichtung funktioniert die medizinische Dokumentation<br />
normalerweise gut, da ein lokaler Konsens bzgl. der verwendeten<br />
Datenstrukturen und deren Interpretation vorliegt.<br />
Sobald medizinische Daten über die Fachabteilung<br />
hinaus möglicherweise fachbereichsübergreifend und vielleicht<br />
sogar länderübergreifend auszutauschen sind, wird<br />
das zugrunde liegende Begriffssystem sehr bedeutsam.<br />
Es ist sicherzustellen, dass die Interpretation einer Nachricht<br />
durch den Empfänger in dessen Kontext zur<br />
gewünschten Information führt. Daraus lassen sich leicht<br />
Eigenschaften für einen Shared EHR folgern:<br />
˜ Neben den Nutzdaten müssen die zu ihrer Darstellung<br />
verwendete Symbolik und die Bedeutung dieser<br />
Symbolik elektronisch kommunizierbar sein.<br />
Diese nahe liegende Forderung stellt ein großes<br />
Problem dar.<br />
˜ Die Terminologie des Begriffssystems und auch das<br />
Begriffssystem selbst wandeln sich im Laufe der<br />
Zeit, z.B. durch neue Erkenntnisse der medizinischen<br />
Forschung. Die elektronische Repräsentation<br />
des Begriffssystems muss also anpassbar sein.<br />
˜ Das Wissen über das Begriffssystem liegt bei den<br />
Spezialisten des Fachgebiets vor und sollte also<br />
durch diese wartbar sein. Eine Erweiterung oder<br />
Anpassung der verwendeten Symbolik und die Formulierung<br />
ihrer Bedeutung müssen daher ohne<br />
Änderung der Programme möglich sein.<br />
Die existierenden EHR-Implementierungen können<br />
hinsichtlich der Art, wie eine »Bindung zwischen Datenstruktur<br />
und Begriff« erfolgt, drei Klassen zugeordnet<br />
8 Forum der Medizin_Dokumentation und Medizin_<strong>Informatik</strong> 1/2005
Fachbeiträge<br />
<strong>openEHR</strong><br />
werden [2]. Abbildung 1 illustriert die jeweils resultierende<br />
Datenstruktur am Beispiel.<br />
˜ Unstrukturierte Daten: Der EHR ist eine Sammlung<br />
unstrukturierter oder nicht einheitlich strukturierter<br />
Datencontainer (Blackbox), deren Interpretation<br />
davon abhängt, dass der jeweilige Nutzer mit<br />
den zur Niederschrift verwendeten Konventionen<br />
vertraut ist und dem proprietär kodierten Inhalt<br />
Bedeutung zumessen kann.<br />
˜ Gesamtmodell-Ansatz: Alle verwendbaren<br />
Begriffe, Konzepte und Strukturelemente eines EHR<br />
sind in einem einzigen Klassenmodell definiert und<br />
allen nutzenden Parteien bekannt. Ein solches<br />
Modell kann bereits für kleine Begriffssysteme sehr<br />
groß und damit unhandlich sein. Darüber hinaus<br />
muss das Modell bereits zum Zeitpunkt der Entwicklung<br />
eines rechnergestützten Informationssystems<br />
berücksichtigt und in die Software implementiert<br />
werden, so dass eine spätere Änderung oder<br />
Erweiterung des Modells zu Änderungen an der<br />
Software führen muss.<br />
˜ Instanziierung eines generischen Modells: Ein<br />
generisches Modell definiert nur wenige allgemein<br />
gültige Objektklassen, deren Instanzen sich zu allen<br />
notwendigen Objektmodellen kombinieren lassen.<br />
Je abstrakter das generische Modell bleibt, desto<br />
allgemein gültiger ist es und desto geringer wird<br />
die Wahrscheinlichkeit der Notwendigkeit einer<br />
späteren Änderung. Allerdings steigt mit der<br />
Abstraktion auch der Interpretationsspielraum<br />
bezüglich der in einem Modell enthaltenen Elemente,<br />
wobei im Extremfall der Abstraktion die<br />
bereits vorgestellten unstrukturierten Datencontainer<br />
vorlägen.<br />
Mit der als »<strong>openEHR</strong>« [7] durch die <strong>openEHR</strong> Foundation<br />
publizierten Architektur wird der beschriebene<br />
generische Modellansatz um zusätzliche, außerhalb des<br />
Modells formulierte Strukturen zur Definition eines<br />
Begriffssystems erweitert. Dieser Ansatz ist nicht neu,<br />
aufgrund seiner zumindest konzeptuellen Einfachheit<br />
aber bewiesenermaßen realisierbar und nicht zuletzt durch<br />
die Aufmerksamkeit, die ihm aktuell geschenkt wird, relevant.<br />
<strong>openEHR</strong> realisiert flexible, aber<br />
eindeutig definierte Begriffssysteme<br />
Ziel des <strong>openEHR</strong>-Ansatzes ist die Entwicklung rechnerbasierter<br />
Informationssysteme, die Informationen korrespondierend<br />
zu einem Begriffssystem speichern können,<br />
ohne dass die Struktur des Begriffssystems fest in<br />
den Programmen kodiert werden muss. Dadurch sollen<br />
die Fachbenutzer vor Ort in der Lage sein, zur Laufzeit<br />
das den verarbeiteten Daten zugrunde liegende Begriffssystem<br />
anpassen zu können. Darüber hinaus müssen die<br />
gespeicherten Informationen einrichtungsübergreifend<br />
kommunizierbar sein. Um dies zu erreichen, ist das grundlegende<br />
Prinzip des <strong>openEHR</strong>-Ansatzes eine als Trennung<br />
von »Wissen« und »Information« bezeichnete Architektur<br />
[7], die auf den im Folgenden beschriebenen Konzepten<br />
Referenzmodell und Archetyp basiert.<br />
Das Referenzmodell legt den Raum möglicher Objektmodelle<br />
fest, indem verwendbare Objektklassen und deren<br />
Beziehungen zueinander definiert werden. Dadurch werden<br />
im Sinne einer »harten« Definition sowohl der Aufbau<br />
eines jeden Objekts, insbesondere Objektname, Eigenschaften<br />
und Funktionen festgelegt als auch die Kombinationsmöglichkeiten<br />
mit anderen Objekten durch Beziehungstyp,<br />
Multiplizität etc. beschrieben. In diesem schlank<br />
gehaltenen Referenzmodell sind ausdrücklich nur solche<br />
Objektklassen enthalten, die übergreifend gültig sind und<br />
kein fachspezifisches Wissen darstellen, wie z.B. Data-<br />
Value als Container für Informationen oder das Strukturelement<br />
ItemList zur Zusammenfassung von Elementen<br />
Abbildung 1:<br />
Abbildung des Begriffs<br />
Blutdruck auf<br />
Datenstrukturen in<br />
verschiedener Form [2]:<br />
a) Unstrukturierte Daten<br />
b) Gesamtmodell-Ansatz<br />
c) Generisches Modell<br />
Abbildung 2:<br />
Übersicht über die<br />
<strong>openEHR</strong>-Architektur<br />
Forum der Medizin_Dokumentation und Medizin_<strong>Informatik</strong> 1/2005<br />
9
Fachbeiträge<br />
<strong>openEHR</strong><br />
eine Interessengemeinschaft internationaler Fachleute<br />
weitergeführt werden. Ziel ist es, durch öffentliche, aber<br />
zugleich konsolidierte Aktivitäten den <strong>openEHR</strong>-Ansatz<br />
gemeinschaftlich auszufeilen und durch OpenSource-Software<br />
allgemein nutzbar zu machen. Ein Online-Repository<br />
ermöglicht Zugriff auf den jeweils aktuellen Stand<br />
von Architektur, Spezifikationsdokumenten und Software,<br />
während Forum und E-Mail-Listen intensiv zur konstruktiven<br />
Diskussion genutzt werden. Aufgrund des (unbezahlten)<br />
Engagements der Beteiligten wurde der Ansatz<br />
in verschiedenen Projekten erprobt und hat wesentlichen<br />
Einfluss auf europäische Standardisierungsaktivitäten<br />
sowie die Planung der Gesundheitstelematikplattform in<br />
Australien.<br />
Abbildung 3:<br />
Screenshot der ADL<br />
Workbench<br />
zu einer Liste. Durch Instanziierung der Klassen des Referenzmodells,<br />
also durch Erstellen konkreter Objekte, Füllen<br />
mit Daten und Verknüpfen von Objekten untereinander,<br />
wird Information kodiert. Nur eine kleine Anzahl der<br />
nach dem Referenzmodell erstellbaren Objektmodelle<br />
ergibt jedoch im klinischen Kontext einen Sinn. Daher<br />
wird mit Hilfe von Archetypen (Urbilder, Grundmuster) in<br />
Form einer »weichen« Definition beschrieben, welche<br />
Objektinhalte und -kombinationen sinnvoll sind. Ein Archetyp<br />
ist eine Menge von Regeln, die für bestimmte Objekte<br />
den Wertebereich ihrer Attribute einschränken und<br />
erlaubte Beziehungen zu anderen Objekten definieren.<br />
Abbildung 2 stellt das Verhältnis zwischen Referenzmodell,<br />
Archetyp und Information grafisch dar.<br />
Für die Beschreibung der Archetypen ist mit der Archetype<br />
Definition Language ADL eine Sprache definiert.<br />
Alternativ können Archetypen als Instanzmodell des Archetype<br />
Object Model AOM dargestellt werden, indem<br />
erlaubte Objektkombinationen modelliert werden, ohne<br />
die Attribute mit Werten zu füllen oder Objektbeziehungen<br />
darzustellen. ADL und AOM sind hinsichtlich ihrer<br />
Mächtigkeit äquivalent.<br />
<strong>openEHR</strong> im Detail<br />
Mit der Gründung der <strong>openEHR</strong> Foundation im Jahre<br />
2000 sollten die Forschungsaktivitäten zur Architektur<br />
elektronischer Gesundheitsakten im Umfeld des britischen<br />
Centre for Health Informatics and Multiprofessional Education<br />
(CHIME) am Londoner University College durch<br />
Die bisherigen <strong>openEHR</strong>-Aktivitäten lassen sich entsprechend<br />
der Organisation des Projekts folgenden Bereichen<br />
zuordnen:<br />
˜ Anforderungsermittlung: Basierend auf den Erfahrungen<br />
aus dem <strong>openEHR</strong>-Vorläuferprojekt GEHR (s.u.)<br />
sollen Anforderungen an einen verteilten offenen<br />
Standard für elektronische Gesundheitsakten untersucht<br />
und definiert werden. Anhand der online verfügbaren<br />
<strong>openEHR</strong>-Dokumentation ist zu erkennen,<br />
dass in diesem Arbeitsbereich zuletzt wenig Aktivität<br />
stattgefunden hat.<br />
˜ Spezifikation der Architektur: Im Rahmen dieses<br />
Arbeitsbereichs wird die <strong>openEHR</strong>-Architektur spezifiziert.<br />
Die Architektur umfasst ein Referenzmodell,<br />
eine Sprache und ein Objektmodell zur Beschreibung<br />
von Archetypen sowie ein System modellierter und<br />
anerkannter Archetypen selbst. Zu jedem Bestandteil<br />
der Architektur liegt ein ausführliches, beschreibendes<br />
Dokument vor. Jüngste Aktivitäten beschäftigen<br />
sich vor allem mit der Spezifikation der Archetype<br />
Definition Language. Der jeweils aktuelle genehmigte<br />
Zustand des Referenzmodells ist auf den <strong>openEHR</strong>-<br />
Webseiten in Form eines automatisch generierten<br />
HTML-Exports aus der Programmiersprache Eiffel einzusehen.<br />
˜ Realisierung der abstrakten Architekturspezifikationen:<br />
Zur produktiven Nutzung der <strong>openEHR</strong>-<br />
Konzepte sollen für verschiedene Programmiersprachen<br />
die abstrakten Spezifikationen zu so genannten<br />
Implementation Technology Specifications (ITS)<br />
konkretisiert werden, wie z.B. für Java, XML-Schema,<br />
IDL und Python.<br />
˜ Implementierung: Die bei der Durchführung von Studien<br />
und Pilotprojekten entstehenden Programme und<br />
Werkzeuge werden auf OpenSource-Basis zur Verfügung<br />
gestellt, wie z.B. Programmierschnittstellen für<br />
Java und .NET sowie einige Tools. Die ADL Workbench<br />
10 Forum der Medizin_Dokumentation und Medizin_<strong>Informatik</strong> 1/2005
Fachbeiträge<br />
<strong>openEHR</strong><br />
(siehe Abbildung 3) dient der Exploration vorhandener<br />
Archetyp-Definitionen und unterstützt den Entwickler<br />
durch den Referenz-Parser bei Fehlersuche und Format-Konvertierung.<br />
Ein in ADL vorliegender, geparster<br />
Archetyp kann in XML-, OWL- oder HTML-Form<br />
ausgegeben werden. Der Archetype Editor richtet sich<br />
an die Spezialisten des Fachgebiets und ermöglicht<br />
die Erstellung und Bearbeitung von Archetypen zur<br />
Realisierung einer Terminologie. Das Programm ist<br />
allerdings nicht ganz einfach zu bedienen.<br />
Darüber hinaus ist mit den Werkzeugen eine kleine<br />
Bibliothek von Archetypen verfügbar. Das jüngste Paket<br />
enthält bereits 44 modellierte klinische Konzepte, wie<br />
z.B. Anamnese, Medikation, Pathologiebefund, Schilddrüsen-Laboranalytik<br />
etc.<br />
Referenzmodell<br />
Das <strong>openEHR</strong>-Referenzmodell stellt eine Weiterentwicklung<br />
des GEHR Object Model GOM dar und befindet<br />
sich in fortlaufender Überarbeitung. Auffallender Unterschied<br />
zum GOM ist die Migration vom Konzept der Transaction<br />
zu Composition zugunsten einer Konformität mit<br />
dem ENV 13606. Hintergrund ist der Wunsch, mit einem<br />
Objekt sowohl transaktionsorientierte Ereignisse als auch<br />
feststehende (longitudinale) Fakten kodieren zu können.<br />
Abbildung 4 zeigt eine Grafik aus der <strong>openEHR</strong>-Architektur-Spezifikation.<br />
Abgebildet ist mit den Teilmodellen EHR<br />
und Composition der zentrale Part des <strong>openEHR</strong>-Referenzmodells,<br />
das Reference Information Model, zum besseren<br />
Verständnis ergänzt durch verknüpfte Teilmodelle.<br />
Grundsätzlich werden Datenobjekte (Text, Messwert<br />
etc.) aus dem Teilmodell Data Types unter Verwendung<br />
der Strukturelemente aus dem Teilmodell Data Structures<br />
zu »speicherbaren« Informationseinheiten kombiniert<br />
und fachlich einer Ordnung durch Elemente aus Composition<br />
unterzogen. Welche Kombinationen von Objekten<br />
erlaubt sind, beschreibt ein in ADL oder durch AOM-Klassen<br />
formulierter Archetyp. Die Informationseinheiten werden<br />
durch Gruppierungselemente aus dem Teilmodell EHR<br />
zu einer Gesundheitsakte arrangiert, wobei durch den<br />
zwischengeschalteten Container Versioned Composition<br />
die Verwaltung versionierter Informationseinheiten ermöglicht<br />
wird. Zentrale Teilmodelle des Referenzmodells werden<br />
im Folgenden beschrieben.<br />
EHR Enthält die aggregierenden Strukturen zur Repräsentation<br />
einer <strong>openEHR</strong>-Gesundheitsakte. Dieses Teilmodell<br />
stellt zusammen mit dem Teilmodell Composition<br />
das EHR Information Model dar. Insbesondere werden in<br />
diesem Modellteil die Folder definiert, um die Informationseinheiten<br />
einer Gesundheitsakte zu gliedern und die<br />
Navigation zu ermöglichen. Eine übliche, bereits im GEHR-<br />
Projekt formulierte Gliederung ist die Zuordnung von<br />
Informationen zu folgenden Ordnern:<br />
˜ Persönliche Daten (Name, Geburtsort, Adresse etc.)<br />
˜ Persistente Daten (Diagnosen, Dauermedikation,<br />
Familienanamnese etc.)<br />
˜ Ereignisse<br />
˜ Episoden<br />
Die Ordner Ereignisse und Episoden stellen dabei keine<br />
disjunkten Mengen dar. Ein Beispiel einer Ordnerstruktur<br />
zeigt die Abbildung 5.<br />
Composition Das Paket definiert die zur Speicherung<br />
von Informationseinheiten erforderlichen Strukturelemente.<br />
Eine Composition ist Bestandteil eines EHR und<br />
stellt die Instanziierung eines Archetypen und damit dessen<br />
Ausprägung zu einer konkreten Informationseinheit<br />
dar. Eine Composition enthält Sections zur logischen Gruppierung,<br />
die weitere Sections oder zur fachlichen Zuordnung<br />
Entrys enthalten können. Dabei werden im Kontext<br />
dieses Teilmodells nur fachliche Aussagen getroffen, während<br />
die Komposition komplexer Datenstrukturen im Teilmodell<br />
Data Structures erfolgt. Composition, Section und<br />
Entry können die Wurzeln eines Archetypen sein und werden<br />
daher als »archetypable« bezeichnet. Beispiel: Der<br />
Archetyp blood pressure measurement ist vom Typ Observation<br />
und damit Unterklasse von Entry.<br />
Data Structures Enthält Strukturen zur Definition<br />
komplexer Datenstrukturen wie z.B. Liste und Tabelle. Ein<br />
Zeit-Konzept (History) ermöglicht die Verknüpfung von<br />
Datenstrukturen mit Ereignissen auf der Zeitachse. Auch<br />
Datenstrukturen sind »archetypable«. Beispiel: Im Arche-<br />
Abbildung 4:<br />
<strong>openEHR</strong> Reference<br />
Information Model<br />
(Teilmodelle EHR und<br />
Composition) sowie<br />
verknüpfte Teilmodelle.<br />
Forum der Medizin_Dokumentation und Medizin_<strong>Informatik</strong> 1/2005<br />
11
Fachbeiträge<br />
<strong>openEHR</strong><br />
als ADL-Sprachkonstrukt oder als Instanz des AOM vorliegen.<br />
ADL und AOM sind hinsichtlich ihrer Ausdrucksstärke<br />
äquivalent zueinander.<br />
ADL ist in zwei weitere Sprachen dADL sowie cADL für<br />
unterschiedliche Anwendungsfälle aufgeteilt und verbindet<br />
deren Ausdrücke zu einer kompakten Archetypbeschreibung.<br />
Die Sprache dADL dient der Definition einer<br />
konkreten Objektinstanz, während in cADL Regeln bzgl.<br />
Typ und Attributen einer Objektinstanz formuliert werden.<br />
ADL und damit implizit auch eine Instanz des AOM<br />
beschreiben einen Archetyp in den vier Abschnitten Identifikation,<br />
Beschreibung, Definition und Ontologie.<br />
Identifikation Jeder Archetyp wird durch einen<br />
Identifikator eindeutig bestimmt und ggf. von einem<br />
anderen Archetypen abgeleitet. Folgendes Statement<br />
stellt eine eindeutige Benennung des Archetypen blood<br />
pressure dar.<br />
archetype (adl_version=1.2)<br />
<strong>openEHR</strong>-EHR-OBSERVATION.blood_pressure.v1<br />
Abbildung 5:<br />
Beispiel für eine<br />
Ordnerstruktur, die<br />
durch Objekte aus dem<br />
EHR-Teilmodell realisiert<br />
werden kann.<br />
Die dunkelgrauen<br />
Rechtecke stellen<br />
Instanzen der<br />
Referenzmodell-Klasse<br />
Folder dar und dienen<br />
der nicht notwendigerweise<br />
disjunkten<br />
Einordnung von<br />
Informationseinheiten.<br />
typ blood pressure measurement ist das Messergebnis<br />
blood pressure einem Ereignis (dem Messvorgang baseline<br />
reading) untergeordnet. Aber auch das Messergebnis<br />
selbst ist ein eigenständiger Archetyp.<br />
Data Types Beschreibt grundlegende »fortgeschrittene«<br />
Datentypen wie (kodierbarer) Text, allgemeine Messgröße,<br />
Datum etc. Die verschiedenen Messgrößen sind<br />
detailliert modelliert (z.B. dimensionslose Größe, Wert<br />
mit Maßeinheit, Intervall, Verhältnis etc.). Beispiel: Der<br />
systolische Blutdruck ist eine einfache Messgröße bestehend<br />
aus Messwert und Maßeinheit.<br />
EHR Extract Beschreibt zum EHR-Teilmodell korrespondierende<br />
Klassen, um ein Teilsystem eines EHR zu<br />
einem »Extrakt« zu isolieren und beispielsweise im Rahmen<br />
eines Kommunikationsvorgangs zu versenden.<br />
Archetype Definition Language<br />
und Archetypobjektmodell<br />
Die als <strong>openEHR</strong>-Spezifikation vorliegende Archetype<br />
Definition Language ADL ist eine formale Sprache zur<br />
Beschreibung von Archetypen. Sie legt fest, wie Klassen<br />
des Referenzmodells zu einem fachlichen Begriff kombiniert<br />
werden müssen und welche elementaren Daten sie<br />
enthalten dürfen. Für jeden Archetyp wird ein ADL-Konstrukt<br />
in Textform angegeben, das analog zu XML/DOM<br />
auch als hierarchische Objektstruktur interpretiert werden<br />
kann. Diese Objektstruktur stellt eine Instanziierung<br />
des Archetypobjektmodells AOM dar, welches ebenfalls als<br />
Spezifikationsdokument vorliegt. Ein Archetyp kann somit<br />
Eine Verbindung des Archetypen mit einem Begriff<br />
wird durch das Concept-Statement hergestellt. Im folgenden<br />
Beispiel wird dazu mit der lokalen Referenz<br />
at0000 auf einen Eintrag im Ontologie-Abschnitt (s.u.)<br />
verwiesen.<br />
concept<br />
[at0000] -- blood pressure<br />
Beschreibung Dieser Abschnitt enthält die Meta-<br />
Daten eines Archetypen und umfasst Details zu Zweck,<br />
Anwendungsgebiet und Ersteller des Archetypen sowie<br />
Informationen zum Revisionsverfahren im Rahmen der<br />
Aufnahme in eine global verfügbare Archetyp-Bibliothek.<br />
Die Beschreibungsdetails können in verschiedenen Sprachen<br />
enthalten sein. Die Beschreibung wird in dADL<br />
kodiert:<br />
description<br />
original_author = <br />
description("de") = <<br />
purpose = <br />
[...]<br />
Definition In Form von Einschränkungsregeln (constraints)<br />
werden erlaubte Objektstrukturen formuliert. Dazu<br />
wird für einen Archetypen im Detail festgelegt, welche<br />
Klassen des Referenzmodells instanziiert werden, wie sie<br />
hierarchisch gruppiert sind und welche Attributwerte bzw.<br />
Assoziationen erlaubt sind. Für jede Instanziierung einer<br />
Referenzmodellklasse muss eine eigene Einschränkungsregel<br />
angegeben werden.<br />
12 Forum der Medizin_Dokumentation und Medizin_<strong>Informatik</strong> 1/2005
Fachbeiträge<br />
<strong>openEHR</strong><br />
Der Definitionsabschnitt wird in der Sprache cADL verfasst.<br />
Das folgende Beispiel zeigt einen Ausdruck für den<br />
diastolischen Blutdruck.<br />
ELEMENT[at00005] matches { -- diastolic blood pressure<br />
value matches {<br />
QUANTITY matches {<br />
magnitude matches {0..1000}<br />
property matches {"pressure"}<br />
units matches {"mm[Hg]"}<br />
}<br />
}<br />
}<br />
Der Ausdruck legt unter Verwendung einer lokal gültigen<br />
ID (archetype term) fest, dass zur Erstellung einer Informationseinheit<br />
für den diastolischen Blutdruck die Klasse<br />
Element aus dem Referenzmodell instanziiert werden<br />
muss und die Assoziation value auf eine weitere Instanz<br />
vom Typ Quantity zeigen muss, für die Einschränkungen<br />
bzgl. der Attribute definiert sind.<br />
Ontologie Der Ontologie-Abschnitt fügt der Objektstruktur<br />
des Archetypen eine Semantik hinzu. Dazu können<br />
für verschiedene Sprachen textuelle Beschreibungen<br />
des Archetypen und der einzelnen Informationseinheiten<br />
hinterlegt werden (term definition) und Verknüpfungen<br />
zu einer Terminologie hergestellt werden (term binding).<br />
Ein in dADL kodiertes Beispiel sieht wie folgt aus:<br />
term_definitions("en") = <<br />
items("at0005") = <<br />
text = <br />
description = <br />
><br />
><br />
term_binding("SNOMED-CT") = <<br />
items("at0005") = <br />
><br />
Der Ontologie-Abschnitt stellt keine Definition einer Ontologie<br />
dar. Vielmehr erfolgt hier die Verknüpfung mit einer<br />
Ontologie (oder mehreren).<br />
Templates<br />
Archetypen beschreiben die Struktur von Informationseinheiten<br />
zur Darstellung von Begriffen im Informationssystem,<br />
nicht jedoch deren Repräsentation oder Nutzungskontext.<br />
Zur Laufzeit ist es aber erforderlich, Archetypen<br />
zu kombinieren, um sie z.B. dem Nutzer in einem Bildschirmformular<br />
zu präsentieren, Archetypen bei der Erzeugung<br />
mit Default-Werten zu versehen oder Archetypen je<br />
nach Anwendungssituation weiter einzuschränken. Dazu<br />
sieht <strong>openEHR</strong> das Konzept der Templates vor, die zukünftig<br />
mit Hilfe der Sprache tADL beschrieben werden sollen.<br />
Einrichtungen und Beteiligte der <strong>openEHR</strong>-Initiative<br />
CHIME/UCL<br />
Das Centre for Health Informatics and Multiprofessional<br />
Education am University College London war<br />
federführend im GEHR-Projekt und hat die open-<br />
EHR-Initiative begründet. Sehr aktive Beteiligte<br />
sind David Lloyd (Koordinator des GEHR-Projekts),<br />
Dr. Dipak Kalra und Prof. David Ingram.<br />
http://www.chime.ucl.ac.uk/<br />
Ocean Informatics<br />
Die australische Firma Ocean Informatics entstand<br />
im Rahmen der <strong>openEHR</strong>-Gründung und möchte<br />
die Konzepte dieses Ansatzes und die OpenSource-<br />
Software kommerziell einsetzen. Bekannt als open-<br />
EHR-Mitbegründer sind Dr. <strong>Peter</strong> Schloeffel,<br />
Dr. Sam Heard und Thomas Beale.<br />
http://www.oceaninformatics.biz/<br />
DSTC<br />
Das Distributed Systems Technology Centre ist ein<br />
australisches Joint Venture aus Industrie, Regierung<br />
und Forschungseinrichtungen zur Erforschung und<br />
Entwicklung sicherer verteilter Systeme. Langjährig<br />
Erläuterung von Begriffen im <strong>openEHR</strong>-Kontext<br />
Eine Entität ist ein in der realen Welt eindeutig<br />
identifizierbares Objekt, das entweder materiell<br />
existiert, wie z.B. ein Messgerät, oder ein immaterielles<br />
Konzept darstellt, wie z.B. eine Krankheit. In<br />
der Regel ist eine Klasse hinsichtlich bestimmter<br />
Eigenschaften gleicher Objekte gemeint (z.B. Person)<br />
und nicht eine spezielle<br />
Ausprägung/Instanz dieser Klasse<br />
(z.B. »Herr Meier«).<br />
Begriff meint das gedankliche Konzept eines<br />
möglicherweise komplexen Sachverhalts. Das DIN<br />
definiert Begriff als Denkeinheit, die aus einer<br />
Menge von Gegenständen unter Ermittlung der<br />
diesen Gegenständen gemeinsamen Eigenschaften<br />
mittels Abstraktion gebildet wird. Ein Bezeichner<br />
ist die Repräsentation des Begriffs in einer<br />
Sprache.<br />
Ein Referenzmodell ist ein Modell, das als<br />
idealtypisch für die Klasse der zu modellierenden<br />
Sachverhalte betrachtet werden kann. Im <strong>openEHR</strong>-<br />
Ansatz beschreibt das Referenzmodell Bausteine,<br />
die instanziiert, mit Daten gefüllt und zu den<br />
eigentlichen Informationseinheiten zusammengesetzt<br />
werden können.<br />
Archetyp bedeutet Urform oder Musterbild und<br />
meint hier die Beschreibung des Aufbaus einer<br />
Informationseinheit. Ein Archetyp legt fest, wie<br />
Objekte des Referenzmodells zur Darstellung eines<br />
Begriffs im Computersystem miteinander kombiniert<br />
und welche Werte darin gespeichert werden<br />
dürfen. Ein Archetyp ist unabhängig von Terminologie<br />
und Sprache, da er den Begriff, das gedankliche<br />
Konzept, repräsentiert. Im Ontologieabschnitt einer<br />
aktiv im <strong>openEHR</strong>-Projekt sind Dr. Linda Bird und<br />
Dr. Andrew Goodchild.<br />
http://www.dstc.edu.au/<br />
<strong>openEHR</strong> Foundation<br />
Die <strong>openEHR</strong> Foundation wurde zur Weiterentwicklung<br />
der GEHR- und CEN EN 13606-Konzepte im<br />
Jahre 2000 gegründet und sieht ihre Arbeit als<br />
unabhängig und nichtkommerziell orientiert. Die<br />
Gründungsmitglieder sind Prof. David Ingram,<br />
Dr. <strong>Peter</strong> Schloeffel, Dr. Sam Heard, Dr. Dipak Kalra,<br />
David Lloyd und Thomas Beale. Ein Architecture<br />
Review Board unter der Leitung von Thomas Beale<br />
und mit Mitgliedern der Universitäten Aalborg und<br />
Tromsø, der Firma Ocean Informatics, dem CHIME<br />
sowie dem autralischen Department of Health and<br />
Ageing wacht über die <strong>openEHR</strong>-Architektur.<br />
http://www.openehr.org/<br />
Über die genannten Einrichtungen hinaus haben<br />
viele weitere Beteiligte zur <strong>openEHR</strong>-Architektur,<br />
der Software und der Archetypen-Bibliothek<br />
beigetragen.<br />
Archetyp-Definition sind Hinweise enthalten, die es<br />
im idealen Fall jedem Nutzer auf der Welt ermöglichen<br />
sollen, mit dem Archetypen einen Begriff zu<br />
verbinden. So könnte ein Archetyp für den Begriff<br />
Blutdruck dort Übersetzungen in verschiedene<br />
Sprachen (z.B. blood pressure, pression artérielle,<br />
pressão arterial) und Codes von Terminologiesystemen<br />
(z.B. MeSH: G09.330.553.400.114) enthalten.<br />
In <strong>openEHR</strong> werden Archetypen in der<br />
Sprache ADL verfasst.<br />
Eine Terminologie ist die Gesamtheit der in<br />
einem Fachgebiet üblichen Fachwörter und -ausdrücke.<br />
Sie umfasst also eine Menge von Bezeichnern,<br />
mit denen man etwas benennen kann.<br />
Eine Ontologie ist ein formal definiertes System<br />
von Entitäten (Dingen, Konzepten) und ihren<br />
Beziehungen zueinander. Sie beschreibt also, wie<br />
etwas ist.<br />
Mit Semantik ist hier die Bedeutung einer vorliegenden<br />
Dateneinheit für einen Betrachter<br />
gemeint. Kann der Betrachter mit den Zeichenfolgen<br />
der Dateneinheit einen Begriff verbinden, so<br />
haben sie für ihn eine Bedeutung.<br />
Eiffel ist eine objektorientierte Programmiersprache,<br />
die um 1985 entstanden ist. Sie realisiert<br />
fortgeschrittene Merkmale des objektorientierten<br />
Paradigmas wie z.B. multiple Vererbung. Als Erfinder<br />
des »Design by contract«-Prinzips gilt Eiffel als<br />
Entwicklungsmethode für saubere und stabile Software<br />
und wird von den <strong>openEHR</strong>-Entwicklern für<br />
die Implementierung des Referenzmodells<br />
geschätzt.<br />
Forum der Medizin_Dokumentation und Medizin_<strong>Informatik</strong> 1/2005<br />
13
Fachbeiträge<br />
<strong>openEHR</strong><br />
Ausgewählte<br />
<strong>openEHR</strong>-Projekte<br />
Archetyp-System<br />
Für den institutionsübergreifenden Informationsaustausch<br />
muss der jeweilige Empfänger eines Datenpakets<br />
(z.B. eines EHR Extracts, siehe Referenzmodell) diese<br />
Daten interpretieren und daher die verwendeten Begriffsstrukturen<br />
kennen. <strong>openEHR</strong> sieht in Form des Archetype-<br />
Systems den Aufbau einer gemeinsam genutzten und<br />
gemeinsam erweiterbaren globalen Bibliothek von Archetypen<br />
vor, indem Geschäftsprozesse und Schnittstellen<br />
für dieses System spezifiziert werden. Im Authoring Network<br />
wird der Erstellungs- und Revisionsprozess für Archetypen<br />
festgelegt, während im Dissemination Network die<br />
gemeinsame Nutzung dieser Bibliothek beschrieben ist.<br />
Von GEHR über <strong>openEHR</strong><br />
zum europäischen Standard<br />
Die <strong>openEHR</strong> zugrunde liegenden Konzepte wurden im<br />
europäisch geförderten Projekt GEHR (Good European<br />
Health Record, 1992–1995) entwickelt und realisieren<br />
im Wesentlichen den bereits beschriebenen Ansatz des<br />
generischen Modells eines EHR. Im so genannten GEHR<br />
Object Model GOM wird die Gesundheitsakte als eine<br />
Menge erbrachter Leistungen (Transactions) angesehen,<br />
zu jeder Leistung wiederum eine Menge von Ergebnissen<br />
(Observations) gehörend. Die Resultate dieses Projekts<br />
flossen zu einem großen Teil in den europäischen Standard<br />
ENV 12265 Electronic Healthcare Record Architecture<br />
(1995) und damit auch in die Nachfolgerversion ENV<br />
13606 (1999) ein, dort bereits ergänzt um ein Begriffssystem<br />
zum Füllen der generischen Datencontainer. Die<br />
Spezifikation des CEN-Standards wurde begleitet durch<br />
die EHCR-SupA (Electronic Healthcare Record Support<br />
Action, ca. 1997–2000) unter Federführung des CHIME<br />
(Centre for Health Informatics and Multiprofessional Education)<br />
am University College London.<br />
Der ENV 12265 und damit die GEHR-Architektur wurden<br />
in den Synapses/SynEx-Projekten (1996–2000) verwendet,<br />
um klinische Datenbanken zu einem verteilten<br />
System zu vernetzen. GEHR fand auch außerhalb Europas<br />
Interesse und wurde zur Fortführung dieser Arbeiten<br />
insbesondere in Australien in Good Electronic Health<br />
Record umbenannt (1998–2001). Der originale GEHR-<br />
Ansatz eines generischen Modells wurde in Anlehnung<br />
an den ENV 13606 um ein ausgefeiltes Archetypen-Modell<br />
ergänzt und das Referenzmodell in verschiedenen Iterationen<br />
überarbeitet. Das resultierende Konzept stellt eine<br />
Verschmelzung von GEHR, Synapses/SynEx und Teilen des<br />
ENV 13606 von 1999 dar. Die im Jahre 2000 durch Initiative<br />
des CHIME gegründete <strong>openEHR</strong> Foundation propagiert<br />
dieses Konzept als Open-Source-Ansatz für elektronische<br />
Gesundheitsakten unter dem Namen <strong>openEHR</strong>.<br />
Der Ansatz hat nicht zuletzt durch das Engagement der<br />
Beteiligten großen Einfluss auf den in Abstimmung befindlichen<br />
neuen CEN-Standard prEN 13606 ausgeübt, der<br />
seit 2001 durch die unter wesentlicher Beteiligung ehemaliger<br />
GEHR-Mitglieder im CEN TC/251 gebildete Task<br />
Force EHRcom fortgeschrieben wird. Im 2nd Working Draft<br />
wird der bisherige Teil 1 Extended Architecture durch<br />
einen überarbeiteten Teil 1 Reference Model ersetzt und<br />
ein neuer Teil 2 Archetype Interchange Specification für<br />
die Archetype Language und das Archetype Model hinzugefügt.<br />
Diskussion<br />
Die <strong>openEHR</strong>-Architektur ermöglicht es, klinische<br />
Informationen einrichtungsübergreifend austauschbar<br />
zu machen. Ein allen Nutzern zugängliches (und lokal<br />
GEHR<br />
Das EU-Projekt Good European Health Record (1992–<br />
1995) aus dem 3. Rahmenprogramm Advanced Informatics<br />
in Medicine AIM bildete mit seinen Ergebnissen die<br />
Basis für die Weiterentwicklung zum <strong>openEHR</strong>-Konzept.<br />
Hier entstand das GEHR Object Model als Vorläufer des<br />
<strong>openEHR</strong>-Referenzmodells.<br />
Synapses/SynEx<br />
Ziel der EU-Projekte Synapses und nachfolgend SynEx<br />
(1996-2000) [9] war Spezifikation und Entwicklung einer<br />
Architektur zur Verbindung klinischer Informationssysteme<br />
zu einem Federated Healthcare Record. Der Synapses-Server<br />
kapselt die so genannten Feeder Systems vergleichbar<br />
einer verteilten Datenbank. Die verwendeten Konzepte<br />
basieren auf dem ENV 12265 und damit auf GEHR. Die<br />
Synapses-Projekte dienten der grundsätzlichen Exploration<br />
der Architektur und realisierten kein produktiv einsetzbares<br />
System.<br />
GPCG-Projekte<br />
In Australien wurden Versuche zum automatischen Export<br />
aus proprietären Informationssystemen in eine Patientenakte<br />
nach GEHR-Struktur durchgeführt [2]. Unter der<br />
Bezeichnung Open Architecture Clinical Information<br />
System (OACIS) wurde ein Informationssystem erprobt, um<br />
medizinische Daten vom Krankenhaus zu niedergelassenen<br />
Ärzten zu kommunizieren. Das GP Software Integration<br />
Project beschäftigte sich mit dem Transfer Diabetesrelvanter<br />
Informationen (Diagnose, Medikation, Therapieplan<br />
etc.) zwischen niedergelassenen Einrichtungen.<br />
HealthConnect<br />
HealthConnect ist die Initiative der australischen Regierung<br />
für eine nationale Gesundheitsplattform. Für jeden<br />
Patienten, der seine Zustimmung zur Teilnahme gegeben<br />
hat, soll ein HealthConnect EHR angelegt werden, dem<br />
durch medizinische Leistungserbringer nach einem<br />
Patientenkontakt eine Zusammenfassung über erbrachte<br />
Leistungen und Ergebnisse (event summary) hinzugefügt<br />
werden kann. Die HealthConnect Business Architecture<br />
nimmt in der aktuellen Version 1.9 Bezug auf das neue<br />
Referenzmodell des prEN 13606 und den Archetypansatz.<br />
Nach einer Vorlaufzeit werden seit 2002 zur Erprobung<br />
verschiedener Technologie-Alternativen in einigen australischen<br />
Provinzen geförderte Pilotstudien durchgeführt,<br />
wobei in der Region Brisbane Southside seit 2004 die<br />
<strong>openEHR</strong>-Software zum Einsatz kommt und damit erstmalig<br />
einer klinischen Eignungsprüfung unterzogen wird<br />
[10].<br />
Aktuelle Entwicklungsprojekte können auf der <strong>openEHR</strong>-<br />
Webseite eingesehen werden:<br />
http://www.openehr.org/projects/t_projects.htm<br />
14 Forum der Medizin_Dokumentation und Medizin_<strong>Informatik</strong> 1/2005
Fachbeiträge<br />
<strong>openEHR</strong><br />
erweiterbares) Begriffssystem wird getrennt von den<br />
Nutzdaten verwaltet und kann durch einen gemeinsamen,<br />
kontrollierten Prozess angepasst und erweitert werden,<br />
ohne dass Softwareänderungen nötig sind. Aufgrund<br />
eines langjährigen konsequenten Verbesserungsprozesses,<br />
eines kontinuierlichen Abgleichs mit den relevanten<br />
internationalen Standards und des Engagements<br />
der beteiligten Forscher liegt ein weit fortgeschrittenes<br />
Konzept vor, das den aktuellen prEN 13606 wesentlich<br />
geprägt hat und darüber hinaus Potenzial für einen ISO-<br />
Standard besitzt. Obgleich der <strong>openEHR</strong>-Ansatz und dessen<br />
Vorläufer im vergangenen Jahrzehnt mehrfach im<br />
klinischen Bereich erprobt wurden, konnte jedoch bisher<br />
eine Eignung für den produktiven Einsatz nicht nachgewiesen,<br />
allerdings auch nicht widerlegt werden. Die<br />
nicht unerhebliche Überarbeitung des ursprünglichen<br />
ENV 13606 in Richtung <strong>openEHR</strong>-Konzept stellt darüber<br />
hinaus die Abwärtskompatibilität des zukünftigen EN<br />
13606 in Frage.<br />
Die Modellierung von Archetypen und damit die Erstellung<br />
einer gemeinsamen Begriffsbibliothek ist aufwändig.<br />
Der Archetyp für das vergleichsweise einfache Konzept<br />
einer Blutdruckmessung umfasst in der derzeitigen<br />
Form bereits 529 Codezeilen. Eine umfangreiche Archetypen-Bibliothek<br />
ist aber für den produktiven klinischen<br />
Einsatz notwendig und erfordert also zunächst aufwändige<br />
Vorleistungen. Mit <strong>openEHR</strong> soll allerdings keine<br />
Ontologie erstellt werden. Vielmehr sieht die Architektur<br />
vor, die modellierten Datenstrukturen mit Ontologien zu<br />
verknüpfen.<br />
Vergleicht man <strong>openEHR</strong> mit dem Ansatz der HL7 Clinical<br />
Document Architecture [8], erscheint Letzterer intuitiv<br />
besser fassbar. Im klinischen Bereich wird seit jeher<br />
dokumentenorientiert gedacht und gearbeitet, während<br />
sich Begriffe und Wissen nur schwer greifbar allein in den<br />
Köpfen manifestieren. Erstellung und Handhabung von<br />
Archetypen durch den Kliniker würde daher ein Umdenken<br />
erfordern, aber möglicherweise auch die Reflexion<br />
über das eigene Begriffssystem anregen und vielleicht<br />
auch dadurch zu einer besseren Dokumentation führen.<br />
Weiterhin muss man sich die Frage stellen, ob Informationen<br />
der Patientenakte wirklich auf internationaler<br />
Ebene austauschbar, ja sogar an jedem Ort der Welt durch<br />
die Verknüpfungen zu Ontologien interpretierbar sein<br />
müssen. Grundsätzliche Fragen zum Informationsaustausch<br />
auf regionaler Ebene, wie z.B. Sicherheit, Patientenvertrag,<br />
eindeutige Patientenidentifikation und klinische<br />
Pfade, werden durch <strong>openEHR</strong> nur am Rande oder<br />
gar nicht betrachtet. Von der Beantwortung derartiger<br />
Fragen hängt aber der Aufbau einer Informationsinfrastruktur<br />
im Gesundheitswesen zurzeit vorrangig ab. Auch<br />
der angestrebte OpenSource-Charakter des <strong>openEHR</strong>-<br />
Ansatzes widerspricht der Realität heutiger klinischer<br />
Informationssysteme, deren Landschaft dominiert wird<br />
durch wenige große Firmen, die zwar nicht unbedingt<br />
innovative Lösungen schaffen, dafür aber einen effektiven<br />
Einsatz ihrer Software garantieren.<br />
Die Plattform der <strong>openEHR</strong> Community bietet jedoch<br />
das Potenzial, auch im Bereich der Gesundheitssoftware<br />
von der Produktivität und dem Engagement eines Open-<br />
Source-Projekts zu profitieren. Schließlich beteiligen sich<br />
über diese Plattform an der Entwicklung viele renommierte<br />
Spezialisten mit langjähriger Erfahrung, und auch<br />
die Nutzer erhalten die Möglichkeit zur Einflussnahme.<br />
Für die Modellierung klinischer Terminologie gibt es keine<br />
bessere Alternative, als sie durch die klinischen Nutzer<br />
selbst durchführen zu lassen und die resultierenden Konzepte<br />
der Gemeinschaft zur Diskussion zu stellen. Es bleibt<br />
allerdings abzuwarten, ob die <strong>openEHR</strong>-Konzepte einerseits<br />
ausreichen, um in Ansätzen komplexes medizinisches<br />
Wissen auf Datenstrukturen abzubilden und andererseits<br />
einfach genug sind, um implementierbar und<br />
nutzbar zu bleiben.<br />
Literatur<br />
[1] <strong>openEHR</strong>-Architekturspezifikation: http://www.openehr.org/<br />
[2] Bird L., Goodchild A., Tun Z. Experiences with a Two-Level Modelling<br />
Approach to Electronic Health Records. J Res Prac Inf Tech. 2003; 35:<br />
121–38.<br />
[3] Rogers J, Roberts A, Solomon D, van der Haring E, Wroe C, Zanstra P,<br />
Rector A. GALEN ten years on: tasks and supporting tools. Medinfo. 2001;<br />
10(Pt 1): 256–60.<br />
[4] Dean M, Connolly D, van Harmelen F, Hendler J, Horrocks I, McGuinness<br />
DL, Patel-Schneider PF, Stein LA. OWL Web Ontology Language 1.0<br />
Reference, July 2002. http://www.w3.org/TR/owl-ref/.<br />
[5] Genesereth, M. et. al. (1998), »Knowledge Interchange Format« Draft<br />
proposed American National Standard (dpANS), NCITS.T2/98-004.<br />
[6] Hayes P, Menzel C. A semantics for the knowledge interchange format.<br />
Proceedings of IJCAI 2001 Workshop on the IEEE Standard Upper<br />
Ontology, Aug. 2001.<br />
[7] Beale T. Archetypes and the EHR. Stud Health Technol Inform. 2003;<br />
96: 238–44.<br />
[8] Dolin RH, Alschuler L, Beebe C et al. The HL7 Clinical Document<br />
Architecture. J Am Med Inform Assoc. 2001; 8: 552–69.<br />
[9] Grimson J, Stephens G, Jung B, Grimson W, Berry D, Pardon S. Sharing<br />
Health-Care Records over the Internet. IEEE Internet Computing. 2001;<br />
5: 49–58.<br />
[10] Goodchild A, Gibson K, Anderson L, Bird L. The Brisbane Southside<br />
HealthConnect Trial: Preliminary Results. HIC. 2004.<br />
Forum der Medizin_Dokumentation und Medizin_<strong>Informatik</strong> 1/2005<br />
15