HL7 ist Pflicht in der deutschen Telematikinfrastruktur

In Bezug auf Datenformate hat das Bundesministerium für Gesundheit (BMG) eine strategische Sicht. Das Architekturboard des BMG hat am 7.4.2006 entschieden „die weitgehende Nutzung von HL7 in der Definition von Daten- und Kommunikationsstrukturen zu verwenden, soweit dies durch die HL7-Definition möglich ist. (Notwendige) Änderungen zu HL7 werden über die deutsche HL7-usergroup in die Standardisierung eingebracht.“ (AB Protokoll 7.4.2006)

In einer späteren Entschließung heißt es:

„Nach Auffassung der Leistungserbringer sollten sich die strukturellen Vorgaben für die medizinischen und administrativen Daten nach den Vorgaben von HL7 richten. Wo immer möglich, sollten HL7-Festlegungen genutzt werden. In Bereichen, in denen das nicht möglich ist, sollte eine Erweiterung der HL7 Strukturen angestrebt werden.“ (AB Protokoll 16.6.2006)

Dittmar Padeken (BMG): “Bei den medizinischen Daten ist HL7 auf jeden Fall zu Grunde zu legen. Dieses schließt Detaillierungen, Ergänzungen und auch Abweichungen, die sich aus den spezifischen Erfordernissen des deutschen Gesundheitssystem ergeben, nicht aus.“ (AB Protokoll 31.3.2006)

Die “gematik kann die Standardisierung beeinflussen: wo HL7 keine adäquaten Lösungen bereitstellt, kann das in den HL7-Standardisierungsprozess eingebracht werden oder eigene Lösungen entwickelt werden.“ (AB Protokoll 31.3.2006)

Nun stellt sich die Frage, wo HL7 keine adäquate Lösung bietet. Es hat mittlerweile in Deutschland Architektur-Entscheidungen gegeben, die dazu führen, dass HL7 in Teilbereichen keine Lösung mehr bieten kann.

Zu unserem Beispiel: Es wurde entschieden, dass ein eRezept auf der Karte gespeichert werden soll. Die Karte hat jedoch nur eine sehr geringe Speicherkapazität (zuerst 32 Kb, jetzt 64Kb). Die oben erwähnte Architekturentscheidung führt einerseits dazu, dass ein kartenbasiertes eRezept nur wenige medizinische Details beinhaltet und anderseits, dass man nicht in der Lage ist, ein HL7 CDA eRezept Dokument (XML basiert, detaillierte Rezeptdaten inklusive Kontraindikationen, Diagnosen usw.) auf der Karte zu speichern – weil es „zu umfangreich“ ist. Dazu ist anzumerken, dass die Entscheidung, medizinische Nutzdaten - wie etwa die eVerordnung - unmittelbar auf der Karte zu speichern, ebenfalls eine Vorgabe des BMG und nicht etwa eine Idee der gematik oder ihrer Gesellschafter ist.

HL7 ist im Moment aus medizinischer Sicht die beste Lösung für serverbasierte Anwendungen. Hätte die eGK eine größere Speicherkapazität (was eine Frage der Zeit ist), würden alle Daten- und Kommunikationsstrukturen der Telematikinfrastruktur auf HL7 basieren – gleichzeitig würden sich die Kosten für die Einführung aber immens erhöhen, da größere Chips teurer sind als kleine. Bei 70 Millionen Karten potenzieren sich die Kosten. In anderen Ländern setzt man deshalb das eRezept online um, also ausschließlich auf Servern. Auf einer Karte wäre somit nur der Link auf das eRezept auf dem Server, das in HL7-CDA vorliegt.

Tatsächlich sehen die bisherigen Ergebnisse der gematik lediglich stark reduzierte und eingeschränkte Nachrichten- und Speicher-Strukturen vor, die sich nur noch sehr entfernt auf HL7 v3-Strukturen beziehen.

„Es ist für den Leistungserbringer nicht akzeptabel, wenn sich die gematik bei der Festlegung des Datensatzes in der Facharchitektur allein auf eigene, proprietäre Strukturen stützt, anstatt auf den bestehenden Erfahrungen der HL7 Gruppe aufzubauen.“ (AB Protokoll 27.10.2006)

„Für den VODD und den Verordnungsdatensatz wurde ein Kompromiß zwischen der gematik und den Leistungserbringer erzielt. Das Informationsmodell wird in der Form, wie es in der Facharchitektur steht, Grundlage der weiteren Arbeiten. […] Die KBV bevorzugt weiterhin HL7 als übergeordnetes Informationsmodell, wird sich aber dem Mehrheitsvotum entsprechend an dem neuen Informationsmodell der gematik ausrichten“ (AB Protokoll 26.1.2007)

Das Architekturboard des BMG hat später entschieden: „Die Datenstrukturen [der kartenbasierte Versichertenstammdaten] müssen nicht den Vorgaben durch den HL7-Standard entsprechen. Die Datenstrukturen sollen sich jedoch an HL7 anlehnen und eine Transformation zulassen.“ (AB Protokoll 27.10.2006). Statt internationale Standards zu übernehmen hat man demnach neue Standards teuer entwickeln lassen. Damit ist allerdings auch die Chance verringert, die Karte international zu vermarkten (Zitiert nach Handelsblatt, 19.09.2006) und die Möglichkeit einer einheitlichen Telematikplattform in Deutschland zunächst verschenkt.

Die gematik hat unserer Meinung nach sicherzustellen, dass die kartenspezifischen Datenformate (eRezept und Notfalldatensatz) eindeutig auf HL7 abzubilden sind, so dass die Migration der Daten in ein einheitliches Format ermöglicht wird. Derzeit zeichnet sich allerdings eine nationale Lösung ab. An den ersten Anwendungen werden sich natürlich auch die zukünftigen Anwendungen orientieren. Einmal gemachte Fehler sind kaum noch wieder gut zu machen. Wird im eRezept und bei den Versichertendaten ein nationaler Alleingang versucht, fernab von HL7, hätte dies also fatale monetäre Folgen.

Die Spezifikationshoheit der freiwilligen Anwendungen liegt bei den Leistungserbringern unter beratender Begleitung der Kostenträger. Anwendungen, die über die Pflichtanwendungen hinausgehen, wie der elektronische Arztbrief oder die elektronische Patientenakte werden im freien Markt erarbeitet, orientieren sich an internationalen Standards und kommen schnell in der Breite zum Einsatz. Dies zeigt, dass eine Reglementierung von oben nicht in allen Fällen sinnvoll ist und es auch anders geht.

HL7 ist angesichts seiner fachlichen Breite sowie seiner einzigartigen methodischen Grundlagen in der Deutschen Telematikinfrastruktur als Pflicht zu betrachten - sei es als übergeordnetes Informationsmodell oder als Nachricht/Dokumentstruktur.

-Rene

PermaLink to this page: http://www.ringholm.de/column/hl7_ist_pflicht_in_der_deutschen_telematikinfrastruktur.htm

Index of columns:

• Adding openness to a closed world (Feb 09, 2010)
• How to lower the hurdle for HL7 v3 implementers (Jan 21, 2010)
• HL7 v3 deployment statistics (Dec 17, 2009)
• There's Trouble in Paradigm (Sep 25, 2009)
• Internationalization of HL7 (Sep 24, 2009)
• HL7 UK signs deal with Ringholm to deliver HL7 v2/v3 training courses in London (Sep 17, 2009)
• The use of HL7 in South Africa (Aug 20, 2009)
• The Next Web Conference in Amsterdam (Apr 17, 2009)
• The HL7 UK AGM and RIMBAA (Apr 16, 2009)
• The HL7 Wiki reaches 2000 pages (Mar 02, 2009)
• The HL7 roadmap for CDA R3 and the CCD (Jan 17, 2009)
• HL7 Affiliates Meeting in Orlando (Jan 11, 2009)
• Swiss and Dutch HL7 News (Dec 31, 2008)
• Devices and Prizes (Nov 22, 2008)
• HL7 in Norway: a situation report (Sep 02, 2008)
• Russian whitepaper (Jul 09, 2008)
• The HL7 Interoperability Conference - IHIC 2008 (May 30, 2008)
• HL7 creates a RIM Based Application Architecture (RIMBAA) group (May 18, 2008)
• Notes from the HL7 WGM in Phoenix (May 08, 2008)
• Germany embraces CDA eReferral document specification (May 02, 2008)
• HL7 v3 RIM based applications: an unintended side effect (Jan 19, 2008)
• Collaborative Tools (Jun 21, 2007)
• HL7 ist Pflicht in der deutschen Telematikinfrastruktur (German, Mar 16, 2007)
• HL7 based Tree inventory system (Jan 30, 2007)
• The link between HL7 and Open Source Software (Jan 06, 2007)
• Workflow Bribery (Sep 15, 2006)
• Timezones in HL7 (Jan 23, 2004)
• Controlled vocabularies: "@*%!!!" ? (Sep 01, 2003)
• Trusting the other Party (Nov 01, 2002)

Über Ringholm GmbH