Acelerador HL7 delimitador delimitador delimitador.

Question

Considere el siguiente segmento PV1 en un mensaje HL7V2.

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

Hay 52 campos allí. Nuestro sistema Meditech siempre envía el campo 52 (PV1_52_OTERHEALTHCAREPROVIDER) en esta interfaz, que representó aquí por 55555^Doctor^Secondary^H^^Dr^^DOCT2. Lo tengo configurado para que permita que los delimitadores de arrastre están activados. Como puede ver, hay un delimitador final en este segmento, Sin embargo, esto es después del campo final en el segmento, lo que sucede que contiene los datos que se muestran arriba.

Este será siempre el caso, Meditech siempre está agregando un delimitador final en esta interfaz.

Ninguno de los otros segmentos tiene datos en el campo final, por lo que no nos hemos encontrado con este problema con ellos, a pesar de que tienen delimitadores que se arrastran. En el segmento PV1 estamos recibiendo un error:

Error happened in body during parsing 
Error # 1
Segment Id: PV1
Sequence Number: 1
Error Number: 100
Error Description: Segment sequence error (Unexpected end of message body found)
Encoding System: HL79999

Resulta que esto se debe al delimitador final, ya que eliminando manualmente el delimitador y la reenvío, el error no se produce. Además, si modifico el esquema para agregar un campo de DUMMY (PV1_53_EXTRAFIGN), se permite el mensaje.

Mi pregunta es esta: ¿Cuál es el comportamiento esperado de Permitir que los delimitadores de arrastre en este caso? ¿Se supone que debe permitir un delimitador final en todos los casos , o solo se aplica a los segmentos en los que el campo final está vacío de datos (es decir,: campos adicionales al final del segmento)?

Answer 1

En la tubería de recepción No puede tener delimitador después del último campo en segmento.Parece que este es un error en el acelerador HL7.Esta propiedad parece tener algunos efectos en el lado de envío solo que también solo si los delimitadores están dentro de la cantidad de campos definidos.

Sugeriría tratar con esto en recibir componentes de tuberías y levantarlo con Microsoft Support

Answer 2

Aunque incluso La versión estándar de mensajes de HL7 2.6 no hizo Extienda el segmento PV1 con otros campos y, por lo tanto, su código original fue correcto desde el punto de soporte solo 52 campos de segmento

1. es perfectamente válido para ampliar el protocolo de mensajería HL7 con campos personalizados y segmentos personalizados, siempre que esta extensión esté acordada por todas las partes involucradas y documentado en la Declaración de conformidad HL7 (puedes encontrar algunos enlaces que explican aquí y AQUÍ )

2. Su código de procesamiento de análisis y mensajes debe ser compatible con las versiones anteriores y futuras del protocolo. Número de segmentos, sus nombres y pedidos y número de campos y número de componentes en los campos se pueden determinar y manejar dinámicamente. La sintaxis del mensaje fue diseñada para soportarla. Cosas de codificación dura como "Habrá 52 campos en el segmento PV1, independientemente de lo que el campo de la versión HL7 MSH-12 contenga" no es un enfoque muy bueno, ya que no se escalará

.. ¿Cuál es el comportamiento esperado de permitir delimitadores finales en este caso? ..

El comportamiento esperado es que su solicitud no se bloqueará, no bloqueará el procesamiento de datos, si los datos viajan a través de su código en otro sistema, no debe tomar / eliminar los campos que no entiende (está más o menos escrito en La especificación HL7 en algún lugar ..)