BizTalk 2013 EDI for Health Care: HIPAA-Compliant 834 (Enrollment) and 837 (Claims) Solutions (2014)

Chapter 2. Solution: Receiving 837P Data

This chapter will walk through a complete end-to-end solution on how to build out BizTalk to receive 837P documents from an external trading partner and send an acknowledgement back. The data will be received via an SFTP adapter, archived, processed by an orchestration, and written to a flat file in the ECSIF format. This will introduce many of the key concepts required in virtually any environment that you may find yourself having to develop within.

The solution that you will be working through will demonstrate how to receive 837P documents from an external trading partner and send an acknowledgement back. The data will be received in unencrypted format on an SFTP site, archived by a BizTalk orchestration using a .NET library, and mapped to a flat file format. This will introduce many of the key concepts required in virtually any environment that you may find yourself having to develop within. The overview of this specific solution is shown in Figure 2-1.

Figure 2-1. Inbound 837P Solution Overview

Visual Studio Solution

It is critical that your project structure and namespaces are correct from the start. If these are not exactly what you need for the proper architecture and organization of your solution, you’ll be spending a great deal of time later in the process rewriting and retesting. For this solution, the namespace is in a structure that you should be able to use directly within your own solutions, substituting the wording, but not the structure. You will also be creating a Visual Studio project structure that will be generic enough to fit within any model you may find yourself confronted with. In the case of the solution being built out, the following Visual Studio projects and namespaces will be used:

· Solution Name: Company.BizTalk. This is a generic solution that can hold inbound and outbound projects (see Chapter 3, “Solution: Sending 837P Data”). There are several projects that are common to many projects, so having everything in one solution can be very helpful.

· Schemas. There are two schemas that will be used in this solution - the 837P 5010 schema that ships with BizTalk, and the proprietary ECSIF schema.

o The 837P Schema will be contained in its own project. The project name for this will be Company.BizTalk.Schemas.X837P

o The ECSIF schema will be contained in its own project. The project name for this will be Company.BizTalk.Schemas.ECSIF

Note When setting a namespace, never use a numeric value alone without at least one leading text character (such as the 837 in Company.BizTalk.Schemas.837), as it will result in a variety of potential naming conflicts, unexpected errors, and challenges in testing. If you wish to refer to an EDI document type directly in your namespace, use a pattern such as a leading “X”, like X837P.

· Maps. The map project will contain all maps and XSLT required by the solution, and will have a namespace of Company.BizTalk.Maps.X837.Inbound

· Helper Library. There will be one external .NET assembly project with the namespace of Company.BizTalk.Helper

· Orchestration. There will be one orchestration used, which will be in its own project called Company.BizTalk.Orchestrations.X837.Inbound

· Pipeline. There will be one custom Send pipeline project, which will be called Company.BizTalk.Pipelines.X837.Outbound

The Schema Projects

There will be two schemas required for this project. The first is the 837P 5010 schema that ships with BizTalk. BizTalk has thousands of EDI schemas that come with it, crossing all of the document types and versions available. There are a number of 837P schemas, so it can be tricky to choose the right one when you are first getting started. Take the following steps to create a project that has the correct 837P BizTalk schema for your implementation:

· Create a new project in Visual Studio called Company.BizTalk.Schemas.X837P

· Find the HIPPA folder in the BizTalk EDI schema collection. There are two versions available - 4010 and 5010. You’ll use the 5010 for this chapter. Click on the 837P folder and notice there is a “single” and a “multiple” available for selection. The schema you will need to use will depend on your batching requirements (if you have any).

If you are receiving a batched 837P, for example, which needs to be split into individual documents split at a certain level with access to claims, you would use the “multiple” version. Generally, the best approach is to start with the “single” version and if you find that batching is not working the way you would expect it to, experiment with the “multiple” version. Once you have found the correct XSD, add it to your Visual Studio schema project.

Note To access the EDI schemas with BizTalk, browse to the root Microsoft BizTalk Server 2010 root folder and go to XSD_Schema\EDI. In this directory you will find a file called MicrosoftEdiXSDTemplates.exe. Running this file will extract all available schemas.

The second schema project will contain the proprietary ECSIF file schema structure. ECSIF files were very common on older claims management systems, and are a flat file structure, and will be referred to here and in several mapping discussions in this book. However, don’t let this name mislead you - any flat file that you may need to create a schema for will follow the exact same pattern as what is required for the ECSIF - just substitute your flat file name where appropriate. An example of the ECSIF schema structure is shown in Figure 2-2.

Figure 2-2. ECSIF Flat File Schema Structure Showing Child Delimiter

The steps required for the creation of the ECSIF project are as follows:

· Create a new project in Visual Studio called Company.BizTalk.Schemas.ECSIF

· Add a schema to your project that matches the flat file structure you are seeking. Any flat file schema that you may need to create can be created using BizTalk’s Flat File Schema Wizard, available when you add a new item to your Visual Studio project and select Schema Files. The Wizard is pretty involved, and allows for virtually any structure, simple or complex; however, figuring out how to configure things to produce the schema you are seeking can be a challenge. There are a number of great resources available on the internet to help you work with this Wizard.

The schema projects (especially the X837P) are the foundation of many of the other projects you will be creating, as these other projects reference them. If the schemas change during the course of development, all of the other projects will be impacted. Do everything you can to get the schemas namespaced correctly, and structured correctly (you don’t have to worry about the structure of the 837P schema, but you do have to deal with any schemas you are creating from scratch) at the start of your development.

The Map Project

The map project will allow for the mapping of the inbound 837P data into the ECSIF format. Because the ECSIF supports multiple claims, and the 837P contains multiple claims, there is no need for any splitting of the data before it arrives. The 837P data can simple be mapped into the target ECSIF format using whatever mapping techniques are required. That being said, mapping 837P data can be one of the most challenging mapping exercises that you will face. This is not because of BizTalk, but rather because of the enormity in size and structure of data that represent the claims within the 837P.

Chapter 4 (“Mapping Data”) is dedicated to the activity of mapping, and looks at the specifics of what is required for the ECSIF (or other flat file) structure. Please refer to that chapter in order to build out the correct map.

The map project structure should be as follows:

· Create a new project in Visual Studio called Company.BizTalk.Maps.X837.Inbound

· Add a reference to the two schema project you have created, as you will be mapping from 837P to ECSIF

The .NET Helper Library Project

The .NET helper library is used by the orchestration to archive the inbound XML version of the EDI file to a database in its native XML format. This is an invaluable way of being able to access and report on data through SQL Business Intelligence (BI) platforms such as SSRS without having to push the 837P data to a traditional database model. The .NET class will have a single method in it that looks similar to the code shown in Listing 2-1. You can pass as many or as few parameters as you would like, depending on the needs of your reporting.

Note Always mark your .NET classes as Serializable, so that they can be called from anywhere within BizTalk. To do this, type [Serializable] directly above the class declaration in your helper library.

Listing 2-1. Method Called from Orchestration to Archive Data to SQL

public void ArchiveInboundData(string strSourceFileName, string
strTradingPartner, XmlDocument xmlSource, string strConnectionString)
{
SqlConnection sqlConnection = new SqlConnection(strConnectionString);
SqlCommand sqlCommand = sqlConnection.CreateCommand();
sqlCommand.CommandText = "spInsertInboundData";
sqlCommand.CommandType = CommandType.StoredProcedure;
sqlConnection.Open();

SqlParameter sqlParameter = new SqlParameter();

sqlParameter.ParameterName = "@vchSourceFileName";
sqlParameter.SqlDbType = SqlDbType.VarChar;
sqlParameter.Direction = ParameterDirection.Input;
sqlParameter.Value = strSourceFileName;
sqlCommand.Parameters.Add(sqlParameter);

sqlParameter = new SqlParameter();
sqlParameter.ParameterName = "@vchTradingPartner";
sqlParameter.SqlDbType = SqlDbType.VarChar;
sqlParameter.Direction = ParameterDirection.Input;
sqlParameter.Value = strTradingPartner;
sqlCommand.Parameters.Add(sqlParameter);

sqlParameter = new SqlParameter();
sqlParameter.ParameterName = "@xmlSourceData";
sqlParameter.SqlDbType = SqlDbType.Xml;
sqlParameter.Direction = ParameterDirection.Input;
sqlParameter.Value = new XmlNodeReader(xmlSource);
sqlCommand.Parameters.Add(sqlParameter);

sqlCommand.ExecuteNonQuery();
sqlConnection.Close();
}

The stored procedure called from this method is shown in Listing 2-2. It simply takes the data passed to it and inserts it into a table. Once the data is in the table, it can be queried using standard T-SQL and XQuery. An example of querying the 837P XML data for the Clearing House Trace Number (a common unique identifier for submitted claims) is shown in Listing 2-3.

Listing 2-2. Stored Procedure to Archive 837P XML Data

CREATE PROCEDURE [spInsertInboundData]
@vchSourceFileName As varchar(500)
,@vchTradingPartner As varchar(50)
,@xmlSourceData As xml
AS
BEGIN

SET NOCOUNT ON;
INSERT tblInboundData
(
vchSourceFileName
,vchTradingPartner
,xmlSourceData
,dtmCreateDate
)
VALUES
(
@vchSourceFileName
,@vchTradingPartner
,@xmlSourceData
,getdate()
)
END

Listing 2-3. Using XQuery to Query Archived 837P XML

-- THE FOLLOWING WILL REMOVE NAMESPACE FOR EASE OF QUERYING
SELECT CAST(REPLACE(CAST(@xmlSourceData As varchar(max)),'ns0:','')
As xml) As SourceData
INTO #XML

-- THE FOLLOWING USES XQUERY TO RETRIEVE SPECIFIC VALUE
SELECT DCN.value('REF02__ClearinghouseTraceNumber[1]','varchar(255)') As DCN
FROM #XML
CROSS APPLY SourceData.nodes('//REF_TS837Q1_2300_SubLoop') As header(head)
CROSS APPLY head.nodes('REF_ClaimIdentificationNumberForClearingHouses
AndOtherTransmissionIntermediaries_TS837Q1_2300') as DCN(DCN)
WHERE DCN.value('REF02__ClearinghouseTraceNumber[1]','varchar(255)') IS NOT
NULL

Once you have the .NET helper library built, you can reference the DLL in the orchestration project and call it to archive the inbound XML data. The next section shows how to call this referenced DLL from within an orchestration.

The Orchestration Project

In this solution, the orchestration will receive the 837P directly, map it, archive it to the database, and send it out in the final ECSIF format to a file directory. If archiving to the database was not a requirement, all of this could be accomplished without the use of an orchestration. The mapping could occur directly on either the Receive Port or Send Port. For this solution, however, the orchestration is used, and an example of it is shown in Figure 2-3. In order for this orchestration to work, you must add a reference to the .NET Helper DLL, the two schema projects, and the map project, all created earlier in this chapter.

Figure 2-3. The Orchestration

Details behind each of the shapes in this orchestration must be given, as several of them are Expression Shapes and have important code behind them. There is no restriction as to how you populate your Expression Shapes, and no requirements as to naming standards. In the case of this orchestration, all of the Expression Shapes could be merged into one - but keeping them separate will allow you to see how you could add additional message types to this orchestration and be able to reuse common code. Figure 2-4 is a variation of the orchestration that shows receiving an additional document type of the 837I on a Listen shape and sharing the calls to the Init_Data and Archive_Data Expression Shapes.

Figure 2-4. A Variation on the Orchestration with Shared Common Shapes

The Receive_837P Shape

This is a simple receive shape that must be set to an orchestration message type of the 837P schema (you’ll need to add a reference to this schema project from your orchestration project). Call this message InboundData. The Activate property on this shape must be set to True.

The Set_Vars Shape

This shape sets variables that are specific to the document just received, and which are immediately available to the orchestration (as opposed to the Init_Vars shape which gets its data from a configuration file). The code behind this shape sets several of the fields that are passed as parameters to archive the data. The code, with notes, is shown in Listing 2-4.

Listing 2-4. Set_Vars Expression Shape Code

// Get the Trading Partner ID (from the party settings) directly off the
// inbound file
strTradingPartnerID = msg837P(EDI.ISA06);

// Several options for getting the file name
strFileIdentifier = System.IO.Path.GetFileName(msg837P(FILE.ReceivedFileName));
strReceivedFileName = msg837P(FILE.ReceivedFileName);

// getting the original inbound message as XML into a parameter of type XML
// which can be passed into the helper class and written to the database as XML
xmlOriginalEDI = new System.Xml.XmlDocument();
xmlOriginalEDI = (System.Xml.XmlDocument)msg837P;

The Init_Vars Shape

This shape is used to read from the BizTalk configuration file. There are often variables that are best kept configurable. In this case, the configurable field is the database connection string used to connect to the SQL Server database where the data will be archived. Adding a key/value pair to your configuration file allows for rapid access and alteration of this key. Using the BizTalk configuration file can be done as follows:

· Browse to the root BizTalk Server folder

· Open BTSNTSvc.exe.config in a plain text editor

· You can add new configurable fields to the <appSettings> node of this document. An example of storing a connection string would be:

<add key=“ Company.BizTalk.Archiving.ConnectionString” value=“Data Source=BTSSQLSERVER;Initial Catalog=Archiving;Integrated Security=SSPI;” />

· Save the modified config file and restart the BizTalk Host Instance. The field can now be referenced from an Expression Shape using the code shown in Listing 2-5.

Listing 2-5. Init_Vars Expression Shape Code

strConnectionString =System.Configuration.ConfigurationSettings.AppSettings["Company.BizTalk.Archiving.ConnectionString"];

The Archive_Data Shape

This shape calls the code in the .NET library to do the actual archiving, passing in several fields as parameters. These parameters include the source file name, the trading partner, and the data to be archived. The data being archived in this case is the XML version of the 837P data, readily available to the orchestration in the inbound message. The code for archiving is shown in Listing 2-6. Notice that the inbound message (which is the orchestration message of type Company.BizTalk.Schemas.X837P received on the Receive shape) can be converted to XML and sent straight in as a parameter.

Listing 2-6. Archive_Data Expression Shape Code

// the parameter shown here have all been set in previous shapes
objHelper.ArchiveInboundData(strReceivedFileName,
strTradingPartnerID,(System.Xml.XmlDocument)
InboundData,strConnectionString);

The Pipeline Project

The final project required is a simple custom flat file pipeline using the Flat File Disassembler component that ships with BizTalk. The use of this pipeline on a Send Port will allow the outbound ECSIF document to be output in flat file format. The steps to create this pipeline are as follows, and the pipeline is shown in Figure 2-5.

· Create a new project called Company.BizTalk.Pipelines.X837.Outbound.

· Add a new Send Pipeline to this project.

· In the pipeline GUI interface, drop a Flat File Disassembler component on the Disassemble stage.

· In the properties of the disassembler component, set the Document Schema property to the Company.BizTalk.Schemas.ECSIF schema created earlier in this project (you may have to deploy the schema DLL in order to have access to this).

Figure 2-5. The Flat File Pipeline and Disassembler Component

Setting up the BizTalk Components

With all of the Visual Studio projects completed, you will have a number of BizTalk components to deploy and configure. The first step will be to deploy the DLLs that are created when you compile your Visual Studio projects. This can be done in a variety of ways, but the one which will allow you the most control (and is the quickest) is as follows. This can be used for adding new DLLs and for updating existing DLLs. After you deploy, always restart the BizTalk Host Instance.

· Open BizTalk Administration Console and browse to the Application where your code will be deployed. If one doesn’t exist, create one called “Company.BizTalk”

· Right click the Application and select Add and then BizTalk Assemblies.

· In the window that opens, Click the Add button and add all of the assemblies for this solution - two schema DLLs, one map DLL, one orchestration DLL, and the .NET helper DLL.

· Click the Overwrite all checkbox.

· Click on each DLL and make sure the first and third checkbox in the Option window is selected for each one. You must do this for every DLL that you are adding. Figure 2-6 shows the checkboxes being set (the first and third also need to be checked for the .NET assembly, though it will have several additional boxes).

Figure 2-6. The Options to Select when Deploying Assemblies

Note It can be helpful to have all of your Visual Studio projects write their compiled DLLs to the same directory, as you will be deploying them to BizTalk frequently for testing. This can be done by going into the project properties for each project and setting the Output Path of the build to a common directory, like a custom folder called Binaries.

Party Settings and Agreements

The steps to configure the BizTalk Party settings that contain all of the information about how the data will be validated and what the 837P envelope settings should be are as follows:

· Create a new BizTalk Party that represents your home organization. For now, this will be called Company. All you need to set is the name.

· Create a new BizTalk Party for your trading partner. This will be named Trading Partner for this solution. You’ll need to set one Party up for every trading partner you will be doing business with. Only the name needs to be set.

· You will create one Agreement that represents the exchange of information between your trading partner and your company. Right click the Company Party and create a new Agreement. Set the Protocol type to X12, the First Party will automatically be set to Company, and the second Party should be set to your Trading Partner Party. The moment this is done, two additional tabs will appear within the Agreement. One tab is for inbound data from the trading partner to your company, while the other is for outbound data from your company to the trading partner.

· On the tab representing inbound data from the trading partner to your company, click on the Identifiers, Envelopes and Character set tabs and enter the appropriate information as required by the 837P envelope. You can easily access this either in a sample instance coming from the trading partner (just open in notepad and match the values) or by referencing the trading partner implementation guide (if you have one).

· On the Validation tab, set the Transaction Type property to 837_P - Health Care Claim: Professional.

· On the Envelopes tab, set the following values:

o Transaction Type should be 837_P - Health Care Claim: Professional.

o Version/Release should be 00501 (or 00401 if you are using the 4010 version)

o Target namespace should be http://schemas.microsoft.com/BizTalk/EDI/X12/2006

o GS1 should be HC-Health Care Claim (837)

o GS2, GS3, GS4, and GS5 should be set based on what your trading partner requires (again, see the trading partner implementation guide or a sample 837P instance from them)

o GS7 should be X-Accredited Standards Committee X12

o GS8 should be 005010X222.

Note The GS8 property value can be tricky to get right. If you are batching, or you have a trading partner that requires a certain value here, you may find that you have to create a custom pipeline to override this value right before it is sent to the trading partner.

The Receive Port

The inbound data will be received on an SFTP receive port. The details for configuring this port (with and without decrypted data) are given in Chapter 5. What is important to know here is that the port must not only be created, but must be bound to the orchestration. The steps for creating and binding this port are as follows:

· Create a Receive Port called Company.BizTalk.Receive.X837P.TradingPartner. This allows for a pattern that will support multiple trading partners, if needed.

· Add a Receive Location to this port and call it the same thing as the Receive Port. Make it of type SFTP and configure the appropriate settings for the SFTP connection. Since unencrypted 837P data will be received here, set the Receive pipeline to EdiReceive.

The File Send Port

The Send Port will be used to send the final ECSIF flat file which was mapped in the orchestration. The Send Port should be of type File, and should have the Send Pipeline property set to the Company.BizTalk.Pipelines.X837.Outbound pipeline created earlier. This Send Port should be called Company.BizTalk.Send.ECSIF.

Orchestration Binding

The orchestration is set to pick up a file of type 837P, map it to ECSIF, archive it, and then send out the ECSIF document. Once it has been deployed, it needs to be bound to the appropriate Receive and Send Ports. Take the following steps to bind the orchestration to the ports that were just created:

· In the BizTalk Administration Console, in the Application where you are working, click on the Orchestrations folder and open the Company.BizTalk.Orchestrations.X837.Inbound orchestration you have built and deployed.

· Click on the Bindings tab and set the Host property to the BizTalk Server Application host that is available.

· Set the Receive Port property to the Receive Port you created called Company.BizTalk.Receive.X837P.Receive.

· Set the Send Port property to the Send Port you created called Company.BizTalk.Send.ECSIF.

· Click OK to save these settings.

Enabling and Running the Solution

At this point, all of the components have been deployed and set up. All you need to do is enable your Receive Location for the inbound SFTP, start your Send Port for the outbound ECSIF flat file, and enable your orchestration. All of this can be done through the BizTalk Administration Console. Make sure and restart the BizTalk Host Instance so that all of the most current settings and assemblies are loaded into memory.

Conclusion

You have just worked through a full implementation for receiving 837P data and mapping it to an internal proprietary flat file format (ECSIF). Receiving data and getting it into your system is sometimes all there is to an implementation. Other times, sending data back out to trading partners is required. The next chapter focuses on a specific implementation of sending 837P data to a trading partner, and introduces a number of topics not covered in this chapter.