HL7 Accélérateur de Fuite Délimiteur comportement attendu

Question

Considérez les points suivants PV1 segment HL7v2 message.

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

Il y a 52 champs.Notre système Meditech envoie toujours sur le terrain 52 (PV1_52_OtherHealthcareProvider) sur cette interface, qui sont représentés ici par 55555^Doctor^Secondary^H^^Dr^^DOCT2.Je l'ai mis en place de sorte que Permettre À Des Séparateurs À Droite est SUR.Comme vous pouvez le voir il y a une fuite délimiteur dans ce segment, cependant c'est après le dernier champ dans le segment, qui contient les données ci-dessus.

Ce sera toujours le cas, Meditech est toujours en ajoutant une fuite délimiteur sur cette interface.

Aucun des autres segments de données dans le champ final, donc nous n'avons pas rencontré ce problème avec eux, bien qu'ils aient des séparateurs à droite.Sur PV1 segment, nous recevons un message d'erreur:

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

Il s'avère que c'est en raison de la fuite de délimiteur, en raison de supprimer manuellement le délimiteur et le soumettre à nouveau, l'erreur ne se produit pas.Aussi, si je modifie le schéma d'ajouter un mannequin (PV1_53_ExtraField) le terrain, le message est autorisé.

Ma question est la suivante:Quel est le comportement attendu de permettre à des séparateurs à droite dans ce cas?Est-il censé permettre une fuite délimiteur dans tous cas, ou il ne fait que s'appliquer à des segments où le dernier champ est vide de données (c'est à dire:champs supplémentaires à la fin du segment)?

Answer 1

Sur le pipeline de réception vous ne pouvez pas avoir délimiteur après le dernier champ dans le segment.Il semble que c'est un bug dans HL7 accélérateur.cette propriété semble avoir un certain effet sur envoyer, uniquement du côté que trop que si les délimiteurs sont définis certain nombre de domaines.

Je suggère de gérer cela à recevoir composant de pipeline et de l'aborder avec le support de Microsoft

Answer 2

Bien que même HL7 Standard de Messagerie Version 2.6 ne pas prolonger le PV1 segment avec d'autres domaines et c'est ainsi que votre code d'origine est correcte du point de soutenir que 52 segment des champs

1. Il est parfaitement valide pour prolonger le protocole de messagerie HL7, avec des champs personnalisés et des segments personnalisés, à condition que cette extension est convenu par toutes les parties concernées et documentés dans le HL7 déclaration de conformité (vous pouvez trouver quelques expliquant les liens ici et ici)

2. Votre analyse et de traitement d'un message de code doit être compatible avec les anciens et les futurs versions du protocole.Nombre de segments, leurs noms et l'ordre et le nombre de champs et le nombre de composants dans les champs peuvent être déterminées et traitées de manière dynamique.La syntaxe de message a été conçue pour soutenir.Coder en dur des choses comme "il y aura 52 champs dans le PV1 segment, peu importe ce que les HL7 version champ MSH-12 contient" n'est pas très bonne approche, car il ne sera pas à l'échelle

..Quel est le comportement attendu de permettre à des séparateurs à droite dans ce cas?..

Le comportement attendu est que votre application se bloque pas, ne va pas bloquer le traitement des données, si les données se déplace à travers votre code dans un autre système, vous ne devez pas supprimer/supprimer des champs que vous ne comprenez pas, c'est plus ou moins écrit dans le HL7 spécification quelque part..)