Entwicklung einer ontologiebasierten Architektur zur Sicherung semantischer Interoperabilität zwischen Kommunikationsstandards im Gesundheitswesen
Anhang mit zusätzlichen Erläuterungen

Home -> Frank -> My Thesis
 
 

2. Detaileinsichten

2.1. HL7 Version 2.x - Detaileinsicht

Die erste Version von HL7 (Version 1.0) entstand 1987 durch Einigung mehrerer Firmen, den Datenaustausch in einem "normierten" von ASTM abgeleiteten Format durchzuführen. Daraus entwickelte sich ziemlich schnell die 2. Version, die 1990 verabschiedet wurde. Letztere war und ist Grundlage für die Familie "HL7 Version 2.x", die parallel zur Version 3 weiterentwickelt wird. Gegenwärtig (August 2010) wird die Version 2.7 verabschiedet und die v2.8 mit neuen Vorschlägen vorbereitet. Es ist zu erwarten, dass über die nächsten Jahre noch weitere Versionen folgen werden.

Grundlage ist der pragmatische Ansatz, Nachrichten im "delimitered" Format auszutauschen, um Platz zu sparen. Zu Beginn der Entwicklungsarbeiten war die Länge einer Nachricht für die Übertragung durchaus noch diskussionswürdig.

Das Standard-Encoding (ER7) mit dem Einsatz von 6 hierarchisch orientierten Trennzeichen erlaubt den Aufbau von strukturierten Nachrichten. Dabei wird im Prinzip ein zweidimensionaler Ansatz zur Aufteilung der Informationsinhalte verfolgt:


Abbildung 1: Zweidimensionales Parsen der HL7-v2.x-Nachrichten

Das höchstwertige Trennzeichen (CR = Carriage Return) trennt die einzelnen Segmente und sorgt so für die segmentorientierte Nachrichtenstruktur, um zusammenhängende Nachrichteneinheiten ausdrücken zu können. Damit kann auf "oberster Ebene" entschieden werden, ob eine Informationseinheit (Segment oder Segmentgruppe) verarbeitet werden kann oder nicht . Dazu muss aber der Nachrichtenaufbau bekannt sein. Umgekehrt können auf diese Weise alle Segmente in der jeweiligen Strukturhierarchie identifiziert werden, so dass direkt entschieden werden kann, ob eine Verarbeitung des Segmentes oder der Segmentgruppe möglich ist oder nicht.

Innerhalb eines Segmentes, das über ein Kürzel aus drei Buchstaben (beispielsweise PID = Patientenidentifikation) identifiziert wird, tragen die Felder die eigentliche Information. Sobald ein Segment verarbeitet werden soll, findet die Dekodierung in der zweiten Dimension statt. Hier werden die einzelnen Informationen über 5 weitere Delimiter extrahiert.

Nachfolgend ein Beispiel für eine Aufnahmenachricht:


MSH|^~\&|MEDOS|RAD|SAP-ISH||20030120116412002||ADT^A01|1325-1|P|2.5|||||DEU|8859/1|DEU
EVN|A01|20030120164122|20030120140000
PID|||5432^^^KIS||Mustermann^Gabriele^^^^^L~Maier^Gabriele^^^^^B||19751017|F|||
       Vogelweg 8&Vogelweg&8^^Hamburg-Harburg^^10260^DEU^H~
       ^^Bochum^^^DEU^N||^PRN^PH^^49^40^3542557~^PRN^FX^^49^40^3542558|
       ^WPN^PH^^49^40^5557865||M|CAT||||||Maria-Hilf Krh.|||DEU|Pyrotechniker|DEU
NK1|1|Mustermann^Gerd|FTH|||||||||||M|M|19470521|||DEU|DEU|||||CAT
NK1|2|Mustermann^Helga|MTH|||||||||||M|F|19490630|||DEU|DEU|||||CAT|Maier
PV1|1|I|IN2^4^3^CHI^^^^6||||||||||||||||0345632^^^^VN^KIS^20030120|||||||||||||||||||||||||
       20030120
PV2|||||||||20030402
OBX|2|NM|3141.9^Koerpergewicht^LN||85|kg|||||F|||20030120
DG1|1||E11.5^...^I10-20|||BD|||||||||1.1
DG1|2||I79.2^...^I10-20|||BD|||||||||1.2
DG1|3||S42.41 R^...^I10-20|||BD|||||||||2.1
DG1|4||V99^...^I10-20|||BD|||||||||2.2
IN1|1||0463752^^NII~32453^^NIIP|Techniker Krankenkasse||||||||
       200006|200606||1|Mustermann^Gabriele^^^^^L||19750714|
       Vogelweg 8^^Hamburg-Harburg^^10260^DEU^H|||||
       000000||000000|||||||||||||||||||||||1407750120^^^^^^^200006
IN2|||||I
ZBE|615^MEDOS|20030120140000||INSERT

Abbildung 2: HL7-v2.x-Beispielnachricht

Die weitere Strukturierung des Nachrichteninhaltes innerhalb der Nachrichtenstruktur wird über die Datentypen festgelegt:

2.1.1. Datentypen

Die Datentypen legen die Unterteilung der Felder in ihre Komponenten fest. Die erste 2er Version hatte nur einfache sowie einen generischen zusammengesetzten Datentyp ("CM"). Im Zuge der Weiterentwicklung wurde das Modell der Datentypen weiter verfeinert. In der Version 2.6 gibt es bereits über 90 verschiedene Datentypen.

Im Gegensatz zu Programmiersprachen werden die Datentypen bei HL7 über ihren Inhalt definiert. Beispiele:

  • Adressen
  • Personennamen
  • Zeitbereiche
  • etc.

Bedingt durch die Anzahl an Trennsymbolen können die Datentypen nicht beliebig strukturiert sein, sondern sind auf zwei Ebenen beschränkt. (Die Länge des Feldes ergibt sich als Summe aus den Komponenten zzgl. der Delimiter). Nachfolgend ist das Beispiel für Personennamen gegeben, wobei die beiden Datentypen "FN" und "DR" wieder als Datentyp aufgelöst sind. Für weitere Details dazu sei auf [HL7] verwiesen:

Tabelle 1: HL7-Datentypspezifikation (Verschachtelung aufgelöst)

SEQLENDTOPTTBL#COMPONENT NAME 
1194FNC Family Name
SEQLENDTOPTTBL#COMPONENT NAME
150STR Surname
220STO Own Surname Prefix
350STO Own Surname
420STO Surname Prefix From Partner/Spouse
550STO Surname From Partner/Spouse
230STO Given Name
330STO Second and Further Given Names or Initials Thereof
420STO Suffix (e.g., JR or III)
520STO Prefix (e.g., DR)
66ISB0360Degree (e.g., MD)
71IDO0200Name Type Code
81IDO0465Name Representation Code
9705CWEO0448Name Context
1049DRB Name Validity Range
SEQLENDTOPTTBL#COMPONENT NAME
124DTMO Range Start Date/Time
224DTMO Range End Date/Time
111IDO0444Name Assembly Order
1224DTMO Effective Date
1324DTMO Expiration Date
14199STO Professional Suffix

Über das sog. Komponentenmodell, das mit der Version 2.5 offiziell eingeführt wurde, konnten die bisher nur im Text beschriebenen Zuordnungen (insbesondere der Tabellen, Längen und der Optionalitäten) explizit gemacht werden.

Die HL7-Datenbank hat seit Anbeginn ihrer Existenz ein Komponentenmodell enthalten. Mit ihr wurden auch eindeutige Datentypen eingeführt, um jede Struktur und jede Komponente eindeutig bezeichnen zu können. Aus Kompatibilitätsgründen zu dem Originalstandard musste dann aber eine Zwischenschicht mit einem Mapping eingezogen werden, um die unpräzisen Spezifikationen weiterhin abbilden zu können.

2.1.2. Ereignisse

Ereignisse in der realen Welt - beispielsweise die Aufnahme eines Patienten oder die Neuanlage eines Auftrages - sind der Auslöser, um die dazugehörigen Informationen einem Kommunikationspartner mitzuteilen. Je nach Szenario sind dazu andere Daten notwendig, die in Form von unterschiedlichen Segmentzusammensetzungen dargestellt werden.

Ursprünglich (HL7 v2.1) ist man dabei von Nachrichtentypen ausgegangen, d.h. der Nachrichtentyp sollte ausreichend Informationen liefern, um den Inhalt der Nachricht feststellen zu können. Details zu den Ereignissen wurden dann in einem bestimmten Feld in einem nachfolgenden Segment bereitgestellt. Bei ADT war dies EVN-1 und bei ORM ORC-1. Im Zuge der Weiterentwicklung wurden die Nachrichten umfangreicher und konnten nicht mehr für alle Ereignisse eines Nachrichtentyps gleich gestaltet werden. Aus diesem Grund wurde das Ereignisfeld in den Nachrichtenkopf verlagert. Leider haben die verschiedenen Arbeitsgruppen (TCs) die Situation unterschiedlich umgesetzt. Der ADT-Bereich (Patientenadministration) hat viele ähnliche Nachrichten (genaugenommen 3 Grundstrukturen mit vielen Events) entwickelt, OO (Orders & Observations) ist mit ORM bei wenigen geblieben, hat aber viele "Subevents" in Form von "Order Control Codes" (in ORC-1) entwickelt.

Die Einführung eines Identifikators (ID) für die Nachrichtenstruktur ("Message Structure Identifier") sollte dieses Manko beheben. Initial wurden deshalb alle Nachrichten mit Hilfe der Datenbank abgeglichen um eine derartige ID zu bestimmen. Da nicht alle Nachrichten aufgrund ihrer internen Struktur eindeutig durch einen Parser zu bewältigen waren (mehrere unterschiedliche Nachrichten bei demselben Ereignis), sollte diese ID ebenfalls zur Unterstützung des Parsingprozesses zu Rate gezogen werden können.

Da der Standard nicht datenbankbasiert [SchoOem2001] weiterentwickelt wird, kommt es leider immer wieder vor, dass nicht alle Nachrichten mit derselben Struktur (und ID) gleichartig abgeändert werden, so dass unterschiedliche Strukturen in den Abstimmungsprozess gehen.

Dazu kommt, dass Aufräumarbeiten in der Dokumentation aufgrund von Einsprüchen von Mitgliedern nicht durchgeführt werden können, da diese auf einer Rückwärtskompatibilität bestehen. Das führt zu Dubletten in der Definition, die wiederum eine konsistente Definition erschweren, wenn nicht sogar verhindern. Als Abhilfe bleibt hier nur die konsequente Überprüfung und Erhebung von Einsprüchen während der Ballotierungsphase (vgl. "Die HL7-Datenbank" auf der Webseite).

2.1.3. dynamisches Verhalten

Neben der bisher beschriebenen Definition einer statischen Nachrichtenstruktur gibt es noch ein dynamisches Verhalten. Im Nachrichtenkopf gibt es dazu entsprechende Angaben:


Abbildung 3: HL7-v2.x-Nachrichten - dynamisches Verhalten

Über die Bedingung der Quittungsanforderung für Transport und Verarbeitung kann festgelegt werden, ob und unter welchen Bedingungen eine Quittung geschickt wird. (Wenn nichts angegeben ist, wird von dem Standardverhalten ausgegangen, eine Anwendungsquittung zu schicken.) Damit kann eine Anwendung schon mit 0, 1 oder 2 Antwortnachrichten auf eine versendete rechnen. Bei "Broadcast"-Nachrichten wie ADT muss dies mit der Anzahl der Empfänger multipliziert werden. Damit stellt sich das individuell zu lösende Problem, wie mit unterschiedlichen Rückmeldungen aus den einzelnen Anwendungen umgegangen werden soll, d.h. wenn beispielsweise 2 von 8 Anwendungen die Verarbeitung einer Verlegung ablehnen?

Das derzeit implementierte Standardverhalten ist die Übermittlung einer Transportquittung, die allerdings nicht wirklich ausgewertet wird. Sie dient lediglich zur Erfüllung der Anforderung, eine Quittung zu schicken. Dies ist wiederum in der synchronen Verarbeitungslogik begründet, die fälschlicherweise vielfach implementiert wird. HL7 trifft derzeit keine Aussagen zu einem derartigen Verhalten.

Genau genommen können mehrere Nachrichten verschickt werden, bevor eine Antwort erfolgen muss, so sie denn gefordert ist.

Eine Antwortnachricht nimmt über die Nachrichten-ID Bezug auf die Ursprungsnachricht. Diese ID kann eine irgendwie gestaltete, aber eindeutige Zeichenkette sein. Um Fehler korrekt zuordnen und beheben zu können, muss eine Anwendung über alle Nachrichten Buch führen. Die meisten tun dies nicht, so dass eine konsequente Fehlerverfolgung und im Zuge dessen eine pro-aktive Vermeidung von Fehlern nicht möglich ist.

Ein anderes Problem in Verbindung mit dem dynamischen Verhalten ist die Weiterleitung der Nachrichten an den oder die Empfänger. Der HL7-Standard selbst trifft keine Aussage, wie die Nachrichten verteilt werden sollen, das heißt, ob die Anwendung selbst dafür zuständig ist oder nicht. Ein Kommunikationsserver kann also mit der Verteilung beauftragt werden. Im Gegenzug garantiert er die Weiterleitung und man bekommt direkt von ihm nur eine Transportquittung. Es stellt sich hier nur die Frage, wie mit unterschiedlichen Applikationsquittungen (s.o.) umgegangen werden soll, wenn beispielsweise eins von vier Zielsystemen die Nachricht nicht verarbeiten kann?

Letztendlich kann darauf nur manuell reagiert werden, vorausgesetzt, der Administrator bekommt darüber eine Information.

2.1.4. Löschanforderungen

Die Version 2.x kennt nur drei "Arten von Informationen" (vgl. [IHE Vol.0]):

  • vorhandene Informationen
  • nicht-vorhandene Informationen
  • zu löschende Informationen

Die ersten beiden sind relativ einfach zu verstehen: Werte für ein Feld werden normalerweise übermittelt, wenn sie denn vorliegen. Ansonsten bleibt das entsprechende Feld leer.

Für den Fall, dass eine Information in einer Anwendung gelöscht wurde, ist vorgesehen, dies durch eine spezielle Zeichenfolge kenntlich zu machen. Hierfür sind die doppelten Anführungszeichen ("") vorgesehen.

Die Implementierung dieses Verhaltens setzt voraus, dass eine Anwendung erkennt und sich merkt, dass eine Information gelöscht wurde [IHE Vol.0]. In den meisten Anwendungen werden die Informationen nicht historisiert, so dass die Schnittstelle nicht erkennen kann, dass eine Information nicht mehr vorhanden ist. Damit wird halt schlicht "keine Information" übertragen, so dass im Zielsystem die alte Information solange erhalten bleibt, bis ein neuer Wert übermittelt wird.

Schwierig wird es, wenn ein Empfänger Informationen verschiedener Sender verarbeitet, denn dann spielt die Reihenfolge eine wichtige Rolle. Ohne Weiterleitung der Informationen an alle Beteiligte ist eine Konsistenz nicht zu garantieren.

2.1.5. Null-Flavors

Im Gegensatz zu Löschanforderungen kennt HL7 Version 2.x derzeit keine Unterscheidung, warum eine Information nicht vorliegt. Seit der ersten Version werden Ansätze hierzu über die Tabellenwerte gemacht. Damit ist das Problem nur in bestimmten Fällen (Tabellen) und hier auch nur in einer inskonsistenten Form gemacht worden. Überlegungen für einen generischen Ansatz werden mit Proposal 608 [HL7-V2 Prop.DB] für v2.8 diskutiert. Allerdings bereitet hier die Rückwärtskompatibilität mit Vorversionen Probleme, die noch detaillierter zu analysieren sind.

2.1.6. Übertragungsprotokolle

Wie bereits erwähnt war damals ASTM [ASTM] die Grundlage für die Arbeiten. Auf der einen Seite wurden Verbesserungen eingeführt, wie beispielsweise Segmentbezeichnungen aus genau drei Buchstaben, auf der anderen wurde aber "vergessen", ein Nachrichtenende ("Message Trailer") zu definieren, was zu Problemen mit bestimmten Übertragungsprotokollen führt: Es gibt zwar ein Batch-Protokoll, um mehrere Nachrichten zu einer Übertragungseinheit zusammenzufassen, jedoch wird aus pragmatischen Gründen (zusätzlicher Entwicklungsaufwand) dieses von keiner Firma unterstützt. Gerade bei einer Dateiübertagung werden die Nachrichten einfach hintereinander geschrieben. Bei Übertragung in einer Datei erfordert dies zusätzliche Absicherungen (Semaphordateien, Locking oder Umbenennen), um eine Vollständigkeit der Nachrichten zu garantieren.

Der einfachste und gleichzeitig zuverlässigste Mechanismus ist hierbei das Umbenennen, da dieser Vorgang auf Dateiebene von allen Betriebssystemen als atomare Aktion unterstützt wird. Aus nicht erklärbaren Gründen werden aber Semaphordateien bevorzugt zur Lösung des Problems eingesetzt, obwohl hierbei mit zwei Dateien hantiert werden muss.

Darüber hinaus gibt es mit VPN und D2D [D2D] noch weitere Alternativen.

2.1.7. Profile

Der Standard selbst stellt die Vereinigungsmenge aller Anforderungen aller Hersteller dar, die an der Entwicklung des Standards beteiligt sind. Da solche Anforderungen nicht als verpflichtend deklariert werden können, sind viele Elemente optional, d.h. sie müssen nicht bereitgestellt werden. Dieses Vorgehen ermöglicht eine breite Akzeptanz des Standards, jedoch führt dies im Gegenzug dazu, dass die verschiedenen Hersteller unterschiedliche Daten bereitstellen, so dass ein Datenaustausch trotz Einhaltung desselben Standards nur bedingt möglich ist.

Um dieses Dilemma aufzulösen, werden Nachrichtenprofile eingeführt. Hierbei gibt es drei verschiedene Ebenen:

  • Standard
  • constrainable (=einzuschränken)
  • implementable (=implementierbar)

Die oberste Ebene repräsentiert den Standard selbst, d.h. hier existieren die meisten Optionalitäten. Im "constrainable profile" sind diese Optionalitäten schon etwas eingeschränkt. Allerdings existieren hier noch Wahlmöglichkeiten, die im "implementable profile" ganz eingeschränkt sind. Dabei muß dann zu jedem Element eine Aussage getroffen werden, ob es unterstützt wird oder nicht.

Im Standard ist klar geregelt, wie mit den verschiedenen Optionalitäten verfahren werden darf, um zu einem "implementable profile" zu gelangen:

Tabelle 2: "HL7 Optionality and Conformance Usage"

HL7 OptionalityAllowed Conformance UsageComment
R - RequiredR 
RE - Required, but may be EmptyR 
O - OptionalR, RE, O, C, CE, Xcan be constrained to any other, but O is only permitted for constrainable profiles
C - ConditionalC, R 
CE - Conditional, but may be emptyC, CE, R 
X - Not SupportedX 
B - Backward CompatibilityR, RE, O, C, CE, Xcan be constrained to any other, but O is only permitted for constrainable definitions
X is the prefered one
W - WithdrawnR, RE, O, C, CE, XX is the prefered one

In einem implementierbaren Nachrichtenprofil darf es letztendlich nur zwei Möglichkeiten geben. Entweder ein bestimmtes Element wird unterstützt (="R/RE") oder nicht (="X"). Damit ergibt sich das nachfolgende Überführungsdiagramm. Die einzige Besonderheit stellten hier die Elemente dar, bei denen Bedingungen eine Rolle spielen. Aber auch hier gilt, dass in einem implementierbaren Profil dazu eine exakte Aussage zu treffen ist [OemBlo2007b]:


Abbildung 4: Einschränkungshierarchie für Profile

Ab der Version 2.7 wird auch "RE" im Standard zugelassen/verwendet.

2.2. HL7 Version 3 - Detaileinsicht

Einen ganz anderen Weg beschreitet die "neue" HL7-Version 3: 1995 wurde erstmals versucht, ein global gültiges Modell für das Gesundheitswesen zu erstellen. Nach drei Jahren Arbeit musste jedoch eingestanden werden, dass ein solches Modell nicht zu definieren ist, weil die Anforderungen aus den unterschiedlichen Domänen und den verschiedenen Ländern eine Harmonisierung nicht zulassen.

Stattdessen kam man zu einem Metamodell, dem sogenannten RIM: Reference Information Model [HL7 RIM]. Hierunter ist eine Art Baukasten zu verstehen, dessen Elemente zum Aufbau der Domänen-Modelle verwendet werden können. Dieses RIM besteht selbst nur aus 4 Basisklassen sowie 2 weiteren Beziehungsklassen. (Eine gute Erklärung der Lesart findet man neben dem V2 Guide auch in [Hinch]):


Abbildung 5: HL7-V3-Basis-Bausteine des RIM

Das gesamte Referenzmodell (nachfolgend RIM 0208) umfasst die Basisklassen und deren Spezialisierungen, hier in einer druckoptimierten Fassung:


Abbildung 6: HL7 V3 RIM (Referenz-Informations-Modell)

Dazu kommen dann noch spezielle Klassen, die für die Erzeugung der Nachrichten, Steuerung von Anfragen, Sprachen und übergreifender Kontrolle notwendig sind. Diese spielen für die weitere Betrachtung in dieser Arbeit allerdings keine Rolle:


Abbildung 7: HL7 V3 Klassen für die Kontrolle des Nachrichtenaustauschs

Diese sechs Basisklassen (Abbildung 5) bestehen aus 4 Basisklassen sowie 2 Beziehungsklassen:

Eine Entität dient der Repräsentation von physikalischen, persistenten Objekten. Dazu gehören neben Personen, Material und Geräten auch Organisationen und Orte. Eine Entität drückt etwas Statisches aus.

Eine Rolle (Role) drückt die Fähigkeit aus, die eine Entität besitzt. So kann eine Person beispielsweise die Rolle Patient spielen.

Die Teilnahme (Participation ) beschreibt die Einbeziehung einer Entität in einer bestimmten Rolle an einem Akt. So nimmt beispielsweise eine Person in der Rolle Arzt an einer Aktivität Operation als ausführender Chirurg teil.

Ein Akt ist der Träger für alle Informationen und drückt Veränderungen aus. So ist beispielsweise ein Befund eine Beobachtung und damit eine Aktivität . Zu diesen 4 Basisklassen kommen noch 2 Klassen, um Beziehungen zu realisieren:

Eine Rollenverknüpfung (Rolle Link) setzt verschiedene Rollen in eine direkte Beziehung wie beispielsweise Arbeitgeber/Arbeitnehmer. Dies wird allerdings sehr selten genutzt.

Eine Aktrelation (Act Relationship) verknüpft verschiedene Aktivitäten. So ist beispielsweise die Aktivität Befund die Erfüllung der Aktivität Anforderung.

Diese sechs Basisklassen können in einer Instanziierung in mannigfaltiger Art und Weise zusammengesetzt werden. So drückt nachfolgendes Konstrukt aus, dass eine "Person A" als untersuchender Arzt an einer Untersuchung des Patienten "Person B" teilnimmt.


Abbildung 8: HL7 V3 Beispiel 1 (einfache Aktivität)

Die beiden Linkklassen dienen nachfolgend der direkten Verknüpfung von Rollen bzw. Aktivitäten. Beispielsweise ist hier Hr. Meier Angestellter der Fa. Kunze.


Abbildung 9: HL7 V3 Beispiel 2 ("Role Relationship")

Genauso können zwei verschiedene Aktivitäten - beispielsweise die Anforderung und das dazugehörige Ergebnis - über ein Act-Relationship miteinander verbunden werden.


Abbildung 10: HL7 V3 Beispiel 3 ("Act Relationship")

Eine weitere Besonderheit spielen die zwei Beziehungsmöglichkeiten von Rollen zu Entitäten. In der nachfolgenden Grafik wird dies durch die durchgezogene und die gestrichelte Linie repräsentiert. Es wird davon ausgegangen, dass eine Rolle einen bestimmten Kontext erfordert. So wird eine Person nur dadurch zu einem Patienten, dass sie diese Rolle in dem Kontext einer Organisation (hier Krankenhaus) ausübt.


Abbildung 11: HL7 V3 Beispiel 4 ("Playing and Scoping Entity")

Die in den vier vorgenannten Beispielen angeführten Verknüpfungsmöglichkeiten können beliebig zu komplexeren Gebilden kombiniert werden. Aus diesen Klassen (Bausteinen des Baukastens) werden sog. Domänenmodelle konstruiert. Zu diesem Zweck wird ein Modul zu Microsoft Visio(TM) hinzugeladen, das auf das RIM - die Metainformationen dazu sind in einer Access-Datenbank, dem sog. Repository gespeichert - zurückgreift und die verwendeten Klassen direkt validieren kann:


Abbildung 12: HL7 V3 Beispiel Domänenmodell

Ein Domänenmodell stellt ein (abstraktes) Gebilde aus Klassen dar, die zur Modellierung eines Anwendungsgebietes benötigt werden.

Aus diesem Domänenmodell entnimmt man einen Teil und schränkt die Nutzung weiter ein. Dadurch entsteht ein sogenanntes Refined Message Information Model (R-MIM), das der Umsetzung eines bestimmten Szenariums (Use Case) dient.

Eine weitere Einschränkung im Hinblick auf eine bestimmte Nachricht in diesem Szenarium inklusive der dazugehörigen Sequenzialisierung für eine Übertragung der Information in Form einer Nachricht führt dann zu einer Hierarchical Message Definition (HMD). Eine derartige Definition kann dann sowohl tabellarisch als auch in Form eines XML-Schemas dargestellt werden. Beides ist dann die Grundlage für eine Implementierung. Die ITS - Implementable Technology Specification - sorgt dann für die Umsetzung der abstrakten Modelle in eine konkrete Technologie wie bspw. XML.

Neben diesen abstrakten Modellen und deren Details sind für eine Implementierung noch zwei andere Bereiche wichtig:


Abbildung 13: HL7 V3 Implementierungsaspekte

Die Grundlagen dazu sollen in den nachfolgenden Abschnitten näher erläutert werden.

2.2.1. Zustandsübergänge

Ein Grund für eine Nachricht ist die Veränderung des internen Zustands einer Entität oder einer Aktivität. Zu diesem Zweck sind die generischen Zustandsübergänge definiert worden, die in Form von State Machines umgesetzt werden. In den einzelnen Szenarien werden Untermengen dieser generischen Definition spezifiziert und über Ereignisse in Nachrichten kommuniziert.


Abbildung 14: HL7 V3 State Machine für Acts

Die Zustandsübergänge für Aktivitäten (s.o.) unterscheiden sich von denen für Entitäten (s.u.).


Abbildung 15: HL7 V3 State Machine für Entitäten

2.2.2. Mood-Code ("Modus")

Eine völlig andere Dimension wird durch den sog. Mood-Code realisiert. (Dieses Kunstwort wird am besten durch "Modus" übersetzt.) Gemeint ist damit die Nutzung der abstrakten Klassen (Entitäten und Aktivitäten) in unterschiedlichen Funktionen. So ist eine Beobachtung im "Request"-Mood etwas anderes als eine Beobachtung im "Event"-Mood. Ersteres ist die Anforderung, letzteres das Ergebnis.

Ontologisch betrachtet müsste das in unterschiedlichen Teilbäumen der Hierarchie repräsentiert werden. Für eine automatische Generierung der Strukturen lässt sich das allerdings nicht realisieren. Umgekehrt handelt es sich hier um Informationsobjekte allgemein, deren Semantik erst durch die Kombination verschiedener Attribute erschlossen wird. Für das Mapping muss das entsprechend über Bedingungen berücksichtigt werden.

2.2.3. Anwendungsrollen

Wie einleitend schon erläutert werden die Nachrichten als Interaktion zwischen verschiedenen Akteuren ausgetauscht. Als Auslöser für den Nachrichtenaustausch dient dabei entweder ein Ereignis oder ein Zustandswechsel. Mitunter ist es nicht mit dem Austausch einer einzigen Nachricht getan: mehrere Nachrichten zusammen formen ein bestimmtes Szenario, das nur unter Berücksichtigung (Implementierung) aller dazugehörigen Nachrichten adäquat in einem System abgebildet werden kann.

An dieser Stelle ergibt sich eine Weiterentwicklung gegenüber der Version 2.x, die ein derartiges Konstrukt nicht kennt und deshalb alle Nachrichten ungewertet nebeneinander stellt (vgl. Fehler! Verweisquelle konnte nicht gefunden werden.).

Allerdings ist eine "Anwendungsrolle" ein nicht normatives Konstrukt, d.h. in diesem Fall, dass es noch kein einheitliches Verständnis über die Verantwortlichkeiten in diesem Zusammenhang gibt. So ist nicht geklärt, auf welcher Grundlage und mit welchen Randbedingungen Anwendungsrollen festgelegt werden und was bei der Umsetzung des statischen und dynamischen Verhaltens zu berücksichtigen ist.

2.2.4. Datentypen

Unabdingbare Voraussetzung für einen Nachrichtenaustausch sind Daten. Diese liegen häufig als Einheit von mehreren Einzelwerten vor, die einen gemeinsamen Zusammenhang haben - beispielsweise eine Adresse, die aus Straße, PLZ und Ort besteht. Ein solches Konglomerat von Einzelinformationen wird in Programmiersprachen als Datentyp bezeichnet. Häufig kommen dazu noch Operationen hinzu, die auf diesen Datentypen ausgeführt werden können. So gibt es beispielsweise bei dem Datentyp "integer" die Operation "Vorgänger" (predecessor) und "Nachfolger" (successor).

Welche semantischen Eigenschaften diese Datentypen haben, wird durch "invariant statements" ausgedrückt. Das sind Aussagen, die zu jeder Zeit und für alle möglichen Werte gültig sind. (In anderen Bereichen der Informationswissenschaft (Berechenbarkeit und Logik) werden solche Aussagen als Fixpunkte betrachtet.)

2.2.5. ITS

Diese Datentypenspezifikation wird auf einer abstrakten Ebene unabhängig von einer konkreten Implementierung definiert. Dasselbe gilt für Domänenmodelle. Für eine Nutzung in einem praktischen Einsatz ist eine konkrete Technologie zu wählen und eine Abbildungsvorschrift zu definieren.

Für HL7 V3 ist derzeit nur XML als Technologie zugelassen und liegt in Form einer sog. ITS (Implementable Technology Specification) vor.

Es sind aber auch andere Technologien möglich. Dazu zählen beispielsweise binary XML [XML], ASN.1 [ASN.1] und ER7. Letztere muss aber eine Überarbeitung erfahren, da diese derzeit keine beliebig tief geschachtelten Strukturen zulässt.

Im März 2010 wurde ein neuer Vorschlag eingereicht, eine weitere XML-ITS zu definieren, die die Namen der RIM-Klassen und nicht die der Domänenmodelle verwendet, um dadurch das Problem der Rückwärtskompatibilität zu adressieren. Damit wird der Vorschlag des Autors, der auf der IHIC 2009 präsentiert wurde, - mehr oder weniger unbewusst - aufgegriffen. Ähnliches gilt für die ?ITS und greenCDA.

2.2.6. "Structural Attributes"

Die Klassen in den abstrakten Modelle enthalten Informationen, die für eine korrekte Interpretation einer konkreten Nachrichteninstanz absolut notwendig sind. Das RIM stellt für die Modellierung der Domänen abstrakte Klassen zur Verfügung, die dann entsprechend instanziiert werden können. Da diese Klassen mehrfach und in unterschiedlicher Ausprägung genutzt werden können, muss dies zum korrekten Verständnis angezeigt werden. Die dafür notwendigen Attribute wie "moodCode" und "classCode" werden daher auch "structural attributes" genannt.

2.2.7. "mandatory Values"

Eng verbunden mit diesen structural Attributes ist das Vorhandensein von gültigen Werten. Damit ist gemeint, dass Ersatzinformationen mit Gründen für die Abwesenheit dieser Daten ("gefragt, aber keine Antwort") nicht zugelassen sind. Dies bezieht die Möglichkeit des Rückgriffes auf Defaultwerte mit ein. Da aber die XML-Schemas seitens der Hersteller manipuliert werden, sind Defaultwerte problematisch, da diese zur Auswertung bekannt sein müssen. Daher müsste bei jeder Datenübertagung auch das dazugehörige Schema mit kommuniziert werden, was das Datenvolumen ("Traffic") deutlich erhöht.

2.2.8. "Null-Flavors"

Ein wesentlicher Unterschied der Version 3 zur Version 2 ist die Tatsache, dass Informationen über die Abwesenheit von Daten nicht mit diesen gemischt werden. So gibt es keinen gültigen "Daten-Code" für "unbekannt". Die nachfolgende Tabelle zeigt ein Beispiel:

Tabelle 3: Codierungsbeispiel "Administrative Gender"

V2.xV3
M - MaleM -Male
F - FemaleF - Female
A - AmbiguousUN - undifferentiated
N - Not applicable gibt es nicht bei
O - Other Personen in V3
U - UnknownnullFlavor="NI" - no information

Damit haben die Anwendungen auf der einen Seite die Möglichkeit zwischen ca. einem Dutzend verschiedener Gründe für das Nichtvorhandensein von Informationen zu wählen. Auf der anderen Seite muss diese Art von Informationen in der Anwendung gespeichert werden, um sie überhaupt kommunizieren zu können.

2.2.9. Publishing

Ein weiterer Punkt, den man aus dem Publikationsprozess der Version 2 gelernt hat, ist die Art und Weise, in der man die Informationen editiert. Es werden jetzt keine proprietären Formate wie MS-Word mehr genutzt. Man setzt jetzt auf in Datenbanken sowie XML gespeicherten Daten.

Hierbei muss zwischen Textdokumenten und modellbezogenen Informationen unterschieden werden. Erstere werden in XML-Dokumenten editiert, die vorgegebenen Strukturen (XML-Schemas) gehorchen müssen. Die modellbezogenen Informationen werden unter Bezug auf den jeweiligen Artefact-Code in verschiedenen Tabellen der Datenbank gespeichert. Die Modelle werden über ebendiesen Artefact-Code (als Dateinamen) referenziert.

Auf Basis dieser Informationen werden die zu veröffentlichenden Dokumente in eine HTML-Darstellung generiert und miteinander verlinkt. Um eine übergreifende Verknüpfung dieser Informationen zu gewährleisten werden die verschiedenen Datenbanken, die von den einzelnen Arbeitsgruppen unabhängig voneinander gepflegt werden, vorher zusammengeführt.

In Zukunft wird hier verstärkt auf die MIF-Dateien gesetzt.

 

Last Update: September 22, 2010