Getting Started with HL7 v3 and BizTalk Server 2006

Getting Started with HL7 v3 and Biz...

Switch on low bandwidth view

Collapse All

Language Filter

Published: October 2007

Author: Elizabeth Redding

Company: Partner2Learn, Inc.

Applies to: Health Level 7 version 3 (HL7 v3) messaging, BizTalk Server 2006

Download Location for Files: To download the files referred to in this white paper, click here.

HL7 Version 3 Overview

This section provides an overview of Health Level 7 (HL7) v3.

Why the Need for a New HL7 Version?

The first HL7 v2.x versions were created prior to the widespread adoption of formal information modeling techniques. As the standard developed, the flat file, delimited data structure was kept because of backward compatibility concerns. This means that HL7 v2.x does not contain syntactical rules; rather, you must look outside of the actual data, to the written standard, to determine if the message is constructed correctly. Eventually, with the growing awareness of the benefits provided by a more formal approach to information modeling, the fact that HL7 v2.x does not inherently contain information about both message content and message structure has come to be seen as a limitation.

The Health Level 7 (HL7) organization took the opportunity of defining a significantly different version to introduce the concept of data modeling to the standard and selected XML as the preferred form of encoding for the information models.

HL7 v3 constitutes the first real modeling effort by the HL7 organization. In version 3, HL7 data is encoded as XML and contains several layers of data modeling information before the actual message content. Figure 1 below shows an example of an HL7 v3 message.

Figure 1 - Sample HL7 v3 message

<PRPA_IN403001 xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN403001.xsd">
   <id root="1.1.2.3.4.5" extension="5929" assigningAuthorityName="Litware Inc."/>
   <creationTime value="20050303180027"/>
   <versionCode code="V3PR1"/>
   <interactionId root="1.1.6.7.8" extension="PRPA_IN403001" assigningAuthorityName="HL7"/>
   <processingCode code="D"/>
   <processingModeCode code="T"/>
   <acceptAckCode code="AL"/>
   <receiver typeCode="RCV">
     <device classCode="DEV" determinerCode="INSTANCE">
       <id root="1.4.7.8.3"/>
     </device>
   </receiver>
   <sender typeCode="SND">
     <device classCode="DEV" determinerCode="INSTANCE">
       <id root="1.45.6.7.98"/>
     </device>
   </sender>
   <controlActProcess classCode="CACT" moodCode="EVN">
     <subject typeCode="SUBJ" contextConductionInd="false">
       <encounterEvent classCode="ENC" moodCode="EVN">
         <id root="1.56.3.4.7.5" extension="122345" assigningAuthorityName="Maple Hospital Emergency"/>
         <code code="EMER" codeSystem="2.16.840.1.113883.5.4"/>
         <statusCode code="active"/>
         <subject contextControlCode="OP">
           <patient classCode="PAT">
             <id root="1.56.3.4.7.9" extension="55321" assigningAuthorityName="Maple Hospital Patients"/>
             <patientPerson classCode="PSN" determinerCode="INSTANCE">
               <name>
                 <given>Rob</given>
                 <given>P</given>
                 <family>Young</family>
               </name>
               <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
               <birthTime value="19800309"/>
             </patientPerson>
           </patient>
         </subject>
       </encounterEvent>
     </subject>
   </controlActProcess>
</PRPA_IN403001>

The data modeling in HL7 v3 is achieved through the use of a methodology defined by the HL7 organization called HL7 Development Framework (or HDF) and serves to define the structural requirements of the message along with the actual message content. Since the new version was to be independent from the actual message format, and necessarily could not be backward compatible, the HL7 organization took the opportunity to tighten up the standard. Thus, HL7 v3 contains rigid message structure rules that do not exist in HL7 v2.x.

Basically, the HL7 organization’s motivation to develop a new version centered on the need to build a higher quality standard and to overcome built-in limitations of HL7 v2.x. However, because of the detailed new modeling approach and the fact that the standard heavily leverages XML as the format for message encoding, HL7 v3 also has the effect of making it easier to introduce new material into the standard.

The HL7 organization introduced the first normative version of HL7 v3 in late 2005. It was called the Normative Edition 2005. This edition was followed in mid-2006 with the Normative Edition 2006. With these two editions, most of the new standard is complete. However, as with all data standards, there are a few areas left to be determined. The HL7 organization is planning on releasing updates three times a year, in January, May, and September, with a general-use Normative Edition update at the end of each year.

The primary value of HL7 v3 is its explicit data model, clear definitions, and tighter message definitions. The end result should be easier interface creation for end users.

Who Is Using Version 3?

HL7 v3 is still in its infancy in terms of wide-spread adoption. There are two main factors that influence the adoption rate of HL7 v3: deep investment in HL7 v2 interfaces and lack of vendor adoption of the standard. Few healthcare application vendors offer HL7 v3 interface options, so the need for healthcare clinical interfaces to legacy applications remains a significant roadblock to HL7 v3 adoption in areas where HL7 v2 is prevalent, such as in the United States.

In areas where government entities are influencing interfaces between systems that have previously been completely separate, HL7 v3 has become the standard of choice. Healthcare entities in England, Europe, Canada, and Singapore have all launched initiatives to implement version 3.

HL7 v3 adoption in the United States is starting to gain momentum but it is mostly coming from healthcare organizations and vendors who are creating interfaces between external systems and applications that have previously not interfaced. These organizations are leveraging the message content modeling aspect of HL7 v3 to enable robust message hubs as the backbone for their XML-based, service-oriented architectures.

Components of HL7 v3 Messaging

An HL7 v3 message is more complex than an HL7 v2.x message and requires knowledge of several concepts, which are defined below:

Information models: HL7 v3 is built around the HL7 Reference Information Model (RIM). The RIM expresses data structures used across HL7 v3 standards. The RIM is refined to meet the needs of particular domains through the development of Domain Message Information Models (D-MIM). A message or group of related messages can then be further refined by using a Refined Message Information Model (R-MIM) to specialize the RIM.
Data types: Each piece of data contains one or more attributes that define the structure of that particular piece of data. As models are specialized, the assigned data type may be specialized as well.
Vocabulary: Every message refers to a vocabulary specification that indicates the coding systems and value sets used in the message. These give meaning to the code values that are used in the message.
Message specifications: Drawn from a Refined Message Information Model (R-MIM), a message specification contains the attributes needed to support a specific trigger event. Unlike a model, a message specification is “serialized”; that is to say, it has a defined order for its content. This allows messages to be parsed.
Conformance profiles: Published by a trading partner, a conformance profile specifies how a particular message specification is to be implemented in a particular situation. It resolves any remaining optionality in the message specification by indicating what code values are allowed and whether a particular attribute is to be valued.

Figure 2 below shows the relationship between these version 3 messaging components.

Figure 2 - HL7 v3 messaging components

As you can see from the diagram, in HL7 v3, information models of increasing specification (shown from left to right in Figure 2) are used to create a message specification for a particular type of HL7 v3 message, such as a lab result. Along the way, vocabulary and data type specifications are used to define the data that is used in the message. Finally, a conformance profile can also be used to further document the data values to be used in the message.

The developer working on an HL7 v3 solution will most likely not have to be concerned with message modeling activities. Rather, there will be a specifically defined message specification for the interface and implementation guide. Because HL7 v3 messages contain so much metadata, it is not uncommon to see a series of message part-specific schemas that will need to be referenced together via a master schema to form a complete message definition.

Design and Development Considerations for HL7 v3 Interfaces

Because HL7 v3 heavily leverages XML, Microsoft® BizTalk® Server 2006 can handle HL7 v3 interfaces without the need for the BizTalk Accelerator for HL7, which only addresses compatibility and support for the HL7 v2.x standard. To the developer working with HL7 v3 messages in BizTalk Server, the only version-specific design consideration comes from locating and configuring the appropriate message XML schema definition (XSD) and implementing the business rules to perform additional extended validation that XSD alone does not support. Additionally, while there are many ways to send and receive HL7 v3 messages, Web services are quickly becoming the messaging infrastructure of choice. For interfaces relying on Web services for system integration, an HL7 v3 deployment demands the same BizTalk Server process design as with any Web service-based architecture.

Working with HL7 v3 Schemas

Once a message specification is finalized, an XML Schema definition (XSD) is created to define the message type for that particular message specification. Individual schemas are used to describe the various components of an HL7 v3 message. These dictionary-like schemas are then incorporated in the message specification schema by reference. In the end, a particular message specification will involve multiple schemas.

The body of the message is considered the payload. You will most likely have a specific payload schema that defines the message body. Then there are two other message parts involved, each defined by separate schemas: the transmission wrapper and the control act wrapper. Finally, there are schemas that define the common data elements and coding involved in the structure, called Common Message Element Types (CMET) schemas, data types schema, and vocabulary schemas. These schemas will be included by reference in the interaction schema. Because of the number of referenced schemas, the schema for complete message definition will mostly likely be rather complex.

The HL7 v3 Normative Edition 2006 contains XSD for all message types it defines. The schemas are generated through an automatic process from serialized message models that are represented using the Model Interface Format (MIF). The generation process incorporates the XML Implementation Technology Specification (ITS), which defines what XML instances should look like. However, the resulting XSD represents just one of the possible schemas that can be used to validate the same normative HL7 v3 XML instances. This means that the developer is free to alter the schemas as necessary in order to make them work with their desired technology.

Figure 3 - An HL7 v3 message schema

When working with the HL7 v3 schemas from the HL7 Normative Edition 2006 in BizTalk Server 2006, the developer will need to slightly alter the schemas to address issues with how BizTalk Server handles included schemas. Additionally, the developer will need to alter the XSLT that underlies a BizTalk Server map in order to address issues with how BizTalk Mapper compiles complex maps.

This section discusses how to locate the XSD as well as the specific changes that are necessary to work with the HL7 v3 Normative Edition schemas in BizTalk Server 2006.

Locating Version 3 Schemas

Members of the HL7 organization can download the HL7 Normative Edition 2006 directly from the HL7 organization’s Web site. After the file is downloaded and unzipped, the user will find a welcome page that describes the included folders as well as links to the specific details in the Edition.

The naming convention applied to the message artifacts is explained in section 3.1.1 Artifact Identification System of the Edition. This section is handy for the new developer because it helps in the navigation through the provided schemas.

The schemas can be found in subfolders of the Processable folder included with the Edition. The Processable folder contains files that hold computer-processable representations of the normative standards such as schemas, Microsoft Office Visio® designs, databases, MIF, and so on. Two of these subfolders hold the schemas: coreschemas and multicacheschemas.

The multicacheschemas folder contains the schema definitions for message payloads, transmission and control act wrappers, as well as the CMET definitions. Once the payload schema is located, every other included schema will need to be located as well. This can easily be determined by reading the schema (see the example in Figure 4 below).

Figure 4 - Example of included schema declaration in an HL7 v3 message schema

<xs:include schemaLocation="infrastructureRoot.xsd" /> 
<xs:include schemaLocation="MCCI_MT000100UV01.xsd" /> 
<xs:include schemaLocation="MFMI_MT700701UV01.xsd" /> 
<xs:include schemaLocation="PRPA_MT101001UV01.xsd" /> 
<xs:element name="PRPA_IN101001UV01">

Then all the referenced schemas must be examined for referenced schemas.

Figure 5 - All referenced schemas must be examined for their references

<xs:include schemaLocation="infrastructureRoot.xsd" /> 
<xs:include schemaLocation="NarrativeBlock.xsd" /> 
<xs:include schemaLocation="COCT_MT150003UV03.xsd" /> 
<xs:include schemaLocation="COCT_MT150001UV01.xsd" /> 
<xs:include schemaLocation="COCT_MT150002UV01.xsd" /> 
<xs:include schemaLocation="COCT_MT030202UV01.xsd" /> 
<xs:include schemaLocation="COCT_MT030200UV04.xsd" /> 
<xs:include schemaLocation="COCT_MT710000UV01.xsd" />

As will be discussed later in this document, to work with these schemas in BizTalk Server, the message payload schema and all included schemas should be copied into a single folder for development. Once all the included schemas from the multicacheschemas folder are located, you will need to copy the schemas from the coreschemas folder into the development folder as well.

For example, for the message incident: Add New Person (PRPA_IN101001) the PRPA_IN101001UV01 schema references two schemas that each reference other schemas, etc. In the end, the complete schema set for the PRPA_IN101001 message type includes 20 schemas. These must all be copied into a single folder for processing (see the schema set example in Figure 6 below).

Figure 6 - A "schema set" for an HL7 v3 message

Then, once the necessary BizTalk Server schema edits are made, all of the schemas will be added to a BizTalk project (see Figure 7 below).

BizTalk Server-Specific Schema Configuration

When working with the HL7 Normative Edition schemas in BizTalk Server, you will need to make two specific schema modifications. You will also need to modify the XSLT that underlies any BizTalk Server map that references the Normative Edition schemas.

Schema modifications

The first issue that must be addressed with the schemas is that the chameleon includes statements that are used in the datatypes.xsd, datatypes-base.xsd, and voc.xsd schemas and are not supported when compiling schemas in BizTalk Server. A detailed explanation of the issues for the .NET Framework 1.1 can be found in the Microsoft Knowledgebase article at http://go.microsoft.com/fwlink/?LinkId=100742.

The way to address the issue is to include the targetNamespace and default namespace declaration of “urn:hl7-org:v3” in datatypes.xsd, datatypes-base.xsd, and voc.xsd. After adding the namespace declarations, the root element of the schema files should read:

<xsd:schema … targetNamespace="urn:hl7-org:v3" xmlns="urn:hl7-org:v3">

Note
The ellipsis (…) in the code above indicates other attributes or namespace declarations that should be left untouched, while the part in bold is the new part.

The second issue is that the schemas will not pass basic validation tests if they have relative path references. This is the reason that you originally placed the message schemas and all of the included schemas in the same directory. Once that is done, you will need to modify the path references of the included files.

For example, here is how the <xs:include> elements for the CDA schema should be modified:

From:

<xs:include schemaLocation="../coreschemas/datatypes.xsd"/>
<xs:include schemaLocation="../coreschemas/voc.xsd"/>

To:

<xs:include schemaLocation="datatypes.xsd"/>
<xs:include schemaLocation="voc.xsd"/>

You will need to edit each of the schemas that make up your complete message schema set in the above manner. Once the schemas have been added to a BizTalk project, you can do this by right-clicking a schema, selecting Open With, and then selecting the editor program of choice, or by doing a global search and replace on the schema files.

XSLT modification

In BizTalk Server, when a map has a complex source or destination schema such as the ones developed by HL7, you will need to alter the underlying XSLT before compiling the map. Without the alteration, the system will generate an Out of Memory exception when a map with a complex schema is compiled. The alteration is simple but it needs to be made to every map you develop that uses a complex schema as a source or destination (or both).

Basically, you will develop the map as desired. At any time before you build the map, you will need to right-click the map, select Open With, and then select the text editor program of your choice (such as Notepad). At this point, the XSLT will open in the editor program. In the first few lines of code, you will find an attribute: GenerateDefaultFixedNodes = “yes”. You simply need to change the yes flag to no. When you are finished, the line of data will look something like:

Figure 8 - XSLT for a BizTalk Server v3 map

<?xml version="1.0" encoding="utf-16"?>
<!-- Generated using BizTalk Mapper on Mon, Feb 26 2007 04:45:23 PM -->
<mapsource Name="BizTalk Map" BizTalkServerMapperTool_Version="2.0" Version="2" XRange="100" YRange="420" OmitXmlDeclaration="Yes" TreatElementsAsRecords="No" OptimizeValueMapping="No" GenerateDefaultFixedNodes="No" CopyPIs="No" method="xml" xmlVersion="1.0" IgnoreNamespacesForLinks="Yes">

In BizTalk Server 2004, the GenerateDefaultFixedNodes flag was not present in the XSLT, so it had to be added and set to “no”. In BizTalk Server 2006, the flag is present, but will still need to be set to “no”. It is important to remember that when the GenerateDefaultFixedNodes flag is turned off, the default/fixed values in the generated instance are no longer generated. If you should need them, they will need to be set manually. More information about this issue can be found in the Microsoft Knowledgebase article at http://go.microsoft.com/fwlink/?LinkId=100743.

Working with Web Services

While there are many methods for exchanging HL7 v3 messages, Web services has become the defacto communication protocol of choice for business-to-business (B2B) HL7 v3 messaging.

Essentially, Web services allow the individual components of an HL7 v3 application to be accessible to external applications through the use of platform-independent technologies, such as XML and SOAP.

The primary benefits of Web services are that they:

Operate using open standards, which enable components written in different programming languages, and for different platforms, to communicate.
Promote a modular approach to programming, so companies can re-use the same Web services to communicate with multiple organizations.
Are relatively easy and inexpensive to implement, because they utilize an existing infrastructure (such as the Internet) to exchange information.
Can significantly reduce the costs of enterprise application integration (EAI) and business-to-business (B2B) communications, thus offering companies tangible returns on their investments.
Can be implemented incrementally, rather than all at once. This lessens the cost of adopting Web services, and reduces organizational disruption resulting from an abrupt switch in technologies.

The most important advantage of Web services for HL7 v3 interfaces is that Web services are composed of open standards. This stands to significantly enhance system interoperability over time. The BizTalk Server documentation provides excellent insight into configuring BizTalk Server to consume or publish a Web service.

Message Acknowledgments

A key component of the HL7 messaging infrastructure is reliable messaging. When Web services are used as a means of communication, a minimum level of acknowledgment occurs through the service response. However, you will most likely want to build a message acknowledgment process that reports on the message content into your integration plan.

With HL7 v2, acknowledgments are automatically created as the message moves through the HL7 Disassembler component of the HL7 receive pipeline provided with the BizTalk Accelerator for HL7. However, with HL7 v3, messages are not automatically created as there is no need for a specific pipeline component to process HL7 v3 messages. There are HL7 v3 definitions for message acknowledgments, but how they fit into a comprehensive messaging solution depends on the individual implementation. The developer will need to account for message acknowledgment in the same manner as processing any HL7 v3 message, which means making the necessary schema alterations and XSLT configuration.

Challenges of HL7 v3 Integration

Market realities dictate that HL7 v3 will need to co-exist with HL7 v2.x for quite some time. With over 90% of the larger hospitals in the United States and many other countries worldwide currently utilizing HL7 v2.x message structures, the move to HL7 v3 will most likely be a slow and steady process at best. That means that the primary challenge of any HL7 v3 integration project will be compatibility with the established HL7 v2.x infrastructure within the enterprise.

Integration between different versions within the HL7 2.x standard was facilitated by the backward compatibility rules designed into the standard itself. However, HL7 v3 is by design choice not backward compatible with the flat-file, non-XML format of the HL7 2.x versions. To accomplish a nexus between the two standards, an integration engine like BizTalk Server, capable of understanding and processing both versions, is required. In addition to being able to parse and validate both standards, the integration tool must provide the capability to map data elements between the two versions so that data can be seamlessly translated between formats.

In addition to translating data elements between versions, a complete HL7 v3 integration will require the enforcement of strict business rules.

BizTalk Server 2006 Meets the Challenge of HL7 v3 Integration Projects

Because HL7 v3 messages are encoded with XML, BizTalk Server provides support for HL7 v3 without the need for a special accelerator. The added benefit that BizTalk Server provides for HL7 v3 processing is that, beyond a basic ability to parse and validate the data, BizTalk Server brings with it a flexible and dynamic mapping tool that can be used to seamlessly translate data elements between standards as well as enforce the data modeling requirements found in the HL7 v3 message specification. The strict business rules associated with HL7 v3 data creation can also be accommodated through BizTalk orchestrations and the Business Rule Engine.

Beyond its native support for HL7 v3, BizTalk Server can easily be extended to accommodate the challenges raised by interoperability between systems utilizing both the HL7 v2.x and HL7 v3 standards. The BizTalk Accelerator for HL7 enables BizTalk Server to parse and validate HL7 v2.x data as well as to seamlessly create data in the HL7 v2.x structure. Developing version 2.x BizTalk solutions is discussed in greater length in the separate white paper, HL7 v2 Developer Guide (http://go.microsoft.com/fwlink/?LinkId=100730).

By utilizing the basic components of BizTalk Server together with the pipelines provided with the BizTalk Accelerator for HL7, it is possible to design and implement an HL7 v3 to HL7 v2 integration. The next section defines how these BizTalk Server components could be designed and deployed in order to achieve basic integration between a system processing HL7 v3 patient registration messages and an application utilizing an HL7 v2.4 ADT format.

Integration Test Case

As mentioned earlier, a move to HL7 v3 is not likely to occur in a single enterprise across all of its applications at the same time. Rather, new applications will begin to utilize the HL7 v3 standard while older applications will continue to process only HL7 v2.x formats. Thus, the earliest type of integration scenario encountered will most likely be the requirement to design interoperability between HL7 v3 and HL7 v2.x applications. To do this effectively, the developer will need to identify the nexus between HL7 v2.x and HL7 v3 message types.

The following example details the BizTalk Server configuration steps that are necessary to migrate an HL7 v2.4 ADT^A28 message to an HL7 v3 Add Patient message, identified as the PRPA_IN101001 message type. The task at hand is to carry out two interfaces:

Accept the HL7 v2.4 ADT^A28 message and transform it into an HL7 v3 Add Patient message instance.
Accept an HL7 v3 Add Patient message instance and transform it into an HL7 v2.4 ADT^A28 message type.

It is important to note that our test case demonstrates “a” mapping between HL7 version 2.4 and HL7 v3; it is not meant to serve as a universal mapping. It is based on the example mappings described in the IHE IT Infrastructure Technical Framework, Supplement PIX/PDQ HL7 v3, which is available from the IHE organization at http://go.microsoft.com/fwlink/?LinkId=100905.

Due to the extensive optionality within HL7 v2.4, and to the widely variegated way in which HL7 version 2 standards are implemented, it is not practical to create a general mapping between HL7 v2 and HL7 v3. In practice, it will be necessary to treat most individual HL7 v2 sites as independent implementations, and to generate mappings that are site specific.

In order to enhance the usability of the results, we have chosen to implement stripped-down HL7 v2 and HL7 v3 messages, and to leave out much detail that would be relevant in a production setting. The focus of the example is on necessary BizTalk Server configuration steps and is meant to leave the reader with a functional example of creating HL7 v3 data from HL7 v2 data and vice-versa. In a real environment, the developer will need to add details to the transformation maps to make certain they are version compliant and make certain to add in an acknowledgment component, whether through designing in an HL7 v3 acknowledgment process or through implementing via Web services.

The scenarios below discuss the necessary BizTalk Server configuration steps for processing HL7 v2 data as they relate to the instant scenarios. For a detailed discussion of why the configuration steps are necessary, please refer to the white paper, HL7 v2 Developer Guide (http://go.microsoft.com/fwlink/?LinkId=100730).

Integration Scenario One – Processing an HL7 v2.4 ADT^A28 Message into an HL7 v3 Add Person Message

This section addresses the first part of this common integration challenge through the creation of BizTalk Server components designed around receiving and processing an HL7 v2.4 ADT message into an HL7 v3 Add Person message.

This scenario will require the following BizTalk Server components:

The BizTalk Accelerator for HL7 (providing the necessary HL7 v2.4 schemas and the HL7 receive pipeline to parse and validate the HL7 v2.4-formatted data into an XML format used internally by BizTalk Server)
HL7 v3 message schemas defining the Add Person message format
A map translating the HL7 v2.4 data elements into the HL7 v3 format
An orchestration that enables the creation of a map using multiple input schemas

Configuring the BizTalk Accelerator for HL7 to process the HL7 v2.4 message

To start our development process, we will focus on preparing BizTalk Server to correctly parse and validate the incoming HL7 v2.4 ADT^A28 message. Once you have installed the BizTalk Accelerator for HL7, you will have an HL7 receive pipeline already deployed into your configuration database. As shown in Figure 9 below, this is the pipeline that you will use to configure the receive location that will receive the incoming message. The HL7 receive pipeline has an HL7 Disassembler component that will parse the incoming message from its flat-file format into the XML format used internally by BizTalk Server.

Figure 9 - Receive location configuration using the HL7 receive pipeline

Once the data is parsed, the HL7 Disassembler component will also validate the data against the HL7 v2.4 ADT^A28 schemas provided by the BizTalk Accelerator for HL7. That means that your first development step will be to deploy the HL7 v2.4 schemas that will be used by the accelerator when validating the message. Assuming that this is your initial development activity after installing the accelerator, there are three different projects that you will need to deploy in order to correctly parse and validate your data.

First, you must deploy the schema that defines the MSH segment of the data. During processing through the HL7 Disassembler, the HL7 v2.x message is separated into three distinct components:

Message header (as defined by the MSH segment)
Message body (as defined by the message schema provided with the accelerator)
Z segments (which the user can opt to define through a custom schema for parsing purposes)

Deploy the MSH segment schema

The MSH segment is used to identify the correct message body schema to use to validate the message. This schema must be deployed initially upon accelerator installation as it will be used for all of your HL7 v2.x processing. To deploy it, add a new project to your solution. Into the project add a new item. The MSH schema is contained in a project in the HL7 Projects category called the BTAHL7V2XCommon project (as shown in Figure 10 below).

Figure 10 -The BTAHL7V2XCommon project contains the MSH segment schema

After creating and setting a 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 acknowledgment schemas are available in the configuration database.

Deploy the v2.4 message body schemas

The second step you must perform to configure BizTalk Server to process your HL7 v2.4 message is to deploy the necessary schemas so that the message body can be correctly validated. This entails two steps:

Deploying definitional schemas used to define the data types, segments, and tables found in the message body
Deploying the actual schema that defines the particular message body structure, such as the HL7 v2.4 ADT^A28 structure in this case

These two steps are necessary because, when it comes to HL7 v2.x, individual interpretations of messages abound. To accommodate this, the data fields, segments, and tables identifying looping structures are defined in separate schema files per version to serve almost as a version-specific dictionary. See Figure 11 below.

Figure 11 - Dictionary schemas are used for each v2.x version

Then, individual message schemas are created for each message type. As seen in Figure 12 below, 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 may 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 any object-oriented development.

Figure 12 - The message structure schemas for an HL7 v2.4 ADT^A28 message

In order to fully configure the accelerator to correctly parse your HL7 v2.4 message, you will need to deploy the project containing the HL7 v2.4 dictionary schemas as well as deploy a project containing the HL7 v2.4 ADT^A28 message schemas.

Deploy the HL7 v2.4 dictionary schema

Definitional schemas are provided for each of the HL7 2.x versions in predefined BizTalk projects by version. You will need to deploy the appropriate project for the HL7 version you are processing. In Solution Explorer, add a new HL7 project. The projects are located under HL7 schema projects and the one you need to add is identified as BTAHL7V24Common Project, where the “V24” indicates the version number. When this opens in Solution Explorer, notice that three schemas—datatypes_24.xsd, segments_24.xsd, and tablevalues_24.xsd—are included in the project. See Figure 13 below.

Figure 13 - The BTAHL7V24CommonProject contains the dictionary schemas that must be deployed

After applying the necessary assembly key (.snk) file, deploy this project. This is a one-time step that is necessary for your entire HL7 v2.4 processing because now the definitional schemas referenced by all HL7 v2.4 schemas are available in the configuration database.

Deploy the HL7 v2.4 ADT^A28 message schema

Once the header and version-specific definitional schemas are deployed, you will configure and deploy message-specific schemas as necessary for your HL7 processing. In Solution Explorer, add an empty HL7 project as a new project. In this project, you will add a reference to the previously deployed project containing the definitional schemas for the message version you are processing. For instance, since you are processing an HL7 v2.4 ADT message, you will reference the Version2.4CommonProject you just deployed, as seen in Figure 14 below.

Note
For purposes of the solution provided with this paper, the message schemas have been placed in a project called HL7_v2_to_v3_Conversion \ADT_A28_24_Conversion and they reference the BTAHL7V24CommonProject.

Figure 14 - The project containing your message schemas will reference the previously deployed dictionary schema project

Once the reference is added, you will add a message schema to this project for each message type you are processing. To do this, add a new item to the project, selecting BTAHL7Schemas under BizTalk Project Items in the category pane of the Add New Item dialog box. In the schema selection dialog box, select the version and message type you are interested in. As shown in Figure 15 below, since you are processing a version 2.4 ADT^A28 message, select 2.4 for the version, ADT for Message Type, and A28 for the Event Type, and then select Finish. This will add the message definition schema to your project. The HL7 Schema Selector dialog box will remain open for you to add other schemas into this project. Because this is the only v2 schema we need, select Cancel to close the dialog box.

Figure 15 - When adding an HL7 schema to a project, the HL7 schema selector helps you choose the desired schema

Once you have added a message schema for each message type that you are processing, apply the necessary assembly key (.snk) file and deploy this project. Once done, these are the schemas you will reference and use in your HL7 v2.4 maps and orchestrations.

Configuring BizTalk Server to process the HL7 v3 outgoing message

Because HL7 v3 is encoded as XML you do not need the BizTalk Accelerator for HL7 to process HL7 v3 messages. Rather, you will need to simply add an XSD for the message type you desire to a BizTalk project and then deploy them.

As discussed earlier, it will take multiple schemas to support the HL7 v3 message. The schemas will need to be placed in the same directory. Also, they will need to be edited, as detailed above, so that they include the message specification namespace and so that the includes statements are accurate since the schemas will all be in the same directory.

The schemas used to build the sample scenario provided with this paper came from the HL7 Normative Edition 2006. Figure 16 below shows the schemas used to define our HL7 v3 Add Person message, located in the HL7_v2_to_v3_Conversion \PRPA_IN101001_SchemaSet project called PRPA_IN101001UV01.xsd.

Figure 16 - v3 Add Person message incident schemas

In the next step, you will use a BizTalk Server map to translate the HL7 v2.4 data into the HL7 v3 message format. Maps require you to declare both a source and destination schema. You will need to use the HL7 v3 schema for the appropriate message incident as your destination schema.

Deploy the HL7 v3 message schemas

To deploy the schemas, add a new project to your solution. You will use the Add an Existing Item menu selection to add the necessary HL7 v3 schemas (the message incident and all referenced schemas) into your project.

To reproduce this scenario on your own, the PRPA_IN101001UV01 schema and all the referenced schemas for the message type are contained in the project located at HL7_v2_to_v3_Conversion \PRPA_IN101001_SchemaSet so you will simply add that project as an existing project into your Visual Studio solution and make certain to reference the project in the project containing your map. After applying the necessary assembly key (.snk) file, deploy this project.

Configure and deploy a map creating the HL7 v3 message structure

As mentioned earlier, you will use a BizTalk Server map to create the HL7 v3 message structure from the incoming HL7 v2.4 message format. Now that you have deployed your source and target schemas, you are ready to create a map, according to the following steps. The HL7 v3 message will require information to be mapped from the MSH segment of the incoming HL7 v2.x message as well as the rest of the included body segments.

Because the HL7 Disassembler breaks the MSH segment from the body segments of the incoming HL7 v2.x message, mapping values from the MSH segment and the other body segments at the same time will require creating the map from within an orchestration. The detailed click-through steps that follow this section describe the necessary configuration steps.

In short, you need to define your source and destination schemas for the map. The two source schemas will be the HL7 v2.4 message structure (ADT_A28_24_GLO_DEF.xsd and MSH_24_GLO_DEF.xsd) and the destination schema will be the HL7 v3 message incident schema (PRPA_IN101001UV01.xsd).

Note
For purposes of this scenario, the project included with this white paper at HL7_v2_to_v3_Conversion \ADT_A28_24_Conversion contains an orchestration called CreatePRPA_IN101001UV01.odx and a map called MapPRPA_IN101001.btm, and has all the necessary references to the HL7 v2.4 and HL7 v3 schema projects. If you wish to use this project, you will need to add it to your Visual Studio .NET solution and update the references as necessary. You can download the project by clicking here.

Note

For purposes of this scenario, the project included with this white paper at HL7_v2_to_v3_Conversion \ADT_A28_24_Conversion contains an orchestration called CreatePRPA_IN101001UV01.odx and a map called MapPRPA_IN101001.btm, and has all the necessary references to the HL7 v2.4 and HL7 v3 schema projects. If you wish to use this project, you will need to add it to your Visual Studio .NET solution and update the references as necessary. You can download the project by clicking here.

Figure 17 - v24ORM_to_V3ObsvReqst.btm

Figure 17 above shows the map used to create an HL7 v3 Add Person message from an HL7 v2.4 ADT^A28. The map is only a small sampling of the actual mapping that would need to be performed to completely create the HL7 v3 data structure from an HL7 v2.4 ADT. For ease of reference, it is meant to serve as a sampling of the mapping techniques that would be used to create a complete structure.

To fully configure your map, you will locate the incoming data fields in the HL7 v2.4 message and drag and drop them into the proper location in the HL7 v3 message structure. Because of the strict coding and structure rules of the HL7 v3 format, some of your map rules will require hard coding of values while some will require you to evaluate the incoming field for a certain value before you conditionally create an outgoing value.

To hard code a value, access the Properties window for the element and enter the desired text into the Value row in the Properties window. To evaluate incoming data to conditionally create output data, you will use a combination of a logical functoid and a value mapping functoid.

Basically, with the exception of the simplest maps, you’ll use functions such as logical evaluation and value mapping, string manipulation, database access, and others to create the required HL7 v3 structure. These functions, called functoids in BizTalk Server, can be found in the Toolbox and inserted into the map grid between the source and target panes.

It is worth noting that functoids can be chained so that the output of one functoid can be the input to another. If you cannot locate a functoid that meets your specific needs, you can always utilize the script functoid. The script functoid is an open-ended functoid that will allow you to write in-line code in C#, Visual Basic® .NET, J#, or even XSLT. Script functoids can also call code from referenced assemblies.

The enclosed sample map utilizes basic source to destination data element pointers created through dragging and dropping while some destination values are simply hard coded. Finally, some logical and value mapping functoids are utilized to evaluate the input data to conditionally create the HL7 v3 data element.

The following chart depicts the mapping specifications followed to create the HL7 v3 structure in the included MapPRPA_IN101001.btm map. The chart describes the values that were mapped from the HL7 v2 message to create the HL7 v3 message. However, it should be noted that most of the necessary values that compose an HL7 v3 message are hard coded into the structure because they are values that do not exist in the HL7 v2 structure. Those values can be seen in the created HL7 v3 message that follows the chart.

From	To
'<Schema>' 'Root' 'InputMessagePart_0' 'MSH_24_GLO_DEF' 'MSH' 'MSH.7_DateTimeOfMessage' 'TS.1'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'creationTime' '<Equivalent>' '<TS>' 'value'
'<Schema>' 'Root' 'InputMessagePart_0' 'MSH_24_GLO_DEF' 'MSH' 'MSH.8_Security'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'securityText' '<Equivalent>' '<ST>' '<Sequence>' 'reference' 'value'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_11_PatientAddress' 'XAD_2_City'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'addr' '<Sequence>' '<Choice>' 'city'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_11_PatientAddress' 'XAD_3_StateOrProvince'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'addr' '<Sequence>' '<Choice>' 'state'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_11_PatientAddress' 'XAD_4_ZipOrPostalCode'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'addr' '<Sequence>' '<Choice>' 'postalCode'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_11_PatientAddress' 'XAD_5_Country'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'addr' '<Sequence>' '<Choice>' 'country'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_13_PhoneNumberHome' 'XTN_0_9999999999X99999CAnyText'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'telecom' 'value'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'EVN_EventType' 'EVN_2_RecordedDateTime'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'effectiveTime' '<Choice>' 'high' 'value'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'EVN_EventType' 'EVN_2_RecordedDateTime'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'authorOrPerformer' 'time' '<Choice>' 'high' 'value'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'EVN_EventType' 'EVN_3_DateTimePlannedEvent'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'authorOrPerformer' 'time' '<Choice>' '<Sequence>' and position()='1' 'low' 'value'
'<Schema>' 'Root' 'InputMessagePart_0' 'MSH_24_GLO_DEF' 'MSH' 'MSH.13_SequenceNumber'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'sequenceNumber' '<Equivalent>' '<INT>' 'value' '<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'processingCode' 'code'
'<Schema>' 'Root' 'InputMessagePart_0' 'MSH_24_GLO_DEF' 'MSH' 'MSH.11_ProcessingId' 'PT.0_ProcessingId'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'processingCode' 'code'
'<Schema>' 'Root' 'InputMessagePart_0' 'MSH_24_GLO_DEF' 'MSH' 'MSH.11_ProcessingId' 'PT.1_ProcessingMode'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'processingModeCode' 'code'
'<Schema>' 'Root' 'InputMessagePart_0' 'MSH_24_GLO_DEF' 'MSH' 'MSH.15_AcceptAcknowledgmentType'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'acceptAckCode' 'code'
'<Schema>' 'Root' 'InputMessagePart_0' 'MSH_24_GLO_DEF' 'MSH' 'MSH.5_ReceivingApplication' 'HD.0_NamespaceId'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'receiver' '<Group:InfrastructureRootElements>' 'typeId' 'assigningAuthorityName'
'<Schema>' 'Root' 'InputMessagePart_0' 'MSH_24_GLO_DEF' 'MSH' 'MSH.3_SendingApplication' 'HD.0_NamespaceId'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'sender' '<Group:InfrastructureRootElements>' 'typeId' 'assigningAuthorityName'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'EVN_EventType' 'EVN_2_RecordedDateTime'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'effectiveTime' 'value'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_19_SsnNumberPatient'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' '<Group:InfrastructureRootElements>' 'typeId' 'extension'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_3_PatientIdentifierList' 'CX_0_Id'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' '<Group:InfrastructureRootElements>' 'templateId' 'extension'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_11_PatientAddress' 'XAD_0_StreetAddressSad' 'XAD_0_0_StreetOrMailingAddress'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'addr' '<Sequence>' '<Choice>' 'streetAddressLine'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_11_PatientAddress' 'XAD_0_StreetAddressSad' 'XAD_0_1_StreetName'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'addr' '<Sequence>' '<Choice>' 'streetAddressLine'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_11_PatientAddress' 'XAD_0_StreetAddressSad' 'XAD_0_2_DwellingNumber'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'addr' '<Sequence>' '<Choice>' 'streetAddressLine'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_5_PatientName' 'XPN_0_FamilyName' 'XPN_0_0_Surname'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' '<Choice>' 'assignedPerson' 'name' '<Equivalent>' '<EN>' '<Sequence>' '<Choice>' 'family'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_5_PatientName' 'XPN_0_FamilyName' 'XPN_0_1_OwnSurnamePrefix'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' '<Choice>' 'assignedPerson' 'name' '<Equivalent>' '<EN>' '<Sequence>' '<Choice>' 'prefix'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_5_PatientName' 'XPN_1_GivenName'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' '<Choice>' 'assignedPerson' 'name' '<Equivalent>' '<EN>' '<Sequence>' '<Choice>' 'given'
'<Schema>' 'Root' 'InputMessagePart_1' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_5_PatientName' 'XPN_3_SuffixEGJrOrIii'	'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' '<Choice>' 'assignedPerson' 'name' '<Equivalent>' '<EN>' '<Sequence>' '<Choice>' 'suffix'

Below is the created HL7 v3 message that shows all the values that must be directly created in the HL7 v3 structure because they do not exist in the HL7 v2 structure:

<?xml version="1.0" encoding="utf-8" ?> 
 <ns0:PRPA_IN101001UV01 xmlns:ns0="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ns0:id xsi:type="ns0:II" root="2.16.840.1.113883.19.3.2409" extension="1-976-245" displayable="true" /> 
  <ns0:creationTime xsi:type="ns0:TS" value="199601121005" /> 
 <ns0:securityText xsi:type="ns0:ST">
  <ns0:reference value="" /> 
  </ns0:securityText>
  <ns0:versionCode code="V3PR1" /> 
  <ns0:interactionId xsi:type="ns0:II" root="2.16.840.1.113883.19.3.2409" extension="1-976-245" assigningAuthorityName="HL7" displayable="true" /> 
  <ns0:profileId xsi:type="ns0:II" root="2.16.840.1.113883.19.3.2409" extension="1-976-245" displayable="true" /> 
  <ns0:processingCode code="P" codeSystemVersion="2.4" /> 
  <ns0:processingModeCode /> 
  <ns0:acceptAckCode /> 
  <ns0:sequenceNumber xsi:type="ns0:INT" /> 
 <ns0:attachmentText xsi:type="ns0:ED" mediaType="text/plain">
  <ns0:reference value="This is a brief note." /> 
  <  </ns0:attachmentText>
 <ns0:receiver typeCode="RCV">
  <ns0:typeId assigningAuthorityName="NewSys" displayable="true" /> 
  <ns0:device classCode="DEV" determinerCode="INSTANCE" /> 
  </ns0:receiver>
 <ns0:sender>
  <ns0:typeId assigningAuthorityName="HIS" displayable="true" /> 
  </ns0:sender>
 <ns0:controlActProcess classCode="INFO" moodCode="CODE">
  <ns0:id xsi:type="ns0:II" root="2.16.840.1.113883.19.3.2409" extension="1-976-245-000" displayable="true" /> 
 <ns0:code xsi:type="ns0:CE" code="PRPA_TE101001" codeSystem="2.16.840.1.113883.5.4" codeSystemName="ActCode" displayName="routine">
  <ns0:originalText xsi:type="ns0:ST" representation="Person Event Activate Notification" /> 
  </ns0:code>
 <ns0:effectiveTime>
  <ns0:high value="198808181123" inclusive="true" /> 
  </ns0:effectiveTime>
  <ns0:priorityCode xsi:type="ns0:CE" code="R" codeSystem="2.16.840.1.113883.5.7" codeSystemName="ActPriority" displayName="routine" /> 
 <ns0:authorOrPerformer contextControlCode="AP">
 <ns0:time>
  <ns0:low inclusive="true" /> 
  <ns0:high value="198808181123" inclusive="true" /> 
  </ns0:time>
  <ns0:modeCode xsi:type="ns0:CE" code="PHYSICAL" codeSystem="2.16.840.1.113883.5.1064" codeSystemName="ParticipationMode" displayName="physical presence" /> 
  </ns0:authorOrPerformer>
 <ns0:subject contextConductionInd="true">
 <ns0:registrationEvent>
  <ns0:id xsi:type="ns0:II" root="2.16.840.1.113883.19.3.2409" extension="1-976-245-000" displayable="true" /> 
  <ns0:statusCode code="active" /> 
  <ns0:effectiveTime value="198808181123" /> 
<ns0:author>
  <ns0:typeId root="2.16.840.1.113883.19.4.1" extension="111-222-3333" displayable="true" /> 
  <ns0:templateId extension="PATID1234" displayable="true" /> 
  <ns0:templateId extension="123456789" displayable="true" /> 
 <ns0:assignedEntity>
  <ns0:id xsi:type="ns0:II" root="2.16.840.1.113883.19.3.2409" displayable="true" /> 
 <ns0:addr use="HP">
  <ns0:country /> 
  <ns0:state>IL</ns0:state> 
  <ns0:city>Metropolis</ns0:city> 
  <ns0:postalCode>60069</ns0:postalCode> 
  <ns0:streetAddressLine>123 Center St</ns0:streetAddressLine> 
  </ns0:addr>
  <ns0:telecom value="8665551234" use="H" /> 
 <ns0:assignedPerson>
 <ns0:name xsi:type="ns0:EN">
  <ns0:family>SMITH</ns0:family> 
  <ns0:given>HARRY</ns0:given> 
  <ns0:prefix /> 
  <ns0:suffix>III</ns0:suffix> 
  </ns0:name>
  </ns0:assignedPerson>
  </ns0:assignedEntity>
  </ns0:author>
  </ns0:registrationEvent>
  </ns0:subject>
  </ns0:controlActProcess>
  </ns0:PRPA_IN101001UV01>

When developing your own map, before you build the map, you will need to edit the XSLT and set the GenerateDefaultFixedNode attribute to “no” (as described earlier). If you are using the provided map, this flag is already set correctly.

Once you are satisfied with the map output, you will add the necessary assembly key (.snk) file and deploy the map project. Once deployed, you will want to refresh the configuration database to ensure your access to the maps in the next configuration steps.

Using an orchestration to create a map with multiple input schemas

To configure an orchestration to accept the three parts of an HL7 v2.4 structure that the HL7 Disassembler creates, you will need to add a new item to your project and then add an orchestration. You will also need to 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.

Finally, you will need to add a reference to the BTAHL72XCommonProject because it contains the MSH schema. You will need to access this schema in the map that you are creating in this orchestration.

Note
The orchestration provided in the HL7_v2_to_v3_Conversion \ADT_A28_24_Conversion project is called CreatePRPA_IN101001UV01.odx.

There are many necessary configuration steps involved in designing an orchestration. The following chart depicts the steps necessary to receive an HL7 v2.4 message into an orchestration and call a map to transform the HL7 v2.4 data into an HL7 v3 message structure. In the map, you will have access to both the MSH and body segments components of the HL7 v2.4 message.

Orchestration configuration steps

Use the following procedure to configure the orchestration.

To configure the orchestration

Add a Receive shape to the orchestration. Name it "ReceiveADTA28" and set the Activate property to True.
Add a Message Assignment shape under the Receive shape. Name the outer Construct shape "ConstructMSH". Name the Assign shape "AssignMSH".
Add another Message Assignment shape under the ConstructADTA28Body shape. Name the Construct shape "ConstructADTA28Body" and name the Assignment shape "AssignADTA28Body".
Add a Transform shape under the ConstructV3Msg shape. Name the outer Construct shape "ConstructV3Msg". Name the Transform shape "MapPRPA_IN101001".
Add a Send shape under the ConstructV3Msg shape. Name it "SendV3Msg".
In the Orchestration View window, add the Message definitions you need.

You will need four message definitions:
- PRPA_IN101001 = PRPA_IN101001UV01.xsd
- ADTA28_body = ADT_A28_24_GLO_DEF.xsd
- MSH_Msg = MSH_24_GLO_DEF.xsd
- CompleteADTA28 = will configure after next step
In the Orchestration View window, move under Types and add a Multi-Part Message Type called "CompleteADTA28Type".

Expand the entry and change the Identifier on MessagePart_1 to MSHSegment. Then, add two more message parts called "BodySegments" and "ZSegments".

In the Properties for BodySegments, set BodyPart = True.
In the Properties window for BodySegments, under Type, select Schemas, <Select from referenced assembly> to select ADT_A28_24_GLO_DEF.xsd.
In the Properties window for MSHSegment, under Type, select Schemas, <Select from referenced assembly> to select MSH_24_GLO_DEF.xsd.
In the Properties window for ZSegment, under Type, select .NET Classes, and then click System.String from the drop-down list.
Move to the Messages entry, select CompleteADTA28 and open its Properties window. Click Message Type, expand Multi-part Message Types, and then click <ProjectName>.CompleteADTA28Type.
To configure your orchestration shapes, assign the following messages to the appropriate shape:
- Receive = CompletevADTA28
- ConstructMSH_Msg = MSHMsg
- ConstructADTBodyMsg = ADA28_body
- Constructv3AddPerson = PRPA_IN101001
- Sendv3AddPerson = PRPA_IN101001
Move into the properties window for the Transform shape. Select the ellipses in the MapName line. In the Map Dialog box, select New Map. Configure the Source and Destination messages as follows:
- The Source variable = Click in the first line and select MSHMsg. Then, click in the next line down and select ADTA28_body.
- The Destination variable = PRPA_IN101001
Notice that the Open Mapper check box is selected. When you select OK to close the dialog box, BizTalk Server will create a map for you that uses a combined schema for both input messages as your source schema.
Move into the newly created map and follow the previously detailed mapping specifications.
Create the necessary ports you need for the orchestration.

When complete, your orchestration should look like Figure 18 below, as provided in the HL7_v2_to_v3_Conversion \ADT_A28_24_Conversion project is called CreatePRPA_IN101001UV01.odx.

Figure 18 – Orchestration creating an HL7 v3 message – the CreatePRPA_IN101001UV01.odx

Once you have configured your orchestration, you are ready to build and deploy it. Once deployed, you will create a receive port/location that receives the HL7 v2.4 data. The receive location will use the HL7 receive pipeline. You will also create a send port that sends the HL7 v3 message to your target application. Because the HL7 v3 message will be XML, you will configure the send port to use the XMLTransport pipeline provided with BizTalk Server. Next, bind the orchestration to your receive and send ports, and then enlist and start the orchestration.

Note
In order to keep the focus in this example on necessary BizTalk Server artifact configuration, the example is file based. A complete interface will need to take into account reliable messaging concepts and will most likely include Web service calls.

You are now ready to test the scenario. To do this, place a sample HL7 v2.4 file into the receive location you configured. You should see an HL7 v3-formatted message appear in the file location specified in your send port.

Note
To test the scenario with the artifacts included with this paper (http://go.microsoft.com/fwlink/?LinkId=100621), open the HL7_v2_to_v3_Conversion solution, make sure that all HL7 v2.4 and HL7 v3 schema references are updated, and then build and deploy.

Integration Scenario Two – Processing an HL7 v3 Add Person Message into an HL7 v2.4 ADT Format

Building on the premise that the earliest type of integration scenario encountered will most likely be the requirement to design interoperability between HL7 v3 and HL7 v2.x applications, this section addresses the need to receive and process an HL7 v3 Add Person message into an HL7 v2.4 ADT message format.

This scenario will require the following BizTalk Server components:

HL7 v3 message schemas defining the Add Person message incident format (deployed similarly as the schemas from the previous section)
A map translating the HL7 v3 data elements into the HL7 v2.4 format
An orchestration used to build the HL7 v2.4 MSH segment onto the HL7 v2.4 message body created by the HL7 v3 to HL7 v2.4 map
The BizTalk Accelerator for HL7 (providing the necessary HL7 v2.4 schemas and the HL7 send pipeline to serialize the HL7 v2.4-formatted data from BizTalk Server internal XML format to the HL7 v2.4 flat-file format)

You also need to install the patch discussed here: http://support.microsoft.com/kb/941261.

Configuring BizTalk Server to process the HL7 v3 incoming message

As discussed earlier, you do not need the BizTalk Accelerator for HL7 to process HL7 v3 messages. To receive and process HL7 v3 messages, you will use the default XML receive pipeline. To send the data to a map or an orchestration, you will also need to deploy the appropriate HL7 v3 message schemas.

Deploy the HL7 v3 message schemas

As with Integration Scenario One, you will need to deploy the appropriate HL7 v3 message format schema as well all referenced schemas. In this case, we are receiving an HL7 v3 Add Person message. Once we have downloaded all of the necessary schemas to support our HL7 v3 message from the HL7 Web site and configured them as described earlier, you will build and deploy the project containing the schemas.

Configure a map to translate the HL7 v3 data elements into the HL7 v2.4 format

In order to create the HL7 v2.4 message body structure that you desire, you will create, configure, and deploy a map in a similar fashion to what was described in the previous section. However, in this case, the source schema will be the HL7 v3 message schema and the destination schema will be the HL7 v2.4 message schema. As with the previously described map, you will need to add references into the map project for both schemas as well as for the HL7 v2.4 dictionary schemas.

Note
For purposes of this scenario, the HL7_v2_to_v3_Conversion \ADT_A28_24_Conversion project contains a map called CreateADTA28Body.btm.

The mapping steps necessary to create an HL7 v2.4 structure are not as complex as to create an HL7 v3 structure because the HL7 v2.x standard is simpler than the HL7 v3 standard. Most commonly, when mapping HL7 v3 data into an HL7 v2.x format, the majority of your map will involve dragging and dropping incoming elements into the desired output locations. The following chart depicts the mapping specifications followed to create the HL7 v2.4 structure in the included CreateADTA28Body.btm map.

From	To	Mapping instruction
	'<Schema>' 'ADT_A28_24_GLO_DEF' 'EVN_EventType' 'EVN_1_EventTypeCode'	Hard Code: A28
'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'creationTime' '<Equivalent>' '<TS>' 'value'	'<Schema>' 'ADT_A28_24_GLO_DEF' 'EVN_EventType' 'EVN_2_RecordedDateTime'
	<Schema>' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_1_SetIdPID'	Hard Code: 1
'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' '<Group:InfrastructureRootElements>' 'typeId' 'extension'	'<Schema>' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_19_SsnNumberPatient'
'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' '<Group:InfrastructureRootElements>' 'templateId' 'extension'	'<Schema>' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_3_PatientIdentifierList' 'CX_0_Id'
'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' '<Choice>' 'assignedPerson' 'name' '<Equivalent>' '<EN>' '<Sequence>' '<Choice>' 'family'	'<Schema>' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_5_PatientName' 'XPN_0_FamilyName' 'XPN_0_0_Surname'
'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' '<Choice>' 'assignedPerson' 'name' '<Equivalent>' '<EN>' '<Sequence>' '<Choice>' 'given'	'<Schema>' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_5_PatientName' 'XPN_1_GivenName'
'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' '<Choice>' 'assignedPerson' 'name' '<Equivalent>' '<EN>' '<Sequence>' '<Choice>' 'suffix'	'<Schema>' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_5_PatientName' 'XPN_3_SuffixEGJrOrIii'
'<Schema>' 'PRPA_IN101001UV01' '<Sequence>' 'controlActProcess' 'subject' 'registrationEvent' 'author' 'assignedEntity' 'addr' '<Sequence>' '<Choice>' 'streetAddressLine'	'<Schema>' 'ADT_A28_24_GLO_DEF' 'PID_PatientIdentification' 'PID_11_PatientAddress' 'XAD_0_StreetAddressSad' 'XAD_0_0_StreetOrMailingAddress'

Once you are satisfied with the map, you will add the necessary assembly key (.snk) file and deploy the map project. Once deployed, you will want to refresh the configuration database to ensure your access to the maps in the next configuration steps.

In the previous section, we called the map used to create our outbound HL7 v3 structure through binding it to a send port. However, when creating HL7 v2.x structures, we will not be able to fully create the message structure in this manner. Due to how the BizTalk Accelerator for HL7 handles HL7 v2.x messages, we will need to call this map in an orchestration so that we can add the MSH segment to the top of the message body created by the map.

Creating a complete HL7 v2.4 message through an orchestration

As discussed earlier, the HL7 v2.x message schemas do not contain the MSH segment, because that segment is parsed differently by the BizTalk Accelerator for HL7. The accelerator treats the HL7 v2.x message structure as three distinct units: the message header (MSH segment), the message body (all standard-defined segments after the MSH segment), and Z segments. The impact of this is that when using a map to create an HL7 v2.x message structure, you will 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 the BizTalk Server internal XML structure into the flat-file HL7 2.x structure.

To configure an orchestration to assign the three parts of an HL7 v2.4 structure into a single unit, you will need to add a new item to your project and then add an orchestration. You will also need to 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.

Note
The orchestration provided in the HL7_v2_to_v3_Conversion \ADT_A28_24_Conversion solution is called CreateADTA28Message.odx.

There are many necessary configuration steps involved in designing an orchestration. The following chart depicts the steps necessary to receive an HL7 v3 message into an orchestration, call a map to transform the HL7 v3 data into an HL7 v2.4 message structure, assign an MSH segment to the HL7 v2.4 message body, and send the completed, unified HL7 v2.4 message from the orchestration. Once it leaves the orchestration, the HL7 v2.4 message will be routed through a send port using the HL7 send pipeline so that the data that leaves BizTalk Server will be an HL7 v2.4-formatted flat file.

Orchestration configuration steps

Use the following procedure to configure the orchestration.

To configure the orchestration

Add a Receive shape to the orchestration. Name the shape "Receive_PRPA_IN10101" and set the Activate property to True.
Add a Transform shape under the Receive shape. Name the Construct shape "ConstructADTA28Body" and name the Transform shape "CreateADTA28Body".
Add a Message Assignment shape under the "ConstructADTA28Body" Construct message shape. Name the Construct shape "ConstructfinalADTA28" and name the Assignment shape "AssignfinalADTA28_msgParts".
Add a Send shape under the "ConstructfinalADTA28" shape. Name it "SendfinalADTA28".

In the Orchestration View window, add the Message definitions you need. You will need three message definitions:
- PRPA_IN101001_Msg = PRPA_IN101001UV01.xsd
- ADTA28_body = ADT_A28_24_GLO_DEF.xsd
- finalADTA28Msg = will configure after next step
In the Orchestration View window, move under Types and add a Multi-Part Message Type called "finalADTA28Type".

Expand the entry and change the Identifier on MessagePart_1 to MSHSegment.

Then, add two more message parts called "BodySegments" and "ZSegments".

In the Properties for BodySegments, set BodyPart = True.
In the Properties window for BodySegments, under Type, select Schemas, <Select from referenced assembly> to select the ADT_A28_24_GLO_DEF.xsd.
In the Properties window for MSHSegment, under Type, select .NET Classes, and then click <Select from referenced assemblies>. In the Select Artifact Type dialog box, in the left pane, click System.Xml. In the right pane, click XmlDocument, and then click OK.
In the Properties window for ZSegment, under Type, select .NET Classes, then click System.String from the drop-down list.
Move to the Messages entry, select Completev24ADTA28, and open its Properties window. Click Message Type, expand Multi-part Message Types, and then click <ProjectName>.finalADTA28Type.
In the Orchestration View window, right-click Variables, and then click New Variable to create Variable_1. Click Variable_1, and in the Properties pane, click Identifier, type the new name "HeaderInfo". Click Type, and then double-click <.NET Class>. In the Select Artifact window, in the left pane, click System.Xml, in the right pane, click XmlDocument, and then click OK.
To configure your orchestration shapes, assign the following messages to the appropriate shapes:
- Receive_PRPA_IN101001 = PRPA_IN101001_Msg
- ConstructADTA28Body = ADTA28_body
- ConstructfinalADTA28 = finalADTA28Msg
- SendfinalADTA28 = finalADTA28Msg
Move into the Properties window for the Transform shape and call the CreateADTA28Body map.
- The source variable = PRPA_IN101001_msg
- The destination variable = ADTA28_body
To configure the ConstructfinalADTA28 shape, move into its Properties window and select Messages Constructed, and then select finalADTA28Msg from the drop-down list.

To configure the ConstructfinalADTA28 assignment shape, in the Properties window, click Expression, and then click the ellipsis (…) button to open BizTalk Expression Editor.

Copy the text below the note and paste it into the expression shape. Click OK.

Note
The first block of the expression text is an example hard-coded XML header. The BTAHL7 serializer requires a header segment. You can customize these header values according to the needs of your environment. The second block of the text defines the three message parts required in a multi-part message. The BTAHL7 serializer requires a multi-part message. The third block of the text contains the promoted properties that the BTAHL7 serializer examines in order to correctly serialize an XML message into an HL7 flat-file message.

Note

The first block of the expression text is an example hard-coded XML header. The BTAHL7 serializer requires a header segment. You can customize these header values according to the needs of your environment. The second block of the text defines the three message parts required in a multi-part message. The BTAHL7 serializer requires a multi-part message. The third block of the text contains the promoted properties that the BTAHL7 serializer examines in order to correctly serialize an XML message into an HL7 flat-file message.

HeaderInfo = new System.Xml.XmlDocument();
 
HeaderInfo.LoadXml("<ns0:MSH_24_GLO_DEF xmlns:ns0=\"http://microsoft.com/HealthCare/HL7/2X\"><MSH><MSH.2_EncodingCharacters>^~\\&amp;</MSH.2_EncodingCharacters><MSH.3_SendingApplication><HD.0_NamespaceId>HIS</HD.0_NamespaceId><HD.1_UniversalId></HD.1_UniversalId></MSH.3_SendingApplication><MSH.4_SendingFacility><HD.0_NamespaceId>srcFac</HD.0_NamespaceId><HD.1_UniversalId>srcFacUid</HD.1_UniversalId></MSH.4_SendingFacility><MSH.5_ReceivingApplication><HD.0_NamespaceId>dstApp</HD.0_NamespaceId><HD.1_UniversalId>dstAppUid</HD.1_UniversalId></MSH.5_ReceivingApplication><MSH.6_ReceivingFacility><HD.0_NamespaceId>dstFac</HD.0_NamespaceId><HD.1_UniversalId>dstFacUid</HD.1_UniversalId></MSH.6_ReceivingFacility><MSH.7_DateTimeOfMessage><TS.1>200307092343</TS.1></MSH.7_DateTimeOfMessage><MSH.8_Security>sec</MSH.8_Security><MSH.9_MessageType><CM_MSG.0_MessageType>ADT</CM_MSG.0_MessageType><CM_MSG.1_TriggerEvent>A28</CM_MSG.1_TriggerEvent></MSH.9_MessageType><MSH.10_MessageControlId>msgid2134</MSH.10_MessageControlId><MSH.11_ProcessingId><PT.0_ProcessingId>P</PT.0_ProcessingId></MSH.11_ProcessingId><MSH.12_VersionId><VID.0_VersionId>2.4</VID.0_VersionId></MSH.12_VersionId></MSH></ns0:MSH_24_GLO_DEF>");

finalADTA28Msg.MSHSegment = HeaderInfo;
finalADTA28Msg.BodySegments = ADTA28_body;
finalADTA28Msg.ZSegments = "";

finalADTA28Msg(BTAHL7Schemas.MSH1) = 124; 
finalADTA28Msg(BTAHL7Schemas.MSH2) = "^~\\&";
finalADTA28Msg(BTAHL7Schemas.ParseError) = false; 
finalADTA28Msg(BTAHL7Schemas.ZPartPresent) = false;
finalADTA28Msg(BTAHL7Schemas.SegmentDelimiter2Char) = true;

Create the necessary ports you need for the orchestration.

When complete, your orchestration should look like Figure 19 below, as provided in the HL7_v2_to_v3_Conversion \ADT_A28_24_Conversion project is called CreateADT_A28Message.odx.

Figure 19 - Orchestration creating the complete v2.4 ADT message – the CreateADT_A28Message.odx

After the orchestration is fully configured, you will add the necessary assembly key (.snk) file, and build and deploy it. You will need to refresh the configuration database to have access to the orchestration in BizTalk Explorer.

After you have configured your physical send port in the next step, you will bind this orchestration to that send port as well as to an HL7 v3 receive location created to receive the HL7 v3 Patient Update file. Once bound, you will enlist and start the orchestration in order to test the scenario.

Testing the Scenario

This scenario, like the previous one, depends on the proper configuration of the BizTalk Accelerator for HL7. However, assuming that the necessary HL7 v2.4 schemas remain deployed from the previous scenario, you do not need to take any further action to configure the accelerator. Rather, the only step you will need to complete is to configure a send port to use the HL7 send pipeline provided by the accelerator.

Figure 20 - Send port using the BTAHL7V2XSendPipeline

As seen in Figure 20 above, to configure a send port to serialize HL7 data correctly, you simply need to configure it to use the HL7 send pipeline. You do not need to place a filter on the port, as the v3AddPerson_to_v24ADT_orch will be bound to the port.

As the orchestration is enlisted, you will enable, enlist, and start your receive and send ports. Then, to test the scenario, place HL7 v3 sample data in your receive location, and then move to your send port location and view the created HL7 v2.4 file. The supporting artifacts for this paper can be found at http://go.microsoft.com/fwlink/?LinkId=100621.

Summary

These two processing scenarios were chosen because their simplicity can be used as a foundation for more complex processing needs. Since it is estimated that the majority of HL7 v3 processing will involve interfacing with HL7 v2.x message formats, these two scenarios demonstrate how the flexibility of BizTalk Server 2006 makes it an ideal solution for all of your HL7 processing needs.

As HL7 v3 evolves and more parts of it are finalized as a standard, the schemas needed to define it may become more complex. Regardless of how the standard evolves in particular, its fundamental XML formatting means that BizTalk Server 2006 will be able to process it without the aid of an additional accelerator. However, to achieve interoperability between HL7 v3 and HL7 v2.x systems, you will need the added components provided by the BizTalk Accelerator for HL7.

Where to Get Help

For more information about the evolving HL7 v3 standard, visit the HL7 Web site at http://go.microsoft.com/fwlink/?LinkId=46813.

For the person that is new to BizTalk Server and would like to understand how its components can be used for complete solution design, see the book "Designing Healthcare Solutions with BizTalk Server 2004" at http://go.microsoft.com/fwlink/?LinkId=100906. Although written for BizTalk Server 2004, the book is still completely relevant to BizTalk Server 2006. (Casey, J and Redding, E. Designing Healthcare Solutions with BizTalk Server 2004. New Hampshire: Mann Publishing Group, 2004)

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

About the Author

Elizabeth Redding is president and founder of Partner2Learn, Inc., a company providing BizTalk Server architectural and implementation services and training on HL7, 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 Server accelerator product group for many years and has recently been engaged in several projects concerning the new functionality provided by BizTalk Server 2006 R2.