Tuesday, December 06, 2005

HL7 Accelarator For BizTalk 2004

Since most of my work is centered around BizTalk and HealthCare it probably comes as no suprise that I spend a significant amount of my time on the HL7 Accelerator for BizTalk 2004. Since the product is pretty big, and there are many interesting / annoying points I'll probably split this up into a few postings...

The basics;
The accelerator provides 3 major parts of interest;

  1. The schemas for HL7 version 2.x messages (with some caveats)

  2. The pipeline component to serialize / deserialize the HL7 messages

  3. MLLP Adapter for BizTalk

(More details on the accelerator can be found here)
On a very basic level when you install the Accelerator you get the ability to generate a series of HL7 message schemas within a BizTalk project. These are based on the HL7 XML schemas provided for v2.x (Nb. If you are looking at version 3 schemas for HL7 be aware that there is no support for that within the current accelerator).
The pipeline component provided has the smarts required to serialize and deserialize the raw HL7 message to the BizTalk XML HL7 message.

So far so good. And if your project was to attach say Eclipsis (an admission system) to Misys (a Laboratory Information Management System) then all would be good and everyone happy (although given most vendors semiconducting to the standard you can expect a decent amount of time on schema rework.) The Adapter will handle the transport for you, parties will also allow you to add in multiple source systems on a single receive port and apply different schemas. The more interesting problems start when you are putting in place a "clinical messaging engine"...

For a start, it is pretty standard in BizTalk to utilize the Canonical Data Model. (See Gregor Hohpe's seminal Enterprise Integration Patterns site for more details on the pattern. As a side note, if you are working in integration read this site repeatedly, buy the book and learn the lyrics!). In a typical implimentation of the model you would have a receive schema, a canonical or internal schema, and a send schema. When a message arrives in the receive port a map is applied to transform the message from the receive format to the canonical format. The canonical message is then utilized internally for all business processes, and then the message is sent to a recipient. The message is translated to the send schema on the send port. However if you are using the accelerator this is not possible...

The reason is that the accelerator receives a flat file message that is pipe delimited. The pipeline component processes the message, using parties to determine which schema to apply to the XML output. Provided no errors are encountered in the deserialization of the message then a map on the pipeline would successfully translate the XML message to a secondary format. Prior to the map though the pipeline very importantly raises an ACK: which is sent back to the sender. The ACK will can be either an AA or AE ACK (alright there are more types, but for the purpose of this rambling these two will suffice). The AA ACK says that the message was received and accepted. The AE says the message was received and rejected. And the errors are included. And we never receive any errors right? Sigh...

If a message arrives with an error AND you have a map on the pipeline as well as the HL7 component, the resulting behaviour is that no ACK is raised and no XML message is left in the MessageBox on BizTalk. Why? Well if a message is received with an error in it (such as an unexpected delimiter in the message, say using an unescaped & in a text field) the pipeline component will fail to translate the message to XML. It will then create an ACK with error details to return to the sending system, and pass the NON-XML HL7 message to the message box. If you have a map next, the input schema will not be the expected XML message, and the map will fail. At this point BizTalk will through an error and terminate the pipeline. The result is the ACK waiting to be sent out will also fail , and the world will come to a sticky end. Now one would expect the sending system to gracefully handle no ACK being returned by retrying a given number of times, and the failing the specific message and moving on right? Obviously not. The normal behaviour is to fail completely and shut down!

So to avoid the unpleasantness that comes from breaking all the clinical systems do not have any maps on the receive port along with the HL7 accelerator pipeline component. Instead;
  1. have an orchestration that consumes the receive message and maps to the canonical format

  2. "re-send" the XML HL7 message to a second receive port and proceed as normal

  3. extend the HL7 pipeline to change its behaviour (btw its sealed so you cannot inherit it, but you can wrapper it

Personally I chose number 1 as the most expedient and realistic mechanism on my current project. Option 2 would have less assets in the solution, and Option 3 would be cleanest. Option 4 of course would be to re-develop the pipeline component or ask Microsoft very nicely to do it!

That's all folks.... Next time I think its probably going to be about reduction of solution assets in an Accelerator project...


Post a Comment

<< Home