Episode #25 – HL7v2 und HL7v3

Wir beschäftigen uns heute mit HL7 sowohl ganz kurz der Organisation dann mit HL7 v2, HL7 v3 und in einem anderen Podcast werden wir uns mal mit dem RIM beschäftigen Überleitung. 

Ich habe in der Klausur dich jetzt vor kurzem korrigiert, habe die Studenten gefragt, wo ist der Unterschied zwischen CDA und HL7. Ich habe jetzt leider eben nicht gefragt, HL7 v2 oder V3 und CDA sondern nur HL7 und CDA bin davon ausgegangen, dass die Studenten verstehen, dass ich vermutlich HL7 v2 meint. Jetzt war bestimmt die Hälfte der Studenten tatsächlich so schlau und haben dann ja Antworten, HL7 ist eine Organisation und CDA ist dann eben, ja also auch eine Art Kommunikationsstandard. Und das war klug, das war gut gemacht, das war von mir unpräzise formuliert von den Studenten gut geantwortet, volle Punktzahl, erzähl mal was ist denn die HL7-Organisation. 

Die HL7-Organisation ist die Organisation, die neben HL7 auch noch ein paar andere Standards im Kommunikationswesen beschreibt. 

Die HL7-Organisation kümmert sich eben um HL7 v2, HL7 v3, das Rimm, CDA, FHIR, die Arden Syntax und so weiter. Sie hat sich also die Kommunikation im Gesundheitswesen auf die Fahnen geschrieben. Da wir jetzt schon planen, den nächsten Podcast mit den Institutionen zu machen, würde ich jetzt hier vielleicht die Spannung aufrechterhalten und auf den nächsten Podcast verweisen, weil dort werden wir das Thema noch mal intensiv von den Organisationen herbeleuchten. 

Ich fragte dich ja immer so gerne spontan, du magst es nicht, aber hier weiß ich, dass du die Antwort weißt, HL7, wo versteht es, siebte-Level im dem Schnittstellenstack. Genau, OSI-Referenzmodells, dass die siebte eben die Anwendungsebene und dafür steht eben auch die 7 in HL7. 

Genau, HL7 v2 gibt es eigentlich V1, da habe ich nie was von gehört. Egal, also wie beschäftigt uns erst mal mit HL7 v2, das ist der international am weitesten verbreitete Kommunikationsstandard im Gesundheitswesen, der basiert eben auf keinem Referenzmodell, werden wir vielleicht gleich noch kurz anschneiden, nicht wie CDA und nicht VHL7 v3. Wenn man jetzt einfach noch ein paar Gefühle, weil sie mitnehmen möchte zu HL7 v2, dann ist es, dass es eher pragmatische Ansatz ist, dass der ja textbasiert ist, nach dem Motto, Everyone is special in healthcare, ist es kein Plug-in-Play, sondern man muss eigentlich jede HL7 Kommunikation zwischen zwei Systemen im Krankenhaus, zum Beispiel ein bisschen anpassen, das ist der Nachteil, also one size fits none, auf der anderen Seite ist dieses Anpassen eben sehr pragmatisch und geht sehr schnell vonstatten. In Deutschland ist es glaube ich über 99 Prozent die HL7 v2 einsetzen, dort gibt es unterschiedliche Unterversionen von 2.1, ich glaube aktuell ist gerade die 2.6, die sind untereinander kompatibel, aber das mit der Kompatibilität ist ja sowieso so eine Sache, weil Felder relativ leicht definiert werden können. Es gibt nationale Technical Committees, die in diese HL7-Organisation auch drin sind und die können dann nochmal eigene Z-Signante definieren. In Deutschland gibt es ja die eGK, elektronische Gesundheitskarte und damit die Daten auch über HL7 v2 übermittelt werden können, gibt es eben das Technical Commit, unterwerden solche Deutschland-Spezifika auch definiert. 

Dann machen wir weiter Renato und mich zu Verbreitung, aber habe ich gerade schon mitgemacht oder? Ja, du hast mir so ein bisschen was weggenommen, auch zu den voren Nachteilen nachher noch, aber ich werde mit dann einfach die Punkte rauspicken, die ich noch brauche. Also die Verbreitung, man kann zwar 7V2 sagen, das ist im Gegensatz zu V3 auch, wahrscheinlich der wichtigste Schnittstellen Standard ist, ausgenommen jetzt die Bilder oder der radiologische Bereich. Es kommt vor im administrativen Bereich, also bei Aufnahmeverlegung und Lassung werden die Systeme mit ADT-Nachrichten synchronisiert. Es kommt vor bei dem ganzen Funktionstellen und Laborbereich, also die Auftragserteilung, Terminvergabe und Nachdurchführung der Maßnahmen, dann auch die Befundübermittlung findet über HL7 statt. Das sind dann ORM, ORR, ORU und DFT die Nachrichtentypen bei der Übertragung von Dokumenten. Da gibt es dann NDM-Dokumente und letztendlich ist es auch Thema bei der Abrechnung. Gut, das waren jetzt die Anwendungsbereiche und wie sehen denn jetzt die einzelnen Nachrichten aus, beziehungsweise wie sind sie aufgebaut, Christian? 

Aussehen tun sie nicht gut. Es ist nicht besonders schön menschenlesbar, wenn man sich mal so eine HL7 v2 nachricht anguckt, wird man schnell feststellen, dass es dort ganz viele Striche gibt. Also die Pipes, wenn man was mitnehmen möchte, wo dann erkennt man HL7 v2 nachrichten an den ganz vielen Pipes. Wie sind hier aufgebaut? Eine Nachricht besteht aus mehreren Segmenten. Jedes Segment hat dann Felder und innerhalb dieser Felder kann es nochmal komponenten gehen. Jedes Segment ist leicht zu erkennen, innerhalb einer Nachricht, weil jedes Segment durch einen Zeilenumbruch gekennzeichnet wird. Also wenn man eine Nachricht hat mit sechs Zeilen, wenn man nichts automatischen Zeilenumbruch anstellt, im Notepad oder wo immer, dann weiß man, dass man in dieser Nachricht sechs Segmente hat. Jedes Segment beginnt mit einem Header, mit einem Segment Header und in jedem Segment habe ich ja schon gesagt, gibt es mehrere Felder und diese Felder sind dann mit den Pipes getrennt. Das meint ich vorhin mit diesen Strichen. Also den Strich, den man bekommt, wenn man auf der deutschen Tastatur alt ger und dieses größer kleiner Zeichen drückt, dann gibt es diesen Strich oder für alle Apple jünger, wenn man alt taste und dann die sieben drückt. Das muss das sein, sorry. Genau, also am Anfang von jedem Segment gibt es den Header und der Header beschreibt, um was für ein Segment ist. Segment könnte zum Beispiel sein, ein Patient Visit. Jedes Feld kann eben auch wieder komponenten haben, die können angetrennt sein durch einen Dach. Also das, was man bekommt, wenn man auf den normalen deutschen Tastatur ganz oben, ganz links, diese Tastatur drückt unter Escape, Renato, was ist das beim Mac? Das ist das Dach. Beim Mac heißt das Dach, danke schön. Oder z. B. Das und Zeichen, das trennt dann nochmal Subcomponenten. Ja, ich weiß gar nicht, ob man wenn man das einfach nur hört, das jetzt dann alles sich so merken kann. Also nur mal ihn ganz schnell zusammengefasst. Eine Nachricht besteht aus Mähren, Segmenten, Segment wird durch einen Zeilen Umbruch getrennt. Jedes Segment hat einen Header. Da steht drin, um was es sich für ein Segment handelt. Zum Beispiel Patient Visit. Jedes Segment hat mehrere Felder. Die Felder sind durch diese Pipe getrennt. Wenn ein Feld keine Informationen hat oder auch fünf Felder hintereinander, dann hat man dort einfach vier oder fünf Pipes nebeneinander, ohne dass irgendwas dazwischen steht. Das macht das typische Aussehen von diesen Hals 7v2 Nachrichten aus. Was kann in so einem Feld drin stehen? Na ja zum Beispiel, wenn es sich so in den Patienten handelt der Nachnahme, Vornahme, Geburtstattung etc. Nachrichten Typen hast du gerade schon gesagt. Und es kann ja zum Beispiel sein, dass in einem System, in dem die Patienten aufgenommen werden, eben neuer Patient aufgenommen wurde, dann müssen die anderen Systeme informiert werden. Hallo, wir haben einen neuen Patient bzw. Einen neuen Fall und dann gibt es eben den Nachrichten Typ ADT, steht für den Miss admission discharge and transfer und die häufigsten Nachrichten Typen sind eben ADT, also für Patienten Bewegung, ORM, ORRU und ORU, für orda entry, wenn also einen System im anderen System einen Auftrag schickt, der terminiert werden soll und der befunden nachher zurückgeht. MDM Nachrichten, wenn nachher Dokumente verschickt werden oder auch bar Nachrichten, wenn es um Leistungsdaten zum Beispiel geht nach OPS und ICT. 

Jetzt haben wir also uns kurz angeschaut, wir sind die Nachrichten selbst aufgebaut. Was man natürlich noch sagen muss, da über bei H7V2 ist nicht festgelegt, wie diese Nachrichten an selbst bemittelt werden können. Kann natürlich eine TCP/IP-Socket-Kommunikation machen, gibt auch Häuser, wo die Informationen, diese Nachrichten dann in der Dateigeschrieben werden und die Dateien dann irgendwie auf einem Netzlaufwerk abgelegt werden. Diese H7V2 nach hinten kann man natürlich auch über Web-Service es irgendwo hinschreiben, das ist ja dann nur der Übertragungsweg. 

Ja, ich habe jetzt die Aufgabe, die Vor-Nachteile zu erläutern und da muss ich dir an einer Stelle gleich mal widersprechen beziehungsweise. Okay, ich gebe dir recht, schön sind die Nachrichten nicht, aber ein Vorteil von HL7 ist, dass es doch lesbar ist. Also man macht so eine Datei auf oder man guckt sich die Logfiles an und man kann erahnen, was da gerade übertragen wurde. Also wenn ein Labor wird übertragen wurde, dann steht dann meistens der Name und der Wert drin. Das ist schon mal ein großer Vorteil, wenn man zum Beispiel mal versucht hat, daikum Nachrichten zu lesen. Was extrem schwierig ist, weil dort eben nicht Text übertragen wird, sondern in vielen Fällen werden Code übertragen oder es werden die Sachen in Beiz kutiert. Ich verstehe, Menschen freut nicht verstehe HL7 ist sowas wie CDA, wo dann eben drin steht. Jetzt geht ein Diagnosenbereich auf, dann steht die Diagnosen jetzt geht der Diagnosenbereich zu. Das stimmt ja. Also im Vergleich zu CDA, ist es schlechter lesbar, im Vergleich zu DICOM, ist es wesentlich besser lesbar, wesentlich besser lesbar als so einige Handschriften von Ärzten. Ja, Vorteil auch, es ist flexibel, du hast dir vorhin schon gesagt, man hat zwar regeln, aber man kann dir auch anpassen und das wird teilweise auch getan. Also gerade halt, sieben Nachrichten werden für alle mögliche Kommunikationen eingesetzt. Man kann dann ORM Nachrichten auch dafür missbrauchen, andere Sachen anzufordern oder man kann ORU Nachrichten auch dafür missbrauchen, andere Informationen zu übertragen. Also nicht nur befunde, sondern zum Beispiel auch Informationen, die während einer OP entstanden sind und so weiter. Außerdem natürlich noch die große Verbreitung, also jeder kennt HL7 v2 kaum ein Haus, das das nicht verwende, es gibt kaum einen Softwareanbieter, der nicht irgendwie eine hal 7V2 Schnittstelle anbietet, das heißt, die Wissen über hal 7V2 ist weit verbreitet und es ist einfach. Die Nachteile hast du vorhin ja schon genannt, es ist kein Plug-and-Play, es ist ein wenig standardisiert, teilweise versucht die EHE da, Standards reinzubringen, aber da ist natürlich Wildwuchs Tor und Tür geöffnet und es enthält eben keine Semantik für deine beliebte semantische Interoperabilität, sondern eigentlich nur die Syntax. Also jedes System muss dann auf der anderen Seite genau gesagt bekommen, was es mit den Daten tut. 

Ja, das war HL7 v2, dann schauen wir uns doch mal die weiterentwicklung an Christian, wie sieht’s mit HL7 v3 aus? 

Ja, eigentlich kann man das, was wir gerade dann vor Nachteilen genannt haben, kann man jetzt genau invertieren und kann sagen, HL7 v3 ist eigentlich überraschenderweise ein neuerer Standard, das ist ein richtiger Plug-and-Play Standard, da ist, das ist jetzt meine private Einschätzung viel, viel verkopf da, HL7 v2, also HL7 v2 ist also der hemmt hermlige mit so einem, ja, ist in die Karo Holzfälle hemmt und HL7 v3 ist eher der glatzköpfige mit brülle verkopfte Wissenschaftler, allerdings auch mit altbewährter Technik nämlich XML, V3 ist modell basiert, also basiert auf dem RIM, was wir uns noch mal anschauen werden, dort sind die Rollen der Applikationen klar definiert, Problem ist, HL7 setzt keiner ein, also wenn man in der Untersuchung gesehen finde ich leider nicht mehr, das über 99% HL7 v2 einsetzen und das ist auch das große Problem bei HL7 v3 erstens ein bisschen verkopf, das heißt irgendwelche Anpassungen sind gutes Stück schwieriger, machbar als in HL7 v2 und es setzt keiner ein, weil es keine einsetzt, programmiert es keiner und weil es keiner programmiert, setzt es keiner ein, also es wäre eigentlich eine fast unnötige Investition, Ausnahme ist, dass die IHE Profile standardmäßig eigentlich HL7 v3 nachrichten referenzieren, also IHEEXDS haben wir ja schon mal gesagt, dort wenn auch HL7 nachrichten referenziert, aber eben HL7 v3 und da ist eben die Frage, ob die Anbieter dann über diese IHEE Geschichte irgendwann gezogen werden, HL7 v3 zu machen, meiner Meinung nach hat es kein großen Mehrwert oder ob die einfach sagen wir machen IHEE mit HL7 v2, lassen HL7 v3 einfach komplett aus und das wir haben nicht meinen preferierte Methode wir springen von HL7 v2 direkt auf FHIR, was wir hier ja auch schon mal im Podcast hatten, jetzt habe ich die bestimmte irgendwelche Sachen vorweg genommen oder? 

Eigentlich alles. Ja, also IHEEXDSML passiert, hast ja schon genannt und wir werden uns in einem eigenen Podcast mal nur mit dem Rimm und mit dem genauen Aufbau beschäftigen. 

Vielleicht noch eine Sache, weil du HL7 v3 mit FHIR in Verbindung gesetzt hast oder das miteinander verglichen hast, ja ich glaube auch, dass FHIR eher Chancen hat, später mal eingesetzt zu werden, einmal vor dem Hintergrund, dass sich viele Leute eben auch mit Rest Services auskennen und in HL7 v3 muss man sich dann mal komplett neu eindenken und HL7 v3 hat eben auch diesen Anspruch der Vollständigkeit, also die wollen ja unbedingt die komplette Welt mit HL7 v3 damit im Rimm abdecken, was irgendwie zum Scheitern verurteilt ist und was dann auch dazu führt, dass es unnötig komplex ist und da hat FHIR den Vorteil, dass es effizient ist, den Lieblingswort, fängt mit P an, pifizient, nein, fängt mit P und A an, es hört endlich auf wie dann vorn haben und fängt mit P an. Ach so, Pareto-Prinzip, ja genau, da wollte ich eigentlich doch auf den Haus auf das Pareto-Prinzip, dass man gar nicht versucht, vollständig zu sein, sondern dass man sagt, wir beschränken uns auf die 80% wichtigsten Dinge und brauchen dafür dann aber nur 20% der Arbeit reinzustecken und das finde ich einen guten Ansatz, ich will jetzt nicht sagen, dass HL7 v3 dem Tote geweint ist, aber ich persönlich würde mich auch eher auf FHIR stürzen. 

HL7v2, HL7v3, ADT, Standards im Gesundheitswesen