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

Note
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

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

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

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.

Note
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

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.

Note
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

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

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.

Note
For ease of maintenance, it is a recommended practice to deploy your message schemas separately from maps and orchestrations.

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

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

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.

Note
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

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.

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 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

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.

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

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.

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

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

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.

Note
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

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

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.

Note

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.

The following steps detail how 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.
      

      Note
      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.
        

        Note
        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 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

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.

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

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

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.

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.

Note
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.

Note
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.
  

The following steps detail how to create custom 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.

Note
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.

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.
      

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.

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.
       

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.
      

      Note
      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.

      Note
      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.
      

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.
      

      Note

      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.

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.
      

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.
      

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.

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.
       

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.
      

      Note
      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.

      Note
      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.
      

1. Configure the Transform shape to use the ORM_to_Orders map.

   Note
   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;
      

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.
      

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.
      

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 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.
   

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.

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.

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.

Note
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.

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.