openEHR

openEHR ist eine offene Standardspezifikation in der medizinischen Informatik , die die Verwaltung, Speicherung, den Abruf und den Austausch von Gesundheitsdaten in elektronischen Patientenakten (EHRs) beschreibt. In openEHR werden alle Gesundheitsdaten einer Person in einer einzigen, herstellerunabhängigen und personenzentrierten EHR gespeichert – eine einmalige Speicherung. Die openEHR-Spezifikationen beinhalten eine Spezifikation für EHR-Extraktion ^{[ 1 ]} , befassen sich ansonsten aber nicht primär mit dem Datenaustausch zwischen EHR-Systemen, da dies im Fokus anderer Standards wie EN 13606 und HL7 steht .

Die openEHR-Spezifikationen werden von der openEHR Foundation gepflegt, einer gemeinnützigen Stiftung, die die offene Forschung, Entwicklung und Implementierung von openEHR-EHR-Systemen fördert. Die Spezifikationen basieren auf 15 Jahren europäischer und australischer Forschung und Entwicklung im Bereich EHR-Systeme und neuer Paradigmen, darunter die sogenannte Archetypen-Methodik ^{[ 2 ] [ 3 ]} zur Inhaltsspezifikation.

Die openEHR-Spezifikationen ^{[ 4 ]} umfassen Informations- und Servicemodelle für die elektronische Patientenakte (EHR), demografische Daten, klinische Arbeitsabläufe und Archetypen . Sie sind als Grundlage für eine medizinisch-rechtlich einwandfreie, verteilte und versionierte EHR-Infrastruktur konzipiert.

Die Architektur der openEHR-Spezifikationen als Ganzes besteht aus folgenden Schlüsselelementen:

• Informationsmodelle (auch „Referenzmodell“ genannt);
• der Archetypenformalismus;
• die portable Archetyp-Abfragesprache;
• Servicemodelle / APIs.

Die Verwendung der ersten beiden ermöglicht die Entwicklung von „Archetypen“ und „Vorlagen“. Diese formalen Modelle klinischer und verwandter Inhalte bilden eine eigene Ebene von De-facto -Standards, die weitaus zahlreicher sind als die Basisspezifikationen, auf denen sie aufbauen. Die Abfragesprache ermöglicht es, Abfragen auf Basis der Archetypen anstatt physischer Datenbankschemata zu erstellen und entkoppelt so Abfragen von Details der physischen Persistenz. Die Servicemodelle definieren den Zugriff auf wichtige Backend-Dienste, darunter den EHR-Dienst und den Demografie-Dienst. Für den Anwendungszugriff wird eine wachsende Anzahl schlanker, REST-basierter APIs verwendet, die auf Archetyppfaden basieren.

Die openEHR-Architekturübersicht bietet eine Zusammenfassung der Architektur und der detaillierten Spezifikationen. ^{[ 5 ]}

A central part of the openEHR specifications is the set of information models, known in openEHR as 'reference models'.^[6] The models constitute the base information models for openEHR systems, and define the invariant semantics of the Electronic Health Record (EHR), EHR Extract, and Demographics model, as well as supporting data types, data structures, identifiers and useful design patterns.

Some of the key classes in the EHR component are the ENTRY classes, whose subtypes include OBSERVATION, EVALUATION, INSTRUCTION, ACTION and ADMIN_ENTRY, as well as the Instruction State Machine, a state machine defining a standard model of the lifecycle of interventions, including medication orders, surgery and other therapies.

A key innovation in the openEHR framework is to leave all specification of clinical information out of the information model (also known as "reference model") and instead to provide a powerful means of expressing definitions of the content clinicians and patients need to record that can be directly consumed at runtime by systems built on the Reference Model. This is justified by the need to deal scalably with the generic problem in health of a very large, growing, and ever-changing set of information types.^[7]

Clinical content is specified in terms of two types of artefact which exist outside the information model. The first, known as "archetypes" provides a place to formally define re-usable data point and data group definitions, i.e. content items that will be re-used in numerous contexts. Typical examples include "systemic arterial blood pressure measurement" and "serum sodium". Many such data points occur in logical groups, e.g. the group of data items to document an allergic reaction, or the analytes in a liver function test result. Some archetypes contain numerous data points, e.g. 50, although a more common number is 10–20. A collection of archetypes can be understood as a "library" of re-usable domain content definitions, with each archetype functioning as a "governance unit", whose contents are co-designed, reviewed and published.

Die zweite Art von Artefakt wird in openEHR als „Vorlage“ bezeichnet und dient der logischen Darstellung eines anwendungsfallspezifischen Datensatzes, beispielsweise der Datenelemente eines Patientenentlassungsberichts oder eines radiologischen Befundes. ^{[ 8 ]} Eine Vorlage wird erstellt, indem relevante Elemente aus verschiedenen Archetypen referenziert werden. Eine Vorlage benötigt möglicherweise nur ein oder zwei Datenpunkte oder -gruppen aus jedem Archetyp. Technisch gesehen dürfen openEHR-Vorlagen die Semantik der Archetypen, aus denen sie erstellt wurden, nicht verletzen. Vorlagen werden fast immer für den lokalen Gebrauch von Softwareentwicklern und klinischen Analysten erstellt. Sie werden typischerweise für GUI- Bildschirmformulare, Nachrichtendefinitionen und Dokumentdefinitionen definiert und entsprechen somit „operativen“ Inhaltsdefinitionen.

Die beiden Modellebenen oberhalb des Informationsmodells rechtfertigen dies: Bestehen Datensatzdefinitionen aus vordefinierten Datenpunkten einer Bibliothek solcher Definitionen, so sind alle erfassten Daten (d. h. Instanzen von Vorlagen) letztendlich Instanzen der Standardinhaltsdefinitionen. Dies bildet die Grundlage für standardisierte Abfragen. Ohne die Ebene der Archetypen-„Bibliothek“ ist jeder Datensatz (d. h. jeder operative Inhaltsblock) eindeutig definiert, und ein standardisierter Abfrageansatz ist schwierig.

Dementsprechend definiert openEHR eine auf Archetypen basierende Abfragemethode, bekannt als AQL (Archetype Querying Language). ^{[ 9 ]}

Insbesondere wurde openEHR zur Modellierung gemeinsamer Behandlungspläne verwendet. Die Archetypen wurden so gestaltet, dass sie die Konzepte des gemeinsamen Behandlungsplans berücksichtigen. ^{[ 10 ]}

Obwohl sich die Inhalte einzelner Gesundheitsakten stark unterscheiden können, entsprechen die Kerninformationen in openEHR-Dateninstanzen stets Archetypen. Dies geschieht durch die Erstellung von Archetypen, die klinische Informationen auf eine Weise ausdrücken, die hochgradig wiederverwendbar und in manchen Fällen sogar universell ist. ^{[ 11 ]}

Die Archetypen von openEHR werden in der „Archetype Definition Language“ (ADL), einer öffentlichen Spezifikation von openEHR, ausgedrückt. Es sind zwei Versionen verfügbar: ADL 1.4 ^{[ 12 ]} und ADL 2 ^{[ 13 ]} , eine neue Version mit verbesserter Unterstützung für Spezialisierung, Neudefinition und Annotationen sowie weiteren Verbesserungen ^{[ 14 ]} . Die Version 1.4 von ADL und ihr Gegenstück, das Objektmodell Archetype Object Model (AOM), bilden die Grundlage für den CEN- und ISO-Standard „Archetype Definition Language“ ( ISO-Standard 13606-2 ) ^{[ 15 ]} .

Traditionell wurden Templates in einem einfachen, de facto branchenweit verbreiteten XML-Format entwickelt, bekannt als „.oet“, benannt nach der Dateiendung. ^{[ 16 ]} ADL 2 definiert eine Möglichkeit, Templates mithilfe von Erweiterungen der ADL-Sprache nahtlos mit Archetypen auszudrücken. ^{[ 17 ]}

Es wurden verschiedene Prinzipien für die Entwicklung von Archetypen identifiziert. ^{[ 18 ]} Beispielsweise muss ein Satz von openEHR-Archetypen einem Qualitätsmanagement unterzogen werden, um die Einhaltung mehrerer Axiome, wie etwa der gegenseitigen Ausschließlichkeit, sicherzustellen. Die Archetypen können unabhängig von Softwareimplementierungen und Infrastruktur in den Händen von Klinikergruppen verwaltet werden, um sicherzustellen, dass sie den tatsächlichen Bedürfnissen in der Praxis entsprechen. Archetypen sind so konzipiert, dass sich die Spezifikation klinischen Wissens im Laufe der Zeit weiterentwickeln kann. Herausforderungen bei der Implementierung von Informationsdesigns in openEHR konzentrieren sich darauf, inwieweit die tatsächlichen Systembeschränkungen mit dem Informationsdesign übereinstimmen.

Im Bereich der elektronischen Patientenakten existieren mehrere Informationsmodelle mit sich überschneidenden Anwendungsbereichen, die schwer zu handhaben sind, beispielsweise zwischen HL7 V3 und SNOMED CT . Der openEHR-Ansatz steht vor Harmonisierungsherausforderungen, sofern er nicht isoliert angewendet wird. ^{[ 19 ]}

Dem openEHR-Ansatz folgend, würde die Verwendung gemeinsam genutzter und global verwalteter Archetypen sicherstellen, dass openEHR-Gesundheitsdaten unabhängig vom technischen, organisatorischen und kulturellen Kontext einheitlich bearbeitet und angezeigt werden können. Dieser Ansatz bedeutet auch, dass die von jedem EHR-System verwendeten Datenmodelle flexibel sind, da neue Archetypen definiert werden können, um zukünftigen Anforderungen der klinischen Dokumentation gerecht zu werden. Jüngste Arbeiten in Australien haben gezeigt, wie Archetypen und Vorlagen die Nutzung bestehender Gesundheitsdaten und Nachrichten in einem openEHR-System erleichtern und standardisierte Nachrichten und CDA-Dokumente ausgeben können.

Die Aussicht auf eine Einigung über die Gestaltung und die Formen der Steuerung auf internationaler Ebene bleibt spekulativ, da die Einflüsse von den unterschiedlichen medizinisch-rechtlichen Rahmenbedingungen über kulturelle Unterschiede bis hin zu technischen Unterschieden reichen, wie beispielsweise dem Umfang, in dem eine klinische Referenzterminologie integraler Bestandteil sein soll.

Das openEHR-Framework ist mit dem Electronic Health Record Communication Standard ( ISO 13606 ) konsistent, und das Archetype Object Model 2 (AOM2) wurde von ISO TC 215 offiziell als Entwurfsspezifikation für die Revision 2017 von ISO 13606:2 akzeptiert.

Die openEHR-Archetypen werden von der National e-Health Transition Authority of Australia, dem britischen NHS Health and Social Care Information Centre (HSCIC), der norwegischen Nasjonal IKT Organisation, dem katalanischen Gesundheitsdienst (CatSalut) und dem slowenischen Gesundheitsministerium verwendet.

openEHR wurde als Grundlage für die standardisierte elektronische Patientenakte in Brasilien ausgewählt. ^{[ 20 ]}

Es wird zunehmend in kommerziellen Lösungen auf der ganzen Welt eingesetzt, darunter auch in solchen, die von den openEHR Industry Partners entwickelt wurden.

Ein Ergebnis des openEHR-Modellierungsansatzes ist die offene Entwicklung von Archetypen, Vorlagen und Terminologie-Teilmengen zur Darstellung von Gesundheitsdaten. Dank der offenen Natur von openEHR sind diese Strukturen öffentlich verfügbar und können in Gesundheitsinformationssystemen verwendet und implementiert werden. Nutzer können diese Strukturen in einem kollaborativen Repository, dem Clinical Knowledge Manager (CKM), teilen, diskutieren und genehmigen. CKM wurde von Ocean Informatics Pty Ltd entwickelt . Einige aktuell verwendete openEHR CKMs:

• International openEHR CKM
• Norwegisches nationales IKT-CKM
• Katalanischer Gesundheitsdienst (CatSalut) CKM
• German HighMED CKM

Das von Apperta betriebene UK CKM ist seit dem 1. November 2024 ausgesetzt . Die klinischen Modelle sind über deren GitHub-Repository zugänglich.

• Archetyp (Informationswissenschaft)
• Europäisches Institut für Gesundheitsdaten
• Elektronische Gesundheitsdatenkommunikation ( ISO / CEN EN 13606 - EHRcom)
• Gesundheitsstufe 7
• Schnelle Ressourcen zur Interoperabilität im Gesundheitswesen (FHIR)
• Architektur von Gesundheitsinformatikdiensten (HISA)
• HIPAA
• ProRec
• SNOMED CT

• Offizielle Website