Came across some strange behavior that I haven’t noticed before with the BizTalk 2010 HL7 Accelerator when it generated a NACK.
The receive location is using the standard HL7 pipeline which parses and transforms the HL7 messages into XML. If it’s successful the pipeline component generates an Acknowledgement which gets sent back to the partner. An HL7 Ack looks like this:
The problem occurs when there is an issue with the incoming HL7 message and we throw a negative acknowledgement or NACK, BizTalk generates something like this:
ERR||OBX_ObservationResult^9^23|HL7nnnn^Data type error^102|E||||||||^^^^^^^^^^^
Not so good.
The problem is in the ERR segment and there are a couple of issues.
1. The string OBX_ObservationResult is meant to be just OBX. BizTalk is taking the XML node name for that segment rather than the HL7 segment name.
2. The section with the string HL7nnnn^Data type error^102 is referred to in the HL7 spec as Hl7ErrorCode and should be defined as follows:
<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)>
BizTalk is putting the <Name Of Coding System (ID)> in the <Identifier> field, it should have looked like this: 102^Data type error^HL7nnnn.
3. The correct <Name of Coding System> should also be HL70357 and not HL7nnnn
Clearly we have an issue where the BizTalk HL7 Accelerator is not adhering to the standard, strangely enough BizTalk does accept NACK’s formatted like. I’ve raised this with Microsoft via my VTS channels so we’ll see where it leads, I’m hoping they fix it. I am curious why I’ve not noticed this before and why there aren’t folks complaining on the forums. Could this be a new problem in 2010 or does no one care about NACKS?
In the meantime we’ll just have to setup a map or pipeline component that fixes the NACKS when they get sent. The corrected NACK should look like this:
ERR||OBX^9^23|102^Data type error^HL70357|E||||||||^^^^^^^^^^^