HL7 Accelerator Trailing Delimiter expected behaviour

Question

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)?

Answer 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

Answer 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..)