Eine Fülle an Werkzeugen

HL7 hat eine großartige Entwicklung hinter sich. Im Zuge dieses Fortschritts sind eine ganze Reihe nützlicher Tools entstanden. Kai Heitmann gibt einen Einblick in die Werkstatt, die nie stillsteht.

Health Level 7 (HL7) ist wohl vor allem bekannt wegen seiner Version 2. Sie ist der Nachrichtenstandard für den Austausch von Gesundheitsdaten unterschiedlicher Gesundheitsorganisationen. Hier werden Subsysteme mit administrativen, medizinischen und abrechnungsrelevanten Daten versorgt, sodass alle Systeme auf dem neuesten Stand sind. HL7 v2.x wird seit 1987 von der HL7-Organisation (hl7.org) entwickelt und ist seit Mitte der 1990er-Jahre in der Mehrzahl der deutschen Krankenhäuser zu finden. Ähnlich erfolgreich ist die Clinical Document Architecture (CDA), ein HL7-Standard für elektronische Dokumente sowie FHIR (Fast Healthcare Interoperability Resources), die vor allem mobile Techniken und Verfahren adressiert. Im Folgenden sollen die Funktionen von CDA undFHIR näher beleuchtet werden.

Ein Standard setzt sich durch
Die Clinical Document Architecture (CDA) – ein HL7-Standard für elektronische Dokumente – gehört in die Familie der Version 3-Standards von HL7. Der darauf basierende, modell-getriebene Nachrichtenaustausch hat sich aber weniger durchgesetzt als erwartet. Das „Familienmitglied“ CDA war wesentlich erfolgreicher, ähnlich wie die HL7-Version 2.x. Im Grunde spricht man bei der zweiten Generation von HL7-Standards deshalb oft ausschließlich von CDA. Elektronische Pendants zu den typischen papierbasierten Dokumenten und Formularen wurden zum Beispiel für ärztliche Entlassbriefe, Infektionsschutzmeldungen, Laborberichte, Radiologiebefunde und einiges mehr definiert. Letztlich kann man elektronische Patientenakten als eine Sammlung medizinisch relevanter elektronischer Dokumente auffassen. Neben den strukturierten „Briefkopf“-Daten, die sich zum Beispiel auch in einem Entlassbrief finden (Patient, Arzt, Angehörige, Ereignis und Leistungsort usw.), gibt der sogenannte Body die eigentlichen klinischen Informationen wie Anamnese, Beschwerden, Medikation, Allergien, weiteres Vorgehen etc. wieder. Im Vordergrund steht dabei der Freitext, der sich um computerauswertbare, hochstrukturierte und meist auch codierte Komponenten, sogenannte Entries, etwa Diagnosen, Medikation etc. ergänzen lässt.

Damit eröffnet sich eine ganze Palette von einfachen bis hin zu mehr komplexeren Möglichkeiten, die sicherlich auch zum Erfolg von CDA beigetragen haben. CDA definiert also die Inhalte elektronischer Dokumente mit Strukturen und Semantik, die zum Beispiel in Aktensystemen gespeichert und verwendet werden können. Für den Transport der Dokumente gibt es weitere etablierte Verfahren wie etwa IHE Cross-Enterprise Document Sharing (XDS).

FHIR hat die Entwicklung befeuert
Die bereits erwähnte jüngste Generation der HL7-Standardpalette – FHIR (hl7.org/fhir) – fokussiert vor allem mobile Anwendungen. Sie vereinigt Vorteile der etablierten HL7-Standard „Produktlinien“ Version 2 sowie CDA mit denen aktueller Webstandards und legt einen starken Fokus auf eine einfache Implementierung.

Die Entwicklung von FHIR wurde vom Paradigmenwechsel im Gesundheitswesen beeinflusst: Der Patient will mitbestimmen, was mit seinen Daten passiert und fordert mehr Transparenz. Er ist heute eher online statt offline und möchte Daten in Echtzeit und bedarfsgerecht erhalten, sie selbst nutzen und analysieren.

Im Vordergrund bei FHIR stehen deshalb die sogenannten Resources: kompakte, logisch diskrete Einheiten für den Datenaustausch mit einem zugehörigen wohldefinierten Verhalten und genau festgelegter Bedeutung. Beispiele sind „Patient“, „Maßnahme“, „Medikation“, „Anforderung“ oder „Fragebogen“. Resources können an Bedürfnisse angepasst (Profilierung)und nach Bedarf angereichert (Extensions) werden. Zurzeit befindet sich dieser Standard noch in der Entwicklung. Gerade ist FHIR in Phase 3 des Stadiums „Standard for Trial Use“ (STU) angekommen und wird von einer großen Community feinjustiert. Vor allem wegen seiner einfachen Implementierbarkeit und den damit einhergehenden geringeren Kosten sowie der schon von CDA bekannten Skalierbarkeit kommt FHIR heute und künftig vor allem in mobilen Applikationenzum Ein satz. HL7 Deutschland (hl7.de) arbeitet außerdem an den sogenannten „Basisprofilen“, also der Wiedergabe der deutschen Besonderheiten des Gesundheitswesens wie der „eGK-Nummer“ oder einer lebenslangen Arztnummer (LANR) in FHIR.

Ein reich gefüllter Werkzeugkasten

Um Standards und davon abgeleitete Implementierungsleitfäden (Spezifikation) konsistent zu definieren und Softwareanbieter bei der Implementierung der Standards zu unterstützen, bedarf es leistungsfähiger Tools. Dabei hat sich für die Entwicklung von CDA-basierten Implementierungsleitfäden ART-DECOR ® (art-decor. org) durchgesetzt. Designer können damit sogenannte Building Block Repositories (BBRs) einsetzen und sich so die Wiederverwendbarkeit von Komponenten zunutze machen. Softwareingenieure profitieren zudem in der Implementierungsphase von Test- und Validierungsmethoden für neu zu entwickelnde Software. In größerer Skalierung arbeitet das Tool zum Beispiel eng mit IHE-Gazelle, einem Validierungs-Framework, zusammen. Von der ART-DECOR Expert Group entwickelt und durch das Unternehmen ART-DECOR Open Tools (art-decor-open-tools.net) begleitet, kommt ART-DECOR® inzwischen in über 50 Projekten zum Einsatz, vornehmlich in Europa.

Das von der niederländischen Firma Furore herausgebrachte Tool Forge (fhir.furore.com/Forge) wird dagegen zur Profilierung von FHIR-Resources genutzt und arbeitet optimal mit dem Profile Management- und Publikations-Tool Simplifier (simplifier.net) zusammen. Simplifier selbst kooperiert auch mit ART-DECOR®, sodass auf diese Weise zum Beispiel Übergänge und Mapping von CDA nach FHIR und umgekehrt unterstützt werden.

Alternativ bietet sich das webbasierte Tool ClinFHIR (clinfhir.com) an, das bei der FHIR-Profilierung nicht ganz so umfangreich ist, dafür aber eine ganze Reihe anderer Features aufweist. HL7 Version 2, CDA und FHIR werden uns noch lange begleiten. Erst in den vergangenen Jahren ist deutlich geworden, wie wichtig die einzelnen Tools für alle Phasen sind – vom Design über Implementierung bis hin zum produktiven Einsatz.