---

March 2011

Volume 26 Number 03

BizTalk EDI Solutions - Processing Health Care Claims with BizTalk Server 2010

By Mark Beckner | March 2011

BizTalk Server 2010 introduces an entirely re-architected platform for managing the exchange of Electronic Data Interchange (EDI) documents between trading partners. If you’ve worked with earlier editions of the platform, you may have encountered some headaches with setting up document exchange between various parties. With the latest release, you have complete control over the organization and configuration of document settings related to any interchange between parties.

BizTalk Server 2010 also provides a much-improved experience when developing maps.

To illustrate these new features, I’m going to walk you through the steps required for building out an EDI solution. Every EDI 
solution developed in BizTalk Server 2010 follows a basic pattern:

• Adding and modifying base EDI schemas.
• Creating maps between the EDI document and internal/external messaging.
• Implementing orchestrations to handle workflow associated with processing the EDI documents.
• Configuring trading partner settings, including parties, business profiles, agreements and acknowledgments.
• Configuring ports to enable reception or delivery of documents, whether over FTP, AS2 or another protocol.

For purposes of illustration, we’ll look at the exchange of documents between a hospital and a claims-processing unit. The documents exchanged between parties will be Health Insurance Portability and Accountability Act (HIPAA)-compliant 837 Professional and Institutional files.

Working with Schemas

In most EDI solutions, you’ll be working with two basic types of schema: the EDI schemas that represent the flat files exchanged with trading partners, and the internal schemas that represent document types needed for processing the data within the EDI document.

In my example, the solution exchanges the 837 documents with external parties, but uses a different document format for internal processing. The internal schema represents an ECSIF flat file: a common format for claims processors. The 837 schemas that ship with BizTalk and can be added to a Visual Studio project, but the internal schemas (such as an ECSIF) must be built by hand.

BizTalk Server 2010 ships with thousands of existing schemas that define a majority of the EDI documents in use today. To access the schemas, run the MicrosoftEdiXSDTemplates.exe executable found in the $\Program Files\Microsoft BizTalk Server 2010\XSD_Schema\EDI directory. For the purposes of this example, I’ll use the 837 Professional and Institutional HIPAA-compliant schemas found in the HIPAA\00501 folder. Adding the XSD file to a Visual Studio project allows it to be referenced and used by other BizTalk components—most importantly, by maps.

Figure 1 shows the 837 Professional 5010 schema within Visual Studio 2010. Notice the number of nodes on this schema: the 837 is one of the most complex EDI documents, and can be extremely tricky to work with. It contains hundreds of nodes that are virtually identical, representing subscriber and patient information.

Figure 1 The 837 Professional 5010 Schema

Figure 2 shows the internal schema representing the ECSIF format. This schema was generated using the Flat File Schema Wizard. The wizard can be pointed to a valid flat file instance to create an XSD. A number of the fields in the FileHeader node have been promoted in this schema. Promoted fields allow for improved filtering and mapping options.

Figure 2 The Target ECSIF Schema Format

Once the schemas have been defined and added to the Visual Studio project, you can begin building out the maps. In this case, I’ll look at several scenarios that are useful in mapping an 837 document.

Developing Maps

The mapping interface in BizTalk Server 2010 has been extensively revised and introduces a variety of new capabilities. These capabilities include zooming, automatic node matching and search capabilities. One of the most noticeable enhancements is the ability to click on a line or functoid and have all other mappings fade into the background.

As any EDI map developer will know, some maps get extremely complex, with multiple tabs and dozens (or even hundreds) of functoids. Finding out what data in the source schema maps to what data in the target schema and what functoids are being used to do this mapping can be difficult to visualize. By clicking on any of the lines or functoids used, all related mappings will be highlighted.

An example of a complex map with a specific set of mapping logic highlighted is shown in Figure 3. This brings up a point of BizTalk map development that’s often overlooked: there are times to use the map interface, and there are times not to use it. Not all mapping that’s done in BizTalk is best suited for standard mapping—sometimes using alternative approaches is in order. Alternatives include inline scripting and external components, including XSLT and Microsoft .NET Framework components.

Figure 3 Highlight Capabilities in BizTalk Server 2010 Maps

BizTalk map development generally consists of a combination of standard functoids and inline XSLT and C#. There are even times when shelling out to an external XSLT stylesheet is in order (which bypasses the BizTalk mapper altogether). EDI maps can become complicated and require ingenuity and planning to end up with the needed solution.

To illustrate the use of inline C#, let’s look at a common function of mapping an outbound 837 Professional or Institutional file: the mapping of hierarchical (HL) segments. The HL segments require incremental values for each record in the file, and denote parent/child relationships. There really is no traditional functoid combination that will allow these values 
to be set properly. There is, however, a simple inline C# approach that allows for the correct values. This approach requires two scripting functoids: one that stores a global variable and maps HL01, while the second maps HL02 (which is dependent on the value of HL01).

The HL01 functoid script looks like this:

int intHL01;
  public int getHL01() {
  intHL01++;
  return intHL01;
  }

Here’s the code for the HL02 script:

public int getHL02() {
  return intHL01 -1;
  }

Figure 4 shows the functoids placed in the map.

Figure 4 Mapping HL Segment on Outbound 837

Another situation that frequently arises in mapping EDI documents is the need to use inline XSLT. This is one of the most important skills to incorporate into BizTalk mapping, and is something you should acquaint yourself with. It allows for many options around looping and node creation that simply aren’t available using standard functoid combinations.

One illustration of using Inline XSLT in a map is shown in Figure 5. This code demonstrates how to use the Inline XSLT Call Template functionality to pass in a parameter from the source document (Name) and create a node in the target 837 document.

Figure 5 Passing Parameters to an Inline XSLT Call Template Script

When developing a BizTalk map, always think about the long-term maintainability of the map. Is this something that you’ll be able to easily update? Is this something that someone else can work with in the future? Good coding practice should not be forgotten when working with BizTalk maps, and some amount of architecture and planning should be involved when developing maps that have a lot of logic or complex functionality within them.

Orchestrations

The use of orchestrations in EDI solutions is not a requirement. Often, documents simply need to be mapped from one format to another and delivered, without the need for the inclusion of workflow.

In some cases, however, a document may need to have several steps of processing done to it before it’s ready to be delivered. To illustrate this, I’ll set up an orchestration to map and archive messages to a table in SQL Server. The orchestration will be configured with a filter to ensure only documents of a certain type are processed by it.

The orchestration can be set up to subscribe to just about any of the fields within the ISA or ST segments of an EDI document (among many other properties). To configure an orchestration to subscribe to a specific field on a document, a filter can be set on the initial receive shape of the orchestration, as shown in Figure 6.

Figure 6 Setting a Filter on an Orchestration

With the filter specified, the orchestration can now do the necessary processing of the EDI document. In this case, the orchestration is going to map the data from the 837 format to the ECSIF format and then write this information to an archive table in SQL Server. The mapping of the documents is done through a transform shape and the inclusion of a map file, but the writing of the information to SQL Server has a number of options available for it.

When thinking of SQL Server, many BizTalk developers assume that they need to use one of the adapters available for writing to SQL. The truth is that, in most cases, the SQL adapters are overly complex for basic database calls. Generally, the easiest and most supportable approach for interacting with SQL Server is through the use of a custom .NET assembly class. When developing classes that will be called from orchestration, always make sure and mark the class as serializable to ensure that BizTalk can call it from any type of transaction state:

namespace Demo.BizTalk.Helper {
    [Serializable]
    public class DataAccess
    { }
  }

Developing orchestrations for EDI solutions is no different than for other types of BizTalk implementations. The main thing to remember when developing orchestrations is to keep it simple. There’s an art to BizTalk development and to organizing your BizTalk projects properly. If you’ve planned and developed properly, you’ll end up with a solution that’s easy to make updates to and deploy to a production environment.

Trading Partner Configurations

BizTalk Server 2010 introduces a new interface for managing the exchange of EDI documents between trading partners. It’s made up of three basic tiers of organization: the party, the business profile and the agreement.

The party represents the top-level organization of the trading partner. Configurations on this artifact relate to things that are common across all documents being exchanged with this trading partner. For example, certificates that may be required for secure communication would be configured at this level.

In my example, I have two parties: the claims processor and the hospital. Each is set up as its own unique BizTalk party. All that needs to be configured is the name, as shown in Figure 7.

Figure 7 Top-Level Party Configuration

A party will have one or more business profiles associated with it. The business profile represents a department within an organization that has its own unique business identity when sending or receiving EDI documents. A business identity is the value that appears in the ISA06 or ISA08 segment of an EDI document (depending on whether the document is being sent or received) and uniquely identifies the trading partner from all other entities. Many organizations will have a single business profile, but some will require multiple profiles.

In my example, the claims processor has two business profiles: one that represents professional claims processing, and another that represents institutional claims processing. The hospital also has two business profiles: the national branch and the international branch. Figure 8 shows the parties with their business profiles.

Figure 8 Business Profiles Associated with Parties

Because the business profile represents a unique business identity within a party, configurations at this level deal with information that’s common across all documents that will be exchanged with this identity. All inbound and outbound settings that are common across all document types being exchanged will be configured: the protocols used (X12, EDIFACT, AS2), the validation settings, the transaction sets (EDI documents are allowed at this level), acknowledgments and some of the envelope settings are all configured on a business profile. In many cases, the default information can be used at this level, because the configuration of the specific agreements of a business profile will define this information and more.

A business profile can have one or more agreements. An agreement represents the way that two parties are expecting to exchange one or more document types with one another. This is where the specifics about the envelope, the acknowledgments and the transaction sets allowed are defined. One agreement could allow for certain documents to be exchanged with 997 acknowledgments configured, while another agreement could allow for other document types to forego the acknowledgments.

In my example, the claims processor and the hospital are exchanging documents. The hospital will send the claim (X12 837 Institutional version 5010) to the claims processor, and the claims processor will send an acknowledgment (X12 997) back to the hospital. Figure 9 shows the envelope identifier configuration and Figure 10 shows the transaction set configuration on the agreement for documents flowing from the hospital to the claims processor. Note the tabs at the top of the window indicating the flow of the document.

Figure 9 Configuring ISA Envelope Settings on an Agreement

Figure 10 Configuring Transaction Sets on an Agreement

Figure 11 shows the configuration of the acknowledgments that are sent back from the claims processor to the hospital.

Figure 11 Configuring acknowledgments on an Agreement

If you’re exchanging documents with more than a single trading partner, you’ll likely find that the majority of your configurations are virtually identical—the only thing changing will be the identifiers in the ISA segment of the envelope.

To ease development, make sure to use the template functionality available from the agreement configuration screen. There are two buttons you’ll be interested in: Save As Template and Load From Template. When you have a trading partner fully configured, and the EDI documents are flowing end-to-end with the correct envelope settings and acknowledgments, simply save the agreement settings as a template and use them as the starting point for future agreements.

Port Configurations and Document Delivery

The actual delivery of documents to or from BizTalk to external trading partners is done through the configuration of ports. The port defines the type of delivery mechanism (FTP, file and so on) and contains the BizTalk pipeline that transforms the XML document within BizTalk into the flat file EDI document expected by trading partners. The pipeline contains the logic to interpret (or create) the EDI envelope on a document and to determine which party the document resolves to.

To understand how ports process EDI documents, let’s look at sending an acknowledgment. As you saw earlier, acknowledgments are configured on the agreements of a BizTalk party. When a document arrives, BizTalk can automatically generate a 997 acknowledgment. What happens is that BizTalk creates the 997 XML and drops it on the BizTalk message box, but it doesn’t actually route the message anywhere. A send port must be set up and configured to convert the XML to a flat file, add the envelope and deliver it to the appropriate destination.

Setting up the send port to deliver an acknowledgment requires three basic steps:

1. The definition of the send port and delivery protocol
2. The inclusion of the EdiSend pipeline (or custom pipeline with EDI pipeline components)
3. The configuration of filters to listen for appropriate acknowledgments

Configuring the send port to deliver documents to a specific location is straightforward. Figure 12 shows a Send Port configured with the EdiSend pipeline. The send port will write files out to a file directory with the full EDI envelope and formatting in place.

Figure 12 Setting Pipeline and Delivery Information on a Port

Setting the filter on the send port is also easy to do. It simply requires specifying that it should only pick up acknowledgments generated by the system for this trading partner (as opposed to incoming 997s from the partner). Figure 13 shows a fully configured set of filters.

Figure 13 Filtering on a Send Port

Problem Solved

The new EDI functionality in BizTalk Server 2010 is concentrated primarily in the management of trading partners. Hierarchical relationships and organizations that were impossible with previous editions of the platform can now be modeled with relative ease. In addition to this, the map interface has been enhanced, and the developer experience with mapping is much improved. With the various improvements and increased functionality, any EDI solution can be modeled and developed successfully using BizTalk Server 2010.

---

Mark Beckner is the founder of Inotek Consulting Group LLC. He works across the Microsoft stack, including BizTalk, SharePoint, Dynamics CRM and general .NET development. He can be reached at mbeckner@inotekgroup.com.