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

Home -> Frank -> My Thesis
 
 

1. Anhang A: Standards als Grundlage der Arbeit

Wird auf einen gemeinsamen Standard verzichtet, muss ein Unternehmen die von einem Kommunikationspartner eingehenden Informationen häufig mit großem Aufwand in das eigene Daten(bank)format konvertieren. Hat es mehrere Kommunikationspartner, kann dies in hohem Aufwand resultieren, wenn für jeden Partner andere Datenformate realisiert werden müssen. Die zur Verfügung stehenden Ressourcen zwingen die Hersteller dazu, sich auf wenige einheitliche Standards zu einigen.

Im Gesundheitswesen hat sich im Laufe der Jahre eine Reihe von Kommunikationsstandards etabliert, die von den unterschiedlichsten Organisationen und Instituten spezifiziert worden sind. Zum Teil handelt es sich dabei um einander ergänzende bzw. miteinander konkurrierende Standards. Die beiden wesentlichsten Standards - HL7 v2.x und V3 - werden im Anhang noch einmal näher untersucht.

Einleitend sollen die verfügbaren Standards mit ihren wesentlichsten Merkmalen kurz vorgestellt werden. Zum Teil lassen sich dabei schon Gründzüge in deren Verwendbarkeit hinsichtlich Interoperabilität erkennen und bewerten.

1.1. EDI

EDI (Electronic Data Interchange) ist der Oberbegriff für den interventionsfreien Austausch von Nachrichten zur Steuerung von Geschäftsprozessen. Mit interventionsfrei ist hierbei gemeint, dass an dem Austausch von strukturierten Daten ausschließlich Computerprogramme beteiligt sind und deshalb kein manueller Eingriff notwendig ist. Als Daten wurden ursprünglich nur formularorientierte Informationen, wie sie bspw. in Bestellungen oder Rechnungen zu finden sind, übertragen. Inzwischen wurde EDI aber auch auf Dokumente ausgeweitet.

EDI-Standards werden von offiziellen Gremien (Standard Developing Organisation, SDO) festgelegt und in Form von Spezifikationen veröffentlicht. Allerdings hat jede SDO ihre eigenen Regeln für die Spezifikation der übertragenen Daten aufgestellt. Diese variieren je nach Land, Region, Branche und Initiator.

So wurde von den Vereinten Nationen (UN/ECE) der branchenunabhängige EDI-Standard UN/EDIFACT [EDIFACTORY, UN/EDIFACT a, UN/EDIFACT b] entwickelt und 1987 als ISO-Norm 9735 publiziert. Dieser Standard ist insbesondere in Europa weit verbreitet und so bspw. auch Grundlage für die Kostenübernahmeerklärung nach §301 SGB V [§301] sowie der technischen Anlagen 3 (TA-3) [§300 TA-3], und 4 (TA-4) für Apothekendaten [§300].

1.2. ASC X.12

In den USA und Kanada hat sich im Gegenzug das vom Accredited Standards Committee (ASC) herausgegebene ANSI X.12 durchgesetzt. X.12 ist ein Logistik-Standard zur Unterstützung von Bestellungen, Lieferungen, Wareneingängen, Rechnungen und Zahlungen [X.12].

1.3. HL7

Bereits 1987 hat sich in Palo Alto eine Gruppe von Firmen zusammengefunden, um den Datenaustausch im Gesundheitswesen - hier speziell zwischen Anwendungen innerhalb von Krankenhäusern - durch eine übergreifende gemeinsame Absprache zu vereinfachen. "Health Level Seven" oder kurz HL7 war geboren. Grundlage war damals ASTM (American Society for Testing and Materials) [ASTM]. Daraus hat sich sehr schnell die erste Version (1.0) des HL7-Standards entwickelt, deren Nachfahre (die Familie der 2er-Versionen) heute weit verbreitet und ANSI-Standard (American National Standards Institute) [ANSI] ist.

In Deutschland hat man sich 1993 durch die Gründung einer Benutzergruppe [HL7-DE] des Standards angenommen und versucht, den Einsatz von HL7 durch Interpretationen (Übersetzungen), Erweiterungen (Z-Segmente) und Anpassungen an die nationalen Gegebenheiten zu fördern. Zum Einsatz kam damals zuerst die HL7-Version 2.1, die allerdings noch sehr rudimentär war und schnell durch v2.2 abgelöst wurde. Das Einsatzfeld war die krankenhausinterne Kommunikation. Auch heute noch wird "HL7" häufig mit dieser Art der Kommunikation verbunden.

HL7 [HL7] wurde ursprünglich entwickelt, um rein patientenbezogene administrative Daten kommunizieren zu können. Inzwischen wurde der Standard aber auch um den Austausch medizinischer Daten erweitert, das gesamte Gesundheits- und Sozialwesen erfasst. Basis der gesamten Kommunikation ist der ereignisorientierte Austausch von Nachrichten.

HL7 stellt dabei inzwischen eine Familie von Standards dar, die nicht unerwähnt bleiben sollen, da sich diese ebenfalls mit dem Austausch von Daten beschäftigen:

Version 2.x und Version 3.0 - letztere ist eine neuere Entwicklung auf Basis einer eigenen Methodologie (MDF [HL7-MDF]; weiterentwickelt als HDF [HL7-HDF]) - dienen dem Austausch von patientenbezogenen administrativen und medizinischen Daten in Form von Nachrichten. Details dazu werden im Anhang weiter ausgeführt.

Es ist auf absehbare Zeit nicht erkennbar, welche "Familie" sich durchsetzen wird. Politisch betrachtet möchte man die Version 3 etablieren, rein pragmatisch jedoch ist v2.x derart weit verbreitet, dass an eine Ablösung wohl nicht zu denken ist. Deshalb konzentriert man sich bei der Version 3 auf neue Bereiche, die bisher nicht mit v2.x abgedeckt werden.
Diese beiden Familien sind zueinander inkompatibel. Bei genauerem Hinsehen erschließt sich, dass es auch innerhalb einer Familie zwischen den verschiedenen Versionen/Editionen Kompatibilitätsprobleme gibt, für die bisher keine Lösungen erarbeitet wurden.

Die Clinical Document Architecture (kurz CDA) [CDA] spezifiziert den Aufbau von klinischen Dokumenten. Im Gegensatz zu einem nachrichtenbasierten Standard wie v2.x oder V3 steht hier ein persistentes Dokument mit dem zu übermittelnden Text im Vordergrund. Dabei wird versucht, ein Rahmenwerk für den medizinischen Kontext zu schaffen, in dem dann ein klinisches Dokument mit beliebiger Dokumentenart (Arztbrief, Befund, Notiz, ..) realisiert werden kann. Ziel ist dabei, ein beliebiges Dokument so zu formulieren, dass es sowohl für den Menschen als auch den Computer lesbar wird. Dazu ist eine Strukturierung und Kodierung des Textes unter Rückgriff auf eine Markup-Sprache notwendig. Erreicht wird dies durch eine Kodierung in der eXtensible Markup Language (XML, [XML]), die bekanntermaßen beliebige Texte inklusive Markierungen (sog. Markups) für semantische Informationen enthalten kann. (Die Anfänge der CDA-Arbeiten gehen soweit zeitlich zurück, dass als Datenformat mangels Verfügbarkeit von XML noch SGML (Standard Generalized Markup Language, [SGML]) intendiert war.)
Die Dokumente selber werden in zwei Teile - den Header und den Body - unterteilt. Im Header stehen begleitende Informationen wie Meta-Daten (Patient, Autor, ...), im Body werden der eigentlich Text sowie die klinischen Zusatzdaten untergebracht. Zum Einen kann der Body ein komplettes Dokument in kodierter Form wie bspw. PDF oder RTF enthalten, dann wird der Header nur für die Übermittlung zusätzlicher Daten verwendet. Ansonsten wird davon ausgegangen, dass zumindest (ASCII-)Text mit entsprechenden XML-Markups übermittelt wird. Dieser kann mit Hilfe von sog. XML-Stylesheets so aufbereitet werden, dass der Text für den Anwender leicht lesbar wird. Darüber hinaus kann der Text mit weiteren Markups so angereichert werden, dass ein Computerprogramm diese Details in strukturierter Form auslesen und weiter nutzen kann.

Inzwischen gibt es zu CDA verschiedene Releases (1 + 2), die auf unterschiedlichen Versionen (0098 und 0207) des HL7-RIM (s.u.) [HL7-RIM] aufbauen. Das Release 3 sowie ein allgemeineres Format ("Structured Document Architecture") sind in Arbeit. Des Weiteren sind verschiedene Ebenen (Level) definiert, die die vorgehend erwähnte unterschiedliche Granularität im Body für die diversen Anwendungsfälle ermöglichen.

     <component>
<!-- Anamnese Komponente -->
<section>
Level 2   <code code="10164-2"
codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"/>
Level 1 <title>29.08.2005: Anamnese
<text>
Seit Jahren wiederholt chronische Bronchitiden besonders bei kalter Luft.
Bei Anstrengung expiratorische Atemnot.
Kontakt mit Haustieren.
</text>
Level 3 <entry>
<observation>
<code code="195967001"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Asthma">
</code>
</observation>
</entry>
</section>
</component>

Abbildung 1: CDA Rel.2 Level 3 Beispiel als Auszug

Kaum explizit erwähnt ist Level 0 , das die Einbettung beliebiger Dokumentformate wie bspw. PDF oder Word in einem NonXMLBody-Element vorsieht. Für CDA Rel.3 wird auch ein Level 4 für Referenzen überlegt.

Die Clinical Context Object Working Group (kurz CCOW) [CCOW] beschäftigt sich mit der sogenannten "Visual Integration". Darunter wird der Abgleich des Arbeitskontextes für verschiedene Anwendungen verstanden. Die einzelnen Anwendungen tauschen über einen Context Manager Kontextinformationen aus, d.h. welche Patientendaten gerade bearbeitet werden bzw. wer sich gerade an dem jeweiligen Arbeitsplatz an- oder abmeldet. Dadurch entfallen zeitaufwändige Arbeitsschritte zur Synchronisation an einem Arbeitsplatz (Desktop). Die Spezifikation sieht auch vor, dass ein Kontext verlassen (gebrochen) werden kann, bspw. um ein Dokument zu einem Patienten unabhängig von anderen Arbeitsschritten zu Ende schreiben zu können. Der Patientenkontext kann dann später über Synchronisierungsmechanismen wieder aufgenommen werden. Diese Art der Integration setzt eine funktionierende Datenintegration auf Patienten- und Stammdatenebene voraus, damit Patienten oder Benutzer über entsprechende Kennungen identifiziert werden können.

Darüber hinaus sind noch eine Reihe von "kleineren Standards" hinzugekommen, die sich ebenfalls mit Kommunikation bzw. Wissensrepräsentation beschäftigen: Arden Syntax, GELLO, GLIF, ... Diese spielen für diese Arbeit aber keine Rolle.

1.4. SCIPHOX

SCIPHOX (Standardized Communication In Physician Offices and HOspitals using XML) [SCIPHOX] ist eine deutsche Initiative, um den Datenaustausch zwischen den Arztpraxen niedergelassener Ärzte und Krankenhäusern zu erleichtern. Basis des Datenaustausches ist hierbei der CDA-Standard. Die ersten Arbeiten (im Jahre 2000) zum Entlassbrief und der Überweisung wurden auf Basis des Release 1 durchgeführt. Neben den Festlegungen, welche Informationen im Header zu übertragen sind, entstanden kleinere Nachrichtenfragmente, die sog. "Small Semantic Units" (SSU), die im Body übertragen werden und die wichtigen semantischen Konstrukte normieren. Ein Manko des Rel.1 des CDA-Standards ist die fehlende Strukturierung der eigentlichen medizinischen Daten. Dieses Manko wurde durch die SSU z.T. ausgeglichen. Für Rel.1 des CDA-Standards war auch eine unterschiedlich stark strukturierte Kodierung von Daten angestrebt worden, um einen fließenden Übergang von einer rein text-basierten Übermittlung zu kodierten Informationen zu erreichen. Dieser Schritt in Rel.1 wurde allerdings durch die Weiterentwicklung des CDA-Standards zu Release 2 überholt.

<patient>
...
<birth_dttm V="1936-08-09"/>
<administrative_gender_cd V="M" S="2.16.840.1.113883.5.1"/>
<local_header ignore="all" descriptor="sciphox">
<sciphox:sciphox-ssu type="insurance" country="de" version="v1">
<sciphox:GesetzlicheKrankenversicherung>
<sciphox:Kostentraegerbezeichnung V="AOK Köln"/>
<sciphox:Vertragskassennummer V="27101"/>
<sciphox:Institutionskennzeichen V="7632267"/>
<sciphox:Versichertennummer V="0612304653"/>
<sciphox:Versichertenstatus V="F" S="2.16.840.1.113883.3.7.1.2"/>
<sciphox:KVKgueltigbis V="2002-09"/>
</sciphox:GesetzlicheKrankenversicherung>
</sciphox:sciphox-ssu>
</local_header>
</patient>

Abbildung 2: XML-Beispiel für eine SSU

Die derzeit festgelegten SSUs sind in [SCIPHOX] im Detail aufgeführt.

Mit der Entwicklung des Rel.1 von CDA hat man sich auf die primäre Struktur von Dokumenten konzentriert, um den Abstimmungsprozess erfolgreich durchführen zu können. Damals hatte man schon Vorstellungen davon, wie eine nachgeschaltete Präzisierung der Informationen aussehen könnte, ohne dies direkt im ersten Schritt fordern zu müssen. Mit der parallelen Weiterentwicklung des XML-Standards, des Reference Information Modells der HL7 Version 3 (RIM) und der Konkretisierung der eigenen Vorstellungen wurde in diesem Punkt mit dem Rel.2 ein partielles Re-Design der CDA-Struktur durchgeführt. Man hat damit dann von der ursprünglichen Absicht, mit unterschiedlichen XML-Dokument-Root-Elementen arbeiten zu müssen, Abstand genommen und sich auf die Fähigkeiten von XML besonnen, mit unterschiedlichen Einbettungen arbeiten zu können. Die fein-granularen Informationen sind dann über tiefer strukturierte Details gemäß der RIM-Konvention und HL7-V3-Methodologie eingeführt worden. Damit haben sich die aus Rel.1 bekannten SSUs erübrigt und werden durch sog. Level 3 Konstrukte in Analogie der Clinical Statement Patterns/Templates [HL7 V3 Templates] ersetzt.

Des weiteren wurden die ersten Spezifikationen (eRezept) auf Basis des Release 2 entwickelt. Zuarbeiten hierzu erfolgten von der TeVeGe [TeVeGe], einem Tochterunternehmen der KBV, auf Basis der Vorgaben der Gematik [Gematik]. Somit kann hier festgehalten werden, dass die inhaltlichen Arbeiten von SCIPHOX inzwischen überholt wurden. Die Arbeitsgemeinschaft wurde auch aufgelöst und nach HL7-DE überführt. Die Arbeitsgruppe war damals eine wichtige Initiative, um den ambulanten Sektor mit in die Standardisierung der Kommunikation mit einzubeziehen.

1.5. Detailed Clinical Information Models

Eine neuere Initiative, an der auch der Autor initiativ beteiligt ist, befasst sich mit generischen klinischen Informationsmodellen, die über eine Gemeinschaftsaktivität von IHE PCC sowie HL7 Patient Care, Vocabulary und Terminology [DCM]. Die in dieser Arbeit vorgestellten Ausarbeitungen zu Scores und Assessment Systemen fließen dort ein. So ist das erarbeitete Modell inzwischen als DSTU (Draft Standard for Trial Use) akzeptiert. Die dazugehörige Publikation befindet sich in Vorbereitung.

 

Last Update: March 22, 2010