HL7-Beschleuniger nachlaufender Trennzeichen erwartetes Verhalten

Question

Betrachten Sie das folgende PV1-Segment in einer HL7V2-Nachricht.

PV1|1|E|MYLOC||||55555^Doctor^Doc^D^^Dr^^DOCT|||||||HO||||ER||BC|||||||||||||||||||VALUE||REG|||201406270627||||||||55555^Doctor^Secondary^H^^Dr^^DOCT2|

gibt es dort 52 Felder. Unser Meditech-System sendet immer das Feld 52 (PV1_52_OTHEESSTHCAREPROVIDER) an dieser Schnittstelle, die hier von 55555^Doctor^Secondary^H^^Dr^^DOCT2 dargestellt wird. Ich habe es eingerichtet, so dass nachlaufende Delimiters eingeschaltet ist eingeschaltet ist. Wie Sie sehen, gibt es in diesem Segment ein nachlaufendes Trennzeichen, jedoch dies nach dem endgültigen Feld in dem Segment, das die oben angegebenen Daten enthält.

Dies ist immer der Fall, Meditech hängt immer ein nachlaufendes Trennzeichen an dieser Schnittstelle an.

Keines der anderen Segmente haben Daten im Endfeld, so dass wir nicht mit ihnen in dieses Problem gelaufen sind, obwohl sie nachfolgenden Trennzeichen haben. Im Segment PV1 erhalten wir einen Fehler:

generasacodicetagpre.

Es stellt sich heraus, dass dies auf das nachlaufende Trennzeichen zurückzuführen ist, da das Trennzeichen manuell das Trennzeichen und die Wiedereinleiten des Trennzeichens erfolgt, erfolgt der Fehler nicht. Wenn ich das Schema nicht ändern, um ein Feld dummy (pv1_53_extraField) hinzuzufügen, ist die Nachricht zulässig.

Meine Frage ist dies: Was ist das erwartete Verhalten von zulässige nachlaufende Delimiters in diesem Fall? Soll ein nachlaufendes Trennzeichen in alle Fällen zulassen, oder gilt es nur für Segmente, in denen das Endfeld Daten ungültig ist (dh zusätzliche Felder am Ende des Segments)? .

Answer 1

Bei der Empfangspipeline können Sie nach dem letzten Feld im Segment kein Trennzeichen haben.Es sieht so aus, als ob dies ein Fehler in HL7-Beschleuniger ist.Diese Eigenschaft scheint sich nur auf die Send-Seite nur dann auszuwirken, dass auch nur, wenn Trennschlüsse innerhalb definierter Anzahl von Feldern sind.

Ich würde vorschlagen, mit diesem in der Empfangspipeline-Komponente umzugehen und mit Microsoft-Support aufzuheben

Answer 2

Obwohl sogar HL7 Messaging Standardversion 2.6 nicht Erweitern Sie das Segment PV1 mit anderen Feldern und somit war Ihr ursprünglicher Code aus dem Punkt der Unterstützung nur 52 Segmentfelder

1. Es ist perfekt, das HL7-Messaging-Protokoll mit benutzerdefinierten Feldern und benutzerdefinierten Segmenten zu erweitern, vorausgesetzt, dass diese Erweiterung von allen beteiligten Parteien vereinbart und in der HL7-Konformitätserklärung dokumentiert wird (Sie können einige erläuterne Links finden hier und hier )

2. Ihr Analyse- und Nachrichtenverarbeitungscode sollte mit alten und zukünftigen Versionen des Protokolls kompatibel sein. Anzahl der Segmente, ihre Namen und Ordnung und Anzahl der Felder und Anzahl der Komponenten in Feldern können dynamisch ermittelt und behandelt werden. Die Nachrichtensyntax wurde entwickelt, um sie zu unterstützen. Hardcoding-Dinge wie "gibt es 52 Felder im Segment PV1, unabhängig von dem, was das HL7-Versionsfeld MSH-12 enthält, das" nicht sehr gut ist, da er nicht skaliert wird

.. Was ist das erwartete Verhalten von nachlaufenden Trennzeichen in diesem Fall ?.

erwartetes Verhalten ist, dass Ihre Anwendung nicht stürzt, die Datenverarbeitung nicht blockiert, wenn die Daten über Ihren Code in ein anderes System reisen, das Sie nicht nicht verstehen / entfernen sollen, die Sie nicht verstehen (es ist mehr oder weniger geschrieben Die HL7-Spezifikation irgendwo ..)