One of the most interesting presentations for me at MS-HUG was the update on the HL7 Accelerator for BizTalk Server 2006 R2 given by Stuart Landrum. There are a number of areas of interest here, in particular work that has been done to enable processing of large schema (such as HL7 v3.0 schema), ordered delivery and schema generation.
HL7 v3.0 schema’s are very big. In the past, you simply could not effectively work with the BizTalk mapper to map these schema. In fact, in BizTalk 2004 it was pretty much impossible to natively access these messages, primarily due to issues with the .Net Framework v 1.1. Version 2.0 of the framework helped a lot but the schema still caused huge issues. Solutions ranged from object model representations of the schema, something I personally think is a mistake due to the large nature of elements within the schema that often carry no meaningful business data. I have written before on the issues with large XML schema, HL7 v3.0 in particular. With the R2 release, BizTalk provides two strategies/alterations to help support these schema; the GenerateDefaultFixedNodes flag, and the change to expansion of schema nodes. I am told these two changes effectively reduce the performance requirements of the system to such a point where the schema can be dealt with natively.
The GenerateDefaultFixedNodes flag changes the way the compiler deals with the linked nodes. In the past the compiler would recursively walk through all the links, consuming more and more resources. In many cases, depending on your system, you would simply run out of resources and the system would crash. I personally spent a very frustrating couple of weeks trying to put together a proof of concept in the past where my machine would spin out of control and eventually crash. Now the GenerateDefaultFixedNodes flag will prevent this behaviour by only accounting for linked nodes.
The expansion of the schema is another big step forward. In the previous versions, if you clicked on the expand all nodes in the mapper, you were asking for trouble. The mapper would try and expand all the nodes and would eventually crash out. The change in R2 alters the behaviour to only expand the first instance of the complex type, rather than opening all.
I’ll be trying these out as soon as I get a chance and will post on the results asap.
Ordered Delivery is a big deal in healthcare and was difficult to achieve with the previous versions of BizTalk. The underlying problem seen in BizTalk is the multiple threading nature and the efficiency of processing BizTalk displays. In older style integration engines this simply was not a problem since many were single threaded, and did not execute discrete steps of business logic in a decoupled manner. Subsequent attempts at global solutions often did not take into account the use of orchestrations, or the use of multiple message types within a message class (for example, ADT is a message class with multiple types of messages as represented by triggers – A01, A02 and so on. The HL7 Accelerator generates individual schemas for each of these, resulting in multiple pathways through the system).
The ordered deliver solution within R2 uses a ticketing system with a gate keeper orchestration to re-sequence the messages. The solution uses a custom pipeline component to insert a sequence number into the context properties of the message in the pipeline. Normal processing of the message can then occur during the solution. Prior to transmission to the consumer, the Gate Keeper orchestration essentially ensure the message is the first in the sequence.
The cool part about this approach is it uses correlation sets to achieve the sequencing. This is cool since it will enable developers to use additional data elements for correlation. So for example, you could ensure that all messages that relate to an individual patient are in sequence with each other, but not with other patients. This is huge since the business requirement is usually that individual patient messages are in sequence, for example an A08 cannot come before an A01, or even more critical an A08 does not come before a proceeding A08. It is rarely a requirement that messages are in sequence between patients. It’s not important for the downstream system to receive Patient A’s messages before Patient B. This has a large impact on performance. Fundamentally any attempt to sequence messages will reduce the performance of the system. So the general rule should always be, if you don’t need it, don’t use it.
Now there are a few caveats; the solution assumes that there is one provider and one consumer. This is often not the case. But i still think this is a good start, and provides a good basis for further solution development. For example, I can see a possibility using correlation sets to include consumer information in the solution as well. Also the solution requires that transport level does not alter the sequence. Or to put it another way, BizTalk can ensure the sequence it received the messages in, but not re-order out of sequence messages with this solution.
I do have one concern with the mechanism. In the past we have had significant issues with use of pipeline components in conjunction with the HL7 Accelerator. The issue lies with the way ACK messages are generated. If a message is received the accelerator pipeline component will attempt to convert the message to the appropriate XML representation. If for some reason this fails, a NACK is generated and help in memory until the pipeline completes. This NACK is then sent to the messagebox and then transmitted back to the message sender. If a map, for example, is included in the pipeline, and the message has failed transformation to the XML version, the map will error out and cause the pipeline to collapse, destroying the NACK in the process. The upstream system never receives the NACK and basically sulks, doing nothing, and sending no more messages until an operator resets the interface. I wonder if the same behaviour will be exhibited with this solution?
Image Taken from Stuart Landrums MS-HUG Presentation
The last VERY cool area was Schema Generation. In the past the accelerator basically hid the underlying schema description database from the developers. So if your applications HL7 v2.x schemas deviated from the standard (and what applications don’t?) you were forced to generate a native schema, and then handtool the differences. When you are dealing with multiple systems and schemas this was highly time consuming and frustrating, as well as a significant source of errors. The new model enables you to customize the underlying Access database that HL7 provide on their web site to match your applications and then generate conformant messages directly. Localisation would be a good example of how this could be beneficial. One thought here, you have to be a HL7 member to get hold of this Access Database. But there are plenty of benefits to a membership so it’s not too much of a hardship!
So all in all I am very impressed with the changes, and I’m looking forward to completely rebuilding a couple of client solutions with these and other changes in the platform!
Powered by Qumana