gms | German Medical Science

51. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e. V. (gmds)

10. - 14.09.2006, Leipzig

Bausteine für zukünftige HL7-Hausstandards

Meeting Abstract

Suche in Medline nach

  • Detlef Kraska - Universitätsklinikum Erlangen, Erlangen
  • Bernhard Wentz - Universitätsklinikum Erlangen, Erlangen
  • Hans-Ulrich Prokosch - Friedrich-Alexander-Universität Erlangen-Nürnberg, Erlangen

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (gmds). 51. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie. Leipzig, 10.-14.09.2006. Düsseldorf, Köln: German Medical Science; 2006. Doc06gmds394

Die elektronische Version dieses Artikels ist vollständig und ist verfügbar unter: http://www.egms.de/de/meetings/gmds2006/06gmds248.shtml

Veröffentlicht: 1. September 2006

© 2006 Kraska et al.
Dieser Artikel ist ein Open Access-Artikel und steht unter den Creative Commons Lizenzbedingungen (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.de). Er darf vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Gliederung

Text

Einleitung und Fragestellung

Der Nachrichtenstandard HL7 in der Version 2 (HL7 V2) ist international als der führende Standard für die klinikinterne Kommunikation von strukturierten patientenbezogenen Daten fest etabliert. Die oft diskutierten Nachteile – das Fehlen eines Referenzmodells, zu viele Optionalitäten, Mehrdeutigkeiten bei der Interpretation – haben seine Verbreitung nicht behindert, sondern eher begünstigt. In HL7 V2 können sich die Hersteller von klinischen Anwendungssystemen und die Kunden „wiederfinden“, da der Standard genügend Freiheiten bietet, das eigene Daten- und Transaktionsmodell abzubilden. Dies wurde in der Vergangenheit durch das Fehlen von Conformance Statements und Zertifizierungsstellen zusätzlich begünstigt.

HL7 V2 stellt ein Rahmenwerk dar, das zwar mehr ist als ein kleinster gemeinsamer Nenner, aber zu schwach ist für einen Standard, der Interoperabilität ermöglichen soll. Das Arbeiten mit HL7 V2 in einem konkreten Integrationsprojekt gestaltet sich deswegen oftmals sehr schwierig. Da HL7 V2 den semantischen Aspekt der Interoperabilität oft nur unzureichend abdeckt, braucht man Werkzeuge und Hilfskonstrukte, die es ermöglichen, die verbleibenden Unterschiede zweier zu verbindender Systeme auszugleichen. In den meisten Krankenhäusern und Klinika werden heutzutage Kommunikationsserver eingesetzt, welche – je nach Produkt verschieden stark – auf das Gesundheitswesen spezialisierte Baukästen sind, die das Lösen der meisten der auftretenden Probleme bei der Integration komfortabel unterstützen.

Des Weiteren haben viele Krankenhäuser einen sog. Hausstandard entwickelt, der die spezielle Ausprägung von HL7 V2 für das Haus beschreibt. Diese Hausstandards geben dabei meistens die Ausprägungen der Schnittstellen der eingesetzten zentralen EDV-Verfahren (Patientendatenmanagement, Laborsysteme) wieder, so dass die Hausstandards zweier verschiedener Klinika genauso gut oder schlecht zusammenpassen wie die HL7-Schnittstellenbeschreibungen zweier beliebiger klinischer Anwendungen. Hausstandards haben im Normalfall nicht die Verbreitung einer akademischen HL7-Sicht zum Ziel, sondern sie dienen als Hilfsmittel, um die Implementierungsphase bei Integrationsprojekten zu verkürzen. Größere Klinika schaffen es, kleinere Hersteller zur Implementierung Hausstandard-konformer Schnittstellen zu zwingen, was aber auch nicht immer zielführend sein muss, da dies die spezifischen Eigenheiten der Systeme missachtet.

Welche neueren Entwicklungen aus dem Umfeld des HL7-Standards können die Krankenhäuser und Klinika nutzen, um die Hausstandards umzugestalten, und zwar weg von einer Hersteller- und hin zu einer Standard-getriebenen Beschreibung?

Material und Methoden

Drei Entwicklungen sollen hier betrachtet werden, die den Grad der Interoperabilität steigern wollen: HL7 Version 3 (HL7 V3) in der normativen Edition von 2005 [1] ist der erste Meilenstein einer seit Jahren andauernden Bemühung der internationalen HL7 Gruppe, unter Vermeidung der Defizite von Version 2 und unter Einsatz moderner Entwicklungsmethoden einen Standard zu erschaffen, der die Basis für die Integration klinischen Anwendungen im gesamten Gesundheitswesen darstellen kann. HL7 V3 ist dabei kein fertiger Standard, sondern er ermöglicht es, aufbauend auf dem Reference Information Model (RIM) eigene Domänenstandards abzuleiten, die trotzdem noch konform zu allen anderen Domänenstandards sind. Eine weitere Stärke von HL7 V3 ist, dass klinische Inhalte detailliert modelliert werden können, wohingegen es bei HL7 V2 nur Container für klinische Inhalte gab. HL7 V2 ist detailliert im administrativen und unspezifisch im klinischen Bereich. HL7 V3 hingegen kann – aufbauend auf einem generischen Modell – in allen Bereichen spezifisch sein.

Allerdings wird HL7 V3 wahrscheinlich HL7 V2 innerhalb der Kliniken mittelfristig nicht verdrängen. Für viele Zwecke ist HL7 V2 ausreichend, die Schwächen sind größtenteils beherrschbar. Schnittstellen für den administrativen Bereich sind in HL7 V3 zwar definiert, aber es fehlt bis jetzt noch in großen Teilen die deutsche Anpassung. Für Hersteller bedeutet die Umstellung ihrer Schnittstellen auf die neue Version einen hohen Investitionsaufwand, den sie ohne Druck der Kunden kaum leisten werden.

Die zweite Entwicklung ist die IHE-Initiative [2], die seit 1997 aufbauend auf HL7 V2, DICOM und anderen Standards mittels einer pragmatischen Herangehensweise in Etappen einen immer größer werdenden Bereich der klinikinternen Kommunikation abdeckt und beschreibt. Ein organisatorischer Teilbereich (bspw. die Radiologie) wird mittels mehrerer Integrationsprofile beschrieben, die jeweils einen abgeschlossen Arbeitsbereich betrachten. Ein Integrationsprofil beschreibt Aktoren und die zwischen ihnen ausgetauschten Transaktionen. Für die Implementierung der Transaktionen werden die verwendeten (Nachrichten-)Standards herangezogen. IHE setzt zur Definition der Integrationsprofile als Werkzeuge Arbeitsablauf- und Prozessdiagramme ein, welche in dieser Ausprägung in keinem der anderen Ansätze verwendet werden. Die Diagramme beschreiben die Transaktionen in ihrem Kontext und nicht für sich alleine stehend, was kaum noch Interpretationsspielraum lässt. Bei HL7 V2 ist bei einer Nachricht nicht streng definiert, in welchem Kontext sie zu welchem Zweck verwendet wird - und dieser Freiraum wird auch von den Herstellern genutzt.

IHE hat seine Stärken in Bereichen, in denen die Arbeitsabläufe und die auszutauschenden Informationen relativ strikt definiert werden können. Die Initiative muss sich noch in den Bereichen beweisen, in denen die Aktoren und ihre Interaktionen weniger klar abgrenzbar sind und der Einfluss - ständig wechselnder - gesetzlicher Vorgaben stärker ist. Die Domäne der Patientenadministration wird bei IHE nur in den Teilen betrachtet, die für die beschriebenen Abteilungssysteme relevant sind.

Die letzte der betrachteten Entwicklungen geht von der deutschen HL7 Benutzergruppe aus. Das Projektbüro der Benutzergruppe spezifizierte 2004 eine erste Version von HL7 V2 Nachrichtenprofilen, die 2006 in einer zweiten Version noch einmal umfassend erweitert wurden [3]. Diese Nachrichtenprofile dienen als Basis einer Konformitätsprüfung, die vom ZTG durchgeführt wird und über die ein Zertifikat erworben werden kann. Im Fokus der Nachrichtenprofile stehen Nachrichten aus den Bereichen ADT und BAR, wobei Optionalitäten eingeschränkt und mehrdeutige Felddefinitionen präzisiert werden. Besonderer Wert wird auf die Definition von Informationen gelegt, die für die Abrechnung relevant sind.

Während IHE den Kontext einer Nachricht genau beschreibt und den Inhalt nur soweit wie nötig festlegt, wird bei der Definition der Nachrichtenprofile eine andere Herangehensweise gewählt. Hier wird der Inhalt strikt und ausführlich definiert, der Kontext aber nur lose.

Ergebnisse

HL7 V3 ist im jetzigen Stadium noch nicht so weit, einen HL7 V2 Hausstandard zu ersetzen. HL7 V3 muss im Bereich der klinikinternen Kommunikation hierzulande erst noch Akzeptanz finden. HL7 V3 wirkt momentan nur indirekt auf die klinikinterne Kommunikation, da die Weiterentwicklung von Version 2 nur noch gekoppelt mit der Weiterentwicklung der Version 3 geschieht. Reine HL7 V3-Schnittstellen trifft man dort an, wo entweder HL7 V2 bis jetzt fehlte oder Systeme komplett neu entwickelt wurden [4].

Die Integrationsprojekte an den Klinika können aber von den Arbeiten der IHE-Initiative und von den HL7 Nachrichtenprofilen profitieren. Die Nachrichtenprofile repräsentieren den aktuellen Wissensstand, wie mit HL7 V2 die wichtigsten administrativen Informationen ausgetauscht werden können. Würden alle Hersteller die Nachrichtenprofile unterstützen, könnte dies die Implementierungsphase einer neu einzurichtenden Schnittstelle um einen signifikanten Prozentsatz verringern. Der mindestens genauso aufwändige Teil der Schnittstellenentwicklung, nämlich der Test der implementierten Schnittstelle mit Testszenarios, in denen Nachrichten in ihrem Kontext durchgespielt werden, wird dadurch aber nicht erleichtert. Hier bräuchte es für den Bereich Patientenadministration Arbeitsablauf- und Prozessdiagramme, die im Vorhinein festlegen, welche Abläufe unterstützt werden müssen und welche nicht gestattet sind. IHE bietet dieses nur für den Kontext ausgewählter Abteilungssysteme, was für einen übergreifenden Hausstandard nur ein Anfang sein kann.

Um einen bestehenden Hausstandard im Sinne einer besseren Standardunterstützung – weg von einer Ausrichtung auf die im Haus eingesetzten Systeme – weiterzuentwickeln, sollte ein Abgleich mit den Nachrichtenprofilen durchgeführt werden. Unterstützen die datenliefernden Systeme (bspw. das Patientendatenmanagementsystem) nicht alle erforderlichen Felder, oder ist die benötigte Information nur indirekt ableitbar, kann entweder auf die Hersteller eingewirkt oder eine Ergänzung der Informationen über eine Mediationsschicht [5] implementiert werden. Bei der Beschaffung neuer klinischer EDV-Systeme sollte in der Ausschreibung eine durchgeführte Zertifizierung abgefragt werden.

Hausinterne Testszenarios sind darauf zu prüfen, ob die Abläufe aus den IHE-Prozessdiagrammen abgedeckt sind. Auch die Nachrichteninhalte der IHE-Transaktionen sind mit denen des Hausstandards abzugleichen. Im Zweifelsfall sollte aber eine Felddefinition aus den Nachrichtenprofilen den Vorzug vor einer abweichenden Definition in IHE haben. Bei Anschaffung von Systemen aus einem durch IHE abgedeckten Bereich können die Ergebnisse aus den IHE-Connectathons abgefragt werden.

Diskussion

Obwohl die Entwicklung weitergeht, ist mit HL7 V2 ein Plug&Play nur in Teilbereichen und mit Einschränkungen zu erreichen. Wie nahe HL7 V2 diesem Ziel noch kommen wird, lässt sich jetzt noch nicht sagen. Allerdings geht jede Anstrengung, die HL7 V2 weiterbringt, zu Lasten der Entwicklung von HL7 V3. Wie lange die internationalen HL7 Benutzergruppen noch die Ressourcen aufbringen können und wollen, an zwei Versionen parallel zu arbeiten, steht noch nicht fest. So lange allerdings noch Schnittstellen auf Basis von HL7 V2 in Kliniken in größerem Ausmaß in Einsatz sind, so lange gibt es in der Routine Probleme bei der Integration. Diese Probleme können dann am Besten gelöst werden, wenn alle zur Verfügung stehenden Erkenntnisse aus den Standardisierungsbemühungen genutzt werden.


Literatur

1.
HL7 V3 Normative Edition 2005. Health Level Seven Inc. 2005
2.
Integrating the Healthcare Enterprise. http://www.ihe.net. Zuletzt besucht 9.4.2006.
3.
HL7-v2.5-Nachrichtenprofile. Version 2.0. HL7 Benutzergruppe in Deutschland e.V. 2006
4.
Spahni S et al. Implementing a New ADT Based on the HL-7 Version 3 RIM. Connecting Medical Informatics and Bio-Informatics. Engelbrecht et al. (Eds.). ENMI, 2005.
5.
Wentz B, Kraska D, Knispel S, Prokosch HU. 10 Jahre Erlanger Kommunikationsdrehscheibe - der Weg zu einer zukunftssicheren Integrationsplattform. 50. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds). Freiburg im Breisgau. 2005