Interoperabilität schaffen durch Transparenz in der Implementation von HL7
Maren Müller
Eine zeitgemäße, d. h. Sektor übergreifende und Patienten orientierte Kommunikationsstruktur im Gesundheitswesen sollte Medienbrüche weitestgehend verhindern und den digitalen Datenaustausch ermöglichen. Diese von allen Akteuren im Gesundheitswesen, einschließlich der Politik erhobene Forderung, kann aber nicht allein durch den bloßen Einsatz moderner Informations- und Kommunikationstechnologien garantiert werden. Auch dann nicht, wenn nach Aussagen der IT-Hersteller der gegebene Standard integriert wurde. Letzteres stellt zwar die zwingende Voraussetzung zur Schaffung von Interoperabilität dar; aber mehr auch nicht. Denn die theoretisch postulierte Forderung nach Interoperabilität durch den Einsatz von Standards scheitert in der praktischen Umsetzung oftmals an der facettenreichen Komplexität der Standards. Erst die korrekte, d. h. Standard konforme, Implementierung ermöglicht die Interoperabilität, die uns der Vision einer Plug-and-Play-Fähigkeit von Softwarekomponenten näher bringt. Hier gilt es, Herstellern von IT-Komponenten die Möglichkeit zu eröffnen, die Konformität ihrer Produkte zu den bestehenden Standards neutral zu testen.
HL7 – Kommunikationsstandard mit Interoperabilitätslücken
HL7 ist ein Kommunikationsstandard im Gesundheitswesen, der am häufi gsten in der stationären Versorgung eingesetzt wird. Über HL7 wird die elektronische Kommunikation zwischen nahezu den gesamten Abteilungen innerhalb eines Krankenhauses sowie den angeschlossenen externen Einheiten ermöglicht. Entwickelt wurde der Standard in den USA, wo er in verschiedenen Versionen als ANSI-Standard offizielle Anerkennung findet.
Das einprägsame Kürzel „HL7“ steht für „Health Level Seven“. Dies unterstreicht den Anwendungsbezug für das Gesundheitswesen und referenziert auf die siebte Schicht (Anwendungsebene) des OSI-Modells.
Der Grundgedanke des HL7-Kommunikationsmodells ist es, Daten zu inhaltlich abgrenzbaren Einheiten zusammen zu fassen, den so genannten HL7-Nachrichten. Die Nachrichteninhalte bestehen wiederum aus Segmenten, die ihrerseits in Felder zerfallen. Diese Felder besitzen hinterlegte Tabellen und Datentypen mit Werten. Da man nicht immer alle unterschiedlichen HL7-Nachrichten in der jeweiligen Umgebung benötigt, werden Nachrichten der Versionen 2.x bisher nach Trigger Events (Auslöser), wie beispielsweise einer Patientenaufnahme, implementiert. Die Trigger Events defi nieren jedoch nur eine relativ grobe Nachrichtenstruktur, die viele optionale Felder enthält und damit Möglichkeiten einer unterschiedlichen Implementierung zulassen. Nachrichten mit gleichen Trigger Events sind deshalb nicht ohne weitere Abstimmung kompatibel implementierbar. So kann es bspw. vorkommen, dass ein System eine Nachricht über eine Patientenaufnahme versendet, das empfangende System, bei dem dieser Patient bekannt gemacht werden soll, diese Nachricht empfängt, aber einzelne Segmente und deren dazugehörige Feldern gar nicht auslesen kann. Dies verursacht in erheblichem Maße Aufwand und Kosten.
Damit wird deutlich, dass trotz der Standardisierung von HL7 eine Vielzahl an Möglichkeiten existiert, den Standard in die jeweilige Software zu implementieren. Die Standardisierung ist daher nur der erste Schritt zur Interoperabilität, der zweite ist die einheitliche Implementierung des Standards.
Hier setzt die ZTG Zentrum für Telematik im Gesundheitswesen GmbH an. Im Rahmen des durch das Land NRW und die EU geförderten Projektes „Entwicklung von Konformitätswerkzeugen für den HL7-Standard“ (MTK2 001-0310-003), werden erstmalig aussagekräftige Nachweise bezüglich der Standardkonformität von Softwareprodukten entwickelt. Dazu wurde die HL7-Benutzergruppe Deutschland e.V. durch das ZTG beauftragt, verbindliche Vorgaben zur Implementation von HL7-Nachrichten zu schaffen. Diese Vorgaben wurden in sog. Nachrichtenprofi len zusammengefasst. Nachrichtenprofi le bilden keine gesamte HL7-Nachricht ab, sondern defi nieren Bestandteile, die in HL7-Nachrichten vorkommen, wie bspw. Segmente, Felder, Tabellen oder Datentypen.
Nachrichtenprofi le – Richtlinien zur Implementation von HL7
Insgesamt existieren im HL7-Standard der Version 2.5 über 300 Nachrichten. Hier gilt es, relevante Bestandteile zu identifi zieren, d. h. solche, die häufi g in Nachrichten auftreten. Nach derzeitigem Stand sind dies die folgenden Segmente: MSH, SFT, PID, PV1, PV2, NK1, MSA, Err, ENV. Die Anforderung besteht aber auch darin, mit den Nachrichtenprofi len keine Insellösungen zu erarbeiten, sondern eine enge Orientierung am Standard zu suchen. Weiterhin dürfen die aufgestellten Vorgaben die Möglichkeit zur Abbildung der Dateninhalte nicht einschränken, vielmehr müssen weiterhin alle im Standard vorgesehenen Inhalte abgebildet werden können. Die wichtigste Anforderung besteht jedoch darin, den Nachrichtenprofi - len eine normative Aussagekraft zu verleihen. Um dies zu gewährleisten unterliegen die von den Mitgliedern der HL7-Benutzergruppe Deutschlands e. V. erarbeiteten Profi le dem Abstimmungsmodus (Ballot) innerhalb der gesamten Benutzergruppe in Deutschland. Die Verabschiedung wird im Herbst 2004 erwartet.
Aber nicht nur auf nationaler Ebene werden Vorgaben für den HL7-Standard erarbeitet. Für die Ermittlung von DRGErgebnisdaten wurden auf internatonaler Ebene zwei neue Segmente zur Diskussion gestellt. Auch hier ist im Herbst 2004 mit einer Entscheidung zu rechnen...
Dokumentinformationen zum Volltext-Download Titel: | Konformitätsprüfung und Zertifizierung
| Artikel ist erschienen in: | Telemedizinführer Deutschland, Ausgabe 2005
| Kontakt/Autor(en): | Maren Müller
| Seitenzahl: | 2 | Sonstiges | 1 Abb. | Dateityp/ -größe: | PDF / 249 kB | Click&Buy-Preis in Euro: | kostenlos
| Rechtlicher Hinweis: Ein Herunterladen des Dokuments ist ausschließlich zum persönlichen Gebrauch erlaubt. Jede Art der Weiterverbreitung oder Weiterverarbeitung ist untersagt. |