1. The MLLP adapter (part of the HL7 Accelerator) is a static adapter. You can use it in combination with the ESB Toolkit, but then you still have to define all physical ports. See an earlier blog from me how to solve this.
2. All (I think) hospital systems are working with ACK’s and NACK’s (some institutions ignore these). There are institutions who wants the ACK (or NACK) send be back by the receiving system to the sending system. The HL7 Accelerator (and thus BizTalk) is taking over this responsibility and sends the ACK to the sending system, before the receiving system receives its message (in my opinion: that is why you use a middleware product like BizTalk). In conjunction with the ESB Toolkit this is hard to implement, because the HL7 Accelerator components (Pipeline) are “living their own life” (you have some control, but not to use with the ESB Toolkit. See also some earlier posts of me).
3. I think the most important reason not to use the ESB Toolkit, is that the most systems used in an hospital are not service oriented aware. These systems are specific to a therapy or division, and holds most of the time all information in their storage, and only share information via HL7 because of the patient information or orders/invoices. This sounds like a “no” on my own question and a Hub and Spoke makes then more sense, but it is still possible to point to some services, like the patient administration (new patient, or updated information) or give an order to multiple systems, etc. So you probably have a combination of those two. Does that matter? I don’t think so, because you still have BizTalk Server as your integration tool and the HL7 Accelerator for connecting all systems.
4. Note: I’m still fan of using a canonical data model within BizTalk Server, also within the Healthcare. All systems will map to and from this data model. It will cost you some extra mappings and a small performance penalty, but at the end you can loosely couple all systems.

Please let me know what your experiences are with the ESB Toolkit in conjunction with the HL7 Accelerator.

You can find the video here.

After the Orchestration the message is routed to a send pipeline and there I found another context property I can use: DocSpecType in ‘http://HL7Schemas.HeaderPropertySchema’:

I created a custom pipeline component for setting the MessageType property and setting this value:

This component is used as early as possible:

By creating the properties I can reuse this component in the future.

The itinerary header could not be found. 

Source: Microsoft.Practices.ESB.PipelineComponents.Dispatcher

Method: Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext, Microsoft.BizTalk.Message.Interop.IBaseMessage)

Error Source: Microsoft.Practices.ESB.Itinerary

Error TargetSite: Microsoft.Practices.ESB.Itinerary.IItinerary Create(Microsoft.BizTalk.Message.Interop.IBaseMessage) 

Error StackTrace:    at Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(IBaseMessage msg)
   at Microsoft.Practices.ESB.PipelineComponents.Dispatcher.Execute(IPipelineContext context, IBaseMessage msg)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I’m using the ESB Toolkit 2.0 (BizTalk Server). I’ve created a custom pipeline which uses the pipeline components:

• ESB Itinerary Selector (Decode)
• BTAHL7 2.X Disassembler (Disassemble)
• ESB Dispatcher (ResolveParty)

The error occurs in the ESB Dispatcher. If I look at the context properties then the ItineraryHeader is available and filled with the Itinerary defined in the ESB Itinerary Selector. Why do I get this error? Another strange thing what I see is that the message (body) is my HL7 flatfile (so it is not disassembled to Xml yet).

The solution for my scenario is to not use the pipeline component ESB Dispatcher (or disable it). Then my scenario works fine. In other scenarios I’m using the default pipeline ItinerarySelectReceivePasshrough (or ItinerarySelectReceivePassThrough) and just Xml files as input and these work fine with the ESB Dispatcher.

Is this a problem of the BTAHL7 2.X Disassembler or ESB Dispatcher or a combination of?

For example: consider the next 3 ADT messages: with A01 (patient admit), A02 (patient transfer) and A03 (patient discharge). This is also the sequence/order the messages must be delivered to other systems. You can’t discharge (A03) a patient if the patient is not admitted (A01).

In an Spoke and Hub or Enterprise Application Integration architecture you can connect the systems with each other and make the process sequential. BizTalk Server works asynchronous, so messages are dropped in the MessageBox and processed by a subscriber, which can be an Orchestration or Send port. Example: if the Send port process the second message (A03) faster as the first message (A01) which is used in an Orchestration, then the backend system will return an error (BizTalk processing is also known as: first-in, fastest out). To make this process synchronously BizTalk Server and the MLLP adapter offers some techniques which can be used:

• Ordered Delivery on the receive port.
• Listen-shape in an Orchestration together with a correlation set based on the Patient ID.
• Make use of guaranteed delivery.
• Wait for ACK/NACK response from the backend, before continuing to the next message.

But how to solve this in an ESB architecture? How to solve this with BizTalk Server ESB Toolkit 2.0?

My answer to this question in the title is: yes it can. How? The ESB Toolkit makes use of BizTalk Server, and is therefore based on rules prescribed by BizTalk. The Itinerary will become just a context property on a message for routing thru the BizTalk system. So you can still make the process synchronously. The Orchestration must use a “request” / “response” mechanism to send the message to the backend system, and wait for an ACK before processing the next message. Some blogs from my this month can help to make this happen, also for a generic solution.

Let me know how you think about this or if you have already experience with HL7, MLLP and the ESB Toolkit.

It would be nice if this will be a feature in the next release (or update) from the HL7 Accelerator.

so it can be selected in the Itinerary:

(note: it is not necessary that this Orchestration is deployed, it is not validating)

After exporting the model, the Itinerary contains the next line:

I still can’t think of a reason why this Orchestration should be added to the ESB.Config, because it can be resolved dynamically like the send ports from an application. Now all the developers must change their ESB.Config, and also the production version must be changed (the full name is not stored in the Itinerary, just a Guid or just a string as you wish). Why not store the full assembly name in the Itinerary?

Do you know the answer? Will this be a feature for the next release?

"The type initializer for ‘Microsoft.Practices.ESB.Configuration.ConfigHelper’ threw an exception"

make sure your ESB.Config is not messed up. For eg.: when you added an Orchestration to the Itinerary Service.