@michaelLipscombe 

Entries in HL7 (2)

Wednesday
Apr182012

BizTalk HL7 Accelerator Nack Issue

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:

MSH|^~\&|MYBTS|APPNAME|PARTNER|A01244|20120413135233||ACK^O21^ACK|95335371500217|P|2.5|||NE
MSA|AA|71200517353359

All good.

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:

MSH|^~\&|MYBTS|APPNAME|PARTNER|FCS|20120413135330||ACK^O21^ACK|100000GSM|P|2.5|||NE
MSA|AE|MSG000001
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:

MSH|^~\&|MYBTS|APPNAME|PARTNER|FCS|20120413135330||ACK^O21^ACK|100000GSM|P|2.5|||NE
MSA|AE|MSG000001
ERR||OBX^9^23|102^Data type error^HL70357|E||||||||^^^^^^^^^^^
Tuesday
Apr102012

Custom HL7 Schema Error - Unsupported version id

HL7 2.7 is not yet supported in BizTalk so I tried creating the OML schema for 2.7 manually. I just copied from 2.5 and changed all the namespaces and root elements. First time I ran a test message, which was a 2.5 instance with the version changed I got this error:

Validation error in header during parsing 
Error # 1
Segment Id: MSH
Sequence Number: 1
Field Number: 12
Error Number: 203
Error Description: Unsupported version id
Encoding System: HL7nnnn

This seemed like it was going to be pretty easy. In the MSH header field 12 is the version which references table104. So I added the versions into the enumeration for table104.

image

But after I deployed this change I kept getting the same error. It drove me crazy, undeployed, redeployed, re-gac’ed, restarted hosts, refilled my coffee, re-everything, still nothing. Finally I looked at the MSH schema and realized it didn’t even reference the table, datatype or segment schemas and all the enumerations have been embedded in it. Ummmm yeah thanks for that Disappointed smile

clip_image002

Maybe I should have been a ballerina instead.