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