D I P L O M A R B E I T

Transkript

1 D I P L O M A R B E I T Semantische Interoperabilität im elektronischen Gesundheitsdatenaustausch mittels Dualer Modellierung: Der HL7 Template Ansatz Ausgeführt am Institut für Medizinische Informations- und Auswertesysteme der Medizinischen Universität Wien für die Technische Universität Wien Unter der Anleitung von Ao. Univ.-Prof. Dipl.-Ing. Dr. Georg Duftschmid durch Karl Bointner, Bakk.techn. Saarplatz 20/5/ Wien

2 Kurzfassung Durch die zunehmende Spezialisierung der modernen Medizin gewinnt die fachübergreifende Kooperation von Gesundheitsdienstleistern in der Behandlung gemeinsamer Patienten zunehmend an Bedeutung. Eine wesentliche Voraussetzung für die Effizienz einer derartigen integrierten Versorgung ist der elektronische Austausch von Gesundheitsdaten zwischen den beteiligten Akteuren. Um die übermittelten Daten empfängerseitig maschinell weiterverarbeiten zu können, muss der Datenaustausch auf semantisch interoperabler Basis erfolgen. Die Duale Modellierung ist eine in der Fachwelt viel zitierte Technik für einen semantisch interoperablen Gesundheitsdatenaustausch. Neben der bereits relativ ausgereiften Anwendung der Dualen Modellierung in Form des sogenannten Archetyp -Ansatzes arbeitet die amerikanische Standardisierungsorganisation HL7 seit einigen Jahren an einem ähnlichen Konzept, dem Template -Ansatz. Der Template-Ansatz wird in der Fachliteratur zwar regelmäßig genannt, wurde bisher hinsichtlich seiner Methodik, üblicherweise mit Verweis auf den unfertigen Zustand der Arbeiten, jedoch nur oberflächlich beschrieben. Ziel dieser Arbeit ist es, den Anwendungsbereich von HL7 Templates sowie den aktuellen Entwicklungsstand der zugrunde liegenden Methodik zu beleuchten. Zu diesem Zweck wird nach einem Überblick über die Technik der Dualen Modellierung die kürzlich von HL7 publizierte Spezifikation des Template-Ansatzes dargestellt. Weiters werden drei im internationalen Gesundheitsdatenaustausch bereits praktisch erprobte Implementierungsleitfäden von auszutauschenden medizinischen Dokumenten, welche bisher ein ähnliches Ziel verfolgten wie künftig die HL7 Templates, auf Basis eines einheitlichen Kriterienkatalogs analysiert und der aktuellen Template- Methodik gegenüber gestellt. Die Arbeit schließt mit einem Vergleich des Template-Ansatzes mit dem bereits erwähnten Archetyp-Ansatz, wobei hierfür das HL7 Template Modell und das Archetyp Objekt Modell gegenübergestellt werden. i

3 Inhaltsverzeichnis KURZFASSUNG... I INHALTSVERZEICHNIS... II 1 EINLEITUNG THEORETISCHE GRUNDLAGEN INTEROPERABILITÄT Technische Interoperabilität Semantische Interoperabilität Prozess Interoperabilität DUALE MODELLIERUNG VON GESUNDHEITSINFORMATION DIE STANDARDISIERUNGSORGANISATION HEALTH LEVEL Das Reference Information Model Der Standard HL7 Version Clinical Document Architecture Release DAS HL7 TEMPLATE STAND DER FORSCHUNG ARCHITEKTUREN VON GESUNDHEITSINFORMATIONS-SYSTEMEN, DIE AUF MULTIPLEN MODELLEN BERUHEN IMPLEMENTIERUNGSASPEKTE VON ARCHETYPEN UND TEMPLATES METHODEN ERGEBNISSE ERGEBNISSE DER ANALYSEPLANUNG ERGEBNISSE DER INFORMATIONSBESCHAFFUNG ERGEBNISSE DER MODELLIERUNG UND DER VERIFIKATION Der Implementierungsleitfaden VHitG Arztbrief Der Leitfaden Continuity of Care Document (CCD) Der Electronic Medical Summary Clinical Document Architecture Implementation Guide GEGENÜBERSTELLUNG VON HL7 TEMPLATES UND CEN ARCHETYPEN DISKUSSION ZUSAMMENFASSUNG UND AUSBLICK ii

4 DANKSAGUNG ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS CODE-BEISPIEL-VERZEICHNIS LITERATURVERZEICHNIS ANHANG iii

5 1 EINLEITUNG 1 Einleitung Informationssysteme im Gesundheitswesen müssen heutzutage immer komplexere Anforderungen bewältigen, die durch eine höhere Qualität der Systeme und optimierte Technologien abgedeckt werden müssen. Die Umstellung von der traditionellen Papierdokumentation auf elektronische Dokumentationssysteme hat zur Folge, dass immer größere Datenmengen entstehen, welche entsprechend aufbereitet und gespeichert werden müssen. Diese Daten sind meist nur bestimmten Einrichtungen oder Instituten zugänglich, da im Bereich der medizinischen Informations- und Dokumentationssysteme proprietäre Formate zur Speicherung der Daten verwendet werden, die untereinander oftmals nicht kompatibel sind. Die Integration von einheitlichen Standards in medizinische Informationssysteme ist ein Ziel, das erreicht werden muss, um Patientendaten zwischen unterschiedlichen Gesundheitsdienstleistern austauschen zu können und für autorisierte Personen verfügbar zu machen. Electronic Health Records (EHRs) stellen die moderne Form von elektronischen Patientenakten dar, deren Integration in das Gesundheitssystem in den letzten Jahren ausgiebig diskutiert wurde. Ein EHR repräsentiert laut International Organization for Standardization (ISO 1 ) einen Behälter für Information, bezugnehmend auf den Gesundheitszustand eines Patienten, in computerverarbeitbarer Form [1, 2, 3]. In [4, 5] werden EHRs hierarchisch in fünf Stufen gegliedert: Automated Record: Enthält Patienteninformationen für administrative Zwecke und kann daher als Archivverwaltungssystem angesehen werden. Computerised Medical Record: Enthält alle patientenbezogenen Dokumente, jedoch meist nur in gescannter Form

6 1 EINLEITUNG Electronic Medical Record: Entspricht einer strukturierten medizinischen Dokumentation einer Einrichtung. Electronic Patient Record: Enthält die Summe aller Electronic Medical Records und entspricht daher einer einrichtungsübergreifenden medizinischen Gesamtdokumentation. Electronic Health Record: Entspricht einer lebensbegleitenden Gesundheitsakte eines Patienten (EHR), welche zusätzlich Eintragungen paramedizinischer Einrichtungen und vom Patienten selbst beinhaltet. In Österreich wurde im Jahr 2006 unter dem Titel ELGA 2 mit der Umsetzung eines EHR-Systems auf nationaler Ebene begonnen [6]. Die Arge-ELGA 3 hat diesbezüglich eine Machbarkeitsstudie [7] durchgeführt, die Detailplanung finalisiert und eine Studie zur Kosten/Nutzen-Analyse in Auftrag gegeben. Die Einführung von EHRs soll in Zukunft zahlreiche Vorteile mit sich bringen, wie z.b. eine Verringerung des finanziellen und organisatorischen Aufwands für Gesundheitsdienstleister medizinische Entscheidungsunterstützung Warnungen in Echtzeit, die medizinische Wechselwirkungen anzeigen Vermeidung von Mehrfacherhebungen medizinischer Daten Um den Anforderungen eines EHR-Systems gerecht werden zu können, müssen einheitliche Standards eingesetzt werden, durch die heterogene Informationssysteme miteinander kommunizieren können und ein sicherer Datenaustausch erfolgen kann. 2 Elektronische Gesundheitsakte 3 Arbeitsgemeinschaft Elektronische Gesundheitsakte, 2

7 1 EINLEITUNG In diesem Bereich haben sich vor allem die Standards von HL7 4, openehr 5, und CEN 6 etabliert, die teilweise ähnliche Ziele verfolgen und auf Interoperabilität (siehe Kapitel 2.1) setzen. Derzeit sind verschiedene Harmonisierungsbestrebungen im Gange, die die Stärken der verschiedenen Ansätze vereinen sollen. Interoperabilität ist ein wichtiger Grundsatz, der in Zukunft durch EHR- Systeme abgedeckt werden muss. Zur Aufbereitung der medizinischen Information in EHR-Systemen bietet sich ein relativ neues Konzept an, das Information und Wissen voneinander trennt die Duale Modellierung [2, 3, 8, 9]. In der Praxis kann die Duale Modellierung durch Archetypen umgesetzt werden, die dynamische Konzepte auf Wissensebene repräsentieren (siehe Kapitel 2.2). Neben dem von openehr entwickelten und in der Norm EN/ISO festgeschriebenen Archetypen-Konzept stellt der HL7 Template Ansatz eine weitere wichtige Anwendung der Dualen Modellierung von Daten des Gesundheitswesens dar. Das Konzept der Templates wird in der Literatur seit Jahren als konzeptueller Baustein des HL7 Version 3 Standards zitiert [10, 11, 12, 13, 14], eine detaillierte Erläuterung der Methodik fehlt dabei jedoch bisher, wobei üblicherweise auf die nicht abgeschlossene Entwicklung verwiesen wird. Ziel dieser Arbeit ist es, den Anwendungsbereich von HL7 Templates sowie den aktuellen Entwicklungsstand des zugrunde liegenden Frameworks zu beleuchten. Zu diesem Zweck werden die Implementierungsleitfäden VHitG Arztbrief für das deutsche Gesundheitswesen, Continuity of Care Document (CCD) und Electronic Medical Summary (e-ms), welche spezifische Anwendungen des generischen CDA-Modells darstellen und auf HL7 Templates basieren, mittels eines einheitlichen Kriterienkatalogs

8 1 EINLEITUNG analysiert. Nach einer Darstellung des aktuellen Standes der Template- Framework-Spezifikation von HL7 werden die genannten Implementierungsleitfäden der Spezifikation gegenübergestellt und untersucht, inwieweit diese mit der Spezifikation kompatibel sind. Die Analyse des HL7 Template Ansatzes wird weiters ergänzt durch einen Vergleich mit dem Archetyp Ansatz der Norm EN/ISO

9 2 THEORETISCHE GRUNDLAGEN 2 Theoretische Grundlagen 2.1 Interoperabilität Unter Interoperabilität versteht man die Möglichkeit von Systemen oder (Software-)Produkten, miteinander kommunizieren zu können [1]. Im Besonderen bedeutet das, dass Daten zwischen zwei oder mehreren (Computer-)Systemen ausgetauscht werden können bzw. dass unterschiedliche Programme ihre Datenformate und Protokolle gemeinsam verwenden können. Der Begriff Interoperabilität hat sich in den letzten Jahren in vielen Bereichen der Technik und Industrie angesiedelt. Im medizinisch-technischen Kontext spielt die Interoperabilität eine immer größer werdende Rolle. Eine optimale Patientenversorgung erfordert, dass Krankenhaus-Informationssysteme problemlos miteinander kommunizieren und die ausgetauschten Daten und Informationen auch anwenden können. Das Institute of Electrical and Electronics Engineers (IEEE-USA 7 ) sieht die Interoperabilität als einen entscheidenden und kritischen Punkt bei der Implementierung von Informationstechnologie in bestehende Gesundheitssysteme [15]. Auch in den Bereichen Telekommunikation, Software und öffentliche Sicherheit wird Interoperabilität immer mehr in den Vordergrund gerückt. Im Web finden sich unzählige Definitionen von Interoperabilität. Die HL7 EHR Interoperability Work Group hat den Begriff hierarchisch strukturiert und in 3 Bereiche eingeteilt [16]: Technische Interoperabilität Semantische Interoperabilität Prozess Interoperabilität In den folgenden Kapiteln sollen diese drei Begriffe näher erläutert werden

10 2 THEORETISCHE GRUNDLAGEN Technische Interoperabilität Wenn im technischen Kontext von Interoperabilität gesprochen wird, ist oft die verbreitete Form der technischen Interoperabilität gemeint, die in der Literatur auch unter dem Begriff Funktionale Interoperabilität bekannt ist. Diese Form repräsentiert die niedrigste Stufe der Hierarchie und bezieht sich hauptsächlich auf die Hardware bzw. auf Hardware-bezogene Aspekte. Technische Interoperabilität bedeutet, dass zwei oder mehrere Systeme die Fähigkeit besitzen, Daten auszutauschen, die einem Nutzen zugeführt werden können und menschenlesbar sein müssen. Das Verstehen der Bedeutung der Information und die erfolgreiche Verarbeitung beim empfangenden System kann durch technische Interoperabilität nicht abgedeckt werden. Sie ist jedoch eine Notwendigkeit, um Daten und Information erfolgreich von System zu System transferieren zu können und dadurch deren räumliche Trennung zu überwinden Semantische Interoperabilität Diese zweite Stufe der Interoperabilität bedeutet, dass die empfangenen Daten auch maschinell sinnvoll genutzt und verarbeitet werden können. Bezogen auf Computersysteme heißt semantische Interoperabilität also, dass die Information vom empfangenden System richtig interpretiert wird und daraus ein sinnvolles Ergebnis generiert werden kann. Um eine effektive und sichere Patientenversorgung garantieren zu können, wird diese Stufe in Zukunft anzustreben sein. Semantische Interoperabilität wird in erster Linie durch die Anwendung von Klassifikationssystemen (z.b. ICD 8 ) und Nomenklaturen (z.b. SNOMED CT 9 [17]) erzielt. Dadurch können computerverwertbare Informationen bereitgestellt werden und mit Hilfe von Archetypen (siehe Kapitel 2.2) und Templates (siehe Kapitel 2.4) Strukturvorgaben erzielt werden, die direkt vom System verarbeitet werden können. 8 International Classification of Diseases 9 Systemized Nomenclature of Medicine -- Clinical Terms 6

11 2 THEORETISCHE GRUNDLAGEN Die ISO definiert vier Voraussetzungen zur Realisierung von semantischer Interoperabilität [1], wobei die ersten beiden auch für technische Interoperabilität erforderlich sind: a) Ein standardisiertes EHR Referenzmodell, das Sender und Empfänger der Information gemeinsam verwenden. b) Ein standardisiertes Service-Schnittstellen-Modell, um die Interoperabilität zwischen dem EHR Service und anderen Diensten (z.b. Terminologie und Sicherheitsdienst in einem klinischen Informationssystem) zu gewährleisten. c) Eine Menge an standardisierten domänenspezifischen Konzept- Modellen (z.b. Templates, siehe Kapitel 2.4). d) Standardisierte Terminologien (zur Unterstützung der Templates) Prozess Interoperabilität Diese dritte Stufe der Interoperabilität beschäftigt sich mit Arbeitsprozessen und deren Ablauf. Sie setzt voraus, dass die Daten erfolgreich übermittelt wurden (technische Interoperabilität) und diese vom System auch erfasst und verstanden wurden (semantische Interoperabilität). Sie wurde definiert, um Sicherheit und Qualität speziell im Gesundheitswesen zu garantieren. Dieser Ansatz enthält Methoden, die zur erfolgreichen Integration von Computersystemen in bestimmten Arbeitssituationen herangezogen werden können. Folgende Ziele werden damit verfolgt [16]: Eine explizite Nutzerrollen-Spezifikation Ein benutzerfreundliches Mensch-Maschine-Interface Datenrepräsentation und Datenfluss unterstützen die Arbeitssituation Ein ausgereiftes Arbeitsdesign Effektivität im jeweiligen Einsatz 7

12 2 THEORETISCHE GRUNDLAGEN Bezugnehmend auf das Gesundheitswesen koordiniert die Prozess Interoperabilität die Arbeitsprozesse insofern, als dass die übermittelte Information in einer zeit-, ablauf- und sequenzorientierten Weise erfolgen kann und somit die Patientenversorgung effizient und sicher durchgeführt werden kann. 2.2 Duale Modellierung von Gesundheitsinformation Informationssysteme werden heutzutage in verschiedensten Bereichen eingesetzt, stellen Information und Wissen bereit und bieten Mechanismen an, die eine effiziente und zielorientierte Nutzung der Daten ermöglichen. Finanzielle Aspekte, kürzere Entwicklungszeit und eine einfachere Implementierung sind einige der Motive aufgrund derer viele Informationssysteme auf so genannten singulären Modellen (Single-Level Approach) [8, 9] aufbauen. Dieser Ansatz bedeutet, dass Information und Wissen auf eine Ebene gestellt werden und die Modelle hard-coded in Software und Datenbank integriert werden. Diese direkte Implementierung hat zur Folge, dass umfangreiche und komplexe Systeme große Klassenmodelle und Datenbanken produzieren und dadurch Änderungen und Erweiterungen schwer durchzuführen sind und eine Stabilität des Informationssystems nicht garantiert werden kann. Gesundheitsinformationssysteme stellen einige Ansprüche, die durch Systeme, die auf single-level-modellen basieren, nicht oder nur teilweise abgedeckt werden können. Dynamische Systemkomponenten und das Streben nach semantischer Interoperabilität verlangen einen flexibleren Ansatz [18]. Der Dual Model Approach der Ansatz der Dualen Modellierung soll den Erfordernissen moderner Gesundheitsinformationssysteme gerecht werden und wurde von Thomas Beale vorgestellt [8, 9]. Der Ansatz geht davon aus, dass Information und Wissen semantisch voneinander getrennt werden. Die Idee einer dual-level Methodologie wurde später vom Europäischen Normungsinstitut in dessen 8

13 2 THEORETISCHE GRUNDLAGEN Standards übernommen. Die Ebenen der dualen Modellierung sind folgendermaßen definiert: Informationsebene: Repräsentiert den generischen Teil und wird in der Praxis durch ein Referenzmodell (siehe Kapitel 2.3.1) dargestellt. Information enthält Aussagen über einen bestimmten Sachverhalt oder eine bestimmte Entität und bezieht sich nur auf eine bestimmte Person. Wissensebene: Repräsentiert den dynamischen Teil und wird in der Praxis durch Archetypen [8] repräsentiert. Wissen beinhaltet Aussagen, die allen Entitäten einer Klasse entsprechen. Wissen kann z.b. aus einer medizinischen Datenbank abgerufen werden und ist auf alle Personen anwendbar. Der Begriff Archetyp wurde definiert, um Modelle auf Basis der Wissensebene zu beschreiben. Archetypen sind Strukturen, die Einschränkungen auf Instanzen eines Referenzmodells definieren und verfolgen laut [9] folgende Ziele: Den Nutzern einer Domäne soll die Formulierung ihrer eigenen Konzepte ermöglicht werden. Informationssysteme sollen Benutzereingaben während der Erstellung und Modifizierung von Information leiten und validieren können und gewährleisten, dass alle Instanzen der Information den Erfordernissen der Domäne entsprechen. Interoperabilität soll auf Wissensebene gewährleistet werden. Es soll eine eindeutige Basis geschaffen werden, um komplexe Daten effizient abfragen zu können. In Abbildung 1 werden die Ebenen der dualen Modellierung grafisch dargestellt und in Beziehung gesetzt. 9

14 2 THEORETISCHE GRUNDLAGEN Informationsebene Wissensebene Referenzmodell Archetypobjektmodell Einschränkungen Instanz Instanz Einschränkungen Information Archetyp Abbildung 1: Archetyp-Modell Meta-Architektur, übernommen aus [9] Auf Informationsebene wird ein Referenzmodell definiert, das Struktur und Semantik der Information darstellt. Die Beziehung zwischen Referenzmodell und Informations-Objekt kann mit der üblichen objektorientierten Klassen- Objekt-Beziehung verglichen werden, wobei Information eine Instanz des Referenzmodells darstellt. Auf Wissensebene werden Archetypen definiert, die Struktur und Semantik der Information einschränken. Archetypen haben ein eigenes formales Modell (siehe Abbildung 1 rechts oben) bzw. eine eigene Sprache die Archetype Definition Language (ADL) [19, 20]. 10

15 2 THEORETISCHE GRUNDLAGEN 2.3 Die Standardisierungsorganisation Health Level 7 Die Organisation Health Level 7 (HL7) wurde 1987 gegründet und hat ihren Hauptsitz in Ann Arbor (Michigan, USA). Das Unternehmen wurde vom American National Standards Institute (ANSI) als Standards Developing Organization (SDO) akkreditiert und hat die Mission Standards für das Gesundheitswesen zu entwickeln, um die Gesundheitsversorgung zu verbessern, deren Abläufe zu optimieren und den Transfer von Wissen zu steigern. Viele von HL7 entwickelte Standards werden im Gesundheitswesen intensiv genutzt. Level 7 bezieht sich auf das von der ISO zertifizierte Kommunikationsmodell für Open Systems Integration (OSI) [21, 22]. Dieses Modell ist in sieben Ebenen gegliedert, wobei die ersten vier Stufen zusammengefasst die Kommunikationsebene repräsentieren. Von der fünften bis zur siebenten Stufe spricht man von der Funktionalitätsebene. Level 7 repräsentiert die oberste Ebene der Integration, nämlich die Applikationsebene. Durch die Gründung zahlreicher Benutzergruppen, die sich über den gesamten Erdball verstreuen (unter anderem auch in Österreich 10 und Deutschland 11 ), wurde der Ansatz zu einem international einsetzbaren und anerkannten Standard. Mittlerweile werden HL7 Standards in vielen Ländern eingesetzt und nehmen in manchen sogar den Rang einer offiziellen Norm ein Das Reference Information Model Das Reference Information Model (RIM) [23] wurde von HL7 entwickelt und als Draft-Version erstmals im Jänner 1997 veröffentlicht. Das offizielle Release 1 wurde im Jahr 2003 durch die ANSI anerkannt und auch durch die ISO unter der Referenz ISO/HL :2006 übernommen. Es ist ein

16 2 THEORETISCHE GRUNDLAGEN statisches Modell das aus sechs Hauptklassen besteht, die den Kern des Modells darstellen sollen. Abbildung 2: Die 6 Core-Klassen des HL7 RIM, übernommen aus [23] Act: Diese Klasse repräsentiert Handlungen, die ausgeführt werden und folglich auch dokumentiert werden müssen (z.b. eine Behandlung oder Untersuchung). Entity: Eine Entität repräsentiert physische Dinge und Personen, die für eine Handlung von Relevanz sind (z.b. Person, Röntgen-Gerät). Role: Eine Rolle wird von einer Entität verkörpert. Eine Entität kann jedoch mehrere Rollen haben (z.b. Dokumentenverfasser, behandelnder Arzt). Participation: Eine Beteiligung stellt eine Beziehung zwischen Handlungen und Rollen her. Dabei ist eine bestimmte Rolle an einer bestimmten Handlung beteiligt (z.b. ein bestimmter Arzt führt eine Behandlung durch). ActRelationship: Diese Klasse repräsentiert Beziehungen zwischen verschiedenen Handlungen (z.b. eine Diagnose folgt aus einer Beobachtung). RoleLink: Auch zwischen Rollen können Beziehungen und Abhängigkeiten bestehen (z.b. Hierarchie in einem Krankenhaus). Diese Klassen dienen als Bausteine und somit als Grundlage für alle Informationsmodelle und Strukturen, die im Rahmen des HL7 Version 3 12

17 2 THEORETISCHE GRUNDLAGEN Entwicklungsprozesses (siehe Kapitel 2.3.2) erstellt werden. Diese Bausteine werden in verschiedenen HL7-Schulungen mit Lego Steinen verglichen. Diese Metapher soll RIM-Einsteigern das Prinzip näher bringen, nämlich die Möglichkeit aus verschiedenen Bausteinen unterschiedliche Modelle und Strukturen erstellen zu können. Abgesehen von den sechs Hauptklassen besteht das RIM noch aus einigen Subklassen (siehe Abbildung 3). Das statische Modell wurde mittels der Unified Modeling Language (UML 12 ) [24] erstellt, das durch einige HL7- spezifische Erweiterungen ergänzt wurde. Abbildung 3: HL7 Reference Information Model, übernommen aus [23] Neben den in Abbildung 3 dargestellten Klassen wurde von HL7 die Superklasse 13 InfrastructureRoot erstellt, deren Attribute spezifische Einschränkungen auf Klassen anwenden können und speziell im Kontext des Informationsaustauschs Anwendung finden Eine Superklasse vererbt ihre Attribute an die Subklassen des RIM 13

18 2 THEORETISCHE GRUNDLAGEN InfrastructureRoot.nullFlavor: Dieser Wert zeigt an, dass die betreffende Information nicht vorhanden ist. Er spezifiziert, warum die Information nicht existiert oder in diesem speziellen Fall nicht angewendet werden kann. InfrastructureRoot.realmCode: Dieses Attribut erzwingt bereichsspezifische Einschränkungen. InfrastructureRoot.typeId: Erzwingt Einschränkungen, die in einem HL7-spezifischen Message Type (siehe Kapitel ) definiert sind. Ein Beispiel dazu findet sich in Kapitel InfrastructureRoot.templateId: Gibt an, dass definierte Einschränkungen (Templates) auf die Instanz angewendet werden. Die oben genannten Attribute können aufgrund des Vererbungsprinzips in Instanzen des RIM eingesetzt werden (siehe Kapitel 2.3.3). In [25] wird das RIM als inkohärenter Standard beschrieben, der trotz seines über zehn-jährigen Bestehens Probleme bei der Implementierung, Usability und Dokumentation aufweist. Der angesprochenen Doppeldeutigkeit des RIM könne nur mit der Generierung zweier separater Modelle abgeholfen werden: eine Referenz-Ontologie 14 des Gesundheitsbereichs und ein Modell für die Gesundheitsinformation. In der Praxis hat sich das RIM jedoch etabliert. Die immer wieder laut gewordene Kritik beruht laut [26] auf Missverständnissen und unterschiedlichen Sichtweisen der Anwender Das Domain Message Information Model Um eine spezielle Domäne des Gesundheitswesens darstellen zu können, hat HL7 das Domain Message Information Model (D-MIM) entwickelt. Es wird vom RIM abgeleitet und kann mittels der in Kapitel erwähnten Bausteine beliebig zusammengestellt und an verschiedenste Bedürfnisse 14 Eine Ontologie ist eine (meist hierarchische) Struktur, durch die ein Bereich der Realität modelliert werden kann. 14

19 2 THEORETISCHE GRUNDLAGEN angepasst werden. Dabei kommen die so genannten class clones ins Spiel, welche Kopien von RIM-Klassen darstellen und für eine bestimmte Domäne im Gesundheitswesen eingesetzt werden können. Ein D-MIM besteht aus jenen Klon-Klassen, Attributen und Beziehungen, die zur Konstruktion jeglicher domänenspezifischer Nachrichten benötigt werden. Wie auch das RIM, könnte auch ein D-MIM mittels UML grafisch dargestellt werden. Um jedoch die semantischen Verbindungen zwischen den verschiedenen Klassen und Attributen, sowie deren Einschränkungen besser darstellen zu können, hat HL7 eine eigene Notation entwickelt. Ein D-MIM stellt also ein Modell dar, das Einschränkungen auf das RIM anwendet und weiters eine Basis für alle spezifischeren Modelle, genannt R- MIM (siehe Kapitel ) Das Refined Message Information Model Das Refined Message Information Model (R-MIM) leitet seinen Inhalt vom zugehörigen D-MIM ab und beschreibt jene Klassen, Attribute und Beziehungen, die zur Erstellung von HL7-Nachrichten benötigt werden. Es wird grafisch wie auch das D-MIM durch die HL7 Notation repräsentiert und schränkt das zugehörige D-MIM in der Weise ein, dass ein weitaus spezifischerer Bereich zum Zweck der Erstellung einer Nachricht dargestellt werden kann. Um eine Nachricht aus einem R-MIM generieren zu können bedarf es zwei weiterer Strukturen: Hierarchical Message Description (HMD) Message Type (MT) Eine HMD spezifiziert, wie Nachrichten im HL7-Kontext auszusehen haben und beschreibt Kardinalität, Optionalität, Gruppierung und Sequenz einer Nachricht. Die Abfolge dieser Elemente wird in tabellarischer Form dargestellt (z.b. als MS-Excel-Dokument), ohne sich auf die verwendeten 15

20 2 THEORETISCHE GRUNDLAGEN Implementierungstechnologien (z.b. XML 15 ) zu beziehen. Die Spezifikation enthält weiters so genannte Message Types, die die Regeln zur Erstellung von Nachrichten beschreiben Der Standard HL7 Version 3 Im Jahr 1994 begann die Version 3 Arbeitsgruppe mit der Entwicklung eines neuen Standards und veröffentlichte 1997 das HL7 Version 3 Message Development Framework (MDF) [27] als neue Methodologie. Durch die stetige Weiterentwicklung des MDF wurde ein umfassendes HL7 Development Framework (HDF) [28] gebildet, das nun den Grundstock für Architekturentwicklungen und Nachrichtenstandards darstellen soll [29]. Basierend auf dem RIM wurde ein Paket von modell- und objektorientierten Kommunikationsstandards definiert, welche für die Entwicklung von Nachrichtenspezifikationen eingesetzt werden. Es wurden vier Modelle spezifiziert, die zur Entwicklung von Nachrichtenspezifikationen durchlaufen werden (siehe Abbildung 4). Use Case Model: Das Use Case Model stellt die erste Struktur dar, die im Entwicklungsprozess generiert werden muss und beschreibt den Informationsfluss zwischen den Applikationen. Information Model: Das Information Model muss dessen Inhalt zur Erstellung einer HL7-Nachricht vom Reference Information Model ableiten, was den meist kritischsten Punkt in der Entwicklung darstellt. Interaction Model: Das Interaction Model definiert Trigger Events, Interaktionen und Applikationsrollen, welche das Verhalten von Systemen, die HL7-Nachrichten nutzen, angeben. Message Design Model: Das Message Design Model wird aus Klassen, Attributen und Beziehungen des RIM zusammengestellt und beschreibt somit die Anforderungen an eine Nachricht für eine

21 2 THEORETISCHE GRUNDLAGEN beliebige Interaktion. Das daraus entstehende Message Information Model (MIM, siehe die Kapitel und ) dient als Grundlage für ein message object diagram, aus welchem die Hierarchical Message Descriptions generiert werden. Die Modelle auf denen HL7 Version 3 basiert, wie auch die erwähnte Methodologie, machen Version 3 zu einem mächtigen und flexiblen Standard im medizinischen Sektor. Abbildung 4: Message Development Modelle, übernommen aus [27] 17

22 2 THEORETISCHE GRUNDLAGEN Clinical Document Architecture Release 2 Die Clinical Document Architecture (CDA) ist ein von der ANSI akkreditierter Standard, der die Struktur und Semantik eines klinischen Dokuments zum Zweck der Übermittlung vorgibt [30]. Seit dem Release 2 ist der maschinen-verwertbare Teil der CDA nun vollständig vom RIM abgeleitet. Die CDA wird grafisch durch ein R-MIM (siehe Kapitel ) dargestellt, wobei sich die farbliche Codierung aus den RIM-Klassen (siehe Abbildung 2) ableitet. CDA-Dokumente wurden entwickelt, um eine einfachere und effektivere Kommunikation zwischen Informationssystemen zu gewährleisten, sie können jedoch auch zur Archivierung klinischer Dokumente eingesetzt werden und dadurch deren Persistenz garantieren. Die CDA weist folgende Charakteristika auf: Persistenz: Ein klinisches Dokument bleibt über eine Zeitspanne, die durch lokale oder gesetzliche Anforderungen definiert wird, unverändert. Zuständigkeit: Ein klinisches Dokument wird durch die für die Pflege zuständige Organisation betreut. Möglichkeit der Authentifizierung: Ein klinisches Dokument ist eine Ansammlung von Informationen, dessen Urheberschaft und Integrität sichergestellt werden muss. Kontext: Ein klinisches Dokument erstellt einen Kontext zu seinen Inhalten. Gesamtheit: Die Authentifizierung eines klinischen Dokuments bezieht sich auf die Gesamtheit und nicht nur auf Teile des Dokuments. Menschenlesbarkeit: Ein klinisches Dokument ist menschenlesbar. 18

23 2 THEORETISCHE GRUNDLAGEN Die CDA verfolgt einige Ziele, die jedoch in der Spezifikation nur sehr vage definiert sind. Zusammenfassend sollen hier die wichtigsten Punkte angeführt werden: Die CDA legt ihr Hauptaugenmerk auf die Patientenversorgung Kosteneffektive Implementierungen sollen mit einer hohen System- Bandbreite ermöglicht werden Der Austausch von menschenlesbaren Dokumenten zwischen Benutzergruppen (auch zwischen jenen mit unterschiedlichen Erfahrungsstufen) soll unterstützt werden Die Langlebigkeit aller kodierten Informationen betreffend der CDA- Architektur soll gefördert werden Die Weiterverarbeitung der CDA-Daten soll einer großen Auswahl an Applikationen ermöglicht werden CDA-Dokumente sollen mit einer großen Anzahl von Applikationen zur Dokumentenerstellung kompatibel sein Generell kann man sagen, dass mit Hilfe der CDA in Zukunft eine Textstrukturierung angestrebt wird und somit eine hohe semantische Interoperabilität gewährleistet werden kann. Um jedoch zu garantieren, dass der Empfänger des Dokuments die mitgelieferte Information auch ohne Zuhilfenahme von spezieller Software lesen und interpretieren kann, ist es notwendig, dass die vom Verfasser erstellten Inhalte menschenlesbar also narrativ übermittelt werden. Die zusätzliche Möglichkeit der Maschinenlesbarkeit stellt zwar einen für die Zukunft wichtigen Aspekt für die medizinische Dokumentation dar, wird aber in den Spezifikationen nicht zwingend vorgeschrieben, sondern nur als optionale Möglichkeit gehandhabt. Die CDA ist ein XML-Dokument, das die oben genannten Charakteristika aufweisen muss. Ein CDA-Dokument muss mit einem einfachen Editor ohne Zuhilfenahme spezieller Software gelesen werden können. Mit zusätzlichen 19

24 2 THEORETISCHE GRUNDLAGEN XML-Stylesheets [31] kann der Quelltext jedoch auch in einer gewünschten Formatierung anzeigbar gemacht werden. Die CDA besteht aus einem Header und einem Body, die zwingend aus narrativem Text (unstrukturiert) und optional aus maschinenverwertbaren (strukturierten) Daten bestehen. Zusätzlich können dem Dokument noch Multimedia-Dateien, wie z.b. Audiodateien und Bilder beigefügt werden. Aufgrund der Wichtigkeit der CDA für diese Arbeit werden in den nächsten Kapiteln die Klassen und Attribute von Header und Body näher betrachtet. Die Root-Klasse eines CDA-Dokuments ClinicalDocument stellt den Einstiegspunkt in das Objektmodell (R-MIM, siehe Abbildung 5) der CDA dar und enthält zahlreiche Attribute, deren Bedeutung in Kapitel erläutert werden soll. Das Attribut typeid der Superklasse InfrastructureRoot muss innerhalb der ClinicalDocument-Klasse vorkommen und folgendermaßen aussehen: <typeid root= extension= POCD_HD /> Code-Beispiel 1: Das XML-Fragment "typeid", übernommen aus [30] Die ebenfalls aus der Klasse InfrastructureRoot stammende templateid kann in allen Klassen eines CDA-Dokuments vorkommen und deutet somit darauf hin, dass zusätzliche Einschränkungen auf die Klassen angewendet werden. 20

25 2 THEORETISCHE GRUNDLAGEN CDA R2 Header Der Header identifiziert und klassifiziert das Dokument durch die Metadaten und ermöglicht dadurch die Dokumentenverwaltung und den Austausch von CDA-Dokumenten innerhalb von Institutionen und über Institutionsgrenzen hinaus Header Attribute In diesem Kapitel soll eine Übersicht der Attribute der Root-Klasse ClinicalDocument erstellt und ihre Bedeutung kurz erläutert werden. ClinicalDocument.id: Identifiziert das Dokument durch einen eindeutigen Identifier. ClinicalDocument.code: Beschreibt die Art des Dokuments (z.b. Entlassungsbericht). o CE Coded With Equivalents bedeutet, dass der Dokumenttyp kodiert vorliegen muss und eine Ausprägung des Datentyps Concept Descriptor sein muss, welcher ein Konzept mit einem Code beschreibt. o CWE Coded With Extensibility gibt die Strenge der Kodierung an und bedeutet, dass auch ein Code verwendet werden darf, der nicht in den Vocabularies von HL7 beschrieben ist (z.b. LOINC 16 ). o CNE Coded non-extensible schreibt vor, dass nur Codes aus den Vocabularies verwendet werden dürfen. CWE und CNE leiten sich aus dem Datentyp Coded Value (CV) ab, der kodierte Daten zulässt. ClinicalDocument.title: Repräsentiert den Dokumententitel. 16 Logical Observation Identifiers Names and Codes (LOINC) Ein Begriffssystem zur Verschlüsselung von Laborwerten und klinischen Untersuchungen, 21

26 2 THEORETISCHE GRUNDLAGEN ClinicalDocument.effectiveTime: Bezeichnet den Zeitpunkt der Erstellung des Dokuments. ClinicalDocument.confidentialityCode: Beschreibt die Vertraulichkeit des Dokuments, die Normal (N), Restricted (R) oder Very Restricted (V) sein kann. ClinicalDocument.languageCode: Spezifiziert die Sprache des Dokuments mit Hilfe eines von HL7 definierten Kodierungssystems. ClinicalDocument.setId: Ein Identifier, der über alle Dokumentrevisionen gebraucht wird. ClinicalDocument.versionNumber: Eine Zahl, welche die Version des Dokuments angibt Header Beteiligte Seit der Veröffentlichung des Release 2 der CDA, das durch die Entwicklung des RIM maßgeblich beeinflusst wurde, können im Header weitaus mehr beteiligte Personen und Organisationen unterschieden werden, als das noch im Release 1 der Fall war [10]. Eine beteiligte Person kann in einem CDA- Dokument mehrere Rollen gleichzeitig besetzen. In den folgenden Punkten soll die Bedeutung der wichtigsten Klassen beschrieben werden, die über eine Beteiligung (Participation) mit der Root- Klasse ClinicalDocument in Beziehung stehen. authenticator: Eine Person, welche die Richtigkeit eines Dokuments bescheinigt, die jedoch nicht das Recht einer legalen Beglaubigung hat. author: Verfasser des Dokuments (z.b. eine Person, eine Maschine bzw. ein System). custodian: Jedes CDA Dokument wird durch genau eine Organisation verwaltet. 22

27 2 THEORETISCHE GRUNDLAGEN dataenterer: Eine Person, die Daten in das Ursprungssystem eingibt. encounterparticipant: Repräsentiert einen Kliniker, der an einer Interaktion zwischen dem Patient und dem Gesundheitsdienstleister (z.b. ein Arztbesuch) beteiligt ist. informant: Eine Person, die relevante Informationen zur Verfügung stellt (z.b. ein Elternteil eines Kindes). informationrecipient: Der Empfänger des Dokuments. legalauthenticator: Eine beteiligte Person, die das Dokument legal bescheinigt hat. participant: Alle Beteiligten (Personen und Organisationen), die nicht schon explizit durch andere Klassen abgedeckt werden. performer: Repräsentiert Kliniker, die ein ServiceEvent (siehe Kapitel ) ausführen. recordtarget: Repräsentiert das EHR, welchem das CDA-Dokument zugeordnet wird und nimmt Bezug auf den Patienten, der die medizinische Leistung in Anspruch nimmt. responsibleparty: Stellt eine Person oder Organisation dar, die die Verantwortung über die ausgeführte Interaktion (encounter) hat Header Beziehungen In Abbildung 6 sind jene Klassen abgebildet, die über eine Beziehung mit der Root-Klasse ClincialDocument in Verbindung stehen. Ihre Bedeutung soll in den folgenden Punkten erläutert werden: ParentDocument: Ein anderes Dokument, das die Quelle eines überarbeiteten Dokuments oder eines Dokumentenanhangs darstellt. ServiceEvent: Repräsentiert die eigentliche Handlung, die dokumentiert werden soll (wie z.b. eine Darmspiegelung). 23

28 2 THEORETISCHE GRUNDLAGEN Order: Beinhaltet Anweisungen, die im Laufe einer klinischen Interaktion erfüllt werden müssen (z.b. die Anforderung eines Röntgen). Consent: Beschreibt Genehmigungen, die mit dem CDA-Dokument einhergehen. EncompassingEncounter: Diese Klasse beschreibt die klinische Interaktion, innerhalb der die Dokumentation stattgefunden hat. 24

29 2 THEORETISCHE GRUNDLAGEN Abbildung 5: CDA R2 Header mit Beteiligten, übernommen aus [30] 25

30 2 THEORETISCHE GRUNDLAGEN Abbildung 6: CDA R2 Header Beziehungen, übernommen aus [30] 26

31 2 THEORETISCHE GRUNDLAGEN CDA R2 Body Der Body enthält den klinischen Befund und kann entweder aus unstrukturiertem Text (repräsentiert durch die Klasse NonXMLBody) oder aus strukturiertem Markup (repräsentiert durch die Klasse StructuredBody) bestehen. Jedes CDA-Dokument besteht aus genau einem Body, welcher über die Beziehung component mit der Root-Klasse in Verbindung steht (siehe Abbildung 7). Beim Eintritt in den Body gelangt man in den so genannten BodyChoice, der die Auswahl zwischen strukturiertem XML-Code und unstrukturiertem Blob 17 ermöglicht Section Jeder Body enthält mindestens eine Section-Klasse, welche ähnlich wie die Klasse ClinicalDocument aus verschiedenen Attributen aufgebaut ist: Section.id: Ein eindeutiger Identifikator einer Section Section.code: Spezifiziert die Art der Section Section.title: Der menschenlesbare Titel der Section Section.text: Repräsentiert den Narratviblock der Section, welcher vom Empfänger des Dokuments gerendert werden muss Section.confidentialityCode: Die Vertraulichkeit der Section (siehe Kapitel ). Ein hier angegebener Wert überschreibt für den Kontext der aktuellen Section den gleichnamigen Wert, der in der Klasse StructuredBody angegeben wurde. Section.languageCode: Die gewählte Sprache für Inhalt und Attribute Wie auch im Header kann es in einer Section verschiedene Beteiligte geben, die entweder eine exakte Kopie der jeweiligen Klasse im Header darstellen, 17 Blob steht für Binary Large Object und bezeichnet große binäre Objekte, die in einer Datenbank unstrukturiert vorliegen 27

32 2 THEORETISCHE GRUNDLAGEN oder durch einen neuen Wert überschrieben werden können. Diesen Kontext findet man in einigen Attributen der CDA (z.b. confidentiality und language). Im Header definierte Werte können bis in verschachtelte Klassen des Bodys propagiert werden, falls sie nicht durch neue Werte überschrieben wurden. Die Beteiligten author und informant können analog zu den gleichnamigen Beteiligten des Headers gesehen werden. Der Beteiligte subject repräsentiert jene Person, auf die sich die in der Section beschriebene Handlung bezieht. Einer Section können über die Beziehung component beliebig viele Sections folgen, wobei der Kontext in die untergeordneten Sections propagiert wird clinicalstatement Über die Beziehung entry gelangt man zu einer weiteren ChoiceBox clinicalstatement (siehe Abbildung 8). Durch die so genannten entries (oder auch entry-acts) können narrative Inhalte der Sections durch kodierte, computerverwertbare Inhalte dargestellt werden. Anders als bei bodychoice und Section ist ein entry nicht zwingender Bestandteil eines CDA- Dokuments, da hier eine 0 *-Kardinalität besteht. Die in einem clinicalstatement erlaubten Klassen stellen Ableitungen von RIM-Klassen dar und sollen in den folgenden Punkten kurz beschrieben werden: Observation: Repräsentiert klinische Beobachtungen. RegionOfInterst: Der Bereich, der in einem Bild von Interesse ist. ObservationMedia: Repräsentiert Multimedia-Inhalte, die Teil des bescheinigten Inhalts eines CDA-Dokuments sind (im Gegensatz zur Referenz ExternalObservation). SubstanceAdministration: Wird für die Darstellung der Medikation genutzt und kann auch Events repräsentieren, die mit der Medikation in Verbindung stehen (z.b. Medikationsgeschichte oder der geplante Ablauf der Medikation). 28

33 2 THEORETISCHE GRUNDLAGEN Supply: Die Weitergabe eines Produkts oder Materials von einer Entität zur nächsten. Procedure: Repräsentiert Prozeduren, deren Folge die Änderung des physischen Zustands des betreffenden subjects ist. Encounter: Durch diese Klasse werden weitere Interaktionen zwischen Patient und Kliniker repräsentiert (zusätzlich zu den Interaktionen, die durch die Klasse EncompassingEncounter im Header beschrieben werden, siehe Kapitel ). Organizer: Kann verwendet werden, um beliebige Gruppierung von CDA-entries zu erstellen, welche einen gemeinsamen Kontext haben (Weitere Organizer können durch die Beziehung component realisiert werden). Act: Wenn die Gesundheitsdienstleistung keiner spezielleren Klasse zugeordnet werden kann wird auf die allgemeine Klasse Act zurück gegriffen. Der folgende XML-Code repräsentiert eine einfache Observation, in der die Körpertemperatur dokumentiert wurde. Diese ist in eine Section Vital- Signs eingebettet. 29

34 2 THEORETISCHE GRUNDLAGEN <section> <code code="8716-3" codesystem=" " codesystemname="loinc"/> <title>vital Signs</title> <text>temperature is 36.9 C</text> <entry> <observation classcode="obs" moodcode="evn"> <code code=" " codesystem=" " codesystemname="snomed CT" displayname="body temperature"/> <statuscode code="completed"/> <effectivetime value=" "/> <value xsi:type="pq" value="36.9" unit="cel"/> </observation> </entry> </section> Code-Beispiel 2: Observation innerhalb einer section, übernommen aus [10] In diesem Beispiel werden einige typische Attribute einer Observation ersichtlich, wie z.b. Observation.code und Observation.value. Der moodcode EVN (Event) sagt aus, dass es sich um ein Ereignis handelt und dass die Observation somit stattgefunden hat. Die clinicalstatements sind mit zahlreichen Beteiligten verknüpft, die wie auch in den Sections entweder vom Header in den Body propagieren oder durch neue Werte überschrieben werden. Die wichtigsten Beteiligten decken sich mit den Klassen in Kapitel Über die Beziehung reference können über die CDA-entries noch externe Objekte (wie z.b. Bilder oder ältere Befunde) referenziert werden. 30

35 2 THEORETISCHE GRUNDLAGEN Abbildung 7: CDA R2 Section, übernommen aus [30] 31

36 2 THEORETISCHE GRUNDLAGEN Abbildung 8: CDA R2 Body entries, übernommen aus [30] 32

37 2 THEORETISCHE GRUNDLAGEN 2.4 Das HL7 Template Bestehende Gesundheitsinformationsmodelle sind in der Lage einen Ausschnitt der realen Welt darzustellen. Wie wir bereits in Kapitel gesehen haben, kann mittels ausgewählter RIM-Klassen ein klinisches Dokument erstellt werden, das einem klassischen Papier-Dokument entspricht. Diese Strukturen sind oftmals relativ allgemein gehalten und können daher nur schwer für speziellere medizinische Anwendungen (wie z.b. einen Laborbefund) herangezogen werden [32]. Das HL7 Template beinhaltet eine Menge von Bedingungen, durch die es ermöglicht wird, bestehende Modelle einzuschränken und zu verfeinern. Dadurch kann ein weitaus spezifischerer Bereich einer im HL7-Kontext meist klinischen Anwendung dargestellt werden. Ein Template wird ebenso wie die CDA durch ein XML-Dokument repräsentiert und enthält idealerweise noch zusätzliche Metadaten, die den Zweck und die Anwendung des Templates beschreiben. Optional können dem Template noch Anhänge beigefügt werden, wie z.b. eine grafische Repräsentation des Template-Modells. Das Template-Konzept von HL7 beruht auf der in Kapitel 2.2 behandelten Dualen Modellierung, in der Informations- und Wissensebene voneinander getrennt werden. Im HL7-Kontext wird die Informationsebene durch das RIM (siehe Kapitel 2.3.1) und die Wissensebene durch Templates repräsentiert. Die Organisation HL7 hat eine Gruppe ins Leben gerufen, die sich mit der Ausarbeitung von Vorgaben zur Erstellung von Templates beschäftigt. Diese Vorgaben wurden in einer Spezifikation zusammengefasst, die in Zukunft zur Erstellung von HL7 Templates herangezogen werden soll und im Folgenden erläutert wird. Die HL7 Template Spezifikation Diese Spezifikation [33] wurde als Draft Standard for Trial Use (DSTU) veröffentlicht, trägt den offiziellen Titel Specification and Use of Reusable Constraint Templates und beinhaltet allgemeine Vorgaben zur Erstellung 33

38 2 THEORETISCHE GRUNDLAGEN von HL7 Templates. Die aktuelle near final version wird nach erfolgreicher Absolvierung eines Balloting-Verfahrens wie auch andere Entwicklungen von HL7 als offizieller Standard durch die ANSI akkreditiert werden. Die Definition von HL7 besagt, dass ein Template folgendermaßen repräsentiert wird: durch eine formale Definition in einer oder mehrerer menschenlesbaren Sprachen oder Notationen (optional) durch ein Static Model (optional) durch eine oder mehrere implementierungsspezifische Repräsentationen, die zur Validierung von Instanzen in einem speziellen Kontext genutzt werden können Der Begriff Static Model wird im HL7 Kontext einerseits für das RIM verwendet und andererseits für alle Modelle, die Einschränkungen auf das RIM repräsentieren. Weiters werden auch Klassenmodelle und Schemata als Static Models bezeichnet. Im Kontext der Template Spezifikation wird der Begriff zur Beschreibung mehrerer Konzepte verwendet. Einerseits steht das Static Model für das Template selbst, welches eine Instanz des HL7 Template Modells (siehe Anhang) repräsentiert und die Einschränkungen der Klassen, Attribute und Assoziationen in einer maschinen-verwertbaren Sprache enthält. Weiters steht das Static Model für das HL7 Template Modell zur Erstellung von Templates und alle Modelle, die Einschränkungen auf das RIM anwenden, wie z.b. das Constrained Information Model (CIM) in Abbildung 10. In Abbildung 9 wird ein Modell eines Templates dargestellt, das einen Ausschnitt des in der Medizin verwendeten Barthel-Index (BI) darstellt, welcher zur Bewertung des funktionellen Status eines Patienten verwendet wird. Wird das Modell publiziert, wird dem Template ein template identifier (templateid) zugeordnet (z.b : REPC_RM000103), der aus einem OID (Object Identifier) und einem model identifier 34

39 2 THEORETISCHE GRUNDLAGEN zusammengesetzt wird. Ein OID ist eine weltweit eindeutige Nummer, die einen Knoten in einem hierarchisch zugewiesenen Namensraum repräsentiert. Knoten können an Institutionen weitergegeben werden, die zur eigenen Verwendung verwaltet werden und zur eindeutigen Identifikation Objekten zugeordnet werden können. Ein Template schränkt immer ein zugehöriges allgemeineres Modell ein. Im Fall des Barthel-Index wurde das CIM aus Abbildung 10 näher spezifiziert. Das Beispiel-CIM ist ein sehr generisch gehaltenes Modell, das auf dem clinical statement pattern basiert (siehe Kapitel ). Es besteht aus einer Klasse Observation, welche components enthalten kann, die wiederum Observations darstellen. Abbildung 9: Modell des "Barthel-Index", übernommen aus [33] 35

40 2 THEORETISCHE GRUNDLAGEN Abbildung 10: Constraint Information Modell, übernommen aus [33] Ein Template wird als einfaches XML-Dokument gespeichert, welches zusätzlich noch eine Repräsentation durch ein statisches Modell und Metadaten beinhalten kann. Die Liste der Metadaten wurde gemeinsam mit dem Europäischen Normungsinstitut (CEN) erstellt, um in Zukunft die Möglichkeit zu wahren, HL7 Templates und CEN Archetypen in gemeinsamen Registern speichern und verwalten zu können. Metadaten beschreiben das Template und ermöglichen eine einfachere Wiederfindung und Wiederverwendung (Reuse) derselben. Einige zwingende Attribute der Metadaten sollen in den folgenden Punkten angeführt werden: id: ermöglicht eine eindeutige, jedoch nicht-semantische Identifikation name: der Name des Templates in Freitext intention: der Zweck des Templates in Freitext beschrieben derivationmodelid: die eindeutige Id des Modells, das durch das Template eingeschränkt wird 36

41 2 THEORETISCHE GRUNDLAGEN referencemodelid: die eindeutige Id des Referenzmodells, von welchem das Template abgeleitet wird (im HL7-Kontext immer das RIM) publicationstatus: kann Draft, Not For Use, For Production Use, Withdrawn oder Superseded sein Der XML-Code eines Templates basiert auf einem UML-Diagramm, das in Kapitel 5.4 näher beschrieben wird. Templates stellen eine formale Definition eines medizinischen Konzepts dar. Ein Beispiel für die Anwendung eines klinischen Templates ist ein Laborbericht, in dem Templates seine spezifische Form bestimmen können wie z.b. ein Complete Blood Count (CBC), der Auskunft über die Zellen im Blut gibt. HL7 Templates können entweder flach oder tief strukturiert werden. Tiefe Templates enthalten alle nötigen Klassen, Attribute und Assoziationen, die zur Beschreibung einer bestimmten Anwendung vonnöten sind. Ein einfaches Beispiel für ein tiefes Template findet sich in Abbildung 9. Flache Templates basieren auf der Idee, bestehende Komponenten wieder zu verwenden. Als wiederverwendbare Komponenten kommen dabei so genannte Common Message Element Types (CMETs) zum Einsatz, auf die vom flachen Template aus verwiesen wird (siehe Abbildung 11). Vorteile von tiefen Templates: Sie sind vollständig und daher einfacher zu verstehen Die Verarbeitung kann einfacher und schneller erfolgen Vorteil von flachen Templates: Die Wiederverwendung wird gewährleistet In der Praxis wird man sich häufig für eine Kombination der beiden Konzepte entscheiden. 37

42 2 THEORETISCHE GRUNDLAGEN Abbildung 11: Flach strukturierter Barthel-Index mit CMETs, übernommen aus [33] Um sowohl die Wiederverwendung als auch das Wiederauffinden von Template-Konzepten zu gewährleisten und zu vereinfachen soll in Zukunft ein zentrales Register erstellt werden. In der Spezifikation wird erwähnt, dass das National Institute of Standards and Technology (NIST 18 ) mit der Erstellung eines Registers (NIST artefacts registry) beauftragt wurde, welches sich jedoch noch in der Entwicklung befindet

43 2 THEORETISCHE GRUNDLAGEN Die Spezifikation enthält weiters ein Kapitel Best Practice for Template Design, das sehr allgemein gehaltene Punkte zur Erstellung von Templates auflistet. Diese Punkte können nicht als Vorgaben sondern eher als Empfehlungen verstanden werden und sind daher von HL7 sehr vage definiert worden: Einschränkungen in Form eines Static Models sind optional. Es wird jedoch empfohlen die Einschränkungen in Form eines Static Models zu repräsentieren. Templates sollten angemessene Namen tragen, die auf die Bedeutung hinweisen (nicht die Bezeichnung der Klon-Klassen verwenden). Templates sollten im globalen NIST artifacts registry registriert sein 39

44 3 STAND DER FORSCHUNG 3 Stand der Forschung Im Folgenden werden wichtige aktuelle Arbeiten zur Dualen Modellierung von EHR-Systemen im Allgemeinen und zu praktischen Aspekten des Template/Archetyp-Ansatzes im Speziellen besprochen. Interoperabilität stellt einen Kernaspekt von EHR-Systemen dar, der in den Arbeiten in Kapitel 3.1 immer wieder adressiert wird. Weiters basieren die in Kapitel 3.1 erwähnten Arbeiten auf der Model-Driven Architecture (MDA), die in der Praxis zur Konstruktion von Softwaresystemen eingesetzt wird. In Kapitel 3.2 werden praktische Implementierungen von Templates und Archetypen aus verschiedenen Ländern vorgestellt. 3.1 Architekturen von Gesundheitsinformationssystemen, die auf multiplen Modellen beruhen In [34] wird eine Methode beschrieben, wie mit Hilfe der MDA Health Care Information Systems (HCIS) generiert werden können. Die MDA wurde von der Object Management Group (OMG) [35] entworfen und bietet ein Framework, das organisatorische Prozesse von der technologischen Entscheidungsplattform trennt [34]. In der Gesundheitsversorgung können Software-Entwickler die MDA-Architektur als Bauplan für die Repräsentation einer Organisationsarchitektur verwenden, wobei UML als Modellierungstool angewandt wird. Im Rahmen einer MDA-Applikation werden zwei Modelle unterschieden das Platform Independent Model (PIM) und das Platform Specific Model (PSM). Clinical Decision Support Systems (CDSS) und EHR-Systeme können unter dem eingangs erwähnten Begriff HCIS zusammengefasst werden. Die MDA verfolgt folgende Ziele: Plattformunabhängige Produktion von Begriffsmodellen durch Separation des Konzeptmodells (PIM) vom physischen Modell (PSM) Die Nutzung von offenen Standards, wie z.b. UML 40

45 3 STAND DER FORSCHUNG Sicherstellung der Interoperabilität durch Erstellung von Beziehungen (im MDA-Kontext Brücken genannt) zwischen PSM und PIM Durch Separation der Modelle wird die Abhängigkeit von einem Softwarelieferanten minimiert Geringere Entwicklungskosten durch erhöhte Produktivität und Wiederverwendbarkeit der Modelle Portabilität durch die Generierung plattformunabhängiger Modelle Der MDA-Entwicklungsprozess besteht aus drei Schritten. Als erstes wird ein PIM auf hoher Abstraktionsebene generiert, das z.b. durch ein UML- Diagramm repräsentiert wird. Im zweiten Schritt wird durch Transformation ein PSM für jede Plattform generiert. Im dritten Schritt wird das PSM durch Mapping-Verfahren in Anwendungscode umgewandelt. Die Schritte zwei und drei werden üblicherweise automatisiert ausgeführt. Mit Hilfe der MDA ist es möglich flexible und stabile Modelle zu erstellen. Durch Separation von PIM und PSM können offene Standards verwendet werden, wodurch ein hohes Maß an Interoperabilität gewährleistet werden kann. Eine Integration von HL7 Standards in die MDA wird zukünftig angestrebt. In [36] werden Voraussetzungen und Bedingungen zur Erfüllung semantischer Interoperabilität von EHR-Systemen beschrieben. Individuelle Patienteninformationen können durch die Vernetzung von Gesundheitsdienstleistern und den Einsatz von EHR-Systemen zur Verwaltung der komplexen Daten von verschiedensten Standorten auf der ganzen Welt abgerufen werden. Um semantische Interoperabilität in EHR-Systemen gewährleisten zu können müssen folgende Punkte adressiert werden: Die Möglichkeit des semantischen Austauschs und die Zusammenführung von EHR-Daten zwischen Systemen 41

46 3 STAND DER FORSCHUNG Die einheitliche Nutzung moderner Terminologie-Systeme und medizinischer Wissensdatenbanken Die Möglichkeit der Integration und sicheren Nutzung von computergesteuerten Protokollen, Alarmen und Pflegeleitung durch EHR-Systeme Gewährleistung der notwendigen Datenqualität und -konsistenz Diese Erfordernisse für semantische Interoperabilität führten zu einem Lösungsansatz, der mit Hilfe einer Service-orientierten Architektur (SOA) erstellt wurde, welche auf dem Ansatz der Model-Driven Architecture [34] aufbaut. Das daraus entstandene Generic Component Model (GCM) ist der Vorgänger einiger heute verwendeter Referenzmodelle [2, 23], welche auf den medizinischen Bereich fokussieren. Als treibende Kraft für die Ermöglichung semantischer Interoperabilität werden Referenzmodelle und daraus instanzierte Archetypen genannt, vor allem aber in Verbindung mit klinischen Terminologien, wie z.b. LOINC [37], SNOMED CT und ICD, wodurch eine große Menge an klinischen Konzepten beschrieben werden kann. 3.2 Implementierungsaspekte von Archetypen und Templates Das schottische Gesundheitsministerium (NHS Scotland 19 ) gab im November 2005 ein Projekt in Auftrag, das unter dem Titel A National Library of Clinical Templates for Community Nursing in Scotland: A Feasibility Study durchgeführt wurde und darauf abzielte, eine nationale Bibliothek klinischer Templates für die Krankenpflege zu schaffen und deren Vorteile für die klinische Pflege aufzuzeigen. openehr Archetypen und HL7 Templates wurden herangezogen, um Interoperabilität und Systementwicklung zu fördern und Klinikern das Potential der Strukturen zu

47 3 STAND DER FORSCHUNG verdeutlichen. Das Projekt ist in [38] beschrieben und wurde in drei Phasen eingeteilt. In der Phase professional development wurden Möglichkeiten untersucht, wie Kliniker an der Entwicklung von Templates teilnehmen können. Während des Template-Entwicklungsprozesses wurden verschiedene medizinische Personengruppen festgelegt, die Kommentare und Anregungen zu bestehenden Strukturen abgeben konnten und somit am Entwicklungsprozess teilhaben konnten. Die Zusammenarbeit von Klinikern und Entwicklern wurde über eine Webseite 20 realisiert. In der zweiten Phase library management wurden die aus dem Entwicklungsprozess gewonnenen Erkenntnisse in Domänenmodellen und Template- oder Archetypanwärtern umgesetzt. Die dritte Phase implementation beschäftigte sich mit der Evaluierung der entwickelten Modelle, wobei bereits existierende Systeme und Schemata eingesetzt wurden. Die Studie zeigte auf, dass Template- und Archetypstrukturen einen optimalen Weg für schnelle Entwicklung, Re-Use und Interoperabilität darstellen. Die Lücke zwischen klinischen Standards und deren Implementierung in medizinische Informationssysteme muss jedoch noch geschlossen werden. Im Jahr 2000 wurde das Projekt PropeR mit dem Ziel gestartet, den Effekt von Software zur Entscheidungsunterstützung (Decision Support Software, DSS) in Bezug auf die Qualität von Patientenversorgung zu untersuchen. Im Artikel [39] wird auf Schlaganfallpatienten eingegangen, die zu Hause gepflegt werden. Das PropeR EHR System wurde als Client-Server-Lösung implementiert, als Informationsmodell fungiert die Clinical Observation Access Specification (COAS) der OMG. Die PropeR-Definition von Archetypen unterlag der Anforderung, dass Archetypen möglichst einfach zu entwickeln sein sollen, da diese per Hand und nicht durch einen Archetypgenerator erstellt werden

48 3 STAND DER FORSCHUNG Bei der Modellierung der Archetypen wurde vor allem auf Kontext und die Darstellung am Bildschirm Wert gelegt. PropeR Archetypen werden mit Hilfe der Sprache XML implementiert. Die Evaluation des PropeR EHR-Systems war bei der Veröffentlichung des Artikels noch nicht abgeschlossen. Vier Gesundheitspraktiker sind im Test involviert und bauen über GPRS und Laptop eine Verbindung zum PropeR EHR-System am Wohnort des Patienten auf. Dabei wird die Software auf Nutzerfreundlichkeit, Bugs und Performance getestet. Es ist geplant ein größeres Experiment mit 17 Heilpraktikern mit dem Ziel der Evaluierung der Qualität der Patientenversorgung durchzuführen. Das unit testing framework von Beck [40] ist eine Methode, mit der einzelne Softwareelemente auf deren Funktionalität überprüft werden können. Darauf basierend wird in [41] ein Test-Framework für Archetypen beschrieben. Dieses Framework nutzt Archetypen, die auf dem Reference Model und dem Archetype Object Model (AOM, im openehr-kontext auch als kernel bezeichnet) [42] basieren, um die Semantik von Implementierungen des AOM zu testen. Folgende Voraussetzungen sollen dabei erfüllt sein: Tests sollen unabhängig von Plattform und Implementierung sein Tests sollen Archetyp-basiert sein und vorzugsweise automatisch generiert werden Das Test-Framework wurde in drei logische Ebenen gegliedert: Testvorrichtung (test fixture): Sie wird durch definierte Regeln automatisch generiert, um den Test durchzuführen und ein erwartetes Resultat zu erhalten. Diese Vorrichtung sollte plattformunabhängig gestaltet werden, um verschiedene openehr Kernel-Implementierungen auf unterschiedlichen Plattformen validieren zu können. Testfall (test case): Repräsentiert eine Testlogik für ein spezifisches Szenario. Er enthält Informationen zur zu testenden Kernel- 44

49 3 STAND DER FORSCHUNG Operation, zu den Eingabewerten und dem erwarteten Ergebnis der Kernel-Operation. Testläufer (test runner): Kann die Testvorrichtungen laden und nutzt Testfälle als Spezifikation, um mittels definierter Eingabedaten einen Test ausführen zu können und die Ausgabe mit erwarteten Ergebnissen zu vergleichen. Ein händisch erstellter Testfall ist in Code-Beispiel 3 zu sehen und basiert auf einem Blutdruck-Archetyp 22. <PathQueryTestCase> <DataInstance>blood_pressure-001.dadl</DataInstance> <Test> <Path>/observation/data/events//data/items/ value/magnitude</path> <Expected>120.0</Expected> </Test> <Test> <Path>/observation/data/events//data/items/ value/magnitude</path> <Expected>90.0</Expected> </Test> </PathQueryTestCase> Code-Beispiel 3: Testfall-Spezifikation in XML zur Pfadabfrage, übernommen aus [41] Mit dem plattformunabhängigen Test-Framework wurde eine Methode erstellt, um zu testen, ob die Semantik eines Archetyps von einem System richtig interpretiert wird. Da Archetypen maschinenlesbare Strukturen darstellen, können Regeln erstellt werden, die eine automatisierte Generierung von Testvorrichtungen und fällen ermöglichen observation/openehr-ehr-observation.blood_pressure.v1.adl 45

50 4 METHODEN 4 Methoden Ziel dieser Arbeit ist es, den Anwendungsbereich von HL7 Templates sowie den aktuellen Entwicklungsstand des zugrunde liegenden Frameworks zu erheben und zu analysieren. Die im Rahmen dieser Diplomarbeit eingesetzte Methode stützt sich auf das Vorgehensmodell für die Systemanalyse nach Ammenwerth und Haux, das in [43] beschrieben ist. Auf Basis dieses Vorgehensmodells sollen die internationalen Aktivitäten im Bereich der HL7 Templates erhoben und nach bestimmten Kriterien analysiert werden. Abbildung 12 zeigt eine angepasste grafische Darstellung des Vorgehensmodells zur Systemanalyse nach Ammenwerth und Haux. Abbildung 12: Vorgehensmodell zur Systemanalyse nach Ammenwerth und Haux, adaptiert übernommen aus [43] 46

51 4 METHODEN In Abbildung 12 wird der übliche Ablauf einer Systemanalyse grafisch dargestellt, wobei nicht zwangsläufig alle Schritte durchgeführt werden müssen. Ausgehend von einer spezifizierten Fragestellung werden im Normalfall sukzessive folgende Schritte durchgeführt: In der Analyseplanung werden im Wesentlichen die Zielsetzung der Systemanalyse konkretisiert, der zu analysierende Problembereich genauer definiert und die Durchführung der Systemanalyse geplant. Die Informationsbeschaffung dient der Erhebung der benötigten Informationen und bedient sich verschiedener Methoden, wie z.b. Befragung, Beobachtung, Dokumenten- und Literaturanalyse. Im Zuge der Modellierung werden unter Anwendung informeller, formaler oder semiformaler Methoden die Ergebnisse der Informationsbeschaffung geeignet aufbereitet. Die Ergebnisse müssen dabei nicht zwangsläufig in Form eines grafischen Modells aufbereitet werden, sondern können auch in strukturierter Textform dargestellt werden. In der Phase der Verifikation werden die in der Modellierungsphase erstellten Modelle hinsichtlich Korrektheit, Vollständigkeit und Angemessenheit geprüft. Diese Prüfung erfolgt in der Regel durch Fachexperten und hat entweder eine Nachbearbeitung (Sprung in einen vorherigen Schritt) oder eine Eignung des Modells zur Folge. Sollte die Prüfung fehlschlagen, müssen je nach Art des Problems bereits durchgeführte Schritte überarbeitet werden (siehe graue Pfeile in Abbildung 12). Somit kann es vorkommen, dass die Punkte des Modells nochmals abgearbeitet werden müssen. 47

52 5 ERGEBNISSE 5 Ergebnisse Ziel der Diplomarbeit ist es, den Anwendungsbereich von HL7 Templates sowie den aktuellen Entwicklungsstand des zugrunde liegenden Frameworks zu beleuchten. Obwohl in diesem Gebiet schon seit einigen Jahren an einem einheitlichen Standardisierungskonzept gearbeitet wird, ist der diesbezügliche Fortschritt relativ langsam. Die Erstellung einer Spezifikation zur einheitlichen Repräsentation von Templates (siehe Kapitel 2.4) war der erste wichtige Schritt in Richtung Standardisierung. Global gesehen stecken die HL7 Templates jedoch noch in ihren Kinderschuhen und werden erst seit kurzer Zeit Schritt für Schritt in den Bereich Gesundheitswesen eingeführt. 5.1 Ergebnisse der Analyseplanung Im Rahmen der Analyseplanung wurde die Zielsetzung dieser Diplomarbeit weiter konkretisiert. Es sollen zunächst bereits bestehende, auf HL7 Templates basierende Implementierungsleitfäden analysiert werden. Im Rahmen dieser Analyse sollen die Implementierungsleitfäden auch in Bezug zur aktuellen Template-Spezifikation der HL7 Organisation (siehe Kapitel 2.4) gesetzt werden. Dadurch kann deutlich gemacht werden, inwieweit bestehende Implementierungsleitfäden schon die Erfordernisse, die zukünftig an HL7 Templates gestellt werden, erfüllen. Die Analyse wird weiters ergänzt durch einen Vergleich des HL7 Template Ansatzes mit dem in der Norm EN/ISO beschriebenen Archetyp-Ansatz. Dabei werden einführend die Modellstrukturen von CEN und HL7 gegenüber gestellt und weiters die beiden UML-Modelle zur Erstellung von Archetypen und Templates miteinander verglichen. Um eine einheitliche Vergleichsbasis der Implementierungsleitfäden zu erzielen, wurde ein Kriterienkatalog erstellt, an Hand dessen die verschiedenen Implementierungsleitfäden betrachtet werden sollen. Damit können sowohl Analogien als auch Unterschiede aufgezeigt werden. Die Kriterien werden im Folgenden kurz dargestellt. 48

53 5 ERGEBNISSE Kriterienkatalog für die Analyse der Implementierungsleitfäden Autoren: Um einen Überblick über die verschiedenen Verfasser der Spezifikationen zu erhalten, werden in diesem Kapitel die wichtigsten Autoren angeführt und deren Bedeutung für die Arbeit aufgezeigt. Ziel und Anwendungsbereich: In diesem Kapitel soll erläutert werden, welche Ziele die analysierten Implementierungsleitfäden verfolgen und in welchen Bereichen diese eingesetzt werden. Einschränkungen auf Quell-Modell: Dieser Punkt stellt den Kern der Analyse dar. Durch eine zusammenfassende Darstellung der durch den Implementierungsleitfaden eingeschränkten Attribute des Quell-Modells soll ein Vergleich der Leitfäden ermöglicht werden. Relevante Modelle: Dieses Kapitel soll die dem Ansatz zugrunde liegenden Modelle und deren Bedeutung für den jeweiligen Implementierungsleitfaden erläutern. Art der Repräsentation: Zur Repräsentation von in Implementierungsleitfäden beschriebenen Strukturen können verschiedene Formalismen angewandt werden, welche in diesem Kapitel beschrieben werden sollen. Gegenüberstellung mit der HL7 Template-Spezifikation: In diesem Kapitel sollen die Anforderungen der HL7 Template- Spezifikation mit den Gegebenheiten der jeweiligen Implementierungsleitfäden verglichen werden. Durch die Gegenüberstellung soll erörtert werden, inwieweit die Implementierungsleitfäden den Erfordernissen entsprechen, die zukünftig an den Template-Formalismus gestellt werden. Das HL7 Template Modell (siehe Anhang) enthält genaue Vorgaben, wie Templates auszusehen haben und welche Komponenten sie enthalten müssen. Die Leitfäden sollen auch der allgemeinen Definition von HL7 49

54 5 ERGEBNISSE Templates gegenübergestellt werden (vgl. Kapitel 1.1 in [33]), laut der ein Template folgendermaßen zu repräsentieren ist: o durch eine formale Definition in einer oder mehrerer menschenlesbaren Sprachen oder Notationen o (optional) durch ein Static Model 23 o (optional) durch eine oder mehrere implementierungsspezifische Repräsentationen, die zur Validierung von Instanzen in einem speziellen Kontext genutzt werden können 5.2 Ergebnisse der Informationsbeschaffung Im Rahmen der Informationsbeschaffung wurde eine Datenbestandsanalyse in Form einer Literaturanalyse durchgeführt, um den Anwendungsbereich von HL7 Templates zu erfassen. Die Methode der Literaturanalyse wurde deshalb angewendet, da in dem zu analysierenden Bereich bereits ausreichend Dokumentation in angemessener Qualität zu finden war. Als Ergebnis der Literaturanalyse wurden folgende Arbeiten ermittelt: VHitG Arztbrief für das deutsche Gesundheitswesen [12] HL7 Continuity of Care Document (CCD) [44] e-ms Clinical Document Architecture Implementation Guide [45] Guide d implémentation du Volet Médical au format CDA Release 2 Niveau 3 [46] Implementation Guide for CDA Release 2 Level 1 and 2 Care Record Summary (US realm) [13] Implementation Guide for CDA Release 2 Levels 1, 2 and 3 Diagnostic Imaging Report Universal Realm [47] 23 In der Template-Spezifikation wird nicht näher ausgeführt, was mit Static Model genau gemeint ist wie in Kapitel 2.4 bereits erwähnt, wird dieser Begriff von HL7 ja in verschiedenen Bedeutungen verwendet. Im Rahmen der folgenden Analyse wird unter Static Model eine Instanz des in [33] spezifizierten HL7 Template Modells verstanden. 50

55 5 ERGEBNISSE Reha-Kurzbrief auf Basis der HL7 CDA Release 2 [48] Der ärztliche Reha-Entlassungsbericht auf Basis der HL7 CDA Release 2 [49] Addendum zum Arztbrief: Labor auf der Basis der HL7 CDA Release 2 [50] Addendum zum Arztbrief: Medikation auf der Basis der HL7 CDA Release 2 [51] Alle oben erwähnten Leitfäden basieren auf der Clinical Document Architecture Release 2, und schränken diese für ihre jeweiligen Anwendungsbereiche weiter ein. Zur Analyse werden drei ausgewählte Leitfäden heran gezogen der VHitG Arztbrief, das HL7 Continuity of Care Document und die Electronic Medical Summary (e-ms). Die Gründe für die Wahl werden weiter unten erläutert. Die durch die Implementierungsleitfäden spezifizierten Dokumenttypen Arztbrief, Continuity of Care Document und Electronic Medical Summary schränken teilweise unter Referenzierung von Template-Identifikatoren ein allgemeines CDA- Dokument ein. Die für die Analyse ausgewählten Leitfäden wurden von den zuständigen Gremien (der Arztbrief von der HL7 Benutzergruppe Deutschland, das CCD von HL7 und die Electronic Medical Summary von der Vancouver Island Health Authority) anerkannt und sind ausreichend dokumentiert. Weiters werden die Leitfäden häufig in der Fachwelt zitiert und sind daher in der Literatur am häufigsten anzutreffen. Der VHitG Arztbrief wird in Deutschland bereits produktiv eingesetzt und hat sich als geeignetes Mittel zur Speicherung und Übertragung von medizinischer Dokumentation behauptet. In [52] wird adressiert, dass in Stuttgart bis Ende 2005 bereits Arztbriefe verschickt wurden. Im Jahr 2006 waren es monatlich ca Arztbriefe, die über die Doctor 2 51

56 5 ERGEBNISSE Doctor (D2D 24 ) Community ausgetauscht wurden. Der Arztbrief hat in Deutschland einen hohen Stellenwert und wird daher einer genauen Analyse unterzogen. Das Continuity of Care Document wird laut Aussage von Liora Alschuler einer Co-Autorin des CCD-Leitfadens bereits produktiv und mit einer guten Resonanz in den Vereinigten Staaten eingesetzt. Die Gesundheitsversorgung in den USA spielt sich, anders als in Europa, hauptsächlich in den Spitälern ab, darum wird das CCD auch vermehrt in Spitälern eingesetzt. Weiters ist das CCD Prüfkriterium im EMR-Compare Projekt 26 des Medical Records Institutes (MRI), in dem EMR-Systeme aufgrund bestimmter Kriterien geprüft und einander gegenübergestellt werden. Der Electronic Medical Summary (e-ms) CDA Implementation Guide wurde im Rahmen des British Columbia e-ms Projekts, das vom kanadischen Gesundheitsministerium und der British Columbia Medical Association gefördert wurde, erstellt. Das e-ms Projekt war Teil eines Großprojektes des kanadischen Gesundheitsministeriums, das die Einführung eines EHR- Systems in der kanadischen Provinz British Columbia zum Ziel hatte [53]. Der Leitfaden ist sehr gut dokumentiert und enthält viele Beispiel-Codes zu den einzelnen Kapiteln. Aus diesen Gründen stellt der Leitfaden e-ms den dritten zu analysierenden Leitfaden dar. Der Implementierungsleitfaden der französischen HL7-Gruppe Guide d implémentation du Volet Médical steht nur in französischer Sprache zur Verfügung und konnte daher nicht näher analysiert werden. Der Implementierungsleitfaden Care Record Summary ist ein Ansatz, der ähnlich dem Leitfaden CCD aufgebaut ist, weshalb hier nur mit einem geringen Erkenntnisgewinn zu rechnen wäre. Auf eine Analyse wurde daher verzichtet D2D ist eine Software-Ergänzung zu bestehenden Praxisverwaltungssystemen (PVS) und Krankenhausinformationssystemen (KIS). Durch D2D wird eine sichere Übertragung garantiert Persönliche Korrespondenz mit Liora Alschuler

57 5 ERGEBNISSE Der Implementation Guide - Diagnostic Imaging Report befand sich zum Zeitpunkt der Analyse noch in einem nicht finalen Zustand, daher wurde dieser Leitfaden keiner näheren Analyse unterzogen. Reha-Kurzbrief, Reha-Entlassungsbericht, Addendum Labor und Addendum Medikation sind VHitG-Anwendungen, die ähnlich dem Arztbrief aufgebaut sind bzw. Erweiterungen dessen darstellen. Da für diese Leitfäden aufgrund der engen Verwandtschaft zum Arztbrief nur mit geringem Erkenntnisgewinn zu rechnen wäre, wurden diese Leitfäden keiner Analyse unterzogen. 5.3 Ergebnisse der Modellierung und der Verifikation Im Modellierungsschritt wurden die im Zuge der Informationsbeschaffung ermittelten Quelldaten auf Basis des in der Analyseplanung definierten einheitlichen Kriterienkatalogs gegliedert und durch eine einfache textuelle Darstellung aufbereitet. Die resultierenden Darstellungen der untersuchten Implementierungsleitfäden wurden in gemeinsamen Revisionssitzungen mit dem Betreuer der Arbeit überarbeitet Der Implementierungsleitfaden VHitG Arztbrief Der Arztbrief für das deutsche Gesundheitswesen basiert auf der Clinical Document Architecture Release 2 und wurde vom Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.v. (VHitG) erstellt. Da die CDA ein internationaler Standard ist, wurde die Spezifikation des Arztbriefes von der Arbeitsgruppe Sciphox [54] auf die nationalen Bedürfnisse in Deutschland angepasst. Daraus entstand ein ausführlich dokumentierter Implementierungsleitfaden, der Software-Entwicklern die Möglichkeit bietet, den Arztbrief anzuwenden und durch zusätzliche Einschränkungen und Bedingungen zu erweitern und zu verfeinern. Weiters dient er Beratern, die sich mit der Materie näher auseinandersetzen möchten, als Nachschlagewerk. 53

58 5 ERGEBNISSE In den nachfolgenden Punkten wird dieses Dokument nach den in der Analyseplanung gewählten Kriterien analysiert Autoren An erster Stelle der Verfasser dieses Dokuments steht der Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.v. (VHitG). Dieser Verein wurde im Herbst 1995 unter dem Namen VHK (Verband der Hersteller von Krankenhaus-Informationssystemen) gegründet und im Jahr 2001 durch eine Namensänderung in den VHitG umgewandelt. Zu VHK- Zeiten durften nur Unternehmen, die IT-Lösungen für das Krankenhaus herstellten, Mitglied werden. Mit der Verbands-Umstrukturierung und der Änderung des Vorstandes ist es nun jeder Organisation möglich Mitglied zu werden, die Informations- und Kommunikationssysteme herstellt und vertreibt und mit Software-Produkten im Gesundheitswesen einen Jahresumsatz von mindestens Euro erwirtschaftet. Während der Verein mit noch 26 Mitglieder verzeichnete, sind es mit dem Stand vom schon 40 Unternehmen der Gesundheitsbranche. An zweiter Stelle der Autoren steht die HL7 Benutzergruppe Deutschland mit der damals noch existierenden Sciphox Arbeitsgemeinschaft GbR mbh und dem Vorstandsmitglied von HL7 Deutschland, Dr. Kai U. Heitmann. Das Ziel von Sciphox war es, öffentlich diskutierte Vorgaben für Dokumentationsmodelle im Gesundheitswesen auf Basis der CDA zu erarbeiten und bereit zu stellen. Diese Arbeit wurde durch die beiden Trägervereine HL7 Deutschland und dem Qualitätsring medizinische Software (QMS) unterstützt. Mittlerweile ist die Arbeitsgemeinschaft vollständig in die HL7 Benutzergruppe Deutschland übergegangen Ziel und Anwendungsbereich Der Implementierungsleitfaden verfolgt das Ziel, die Eigenschaften und Vorteile eines Arztbrief-Dokuments darzulegen, um zu einem allgemeinen Verständnis der eingesetzten Modelle und Formalismen zu gelangen. Weiters soll dieser Leitfaden mit seinen Beschreibungen und Beispielen als 54

59 5 ERGEBNISSE praktische Implementierungshilfe für Entwickler und Berater gelten. Die Möglichkeiten der Übermittlung von Arztbrief-Dokumenten werden zwar im Leitfaden angesprochen, jedoch nicht näher spezifiziert. Die Anwendung ist zwar von Seiten der Entwickler nicht auf bestimmte Bereiche des Gesundheitswesens beschränkt, primär wird jedoch auf die Kommunikation zwischen niedergelassenen Ärzten und Spitälern fokussiert. Dabei kann der Arztbrief durch zusätzliche Einschränkungen (z.b. auch durch zusätzliche Templates) als stationärer Entlassbrief oder als Facharztbrief zwischen Arztpraxen, Kliniken und Krankenhäusern ausgetauscht werden Einschränkungen auf Quell-Modell Da jeder Arztbrief eine Instanz eines CDA-Dokuments ist, gelten die bereits in Punkt erwähnten Eigenschaften und Charakteristika der CDA auch für den Arztbrief. Ein Arztbrief ist demnach persistent (er wird im System dauerhaft gespeichert) und eine Instanz der Klasse ClinicalDocument in Form eines XML- Dokuments Arztbrief Header Der Header identifiziert das Dokument mit dem Attribut id, das zwingend einmal vorkommen muss. Weiters enthält der Header noch einige Informationen zum Dokument selbst und dessen Erstellung, administrative Inhalte, sowie Informationen zu beteiligten Personen bzw. dem Patienten selbst. Der Header wird in strukturierter Form dargestellt, das bedeutet, dass die Informationen semantisch festgelegt sind und bei einer Übermittlung die Interoperabilität gewahrt wird. 55

60 5 ERGEBNISSE Die generellen Anforderungen an den Header sind wie folgt beschrieben: Jede Person muss durch einen Namen identifiziert sein. Für jeden Heilberufler muss ein Name, eine Adresse und die Telekommunikations-Information angegeben werden. Jede Organisation muss durch einen Namen, eine Adresse und eine Telekommunikations-Information identifiziert sein. In den folgenden Punkten werden jene Klassen und Attribute der CDA (siehe Kapitel ) angeführt, die im Rahmen des Arztbrief- Implementierungsleitfadens eingeschränkt werden: code: Wird in einem Arztbrief-Dokument durch einen LOINC-Code repräsentiert und muss aus einer bestimmten Vokabeldomäne stammen. In Tabelle 1 werden drei repräsentative Beispiele der möglichen Codes repräsentiert. Code Dokumententyp Bezeichnung Deutsche Summarization Zusammenfassung of Episode Note der Behandlungsepisode Discharge Zusammenfassung summarization bei Entlassung note Operative note Operationsbericht Berufsgruppe Heilberufler Arzt Tabelle 1: Auszug aus der Vokabeldomäne für ClinicalDocument.code, übernommen aus [12] effectivetime: Das Erstellungsdatum muss mindestens tagesgenau sein. 56

61 5 ERGEBNISSE languagecode: Im Sprachencode ist das zweigeteilte Format ss-cc zu wählen, wobei der erste Code-Teil der ISO (standardisierter Sprachencode repräsentiert durch zwei Kleinbuchstaben) entstammen muss und der zweite Code-Teil der ISO 3166 (standardisierter Ländercode repräsentiert durch zwei Großbuchstaben), siehe Code-Beispiel 4. <languagecode code= de-de /> Code-Beispiel 4: Beispiel für den Sprachencode, übernommen aus [12] templateid: Dieses Attribut kann an vielen Stellen eines Arztbrief- Dokuments vorkommen, wird aber im Rahmen des Leitfadens nur im Header adressiert und muss dort mit einer von der VHitG vorgegebenen OID belegt werden. Folgende Beteiligte (siehe Kapitel ) werden im Header des Arztbriefs eingeschränkt: recordtarget: Die Patientenrolle (patientrole) muss durch genau einen Patienten (Entität patient) repräsentiert werden. o Der Geburtsort des Patienten (Birthplace) muss eine Adresse mit mindestens <city> oder <country> enthalten. legalauthenticator und authenticator: Das Attribut signaturecode kann die Werte I (Intended die Anbringung einer Signatur ist beabsichtigt), S (Signed die Signatur ist vorhanden) oder R (Required eine Signatur ist erforderlich) annehmen. participant: Das Attribut typecode kann entweder den Wert IND (indirect target nicht direkt an der Dokumentation beteiligt, wie z.b. Angehörige) oder HLD (holder Beteiligter besitzt Dokumente, wie z.b. Verträge, die Übereinkunft mit dem Autor repräsentieren) annehmen. 57

62 5 ERGEBNISSE o AssociatedEntity: Das Attribut classcode darf nur die Werte aus Tabelle 2 annehmen. Die für die Attribute typecode (aus der Beteiligung participant) und classcode geltenden Regeln werden in der Spalte Anmerkungen angeführt. Beschreibung typecode AssociatedEntity. classcode Anmerkungen Angehöriger IND NOK Mindestens eine Person muss angegeben sein Notfall-Kontakt IND ECON Mindestens eine Person muss angegeben sein Besitzer (Halter) einer Versicherungspolizze HLD POLHOLD Mindestens eine Organisation muss angegeben sein Versicherter COV COVPTY Andere Personen oder Organisationen IND PRS Mindestens eine Person muss angegeben sein Tabelle 2: Vokabel Domänen für AssociatedEntity.classCode, übernommen aus [12] Ein Bezug zu einem vorgehenden Dokument ist über die Beziehung relateddocument zur Klasse ParentDocument möglich. Das Beziehungsattribut typecode beschreibt hierbei den Bezug zum Vordokument und kann die Werte APND für Anhang und RPLC für Ersatzbericht annehmen. Die Klasse ParentDocument muss zumindest das Attribut id enthalten. Der Patientenkontakt wird über die Beziehung componentof durch die Klasse EncompassingEncounter beschrieben, wobei das Attribut code die 58

63 5 ERGEBNISSE Werte IMP (Stationärer Aufenthalt), AMB (Ambulanter Aufenthalt) und VR (Kontakt ohne tatsächliche Begegnung) annehmen kann. Über die Beziehung authorization können durch die Klasse Consent Einverständniserklärungen realisiert werden, wobei dabei das Attribut statuscode der Klasse Consent auf completed (repräsentiert die abgeschlossene Einverständnisverklärung) gesetzt wird. Die Beziehung documentationof ermöglicht mit der Klasse ServiceEvent eine Repräsentation einer erbrachten Gesundheitsdienstleistung (z.b. eine Koloskopie), wird aber im Implementierungsleitfaden Arztbrief nicht verwendet Arztbrief Body In der CDA werden zwei Arten von Bodies erlaubt, nämlich StructuredBody und NonXMLBody (Abbildung 7). Der Arztbrief schränkt die CDA insofern ein, als er nur StructuredBody zulässt. Der Body eines Arztbrief-Dokuments besteht aus mindestens einer Section, die narrativen Text, Codes und maschinenauswertbare Repräsentationen des narrativen Textes enthalten kann. Daraus leiten sich die in CDA Release 2 möglichen Strukturierungsgrade ab unconstrained, section-level templates applied und entry-level templates applied. In früheren Spezifikationen der CDA (vor Release 2) waren Strukturierungsgrade der Level 1 bis 3 möglich. Diese Bezeichnung ist in CDA Release 2 nicht mehr üblich, wird jedoch im Implementierungsleitfaden Arztbrief noch angeführt. Aus den Schulungen und Präsentationen von HL7 sind die drei Strukturierungslevel aus Release 1 noch nicht vollständig verschwunden, deshalb werden sie in den folgenden Punkten als Repräsentation für den CDA Release 1 Standard in Klammern angeführt. Die nachfolgende Auflistung soll die Möglichkeiten der Strukturierung eines Arztbrief-Dokuments aufzeigen: 59

64 5 ERGEBNISSE unconstrained (Level 1): Repräsentiert eine ausschließlich menschenlesbare, unstrukturierte Section. Solche Abschnitte sind nicht mit Codes versehen und nicht durch Templates eingeschränkt. Eine Section enthält auf dieser Ebene nur einen optionalen Titel, sowie die klinische Dokumentation in menschenlesbarer Form. Die Lesbarkeit kann durch die Verwendung von Stylesheets (diese ermöglichen die Anwendung von Stilkomponenten, wie z.b. Überschriften, Paragrafen, Tabellen und Listen) für den menschlichen Gebrauch angepasst werden. section-level templates applied (Level 2): Durch die Angabe von Codes (im Arztbrief nur LOINC [37, 55]) können Applikationen die Section identifizieren und verwerten, wodurch eine höhere Strukturiertheit erreicht wird. Weiters können Templates auf Section- Ebene, so genannte section-level templates, zum Einsatz kommen. Neben dem Erzwingen von Elementen, wie z.b. Paragrafen und Abschnitten können solche Templates in Zukunft auch zur Entscheidungsunterstützung herangezogen werden. Die Art der Einschränkung ist eine Folge des Dokumententyps (z.b. ein OP- Bericht stellt andere Anforderungen an einen Abschnitt als ein Pathologie-Befund). entry-level templates applied (Level 3): Auf dieser Ebene können Informationen durch CDA-entries (siehe Kapitel ) maschinenauswertbar gemacht werden. Applikationen, die die Inhalte des Arztbriefs verwerten sollen sind somit in der Lage bestimmte Einzelinformationen, wie z.b. Blutdruck oder Medikationen zu identifizieren und sinnvoll anzuwenden. Auch hier kann der Einsatz von Templates (auf dieser Ebene entry-level templates) bestimmte Vorgaben an das Dokument stellen und somit Einzelinformationen verpflichtend machen. Dazu können bestimmte CDA Body entries (z.b. Observation oder Act) die gleichen Informationen tragen, die auch im Textteil erwähnt werden, jedoch maschinen-lesbar. 60

65 5 ERGEBNISSE <component> <section> <code code=" " codesystem=" " codesystemname="loinc"/> <title>anamnese</title> <text>seit Jahren wiederholt chronische Bronchitiden besonders bei kalter Luft. Bei Anstrengung exspiratorische Atemnot. Kontakt mit Haustieren. </text> <entry>hl7 Version 3 RIM Klassen mit Codes </entry> </section> </component> Code-Beispiel 5: entry innerhalb einer section, übernommen aus [12] In [21] wird bezüglich des Arztbriefs und der CDA oftmals von so genannten Small Semantic Units (SSUs) gesprochen, die im Implementierungsleitfaden jedoch nicht mehr vorkommen. Diese kleinen semantischen Strukturen wurden von Sciphox definiert und wurden in CDA Release 1 für jenen Zweck verwendet, den in CDA Release 2 die entry-level templates erfüllen (z.b. wurden die SSUs Procedure und Observation für den gleichen Zweck erstellt, wie es in CDA Release 2 die jeweiligen entries tun). In CDA Release 1 konnten solche Erweiterungen nur durch lokales Markup 27 realisiert werden, darum forschte man nach einer Möglichkeit, semantische Strukturen in ein klinisches Dokument einbinden zu können. Sciphox konstruierte SSUs, die die Aufgabe hatten, strukturierte Information (z.b. Versicherungsdaten, die aus einer Krankenversicherungskarte übernommen werden können) durch semantische Strukturen darzustellen. Mit dem CDA Release 2 wurden entry-level templates definiert und die genannten SSUs wurden daher nicht mehr verwendet. 27 In CDA Release 1 wurde das XML-Element <local_markup> zur Repräsentation semantischer Inhalte verwendet. 61

66 5 ERGEBNISSE Relevante Modelle Die CDA ist Grundlage aller Arztbrief-Dokumente und stellt somit das Basis- Modell dar. Da die CDA vom RIM abgeleitet ist, besteht natürlich auch ein Bezug zum RIM. Im Leitfaden wird an vielen Stellen auf die in Kapitel erwähnte R-MIM Repräsentation der CDA Bezug genommen, um die verschiedenen Werteinschränkungen des Leitfadens zu erläutern. Weiters flossen in die Entwicklung des Leitfadens Vorarbeiten folgender anderer Leitfäden mit ein: e-ms Clinical Document Architecture Implementation Guide Guide d implémentation du Volet Médical au format CDA Release 2 Niveau 3 Implementation Guide for CDA Release 2 Level 1 and 2 Care Record Summary (US realm) Use Cases for Medical Summaries Art der Repräsentation Ein Arztbrief-Dokument wird in XML repräsentiert und muss den Anforderungen des Implementierungsleitfadens entsprechen. Diese Anforderungen werden neben der textuellen Repräsentation in Form des Leitfadens selbst auch formal repräsentiert, und zwar mittels XML- Schemas und Schematron-Skripts 29. Die beiden letzteren können dann auch zur Validierung herangezogen werden. Im Implementierungsleitfaden wird die Validierung in zwei Schritten definiert: Im ersten Schritt wird der Arztbrief gegen das generische CDA-XML- Schema validiert, das im Rahmen des CDA Release 2 Standards offiziell veröffentlicht wurde

67 5 ERGEBNISSE Im zweiten Schritt können Schematron-Skripts zum Einsatz kommen, mittels derer ein Arztbrief-Dokument auf Konformanz mit den Vorgaben des Implementierungsleitfadens geprüft werden kann. Ein XML-Dokument, das kein valides CDA-Dokument darstellt, bzw. sich nicht gegen das CDA-Schema bzw. gegen die Schematron-Skripts validieren lässt, ist kein gültiger Arztbrief Gegenüberstellung mit der HL7 Template Spezifikation Im Folgenden soll analysiert werden, ob der Implementierungsleitfaden Arztbrief die generellen Anforderungen der Template Spezifikation erfüllt. Der Implementierungsleitfaden repräsentiert die formale Definition in menschenlesbarer Sprache. Das laut Template-Spezifikation optionale Static Model ist im Leitfaden Arztbrief nicht inkludiert, da dieser ja zeitlich vor der Template-Spezifikation entstand. Der Implementierungsleitfaden Arztbrief kann zur Prüfung der Validität gegen das generische CDA-Schema und die im Leitfaden definierten Schematron-Regeln validiert werden. Die obligatorische Anforderung der Template-Spezifikation bezüglich einer menschenlesbaren Definition ist durch den Implementierungsleitfaden Arztbrief damit abgedeckt. Zur Gegenüberstellung des Leitfadens mit dem HL7 Template Modell wird in Code-Beispiel 6 demonstriert, wie ausgewählte Attribute des Headers als Instanz des Template Modells dargestellt werden könnten. 63

68 5 ERGEBNISSE <model abstract="false" name="clinicaldocument" sourcemodel="xy"> <feature xsi:type="attribute" name="id" min="1" max="1"conformance="r" mandatory="true" datatype="ii"/> <feature xsi:type="attribute" name="code" min="1" max="1" conformance="r" mandatory="false" datatype="ce"> <vocabulary extensions="true" valueset=" , , , "/> </feature> <feature xsi:type="attribute" name="title" min="0" max="1"conformance="a" mandatory="false" datatype="st"> </feature> Code-Beispiel 6: Auszug aus Arztbrief-Header-Attributen, modelliert als Instanz des HL7 Template Modells In Code-Beispiel 6 hält das Attribut sourcemodel den Wert xy. Technisch gesehen müsste an dieser Stelle die derzeit noch nicht existente OID des Arztbrief R-MIMs stehen Der Leitfaden Continuity of Care Document (CCD) Der HL7 Leitfaden Continuity of Care Document [44] ist eine Spezifikation, die in Zusammenarbeit mit ASTM International 30 (ursprünglich ASTM American Society for Testing and Materials) entstanden ist. Sie ist aus der Synergie zweier bereits bestehender Dokumentenstandards hervorgegangen der CDA und dem von der ASTM entwickelten Continuity of Care Record (CCR) [56]. Ziel des CCD-Leitfadens ist es, eine Umsetzung des CCR-Standards auf Basis der CDA zu realisieren, indem letztere entsprechend den Anforderungen der CCR eingeschränkt wird. Der CCD- Leitfaden wird in den folgenden Kapiteln ebenfalls nach der festgelegten Kriterienliste analysiert. In [11] wird festgestellt, dass man ein komplettes CCR-Summary- Dokument durch ein document template der CDA ausdrücken könnte

69 5 ERGEBNISSE Durch die Erstellung des CCD-Leitfadens wurde dies erfolgreich in die Tat umgesetzt Autoren Da das CCD aus der Zusammenarbeit zweier großer Standardisierungsorganisationen nämlich HL7 und ASTM International hervorgegangen ist, setzt sich das Autorenteam hauptsächlich aus Mitarbeitern der beiden Unternehmen zusammen. Die Organisation HL7 wurde bereits in Kapitel 2.3 vorgestellt. ASTM International ist einer der weltweit größten und einflussreichsten Entwickler von technischen Standards im Bereich Produkte, Materialien, Systeme und Dienstleistungen auf non-profit -Basis. Das Unternehmen wurde bereits im Jahre 1898 unter dem Namen American Chapter for the International Association for Testing and Materials gegründet und ging später in die American Society for Testing and Materials (ASTM) über. Die Namensänderung in ASTM International zeigt, dass sich das Unternehmen eine globale Anwendung ihrer entwickelten Standards zum Ziel gesetzt hat. Die international anerkannte Arbeit verdankt die Organisation unter anderem ihren über Mitgliedern, die Experten, Produzenten, Konsumenten, Regierung und Akademien aus über 120 Ländern repräsentieren Ziel und Anwendungsbereich Der Leitfaden CCD beschreibt Einschränkungen auf der Clinical Document Architecture Release 2 gemäß den Anforderungen des CCR-Standards. Ein CCR-Dokument enthält die wichtigsten administrativen, demografischen und klinischen Informationen eines Patienten zu einem bestimmten Zeitpunkt. Um die so genannte Continuity of Care also den Fortgang einer Behandlung sicher zu stellen, wurde ein Dokument entwickelt, das eine Momentaufnahme des Patientenstatus enthalten soll. Während durch die Entwicklung der CDA klassische Papierdokumente durch virtuelle Dokumente abgelöst werden konnten, kann ein CCR-Dokument als so genannter summary record, also eine Zusammenfassung des 65

70 5 ERGEBNISSE Gesundheitszustands eines Patienten, verstanden werden. Der Leitfaden CCD wurde entwickelt, um die Vorteile der beiden Standards in sich zu vereinen und somit eine Harmonisierung der Ansätze zu erreichen. Weiters können nun auch jene Institutionen, die bisher an die Anwendung der CDA gebunden waren, die Stärken des Standards von ASTM International nützen Einschränkungen auf Quell-Modell Ein CCD-Dokument besteht wie auch ein Arztbrief-Dokument aus Header und Body. CCR-Dokumente enthalten anders als Arztbrief- und CCD-Dokumente zusätzlich den so genannten Footer, der im Dokument vorkommende Akteure, externe Referenzen, Kommentare und Signaturen hält. All diese Informationen werden im CCD-Leitfaden auf Klassen des Headers und Bodys der CDA abgebildet ( mapping ), die Konformität zu den Klassen des CCR-Footers aufweisen CCD Header Der Header eines CCD-Dokuments besteht aus Klassen und Attributen, die aus den Anforderungen der CCR übernommen und auf CDA-Erfordernisse angepasst wurden. Die Root-Klasse wird durch die ClinicalDocument-Klasse dargestellt (siehe Abbildung 5). Tabelle 3 zeigt, wie die Attribute eines CCR an die Anforderungen der CDA angepasst ( gemapped ) werden: CCR Objekt CCR Unique Identifier Language Version Creation Date/Time CDA Anpassung ClinicalDocument.id ClinicalDocument.languageCode ClinicalDocument.templateId ClinicalDocument.effectiveTime Tabelle 3: CCR-Header Attribute auf CDA ClinicalDocument-Attribute gemapped 66

71 5 ERGEBNISSE Die templateid wird zusätzlich noch in sämtlichen Bereichen des Dokuments bis hinunter auf entry-ebene verwendet und mit jeweils fix vorgegebenen OIDs für die verschiedenen Templates belegt. Die im CCD-Dokument beschriebene Episode einer Gesundheitsversorgung wird durch die Klasse serviceevent dokumentiert (siehe Kapitel ). Dieser Beteiligung, die in einem CCD-Dokument zwingend anzugeben ist, wird der Wert PCPR für patient care provision (Gesundheitsversorgung) zugewiesen. Der Patient selbst wird über die Beziehung recordtarget repräsentiert. Ein CCD-Dokument kann manuell oder automatisiert erstellt werden und enthält dementsprechend den Autor assignedperson oder representedorganization (die für die Generierung verantwortliche Organisation) über die Beziehung author. Optional kann über die Beziehung informationrecipient eine Person oder Organisation spezifiziert werden, an die die Aufzeichnung gerichtet ist. Die Angabe des Zwecks eines CCD-Dokuments wird durch den CCD- Leitfaden nicht zwingend vorgeschrieben und wird bei Bedarf durch eine Section repräsentiert, deren Attribut code den LOINC-Code für Summary purpose und das Attribut title den String purpose enthalten müssen. Folgende Klassen des CCR-Bodys werden in der CCD durch Klassen des Headers repräsentiert. Support: enthält die engsten Angehörigen, Verwandte und Erziehungsberechtigte und wird über ClinicalDocument / recordtarget / PatientRole / Patient / Guardian repräsentiert. Healthcare Providers: repräsentiert die Gesundheitsdienstleister, die in den jeweiligen Fall involviert sind. Sie werden durch die Klasse performer in ClinicalDocument / documentationof / ServiceEvent repräsentiert. 67

72 5 ERGEBNISSE CCD Body Der Body enthält den Kern der patientenbezogenen Daten (wie z.b. Medikationen und medizinische Prozeduren), die in erster Linie aus narrativem Text bestehen. Zusätzlich kann der unstrukturierte Text teilweise oder vollständig durch kodierte Elemente maschinenlesbar gemacht werden. Der CCD-Leitfaden erlaubt ausschließlich die Verwendung des StructuredBody-Elements. Werden die Daten des Bodys dynamisch durch eine Applikation generiert, kann die Applikation entries erstellen, die auf die Ursprungsdaten verweisen (siehe Code-Beispiel 7). Diese Referenzierung ist nicht zwingend vorgeschrieben, wird aber empfohlen. <section> <code/> <title/> <text> <content ID="Blob1">...procedure/code original text... </content> <content ID="Blob2">...act/text uncoded text blob... </content> </text> <entry> <procedure> <code code="12345" codesystem=" "/> <originaltext> <reference value="#blob1"/> </originaltext> </procedure> </entry> <entry> <act> <text> <reference value="#blob2"/> </text> </act> </entry> </section> Code-Beispiel 7: Referenzierung des zugehörigen Narrativblocks von einem entry ausgehend, übernommen aus [44] 68

73 5 ERGEBNISSE Im CCD-Leitfaden werden für jede Header- und Body-Klasse template identifiers definiert, wodurch Templates zur Anwendung kommen können, welche die Einschränkungen des Leitfadens maschinenlesbar repräsentieren. Im Rahmen des CCD-Leitfadens wurden die Templates als Schematron- Skripts implementiert. In den folgenden Punkten sollen die Elemente des CCR-Bodys und deren Repräsentation im CCD-Leitfaden erläutert werden. Die unten angeführten Elemente werden durch Klassen des clinicalstatement-patterns repräsentiert und sind jeweils in eigene Sections eingebettet: Payers: enthält Daten des Zahlenden (z.b. Versicherung oder Patient selbst) und wird durch einen Act repräsentiert. Advance Directives: enthält Patientenverfügungen (z.b. bezüglich einer Reanimation) und Referenzen zu unterstützender Dokumentation und wird durch eine Observation repräsentiert. Referenzen zu externen Dokumenten werden über reference / ExternalDocument ermöglicht. Support: repräsentiert Informationen zu direkten Familienmitgliedern, Verwandten und Erziehungsberechtigten. Ein Erziehungsberechtigter kann durch die Klasse Guardian, andere Patientenunterstützung über den Beteiligten participant realisiert werden. Functional Status: durch diese Klasse werden der physische und mentale Status des Patienten und Abweichungen vom normalen Status dokumentiert. Stati können mittels problem observations oder result observations, sowie als Text repräsentiert werden, falls die ersten beiden nicht anwendbar sind. Problems: stellt eine Aufstellung der Krankengeschichte eines Patienten dar und kann als problem act oder problem observation realisiert werden. Family History: enthält Befunde von Vorfahren des Patienten, um auf mögliche genetische Risiken hinzuweisen und kann als Observation oder Organizer implementiert werden. 69

74 5 ERGEBNISSE Social History: enthält Risikofaktoren und soziale und ökologische Aspekte, wie z.b. Rasse, Familienstand und Religion. Wird in der CCD als Observation realisiert. Alerts: beschreibt Allergien, Nebenwirkungen und Warnungen, die für den Gesundheitszustand des Patienten ausschlaggebend sind. Alerts können über Observations oder Problem Acts (siehe weiter oben) realisiert werden. Medications: diese Klasse beschreibt die vergangenen und derzeitigen Medikationen und kann je nach Anwendungsfall mittels SubstanceAdministration oder Supply dargestellt werden. Medical Equipment: enthält Daten zu implantierten und externen Geräten, die für den Gesundheitszustand des Patienten ausschlaggebend sind. Für Medical Equipment kommen die gleichen Datenobjekte zur Anwendung wie in den Medications. Immunizations: repräsentiert den derzeitigen Immunisierungsstatus, sowie eine Aufstellung der Impfungen (Impfpass). Hier kommen ebenfalls die gleichen Datenobjekte zur Anwendung, wie in den Medications. Vital Signs: enthält Ausprägungen von Lebenszeichen, wie z.b. Puls, Blutdruck, Gewicht und Größe. Sie werden wie Results behandelt (siehe nächster Punkt). Results: enthält Ergebnisse von Untersuchungen, wie z.b. Laborwerte und Röntgenuntersuchungen. Diese können durch die Klassen Organizer oder Observation realisiert werden. Procedures: enthält alle Prozeduren (wie z.b. einen chirurgischen Eingriff). Da der Begriff Prozedur im CCR-Kontext breiter als die Definition von HL7 ist, müssen mehrere Klassen zur Repräsentation in einem CCD-Dokument herangezogen werden Observation, SubstanceAdministration, Procedure, Act. Encounters: beschreibt die Arztbesuche des Patienten (auch Nichtphysische, wie z.b. telefonischer Kontakt) und wird durch die Klasse Encounter repräsentiert. 70

75 5 ERGEBNISSE Plan of Care: enthält zukünftige Prozeduren, Anordnungen und Eingriffe und wird je nach Anwendungsfall durch die Klassen Act, Encounter, Observation, Procedure, SubstanceAdministration oder Supply dargestellt. InternalCCRLink: Repräsentiert einen Verweis von einem Objekt zu einem anderen und wird durch die Klassen entryrelationship / typecode und reference / typecode in einem entry repräsentiert. Alle Datenobjekte eines CCRs müssen eine angegebene Datenquelle (Source) aufweisen, die durch eine Person, Organisation oder eine Referenz zu anderen Datenobjekten repräsentiert wird. Ein CCD-Dokument adressiert diese Quellen mit den CDA-Klassen informant und reference. Datum und Zeit, Namen, Adressen, Telefonnummern, -Adressen und URLs werden in einem CCD-Dokument durch direktes Mapping von CCR- Klassen auf HL7 RIM-Klassen oder Datentypen realisiert CDA Erweiterungen Im CCR-Leitfaden werden einige Anforderungen definiert, die in der CDA nicht realisiert werden können und daher spezielle Erweiterungen erfordern. Um den Anforderungen gerecht zu werden, wurden im CCD-Leitfaden optionale Erweiterungen für ein konformes CCD-Dokument erstellt. Entity Identifiers: In CDA R2 können zwei Beteiligte in verschiedenen Rollen nicht als gleiche Entität identifiziert werden. Zur Lösung des Problems können in einem CCD-Dokument entity identifiers verwendet werden, die bei Anwendung zwei Beteiligte als gleiche Entität identifizieren können. Deceased Indicator and Time: In der Section Family history können Befunde von Familienmitgliedern des Patienten gespeichert werden. Falls das Familienmitglied verstorben ist können zusätzliche Elemente deceasedind und deceasedtime hinzugefügt werden. 71

76 5 ERGEBNISSE Patient Relationship: In CDA R2 können keine Beteiligten (außer dem informant) mit dem Patienten in Bezug gesetzt werden. Aus diesem Grund gibt es in der CCD eine Erweiterung, die es möglich macht, jeden Beteiligten (z.b. den author) über eine relationship role mit dem Patienten in Bezug zu setzen Relevante Modelle CDA und CCR stellen die Grundstrukturen für ein CCD-Dokument dar. Die CDA wurde in Kapitel schon ausführlich behandelt. Nachfolgend wird kurz auf den Continuity of Care Record eingegangen. Ein CCR-Dokument enthält jene Klassen und Attribute, die im Rahmen der CCD-Charakteristika in Kapitel angesprochen wurden. Die Entwicklung des CCR- Leitfadens wurde stark durch Wünsche und Sichtweisen des klinischen Personals beeinflusst und präsentiert sich daher sehr patientenfokussiert. Anders als die CDA, die eine Virtualisierung von medizinischen Dokumenten anstrebt, ist ein CCR-Dokument eine Zusammenfassung des Gesundheitszustands eines Patienten, was in EHRs oftmals als Patient Overview bezeichnet wird. Die derzeit gültige Version 1a wurde als ASTM International Standard anerkannt Art der Repräsentation Ein CCD-Dokument wird durch ein XML-Dokument repräsentiert, um sowohl eine einfache Übermittlung, als auch eine unkomplizierte Darstellung zu ermöglichen. Zur allgemeinen Gültigkeitsprüfung kann ein CCD-Dokument gegen das in Kapitel angesprochene generische CDA-Schema validiert werden. Zusätzlich können Schematron-Schemas zur Validierung herangezogen werden. Mit Hilfe von XSLT-Stylesheets kann das validierte CCD-Dokument in ein HTML-File transformiert werden, um den XML-Code strukturiert in einem Webbrowser anzeigen zu können. 72

77 5 ERGEBNISSE Gegenüberstellung mit der HL7 Template Spezifikation Im Folgenden soll analysiert werden, ob der Implementierungsleitfaden CCD die generellen Anforderungen der Template Spezifikation erfüllt. Die Formale Definition in menschenlesbarer Sprache wird durch den Implementierungsleitfaden selbst repräsentiert. Das laut Template-Spezifikation optionale Static Model ist im Leitfaden CCD nicht inkludiert, da dieser ja zeitlich gesehen vor der Template-Spezifikation entstand. Instanzen des CCD-Leitfadens können mit Hilfe des generischen CDA- Schemas und der im Leitfaden definierten Schematron-Regeln auf Gültigkeit geprüft werden. Die obligatorische Anforderung an ein HL7 Template ist vom CCD-Leitfaden also erfüllt. Um das HL7 Template Modell mit dem CCD-Leitfaden vergleichen zu können werden in Code-Beispiel 8 ausgewählte Attribute des CCD-Headers als Instanz des Template Modells dargestellt. 73

78 5 ERGEBNISSE <model abstract="false" name="clinicaldocument" sourcemodel="xy"> <feature xsi:type="association" name="documentationof" min="1" max="1" conformance="r" mandatory="true" rimname="outboundrelationship"> <target abstract="false" sourcemodel="xy" name="documentationof"> <feature xsi:type="association" conformance="r" mandatory="true" max="1" min="1" name="serviceevent" rimname="target"> <target abstract="false" sourcemodel="xy" name="serviceevent"> <feature xsi:type="attribute" conformance="r" mandatory="true" max="1" min="1" name="classcode" datatype="cs"> <vocabulary extensions="false" domain="actclass" code="pcpr" valueset=" "/> </feature> <derives xref="observation"/> </target> </feature> <derives xref="actrelationship"/> </target> </feature> Code-Beispiel 8: Einschränkung des Attributs classcode der Klasse ServiceEvent, modelliert als Instanz des HL7 Template Modells 74

79 5 ERGEBNISSE Der Electronic Medical Summary Clinical Document Architecture Implementation Guide Der Electronic Medical Summary (e-ms) CDA Implementation Guide wurde im November 2005 finalisiert und im Jänner 2006 offiziell veröffentlicht. Ein e-ms-dokument beinhaltet ausgewählte Patientendaten, die zwischen verschiedenen Gesundheitsdienstleistern ausgetauscht werden, um den Zugriff auf Pflegedaten des Patienten zu gewährleisten Autoren Der Implementierungsleitfaden e-ms wurde von Mitarbeitern der Gesundheitsbehörde in Vancouver Island 31 unter der Mitarbeit der Organisation Gordon Point Informatics Ltd. 32 erstellt Ziel und Anwendungsbereich Ziel dieses Leitfadens ist es, einen Überblick über alle relevanten CDA- Elemente zu geben, die in einer e-ms Implementierung realisiert werden. Es liegt auf der Hand, dass der Leitfaden vorwiegend für Software-Entwickler im EHR-Bereich erstellt wurde. Als Ziel des resultierenden e-ms-dokuments wird die Standardisierung von klinischen Dokumenten zum Zweck des Austauschs adressiert, wenn die Pflege eines Patienten verschiedene Gesundheitsdienstleister durchläuft. Durch diese Standardisierung soll eine höhere Qualität bei der Patientenversorgung und der medizinischen Daten erreicht werden. Der Leitfaden soll nach einem Testverfahren und einer Bewertung durch Anbieter von EHR-Systemen als offizieller Standard in der Gesundheitsversorgung von British Columbia eingesetzt werden. 31 Vancouver Island liegt in der Provinz British Columbia

80 5 ERGEBNISSE Einschränkungen auf Quell-Modell Ein e-ms-dokument besteht aus Header und Body. Der Body muss mindestens auf level 2 ( section-level templates applied, also nicht unstrukturiert) vorliegen. Die Anwendung der in der Superklasse InfrastructureRoot definierten typeid wird im Implementierungsleitfaden nicht adressiert. Anders als bei den Implementierungsleitfäden Arztbrief und CCD beinhaltet der Implementierungsleitfaden e-ms ein vollständiges R- MIM, das die eingeschränkten Klassen, Attribute und Beziehungen der CDA grafisch repräsentiert. Die Bedeutung der einzelnen Elemente wurde großteils bereits in Kapitel besprochen, deshalb wird im Folgenden nur auf Besonderheiten und die nicht im R-MIM enthaltenen Business Rules eingegangen. Im Implementierungsleitfaden wird speziell darauf eingegangen, ob ein Element (Klasse, Beziehung oder Attribut) des R-MIMs in einem e-ms- Dokument vorkommen muss oder nicht, wobei es folgende Möglichkeiten gibt: Mandatory (M): Das Element muss im Dokument vorkommen. Required (R): Das Element muss unterstützt werden. Falls die betreffenden Daten vorliegen muss das Element im Dokument adressiert sein. Falls die Daten nicht vorliegen muss ein nullflavor gesetzt werden. Optional (O): Das Element kann im Dokument vorkommen, muss aber nicht. Not Supported (X): Das Element darf nicht im Dokument vorkommen. Im Implementierungsleitfaden wird eine Nomenklatur verwendet, die aufbauend auf den oben erwähnten Eigenschaften verschiedene Kombinationen aus dem Grad der Strukturiertheit (im Leitfaden wird die veraltete Bezeichnung level 2 und level 3 verwendet) und den so genannten conformance indicators (M, R, O, X) adressiert. Der Header eines e-ms- Dokuments liegt immer in strukturierter Form vor und trägt daher die 76

81 5 ERGEBNISSE Bezeichnung O2 für optional in level 2 und je nach Kardinalität des Elements entweder R3 (Required in level 3) oder M3 (Mandatory in level 3). Diese Nomenklatur zieht sich durch den gesamten Implementierungsleitfaden und bietet somit eine gute Möglichkeit, die verschiedenen Elemente des e-ms-dokuments zu charakterisieren e-ms Header In Abbildung 13 werden jene Klassen, Attribute und Beziehungen des CDA- Headers angeführt, die im Rahmen des e-ms Implementierungsleitfadens eingeschränkt werden. Das Attribut code in der Klasse ClinicalDocument repräsentiert den Dokumenttyp und spezifiziert das Dokument als Überweisung, Befragung oder Krankenbericht. Das Attribut typecode der Beziehung relateddocument kann die Werte APND (Antwort auf ein vorheriges Dokument) oder RPLC (ersetzt ein anderes Dokument) annehmen. 77

82 5 ERGEBNISSE Abbildung 13: R-MIM des e-ms Headers, übernommen aus [45] 78

83 5 ERGEBNISSE e-ms Body Im Folgenden sollen die Elemente des e-ms Bodys und deren Repräsentation in der CDA erläutert werden. Die folgenden Sections sind bis auf Purpose optional. Die Inhalte werden auf der Ebene section-level templates applied und optional auf der Ebene entry-level templates applied mit Observations dargestellt, wenn in den unten angeführten Punkten nicht ausdrücklich eine andere Darstellung angeführt wird. Das Attribut Observation.code wird im Leitfaden nicht verwendet. Da das Schema dieses Attribut verlangt muss ihm der nullflavor NA (not applicable) zugewiesen werden. Purpose: Der Zweck des Dokuments beinhaltet den Grund für die Erstellung des Dokuments, die Dringlichkeit und involvierte Gesundheitsdienstleister. Alerts: Weist auf für den Gesundheitsdienstleister besonders zu beachtende Faktoren hin (auch z.b. ein Testament). Social History / Risks: Die soziale Geschichte des Patienten und Risiken identifizieren Faktoren, die medizinischen Einfluss auf die Patientenversorgung haben (z.b. Raucher). Examination Measurements: Repräsentiert Größe, Gewicht, Blutdruck und Puls. Active Problem List: Diese Liste beinhaltet Informationen zu derzeitigen Problemen und Diagnosen, die den Fortgang der Patientenversorgung beeinflussen könnten (z.b. Hypertonie). Current Medications: Repräsentiert Medikamente die der Patient derzeit zu sich nimmt. Die Inhalte können auf der Ebene entry-level templates applied in der Klasse SubstanceAdministration gespeichert werden. 79

84 5 ERGEBNISSE Medical History: Die Krankengeschichte beinhaltet vergangene Diagnosen, die auf die Patientenversorgung Einfluss nehmen könnten (z.b. auch Schwangerschaften). Surgical History: Repräsentiert Informationen über vergangene chirurgische Eingriffe, deren Inhalte in Sections und Procedures gespeichert werden. Medical Imaging History: Beinhaltet Informationen zu vergangenen, abgeschlossenen Bildgebungsverfahren (wie z.b. Röntgen, CT, MR) Other Treatments: Dieses Element repräsentiert andere Behandlungen oder Therapien des Patienten (z.b. pflanzliche Heilmittel). Allergies: Gibt Auskunft über Allergien und Nebenwirkungen eines Patienten. Immunization: Repräsentiert die Impfungen eines Patienten. Labs: Gibt Auskunft über durchgeführte Labortests. Past Referrals and/or Hospitalizations: Beinhaltet Informationen zu vergangenen Überweisungen oder Krankenhaus-Einweisungen, die die Behandlung des Patienten beeinflussen könnten. Die Inhalte können durch Sections oder die Klasse Encounter repräsentiert werden. Family History: Die Familiengeschichte gibt Auskunft über vergangene oder derzeitige Gegebenheiten von Familienmitgliedern des Patienten, die Auswirkungen auf die Behandlung des Patienten haben könnten. Observation Media: Repräsentiert Anhänge, die Dokumente darstellen. Die Inhalte werden in den Attributen der Klasse ObservationMedia gespeichert. 80

85 5 ERGEBNISSE Abbildung 14: R-MIM des e-ms Bodys Teil 1, übernommen aus [45] 81

86 5 ERGEBNISSE Abbildung 15: R-MIM des e-ms Bodys Teil 2, übernommen aus [45] 82

87 5 ERGEBNISSE Relevante Modelle Die CDA ist, wie auch bei den anderen analysierten Leitfäden, die Grundstruktur für alle e-ms-dokumente Art der Repräsentation Ein e-ms-dokument wird als XML-Dokument gespeichert. Zur Validierung von e-ms-dokumenten wurde ein CDA-konformes Schema erstellt, das die Einschränkungen des Implementierungsleitfadens beinhaltet. Weiters wurde von den Editoren ein Schematron-Schema erstellt das die so genannten Business Rules des Leitfadens enthält und die CDA durch Anwendung der Regeln weiter einschränkt (z.b. das Erzwingen eines bestimmten Codes in einem bestimmten Attribut). Zur grafischen Repräsentation der Klassen, Attribute und Beziehungen eines vollständigen e-ms-dokuments wurde das R-MIM der CDA auf die Erfordernisse der e-ms angepasst und ein spezifisches R-MIM erstellt Gegenüberstellung mit der HL7 Template Spezifikation Im Folgenden soll analysiert werden, ob der Implementierungsleitfaden e- MS die generellen Anforderungen der Template Spezifikation erfüllt. Der Implementierungsleitfaden e-ms repräsentiert die formale Definition in menschenlesbarer Sprache. Das laut Template-Spezifikation optionale Static Model ist im Leitfaden e-ms nicht inkludiert, da dieser ja zeitlich gesehen vor der Template-Spezifikation entstand. Der Implementierungsleitfaden e-ms enthält ein speziell für e-ms- Dokumente entwickeltes Schema, das zur Validierung herangezogen werden kann. Regeln, die nicht im Schema enthalten sind können durch ein im Leitfaden enthaltenes Schematron-Schema abgeprüft werden. 83

88 5 ERGEBNISSE Die obligatorische Anforderung an ein HL7 Template wird also auch vom e- MS Implementierungsleitfaden erfüllt. Im Folgenden werden ausgewählte Attribute des e-ms Headers als Instanz des HL7 Template Modells abgebildet. <model abstract="false" name="clinicaldocument" sourcemodel="xy"> <feature xsi:type="attribute" name="id" min="1" max="1" conformance="r" mandatory="true" datatype="ii"/> <feature xsi:type="attribute" name="code" min="1" max="1" conformance="r" mandatory="false" datatype="ce"> <vocabulary extensions="true" valueset=" "/> </feature> <feature xsi:type="attribute" name="title" min="1" max="1" conformance="r" mandatory="true" datatype="st"/> <feature xsi:type="attribute" name="effectivetime" min="1" max="1" conformance="r" mandatory="true" datatype="ts"/> Code-Beispiel 9: Abbildung von e-ms Header-Attributen als Instanz des HL7 Template Modells 84

89 5 ERGEBNISSE 5.4 Gegenüberstellung von HL7 Templates und CEN Archetypen Der HL7 Template Ansatz ist ein Konzept, das aufgrund seiner Möglichkeiten und Ziele sehr große Ähnlichkeit zum Archetyp-Ansatz aufweist. Dieser wurde wie bereits eingehend in Kapitel 2.2 besprochen erstmals durch die Organisation openehr vorgestellt und später durch CEN übernommen und normiert. Aufgrund der Ähnlichkeit von HL7 Templates und CEN Archetypen soll im Folgenden ein grober Vergleich der zugrunde liegenden Modelle erstellt werden, der die Unterschiede und Analogien beider Strukturen aufzeigen soll. Abbildung 16: Gegenüberstellung der Modelle von CEN und HL7 85

90 5 ERGEBNISSE Auf den ersten Blick ist zu sehen, dass HL7 weitaus mehr Modelle spezifiziert als CEN, deren Architektur aus RM (Referenzmodell) und AT (Archetyp) besteht. Ausgegangen wird in beiden Fällen von einem Referenzmodell, das die nötigen Klassen, Beziehungen und Attribute zur Erstellung spezifischerer Modelle enthält. Bei näherer Betrachtung von RM und RIM lässt sich erkennen, dass diese sehr unterschiedlich definiert sind. Das Referenzmodell von CEN enthält bereits Möglichkeiten, Instanzen bis auf Section- oder Entry-Ebene zu strukturieren. Das RIM setzt hingegen auf einer abstrakteren Ebene an, wodurch weitere Modelle und Mechanismen (z.b. Refinement- und Constraintmechanismen) notwendig werden, um die Klassen des RIM auf die Erfordernisse eines EHRs anpassen zu können. Mittels der Clinical Document Architecture (CDA) wurde ein derartiges EHRnahes Modell vom RIM abgeleitet, das in etwa dem Teilmodell des RM ab der Klasse COMPOSITION entspricht. Aufgrund dieser Erkenntnisse wird das RM in Abbildung 16 der CDA gegenübergestellt. Der CEN Archetyp ist eine Instanz des Archetype Object Models (AOM) siehe Abbildung 1 und definiert Einschränkungen auf das RM. Das HL7 Template ist eine Instanz des HL7 Template Modells und schränkt entweder das RIM selbst oder ein vom RIM abgeleitetes Modell ein. Die beiden Ansätze verfolgen grundsätzlich das gleiche Ziel und sollen zukünftig auch in gemeinsamen Registern gespeichert werden und gegenseitig kompatibel sein. Die Bedeutung von D-MIM, R-MIM und Implementierungsleitfaden (IMPL) wurde im Lauf der Arbeit bereits erläutert. Der Implementierungsleitfaden wird in Abbildung 16 auf die gleiche Ebene wie das HL7 Template gestellt, da Leitfäden Template-Strukturen enthalten können. Der Begriff Template wurde von CEN in deren Draft Version pren verwendet. Die Definition in [1] besagt, dass ein Template im CEN-Kontext eine semantische Einschränkung von Archetypen wie beispielsweise in einem Formular benötigt repräsentiert. Der Begriff wurde von openehr eingeführt und wird im offiziellen CEN-Standard EN [19] nicht mehr 86

91 5 ERGEBNISSE adressiert. Im openehr-kontext wird das Template-Konzept jedoch weiterhin verwendet. Gegenüberstellung von HL7 Template Modell und CEN Archetype Object Model Die beiden Modelle (siehe Anhang) unterscheiden sich auf den ersten Blick dadurch, dass das Archetype Object Model eine Paketstruktur aufweist, wobei diese nur der besseren Überschaubarkeit dient. In der Gegenüberstellung werden nur die vier Haupt-Packages Archetype Package, Archetype Description Package, Constraint Model Package und Ontology Package berücksichtigt. In den folgenden Abbildungen werden Ausschnitte der beiden Modelle repräsentiert durch Klassen und Beziehungen dargestellt und einander gegenüber gestellt. Im ersten Teil des Vergleichs werden ausgehend von den Root-Klassen jene Klassen und Beziehungen beschrieben, die mit der Root-Klasse in Beziehung stehen und den Header eines Templates bzw. Archetyps darstellen. 87

92 5 ERGEBNISSE Abbildung 17: Klassen zur Definition des Templates, adaptiert übernommen aus [33] Die Klasse Template ist der Entry-Point in das Template-Modell und erbt alle Attribute der Klasse TemplateMetadata, welche die Definition der Bedeutung, den Nutzen und den Zweck des Templates beschreiben. Die Klasse TemplateMetadata ist über Beziehungen (Kompositionen) mit den Klassen Revision, Identifier und NameAndContact verbunden, die den Autor, Identifikations- und Revisionsdaten des Templates darstellen. Die Klassen RIM und Attachment sind vorgeschriebene Teile einer Template- Instanz und enthalten die RIM-Definition und Anhänge zur Darstellung von zusätzlichen Informationen zum Template (z.b. Schematron-Regeln oder eine grafische Repräsentation des Static Models). Die Klasse RIM ist über die Beziehung classes mit der Klasse RimClass verbunden, über die die RIM- Klassen repräsentiert werden, die dem Template zugrunde liegen. Über die Beziehung model gelangt man zum Hauptteil des Templates, der die Einschränkungen enthält (siehe Abbildung 19). 88

93 5 ERGEBNISSE Die oben erwähnten Klassen des Template Modells werden den Klassen des Archetype Object Models in Abbildung 18 gegenüber gestellt, da diese großteils den gleichen Zweck erfüllen. Abbildung 18: Klassen zur Beschreibung eines Archetyps, adaptiert übernommen aus [19] Die Klasse Archetype stellt die Root-Klasse eines Archetyps dar und ermöglicht mit Hilfe der enthaltenen Attribute die Identifikation des Archetyps. In den Klassen Archetype_Description und Archetype_Description_Item werden beschreibende Informationen, wie z.b. Autor und Zweck des Archetyps spezialisiert. Über die Beziehung revision_history kann die Klasse Audit_Details Informationen zur Revision des Archetyps und zu einer Übergabe an ein Repository enthalten. Die Klasse C_Complex_Object ist über die Beziehung definition mit der Klasse Archetype verbunden und repräsentiert den Einstiegspunkt in den Hauptteil des Archetyps. Informationen zu Übersetzungen des Archetyps können über die Beziehung translations in der Klasse Translation_Details gespeichert werden. 89

94 5 ERGEBNISSE Der zweite Teil der Gegenüberstellung soll die Klassen des Hauptteils von Template und Archetyp miteinander vergleichen. Abbildung 19: Klassen zur Repräsentation von Einschränkungen, adaptiert übernommen aus [33] Wie oben bereits angeführt gelangt man über die Beziehung model zur Klasse CloneClass (in [33] teilweise auch als ConstrainedClass bezeichnet), über die man in den Hauptteil des Templates gelangt (siehe Abbildung 19). Dieser enthält die Einschränkungen, die auf das einzuschränkende Modell (in der Spezifikation als Static Model bezeichnet) angewendet werden, jedoch nicht zwingend in einem Template enthalten sein müssen. Eine CloneClass kann Auswahlmöglichkeiten (über die Beziehung choices), Assoziationen und Attribute enthalten, wobei choices nur in abstrakten Klassen und Attribute nur in nicht abstrakten Klassen vorkommen können. Die Darstellung der eingeschränkten Attribute und Assoziationen in einem Template geschieht über die Klasse Feature, die Attribute der Klassen Attribute und Association erbt. Werden Assoziationen eingeschränkt, gelangt man über die Beziehung target wieder zurück in die Klasse CloneClass und der Zyklus beginnt von Neuem. Über die Klasse 90

95 5 ERGEBNISSE VocabularyConstraints können eingeschränkte Attribute weiter spezifiziert werden. Zusätzliche Einschränkungen von Features, oder der Template-Instanz selbst, können über die Klasse Constraint verwirklicht werden, jedoch nur in der Sprache OCL. Abbildung 20: Klassen zur Repräsentation von Einschränkungen, adaptiert übernommen aus [19] Im Vergleich dazu gelangt man im Archetype Object Model über die Beziehung definition in den Hauptteil eines Archetyps, der die Einschränkungen des Referenzmodells enthält (siehe Abbildung 20). Dieser muss zwingend vorkommen und beginnt mit einer Instanz der Klasse C_Complex_Object. Alle Knoten einer Archetyp-Definition sind Instanzen des Supertyps Archetype_Constraint. 91

96 5 ERGEBNISSE Die Klasse C_Attribute ist über die Beziehung features mit der Klasse C_Complex_Object verbunden und repräsentiert die eingeschränkten Attribute (und Beziehungen) des Referenzmodells. Attribute, die nur einen Wert enthalten (wie z.b. ein Geburtsdatum) werden mit Hilfe der Klasse C_Single_Attribute eingeschränkt. Die Klasse C_Multiple_Attribute stellt eingeschränkte Attribute dar, die mehrere Werte enthalten können (wie z.b. eine Liste). Die Klasse C_Attribute ist falls sie eine Einschränkung auf eine Beziehung darstellt über die Beziehung children mit der Klasse C_Object verbunden, welche die Einschränkungen auf das Objekt repräsentiert, welches die Beziehung referenziert. Die Klasse C_Primitive_Object repräsentiert Einschränkungen auf Instanzen primitiven Typs (z.b. Integer, String und Boolean). Über die Klasse Archetype_Slot können dem Archetyp weitere Archetypen angehängt werden (Verschachtelung), die weitere Beschreibungen und Einschränkungen enthalten können. Die Klasse Assertion wird zur Repräsentation von Einschränkungen mit Hilfe von Prädikatenlogik verwendet. Der dritte Teil der Gegenüberstellung vergleicht jene Klassen des HL7 Template Modells und des AOM, die zur Repräsentation von Terminologien verwendet werden können. Abbildung 21: Klasse zur Repräsentation von Terminologien, adaptiert übernommen aus [33] 92

97 5 ERGEBNISSE In der Klasse Term des Template Modells (siehe Abbildung 21) können Informationen zu Referenz-Terminologien gespeichert werden. Die Syntax wird im Codesystem definiert, die das Konzept beschreibt. Abbildung 22: Klasse zur Repräsentation von Terminologien, adaptiert übernommen aus [19] Terminologien können im AOM in der Klasse Archetype_Ontology (siehe Abbildung 22) dargestellt werden. Die Gegenüberstellung der beiden Modelle zeigt, dass sehr viele Ähnlichkeiten zwischen den Modellen bestehen und daher Archetypen und Templates ähnlich implementiert werden können. Es bestehen allerdings auch Unterschiede, die im Folgenden nochmals kurz zusammengefasst werden sollen: Das AOM erlaubt die Verschachtelung von mehreren Archetypen (Archetype_Slot). Aus dem Template Modell ist eine ähnliche Möglichkeit nicht ersichtlich, HL7 sieht für diesen Zweck jedoch die Referenz von CMETs vor (siehe Abbildung 11). Auswahlmöglichkeiten werden im HL7 Template Modell durch choices vorgesehen. Im AOM gibt es eine ähnliche Implementierung nicht. 93

98 5 ERGEBNISSE Das AOM repräsentiert im Gegensatz zum HL7 Template Modell Attribute und Beziehungen über dieselben Klassen. Attachments werden im AOM nicht berücksichtigt. Ein großer Unterschied von Templates und Archetypen zeigt sich in der Festlegung, welche Klassen, Beziehungen und Attribute in der eingeschränkten Instanz vorkommen müssen. CEN definiert in [19], dass ein Archetyp nur die eingeschränkten Teile des Referenzmodells repräsentiert. Im Kapitel Incompleteness der Template Spezifikation wird darauf hingewiesen, dass ein Template so unvollständig wie möglich sein sollte, um eine mögliche Wiederverwendung garantieren zu können. Laut Grahame Grieve dem Autor der Template Spezifikation müssen jedoch alle Attribute im Template wiederholt werden, auch wenn sie keine Einschränkung auf dem einzuschränkenden Modell repräsentieren. Dieses Bild zeigt sich auch im Beispiel-XML-Dokument des Barthel-Index in der Template Spezifikation. 94

99 6 DISKUSSION 6 Diskussion Die in dieser Arbeit angewandte Methode stützt sich auf das Vorgehensmodell nach Ammenwerth und Haux, das in [43] definiert wurde. Das Vorgehensmodell ist Teil des taktischen Managements von Informationssystemen und wurde auf die Erfordernisse der Diplomarbeit angepasst. Aufbauend auf dem Vorgehensmodell wurde eine Analyse von drei ausgewählten Implementierungsleitfäden aufgrund eines definierten Kriterienkatalogs durchgeführt. Die Aufbereitung der Implementierungsleitfäden nach einheitlichen Kriterien stellte sich als gute Methode zur Analyse von komplexen und umfangreichen Arbeiten heraus. Durch die übersichtliche Darstellung der wichtigsten Teile können die Leitfäden einander gegenüber gestellt und somit Analogien und Unterschiede verdeutlicht werden. In den Gegenüberstellungen der einzelnen Implementierungsleitfäden mit der HL7 Template Spezifikation ist zu erkennen, dass Teile der Leitfäden mit der Spezifikation überein stimmen. Durch die Abbildung von Fragmenten der Leitfäden als Instanz des HL7 Template Modells wird skizziert, wie ein HL7 Template in Zukunft aussehen könnte. Nach Standardisierung des Template-Konzeptes kann die Instanzierung eines vollständigen Templates als Ziel zukünftiger Arbeiten gesehen werden. HL7 Templates befinden sich derzeit in einem Entwicklungsstadium. Die HL7 Template Spezifikation besteht derzeit noch in der Version Draft Standard for Trial Use und wird nach Fertigstellung aller Arbeiten im Falle einer positiven Abstimmung in einem Balloting-Verfahren als offizieller HL7 Standard anerkannt. Die Template Spezifikation wirkt an manchen Stellen noch unfertig und weist teilweise Fehler und Unklarheiten im Text und in den Modellen auf. 95

100 6 DISKUSSION Vor allem das HL7 Template Modell und das zugehörige Schema widersprechen sich in einigen Punkten. Die Kardinalität der Klasse Attachment ist im Template-Modell mit 1..* und im Schema mit 0..* deklariert. Es ist nicht definiert, wann Klassennamen und wann Bezeichnungen der Beziehungen zur Repräsentation der XML-Elemente im Schema verwendet werden. Die Klasse CloneClass des Template-Modells wird in der Dokumentation als ConstrainedClass bezeichnet. Fehler und Unklarheiten sollten mit der nächsten Abstimmung behoben werden. 96

101 7 ZUSAMMENFASSUNG UND AUSBLICK 7 Zusammenfassung und Ausblick Ziel dieser Arbeit war es, den Anwendungsbereich von HL7 Templates sowie den aktuellen Entwicklungsstand des zugrunde liegenden Frameworks zu erheben und zu analysieren. Der erste Teil der Arbeit beschäftigte sich mit den Konzepten, die dem HL7 Template zugrunde liegen, und theoretischen Grundlagen zu semantischer Interoperabilität und Dualer Modellierung. Weiters wurde der Template Formalismus auf Basis der HL7 Template Spezifikation dargestellt und auf die Eigenschaften des Ansatzes eingegangen. Der Stand der Forschung brachte einen Einblick in internationale Arbeiten im Bereich multimodell-basierter Architekturen des Gesundheitswesens und praktischer Anwendungen von Templates und Archetypen. Im Rahmen der Informationsbeschaffung wurde eine Literaturanalyse im Bereich der führenden Standardentwickler für das Gesundheitswesen durchgeführt. Daraus wurden zehn Implementierungsleitfäden ermittelt, die auf der CDA basieren und diese aufgrund der jeweiligen Anforderungen einschränken. Aus diesen Leitfäden wurden drei in der Praxis häufig eingesetzte Arbeiten ausgewählt und einer ausführlichen Analyse unterzogen. Im Ergebnisteil der Arbeit wurden die Implementierungsleitfäden anhand eines in der Analyseplanung erstellten Kriterienkatalogs untersucht, um eine einheitliche Vergleichsbasis der Leitfäden zu schaffen. Weiters wurden die Leitfäden den aktuellen Erfordernissen der HL7 Template Spezifikation gegenübergestellt, um zu ermitteln, inwieweit die Arbeiten bereits den Anforderungen entsprechen, die zukünftig an ein HL7 Template gestellt werden. Durch Beispiel-XML-Fragmente wurde gezeigt, wie Instanzen des HL7 Template Modells generiert werden können. Aufgrund der engen Verwandtschaft von HL7 Templates und CEN Archetypen wurden die beiden Modelle zur Instanzbildung von Templates und Archetypen untersucht und einander gegenüber gestellt. 97

102 7 ZUSAMMENFASSUNG UND AUSBLICK Das HL7 Template ist nur eine mögliche Anwendung von HL7, um Einschränkungen auf Modelle anzuwenden. Im HL7-Kontext gibt es mehrere laufende Projekte, die sich mit der Anwendung von Constraints auf bestehende Modelle beschäftigen z.b. OCL als Constraint-Language in vom RIM abgeleiteten Modellen 33 oder das Projekt Refinement, Constraint and Localization, Release In letzterem werden die bereits erwähnten CMETs beschrieben sowie so genannte Constraint Profiles erläutert, die speziell für die Einschränkung von R-MIMs verwendet werden können. Eine Gegenüberstellung von HL7 Templates mit den erwähnten weiteren Einschränkungsmöglichkeiten ist nicht Thema dieser Arbeit und kann in zukünftigen Arbeiten adressiert werden. HL7 Templates sollen in Zukunft zur Entscheidungsunterstützung und zur Validierung von Gesundheitsdaten herangezogen werden. Diese Anwendungsmöglichkeiten sehe ich persönlich aufgrund des derzeitigen Status von Templates als zukünftige Vision und bedarf noch weiterer Forschung und Weiterentwicklung des Konzeptes. Derzeit wird von HL7 am Release 3 der CDA gearbeitet. Dieser Standard wird viele Neuerungen mit sich bringen, die im Rahmen einer Wiki-Seite diskutiert werden. Ein großer Unterschied zum Release 2 wird sich im Clinical Statement Model der CDA zeigen. Dieses wird sich laut Robert H. Dolin 36 bedeutend erweitern. Eine Erweiterung Strukturebenen auf Level 4 ist ebenfalls in Planung. Ein Abschluss der Entwicklungsarbeiten ist zum jetzigen Zeitpunkt noch nicht absehbar Vorsitzender des CDA R2 Projekts 98

103 Danksagung An dieser Stelle möchte mich bei Ao. Univ.-Prof. Dipl.-Ing. Dr. Georg Duftschmid bedanken, der mir als Betreuer meiner Diplomarbeit stets mit Rat und Tat zur Seite stand. Weiters danke ich meiner Freundin Miriam Arocker für die Unterstützung während der Studienzeit und meinen Eltern, die mir das Studium ermöglicht haben. 99

104 Abbildungsverzeichnis Abbildung 1: Archetyp-Modell Meta-Architektur, übernommen aus [9] Abbildung 2: Die 6 Core-Klassen des HL7 RIM, übernommen aus [23] Abbildung 3: HL7 Reference Information Model, übernommen aus [23] Abbildung 4: Message Development Modelle, übernommen aus [27] Abbildung 5: CDA R2 Header mit Beteiligten, übernommen aus [30] Abbildung 6: CDA R2 Header Beziehungen, übernommen aus [30] Abbildung 7: CDA R2 Section, übernommen aus [30] Abbildung 8: CDA R2 Body entries, übernommen aus [30] Abbildung 9: Modell des "Barthel-Index", übernommen aus [33] Abbildung 10: Constraint Information Modell, übernommen aus [33] Abbildung 11: Flach strukturierter Barthel-Index mit CMETs, übernommen aus [33] Abbildung 12: Vorgehensmodell zur Systemanalyse nach Ammenwerth und Haux, adaptiert übernommen aus [43] Abbildung 13: R-MIM des e-ms Headers, übernommen aus [45] Abbildung 14: R-MIM des e-ms Bodys Teil 1, übernommen aus [45] Abbildung 15: R-MIM des e-ms Bodys Teil 2, übernommen aus [45] Abbildung 16: Gegenüberstellung der Modelle von CEN und HL Abbildung 17: Klassen zur Definition des Templates, adaptiert übernommen aus [33] Abbildung 18: Klassen zur Beschreibung eines Archetyps, adaptiert übernommen aus [19] Abbildung 19: Klassen zur Repräsentation von Einschränkungen, adaptiert übernommen aus [33] Abbildung 20: Klassen zur Repräsentation von Einschränkungen, adaptiert übernommen aus [19] Abbildung 21: Klasse zur Repräsentation von Terminologien, adaptiert übernommen aus [33] Abbildung 22: Klasse zur Repräsentation von Terminologien, adaptiert übernommen aus [19]

105 Tabellenverzeichnis Tabelle 1: Auszug aus der Vokabeldomäne für ClinicalDocument.code, übernommen aus [12] Tabelle 2: Vokabel Domänen für AssociatedEntity.classCode, übernommen aus [12] Tabelle 3: CCR-Header Attribute auf CDA ClinicalDocument-Attribute gemapped Code-Beispiel-Verzeichnis Code-Beispiel 1: Das XML-Fragment "typeid", übernommen aus [30] Code-Beispiel 2: Observation innerhalb einer section, übernommen aus [10] Code-Beispiel 3: Testfall-Spezifikation in XML zur Pfadabfrage, übernommen aus [41] Code-Beispiel 4: Beispiel für den Sprachencode, übernommen aus [12] Code-Beispiel 5: entry innerhalb einer section, übernommen aus [12] Code-Beispiel 6: Auszug aus Arztbrief-Header-Attributen, modelliert als Instanz des HL7 Template Modells Code-Beispiel 7: Referenzierung des zugehörigen Narrativblocks von einem entry ausgehend, übernommen aus [44] Code-Beispiel 8: Einschränkung des Attributs classcode der Klasse ServiceEvent, modelliert als Instanz des HL7 Template Modells Code-Beispiel 9: Abbildung von e-ms Header-Attributen als Instanz des HL7 Template Modells

106 Literaturverzeichnis [1] International Organization for Standardization. ISO/TR 20514:2005 Health informatics -- Electronic health record -- Definition, scope and context; [2] CEN/TC 251 WG1. Health informatics - Electronic health record communication - Part 1: Reference model; Report No.: EN [3] Kalra D. Electronic health record standards. Yearb Med Inform. 2006: [4] Waegemann C. The five levels of electronic health records. MD Comput May-Jun;13(3): [5] Waegemann C. Current Status of EPR Developments in the US. Toward An Electronic Health Record Europe 99; 1999; Newton, MA: Medical Records Institute; p [6] Dorda W, Duftschmid G, Gerhold L, Gall W, Gambal J. Austria's path toward nationwide electronic health records. Methods Inf Med. 2008;47(2): [7] Bundesministerium für Gesundheit und Frauen Familie und Jugend. Machbarkeitsstudie ELGA [cited 2008 September]; Available from: /machbarkeitsstudie_elga.pdf [8] Beale T. Archetypes and the EHR. Stud Health Technol Inform. 2003;96: [9] Beale T. Archetypes: Constraint-based Domain Models for Futureproof Information Systems [cited 2008 January]; Available from: [10] Dolin RH, Alschuler L, Boyer S, Beebe C, Beilen FM, Biron PV, et al. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2006;13(1):

107 [11] Ferranti JM, Musser RC, Kawamoto K, Hammond WE. The clinical document architecture and the continuity of care record: a critical analysis. J Am Med Inform Assoc May-Jun;13(3): [12] Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.v. Implementierungsleitfaden Arztbrief [cited 2008 September]; Available from: VHitG-Arztbrief-v150.pdf [13] HL7. Implementation Guide for CDA Release 2 - Level 1 and 2 - Care Record Summary (US realm) [cited 2008 November]; Available from: [14] Blobel B. EPA-Modelle im Vergleich: openehr, HL7 V3 Specs, EN/ISO 13606, CCR. Jäckel A (Hrsg) Telemedizinführer Deutschland. 2007;Ausgabe 2008:p [15] IEEE. Position: Interoperability for the national health information network [cited 2008 September]; Available from: [16] HL7 Interoperability Work Group. Coming To Terms - Scoping Interoperability for Health Care [cited 2008 September]; Available from: February-2007.pdf [17] International Health Terminology Standards Development Organisation. SNOMED CT [cited 2008 September]; Available from: [18] Garde S, Knaup P, Hovenga E, Heard S. Towards semantic interoperability for electronic health records. Methods Inf Med. 2007;46(3): [19] CEN/TC 251 WG1. Health informatics - Electronic health record communication - Part 2: Archetypes interchange specification; Report No.: EN [20] openehr. Archetype Definition Language [cited October 2008]; Available from: 103

108 [21] Haas P. Gesundheitstelematik: Springer [22] Stöttinger K. Das OSI-Referenzmodell: Datacom [23] HL7. Reference Information Model [cited 2008 September]; Available from: [24] Hitz M, Kappel G, Kapsammer E, Retschitzegger W. dpunkt.verlag [25] Smith B, Ceusters W. HL7 RIM: an incoherent standard. Stud Health Technol Inform. 2006;124: [26] Schadow G, Mead CN, Walker DM. The HL7 reference information model under scrutiny. Stud Health Technol Inform. 2006;124: [27] HL7. Message Development Framework [cited 2008 September 22]; Available from: [28] HL7. Development Framework [cited 2008 September 23]; Available from: [29] Beeler GW. HL7 version 3--an object-oriented methodology for collaborative standards development. Int J Med Inform Feb;48(1-3): [30] HL7. Clinical Document Architecture Release [cited 2008 September]; Available from: [31] St. Laurent S, Fitzgerald M. XML Kurz und Gut. 3. Auflage ed: O'Reilly [32] Bointner K., Duftschmid G. Semantische Interoperabilität im elektronischen Gesundheitsdatenaustausch mittels dualer Modellierung - Der HL7 Template Ansatz. ehealth Medical Informatics meets ehealth; 2008; Vienna; p [33] HL7. Specification and Use of Reusable Constraint Templates [cited 2008 September]; Available from: s.htm 104

109 [34] Raghupathi W, Umar A. Exploring a model-driven architecture (MDA) approach to health care information systems development. Int J Med Inform May;77(5): [35] Object Management Group. OMG [cited 2008 September]; Available from: [36] Kalra D, Blobel BG. Semantic interoperability of EHR systems. Stud Health Technol Inform. 2007;127: [37] Regenstrief Institute. LOINC [cited 2008 September]; Available from: [38] Hoy D, Hardiker NR, McNicoll IT, Westwell P, Bryans A. Collaborative development of clinical templates as a national resource. Int J Med Inform Jul 17. [39] van der Linden H, Grimson J, Tange H, Talmon J, Hasman A. Archetypes: the PropeR way. Stud Health Technol Inform. 2004;107(Pt 2): [40] Kent B. Simple Smalltalk Testing: With Patterns. [cited 2008 September]; Available from: [41] Chen R, Garde S, Beale T, Nystrom M, Karlsson D, Klein GO, et al. An archetype-based testing framework. Stud Health Technol Inform. 2008;136: [42] openehr. Archetype Object Model [cited 2008 November]; Available from: [43] Ammenwerth E, Haux R. IT-Projektmanagement in Krankenhaus und Gesundheitswesen: Schattauer GmbH [44] HL7, ASTM. Implementation Guide: CDA Release 2 - Continuity of Care Document (CCD) [cited 2008 September]; Available from: [45] Vancouver Island Health Authority. e-ms Clinical Document Architecture Implementation Guide [cited 2008 November]; Available from: 105

110 [46] HL7 France. Guide d Implementation du Volet Médical au format CDA Release 2 Niveau [cited 2008 November]; Available from: olet_medical_cda_release_2_niveau_3_v0-7.pdf [47] HL7. Implementation Guide for CDA Release 2 Levels 1, 2 and 3 Diagnostic Imaging Report Universal Realm [cited 2008 November]; Available from: [48] Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.v. Reha-Kurzbrief auf Basis der HL7 CDA Release [cited 2008 November]; Available from: G_Initiative/downloads/Leitfaden-VHitG-DRV-Reha-Kurzbriefv100.pdf [49] Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.v. Der ärztliche Reha-Entlassungsbericht auf Basis der HL7 CDA Release [cited 2008 November]; Available from: G_Initiative/downloads/CDA-Leitfaden-DRV-Entlassbericht-v100.zip [50] Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.v. Addendum zum Arztbrief: Labor auf der Basis der HL7 CDA Release [cited 2008 November]; Available from: [51] Verband der Hersteller von IT-Lösungen für das Gesundheitswesen e.v. Addendum zum Arztbrief: Medikation auf der Basis der CDA Release [cited 2008 November]; Available from: [52] Kassenärztliche Vereinigung Nordrhein. Elektronischer Arztbrief mit D2D auf dem Vormarsch [cited 2008 November]; Available from: [53] Health Chief Information Officer Council. Framework for an Electronic Health Record for British Columbians [cited

111 November]; Available from: [54] Arbeitsgemeinschaft SCIPHOX GbR mbh. Standardized Communication of Information Systems in Physician Offices and Hospitals using XML. [cited 2008 October]; Available from: [55] Deutsches Institut für Medizinische Dokumentation und Information. LOINC Begriffssystem zur Verschlüsselung von Laborwerten und klinischen Untersuchungen. [cited 2008 September]; Available from: [56] ASTM International. Continuity of Care Record [cited 2008 November]; Available from: 107

112 Anhang HL7 Template Modell 108