Export (0) Print
Expand All

HL7 v2 Developer Guide

A printer-friendly version of this document can be downloaded from here.

The purpose of this paper is to serve as a guide for the developer who is building HL7 v2 solutions with Microsoft® BizTalk® Server 2006. The paper addresses common development concerns that are encountered when processing HL7 v2–formatted data through BizTalk Server 2006 using BizTalk Accelerator for HL7 v2.0 (HL7 Accelerator).

A working knowledge of the HL7 v2.x message structure and messaging protocols is presumed. Since the focus is on the development of HL7 v2 solutions, topics such as HL7 v2 to HL7 v3 interoperability and HL7 v2 solution architectural patterns and design are covered separately.

The sample code referenced in this paper can be found here.

The HL7 messaging protocol was designed to facilitate high volumes of pre-defined data to be shared across many applications in a reliable fashion. This necessitates automatically routing data using a traditional file transfer or via a TCP/IP socket in both a real-time and batched fashion. The protocol accounts for messaging reliability through real-time message acknowledgment requirements. Finally, as a basic messaging standard, the HL7 v2 message structure is a complex, flat-file, delimited format.

BizTalk Server is a robust and flexible integration tool that is ideally suited for reliably routing high volumes of data among line-of-business (LOB) applications. It was designed as a cross-industry solution that uses XML as its core message format. To accommodate industry-specific needs, added components are developed to provide not only industry-specific transport protocol support, but also support for industry-defined message structures. In the case of HL7 v2, the HL7 Accelerator provides the following components that supplement BizTalk Server's native functionality:

  • More than 1,300 HL7 schemas for 2.1 through 2.5 message types
  • HL7 message disassembler and assembler pipeline components that convert and validate data to/from the HL7 v2 structure to XML for internal BizTalk Server use
  • A transport adapter that supports the Minimal Lower Layer Protocol (MLLP)
  • Automatic message acknowledgement creation
  • Batch file support

The HL7 Accelerator is installed after BizTalk Server is installed and configured. Its purpose is to add functionality to BizTalk Server, so that it can appropriately address expected HL7 processing functionality. Although development success depends to a great deal on knowledge of the HL7 message structure and messaging protocols, it is also driven by an awareness of core BizTalk functionality – namely, that it is a robust event-driven, XML-based, business process management tool.

There are some fundamental differences between HL7 industry processing needs and expectations and BizTalk’s core functionality. A basic example is that HL7 v2.x is a complex flat-file structure that, despite being considered a data standard, is also highly flexible. It is often expected of an HL7 integration engine that non-standard compliant data be accepted and processed without notification to the receiving system of non-compliance. However, because BizTalk Server parses the HL7 data into XML so that components of the data can be accessed via maps and orchestrations, its core functionality requirement of defined data definition via schemas becomes a challenge when developing certain HL7 interfaces. Being aware of the differences allows you to address the gap head on and develop solutions accordingly.

As discussed further in this paper, the typical development problem areas are related to how data is validated and parsed into XML and how BizTalk Server is designed to route data through the message box. With an awareness of how the HL7 parser that is provided by the HL7 Accelerator works in conjunction with BizTalk core components such as pipelines and orchestrations, you can realize greater initial interface success and thus avoid lengthy troubleshooting diversions.

The first step in developing an HL7 solution is getting the inbound data into the BizTalk message box. This entails having an understanding of the message types and versions that you will be processing. Once you know the message type and version that you will be using, you have all the information you need to configure and deploy the appropriate HL7 message schema. You can then receive, validate, and parse your messages into the BizTalk message box.

The HL7 schemas provided by the HL7 Accelerator were created directly from the HL7 organization’s HL7 v2.x message database. This means that the schemas you deploy out of the box in BizTalk Server match the HL7 organization’s version-specific definitions.

However, it is rare that an HL7 message will match the industry defined standard exactly. Although you can easily determine the message type and version you are processing, it is not likely that you will be aware of the exact differences between your particular data file and the industry standard. During your initial pass of HL7 data through BizTalk Server, those differences, if any, will be identified in detail via a message acknowledgement.

This section details how to configure BizTalk Server to process HL7 messages that comply with the defined HL7 message structure. Additionally, it addresses how to quickly and easily identify messages that do not exactly match the HL7 standards. For structurally compliant messages, you can begin accepting and processing HL7 data through BizTalk Server with minimal development.

For non-compliant messages, the next step is to customize the provided HL7 message schema as necessary for the interface. The next section details how to customize your HL7 v2 message schema.

Configuring a Test HL7 Solution

Configuring a test solution allows you to immediately move data into BizTalk Server. During this process, all issues with non-standard compliant data are identified. Once identified, schemas can be customized as necessary. Since schemas are central to all BizTalk processes, this step is vital to the rapid development of an HL7 solution.

The steps to configuring a test HL7 solution are:

  1. Deploy the necessary schema
    • Message header and acknowledgement schema
    • Dictionary schema
    • Message structure schema
  2. Configure acknowledgements
  3. Configure a receive location to use the HL7 Receive Pipeline
  4. Configure send ports
    • Use the HL7 Send Pipeline
    • Use proper filters

The steps are detailed in the sections that follow, along with an explanation of why they are necessary. The explanations about the role of each development step help explain the necessary steps when customizing HL7 schema for non-standard compliant data. A sample test solution can be configured by following the step-by-step click-through instructions at the end of this section.

Deploying the Necessary HL7 Schema

As mentioned earlier, the HL7 Accelerator comes with 1300 predefined schemas to match every 2.X (2.1 through 2.4) message type. These schemas were generated from a Microsoft Access database that the HL7 organization provided, so they are considered “official” definitions.

However, when it comes to a version 2.X message, you rarely see an “official” message. Rather, individual interpretations of messages abound. To accommodate this reality without adding an excessive amount of complexity to the schema, the data fields, segments, and tables that identify looping structures are defined in separate schemas per version. They serve almost as a version-specific dictionary.

Individual message components are defined in “dictionary” schema
Bb981217.5af2a17c-298e-4dd6-9615-945516d62b59(en-US,BTS.10).gif
Bb981217.note(en-US,BTS.10).gifNote
The current release of the HL7 Accelerator does not contain predefined schema for versions higher than v2.5. Handling higher versions is discussed in the “Customizing the HL7 v2 Schema” section. Future releases of the HL7 Accelerator will provide schema for versions higher than v2.5.

After they are defined, individual message schemas are created for each message type. These individual message schemas depict the necessary message structure. Message schemas then reference the dictionary schemas for common individual definitions. You can think of this as the same way a Microsoft Visual Studio® project might reference external assemblies to access classes. In fact, a BizTalk project, just like any other development project in Visual Studio, follows the same reference rules of object-oriented development.

Message schema depict the message structure and reference the dictionary schema for individual definitions
Sample message schema

The benefit of this definitional separation is that message structures can be both globally and locally altered from the official standard. If you want to alter the definition of a segment or data field for every message that you process, alter the definitional schema. If you want to only vary from the standard for that particular message type, you can make the change locally in the message schema. The usability benefit of this definitional separation is that the message schemas are less complex, and thus easier to work with inside the mapping tool.

Because of the backward-compatibility rules, the version 2.5 MSH segment and acknowledgment (ACK) structures are appropriate for all prior versions. Furthermore, regardless of the specific HL7 version that you are processing, you will always have an MSH segment, and the engine will auto-generate acknowledgements. For this reason, separate schemas have been provided for the MSH segment and for HL7 acknowledgements in a version 2.5 format.

The Message header schema
Bb981217.aa601aec-44a5-46bb-92ac-bf498b276a25(en-US,BTS.10).gif

To understand what needs to be deployed, take a look at the provided schemas. Starting with the premise, as discussed earlier, that both definitional and message structure schema are provided by version, it is necessary to deploy both of these schema types. Because the message structure schemas rely on the definitional schemas, it is necessary to make sure that the message structure schemas have the appropriate reference to the definitional schemas once deployed. Additionally, you will need to deploy the schemas that define the MSH segment and acknowledgements.

Deploy the Project That Contains MSH and ACK Schemas

To begin, in Solution Explorer in Visual Studio, open the predefined BizTalk HL7 project called BTAHL7V2XCommon Project. This contains the MSH and ACK schemas.

The BTAHL7V2XCommon Project contains schemas for the MSH segment and HL7 acknowledgments
BTAHL7V2XCommon Project schemas

Open a Visual Studio 2005 command prompt, go to C:\BizTalk HL7 Dev, and then run the following command:

sn -k MyKeyFile.snk

After creating and setting this required Assembly Key (.snk) file, deploy this project. This is a one-time step that is necessary for all of your HL7 processing because now the message header and acknowledgement schemas are available in the configuration database.

Bb981217.note(en-US,BTS.10).gifNote
This project should only be deployed once. Once you have done it as part of your initial HL7 test solution, you will not need to perform this step again while you are using this particular message box.

Deploy the Version-Specific Definitional Schemas

Definitional schemas are provided for each of the 2.X versions in predefined BizTalk projects by version. You will need to deploy the appropriate project for the HL7 version that you are processing. In Solution Explorer, add an existing HL7 project. The projects are located under HL7 schema projects and are identified as BTAHL7V231Common Project, where the “V231” indicates the version number. When this opens in Solution Explorer, notice that three schemas—datatypes_231.xsd, segments_231.xsd, and tablevalues_231.xsd—are included in the project.

The BTAHL7V231Common Project contains the definitional schema referred to by all Version 2.31 message schemas
Definitional schema for BTAHL7V231Common Project

After applying the necessary Assembly Key (.snk) file, deploy this project. This is a one-time step that is necessary for all of your version 2.31 processing because now the definitional schemas referenced by all version 2.31 schemas are available in the configuration database.

Bb981217.note(en-US,BTS.10).gifNote
This project should only be deployed once for each HL7 version. Once you have done it as part of your initial HL7 test solution for a particular version, you do not need to perform this step again while you are using this particular message box. If, however, you desire to test a different version, such as v2.4, you will need to repeat this step for the v2.4 Dictionary Schema.

Deploy Specific Message Schemas

Once the header, acknowledgement, and version-specific definitional schemas are deployed, configure and deploy message specific schema as necessary for your HL7 processing. In Solution Explorer, add an empty HL7 project. In this project, add a reference to the previously deployed project that contains the definitional schemas for the message version you are processing. For instance, if you are processing a Version 2.31 Admissions Discharge and Transfer (ADT) message, you would reference the Version2.31 Common Project that you just deployed.

Reference the version-specific definitional schema in your HL7 message project
HL7 message schema references

Once the reference is added, add a message schema to this project for each message type that you are processing. To do this, add a new item to the project, selecting schemas under BTAHL7 Items. In the HL7 Schema Selector dialog box, select the version and message type that you want. For example, if you are processing a version 2.31 ADT^A01 message, select 2.31 for the version, ADT for the message type, and A01 for the trigger event. This adds the message definition schema to your project.

Select the version, message type, and trigger event code to add a message definition schema
HL7 Schema Selector dialog box

Once you have added all of the message schema that you want, apply the necessary Assembly Key (.snk) file, and deploy this project. Once done, these are the schemas you will reference and use in your maps and orchestrations.

Bb981217.note(en-US,BTS.10).gifNote
For ease of maintenance, it is a recommended practice to deploy your message schemas separately from maps and orchestrations.

Configuring Acknowledgements

The HL7 Disassembler (DASM) found in the HL7 Receive Pipeline automatically generates HL7 acknowledgements. However, if you do not configure BizTalk Server appropriately, the acknowledgements will sit unprocessed in the message box.

The HL7 Accelerator makes use of party definitions to associate acknowledgements to sending applications. A party is the means through which BizTalk Server uniquely identifies a sending application by associating the sending application’s identifier with the specific acknowledgement and batching configurations desired for that application.

Once a party has been defined, the BizTalk Accelerator for HL7 Configuration Explorer (accessed via the Start menu) is used to configure the type and format of the acknowledgements sent to that party. You need to add a party for each application that sends data into BizTalk Server. The party definition must contain the value that the particular application places in the MSH.3 field in the message header because that is how the parser matches the data to the party definitions.

Parties are defined and configured in BizTalk Explorer. To add a party, simply right-click the Parties tab within BizTalk Explorer under your configuration database, and then select Add New Party. Name the party something that is relevant to your processing. In the Aliases column, enter the value that occurs in the MSH.3 field in the message header.

Define a party for each application sending data into BizTalk Server
Party Properties - Aliases - Configurations dialog

Once you have defined the party, you can configure the acknowledgements going to this party in the BizTalk Accelerator for HL7 Configuration Explorer.

The HL7 Configuration Explorer
HL7 Configuration Explorer

To configure an acknowledgment, select the desired party on the Parties tab, and then click the Acknowledgment tab. The generated application acknowledgement details all areas where the received message does not match the schema. Use this to identify the parts of the schema that must be customized in order to process your desired message type.

The HL7 DASM can create three basic types of acknowledgements based on the configuration settings found in the HL7 Configuration Explorer:

  • Commit Acknowledgment, which basically informs the sending system that BizTalk actually received the message.
  • Application Acknowledgment, which identifies how BizTalk Server handled the message contents. It is in the Application Acknowledgment that you will see details on any parsing errors.
  • Static Acknowledgment, which is used when you want to always return a user-defined acknowledgment.

Both the Original and Enhanced Mode acknowledgment types will return an Application Acknowledgement (App ACK). The difference is that the Original Mode will only return an App ACK while the Enhanced Mode will return both an App ACK and a System ACK. For purposes of a test solution, you only need to set the acknowledgement type to Original.

Bb981217.note(en-US,BTS.10).gifNote
Acknowledgment settings play a key role in how BizTalk Server interacts with your receiving system. Regardless of your ACK settings, the value in the MSH.15 of the inbound message determines whether an ACK will be generated. If there is nothing in the MSH.15, then your settings in here will determine behavior.

Acknowledgement settings in the HL7 Configuration Explorer
HL7 Configuration  Acknowledgement Settings

At the point that the ACK is being created, BizTalk Server is the acknowledging application; however, BizTalk Server theoretically acknowledges the message on behalf of the receiving application (the entity identified in the MSH.5 element). The default behavior is for the DASM to automatically switch the MSH.3 value in the incoming message to the MSH.5 element in the ACK. In this way, the automatically generated ACK will have an MSH that identifies the original receiving application (the MSH.5) as the now-sending application (the MSH.3). Likewise, the original sending application (the MSH.3) becomes the now-receiving application (the MSH.5) in the ACK. If you want to override this behavior, perhaps to identify BizTalk Server as the acknowledging application, you can enter desired MSH values on the Acknowledgment tab of the HL7 Configuration Explorer.

Acknowledgments will be discussed again later in this paper in regards to controlling message flow through BizTalk Server. However, at this point, you are using the ACK to identify any structural issues with your data. Therefore, for purposes of a test solution, you need only configure the system for application acknowledgements.

Configuring Validation Settings

At this point, the only validation setting that you need to consider is the Allow Trailing Delimiters setting found on the Validation tab of the HL7 Configuration Explorer. The default behavior of the HL7 DASM is to not expect to see delimiter values holding the place for optional elements that come at the end of a segment when those elements are not present. Basically, the standard states that segments should end after the last element that holds a value, as in the following example.

Message with no trailing delimiters

MSH|^~\&|HIS|MCM|NewSys||199601121005||ADT^A01|000001|P|2.3.1
EVN|A01|198808181123
PID|||PATID1234^5.0^M11~123456789^5
NK1|1>

However, it is quite common for sending applications to produce data that does contain delimiters between empty elements at the end of a segment, as shown in the following example. This is commonly referred to as trailing delimiters.

Message with trailing delimiters

MSH|^~\&|HIS|MCM|NewSys||199601121005||ADT^A01|000001|P|2.3.1
EVN|A01|198808181123|||
PID|||PATID1234^5.0^M11~123456789^5|||||||||
NK1|1|||||

Before running your test solution, you should look at your test file to determine if trailing delimiters are present. If they are, click the Validation tab in the HL7 Configuration Explorer for the correct party (the MSH.3 message value). On the Validation tab, select the Allow Trailing Delimiters check box. If trailing delimiters are not present, you do not need to configure this setting.

The HL7 Receive Pipeline

The BTAHL7 (BizTalk Accelerator for HL7) Receive Pipeline contains its own disassembler component (DASM) that reads the MSH segment to determine the message type and version. Based on this information, it then looks to the configuration database to locate the appropriate message schema that defines the message.

Armed with the schema that defines the structure, the data is then parsed, or disassembled, from its delimited structure and converted into XML for use by the BizTalk engine. As the data is disassembled, it is validated against the message schema. This all occurs within the disassembler component of the pipeline and is alternatively referred to as the BTAHL7 Disassembler. Unlike the default flat-file DASM that BizTalk Server provides, the HL7 one does not require that a schema be specified per pipeline.

Once the message is validated, the DASM also creates the appropriate acknowledgement of the message. More than one acknowledgement may be created, depending on the acknowledgement level that was configured for the party that sent the original message. As discussed earlier, the DASM will create system and application level message acknowledgements. These are created after validation by the BTAHL7 DASM component. Both the XML-ized message and acknowledgement are then published to the BizTalk message box where they will remain until subscribing systems pick them up.

The BTAHL7 Receive Pipeline is automatically deployed when you install the BizTalk Accelerator for HL7. Thus, there is out-of-the box functionality, meaning that you do not need to do anything special to use the pipeline in your HL7 receive locations.

Locations receiving HL7 data must use the BTAHL7 Receive Pipeline
BTAHL7 Receive Location Properties

However, functionally speaking, the BTAHL7 Receive Pipeline is simply a custom BizTalk pipeline. Because of this, you can re-use the DASM within your own custom pipelines and have the ability to add components before or after the DASM stage. This is useful if you need to preprocess the data before publication to the message box.

The HL7 Send Pipeline

Similar to the BTAHL7 Receive Pipeline, the BTAHL7 Send Pipeline uses the HL7 message schema to assemble, or serialize, and validate the structure of the data into a delimited flat-file before it is sent to subscribing systems. Essentially, the BTAHL7 Assembler (ASM) takes the XML document from the BizTalk message box and returns an HL7-encoded message.

As with the BTAHL7 Receive Pipeline, the BTAHL7 Send Pipeline is automatically deployed upon installation of the BizTalk Accelerator for HL7. The BTAHL7 Send Pipeline is used in all send port definitions that subscribe to HL7 data and require HL7 output.

Send Ports sending HL7 data must use the BTAHL7 Send Pipeline
Send Port Properties Configuration dialog box

As with the BTAHL7 Receive Pipeline, the BTAHL7 ASM can be re-used in your own custom send pipelines. A component added before the assembly stage affects the data while it is still in its XML form; a component added afterwards will occur once the data has already been serialized into an HL7-encoded message.

Configuring Send and Receive Ports

As the message passes through the HL7 DASM in the HL7 Receive Pipeline, one of two things happens to it. If the data matches the deployed HL7 schema, it is parsed into XML and placed in the message box. If the data does not match the deployed HL7 schema, it is passed through to the message box in its original form.

In both cases, if you have configured BizTalk Server to produce an acknowledgment, one will be generated and placed in the message box with the message. If the message was parsed, a positive ACK will be generated. If the data had structural errors (also referred to as parse errors) then a negative ACK (or NACK) will be generated.

Use the Application ACK to identify what, if any, schema changes are necessary to be able to process your message through BizTalk Server. If you receive an ACK, you do not need to alter the HL7 schema.

Positive Application Acknowledgement (ACK)

MSH|^~\&|NewSys||HIS|MCM|20061117155328||ACK^A01^ACK|100000|P|2.3.1|||NE
MSA|AA|000001

If you receive a NACK, it will contain details of what needs to be altered in your schemas to process your message through BizTalk Server. As you can see in the following example, the NACK contains an entry for every element and segment that is in error.

Negative Application Acknowledgement (NACK)

MSH|^~\&|NewSys||HIS|MCM|20061117155436||ACK^A01^ACK|100000|P|2.3.1|||NE
MSA|AE|000001
ERR|PV1_PatientVisitSegment^1^2^103&Table value not found&HL7nnnn
ERR|DRG_DiagnosisRelatedGroupSegment^1^11^unexpected data found

For example, the NACK just shown has identified that the second element in the first instance of the PV1 segment is in error because the value in the element does not match its restriction list. Furthermore, the DRG segment is in error because it is structurally incorrect—perhaps because the segment contains more elements than allowed or because the element contains components that it is not expected to have. These entries and their fixes are discussed in further detail in the “Customizing the HL7 v2 Schema” section that follows.

Because some sort of acknowledgment is dropped to the message box along with your message, whether good or bad, you need to have send ports that subscribe to:

  • The good HL7 message (assuming you wish to re-serialize it to an HL7 v2 format via the HL7 Send Pipeline).
  • The bad HL7 message (because it will have been unparsed and thus will fail serialization through the HL7 Send Pipeline).
  • The acknowledgement (one port can receive both ACKs and NACKs).

To configure a send port to receive the good HL7 message, use the HL7 Send Pipeline and a filter that looks for the original MSH.5 value, which is the value for the receiving system. You might also want to add a condition that says there were no parse errors.

Send Port filter for good messages
Configuring the Send Port filter for good messages

To configure a send port to receive any messages that fail validation, or bad messages, you will use the default PassThru Pipeline. This is because the message will not have been parsed into XML and by definition is not properly formed in the expected HL7 structure. You will see it produced to you in its original format. As a filter, set the condition to check for all messages that are both HL7 messages and have parse errors.

Send Port filter for bad messages
Configuring the Send Port filter for bad messages

Finally, to configure a send port to receive your acknowledgments, use the HL7 Send Pipeline, and set a filter that looks for the original MSH.3 value in the MSH.5 position, since the ACK will reverse the original MSH.3 and MSH.5 values. So, for example, if the original message has an MSH.3 of HIS, the filter for the acknowledgment send port looks for HIS in the MSH.5 position.

Bb981217.note(en-US,BTS.10).gifNote
A send port with the filter pictured in the following figure receives any message that has the value HIS in the MSH5.1 position. To guarantee that you only receive acknowledgment messages at this send port, add a filter for the ACK message type.

Send Port filter for acknowledgements
Configuring the filter for acknowledgements

Once you have the send ports configured, you can create a receive port and receive location that will pick up the original message from a test file location. The only necessary configuration for the receive location is that you use the HL7 Receive Pipeline.

Receive Locations for HL7 data use the HL7 Receive Pipeline
Bb981217.13a475d4-cc8c-4e19-8d60-03788ef1efcf(en-US,BTS.10).gif

Once you have configured your receive port and three send ports, enable, enlist, and start all. You are now ready to send your desired message through BizTalk Server by placing it in your receive location. Once the message is consumed, check to see if an ACK or NACK was generated. If an ACK was generated, there is no need to customize your schema. If a NACK was generated, compare the errors to the message to determine what values in the schema need to be altered to match your message format and structure.

When altering schema, it is a good idea to create custom schema that are specific by interface or vendor. The next section details how to customize the HL7 schema.

Bb981217.note(en-US,BTS.10).gifNote
This approach presumes that your test data is similar to your production data. To ensure that your test solution mimics real life, to the extent possible, your test messages should be obtained from a production feed. This approach is meant to quickly identify necessary BizTalk schema customization. It is not meant to negate the need for developers to perform an initial message analysis and to understand the message specifications of the systems involved in the exchange.

Click-Through Steps for Configuring a Test Solution

The following steps detail how to configure a test solution.

To configure a test solution
  1. Create a blank solution. A solution might include only one BizTalk project if the solution is relatively simple. A solution might include many BizTalk projects, if the solution consists of numerous projects that are developed independently and then must be integrated later.

    1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2005, and then click Microsoft Visual Studio .NET 2005.
    2. On the File menu, point to New, and then select Project.
    3. In the New Project dialog box, select Empty BizTalk Server Project template.
    4. In the Name field, type ADT_Test as the solution name.
    5. In the Location field type C:\BizTalk HL7 Dev.
    6. In the Solution Name field type Test Solution.
    7. Check the Create Directory for Solution box.
    8. To open the new solution, click OK.
  2. Add the HL7 2X Common Project to the solution. The schemas in this project are used by the Disassembler to determine which message type/version to validate against and to create the acknowledgment. This project is not version-specific, and is common to all message types. It must be deployed along with the version-specific schema projects you will create in a later step.

    1. In Solution Explorer, right-click Test Solution, point to Add, and then select New Project.
    2. In the Add New Project dialog box, navigate to BizTalk Projects.
    3. In the Templates pane, select BTAHL7V2XCommon Project.
    4. In the Name field, type BTAHL7V2XCommon as the project name and save into the C:\BizTalk HL7 Dev\Test Solution folder.
    5. Click OK to open the new project.
      Bb981217.note(en-US,BTS.10).gifNote
      In Solution Explorer, notice that three schemas (MSH_25_GLO_DEF.xsd, ACK_24_GLO_DEF.xsd and ACK_25_GLO_DEF.xsd) are included in the project.

  3. Assign a Strong Key file to the project and deploy.

    1. In Solution Explorer, right-click the BTAHL7V2XCommon project and select Properties.
    2. In left pane of the BTAHL7V2XCommon Property Pages page, click Assembly.
    3. In the right pane, scroll down to the Strong Name section, click the field to the right of Assembly Key File, and then click the ellipses ().
    4. In the Assembly Key File dialog box, navigate to C:\BizTalk HL7 Dev\MyKeyFile.snk, and then click Open.
    5. To save changes, click OK.
  4. Build and deploy the project.

    1. In Solution Explorer, right-click the BTAHL7V2XCommon project, and then select Build. The build results are displayed in the Output window.
    2. Right-click the BTAHL7V2XCommon project and select Deploy. The build results are displayed in the Output window.
    3. On the File menu, select Save All to save your work.
  5. Add the BTAHL7V231Common Project to the solution. The schemas in this project are common to all message types in version 2.3.1.

    1. In Solution Explorer, right-click the Test Solution point to Add, and then select New Project.
    2. In the Add New Project dialog box, navigate to BizTalk Projects.
    3. In the Templates pane, select BTAHL7V231Common Project.
    4. In the Name field type BTAHL7V231Common as the project name and save it to the C:\BizTalk HL7 Dev\Test Solution folder.
      Click OK to open the new project.
      In Solution Explorer, notice that three schemas (datatypes_231.xsd, segments_231.xsd, and tablevalues_231.xsd) are included in the project.
  6. Assign a Strong Key file to the project.

    1. In Solution Explorer, right-click the BTAHL7V231Common project and select Properties.
    2. In left pane of the BTAHL7V231Common Property Pages page, click Assembly.
    3. In the right pane, scroll down to the Strong Name section, click the field to the right of Assembly Key File, and then click the ellipses ().
    4. In the Assembly Key File dialog box, navigate to C:\BizTalk HL7 Dev\MyKeyFile.snk, and then click Open.
    5. Click OK to save changes.
  7. Build and deploy the project.

    1. In Solution Explorer, right-click the BTAHL7V231Common project and select Build.
    2. Right-click the BTAHL7V231Common project, and then select Deploy.
    3. To save your work, on the File menu, select Save All.
  8. Add a reference to the project that is going to contain the message structure schemas.

    1. In Solution Explorer, select the ADT_Test project.
    2. Right-click References, and then select Add a Reference.
    3. In the References dialog box, click Projects tab, and then select BTAHL7V231Common.
    4. Click OK to close the dialog box.
  9. Add the message-specific schema to the project.

    1. In Solution Explorer, select ADT_Test, right-click and select Add New Item.
    2. In the Add New Item dialog box, select BTAHL7Schemas, in the Templates pane, click BTAHL7 Schemas, and then click Add.
    3. From the Version drop-down menu, select 2.31. From the Message Type drop-down menu, select ADT. For Trigger Event, select A01. To add the schema to your project, select Finish.
    4. To close the dialog box, select Cancel.
      In Solution Explorer, notice that the ADT_A01_231_GLO_DEF.xsd schema has been added to the project.
  10. Assign a Strong Key file to the project.

    1. In Solution Explorer, right-click the ADT_Test project, and then select Properties.
    2. In left pane of the ADT_Test Property Pages page, select Assembly.
    3. In the right pane, scroll down to the Strong Name section, click the field to the right of Assembly Key File, and then click the ellipses ().
    4. In the Assembly Key File dialog box, navigate to C:\BizTalk HL7 Dev\MyKeyFile.snk, and then click Open.
    5. To save changes, click OK.
  11. Build and deploy the project.

    1. In Solution Explorer, right-click the ADT_Test project, and then select Build.
    2. Right-click the ADT_Test project, and then select Deploy.
    3. To save your work, on the File menu, select Save All.
  12. Create the necessary receive port and receive location to send the HL7 message through BizTalk Server.

    1. Right-click Receive Ports, and then select Add Receive Port.
    2. In the Create New Receive Port dialog box, click OK to accept the default One-Way Port receive port.
    3. In the One-Way Receive Port Properties dialog box, type fromHIS in the Name box, and then click OK.
    4. Right-click Receive Locations, and then select Add Receive Location.
    5. In the Receive Location Properties dialog box, type ReceiveHIS in the Name box.
    6. In the Transport Type box, select File from the drop-down list.
    7. In the Address URI box, click the ellipses ().
    8. In the File Transport Properties dialog box, type C:\BizTalk HL7 Dev\Scenario Test Folders\fromHIS in the Receive Folder box. Change the file mask to *.txt and then click OK.
    9. In the Receive Handler box, select BizTalkServerApplication.
    10. In the Receive Pipeline box, select BTAHL72XPipelines.BTAHL72XReceivePipeline (Microsoft.Solutions.BTAHL7.HL72fDasm).
    11. Click OK to close the Receive Location Properties dialog box.
    12. Right-click the ReceiveHIS receive location, and then select Enable.
  13. Create the necessary send ports to send the HL7 message through BizTalk Server and to capture the original message as well as the generated acknowledgment.

    1. In BizTalk Explorer, right-click Send Ports, and then select Add Send Port.
    2. To accept the default Static One-Way Port, click OK.
    3. In the Static One-Way Send Port Properties page, type toNewSys in the Name box.
    4. In the Transport Type box, select File from the drop-down list.
    5. In the Address URI box, click the ellipses ().
    6. In the File Transport Properties dialog box, type C:\BizTalk HL7 Dev\Scenario Test Folders\toNewSys in the Destination Folder box. Next change the file mask extension to %MessageID%.txt and then click OK.
    7. In the left pane, click the Send node.
    8. In the Send Pipeline box, select BTAHL72XPipelines.BTAHL72XSendPipeline (Microsoft.Solutions.BTAHL7.HL72fAsm).
    9. In the left pane, click the Filters & Maps>Filters node.
    10. In the right pane, under the Properties column drop down, select BTAHL7Schemas.MSH3_1.
      This is because, in the ACK, the MSH3.1 and MSH5.1 from the original message are switched.
    11. Under the Operator column, select == and under the Value column, type the publishing system name of HIS.
      Bb981217.note(en-US,BTS.10).gifNote
      This entry is case-sensitive and must match the MSH.3 value in the message.

    12. To close the dialog box, click OK.
    13. Right-click the toNewSys port, select Enlist, and then click Start.
    14. In BizTalk Explorer, right-click Send Ports, and then select Add Send Port.
    15. To accept the default Static One-Way Port, click OK.
    16. In the Static One-Way Send Port Properties page, type ACKs in the Name box.
    17. In the Transport Type box, select File from the drop-down list.
    18. In the Address URI box, click the ellipses ().
    19. In the File Transport Properties dialog box, type C:\BizTalk HL7 Dev\Scenario Test Folders\ACKs in the Destination Folder box, change the file mask to %MessageID%.txt, then click OK.
    20. In the left pane, click the Send node.
    21. In the Send Pipeline box, select BTAHL72XPipelines.BTAHL72XSendPipeline (Microsoft.Solutions.BTAHL7.HL72fAsm).
    22. Click OK.
    23. In the left pane, click the Filters & Maps<Filters node.
    24. In the right pane, under the Properties column drop down, select BTAHL7Schemas.MSH5_1. Then, under the Operator column, select ==. Finally, under the Value column, type the publishing system name of HIS.
    25. To close the dialog box, click OK.
    26. Right-click the ACKs port, select Enlist, and then click Start.
  14. Add party definitions for the sending and receiving parties in the MSH.3 and MSH.5 fields.

    1. In BizTalk Explorer, right-click Parties, and then select Add Party.
    2. In the Add Party dialog box, type HIS as the name.
    3. To close, click OK.
    4. Repeat these steps to add another party definition named NEWSYS.
  15. Configure the incoming party definition for the desired acknowledgment type.

    1. Open the HL7 Configuration Explorer from Start>Programs>Microsoft BizTalk Accelerator for HL7 2.0>BTAHL7 Configuration Explorer.
    2. In the Parties navigation panel, select HIS, and then navigate to the Acknowledgement tab.
    3. Under Acknowledgement Type, select Original Mode.
    4. Select Save.
  16. Test the message for errors by sending through the system.

    1. Copy the file C:\BizTalk HL7 Dev\Scenario test Folders\Test Data\HIS1_ADT^A01.txt to the receive location, C:\BizTalk HL7 Dev\Scenario Test Folders\fromHIS.
    2. Move to C:\BizTalk HL7 Dev\Scenario Test Folders\toNewSys to see the processed message.
    3. Move to C:\BizTalk HL7 Dev\Scenario Test Folders\ACKs to see the generated acknowledgment.
    4. Repeat these steps for C:\BizTalk HL7 Dev\Scenario Test Folders\Test Data\HIS_ADT^A01x.txt. You will notice that no message appears in C:\BizTalk HL7 Dev\Scenario Test Folders\toNewSys. This is because the inbound message does not match the schema, so it is considered invalid. The ACK will indicate the errors: C:\BizTalk HL7 Dev\Scenario Test Folders\ACKs.
    5. Open the BizTalk Server Administration console, and view the Windows Event Log.
    6. Use the Windows Event Log and/or the Acknowledgement to determine which fields are in error.
    7. Note that the error segment indicates that the PV1.2 element contains a value that is not in the element’s table. This means that the value in the message is not included in the list of restrictions for that field.
    8. By selecting the PV1.2 element in the ADT_A01_231_GLO_DEF.xsd schema in the ADT_Test project and opening its properties window, you will notice that the field is limited by Table4.
  17. Identify the needed schema changes.

    1. Double-click the Tablevalues_231.xsd schema in the BTAHL7V231Common Project to open it.
    2. Select Table4 in the schema and open its properties window. Notice that there is no ZZ in the list of allowed values.

The HL7 Receive and Send pipelines is the crux of HL7 processing. When an HL7 message is parsed by the HL7 Disassembler component of the HL7 pipeline (the HL7 DASM), three things happen that are fundamental to HL7 processing.

  • If configured for acknowledgements, or if the MSH.15 and MSH.16 request them, the DASM generates one or more acknowledgements (depending on the configuration or MSH values). If the message is valid compared to the deployed HL7 schema, a positive acknowledgement is generated (an ACK). If the message does not match the deployed HL7 schema, a negative acknowledgement (or NACK) is generated. The ACK/NACK is placed in the BizTalk message box along with the original message.
  • BizTalk Server never rejects the inbound message. Some format of the message is always placed in the message box. If the message matches the deployed HL7 schema, it is parsed into XML. If the message does not match the deployed HL7 schema, it is not parsed; rather, it is placed into the message box in its original format. Data that is not parsed (because it fails validation against the schema) fails when it runs through the HL7 Assembler component (HL7 ASM) in the HL7 Send Pipeline because the HL7 ASM compares the data to its expected schema and tries to serialize it from XML to an HL7 v2 format. If the data is not in an internal HL7 XML format, it will fail in the HL7 ASM component.
  • During parsing, the HL7 DASM breaks the inbound message into three parts: one part for the MSH segment, which the DASM uses for processing instructions; one part for the expected segments in the defined HL7 message (those that are defined by the HL7 standards); and one part for custom segments, or Z segments, which the DASM expects to be at the end of a message (as suggested by the HL7 standards).
    Although the DASM expects the bulk of custom segments to appear at the end of a message (because the standard suggests that they be placed there), it can handle floating Z segments. This is because it is designed to assume that any segment that does not match a segment definition from the message schema is an undeclared Z segment. However, once the DASM finds a floating undeclared Z segment, it assumes that all other segments are Z segments and stops validating them.

The following sections describe how to handle common development needs. When considering how certain development steps happen with HL7 data, it will be helpful to keep these basic steps in mind. This is so because all configuration or BizTalk design steps that are specific to HL7 processing are caused by the basic functionality of the HL7 DASM and ASM components.

This section discusses creating custom schemas.

Why and How You Need To Create Custom Schemas

As discussed earlier, the HL7 Accelerator comes with 1300 schemas that define the HL7 v2 standard as found in the HL7 Organization’s Microsoft Access database. The schemas are provided as a means of jump-starting your integration by providing the definition for expected message formats. However, as also discussed earlier, the reality of HL7 v2 messaging is that very few v2 messages actually conform to the HL7 organization’s published standards. In fact, v2 messages of the same version within an enterprise will likely vary by application. For this reason, most HL7 interface solutions require some customization of the provided HL7 schema.

This section explains the general steps required to customize the HL7 schemas and then contains a detailed tutorial step-through of a sample customization scenario.

Why You Need to Create Custom Schema

The standard schemas that the HL7 Accelerator provides follow a specific naming convention that the parser in the HL7 DASM relies on to match schema with messages as they move through the HL7 Receive Pipeline. As seen in the figure that follows, the schema name contains the message type and version information that are found in the MSH segment. The HL7 parser is coded to match the values found in the MSH with the associated deployed schema by schema name.

Schema names match MSH values
Schema and matching MSH value

Since different applications are likely to send different types of the same message version, you will need to deploy application-specific schemas to ensure proper validation. The easiest way to approach this is to copy the standard schemas and make the necessary alterations.

Create Custom Namespaces

Because of how the HL7 parser matches messages with schema, all HL7 schemas must conform to the expected naming convention. Since schemas are uniquely identified by namespace, the way that customized schemas are differentiated from the standard schemas is by altering the namespace on the customized schemas.

The HL7 parser is designed to check the party configurations for each HL7 message. It reads the MSH.3 and checks for whether a party has been defined. If it has, then the HL7 parser follows the configuration supplied via the HL7 Configuration Explorer.

The standard schemas contain the following namespace: http://microsoft.com/HealthCare/HL7/2X.

Standard namespace in an HL7 schema
Standard HL7 schema

When you customize schema, create a new namespace declaration in the schema. Then, define a party for the sending application, and provide the expected namespace as part of the configuration for that party in the HL7 Configuration Explorer.

Custom namespace in an HL7 schema
Custom HL7 schema

As discussed, sets of four schema are related to define a single message. The set of four comes from the Message Structure schema, which references the Dictionary schema. The Dictionary schema are composed of individual schema for:

  • Segments
  • Data Types
  • Table Values

The more inclusive of each of these schema references the successively smaller ones: the Message Structure schema references the Segment schema, which references the Data Types schema, which finally references the Table Values schema.

When changing the namespace for customized schema, the namespace must be changed in each of the four schemas in a message schema set. Furthermore, since an acknowledgment needs to be created based on the customized schema, a custom Acknowledgement schema needs to be created with the same namespace.

Despite the other namespace changes, do not alter the namespace in the MSH schema. This is because the HL7 parser only looks for a single MSH, the standard one that the HL7 Accelerator provides.

Once the namespaces have been changed, make the necessary alterations to the schema to address the issues raised by the NACK that was generated when running the test message.

Make Necessary Schema Changes

Using the NACK you created as part of your test solution as a guide, identify every instance where your test data does not match the HL7 schema. Typically, you will find that segments contain unexpected elements, or that elements contain unexpected components. When this happens, either alter the Segment.xsd to add an additional element to a segment or alter the DataTypes.xsd to add an additional component to an element.

Bb981217.note(en-US,BTS.10).gifNote
Because the Segment, Data Types, and Table Values schemas contain the definitions for all message types in a particular version, a change to a segment is effective in every message type that includes that segment. Likewise, a change to an element affects every instance of that element in every message type for that version.

Another situation where the data does not match the schema occurs when an element value does not match the restriction list for that element. An example is a situation where a code is used, and that code does not appear in the table values for that particular element or component. When this occurs, identify the controlling table value, and add the value that appears in the data to the table. The detailed steps that follow in this section will help you through this exercise.

Bb981217.note(en-US,BTS.10).gifNote
Table data validation can be turned off from the HL7 Configuration Explorer. So, if the only way your data differs from the HL7 schema is in terms of restriction lists, and you do not wish to have the validation occur at this level at all, turning off data validation through the HL7 Configuration Explorer is easier than customizing your schema.

The accelerator Help documentation provides detailed guidelines on making changes to the schema. It is important to read the Help files when making changes because the elements and segments follow a proscribed naming convention. Because the standard identifies segments that vary from the standard as Z segments, the Help documentation concerning creating declared Z segments applies to any alterations that you need to make to a segment.

The basic naming convention is:

  • Segments are identified with a three-letter code, then an underscore, then the name of the segment such as PID_PatientIdentificaitonSegment. To create a declared Z segment, your segment code should start with a Z.
  • Elements are identified with the segment’s three-letter code, then an underscore, then a number that identifies the element’s position within the segment, then an underscore and the name of the element. An example is PID_1_SetId for the first element in the PID segment and PID_2_PatientId for the second element in the PID Segment. The positional numbering always starts with 1.
  • Components are identified by their Data Type code from the HL7 specifications, then an underscore, then a number identifying the component’s position within the element, then an underscore and the component name. An example is CX_0_Id and CX_1_CheckDigit for the first and second components of the PID_2_PatientId element. The positional numbering always starts with 0.

Click-Through Steps for Customizing Schema

The following steps detail how to create custom schema.

To customize schema
  1. Add a solution to contain the Common schema, ACK, and message structure schema for the version you are processing.

    1. Add a New Blank Solution by going to File>New>Project, and name the solution HIS_CustomSchema.
    2. In the Location box, enter C:\BizTalk HL7 Dev.
    3. In the Solution Name box, select Create Now, name it CustomSchema and then click the Create New Directory box.
    4. Right-click the solution, click Add a New Project, add the BTAHL7V231Common project, and then name it HIS_231CommonProject.
    5. Right-click the solution, click Add a New Project, add the BTAHL7V2XCommon project, and then name it HIS_ACK_Schema.
    6. Right-click the HIS_Custom_Schema project, and then add the ADT_A01_231_GLO-DEF.xsd schema to it by selecting Add New Item>BTAHL7 Schema and selecting the proper schema from the dialog box.
  2. Change the namespaces in all of the schema.

    1. Select the Tablevalues_231.xsd schema in the HIS_V231Common project.
    2. Right-click it, and then select Open With.
    3. Select Add, click Browse next to the Program entry, browse to C:\WINDOWS\Notepad.exe, and then click Open.
    4. Name the entry Notepad and click OK.
    5. In the Open With dialog box, select Notepad to open the schema for editing.
    6. In Notepad, select Edit>Replace, find all references to microsoft.com/HealthCare and replace them with HIS. Save the file and close.
    7. Repeat these steps with the following schema in this exact order:
      datatypes_231.xsd
      segments_231.xsd
      ADT_A01_231_GLO_DEF.xsd
      ACK_24_GLO_DEF.xsd
      ACK_25_GLO_DEF.xsd
  3. Make the needed schema changes.

    1. Double-click the Tablevalues_231.xsd schema in the HIS_231Common Project to open it.
    2. Select Table4 in the schema, and then open its Properties window.
    3. Select the browse ellipsis in the Enumeration setting.
    4. Add a ZZ to the table. To save your change, click OK.
  4. Assign a Strong Key file to the project and deploy.

    1. In Solution Explorer, right-click the HIS_231Common project, and then click Properties.
    2. In left pane of the HIS_231CommonProject Property Pages page, click Assembly.
    3. In the right pane, scroll down to the Strong name section, click the field to the right of Assembly Key File, and then click the ellipses (…).
    4. In the Assembly Key File dialog box, navigate to C:\BizTalk HL7 Dev\MyKeyFile.snk, and then click Open.
    5. To save changes, click OK.
    6. Repeat these steps for every other project in the solution.
  5. Build and deploy the project.
    It is important to build the project with the Common schema before the project with the Message Structure schema because the Message Structure schema references the Common schema.

    1. In the Solution Explorer window, right click the HIS_231Common Project project, and then select Build.
    2. Right-click the HIS_231Common Project, and then select Deploy.
    3. Repeat these steps for the HIS_CustomSchema project and the HIS_ACK_Schema project.
  6. Add party definitions for the sending field.

    1. In BizTalk Explorer, right-click Parties, and then select Add Party.
    2. In the Add Party dialog box, type HIS as the name.
    3. To close, click OK.
  7. Configure the incoming party definition:

    1. Open the HL7 Configuration Explorer from Start>Programs>Microsoft BizTalk Accelerator for HL7 2.0>BTAHL7 Configuration Explorer.
    2. In the Parties navigation panel, select HIS, and then navigate to the validation tab.
    3. In the Schema Namespace field, add the custom namespace http://HIS/HL7/2X, and then click Save.
  8. Restart the BizTalk service.

  9. Test your solution.

    You are now ready to test your solution by copying the C:\BizTalk HL7 Dev\Scenario Test Folders\Test Data\HIS_ADT^A01x.txt file into the C:\BizTalk HL7 Dev\ Scenario Test Folders\fromHIS directory and seeing if the message is processed.

Bb981217.note(en-US,BTS.10).gifNote
As of the writing of this paper, there is a known issue with the HL7 Accelerator v1.3 not being able to generate application acknowledgements based on messages that use customized schema. If you follow the preceding steps and receive error messages about not being able to locate the acknowledgement schema, contact Microsoft Support for the appropriate fix.

The schemas that the HL7 Accelerator provided were generated from the Microsoft Access database of the HL7 organization. Because of this, the HL7 Accelerator does not supply schema for versions that were not finalized as of the release of the product, such as v2.5 or v2.6. The HL7 Accelerator also does not supply schema for message types that are not defined by the standard.

It is expected that Microsoft will release the tool that it used to generate the schema from the Access database with the upcoming BizTalk Server 2006 R2 release. Once that happens, you will be able to generate any schema that you desire from the Access database. Presumably, you will be able to alter the database and generate the schema directly, thus eliminating the customization steps that were just defined.

However, until the availability of that tool, you can process newer version or custom type messages by customizing an existing message schema. The preceding steps define how to handle message body customization, but when dealing with a newer version or a custom message type, you will also need to customize the MSH Segment schema. This is required because the HL7 DASM reads the MSH segment to determine the message body schema to use for parsing.

Customizing the MSH Segment

When customizing the MSH segment, you will not use a custom namespace as you do with other HL7 schema. This is because the HL7 DASM is coded to look for the MSH Segment schema that contains the standard namespace. That means that you will only ever have one MSH segment deployed. When you need to make changes to the schema, you should remember that your changes will have a global effect on every message received.

As discussed earlier, the HL7 DASM uses the MSH segment to determine all processing instructions. The values that appear in the MSH.9 identify the message event and type. Those elements in the MSH schema are restricted to be the message event (MSH.9.1) and type codes (MSH.9.2) that are defined in the HL7 v2 standard. If you are using a code that is not defined in the standard, you must add the codes that are contained in your message to the restriction list for both the MSH.9.1 and the MSH.9.2. You can do this directly by accessing the property settings for the element in the MSH and adding the desired value to the enumeration list for the element.

You can also customize the structure of the MSH by adding components to an element if need be. When you do that, however, you need to follow the same naming convention as all elements and components in the schema.

Customization Needed for Newer Versions

If you are processing a message version such as 2.5 or 2.6, you need to add those values to the restriction list for the MSH.12. When processing a custom schema for version 2.5 or 2.6, you should also create a custom message structure schema that has the naming convention that the DASM is looking for, the combination of the MSH.9 and MSH.12 that was discussed earlier.

When creating a custom, version specific schema, you should create the custom version-specific dictionary schema, so that you can accommodate any version-specific changes to segments and data types or table values. To create these custom schemas, follow the same steps that were detailed earlier for creating application-specific schema. When following these steps, remember that you must customize the acknowledgment schema also.

Once you have customized the MSH Segment to include the new message version in the MSH.12 and have deployed schema with the version-specific name and custom namespaces, you can determine the extent of the necessary schema changes. Do this by running the data against the schema as a test solution. When processing a version 2.5 or 2.6 message, take advantage of the backwards compatibility functionality of HL7 v2 messages; most likely, there will only be a few necessary schema changes for your particular message types.

Bb981217.note(en-US,BTS.10).gifNote
Microsoft does not officially support this approach. It is offered here only as an alternative workaround.

Although you need the BizTalk Accelerator for HL7 to process HL7 data correctly, remember that you have access to all the basic components of BizTalk Server also. That means that you can send the data through maps or orchestrations as needed. Given the varied data structures of line-of-business applications, the odds are that you will need to transform your HL7 data into a new shape or that you will need to create HL7 data from an old shape. Use BizTalk maps to accomplish these needs.

The schema that you use for HL7 data is the message schema you deployed earlier in this paper. That message schema defines the segment structure for only the body of the message. (Remember, the MSH segment has its own schema.) Therefore, when mapping HL7 data, you only have access to the body of the message. When mapping from HL7 data, this generally is not an issue because the body of the message contains everything in the message header segment, except the sending and receiving system identifiers. However, when mapping to HL7, take some extra steps to assign an MSH segment to the beginning of the message body that your map creates.

Mapping HL7 Formatted Data to Non-HL7 Formatted Data

When mapping from HL7 data to a new format, use the HL7 message schema that matches your input data as the Data Source schema. Then use a schema that defines your desired output as your Destination schema. Once both are defined, you can drag and drop HL7 field components to the appropriate output element, using Functoids to alter the data as necessary.

A map with H7 data as input creating non-HL7 data
H7 to non-H7 data map

Once you are satisfied with your map output, you are ready to deploy the map project. To do this, first add an assembly key file to the project, then select Build and Deploy. Once deployed, the map can be called via a receive port, as part of an orchestration Transform shape, or via a send port.

Bb981217.note(en-US,BTS.10).gifNote
The following steps are for basic mapping based on a single input schema to a single output schema. Therefore, they do not show how you can access your MSH segment as well as the body of your message in a single map. That can be configured through calling a map via an orchestration. For specific steps, contact info@partner2learn.com.

Bb981217.note(en-US,BTS.10).gifNote
Because BizTalk Server relies on XML data for map processing, all maps called via a send port occur on the data before the ASM serializing. This is helpful to keep in mind when coordinating map outputs.

Click-Through Steps for Basic Mapping– HL7 Data to Non-HL7 Data

To map HL7 data to non-HL7 data
  1. Add a project to your solution to hold your map.

    All schema used in a map must be included or referenced in the same project as the map.

    1. Open the Test Solution.sln file from C:\BizTalk HL7 Dev\Test Solution by going to File>Open>Project/Solution.
    2. Right-click Test Solution, and then select Add>Existing Project.
    3. Add the OrderMapping.btproj project from C:\BizTalk HL7 Dev\Artifacts\Order Mapping.
    4. Right-click the OrderMapping project, and then add a reference to the BTAHL7V231Common project.
  2. Create the BizTalk map.

    1. Add a New Item to the OrderMapping project. Select Map Files, and then name the map ORM_to_Orders.
      BizTalk Mapper opens and the new map (ORM_to_Orders) is added to Solution Explorer.
  3. Open the source and destination schemas.

    This allows you to view the structure of the source and destination schemas.

    1. In the Source Schema pane (left side), click Open Source Schema.
    2. In the BizTalk Type Picker, expand Schemas, select ORM_O01_231_GLO-DEF.xsd, and then click OK.
    3. In the Destination Schema pane (right side), click Open Destination Schema.
    4. In the BizTalk Type Picker, expand Schemas, select OrderMapping.Orders, and then click OK.
  4. Create links between fields.

    1. Create links between fields in the Source schema and the Destination schema according to the following table.

      Source Schema Node Destination Node

      Sequence (first one you see)

      --

      PID.5_PatientName

      XPN.0_FamilyLastName

      XPN.0.0_FamilyName

      PatientLastName

      PID.5_PatientName

      XPN.1_GivenName

      PatientFirstName

      PID.5_PatientName

      XPN.2_MiddleInitialOrName

      PatientMiddleInitial

      PID.8_Sex

      Gender

      PID.7_DateTimeOfBirth

      Birthdate

      PID.2_PatientId

      CX.0_Id

      PatientIdentifier

      Sequence( last one you see)

      --

      ORC.1_OrderControl

      OrderType

      ORC.15_OrderEffectiveDateTime

      OrderDate

      Sequence (first you see under current Sequence)

      Choice

      --

      OBR.4_UniversalServiceId

      CE.0_Identifier

      Procedure Code

      OBR.4_UniversalServiceId

      CE.1_Text

      Procedure Name

  5. Validate the map.

    1. In Solution Explorer, right-click the ORM_to_Orders map.
    2. Select Validate Map.
  6. Build and deploy the map.

    1. On the File menu, click Save All.
    2. Build and deploy the OrderMapping project.
  7. Add a send port that subscribes to the ORM files, and that will convert the ORM to Order.xml.

    1. In BizTalk Explorer, add a Send Port named toOrderSys.
    2. Set the Transport to File and URI to C:\BizTalk HL7 Dev\ Scenario Test Folders\toOrderSys.
    3. Set the Send Pipeline to Microsoft.BizTalk.DefaultPipelines.XMLPipeline.
    4. Select Filters&Maps>Filters and in the right pane, under the Properties column drop-down list, select BTAHL7Schemas.MSH5_1.
    5. Under the Operator column, select == and under the Value column, type the publishing system name of OrderSys.
    6. Under Filters&Maps>Maps, click in the Map to Apply column and select OrderMapping.ORM_to_Orders from the drop-down list. Click in the Source and Destination columns to see the values fill in.
    7. To create the send port, click OK.
    8. Click Enlist, and then click Start.
  8. Add a receive location for data from the application sending ORM files – ORMsys.

    1. In BizTalk Explorer, add a receive port named fromORMsys. Accept all the defaults.
    2. Under the fromORMsys receive port, add a receive location named ReceiveORM.
    3. In the Transport Type box, select File from the drop-down list.
    4. In the Address URI box, click the ellipses (…).
    5. In the File Transport Properties dialog box, type C:\BizTalk HL7 Dev\Test Solution\Scenario Test Folders\fromORMsys in the Receive Folder box.
    6. Change the file mask to *.txt, and then click OK.
    7. In the Receive Handler box, select BizTalkServerApplication.
    8. In the Receive Pipeline box, select HTAHL72XPipelines.BTAHL72XReceivePipeline (Microsoft.Solutions.BTAHL7.HL72fDasm).
    9. Click OK to close the Receive Location Properties dialog box.
    10. Right-click the ReceiveORM receive location, and then click Enable.
  9. Test the scenario.

    1. Copy ORM^O01.txt from C:\BizTalk HL7 Dev\Scenario Test Folders\Test Data to C:\BizTalk HL7 Dev\Scenario Test Folders\fromORMsys.
    2. To verify that your data was processed, move to C:\BizTalk HL7 Dev\Scenario Test Folders\toOrderSys.

Creating HL7 Formatted Data with an Orchestration

As discussed earlier, the V2.x message schemas do not contain the MSH segment because the HL7 Accelerator parses that segment differently. The HL7 Accelerator treats the V2.x message structure as three distinct units:

  • The message header (MSH segment)
  • The message body (all standard-defined segments after the MSH segment)
  • Z-segments

The impact of this is that when using a map to create or modify a V2.x HL7 message structure, you need to use an orchestration to assign the various message structure parts into a single structure for outbound processing through the HL7 Send Pipeline. You need to use the HL7 Send Pipeline when sending HL7 V2.x data outbound from BizTalk Server because it contains the HL7 Assembler, which serializes the data from BizTalk Server’s internal XML structure into the flat file 2.x structure.

Bb981217.note(en-US,BTS.10).gifNote
When using BizTalk Server to create or modify an HL7 message, you must use an orchestration. The following steps detail how to manually create the MSH and assign it to the body of your message. You can also use a map to create the MSH if you choose. Either way, you must use an orchestration because that is the only way to create the multi-part message that the HL7 Assembler expects.

To configure an orchestration to assign the three parts of a V2.4 structure into a single unit, add a new project to your solution, and then add an orchestration as a new item into the project. Once this is complete, add references to the V2.4 message schema (including V2.4 dictionary schema) as well as to your map. Also, add a reference to the Microsoft.Solutions.BTAHL7.HL7Schemas.dll that is located in <HL7 Accelerator install directory>\Program Files\Microsoft BizTalk Accelerator for HL7 2.0\Bin.

Because orchestrations are used to configure business processes, there are many necessary configuration steps involved in designing an orchestration. The following steps are necessary to receive a non-HL7 message into an orchestration:

  • Call a map to transform the data into a V2.31 message structure.
  • Assign an MSH segment to the V2.31 message body.
  • Send the completed, unified V2.31 message from the orchestration.

Once it leaves the orchestration, the V2.31 message is routed through a send port using the HL7 Send Pipeline, so that the data that leaves BizTalk Server will be a V2.31 formatted flat file.

Click-Through Steps for Orchestration Configuration

Prerequisite: Before setting up Orchestration Configuration (RFH 2591), KB article 941261 must be applied. You can find the article and its associated update at http://go.microsoft.com/fwlink/?LinkId=106338.

To create and configure an orchestration project
  1. Open the test solution because you will add a project to the solution to hold the orchestration. You need to reference the projects that contain the schemas you need in the orchestration.

    1. Open the Test Solution.sln file from C:\BizTalk HL7 Dev\Test Solution by going to File>Open>Project/Solution.
    2. Right-click Test Solution, and then click Add an Existing Project.
    3. Select the CreateADT^A01 project from C:\BizTalk HL7 Dev\Artifacts\CreateADT^A01.
    4. Right-click the CreateADT^A01 project, and then click Add a Reference to the following projects: BTAHL7V231Common and ADT_Test.
    5. Before closing the dialog box, add a reference to the .dll that the HL7 ASM uses to validate: C:\Program Files\Microsoft BizTalk Accelerator for HL7 2.0\Bin\Microsoft.Solutions.BTAHL7.HL7 Schemas.dll. Do this by clicking the Browse tab in the Add Reference dialog box, browsing to the above directory, and then clicking the CreateADT^A01 project.
  2. Create a new orchestration.

    1. In Solution Explorer, right-click the CreateADT^A01 project, point to Add, and then select Add New Item.
    2. In the Templates pane, click BizTalk Orchestration.
    3. In the Name field, type CreateA01fromREG.odx.
    4. Click Open to create a new orchestration file.
  3. Create the business process workflow.

    The Receive shape starts the orchestration by receiving a message from a port (you will configure the port later).

    The Activate property must be set to true before an orchestration can be started.

    The Transform shape is used to move data from one message to another by using a predefined map.

    The Construct shape will be used to configure a message transform later.

    The Send shape is used to send a message to a port.

    1. If the toolbox is not docked on the left side, on the View menu, click Toolbox.
    2. To display the shapes available for creating an orchestration, in the toolbox, click BizTalk Orchestrations.
    3. From the Toolbox, drag the Receive shape to the design surface, and drop it on the area labeled Drop a shape from the toolbox here.
    4. In the Properties window (on the bottom-right of your screen), click the Name property to change the name of the receive shape to ReceiveREG, and then press Enter.
    5. In the Properties window, change the Activate property to True.
    6. Drag a Transform shape under the ReceiveREG receive shape, and name it A01_Body_Creation.
    7. Select the ConstructMessage_1 shape that is around the A01_Body_Creation Transform shape, and name it ConstructA01Body.
    8. Drag a Message Assignment shape under the ConstructA01Body shape, and name it A01FinalConstruct.
    9. Select the ConstructMessage_1 shape that is around the A01FinalConstruct Message Assignment shape, and name it Construct3PartHL7Message.
    10. Drag the Send shape from the toolbox, drop it under the Construct3PartHL7Message shape, and name it SendADTA01.
    11. On the File menu, click Save All.
To create orchestration variables
  1. Create message variables.

    In this task, you create variable names for message instances represented by the REG and the ADT^A01 schemas. These variable names are used to reference a specific message instance within the orchestration.

    1. In the Orchestration View window, right-click Messages, and then click New Message.
    2. Select the Message_1 and change the Identifier property to REGInstance as the new variable name, and then press Enter.
    3. Select the drop-down list of the Message Type property, expand Schemas, and then select CreateADT_A01.Reg.
    4. Repeat the previous steps to create additional message variables:
      ADTA01body = ADT_A01_231_GLO_DEF.xsd from the Referenced Assembly
      ADT_Test.finalADTA01message = will configure after next step
  2. Create and configure a multi-part message type for the HL7 formatted message.

    1. In the Orchestration View window, move under Types and add a multi-part message type called finalADTA01messageType.
    2. Expand the entry, and then change the Identifier on MessagePart_1 to MSHSegment.
    3. Add two more message parts called BodySegments and ZSegments.
      Bb981217.note(en-US,BTS.10).gifNote
      Every HL7 message in an orchestration is represented as a multi-part message and will have the same three parts defined. You must always name them these exact names and create them in this order: MSHSegment, BodySegments, ZSegments.

      Bb981217.note(en-US,BTS.10).gifNote
      Once you have created and named the message parts, do not rename them. If necessary, delete the old body part, and create a new body part with a new name.

    4. In the Properties window for BodySegments, under Type, select <Select from referenced assembly> to select the ADT_A01_231_GLO_DEF.xsd from the ADT_Test assembly. Make sure that the BodyPart property is set to True.
    5. In the Properties window for MSHSegment, under Type, select .NET Classes, and then click <Select from referenced assemblies>.
    6. In the Select Artifact Type dialog box, in the left pane, click System.Xml.
    7. In the right pane, click XmlDocument, and then click OK.
    8. In the Properties window for ZSegments, under Type, select .NET Classes, then click System.String from the drop-down list.
  3. Configure the finalADTA01 Message variable as the multi-part message type that you just created.

    1. Move to the Messages entry, select finalADTA01Message, and then open its Properties window.
    2. Click Message Type, expand Multi-part Message Types, and then click <ProjectName>.finalADTA01Message.
  4. Configure a variable, which you will define in a message assignment shape shortly.

    1. In the Orchestration View window, right-click Variables, and then click New Variable to create Variable_1.
    2. Click Variable_1, and in the Properties pane, click Identifier, and then type the new name HeaderInfo.
    3. Click Type, and then double-click <.NET Class>.
    4. In the Select Artifact window, in the left pane, click System.Xml.
    5. In the right pane, click XmlDocument, and then click OK.
To configure orchestration shapes
  1. Configure the Transform shape to use the REG_to_ADT map.

    1. On the orchestration design surface, select the ConstructADTbody shape.
    2. In the Properties window, select Messages Constructed property, and then select the ADTA01body check box in the drop-down list.
    3. On the orchestration design surface, click the ADT_Body_Creation transform shape, in the Properties window, click Map Name, and then click the ellipsis (…) button in the attribute field.
    4. In the Transform Configuration dialog box, click Existing Map, and then select the REG_to_ADT map in the drop-down list.
    5. Select Source in the left pane.
    6. Click the empty box under Variable Name, and then select REGInstance from the drop-down box.
    7. Select Destination in the left pane, and then click ADTA01body from the drop-down box.
    8. To save changes, click OK.
  2. Configure the remaining orchestration shapes.

    • Assign the following messages to the appropriate shape by selecting the shape, moving to its Properties window, and then selecting Message:
      ReceiveREG shape = REGInstance
      Construct3PartHL7Message shape = finalADTA01message
      SendADTA01 shape = finalADTA01message
  3. Create an expression for the A01_Final_Construct shape. Because the HL7 ASM in the HL7 Send Pipeline expects a three-part message, you must manually declare what each part is.

    This expression manually places the MSH segment onto the ADT^A01 message that the map created. It does not populate any Z segments.

    1. On the orchestration design surface, select the A01_Final_Construct shape.
    2. In the Properties window, click Expression, and then click the ellipsis (…) to open BizTalk Expression Editor.
    3. Open the file C:BizTalk HL7 Dev\Artifacts\Orchestration Expression.txt and copy its contents into the expression shape, and then click OK.
      Bb981217.note(en-US,BTS.10).gifNote
      The first block of the expression text is an example of a hard-coded XML header. The BTAHL7 ASM requires a header segment. You can customize these header values according to the needs of your environment. The second block of the preceding text defines the three message parts that are required in a multi-part message. BTAHL7 ASM requires a multi-part message. The third block of the preceding text contains the promoted properties that the BTAHL7 ASM examines in order to correctly serialize an XML message into an HL7 flat-file message.

To create and configure ports
  1. Create one receive port and one send port. The receive port is used to receive the REG.xml file from the REG system. The send port will be used to send the ADT^A01 message to the toHIS folder.

    1. Drag the Port shape from the Toolbox to the Port Surface on the left side of the design surface, and drop the shape so that it is aligned vertically with the ReceiveREG shape.
    2. In the Port Configuration Wizard, click Next.
    3. On the Port Properties page, type ReceiveREGPort in the Name field, and then click Next.
    4. On the Select a Port Type page, type ReceiveREGPorttype in the Port Type Name field, and then click Next.
      This scenario uses the default communication pattern (One-Way) and default access restrictions (Internal).
    5. On the Port Binding page, click Next to accept the default values, and then click Finish.
    6. Repeat the previous steps to create the send port using the following parameters.

      For This Do This

      Port Properties

      Name:

      SendADT_A01

      Port Type Name

      SendADT_A01type:

      Leave the default communication pattern (One-Way) and access restrictions (Internal).

      Direction of Communication

      Change direction to:

      I'll always be sending messages on this port.

      Port Binding

      Specify Later

  2. Connect the ports to the receive shapes.

    In this task, configure how the messages enter and leave the orchestration.

    1. Connect the ReceiveREGPort to the ReceiveREG Receive shape by selecting the green handle in the ReceiveREGPort and dragging it to the green handle on the ReceiveREG Receive shape.
    2. Repeat the previous steps to connect the send port to the Send shape. Use the following parameters.

      For This Do This

      Action Shape

      SendADTA01

      Message in the Action Shape

      finalADTA01Message

      Send Port connected to the Action Shape

      SendADT_A01

  3. Assign a strong name to the project, build and deploy it.

    1. Assign the C:\BizTalk HL7 Dev\MyKeyFile.snk to the orchestration project.
    2. Click Save All, and then build and deploy the CreateADT^A01 project.
    3. Refresh the BizTalk Management Database and move under Orchestrations in BizTalk Explorer to confirm that the orchestration is listed.
To test the orchestration
  1. Create the physical receive port and location to get the REG.xml file into BizTalk Server.

    You will bind this receive location directly to the orchestration in a later step.

    1. Right-click Receive Ports, and then select Add Receive Port.
    2. To accept the default One-Way Port receive port, in the Create New Receive Port dialog box, click OK.
    3. In the One-Way Receive Port Properties dialog box, type fromREG in the Name box, and then click OK.
    4. Right-click Receive Locations, and then select Add Receive Location.
    5. In the Receive Location Properties dialog box, type REGFileDrop in the Name box.
    6. In the Transport Type box, select File from the drop-down list.
    7. In the Address URI box, click the ellipses (…).
    8. In the FILE Transport Properties dialog box, type C:\BizTalk HL7 Dev\ScenarioTest Folders\fromREG in the Receive folder box, and then click OK.
    9. In the Receive Handler box, select BizTalkServerApplication.
    10. In the Receive Pipeline box, select Microsoft.BizTalk.DefaultPipelines.XMLReceive.
    11. To close the Receive Location Properties dialog box, click OK.
  2. Create the physical send port and location to get the ADT^A01 file out of BizTalk Server.

    You will bind this send port directly to the orchestration in a later step.

    1. In BizTalk Explorer, right-click Send Ports, and then select Add Send Port.
    2. To accept the default Static One-Way port, click OK.
    3. In the Static One-Way Send Port Properties page, type toHIS in the Name box.
    4. In the Transport Type box, select File from the drop-down list.
    5. In the Address URI box, click the ellipses (…).
    6. In the FILE Transport Properties dialog box, type C:\BizTalk HL7 Dev\Scenario Test Folders\toHIS in the Destination Folder box.
    7. Change the file mask extension to .txt and then click OK.
    8. In the left pane, click the Send node.
    9. In the Send Pipeline box, select BTAHL72XPipelines.BTAHL72XSendPipeline (Microsoft.Solutions.BTAHL7.HL72fAsm).
    10. Click OK.
  3. Bind the orchestration to the physical send and receive ports.

    1. In BizTalk Explorer, expand Orchestrations, and then select the CreateA01fromREG.odx orchestration.
    2. Right-click the CreateA01fromREG.odx orchestration, and then select Bind.
    3. In the left pane, select Bind, and then make the following configurations:
      ReceiveREGPort = the fromREG Receive Port
      SendADT^A01 = the toHIS Send Port
    4. In the left pane, select Host, configure BizTalkServerApplication in the right pane, and then click OK.
    5. Right-click the CreateA01fromREG.odx orchestration again, select Enlist, and then click Start. This will bring up a wizard. Select all boxes to start all necessary ports at the same time.
  4. Test the orchestration.

    1. Once the orchestration is started, copy the file: C:\BizTalk HL7 Dev\Scenario Test Folders\Test Data\REG.xml into the C:\BizTalk HL7 Dev\Scenario Test Folders\fromREG folder.
    2. Once the file is removed from the C:\BizTalk HL7 Dev\Scenario Test Folders\fromREG folder, check to see that the ADT^A01 file was created in the C:\BizTalk HL7 Dev\Scenario Test Folders\toHIS folder.

Sending HL7 Data through an Orchestration

When your HL7 processes involve only basic transformation of HL7 data into a non-HL7 format, you can accomplish your goal by writing a map that translates the body segments into a new format (as discussed earlier). This map can then be called via a receive port or send port depending on your processing needs.

Because the new shape does not utilize the HL7 Assembler, functionally speaking, you do not care that the HL7 DASM originally broke the message into three parts. This is because your map applies to the Body Segments, and the new data will use a different pipeline than the HL7 Send Pipeline.

When sending HL7 data through an orchestration, however, you do care about the fact that the HL7 DASM splits the original message into three parts because this means that the orchestration will actually receive a three-part message. Therefore, a multi-part message type must be defined in order for the data to be handled correctly.

Use the same multi-part message definition that you use when creating HL7 data with an orchestration. As detailed in the last section, when creating the multi-part message type, you must create the included parts in an exact order, using the case-specific names of:

  • MSHSegment (created first)
  • BodySegments (created second)
  • ZSegments (created last)

Once all three types under the multi-part message type for your HL7 message are defined, create a message definition and configure it as a multi-part message type, selecting your newly defined definition. Then configure the orchestration Receive shape with this message definition.

If you plan on calling a map that uses the BodySegments part of the message in the orchestration, you must also create a message definition in the orchestration for the BodySegments and associate it with the appropriate Message Structure schema.

Bb981217.note(en-US,BTS.10).gifNote
Because this schema references the Version Dictionary schema, make sure that your project includes references to the version-specific schema as well. After the orchestration receives the multi-part message via a Receive shape, add a Message Assignment shape that associates the Body Segment message definition you just defined with the BodySegments part of the multi-part message. Once this is done, you can then work with the Body Segment message for your other orchestration processing.

Click-Through Steps for Sending HL7 Data to an Orchestration

Prerequisite: Before setting up Orchestration Configuration (RFH 2591), KB article 941261 must be applied. You can find the article and its associated update at http://support.microsoft.com/kb/941261.

To create and configure an orchestration project
  1. Open the test solution because you will add an orchestration to the Order Mapping project that will receive the ORM^O01.

    1. Open the Test Solution.sln file from C:\BizTalk HL7 Dev\Test Solution by going to File>Open>Project/Solution.
    2. Select the OrderMapping project and add a reference to the .dll that the HL7 ASM uses to validate: C:\Program Files\Microsoft BizTalk Accelerator for HL7 2.0\Bin\Microsoft.Solutions.BTAHL7.HL7 Schemas.dll. Do this by clicking the Browse tab in the Add Reference dialog box, and then browsing to the above directory.
  2. Create a new orchestration.

    1. In Solution Explorer, right-click the OrderMapping project, point to Add, and then select Add New Item.
    2. In the Templates pane, click BizTalk Orchestration.
    3. In the Name field, type ORM_Processing.odx.
    4. To create a new orchestration file, click Open.
  3. Create the business process workflow.

    The Receive shape starts the orchestration by receiving a message from a port (you will configure the port later).

    The Activate property must be set to true before an orchestration can be started.

    The Transform shape is used to move data from one message to another by using a predefined map.

    The Construct shape will be used to configure a message transform later.

    The Send shape is used to send a message to a port.

    1. If the toolbox is not docked on the left side, on the View menu, click Toolbox.
    2. To display the shapes available for creating an orchestration, in the toolbox, click BizTalk Orchestrations.
    3. From the toolbox, drag the Receive shape to the design surface and drop it on the area labeled Drop a shape from the toolbox here.
    4. In the Properties window (on the bottom-right of your screen), click the Name property to change the name of the receive shape to ReceiveORM, and then press Enter.
    5. In the Properties window, change the Activate property to True.
    6. Drag a Message Assignment shape under the ReceiveORM shape, and then name it CallOutBodySegments.
    7. Select the ConstructMessage_1 shape that is around the CallOutBodySegments Message Assignment shape, and then name it AssignORMBodySegments.
    8. Drag a Transform shape under the AssignORMBodySegments Construct shape, and then name the Transform1 shape ORM_to_Orders.
    9. Select the ConstructMessage_1 shape that is around the ORM_to_Orders shape, and then name it CreateOrderMsg.
    10. Drag the Send shape from the toolbox, drop it under the ConstructOrder shape, and then name it SendOrder.
    11. On the File menu, click Save All.
To create orchestration variables
  1. Create message variables.

    In this task, you create variable names for message instances represented by the Orders and the ORM_O01 schemas. These variable names are used to reference a specific message instance within the orchestration.

    1. In the Orchestration View window, right-click Messages, and then click New Message.
    2. Select the Message_1 and change the Identifier property to ORMBodySegments as the new variable name, and then press Enter.
    3. Select the drop-down list of the Message Type property, expand Schemas, and then select BTSHL7Schemas.ORM_O01_231_GLO_DEF.xsd.
    4. Repeat the previous steps to create an additional message variables:
      Order = OrderMapping.Orders.xsd.
      ORM_O01_Message = will configure after next step
  2. Create and configure a multi-part message type for the HL7 formatted message.

    1. In the Orchestration View window, move under Types and add a multi-part message type called ORM_O01_MessageType. Expand the entry, and then change the Identifier on MessagePart_1 to MSHSegment.
    2. Add two more message parts called BodySegments and ZSegments.
      Bb981217.note(en-US,BTS.10).gifNote
      Every HL7 message in an orchestration is represented as a multi-part message and will have the same three parts defined. You must always use these exact names and create them in this order: MSHSegment, BodySegments, ZSegments.

      Bb981217.note(en-US,BTS.10).gifNote
      Once you have created and named the message parts, do not rename them. If necessary, delete the old body part, and create a new body part with a new name.

    3. In the Properties window for BodySegments, under Type, select Schema to select the BTAHL7.ORM_231_GLO_DEF.xsd from the ADT_Test assembly. Make sure that the BodyPart property is set to True.
    4. In the Properties window for MSHSegment, under Type, select .NET Classes, and then click <Select from referenced assemblies>.
    5. In the Select Artifact Type dialog box, in the left pane, click System.Xml. In the right pane, click XmlDocument, and then click OK.
    6. In the Properties window for ZSegments, under Type, select .NET Classes, and then click System.String from the drop-down list.
  3. Configure the ORM_O01_Message variable as the multi-part message type you just created.

    1. Move to the Messages entry select ORM_O01_Message and open its Properties window.
    2. Click Message Type, expand Multi-part Message Types, and then click OrderMapping.ORM_O01_MessageType.ORM_O01_231.GLO_DEF.xsd.
To configure orchestration shapes
  1. Configure the Transform shape to use the ORM_to_Orders map.

    Bb981217.note(en-US,BTS.10).gifNote
    At this point in the orchestration, you are free to design the processing as needed for your solution. This is only being presented here by way of example.

    1. On the orchestration design surface, select the CreateOrderMessage shape.
    2. In the Properties window, select Messages Constructed property, and then select the Order check box in the drop-down list.
    3. On the orchestration design surface, click the ORM_to_Orders transform shape, in the Properties window, click Map Name, and then click the ellipsis (…) button in the attribute field.
    4. In the Transform Configuration dialog box, click Existing Map, and then select the ORM_to_Orders map in the drop-down list.
    5. In the left pane, select Source.
    6. Click the empty box under Variable Name, and then select ORMBodySegments from the drop-down box.
    7. In the left pane, select Destination, and then click Orders from the drop-down box.
    8. Click OK to save changes.
  2. Configure the remaining orchestration shapes.

    To configure your orchestration shapes, assign the following messages to the appropriate shape by selecting the shape, moving to its Properties window and selecting Message:

    ReceiveORM shape = ORM_O01_Message

    AssignORMBodySegments shape = ORMBodySegments

    SendOrder shape = Order

  3. Create an expression for the CallOutBodySegments shape. That assigns the message instance for just the ORM_O01 schema with the BodySegments part of the multi-part message.

    1. On the Orchestration Design surface, select the CallOutBodySegments shape.
    2. In the Properties window, click Expression, and then click the ellipsis (…) button to open BizTalk Expression Editor.
    3. Open the BizTalk Expression Editor, and then type the following expression: ORMBodySegments=ORM_O01_MessageType.BodySegments;
To create and configure ports
  1. Create and configure ports.

    In this task, you create one receive port and one send port. The receive port is used to receive the ORM^O01 message.

    The send port is used to send the new Order message to the toOrderSys folder.

    1. Drag the Port shape from the toolbox to the port surface on the left side of the design surface, and drop the shape so that it is aligned vertically with the ReceiveORM shape.
    2. In the Port Configuration Wizard, click Next.
    3. On the Port Properties page, type ReceiveORMPort in the Name field, and then click Next.
    4. On the Select a Port Type page, type ReceiveORMPorttype in the Port Type Name field, and then click Next.
    5. On the Port Binding page, click Next to accept the default values, and then click Finish.
    6. Repeat the previous steps to create the send port using the following parameters.

      For This Do This

      Port Properties

      Name:

      SendOrderPort

      Port Type Name

      SendOrderPorttype:

      Leave the default communication pattern (One-Way) and access restrictions (Internal).

      Direction of Communication

      Change direction to:

      I'll always be sending messages on this port.

      Port Binding

      Specify Later

  2. Connect the ports to the receive shapes.

    In this task, you configure how the messages enter and leave the orchestration.

    1. Connect the ReceiveORMPort to the ReceiveORM receive shape by selecting the green handle in the ReceiveORMPort and dragging it to the green handle on the ReceiveORM receive shape.
    2. Repeat the previous steps to connect the send port to the send shape. Use the following parameters.

      For This Do This

      Action Shape

      SendOrder

      Message in the Action Shape

      Order

      Send Port connected to the Action Shape

      SendOrderPort

  3. Build and deploy.

    1. Click Save All, then build and deploy the OrderMapping project.
    2. Refresh the BizTalk Management Database and move under Orchestrations in BizTalk Explorer to confirm that the orchestration is listed.
To test the orchestration
  1. Configure the toOrderSys physical send port to not call the ORM_to_Orders map.

    You will bind this send port directly to the orchestration in a later step.

    1. In BizTalk Explorer, right-click the toOrderSys send port, and then select Edit.
    2. Select Filters&Maps>Maps, and then delete the ORM_to_Orders map.
    3. Select Filters&Maps>Filters, and then delete the filter on the port.
  2. Bind the orchestration to the physical send and receive ports.

    1. In BizTalk Explorer, expand Orchestrations, and then select the Order_Processing.odx orchestration.
    2. Right-click the Order_Processing.odx orchestration, and then select Bind.
    3. In the left pane, select Bind, and then make the following configurations:
      ReceiveORMPort = the fromORMsys Receive Port
      SendOrder = the toOrderSys Send Port
    4. In the left pane, select Host, configure BizTalkServerApplication in the right pane, and then click OK.
    5. Right-click the Order_Processing.odx orchestration again, select Enlist, and then click Start. This will bring up a wizard.
    6. Select all boxes to start all necessary ports at the same time.
  3. Test the orchestration

    1. Once the orchestration is started, copy the file: C:\BizTalk HL7 Dev\Scenario Test Folders\Test Data\ORM^O01.txt into the C:\BizTalk HL7 Dev\Scenario Test Folders\fromORMsys folder.
    2. Once the file is removed from the C:\BizTalk HL7 Dev\Scenario Test Folders\fromORMsys folder, check to see that the Orders.xml file was created in the C:\BizTalk HL7 Dev\Scenario Test Folders\toOrderSys folder.

Controlling the Order of Mapped Elements

Currently in BizTalk Server there is a known problem with how BizTalk Mapper generates Extensible Stylesheet Language Transformations (XSLT). This issue causes undesirable output when mapping a complex schema onto itself or when one input complex element node is mapped to more than one output complex node element. Although this issue is expected to be fixed in BizTalk Server 2006 R2, it is easily enough fixed for mappings created in BizTalk Server 2004 or BizTalk Server 2006. This section defines the issue and the solution.

The Issue

Basically, the issue arises with HL7 data when mapping input groups, such as looped segments or repeating elements containing components, to a similar structure on output. Although the mapping commands are correct, the resulting output does not maintain the group structure and simply repeats the group. The resulting output has all the group contents grouped together. This issue is caused by the XSLT code that BizTalk Mapper generates. When the BizTalk engine executes the mapper-generated XSLT, it follows the commands it sees, which cause it to loop through the group contents rather than maintain the group integrity.

For example, if you have the following input:

<Sorted_Input>
<A><one/></A>
<B><two/></B>
<A><one/></A>
<B><two/></B>
</Sorted_Input>

BizTalk Mapper generates XSLT, which builds the following output:

<Bad_Output>
<A><one/></A>
<A><one/></A>
<B><two/></B>
<B><two/></B>
</Bad_Output>

The desired output is shown below:

<Good_Output>
<A><one/></A>
<B><two/></B>
<A><one/></A>
<B><two/></B>
</Good_Output>

The undesirable output is caused by the XSLT code that the BizTalk mapping user interface generates. Basically, BizTalk Server adds a for-each loop to every record; someone writing XSLT manually would have used a single for-each command along with if statements to ensure the elements stayed properly sorted.

To further illustrate this BizTalk Mapper issue, the following is the simplified XSLT that BizTalk Server generates when a map is created to demonstrate the preceding scenario:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
                xmlns:var="http://schemas.microsoft.com/BizTalk/2003/var" 
                xmlns:msxsl="urn:schemas-microsoft-com:xslt" 
                version="1.0"><xsl:output indent="yes"/>
<xsl:template match="/">
<xsl:for-each select="Sorted_Input">
    <Bad_Output>
        <xsl:for-each select="A">
            <A><one><xsl:value-of select="one"/></one></A>
        </xsl:for-each>
        <xsl:for-each select="B">
            <B><two><xsl:value-of select="two"/></two></B>
        </xsl:for-each>
    </Bad_Output>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

Notice the separate for-each statements for A and for B. When the BizTalk engine executes the XSLT code, it executes those statements separately, thus grouping all the A elements and then moving to B and grouping all those elements:

<Bad_Output>
<A><one/></A>
<A><one/></A>
<B><two/></B>
<B><two/></B>
</Bad_Output>

Ideally, this is what BizTalk Server should produce:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
                xmlns:var="http://schemas.microsoft.com/BizTalk/2003/var" 
                xmlns:msxsl="urn:schemas-microsoft-com:xslt" 
                version="1.0"><xsl:output indent="yes"/>
<xsl:template match="/">
<xsl:for-each select="Sorted_Input">
    <Good_Output>
        <xsl:for-each select="A|B">
            <xsl:if test="local-name()='A'">
                <A><one><xsl:value-of select="one"/></one></A>
            </xsl:if>
            <xsl:if test="local-name()='B'">
                <B><two><xsl:value-of select="two"/></two></B>
            </xsl:if>
        </xsl:for-each>
    </Good_Output>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

In this example, notice the combined for-each statement for A and B. When the BizTalk engine executes the XSLT code, it executes the command for each instance of A and B together. Thus, it moves through the first instance of A and then the first instance of B before moving on to the second instance of A and B, and so on. This produces the expected results:

<Good_Output>
<A><one/></A>
<B><two/></B>
<A><one/></A>
<B><two/></B>
</Good_Output>

The Solution

The solution to this issue is to access BizTalk Mapper–generated XSLT and manually alter the for-each statements. Then add the manually adjusted XSLT into your BizTalk project instead of the BizTalk map. When the BizTalk engine executes the assembly, it will execute the XSLT directly and not use BizTalk Mapper to generate XSLT (which it then would execute).

The following are the steps to manually adjust the XSLT and then have BizTalk Server execute the adjusted XSLT rather than the original map.

  1. Create your desired map in BizTalk Mapper.
  2. Validate the map. This causes BizTalk Mapper to generate XSLT.
  3. Open the generated XSLT, and edit the multiple for-each statements for the repeating groups that you wish to control.
  4. Save the edited XSLT.
  5. Back in your BizTalk project, create a new map that contains only the input and output schemas (do not add any mapping commands).
  6. Right-click the mapping grid, and add the path to your saved edited XSLT file as the custom XSLT path.
  7. You can now test the map to confirm your desired results. Once you are satisfied with your results, remove the original map from your project.

Controlling the Flow of HL7 Data Through BizTalk Server

When using BizTalk Server with certain HL7 processing scenarios, it is important to understand how to control the flow of messages through BizTalk Server. This is because BizTalk Server is a First In, Fastest Out processor and some HL7 scenarios require First In, First Out processing. It is expected that BizTalk Server 2006 R2 will include functionality that allows the user to configure BizTalk Server for First In, First Out processing. Until then, however, you can use a combination of acknowledgment, orchestration and port configurations to force BizTalk Server to process on a First In, First Out basis.

The Issue

Fundamentally, BizTalk Server is designed to route and transform messages as quickly and efficiently as possible. Since it follows a publish/subscribe methodology, messages are sent to the message box as soon as they arrive. From the message box, messages are sent to subscribing systems and processes. If messages A and B arrive in close order, the order they are sent out of BizTalk Server depends entirely on the extent of processing each undergoes. Thus, if B is a smaller message that requires less validation or if it goes directly to a send port while A moves through an orchestration, then B will be the first message to leave even though A arrived first. Because of this, BizTalk Server can be described as a First In, Fastest Out processor.

With HL7 processing, there are times when message order matters. A common example is where an emergent patient has a procedure ordered before or simultaneously with the registration being processed. If an ORD message arrives before the ADT message, the destination application will reject the ORD because it does not have an associated patient.

For example, if an HIS system sends an ADT message at the same time that an Order system sends an ORD, one of four things will happen:

  • The ADT arrives first and is processed through BizTalk Server before the ORM. In this case, the destination system does not have an issue.
  • The ADT arrives first but takes longer to process than the ORM, so it leaves second. In this case, the destination system rejects the ORM.
  • The ORM arrives first and is processed through BizTalk Server before the ADT, which causes the destination system to reject the ORM.
  • The ORM arrives first, but takes longer to process than the ADT. Therefore, it leaves second and is processed through BizTalk Server after the ADT. In this case, the destination system does not have an issue.

Although only two of these four possibilities causes problems, that translates to a 50 percent error potential for normal system processing. To avoid this error rate, the basic question becomes how to get a stream of related but out-of-sequence messages back into the correct order, so that they leave BizTalk Server in the correct order.

The Solution

Keeping the messages in order to start with is impossible given the dynamics of multiple systems that send event-based messages. Regardless, even if it could be done, BizTalk Server cannot guarantee that system insert order will be determined by the order that messages arrive because some messages take longer than others to process.

The good news with HL7 processing is that you do not need to provide ordered delivery for the entire message stream. Instead, the order of messages must only be guaranteed for a single patient. It is possible to leverage the fact that the destination system most likely has a resource state engine that controls state on a per-patient basis. Basically, most HL7 systems will fail if the messages that control their state arrive out of order for the resource, which is most likely the patient. The system does not care if messages arrive out of order for separate patients, because the system’s state engine is controlling the state on a per patient basis.

The answer is to introduce an acknowledgement process that makes sure only one message at a time passes through the system. To work, the acknowledgment process must cause the next message to not be sent until the last message is done processing. This is easily accomplished when following HL7’s MLLP transport protocol because it dictates that messages be positively acknowledged before sending a following message.

Next, group the message processing to a single process per patient. In this way, logic can be introduced that stores the received messages and forces them out to the destination system in a desired order. With BizTalk Server, set a correlation value based on a unique resource identifier (such as a Patient ID) found in all expected message types. Create an orchestration to handle the necessary logic for the message processing and configure the orchestration to follow the defined correlation value. In this way, for example, all messages for a single patient are sent into the same orchestration.

Even with logic built into the orchestration to force messages out in a desired sequence, you need to make certain that the messages leave the orchestration in a series rather than as a group. Thus, the final step will be to control the message flow out of the orchestration, so that only one message at a time is sent out. You can do this by enabling delivery notification on the send port to which the orchestration is bound.

Concerns about the Approach

An immediate concern about this approach is that it increases message latency. The amount of time between the message being received by the MLLP adapter and sent out of an orchestration via a send port may increase by a manner of seconds. However, the increased latency is offset by the fact that the delay is only on a per-patient basis.

Since a new process will be initiated for every unique patient, actual system throughput will not be linearly affected by the increased message latency for any one particular patient. It may take longer to get a set of messages through a process than if the messages were simply directly routed to a destination system, but this is offset by the fact that multiple processes will be spawning at any given time. Basically, you may be damming the river a bit, but will be creating multiple downstream channels for the water to flow through, so you do not actually cause the upstream water to rise.

Experience with this approach has shown that you can expect to see message throughput decrease a bit, but it still stays well within acceptable limits. The result is that you can achieve a complete ordered message solution by using basic configurations of the combined functionality that the HL7 Accelerator and BizTalk Server provide.

Bb981217.note(en-US,BTS.10).gifNote
A natural outcome of this approach is that your message box might become overloaded with messages. You can alleviate processing concerns through common message box tuning techniques such as increasing memory, putting multiple message box databases on separate spindles, and isolating the Transaction Log on a separate spindle.

Configuration Steps for Ordered Messaging

The following are the configuration steps necessary to control the flow of HL7 messages through BizTalk Server.

  1. Configure a two-way receive port using the MLLP adapter provided with the HL7 Accelerator. This solution depends on use of the MLLP transport protocol because, under the protocol, a sending system will only transmit future messages once it has received a positive acknowledgment for the prior message.
    Configure BizTalk to produce a single acknowledgment for the message. An Original Mode acknowledgment will work. With acknowledgments configured, BizTalk Server creates a positive acknowledgment (ACK) if the message does not have any parsing errors. If the message does have parsing errors, BizTalk Server creates a negative acknowledgment (NACK).
    When configuring the acknowledgment in the HL7 Configuration Explorer, select the Send Acknowledgement via the Two-Way Receive Port option. This causes ACK/NACK to be transactionally committed to the BizTalk message box along with the original message. Then, the ACK/NACK will be automatically routed to the sending system via the MLLP adapter.
  2. In the HL7 message schema, promote the resource ID value for the destination system. As discussed, this solution works when the state of a destination system is based on a per-patient or unit basis. You will need to identify the value in the incoming message that determines a unique patient or unit for the destination system. With most systems this is the Medical Record Number (MRN) in the message, usually the PID.3. An example of a unit resource instead of a patient resource is a bed management system, where you promote the Bed ID and Hospital ID together.
  3. Create a Correlation Set based on the promoted resource ID. The way to force all messages from a single patient or unit into a single instance of an orchestration is to create a correlation set for a unique value and then configure the orchestration to follow that correlation set. In this way, a single instance of an orchestration initiates for every unique instance of the promoted value. Correlating on the promoted value forces all messages that share the correlated value into the single instance of the orchestration for that value.
  4. Configure an orchestration to process all messages related to the single resource (such as patient or bed). Now is the point where you design and configure an orchestration to process all messages for a single patient (such as a single bed). The process design includes logic that forces the messages out in the desired order. At a minimum, these steps require the configuration discussed earlier for configuring an orchestration to receive HL7 messages.
    Configure the orchestration to only initiate for messages that were able to be parsed by the HL7 DASM. As discussed earlier, all messages, good and bad, will pass through the DASM and be committed to the message box along with their acknowledgment (if configured appropriately). This is how NACKs are guaranteed. When a message is good, it will have been parsed into XML for further processing through BizTalk. However, when a message is bad, by definition, it could not be parsed into XML and so BizTalk will pass it through to the message box in its original HL7 format.
    Thus, if you do not filter for only good messages, an orchestration that is bound to a receive port tries to initiate for every message, good and bad, which only causes processing failures. To avoid this, set a ParseErrors=false filter on the Receive Shape in the orchestration. With this filter, an orchestration only initiates for the messages that passed parsing (the good ones).
  5. Configure a send port using the Passthru pipeline to receive the bad messages. Because HL7 DASM will pass bad messages through to the message box in their original state, you should configure a drop location to remove those messages from the message box. A simple Send Port with a filter set to ParseErrors=true accomplishes this.
  6. Configure the delivery notification on send port(s) that are bound to the orchestration. With delivery notification, you cause messages to move from BizTalk Server to the destination system in a consecutive manner because future messages are only sent once BizTalk Server has confirmed receipt of the present message. In this way, you guarantee that the downstream messages do not flood the destination system, thus confusing its state engine and causing it to reject the messages.

Working with HL7 v2 messages in BizTalk Server can seem challenging because of the combination of knowledge that you as a developer must have. You need to understand the systems that you are working with, the varied structure of your messages, and finally how the HL7 Accelerator complements BizTalk’s already robust capabilities. This paper has detailed the few functional points of the HL7 Accelerator that, when understood, enable you to leverage basic BizTalk functionality for a complete solution.

Summarized, these points are:

  • The HL7 DASM performs its own parsing on the HL7 message based on managed code. The HL7 DASM depends on the HL7 schema being named with a defined naming convention. Also, the DASM can be utilized inside of any custom pipeline, so you are free to create pre- and post-processing on the message as desired.
  • The HL7 DASM is coded to read the MSH segment to determine which schema to use to validate the data. The MSH segment must contain the original Microsoft namespace from the installed schema. If you need to customize MSH values, you must customize the original schema because only one namespace is allowed (and this only one should be deployed for proper processing).
  • You are free to customize the HL7 schema that define the rest of the message beyond the MSH segment, but the names of the schema must remain unchanged. To make the custom schema unique, you will change the namespaces so that only unique namespaces are deployed.
  • When using custom schema to validate data, a custom ACK will be generated. For this reason, the ACK schema’s namespace must match the message schema’s namespace.
  • All data passes through the DASM. ACKs and NACKs are generated by the DASM and placed along with the message in the message box. Good messages are parsed into XML and dropped to the message box along with an ACK. Bad messages are not parsed and are placed in the message box in their original format along with a NACK.
  • Bad data fails in the HL7 ASM because the ASM is designed to serialize the XML into an HL7 v2 format. When data fails in the ASM, it was invalid to start with.
  • When creating an acknowledgement, the HL7 DASM automatically reverses the MSH.3 and MSH.5 values. You can control the values that are placed in the MSH fields in the HL7 Configuration Explorer.
  • Because the HL7 DASM relies on the MSH segment for validation and parsing instructions, it splits the message into three parts: the MSH Segment, the expected message body segments, and then any custom segments, or Z segments. Because Z segments by definition cannot be anticipated, the Z segment part simply expects an XML string.
  • Once split off, you can control the values in the MSH segment through the HL7 Configuration Explorer. If you want to simply route a message through BizTalk Server but have the MSH in the outbound message reflect MSH values, you do not need a map. You simply configure the new values on the MSH tab in the Configuration Explorer.
  • The HL7 ASM expects to receive messages that have been parsed by the HL7 DASM. Accordingly, it expects an HL7 three-part message and is coded to serialize the three parts into a single message. Because of the HL7 ASM coding, the three parts must follow a specific naming convention: MSHSegment, BodySegments, and ZSegments.
  • Processing that relies on the HL7 three-part message requires an orchestration because multi-part messages can only be defined in an orchestration. Thus, if you are converting HL7 data into non-HL7 data, and this not using the HL7 ASM, you can call a map directly from a receive or send port.
    If you are converting, processing, or creating the entire HL7 message, you must use an orchestration to accept or create the necessary three parts. In an orchestration the parts are defined in order: MSHSegment, BodySegments, and ZSegments. The MSHSegment and ZSegments parts can have schemas as a definition if desired; otherwise, they are set as an System XML Document (so you can hard-code the MSH values) and as an XML String, respectively. The BodySegments part must always be set to BodyPart=true and have the message structure schema as a definition.

If you are new to BizTalk Server and would like to understand how to use its components for complete solution design, the book Designing Healthcare Solutions with BizTalk Server 2004, although written for BizTalk Server 2004, is still completely relevant in BizTalk Server 2006. (Casey, J and Redding, E. Designing Healthcare Solutions with BizTalk Server 2004. New Hampshire: Mann Publishing Group, 2004.)

To connect with others in the HL7 BizTalk community, post your question or comment in the public newsgroup for BizTalk Server and the HL7 Accelerator at http://go.microsoft.com/fwlink/?LinkId=91466.

Finally, for further help on developing HL7 Solutions with BizTalk Server, see http://go.microsoft.com/fwlink/?LinkId=91825.

Elizabeth Redding is president and founder of Partner2Learn, Inc., a company that provides BizTalk architectural and implementation services and training on HL7, electronic data interchange (EDI), and healthcare integration projects worldwide. Known for her domain expertise in healthcare as well as integration, Elizabeth has been instrumental through the years in assisting many healthcare companies, both providers and payers, of all sizes with their business process integration strategies. As a Microsoft Certified Partner, her company, Partner2Learn, has worked closely with the BizTalk Accelerator product group for many years and has recently been engaged in several projects that concern the new functionality that BizTalk Server 2006 R2 provides.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2007 Microsoft Corporation. All rights reserved.

Microsoft, BizTalk, and Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.

Show:
© 2014 Microsoft