Welche Probleme treten bei der Arbeit mit HL7-Nachrichten auf?

Ich teste ein Produkt für Unternehmen des Gesundheitswesens und wir arbeiten mit HL7-Nachrichten. Ich sah Leute, die über eine andere Frage zu den Problemen mit HL7 stöhnten, aber keine Einzelheiten erwähnten. Kann mir jemand eine Vorstellung davon geben, nach welchen Themen oder Problemklassen wir speziell suchen sollten?

Wir verwenden einige häufig verwendete Bibliotheken für das Parsen. Wenn Einzelheiten zu diesen oder unseren Aktivitäten hilfreich wären, lassen Sie es mich bitte in den Kommentaren wissen und ich werde die Frage ergänzen, wenn ich kann.

testing parsing hl7

— Ethel Evans
quelle

Antworten:

Ich nehme an, Sie haben es mit HL7 v2.x zu tun

HL7 ist freiwillig extrem flexibel. Das hat große Vorteile, bringt aber auch Herausforderungen mit sich. Eine Grundregel, die zu beachten ist, ist, dass jede einzelne Implementierung anders sein wird. Wenn Sie dasselbe Produkt in zwei verschiedenen Umgebungen (z. B. zwei Krankenhäusern) bereitstellen, ist die Datenaustauschregel wahrscheinlich unterschiedlich. Ihr Produkt muss bereit sein, diese versteckten Anforderungen zu erfüllen, wenn Sie die Anzahl der HL7-Schnittstellen skalieren möchten, mit denen es interagieren wird.

In den meisten Gesundheitssystemen, die sich mit HL7 befassen, stehen wir vor dieser unvollständigen Liste gemeinsamer Herausforderungen:

Jedes System könnte die Bedeutung jedes Datenstücks interpretieren. Auch der Kontext und die Workflows können die Semantik beeinflussen. Ich habe einige Systeme gesehen, die die Kontonummer (PID.18) oder die Besuchsnummer (PV1.19) verwendeten, um den Patienten zu identifizieren, der einigen klinischen Arbeitsabläufen entspricht. Diese Art von semantischer Lücke wird wahrscheinlich einige Auswirkungen darauf haben, wie das System mit diesen Daten umgeht.
Erforderlich oder optional: Da ein Datenelement ausgetauscht werden kann, um mehrere Ziele in verschiedenen Kontexten zu erreichen, werden die meisten Segmente und Felder in der offiziellen Dokumentation (und einigen Parsern) als optional dokumentiert. Um jedoch bestimmte Arbeitsabläufe zu erfüllen, würden Gesundheitsprodukte wahrscheinlich Datenbeschränkungsregeln hinzufügen und einige andere lockern. In den meisten Fällen muss eine Einzelfallanalyse durchgeführt werden, um sie zu identifizieren.
Tabellen: HL7 enthält eine Liste der vorgeschlagenen Werte für einige Felder. Zum Beispiel ist die vorgeschlagene Werteliste für das Geschlecht 6 lang ... Offensichtlich implementieren die meisten Systeme nicht alle 6, aber was ist Ihre Mapping-Strategie, wenn Sie eine erhalten, die Sie nicht im Voraus unterstützen?
Segmente und Felder können angepasst werden: Feldlänge, Datentypen und andere Definitionsattribute können angepasst werden. Sie müssen es einer Datenstruktur zuordnen, die Sie kennen, ohne wichtige Informationen zu verlieren.

jlmorin

www.caristix.com

— jlmorin
quelle

Einige Probleme, auf die ich gestoßen bin:

Einige Organisationen verwenden möglicherweise unterschiedliche Versionen von HL7, sodass Kompatibilitätsprobleme auftreten ("Cross-Walking"). Dies wird Ihnen sicherlich begegnen, wenn Sie an organisationsübergreifenden Datenübertragungen beteiligt sind.
Es gibt keinen semantischen Standard (für v2.x hat v3 möglicherweise begonnen, dies zu beheben). Selbst wenn Sie wissen, welche Daten sich in einem bestimmten Feld befinden sollten, kennen Sie möglicherweise nicht die genaue Bedeutung oder Darstellung dieser Bytes.
HL7 ist ein nicht standardmäßiger Standard. Es unterstützt herstellerspezifische, Z-segmentsweit verbreitete und vollständig proprietäre Produkte.
HL7 v2.x (viele Werte von x werden in freier Wildbahn noch verwendet) ist ein nicht XML-proprietäres Format, daher benötigen Sie einen HL7-Parser, um damit arbeiten zu können. (Dies wissen Sie, da Sie bereits eine HL7-Parsing-Bibliothek haben, die diese nur für andere enthält.)

— G__
quelle

Das Schlimmste davon ist der Mangel an Semantik. Wenn sogar die Leute, die den Standard schreiben, sagen "Nun, Sie könnten X oder Y senden, aber Z ist auch gültig", wissen Sie, dass Sie ein Problem haben. Was es spart, ist, dass niemand außer den Parser-Leuten mit der gesamten Palette von HL7-Optionen umgehen muss - jeder befasst sich mit der kleinen Teilmenge, die tatsächlich von seinen Kunden empfangen wird. Das bedeutet, dass das Schreiben eines neuen Akzeptors eher ein Entdeckungsprozess ist (den ich gerade durchlaufe) als eine Übung zum "Implementieren des Standards". Oh, und raten Sie mal, welche Option Sie senden müssen, um den gewünschten Effekt zu erzielen.

@ +1 für die Antwort, und mit könnte ich +1 für die Aufnahme von Informationen für andere Personen als das OP (ich) geben. @moz - ein guter Punkt, um nur eine kleine Teilmenge zu benötigen. Das ist genau unsere Situation. Sie bestätigen auch meinen Verdacht, dass der Vergleich mit Kundendaten der Schlüssel sein wird.

— Ethel Evans

@ethel und @moz, genau diese Art des Denkens macht den Umgang mit HL7 so schwierig. Nehmen Sie sich bitte die Zeit, um Ihre Programme so flexibel wie möglich zu gestalten. HL7 ist ein Ort, an dem YAGNI in keiner Weise anwendbar ist.

— Peter Turner

Okay, das macht Sinn. Ich glaube nicht, dass unsere Anwendung YAGNI-Probleme verursachen wird, da wir im Voraus planen, die Arten von HL7-Nachrichten zu erweitern, die wir zur Bereitstellung von Wert verwenden können. Wir wissen, dass wir nicht wissen, was wir in Zukunft brauchen werden.

— Ethel Evans

Deshalb bin ich ein Fan davon, die Open-Source-Bibliotheken (HAPI / NHAPI) zumindest für die Empfangsseite zu verwenden. Es ist viel besser, ein hohes Niveau zu haben: "Wir haben eine gültige HL7-Nachricht, haben aber keinen Code geschrieben, um sie zu verarbeiten" als "Unser Parser ist fehlgeschlagen, weil wir diese Nachricht nicht erwartet haben". Leider fängt jeder klein an "wir senden nur X und empfangen Y", so dass es viel einfacher ist, etwas zusammen zu hacken, als es jedes Mal zu erweitern, wenn eine neue Anforderung eintrifft, bis es schließlich unter dem Gewicht der angesammelten Kruft zusammenbricht.

Das erste Problem besteht darin, sicherzustellen, dass jeder weiß, was HL7 ist.

Dies ist eine Möglichkeit, Codierer für [medizinische | Abrechnungs- | Versicherungen] zu ersetzen und einer [Apotheke | Bank | Versicherungsgesellschaft] Geld zu sparen.

Das ist die Falte zusätzlich zu all den normalen Problemen in der Softwareentwicklung.

Scope Creep
Unvollständige Angaben
Ungültige proprietäre Spezifikationen, die "nicht geändert werden können"

Wenden Sie sich also an Ihre [Apotheke | Bank | Versicherungsgesellschaft], die so viel Geld wie möglich von einer HL7-Schnittstelle an die Einrichtung, die Ihre Software verwendet, herausholen möchte. Ihr Vertrag ist mit der Einrichtung, ihr Vertrag ist mit der Apotheke, die [Apotheke | Bank | Versicherungsgesellschaft] hat keine Ahnung, wie Ihre Software funktioniert, die Einrichtung hat keine Ahnung, was HL7 ist, und Sie sind in der Apotheke abgehakt, weil sie Sagen Sie Ihnen ständig, dass Ihre Software fehlerhaft ist.

Ich glaube, das Problem mit HL7 ist, dass es meistens billig gemacht wird. HL7 3.0 wird möglicherweise niemals eintreten, da es niemals monetarisiert wird.

Wenn Sie für HL7 bezahlen möchten, denken Sie daran, dass Sie auch für HL [1-6] bezahlen. Eine SOAP-Schnittstelle ist nicht HL7. Ein HL7-Nachrichtenparser ist weder HL7 noch ein Nachrichtengenerator.

— Peter Turner
quelle

HL7 ist weit mehr als nur für Apotheken. Am häufigsten wird HL7 verwendet, um unterschiedliche Systeme wie eine EMR mit einem Abrechnungssystem zu verbinden.

— Bill

Unser Produkt richtet sich nicht einmal indirekt an Apotheken, und die Antwort ist sehr voreingenommen, ohne dass die Antwort unterstützt wird.

— Ethel Evans

@Ethel Ich werde einige reguläre Ausdrücke hinzufügen, aber Sie sollten in Ihrer Frage genauer sein. Mit unserer 100% igen HL7-Implementierung aus eigenem Anbau machen wir mehr als nur Apotheken, aber die treibende Kraft hinter der Entwicklung ist immer "Big Pharma". Wenn andere von einer weit verbreiteten Spezifikation profitieren können, dann sei es so.

— Peter Turner

@Peter: Ich werde versuchen genauer zu sagen, warum ich denke, dass dies nicht hilfreich ist. Erstens scheint Ihr hervorgehobenes Zitat stark voreingenommen und nicht unterstützt zu sein. Zweitens sind die Elemente auf Ihrer nummerierten Liste entweder vage oder fügen sich nicht über das hinaus, was andere Antworten klarer gesagt haben. Drittens ist Ihr Beispielszenario sehr spezifisch und ähnelt nicht dem Szenario, mit dem ich (und anscheinend auch andere) es zu tun haben, was es nicht aussagekräftig macht. Viertens scheint Ihre Aussage, dass HL7 billig gemacht wird, voreingenommen und nicht unterstützt zu sein. Fünftens mache ich nicht "HL7", sondern arbeite mit HL7-Nachrichten, sodass der Punkt des letzten Absatzes verloren geht.

— Ethel Evans

@Ethel, wie um alles in der Welt soll ich meine Behauptungen unterstützen? Ich profitiere überhaupt nicht davon, wenn ich mich mit HL7 beschäftige. Was ich aus meiner Erfahrung in den letzten Jahren mit mehreren Anbietern weiß, ist, dass wenn jemand sagt, dass er mit meinem arbeiten möchte Software und um ihnen eine "Testnachricht" zu senden, damit sie einen Überblick darüber bekommen, wie sie aussehen soll, erstellen sie eine Art ORM um die Nachricht und es funktioniert einfach dafür. Das ist nicht gut. Wenn meine Antwort anders erscheint als die anderer, dann sicherlich nicht, weil ich dir nicht die Wahrheit sage. Bei HL7 geht es hauptsächlich ums Geld.

— Peter Turner