Next week I’m going to give a BizTalk Server developers training in combination with the HL7 Accelerator. The audience consists of Cloverleaf developers and administrators. The training will be customized for the hospital and I’m really looking forward to these days!
Tag Archives: HL7
BizTalk Server ESB Toolkit and HL7 Accelerator
Last year (September-October 2010) I blogged a lot about the ESB Toolkit in conjunction with the HL7 Accelerator. I also asked myself the question: Can the Healthcare take benefits of an ESB?. I then gave the answer: “yes it can”. And I’m still supporting this, but not in conjunction with the ESB Toolkit. I have several reasons for this:
- 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.
- 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).
- 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.
- 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.
Why using BizTalk Server in the Healthcare?
I’m not going to give you the standard reasons why you should use BizTalk Server, but I will point to the reasons from the clients I worked with. I put the list in order, from which I think is the most important reason till the least important reason. Note: because Cloverleaf is one of the widest spread integration products in the Healthcare, I can’t neglect to compare with this product.
- In comparison to other products, Microsoft BizTalk Server has a positive Return Of Investment and one of the lowest (if not the lowest) Total Cost of Ownership (wow, that sounds like sales, but it is true
) - With BizTalk Server you don’t have to deal with Vendor lock-in. BizTalk Server is not open source, but there is a large community and a lot of vendors who can deliver BizTalk Server expertise. (HL7 knowledge can still be a problem)
- BizTalk Server is not a black-box. Because of the documentation from Microsoft, bloggers, and other communities; BizTalk Server is very open.
- Keep old systems up and running. BizTalk Server is very flexible. BizTalk Server 2009 and BizTalk Server 2010 (and older versions) are delivered with the HL7 Accelerator. See my presentation or article (Dutch) for the benefits.
- One disadvantage: HL7 v2.6 and v3.0 are not supported (yet), but
- 2.5 is at the moment the de facto standard, so that shouldn’t be a problem and
- HL7 v3.0 is XML based and BizTalk Server is all about XML, so that also shouldn’t be a problem (just download the schemas from the HL7 organization site)
- One disadvantage: HL7 v2.6 and v3.0 are not supported (yet), but
- BizTalk Server has more possibilities to work with the messages in a flexible way (like translation, use custom code, enrich data via databases).
- BizTalk Server also support other transports then only MLLP.
- When you want to connect to a governance site which support SOAP, then with BizTalk Server a connection is easily established (eg. in the Netherlands: SBV-Z, Nictiz, etc).
- “Use Microsoft products, unless …” (heard twice, so there must be a truth in there
) There are healthcare institutions who shift up to Microsoft platform and therefore wants to use BizTalk Server (note: this is also the case for other platforms like SAP or Oracle).
This is the list I’m aware of (in respect to the Healthcare). Do you think I’m missing something? Or do you have another opinion? Please let me know.
Presentation about Healthcare and BizTalk Accelerator for HL7 (EN)
I placed an English version of this presentation on this site. Don’t hesitate to contact me if you have questions or remarks. Click here.
Cheers Gerben
Presentation about Healthcare and BizTalk Accelerator for HL7
Last week I gave a presentation at the BTUG (NL), and I really enjoyed it. The presentation can be found here (note: it is Dutch). If you need more information or in English then please contact me.
Article in Software Release Magazine (NL)
Mijn artikel over BizTalk Accelerators en met name over de HL7 Accelerator in de zorg is verschenen in de Software Release Magazine (een IT blad in Nederland). Het artikel kunt u hier vinden. Wilt u meer weten, dan kunt u natuurlijk altijd contact met me opnemen.
(ENGLISH)
My article about BizTalk Accelerators and especially about HL7 Accelerator in the Healthcare appeared in the Software Release Magazine (an IT magazine in the Netherlands). You can find the article over here. Note: it is a Dutch article. Let me know if you are interested in BizTalk Server Accelerators and HL7.
Cheers Gerben
“Body schema is missing” (2)
In my last post I blogged about this message. After fixing the input files, I still received this message. After some digging I noticed that the MessageType was empty (from ‘http://schemas.microsoft.com/BizTalk/2003/system-properties’). This field is used by the pipeline component BTAHL7 2.X Assembler. This field is not promoted because I’m using a generic Orchestration for routing HL7 messages via the ESB Itinerary to the MLLP Adapter (see earlier post about using a static port in an ESB Itinerary). In this Orchestration I’m receiving and sending System.Xml.XmlDocument for the message header, body and z-segment (MultiPart message). It is also not possible to write in this MessageType property, because it is read-only (in an Orchestration).
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.
"Body schema is missing"
When you are working with HL7 schemas and you receive this message, then you should have a look at your incoming message. Probably it doesn’t match your Xsd. In my case it had to do with elements which don’t match the enumeration defined in the tablevalues_25.xsd (my input elements were empty). The BTAHL7 2.X Assembler is using the schemas for creating the Xml file, but also for validating. It really has nothing to do with your schema if it is deployed or not (in my case).
There was a failure executing the send pipeline: "BTAHL72XPipelines.BTAHL72XSendPipeline, BTAHL72XPipelines, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "BTAHL7 2.X Assembler" Send Port: "SendPortMLLP" URI: "ip-address:port" Reason: Body schema is missing
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Using an HL7 multi-part message in an Orchestration
I receive a flatfile HL7 message with the next records: MSH, EVN, PID and PV1. This message goes thru the pipeline component BTAHL7 2.X Disassembler. After the disassembler the BizTalk message contains 3 message parts: MSHSegment, BodySegments and ZSegments (which is empty in my case).
To use this message in an Orchestration you have to define a message as a multi-part message with these three parts. If you don’t do any processing in your Orchestration then you can use System.Xml.XmlDocument as message part type (it is only a reference).
You have to define these parts in the right order, so MSHSegment, BodySegments (with “Message Body Part” set to True) and ZSegments. If you don’t define these in the right order, you will receive an xlang/s error in the EventLog:
xlang/s engine event log entry: Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘MyCompany.MyOrchestration(da177201-2c29-4fbd-56f9-ad118705a27b)’.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 233a2806-2f36-46f2-9204-f8bfb2fc5403
Shape name: Receive_1
ShapeId: 160d728f-0375-4445-b21c-6e56d665eccc
Exception thrown from: segment 1, progress 3
Inner exception: Multi-part message ‘InboundMsg’ has body part ‘BodySegments’, expected body part ‘MSHSegment’.
Exception type: WrongBodyPartException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Void ReadMessageState(Microsoft.XLANGs.Core.Envelope, Microsoft.XLANGs.BaseTypes.XLANGMessage)
The following is a stack trace that identifies the location where the exception occuredat Microsoft.BizTalk.XLANGs.BTXEngine.BTXXlangStore.ReadMessageState(Envelope env, XLANGMessage msg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.ReceiveMessage(Int32 iOperation, Envelope env, XLANGMessage msg, Correlation[] initCorrelations, Context cxt, Segment s)
at ‘MyCompany.MyOrchestration.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
You can find some more information here.
“The itinerary header could not be found”
I received the next message in the EventLog:
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?
