1

Consider the following PV1 segment in an HL7v2 message.

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

There are 52 fields there. Our Meditech system always sends out field 52 (PV1_52_OtherHealthcareProvider) on this interface, which it represented here by 55555^Doctor^Secondary^H^^Dr^^DOCT2. I have it set up so that Allow Trailing Delimiters is ON. As you can see there is a trailing delimiter in this segment, however this is after the final field in the segment, which happens to contain the data shown above.

This will always be the case, Meditech is always appending a trailing delimiter on this interface.

None of the other segments have data in the final field, so we haven't run into this issue with them, despite them having trailing delimiters. On PV1 segment we are receiving an 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

It turns out this is due to the trailing delimiter, because manually removing the delimiter and resubmitting, the error does not occur. Also if I modify the schema to add a dummy (PV1_53_ExtraField) field, the message is allowed.

My question is this: What is the expected behaviour of allow trailing delimiters in this case? Is it supposed to allow a trailing delimiter in all cases, or does it only apply to segments where the final field is void of data (ie: extra fields at the end of the segment)?

Bensonius
  • 1,501
  • 1
  • 15
  • 39

2 Answers2

2

Although even HL7 Messaging Standard Version 2.6 did not extend the PV1 segment with other fields and thus your original code was correct from the point of supporting only 52 segment fields

1. It is perfectly valid to extend the HL7 messaging protocol with custom fields and custom segments, providing that this extension is agreed on by all involved parties and documented in the HL7 conformance statement (you can find some explaining links here and here)

2. Your parsing and message processing code should be compatible with both old and some future versions of the protocol. Number of segments, their names and order and number of fields and number of components in fields can be determined and handled dynamically. The message syntax was designed to support it. Hardcoding things like "there will be 52 fields in the PV1 segment regardless of what the HL7 version field MSH-12 contains" is not very good approach as it will not scale

..What is the expected behaviour of allow trailing delimiters in this case?..

Expected behavior is that your application will not crash, will not block the data processing, if the data travels through your code into another system you should not drop/remove fields you don't understand (it is more or less written in the HL7 specification somewhere..)

Community
  • 1
  • 1
xmojmr
  • 8,073
  • 5
  • 31
  • 54
  • It sounds like this is answering the expected behaviour of an application that uses HL7 in general. However, I'm talking about BizTalk specifically. I'm just wondering if Microsoft considers this to be "as designed" or if it truly is a bug which disallows that last trailing delimiter. – Bensonius Aug 01 '14 at 15:40
  • @LaMMMy I'm sorry if you find my answer useless. I can delete it in that case. HL7 in general allows any number of trailing delimiters, their meaning is just a NOP instruction. Your specific implementation choice (the Microsoft's BizTalk engine) is no exception and no excuse. It is your implementation choice as the service provider and your responsibility to configure it to behave correctly. If you are looking for an answer to question "Can I blame Microsoft?" then my answer is "I don't know" and did not read it from your original question – xmojmr Aug 01 '14 at 17:31
  • Haha. Your answer is useful in determining that I do believe that biztalk is definitely not following the standard here. Don't be so hard on yourself. – Bensonius Aug 02 '14 at 04:20
  • @xmojmr's answer helped resolve my parsing issue. A Meditech app is emitting ADT^A08 messages with a tailpipe '|' after field AL1-6 (IdentificationDate), the last field defined for segment AL1 in HL7 2.4. All the other segments of the message have "legitimate" tailpipes (successive fields are defined for the segment, but no values present) which parsed fine. I thought my AL1 parsing error was a bug (all the messages "looked the same" at the end so what's with AL1?), but on AL1 this indicated another defined field, which there isn't. I'll add a pretend AL1-7 field to the end of my AL1 type. – CobolCommando Apr 05 '21 at 18:34
1

On receive pipeline you can not have delimiter after the last field in segment. It looks like this is a bug in HL7 accelerator. this property seems to have some affect on send side only that too only if delimiters are within defined number of fields.

I would suggest to deal with this in receive pipeline component and raise it with Microsoft support

Vikas Bhardwaj
  • 1,455
  • 8
  • 10