In previous chapter, you learned about the future directions for HL7 with BizTalk. In this chapter, you will learn about the best practices for working with HL7 in BizTalk, which help improve the design and maintenance of applications. You will learn about best practices in the following areas:

• Managing HL7 Message Schemas
• Dynamic Data Validation
• Managing Trading Partners
• Message Exchange Pattern
• Ordered Delivery
• Optimization for Performance

Managing HL7 Message Schemas

BizTalk provides all HL7 message schemas as part of the HL7 Accelerator installation. The number of schemas is dependent on the following three properties:

• Message Type
• Message Trigger Event
• HL7 Messaging Standard Version

For each of these properties, BizTalk has one message schema (XSD) defined. In addition to these schemas, there are other schemas like the message header (MSH) and acknowledgment (ACK) message schemas. Managing so many schemas in a BizTalk environment can be a very painful task, especially when you need to deal with different versions, or different trigger events of one or more message types.

In order to manage these schemas in a more controlled manner and avoid deployment of all the schemas to a BizTalk environment, you can follow the best practices covered in this chapter, which will not only reduce the number of schemas deployed in your environment but will also help in maintaining them easily.

Deploying MSH and ACK Message Schemas to Their Own BizTalk Application

MSH and ACK message schemas are required to be deployed only once in entire BizTalk environment; in other words, there can’t be two MSH or ACK message schemas for messages to parse successfully by the HL7 Disassembler. It is a recommended practice to deploy and maintain these schemas in their own solution and BizTalk application. These schemas are hardly ever touched after first deployment. Keeping them separate will allow you to not worry about these while deploying and maintaining other message schemas.

Using One HL7 Message Standard Version

The BizTalk HL7 Accelerator supports HL7 versions from HL7 V2.1 to V2.6. HL7 messaging standards with higher versions are backward compatible with lower versions, so Version 2.6 is compatible with Version 2.1. So if you are receiving messages of different versions in a BizTalk environment then it is recommended to only use higher versions of a schema in BizTalk and use a pipeline component to change the version in the message header before passing the message to  the HL7 Disassembler.

Using Minimum Required Message Trigger Event Schemas

Similar to different schema versions, there are also have many message trigger events for a particular message type. BizTalk has a different schema for each trigger event of a particular message type; however, the message structure for each of these schemas is nearly same. So all ADT message trigger events (A01- A62) can be managed with one or two message schemas deployed. It is recommended to install and deploy only the minimum required message schemas and use a pipeline component to change the trigger event before parsing the message. This reduces the number of schemas to be deployed to a very low number, highly improving the maintenance of these schemas.

Changing Namespace for Customized Message Schemas

It’s highly unlikely that messages received will be in the exact format as defined by the HL7 messaging standard, and some customization to BizTalk message schemas is always required. It is recommended to change the target namespace of these customized schemas and use a trading partner to use these schemas. This allows you to isolate the changes from the original message schemas and their namespace. Please refer to Chapter 4 to customize a message schema.

Dynamic Data Validation

Dynamic data validation is about validating HL7 message content with dynamic data (the data that changes frequently). Although the HL7 Accelerator provides the ability to validate message content and format it using a message schema definition, this method of validation has following limitations:

• This is a static validation because the schema definition once deployed can’t be changed dynamically at runtime. Any change to the schema requires redeployment of the message schema.
• Redeployment of artefacts affects time-to-market: it slows down the process of delivering the new requirements.
• Many times HL7 messages received are not as per the HL7 messaging standard. Also, changing the message content is not feasible. In such cases, schema validation produces many more errors, as anticipated.

These limitations are huge in a large and changing environment as there is much pressure to deliver the ever-changing requirements quickly. To overcome these limitations, it is recommended to use the approach outlined in the following sections.

Resolving Message Structure Validation Issues

The HL7 Accelerator always performs message structure validation irrespective of whether message body validation is turned on or not. Message structure validation validates the segment and the field’s structure, whether the expected number of fields or subfields is present or not. For example, the OBX5 field by definition is a simple text (ST) format data type, and if in a message the OBX5 field has subfields in it, then the message structure validation will fail with a data type error. These data type errors can be difficult to find at times, and one of the best ways is to test the messages. In order to resolve these issues, it is recommended to resolve all such message structure validation by either making the message source change the message according to the definition or change the message schema to accommodate fields.

Using a Database to Maintain Dynamic Data

In order to maintain data that changes frequently, it is highly recommended to use a database to maintain such data, which allows easy updates to the data at runtime without redeploying the artefacts. The dynamic data can also include HL7 codes such as LOINC codes, SNOMED codes etc., against which you need to validate the message content.

Using Business Rules Engine (BRE) for Message Content Validation

This ensures that message content is valid as per your requirements by implementing business rule engine (BRE) policies. BRE policies can be invoked from pipeline components or from orchestration to perform message content validation. There are number of advantages of using BRE policies for message body validation:

• BRE policies can use a database to refer to dynamic data that changes frequently, which allows you to add or change the data at runtime without any redeployment.
• Validation will be based upon specific requirements rather than entire message content.

In order to implement content validation using BRE, you need to turn off message body validation from the HL7 Party Configuration Explorer and create a BRE policy referring to the database. Please refer to http://msdn.microsoft.com/en-us/library/aa560118.aspx to create a BRE policy for accessing a database. The BRE policy can be invoked from a pipeline component to return the validation errors as part of the message acknowledgment or from an orchestration depending on the requirement.

Managing Trading Partners (Parties)

In a large environment, you may receive or send HL7 messages to and from many different trading partners, with each of them having a different MSH3 or MSH5 in the HL7 message. As you learned in Chapters 3 and 4, you need to set up a BizTalk trading partner (party) for many functionalities of the HL7 Accelerator with respect to MSH3 and MSH5 values. Setting up a trading partner for each and every sending or receiving application can be very unmanageable especially if the environment is large. You can have smaller number of trading partners and manage them easily by using the following best practice.

Group Trading Partners

Generally a trading partner is created for each different MSH3 (Sending Application) value in message you receive, so if you receive HL7 messages having three different MSH3 values, you need to create three trading partners to apply the configuration you need. If each of these sending applications sends messages of the same type or which require similar customization and configuration, it is recommended to create only one trading partner and have one pipeline component to change the MSH3 value in the component before passing the message to the HL7 Disassembler. This way you can group the trading partners and reduce them significantly.

The same applies to trading partners created for the receiving application (MSH5). For example, if you need to batch outgoing HL7 messages for different destinations, you must create a trading partner for each MSH5 to create the required batch schedule. It is recommended to create one trading partner with one schedule and use the same trading partner in MSH5 when sending the message.

Message Exchange Patterns

There are specific message exchange patterns for HL7 messaging. The following are the key patterns you use in HL7 in BizTalk.

Fire-And-Forget Pattern

In the fire-and-forget pattern, the sending application keeps sending the messages without waiting for the message acknowledgment. This pattern performs better; however, it has the disadvantage that messages can’t be traced back in case of any issues.

Request-Response Pattern

In Chapter 2, we discussed two message processing exchange patterns, original mode and enhanced mode. Each mode differs in the way it sends acknowledgment to the sending application; however, the similarity is that in both the sending application waits for acknowledgment before sending the next message. The message exchange pattern is referred to as a request-response exchange.

It is recommended to use the request-response message exchange pattern, which ensures that you can trace the message acknowledgment and does not send the next message until you receive acknowledgment. If you are the receiver, you should use the request-response pattern with enhanced mode; in other words, use an intermediary storage to store messages, such as MSMQ or SQL Server, and return the acknowledgment before processing the messages. Storing messages in MSMQ or any other queuing system also helps in achieving ordered delivery of the messages.

Example

In order to demonstrate the above best practices with an example, consider the following scenario:

• BizTalk receives an ADT version 2.3 message with different trigger events.
• BizTalk validates the message and returns the acknowledgment.
• BizTalk stores the message in intermediate storage, such as MSMQ.

The steps to implement this scenario are covered in the following sections. Some of these steps are similar to those provided in the Chapter 4 scenario.

Building a Common Project

The first step in implementing the scenario is to create a common project that contains a message header (MSH) and acknowledgment (ACK) schema. This will only need to be done once in the BizTalk environment for all HL7-based applications. You can skip this step if you already have MSH and ACK messages deployed to BizTalk.

1. Create a Visual Studio blank solution and name it HL7.Common.
2. Create a new BTAHL7V2XCommon project in the solution named HL7.Common.Schemas, as shown in Figure 7-1.

   

   Figure 7-1. Common project template

3. The project in Solution Explorer will look like Figure 7-2.

   

   Figure 7-2. Common project in Solution Explorer

4. Change the BizTalk Deployment properties to deploy this project to BizTalk under the HL7.Common BizTalk application.
5. Sign the project using a strong name key and deploy it.

Building a Message Schema (ADT) Project

The next step is to create BizTalk project to add ADT message type schemas and deploy it. You will use ADT V2.5.1 schemas even though you are going to receive a V2.3 message. This will help you maintain less BizTalk schemas.

1. Create a new Visual Studio blank solution called HL7.Samples.
2. Create a BTAHL7V251Common project to the solution, as shown in Figure 7-3.

   

   Figure 7-3. Segments, DataTypes, TableValues project template

3. The above step will add the datatypes_251, tablevalues_251, and segments_251 schemas. Now add a new item to project by pressing Ctrl+Shift+A and select BTAHL7 Schemas, as shown in Figure 7-4.

   

   Figure 7-4. Message Type schema template

4. Click Add, and don’t worry about naming the file as next step overrides anything you select here. Once you click Add, you will get a new screen called HL7 Schema Selector to select the message type, triggering event, and version.
5. Select the message class, version, message type, and trigger event, as shown in Figure 7-5. Once you click Create, it adds schema ADT_A01_251_GLO_DEF.xsd.

   

   Figure 7-5. HL7 schema type selector

6. By default, the message schema is expected to be added to a separate project because it refers to segments_251. xsd from an assembly reference, as shown below from the schema file:

   <xs:import schemaLocation="BTAHL7Schemas.segments_251" namespace="http://microsoft.com/HealthCare/HL7/2X/2.5.1/Segments" />

7. Since you added the schema to same project as the segments_251 schema, change the schemaLocation as follows:

   <xs:import schemaLocation="segments_251.xsd" namespace="http://microsoft.com/HealthCare/HL7/2X/2.5.1/Segments" />

8. The project in Solution Explorer will look like Figure 7-6.

   

   Figure 7-6. Message schema project in Solution Explorer

9. Change the default namespace from http://microsoft.com/HealthCare/HL7/2X with namespace http://hl7.samples/schemas/hl7/2x in all .xsd files.
10. Change the BizTalk deployment application to HL7.Samples in the project properties.

Building a Custom Receive Pipeline Component

This pipeline component changes incoming MSH segment fields to standardize the message before disassembling the message. It changes three MSH segment fields as follows:

1. The pipeline component changes MSH3 and MSH5 to HL7_Samples corresponding to the HL7 party you will define.
2. The pipeline component changes MSH8 to ADT^A01 always because A01 is the schema you have deployed.
3. The pipeline component changes MSH12 to 2.5.1 to standardize the message version.

The pipeline component code is shown in Listing 7-1.

Listing 7-1. Pipeline Code

public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)
{
    if (pContext == null || pInMsg == null)
        throw new ArgumentNullException();

    IBaseMessageContext msgContext = pInMsg.Context;

    if (msgContext == null)
        throw new ArgumentNullException("pInMsg.Context");

    //wrap the stream into readonly seekable stream
    if (!pInMsg.BodyPart.GetOriginalDataStream().CanSeek)
    {
        ReadOnlySeekableStream seekableStream = new
        ReadOnlySeekableStream(pInMsg.BodyPart.GetOriginalDataStream());
        // Set new stream for the body part data of the input message.
        //This new stream will then used for further processing.
        // We need to do this because input stream may not support
        //seeking, so we wrap it with a seekable stream.
        pInMsg.BodyPart.Data = seekableStream;
        pContext.ResourceTracker.AddResource(seekableStream);
    }

    Stream stream = pInMsg.BodyPart.GetOriginalDataStream();
    //preserve stream position
    long position = stream.Position;

    string message;
    StreamReader sr = new StreamReader(stream);
    message = sr.ReadToEnd();

    stream.Position = position;

    //1. replace MSH3 and MSH5 with a Party defined e.g. HL7_Samples
    //2. change MSH12 to 2.5.1
    //3. Change MSH8.2 to A01

    string[] segments = message.Split('
'),
    string[] mshSegment = segments[0].Split('|'),

    //These are hard coded in pipeline for demo, can be used from //pipeline properties
    mshSegment[2] = "HL7_Samples";
    mshSegment[4] = mshSegment[2];

    mshSegment[8] = "ADT^A01";
    mshSegment[11] = "2.5.1";

    //aggregate the message segments back
    segments[0] = mshSegment.Aggregate((s1, s2) => s1 + "|" + s2);
    message = segments.Aggregate((s1,s2)=> s1 + '
' + s2);

    //change the message
    MemoryStream ms = new MemoryStream(System.Text.Encoding.ASCII.GetBytes(message));
    pInMsg.BodyPart.Data = ms;
    pContext.ResourceTracker.AddResource(ms);

    return pInMsg;
}

After building the pipeline component, build and install the pipeline component to GAC (Global Assembly Cache) and the C:Program Files (x86)Microsoft BizTalk Server 2013Pipeline Components folder.

Building a Custom Receive Pipeline

This step creates a custom receive pipeline that uses the BizTalk HL7 Disassembler pipeline component in the disassembler stage, along with your custom pipeline component created in the previous step at the decode stage, as shown in Figure 7-7. Please add this pipeline to the project HL7.Samples.Pipelines in same solution.

Build the solution and deploy the projects to the HL7.Samples BizTalk application.

Configuration

After deploying the application, follow these steps to configure the application.

1. Create a HL7 Party with the name HL7_Samples and change the acknowledgment mode to original mode, uncheck the body validation, check the allow trailing delimiters checkbox, and change the schema namespace to http://hl7.samples/schemas/hl7/2x.
2. Create a two-way receive port, as shown in Figure 7-8.

   

   Figure 7-8. Two-way receive port

3. Configure MSMQ on the development machine if it’s not already available. You can check the Windows Add Features to see if MSMQ is configured or not, as shown in Figure 7-9.

   

   Figure 7-9. MSMQ

4. In Computer Management or Server Manager, go to Services and Applications Message Queuing. Create a private queue called hl7samples_adt with transaction set to true, as shown in Figure 7-10.

   

   Figure 7-10. MSMQ Queue HL7Samples_ADT

5. Create a one-way send port to save the incoming message MSMQ with the configuration shown in Figure 7-11.

   

   Figure 7-11. One-way send port

Testing the Application

Once application is deployed and configured, you can test the scenario using the following sample message:

MSH|^~&|ADT|MCM||MCM|198808181126|SECURITY|ADT^A01|MSG00001|P|2.3|||AL|NE
EVN|A01|198808181123
PID|||PATID1234^5^M11||J^WILL^A^III||19610611|M||2106-3|1 ELM STREET^^GREEN^NA^11111-1020|GL|(111)111-1212|(111)111-3434~(111)111-3114||S||PATID12345001^2^M10|123456789|9-87654^NC
NK1|1|J^BA^K|SPO|||||20011105
PV1|1|I|2000^2012^01||||004777^LEBAU^SID^J.|||SUR||-||1|A0
AL1|2||^CAT DANDER
DG1|001|I9|1550|MAL NEO LIVER, PRIMARY|19880501103005|F||
ROL|45^RECORDER^ROLE MASTER LIST|AD|CP|K^SM^E|199505011201
GT1|1122|1519|BILL^GATES^A
IN1|001|A357|1234|BCMD|||||132987
IN2|ID1551001|SSN12345678
ROL|45^RECORDER^ROLE MASTER LIST|AD|CP|K^E|199505011201

As you can see, this message is of Version 2.3. When you test this message by sending it via MLLPSend or 7Edit to your receive location, you will receive the accept acknowledgment and the message is moved to your MSMQ queue with changed message version.

Ordered Delivery

In a HL7 messaging solution, ordered delivery of some of the messages is important because the order of those messages relates to real-life events that occur; for example, in patient administration, the patient admit (A01) event occurs before the patient discharge (A03) event. In a system, ADT^A01 should flow before ADT^A03 for a single patient, and this order should be maintained in all systems involved. The key point to note here is that for multiple patients the data can flow through in parallel, but for single patient it should be in order. In order to maintain the order delivery in BizTalk, use the following best practices.

Using Order Delivery on Receive Location

The input message should be received using adapters that support ordered delivery, such as MSMQ, MQSeries, and MLLP in BizTalk. This ensures that messages are published in order to the message box.

Using the Send Port with Ordered Delivery

Set the ordered delivery along with “stop sending subsequent messages on current message failure” of MLLP send ports from the transport advanced options. This will ensure that messages are delivered in order from the message box.

Using the Ticket Dispenser and Gate-Keeper Orchestration Pattern

In case of a messaging scenario, the first two options allow you to process the messages in order. However, in cases where you have multiple orchestrations to process the incoming messages before sending the message out, the message order is not guaranteed for messages published from orchestration because each orchestration processing may take a different amount of time to complete. In order to maintain the message order delivery in such scenarios, you need to use a ticket dispenser and re-sequencing pattern in addition to above two steps. The pattern is defined below on a high level.

Creating a Custom Pipeline

Create a custom pipeline component to assign each message a unique sequence number. This sequence is updated to the message context before the message is published to the message box. This sequence number will be used by the gatekeeper orchestration to re-sequence the outgoing messages.

Updating the Sequence Number in Orchestration

In business orchestrations, you can preserve the sequence number in outgoing messages by writing the sequence number in the message context. These orchestrations should also promote a property to make these messages go to gatekeeper orchestration, such as a destination property.

Implementing Gatekeeper Orchestration Using a Sequential Convoy

Implement a new orchestration that serves as gatekeeper for all outgoing messages. It receives all the messages and correlates them based upon a destination property before messages go out. It checks whether the current message is the next message to go out by checking the sequence number of the current message with last sent message sequence number. If the current message is not the one to go out, orchestration keeps it in an in-memory queue. For more details on the pattern, please go to:

http://msdn.microsoft.com/en-us/library/bb851740(v=bts.10).aspx

Optimization for Performance

HL7 message delivery usually takes place using the MLLP send adapter, which does not provide as good performance as other adapters such as WCF-SQL, FILE, etc. This can become even slower if the destination system is not accepting the messages at the rate you expect. This can create a bottleneck in BizTalk, and the BizTalk send host may start to throttle, which will further slow down the message delivery.

If the message incoming rate does not slow down, very quickly you will see lots of messages build up in the “Ready to Run” and “Active” states on the send host. Depending on the daily volume of the messages, this can be a huge problem. In order to avoid this problem, you need to follow some best practices, outlined in the following sections.

Using MSMQ for Message Delivery

You should use MSMQ or another queuing system like MQSeries to store messages before the messages are sent out to a specific destination. Using MSMQ is very simple and straightforward in BizTalk and does not require any additional development. MSMQ allows you to easily control the message flow to the destination by enabling/disabling the MSMQ receive locations whenever the destination system is not available.

Using BizTalk Receive Host Throttling

BizTalk host throttling is great way to control the messages coming into BizTalk Message box in case the destination message outgoing rate is slow. This works especially well in messaging-only scenarios. Use the host throttling performance counters at http://msdn.microsoft.com/en-us/library/aa578302.aspx to determine the right configuration settings for your environment.

Isolating MLLP Hosts

This is a standard BizTalk practice to isolate hosts at receive, send, and orchestration level; however, with HL7-based solutions you may need to further isolate hosts depending on the volume, especially for MLLP send hosts. Since it’s difficult to scale the MLLP send hosts on multiple server, you may need to create multiple MLLP send hosts. One criteria to creating these hosts is based on message type, such as one MLLP send for ADT, one for ORM etc.

Using Messaging Scenario

Wherever possible you should use a messaging-based solution only without implementing orchestrations. For HL7 solutions, especially when you need ordered delivery, the complexity is increased with orchestration. Due to the HL7 message being a multipart message, the only way to create and invoke transformation is through orchestration. However, if transformation is simple and only requires few field changes, it is recommended to do it in pipeline component.

Monitoring

Having the ability to monitor your HL7 implementations is extremely important. Without proper monitoring you won’t know what is going on with your applications.

There are several monitoring tools on the market, but there is only one that stands out. This product provides you with complete control of the entire HL7 environment. That product is BizTalk360 (www.biztalk360.com). BizTalk360 was developed by Saravana Kumar, who is also an Integrations MVP. There are too many features to list here, so it is recommended that you visit the BizTalk360 web site and see them for yourself.

Summary

In this chapter, you learned various best practices for HL7 solution implementation in BizTalk such as managing schemas, the message exchange pattern, ordered delivery, and more. Implementing these best practices is important, even essential, for any HL7 solution in order for it to perform better and to improve manageability. Lastly, you learned about the need for monitoring.