I have often run into the same errors in my time developing BizTalk HL7 applications to interface with various HL7 EHR systems.  These errors stem from using out of the box BizTalk maps to transform HL7 messages using the Microsoft BizTalk Accelerator for HL7.  Here are two of the errors that I have come across that others might have too…

1. Error happened in body during serialization

Error happened in body during serialization
Error # 1

Alternate Error Number: 301
Alternate Error Description: XmlReader not positioned at root elment of ‘ADT_A01_25_GLO_DEF’
Alternate Encoding System: HL7-BTA

This error is thrown by the BizTalk HL7 assembler pipeline BTAHL72XSendPipeline.  The pipeline is stating that it was unable to recognize the first few characters of the HL7 XML message sent to the pipeline.  This is caused by the existence of the XML declaration at the top of the message produced in a BizTalk transform shape, assignment shape, or in a helper class.

<?xml version="1.0" encoding="utf-8"?>

In my case, when creating an HL7 message in a helper class I used an XmlWriter to aid in executing a map through c# instead of orchestration transform shape.  The resolution was to add an XmlWriterSettings object with the ‘OmitXmlDeclaration’ setting set to true.  However, there are many other ways to remove the XML declaration.

...
VirtualStream output = new VirtualStream();
XmlWriterSettings s = new XmlWriterSettings();
<strong>s.OmitXmlDeclaration = true;</strong>

using (XmlWriter outputWriter = XmlWriter.Create(output, <strong>s</strong>))
{
    //transform code here
}

2. Extra line breaks in HL7 message created by BizTalk

One common error is the existing of many line breaks when trying to assemble a message using the BTAHL7 2X Send Pipeline.

This is caused by the empty XML elements within the source XML document sent to the send port pipeline.

There are two ways to fix this.  One is to change the BizTalk map to prevent the transfer of empty elements.  The other is to remove all empty elements from the XML message in C#.  Using a lambda expression against an XDocument is a simple way to do this:

public static string RemoveEmptyNodes(string xml)
{
XDocument xd = XDocument.Parse(xml);
xd.Descendants().Where(e => e.IsEmpty || String.IsNullOrWhiteSpace(e.Value)).Remove();
return xd.ToString();
}

As you can see, using BizTalk’s out of the box functionality with the Microsoft HL7 Accelerator for BizTalk may present some small issues, though they can be easily resolved.

We heavily use the BizTalk Deployment Framework to aid in the deployment of simple to complex BizTalk solutions.  One of the greatest benefits is the ability to run custom deployment tasks and scripts.  In previous blogs we have shown how to run a custom post deployment scripts in BTDF, today, we will show how custom scripts can be used to conditionally import a binding file during BTDF deployment.

Conditionally importing trading partner configurations is significant because when assigning a send port to a trading partner agreement, BizTalk will sometimes disallow the undeployment or re-deployment of the referenced application.  Or, in this case, the client does not want to override trading partner settings every time an application is updated.

The overall steps we will take is

1. Create binding file – in our case containing only trading partner agreements and no port or orchestration bindings
2. Update an existing BTDF project to add binding file to install directory
3. Update the BTDF installation wizard to include a new page controlling whether or not the binding import will occur
4. Update BTDF to execute an import bindings command

First, we will create the binding file.

1. Open the BizTalk Administration Console

2. Right click on the default BizTalk Application, usually ‘BizTalk Application 1′

3. Select Export –> Bindings…

4. Select ‘Export Global Party Information’

5. Select ‘Ok’, then browse to the created file

6. Within the file, remove the ModuleRefCollection, SendPortCollection, DistributionListCollection, and ReceivePortCollection nodes.  This will allow the file to only update the trading partner and agreements within BizTalk.

Next, add the file to BTDF in the default ‘Deployment’ folder created during the recommended BTDF configuration for the project. Below, the file is named ‘TradingPartnerSettings.xml’

Within the Deployment.btdf settings file, which contains all of the BTDF deployment settings, we will next add the TradingPartnerSettings file to the installation directory when installed using the MSI.  Within the ‘CustomRedist’ target, we will use the CreateItem tag to include the file in the installer, and extract into the installation directory on when installed (Copy)

  <Target Name="CustomRedist">
	<!-- Add to installer -->
    <CreateItem Include="..\Deployment\TradingPartnerSettings.xml">
      <Output TaskParameter="Include" ItemName="TradingPartnerSettingsVars" />
    </CreateItem>
	<!-- Add to install directory when MSI is executed -->
    <Copy SourceFiles="@(TradingPartnerSettingsVars)" DestinationFolder="$(RedistDir)\Deployment" />
  </Target>

This assumes that the file is located within the root of the ‘Deployment’ folder where the BTDF project resides.

Next, we will create a CustomPostDeployTarget to execute BTSTask, BizTalk’s command line utilities, to import the above mentioned binding file.

  <Target Name="CustomPostDeployTarget">
    <Exec Command="BTSTask ImportBindings /ApplicationName:$(BizTalkAppName) /Source:&quot;TradingPartnerSettings.xml&quot;" Condition="$(ImportAgreements) == 'true'" />
 </Target>
 <Target Name="CustomPostUndeployTarget" />

The above script will run BTSTask using the name of the installed application.  Even though the binding file was created from ‘BizTalk Application 1′ it will not override any bindings in the application because we have previously removed the orchestration and port bindings from the file in the above steps.  The last important part of the Exec command is the inclusion of a condition.  This specific condition will ensure that the BTSTask ImportBindings command is only executed if the variable ‘ImportAgreements’ is set to true.  You may ask, ‘What is the ImportAgreements’ variable?’  That comes next!

The ImportAgreements variable is set within the installation wizard used when deploying the application using the MSI generated by BTDF.  We will need to add a page to the installation wizard allowing us to ask the user a user the question ‘Do you want to import the trading partner bindings?’  The response will be selected using a check box, and stored in the ImportAgreements variable.  To accomplish this, we will add the following snippet into the ‘InstallWizard.xml’ file of BTDF.

  <!-- ask the question, do you want to import the trading partner bindings? -->
  <SetEnvUIConfigItem>
    <PromptText>
      Should trading partner agreements and partner configurations be imported?
    </PromptText>
    <Caption>Import trading partner agreements and partner configurations.</Caption>
    <PromptValue>false</PromptValue>
    <ValueType>Checkbox</ValueType>
    <EnvironmentVarName>ImportAgreements</EnvironmentVarName>
  </SetEnvUIConfigItem>

The SetEnvUIConfigItem node represents a page within the install wizard.  The Prompt Text is the text within the wizard page, and the caption is the text that appears next to the check box.  In this instance, we are defaulting the checkbox as ‘unchecked’, and setting the value of the checkbox to the ‘ImportAgreement’ variable, which can be used in BTSTask command.

The InstallWizard.xml file should look like this when the new SetEnvUIConfigItem has been added.

Now, when building and installing, and then executing the MSI, we can see a new page has been added to the installer

Clicking ‘Finish’ at the end of the page will complete the deployment, and import the bindings containing the trading partner information!

One of the great new additions of the recently released Feature Pack 1 for Microsoft BizTalk 2016 is a REST API, which can be used to administer BizTalk Server.  Longtime users of BizTalk may have experience with using ExplorerOM.dll or WMI based scripts to manage their BizTalk environment.  The REST API introduced in Feature Pack 1 provides a more flexible alternative, including a Swagger definition providing rapid implementation of an application to consume the API.  In this post, I will walk through the process of installing the API as well as using Swagger to generate a C# client and demonstrating a simple command.

The process of installing the management API couldn’t be simpler – a few PowerShell commands is all that is needed!  One note is that IIS is a pre-requisite, but most BizTalk environments would have this already if you have used BAM or the ESB Toolkit.

To Install the API:

• Open up PowerShell ISE as administrator
• Add the following into the script
  • First, we will set the current directory to that of the BizTalk installation.  I have included the default location below, but you should update to match your environment.

    cd 'C:\Program Files (x86)\Microsoft BizTalk Server 2016'
    

  • Next, we call the ‘FeaturePack.ConfigureServices.ps1′ script, included in the installation directory, which will install the REST API site to IIS.

    FeaturePack.ConfigureServices.ps1 `
        -Service management `
        -WebSiteName 'Default Web Site' `
        -ApplicationPool DefaultAppPool `
        -ApplicationPoolUser <your_domain\your_username> `
        -ApplicationPoolUserPassword <your_password> `
        -AuthorizationRoles '<your_domain>\BizTalk Server Administrators'
        

    I have used common IIS settings. You will want to replace <your_domain\your_username> and <your_password> with appropriate settings.  The AuthorizationRoles parameter can be any group, I chose the BizTalk Server Administrators group as I only want to allow users who already have access to the Admin Console.

• Run the script
• Open up IIS and we should see the application has been installed

• For this demonstration, we will enable Anonymous access for our client application, however this is not recommended for actual implementations.

• To ensure that our changes are active, we will reset IIS.  Open up command prompt as administrator and run ‘iisreset’

• Next, we will look at the Swagger Definition.  Open up a browser and navigate to http://localhost/BizTalkManagementService/swagger/

• The Swagger site shows all of the endpoint operations available as part of the API.  More information on the Swagger spec can be found here
• Even better, you can easily test the API and invoke any of the operations using sample input provided by the Swagger definition.  Below, I have executed a GET request for the Hosts, which shows my two host hosts; BizTalkServerApplication, and BizTalkServerIsolatedHost.

Going a step further, Swagger provides multiple ways to generate clients for several different programming languages using Swagger CODEGEN, or an online generator.  We will use the online tool to generate a C# client to can consume our BizTalk API and allow us to rapidly stand up a working application to manage the BizTalk environment.

• In your browser, go to https://generator.swagger.io/
• The operation we will use is ‘POST’ for /gen/clients/{language}.

• The POST operation by default requires a link to the Swagger site for which to generate the client code. However, we can also paste in the Swagger spec, in JSON format of course, achieving the same outcome.  To do that, we will first need to retrieve our Swagger spec.  This can be retrieved from our BizTalkManagementService  http://localhost/BizTalkManagementService/swagger/docs/v1.  This JSON string is the entirety of the Swagger spec and will be used in the next step.

• Next, we can expand the /gen/clients/{language} POST operation.  Within this section there is a sample request that can be used as a start.  Clicking on Example Value in the bottom right of the page will move it over to body text block on the left.

• Select the desired language from the language drop down, in our case ‘csharp’.  Then, instead of using the swaggerUrl value, we will replace it with “spec”: <our copied swagger definition JSON string from the previous step>.  This can be seen below.  Tip: Don’t forget the comma at the end of your JSON string pasted!

• Finally, click ‘Try It Out’ to send the request.  This should produce a HTTP 200 success, and an accompanying link to download the produced code.
• A zip file will be downloaded, unzip it with your program of choice and open up IO.Swagger.sln in Visual Studio.  I chose Visual Studio 2017.

• Finally, we will create a Console App to test our new client.

• First, add a reference to the IO.Swagger.Api project.  Below is a simple ‘hello world’ that will instantiate an instance of the HostApi class and invoke a ‘GET’ to retrieve a list of hosts in our environment and print it to the console.  This is similar to what we did in the Swagger site.

using IO.Swagger.Api;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            var api = new HostsApi();
            var hosts = api.HostsGet();
            foreach (var h in hosts)
            {
                Console.WriteLine(h.Name);
            }
            Console.ReadKey();
        }
    }
}

The output should be the same as the output from the GET request performed in the Swagger API in a previous step; BizTalkServerApplication and BizTalkServerIsolatedHost

As can be seen above, it is easy to have a working client to invoke the commands in our BizTalk Management REST API.  Microsoft’s inclusion of Swagger makes a significant difference in ease of use, reducing the difficulty in programmatically managing BizTalk Servers, especially remote servers that aren’t easily managed with ExplorerOM.

More information on Swagger can be found on their site, including other tools like an IDE, the aforementioned code generators

http://swagger.io/

http://docs.swagger.io/spec.html

https://github.com/swagger-api/swagger-codegen#generating-a-client-from-local-files

_________________________________________________________________________________________

To learn more on how Tallan can help your organization deliver a successful integration solution with Microsoft BizTalk Server 2016, CLICK HERE.

An EDI software’s ability to identify and respond to invalid X12 HIPAA EDI transactions is a major contributor to the effectiveness of EDI dependent organizations. Many healthcare companies appoint a business unit as stewards of the tens of thousands of transactions that are transmitted between payers, providers, and trading partners providing auxiliary services. These business units are often hard-pressed to respond to the quantity of incorrect claims, enrollments and payments received within their current EDI solutions or products.

The T-Connect EDI Management Suite is Tallan’s healthcare EDI product, providing actionable insight, alerting, and painless mechanisms to respond to invalid X12 EDI transactions flowing in and out of the organization. The following is a brief introduction into some of these capabilities.

The EDI solution consists of several components working in unison to introduce, augment or replace an EDI processing system.

· The T-Connect Management Portal, providing an area to track, remediate, or route EDI transactions.

· The T-Connect HIPAA Database, is a SQL Server EDI relational database used to store the full spectrum of HIPAA transactions.

· The T-Connect API rapidly parses EDI files into .Net objects and persists them to SQL Server databases.

· The T-Connect X12 Studio EDI Toolbox is an EDI development toolkit with a wide range of features that are essential to simplifying the EDI development process. There you’ll find features such as edi mapping, editing, validation, and the HIPAA Test File Generator which can generate various sample EDI files for any healthcare EDI transaction type.To demonstrate this remediation and resubmission scenario we will save an X12 EDI file with 10 837 Professional claims to the T-Connect intake folder, one of the many ways to consume and process an EDI transaction within T-Connect. This file contains 9 valid claims and a single invalid claim. The goal of the intake is to parse and persist the file into our T-Connect EDI 837 P Professional database, however as will be shown in the proceeding sections, the invalid claim will have to be fixed before it can succeed.

The below screenshot shows the home page of the site, showing all X12 EDI transaction set types currently authorized for viewing by the logged in user, in this case Administrator. This page also shows the date of last activity for a transaction set, as well as total number of successful and failed transactions.

Clicking on a row, such as 837P Claim, brings us to the next page, one level deeper in navigation to the Messages page, showing a history of processed files (transactions). We could search, sort or filter to a specific transaction, however, we can see that there was a single error out of the 10 total rows in the first entry in the rest list.

Selecting the first row from the results, we are brought to the next page (Details) showing the resulting processing history of the transaction selected. This history is represented as steps within a workflow route. These steps below provide a sample route performing WEDI SNIP Validation, acknowledgment generation, and routing of the valid and invalid records of the transaction. The route is user configurable within the portal.

In the below page, we can see an error produced by the first step, SNIP Validation, identifying one of the 10 total records as invalid. In subsequent steps, we can see the 9 valid records split out of the claim, and the single invalid record isolated within its own transaction message. The act of splitting the invalid records out of the transaction to allow the valid records to succeed is one way of processing the EDI. Another option available within T-Connect is the complete suspension of the entire transaction, in this case all 10 claims would have been prevented from completing the workflow. For our purposes, we have configured the workflow route to allow partial loading of transactions, the 9 valid claims in this case.

We are able to view the actual validation failure present within the message at the bottom of the Details page. Here we can see that the PER segment had an invalid qualifier ‘AAA’, a SNIP Type 2 HIPAA Implementation Guide Requirement Testing error, due to the qualifier not matching an expected value.

The next logical action may be to correct the now isolated invalid record for reprocessing. Correction is easily done by clicking on the X12 Studio icon to the right of the step with the invalid record, launching the X12 Studio Toolkit, an X12 EDI editor with several capabilities around the validation and manipulation of EDI transactions. Validation of the claim is done when launched, showing validation failures in the bottom console and validation results panes.

We can navigate through the file by expanding the tree nodes in the main section.

However, finding the invalid line is quite easy, done by clicking on the first row in the validation result pane. This switches the focus to the line containing the error. From this, we can see the error highlighted in segment PER, element 3 (PER03), value ‘AAA’. Not only do we clearly see the highlighted validation error, but reviewing the properties pane on the right we can see a wealth of metadata including min and max occurrences, rules, enumeration of expected values. The latter is important for our scenario, as opening the drop down list for PER03 , we can see the possible values expected for the qualifier, EM, TE, and PH.

In our scenario, the correct value for PER03, as a qualifier of PER04 is ‘TE’ for PER04’s telephone number. Selecting ‘TE’ from the list in PER03, the entire transaction is immediately re-validated resulting in the removal of the previous validation failure message.

Now that the file is valid, resubmission can commence by clicking on the ‘Resubmit’ button on the toolbar. This allows for the resubmission of the now valid file back into the T-Connect Management Suite’s services, where it is sent through the workflow route shown previously. The single corrected transaction is then revalidated, and can be seen in the portal as such.

The resubmission of the file allowed the one remaining previously invalid, also removing the previous validation failure message from the portal, though all message history and failures are retained in T-Connect for later viewing.

Summary

Tracking and resolution of invalid HIPAA EDI transactions is a powerful capability with many applications. Leveraging the T-Connect EDI Management Suite brings this and other capabilities to your fingertips.

To begin a conversation with Tallan and see T-Connect in action, contact us today to discuss how we can improve your EDI management capabilities.

TriZetto QNXT is a longstanding leader in Healthcare administration platforms, supporting many lines of business including Medicare and Medicaid.  An important function of QNXT is its strength in claim pricing, member administration and billing management.  However, the provided QNXT toolset lacks flexibility in adapting to new processing requirements.  For example, it would be difficult to perform member lookup and replacement prior to processing through QNXT’s modules.

Understanding the Workflow

QNXT utilizes Microsoft BizTalk Server to intake EDI X12 837 claims and X12 834 enrollments that are utilized in its various modules.  The files are translated from EDI to XML within BizTalk’s native EDI parsing pipeline component deployed as part of QNXT’s ‘QNXT Connect’ BizTalk Application.  The XML is then sent into QNXT where it travels through QNXT’s built-in agents and modules.

However, it is often the case that custom logic is necessary to ensure the success of the message within QNXT.  This can be due to:

• Enrichments or lookups necessary to the file, such as the previously mentioned need for a member lookup and replacement
• Conditional routing based on success or failure of the file
• Pre-validation to prevent a single failed record from causing failure of the entire transaction set

Typical Solutions, and Their Limitations

Typically there are two ways to allow for the application of custom logic within a QNXT implementation – applications deployed in BizTalk, or custom agents deployed in QNXT.

Developing BizTalk applications, while very robust and flexible, require an advanced skill set to employ effectively.  Not only does a developer have to know BizTalk, but also have a high degree of knowledge of XML in order to properly ‘work’ with the EDI.  BizTalk does not supply out of the box APIs or tools that ease the development burden when working with EDI.

Looking back at the scenario of member lookups, a BizTalk application would have to be created that would perform member lookups and replacements.  This however, would require knowledge of XPath navigation of the XML schemas used by BizTalk to update the member fields.

QNXT agents can be developed in C# .NET, and easily deployed using a QNXT provided deployment wizard.  These agents can be positioned to execute prior to processing (Pre Agent) or post-processing (Post Agent).  An executing agent has access to an XML representation of the EDI data received by  QNXT, whether claims, enrollments or other data sets.

Using an agent negates the need for specialized BizTalk knowledge, however presents several limitations that have to be overcome:

• XML: EDI is presented as XML within another XML wrapper containing file specific metadata injected by   Many layers of nesting and knowledge of XPath may present difficulty in developing an agent.
• Testing: Testing custom pre and post agents requires either attaching a debugger to QNXT or careful interpretation of log entries within the QNXT process log browser.
• Tracking: QNXT only surfaces the start and end of a custom agent’s execution, with only basic record counts and a success/failure logged.
• Maintenance: There is a wizard provided to deploy agents, however custom built agents may need frequent updates to ensure compatibility as new QNXT versions are deployed.

A Better Solution

T-Connect is a solution designed to integrate with existing infrastructure providing a robust set of APIs, databases, workflow engine and management portal allowing for rapid implementation of complex workflows.  T-Connect was built from the ground up focused on native X12 EDI support, allowing for parsing, validation, splitting, and paper form generation, along with many other features.  Several implementation scenarios are supported, such as an in-place connector into BizTalk and QNXT.

With T-Connect’s workflow engine, the task of adding custom logic is effortless, presenting a simple interface to author routes composed of several steps.  A step can receive, execute logic, and send the file to a destination.  Logic executed can consist of out of the box steps or custom steps developed using the T-Connect step framework to inject any logic into the route.  Pre-built steps included out of the box include:

• SNIP Validation and routing based on the validity of the file
• Persistence into T-Connect EDI Databases
• EDI splitting
• Data lookups and edits
• File renaming

Unlike QNXT Pre and Post agents, T-Connect custom steps have access to the full X12 EDI message, with full access to T-Connect’s robust EDI parser, validator, splitter and API tools.  Upgrades and updates BizTalk or QNXT do not require changes to T-Connect, ensuring stability of the preprocessing workflow.  Errors are surfaced directly within the T-Connect EDI Management portal, allowing seamless editing and resubmission of problem claims or enrollments.

Preprocessing EDI files is well within grasp when using T-Connect within your existing TriZetto QNXT implementation.  Our expansive set of tools and wealth of industry expertise empower your team’s ownership of the EDI lifecycle.

At Tallan, we’re always interested in discussing EDI management challenges. Reach out to us for a consultation to discuss how we can address these challenges within your current infrastructure. Looking to improve other areas of your business? We also discuss a wide variety of topics at our in-person events and webinars! 

There are several ways to intake, parse and route encounters, enrollments, payments and other HIPAA X12 EDI files. However, there are often deficiencies that become quickly apparent, as not many systems provide an adequate level of insight into the status of the in-flight files, nor do they have the tools needed to respond to issues once they arise.

Common Pitfalls

Putting on the hat of an analyst or operator tasked with ensuring that claims are successfully processed from intake to delivery, I may have a few key concerns with any system in the overall processing workflow.

• Tracking the life-cycle of claims is difficult or requires many steps
• Troubleshooting failed messages and determining root causes is time-consuming and requires both business and technical expertise to dig through complex systems
• Re-submission often requires reprocessing the entire file or manual edits to files in unfamiliar formats
• Resolving these issues commonly results in hours or days of lost productivity.

Some of these concerns originate from the system chosen to handle the EDI. Tracking may be difficult if intake, validation, transformation and routing of EDI files is performed by custom in-house applications. As is often the case, custom systems that have evolved over many years of in-house development may not provide a clear understanding as to what files may have failed, or why.

If gateway operations are performed by an integration platform or other off-the-shelf solution, then specialized expertise may be needed to translate seemingly cryptic error messages and determine the root cause of an issue.  For example, as detailed in a recent blog on EDI Reporting and Tracking, an error may be presented as several related errors referencing different files in XML format. However, without experience and knowledge in how EDI is translated into XML, the task of determining the root cause and fixing it can be quite overwhelming.

A Simpler Approach Using T-Connect

With the T-Connect EDI Management Suite, viewing the status of your encounters, enrollments and other EDI files is simple and approachable. For example, below is a screenshot showing a sampling of encounters and their statuses.

Within the Messages page of the EDI Portal, there are several things that can be accomplished:

• Drilling down to a narrower set of files by utilizing the date filters.
• Including a filter on any element within the file, such as an ID, name, or control number. The list of element names is also configurable and can include any element contained within any EDI file.

Aside from the clarity in the files that have succeeded and those that have failed, it is also just as simple a task to identify the issues within the files. The screen capture below shows the ease in viewing status of every subprocess or step that the file went through from its initial intake to its ultimate completion. Some of these steps include:

1. Intake of the file, a HIPAA 005010 837 Professional file with 10 encounters.
2. Validation of the file using WEDI SNIP rules.
3. Validation resulted in splitting of the file to extract and hold the 1 invalid encounter for later processing.
4. The 9 valid encounters were retained in another file that ultimately continued on and was persisted into the T-Connect EDI Databases.

It is important to note that we can see the validation error encountered in the file by selecting the Validation step showing the 1 in the Error Count column. This clearly shows that there was a single validation failure (SNIP 2) encountered where the PER communication number segment contained an invalid PER03 element of ‘AAA’. This level of clarity is not often obtainable with other off the shelf EDI gateways, integration platforms, or EDI processing engines.

The natural next step after identifying that an error has occurred, is to determine what can be done to remedy it, and hopefully remedy the issue without jumping through many hurdles. Thankfully, resolving the validation error is just as easy as identifying the error.

As can be seen in the screen capture below, clicking on the ‘view message’ icon opens up the currently selected file in our free EDI editor. X12 Studio presents the EDI in it’s natural hierarchical structure, along with all validation errors, and lists values for fields that require certain values selected. Generating 999 Acknowledgements and CMS 1500 and UB04 claim forms are some of the other capabilities provided by X12 Studio.

The error message shown in X12 Studio matches the error message shown in the portal previously. Clicking on the error in the ‘Validation Results’ tab highlights the PER error in the file. Selecting the PER03 element shows the 3 possible values for PER03 [EM, TE, and FX]. Now we know that the PER segment is a communication number, and the PER03 element represents the qualifier associated with the PER04 value a phone number in this case. Thus, selecting ‘TE’ from the list immediately re-validates the file and clears the error displayed.

Next up is resubmitting the now fixed encounter into the system for re-processing, also shown in the screen capture above. Re-processing, after being queued up, can be done either immediately, or as a scheduled batch for all resubmitted files. Below, we can see that after resubmission, the now corrected encounter was re-validated successfully, persisted to the T-Connect EDI Database.

Conclusion

As shown above, some of the common issues in tracking, fixing and resolving common claim, encounter and enrollment processing issues is painless with T-Connect. Powerful and complete EDI parsing and validation, alongside tracking and editing tools lower the day-to-day overhead inherent in managing complex healthcare workflows.

To begin a conversation with Tallan and see T-Connect in action, contact us today to discuss how we can improve your EDI management capabilities.

HIPAA X12 EDI transmission between the many entities in the HealthCare industry is performed using files conforming to ANSI X12 specifications. These Claim, Premium Payment and Remittance Advice EDI files may originate from payers, providers, clearinghouses, or third party administrators (TPAs). One prevalent hurdle in sending or receiving these EDI transactions is the often complex onboarding process of new trading partners.

HIPAA EDI files in X12 format may typically look similar to the sample below.

The setup process for new trading partners requires that both the sender and receiver mutually agree on the content of the header fields. The header within an X12 formatted EDI file consists of the following, shown in the first three lines of the above sample.

• Interchange Control Header Segment (ISA) – Indicates the start of at least one Functional Group (GS) and provides the various identifiers, separators, and options used to successfully parse the file interpret its contents. This is the only segment that has a fixed length.
• Functional Group Header (GS) – Indicates the beginning of a (functional) group of Transaction Sets (ST).
• Transaction Set Header (ST) – Indicates the start of a single transaction set, it’s type such as 837 claim or 834 enrollment and version, for example, 005010.

Focusing again on the sample claim file we can begin to extract the information needed for the successful consumption of the file. This requires picking out several values, but we can focus on a few notable values and their purpose.

Delimiters

• Element Delimiter – Specified by the fourth character in the file ‘*’ separates each individual element in the file. Taking the first line as an example, ISA01 is the element after the first asterisk ’00’, ISA16 is element after the last asterisk ‘:’.
• Component Element Separator (ISA16) – ‘:’ delimits elements that may comprise of multiple components.
• Segment Terminator – Specified by the character immediately after ISA16 shows that the character ‘~’ is used to separate each segment. The above sample shows one segment per line

Envelope Settings

• Acknowledgment Requested (ISA13) – Displayed by a ‘1’ or ‘0’ instructing the recipient if an acknowledgment (999) is or is not required.
• Interchange Usage Indicator (ISA14) – Labels the interchange as consisting of test (T) or production (P) data.
• Sender ID Qualifier (ISA05) and Receiver ID Qualifier (ISA07) – Both ‘ZZ’ in the sample designates the type of ID that it qualifies. A value of ’30’ would present a Tax ID designated by the IRS. ‘ZZ’ is used to signify that no particular authority assigned ID numbers, but they have been mutually agreed upon by the sender and receiver.
• Sender ID (ISA06) and Receiver ID (ISA08) – The actual identifiers for the sender and receiver, qualified by the ISA05 and 07 qualifiers.

Typical Onboarding Scenarios

By this point, you may start to realize that EDI files are pretty complex. Even the quick look through the few data elements within the first lines of the file can seem overwhelming. Indeed, the process of setting up a trading partner within most systems is an arduous process. Typically integration platforms or gateways may require you to navigate through a maze of wizards and interfaces, each requiring intimate knowledge of EDI to understand. Doing this to onboard a few partners may not present much of an issue, multiplied by tens, or even hundreds, and the time investment becomes unmanageable.

Rapid Onboarding with T-Connect

An easier way to set up trading partners is by using a partner’s EDI file and extracting the necessary values to satisfy the requisite setup. The T-Connect EDI Management Suite operates in this manner, using any X12 EDI file to create the trading partners and agreements between the partners in seconds. The partner upload feature also takes care to re-use any existing partners if the sender or receiver partner is pre-existing.

After uploading, the trading partner can be edited if desired, but is otherwise immediately used for validating incoming files – without the need to restart services or deploy artifacts!

We Can Help

The T-Connect EDI Management Suite can reduce your partner onboarding woes. But that’s just a sample of what can be achieved. Intake, validate and acknowledge EDI, tailored to you, up and running in a fraction of the time. To begin a conversation with Tallan and see T-Connect in action, contact us today to discuss how we can improve your EDI management capabilities.

The HIPAA X12 EDI specification allows for the inclusion of code values that may be pertinent to the transaction set, such as a claim or encounter. These code values can represent a data point as widespread as a postal or zip code, or as complex as diagnosis and procedure codes.

WEDI describes seven types of validation, referred to as SNIP 1-7, as covered in some of our previous blog posts on SNIP 3 Balancing of Claims and Payments. SNIP 5 – HIPAA External Code Set Testing is the validation of code values against the external code sets they represent.

SNIP 5

As previously stated, SNIP 5 validates that code value exists within an external code list. For example, if a postal (zip) code is present in a subscriber’s address, then it should align with an actual postal code in as determined by the USPS, the external entity maintaining postal codes. Additionally, the code within the transaction set must match the appropriate external code list, a postal code match with the postal code lists, for example.

Examples

ICD-10

International Classification of Diseases 10th Revision (ICD-10) defines two sets of codes, ICD-10-CM for use for coding a diagnosis, while ICD-10-PCS is used for coding a hospital procedure. For this example, we will focus on ICD-10-CM (Clinical Modification), used within the HI segment of the 2300 claim loop. The below image shows a sample claim opened in the T-Connect X12 Studio Toolbox, showing the HI segment and two diagnosis codes adhering to the ICD-10 format.

HI*ABK:E039*ABF:T8741~

The diagnosis code segment in this example represents two diagnoses, the primary diagnosis ‘ABK:E039′, and secondary diagnosis ‘ABF:T8741′. ABK and ABF serve as qualifiers to the code values, indicating that the first and second code values represent the primary and secondary diagnosis, respectively, both using the ICD-10 code list. The E039 and T8741 values are the codes that must correspond to an actual value in the external code list, as dictated by SNIP 5.

Both code lists are maintained by the Centers for Medicare & Medicaid Services (CMS) and the National Center for Health Statistics (NCHS), who also provide guidelines and the ICD-10 code lists.

HCPCS

The Health Care Common Procedure Coding System (HCPS) is a multi-level set of code lists to standardize the reporting of procedures and services within claims. Level 1 uses CPT codes governed by the AMA and Level II uses HCPCS codes covering services and procedures not covered by CPT codes.

The below screenshot from X12 Studio Toolbox shows two services lines within a single patient visit with the first service line and code 99213 pertaining to the initial patient visit.

SV1*HC:99213*40*UN*1***1~

The second service line details a strep test code 87070.

SV1*HC:87070*15*UN*1***1~

Postal Codes

Postal (Zip) Codes define postal address zones. Postal codes are represented by within the N403 element of every N4 segment in a transaction set. An 837 Professional Claim has postal codes presenting Billing Provider Postal Zone (2010AA), Subscriber Postal Zone (2010BA), Payer Postal Zone (2010BB), and Patient Postal Zone (2010CA), to name a few.

Below are postal codes as they may appear in a professional claim.

Postal codes must be present in the N403 element if the address is in the US or Canada or a Country in N404 contains a postal code.

The external code list itself is maintained by the United States Postal Service (USPS) via the Address Information System (AIS). The postal code (and state and county codes) are updated on a monthly basis. The USPS also provides a free API for postal code lookup.

And more!

The difficulty in conforming to WEDI SNIP 5 is in the number of external code lists that are included within the rule, each of which presents its own host of barriers to implementation. The above examples represent a few of the external code lists present in an 837 P claim. Other transaction set types may utilize some of the same code lists but in conjunction with their own lists.

Code lists are often maintained by entities that may require membership for access to the code lists, some may require a paid subscriptions as well. Beyond access to the code list, the effort is expended on incorporating the code lists into the system performing the validations. This is effort is compounded by code lists that may be updated regularly.

SNIP 5 Validation with T-Connect

The T-Connect EDI Management Suite provides a rule management framework which lessons the overhead of applying rules against in-flight EDI transactions. WEDI SNIP rules are supported, as well as your own custom rules and validations, all of which can be applied to specific transactions sets, trading partners or any combination of the two.

We Can Help

Intake, validate and acknowledge EDI, tailored to you, up and running in a fraction of the time. To begin a conversation with Tallan and see T-Connect in action, contact us today to discuss how we can improve your EDI management capabilities.

A quick tip today – I came across an error while trying to enlist one of my send ports while deploying a BizTalk application using the amazing BizTalk Deployment Framework.

“Could not enlist Send Port ‘X’. Exception from HRESULT: 0xC00CE557 (Microsoft.BizTalk.SnapIn.Framework)

This error is commonly caused by a erroneous carriage return and line feed in the send port <Filter> element of an imported binding file – In this case, the PortBindingsMaster.xml binding file in my BTDF deployment configuration.

Below is the original filter expression.

<Filter>
&lt;?xml version=”1.0″ encoding=”utf-16″?&gt;
&lt;Filter xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”&gt;
&lt;Group&gt;
&lt;Statement Property=”BTS.MessageType” Operator=”0″ Value=”http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo#uspUpdateBatchStatus” /&gt;
&lt;/Group&gt;;
&lt;Group&gt;
&lt;Statement Property=”BTS.MessageType” Operator=”0″ Value=”http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo#uspUpdateRecordStatus” /&gt;
&lt;Group&gt;
&lt;/Filter&gt;
</Filter>

Next is the fixed filter expression with the line break after the <Filter> tag removed.

<Filter>&lt;?xml version=”1.0″ encoding=”utf-16″?&gt;
&lt;Filter xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”&gt;
&lt;Group&gt;
&lt;Statement Property=”BTS.MessageType” Operator=”0″ Value=”http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo#uspUpdateBatchStatus“ /&gt;
&lt;/Group&gt;;
&lt;Group&gt;
&lt;Statement Property=”BTS.MessageType” Operator=”0″ Value=”http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo#uspUpdateRecordStatus” /&gt;
&lt;Group&gt;
&lt;/Filter&gt;
</Filter>

Importing the binding file anew, or redeploying using BTDF will then update the binding in the deployed BizTalk application and allow for the successful start of the application.

There are a few common deployment errors in Microsoft Visual Studio when redeploying a previously deployed BizTalk project.

“Failed to add resource(s). Change requests failed for some resource.  BizTalkAssemblyResourceManager failed to complete end type change request.  Failed to update binding information.  Cannot update receive port “”.  Transform “” not found”

There are a few other similar errors that share the same root error “Failed to add resource(s). Change requests failed for some resource” such as

“Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Cannot update assembly”

and

“Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Failed to update binding”

These all share the same root cause.  Visual Studio uses cached binding files when deploying BizTalk applications.  Removing these cached binding files will result in a ‘clean’ deployment that should resolve any binding related deployment errors.  The files are stored in

%APPDATA%\Microsoft\BizTalk Server\Deployment\BindingFiles\

Clearing the contents of this directory should resolve any deployment issues related to cached bindings.

_____________________________________________________________________________________

Learn how T-Connect EDI technology can improve 5010 processing performance in Microsoft BizTalk Server 2016 for your organization.

While building BizTalk projects within Visual Studio, it is possible to receiving the following error when trying to compile a project with multiple orchestrations:

“The namespace ‘[namespace]’ already contains a definition for ‘_MODULE_PROXY_'”

While the error seems obvious, in my case, the namespaces were indeed unique, such that the above error did not make much sense.  The underlying issue was in fact that the type names of two of the orchestrations within the project were identical.  It turns out that an orchestration was at one point duplicated, and only the namespace was changed.  After making the type names unique, the project successfully compiled and deployed.

________________________________________________________________________________________

Learn how T-Connect EDI technology can improve 5010 processing performance in Microsoft BizTalk Server 2016 for your organization.

Recently, while troubleshooting performance issues at a client, I came across a peculiar issue.  The environment in question was a multi- server environment with multiple BizTalk Servers (2010) connected to a SQL Server cluster.  The issue was extremely slow performance when trying to view, refresh, start or stop the host instances through the Administration Console.  Now usually it takes a few seconds for host instances to start, stop, or restart, however, in this case just refreshing the status of the host instances was taking over a minute.

The problem was that one of the BizTalk Servers in the group was offline for some time, causing the host instances tied to that BizTalk Server, within the same group, to become unresponsive.  This caused slowdown in viewing the host instances for any of the other servers in the BizTalk Group.

There are two ways to resolve this:

1. Turn on any offline BizTalk Servers

2. Remove the host instances for any BizTalk Servers that are no longer needed.

In our case, the second option was our chosen on, as the offline BizTalk server was no longer needed.  Once we removed the host instances from the group, the Administration Console was a lot snappier and responded quicker when refreshing, starting, or stopping host instances.

________________________________________________________________________________________

Learn how T-Connect EDI technology can improve 5010 processing performance in Microsoft BizTalk Server 2016 for your organization.

BizTalk is great in its ability to store messages within the MessageBox even after processing failure, however its not always so easy to get those messages back out!   I recently had a need to retrieve all messages that were currently suspended due to validation failures while attempting to generate X12 EDI messages using the Microsoft.Practices.ESB.

The solution is to use Windows Management Instrumentation (WMI) which can be used within PowerShell or C# to interface directly with BizTalk and easily perform administrative tasks programmatically.  For this scenario we will use C#.

The first step is to create a new console application and open up Server Explorer.

Next, right click on ‘Management Classes’ and select ‘Add Classes…’

Next add MSBTS_HostInstanceSetting, and MSBTS_MessageInstance

After the two WMI classes are added, we have to select them within Server Explorer\Servers\Management Classes\ and select ‘Generate Managed Class’ for both HostInstance and MessageInstance

This will create both classes within your solution

Below is my sample code that will first retrieve all suspended instances filtered on a specific message status.

ROOT.MICROSOFTBIZTALKSERVER.ServiceInstance.ServiceInstanceCollection instanceCollection =
ROOT.MICROSOFTBIZTALKSERVER.ServiceInstance.GetInstances(String.Format(“ServiceStatus='{0}'”, 4));

The message statuses possible are

• 1 – Ready to run
• 2 – Active
• 4 – Suspended (resumable)
• 8 – Dehydrated
• 16 = Zombies (completed with discarded messages)
• 32 – Suspended (not resumable)
• 64 – In Breakpoint

Next, we will start to iterate through each suspended instance in the collection

For each host instance, we will then extract and iterate over each instance message

ROOT.MICROSOFTBIZTALKSERVER.MessageInstance.MessageInstanceCollection messageCollection =
ROOT.MICROSOFTBIZTALKSERVER.MessageInstance.GetInstances(
String.Format(“ServiceInstanceID='{0}'”, instance.InstanceID));

Lastly, we will save each message to the file system.

message.SaveToFile(@”C:\temp\messages”);

Below is the full codebase:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

namespace ExtractSuspendedMessages

{

classProgram

{

// sample arguments: ExtractSuspendedMessages “C:\temp\suspendedmsessages” false

staticvoid Main(string[] args)

{

if (args.Length != 2)

Console.WriteLine(“Require 2 inputs.”);

else

ExtractAllMessages(args[0], Convert.ToBoolean(args[1]));

}

privatestaticvoid ExtractAllMessages(string folderLoc, bool terminateInstancesAfterSaving = false)

{

System.IO.Directory.CreateDirectory(folderLoc);

// Use integer to filter for specific suspended service statuses

//1 – Ready to run

//2 – Active

//4 – Suspended (resumable)

//8 – Dehydrated

//16 = Zombies (completed with discarded messages)

//32 – Suspended  (not resumable)

//64 – In Breakpoint

ROOT.MICROSOFTBIZTALKSERVER.ServiceInstance.ServiceInstanceCollection instanceCollection =

ROOT.MICROSOFTBIZTALKSERVER.ServiceInstance.GetInstances(String.Format(“ServiceStatus='{0}'”, 4));

//Loop through each service instance

foreach (ROOT.MICROSOFTBIZTALKSERVER.ServiceInstance instance in instanceCollection)

{

Console.WriteLine(String.Format(“Saving suspended messages for GUID: {0} with error: {1} to folder {2}”,

instance.InstanceID, instance.ErrorDescription, folderLoc));

ROOT.MICROSOFTBIZTALKSERVER.MessageInstance.MessageInstanceCollection messageCollection =

ROOT.MICROSOFTBIZTALKSERVER.MessageInstance.GetInstances(

String.Format(“ServiceInstanceID='{0}'”, instance.InstanceID));

//Loop through each message

foreach (ROOT.MICROSOFTBIZTALKSERVER.MessageInstance message in messageCollection)

{

Console.WriteLine(String.Format(“Saving Message with ID: {0}”, message.MessageInstanceID));

try

{

message.SaveToFile(folderLoc);

}

catch (Exception) { }

}

if (terminateInstancesAfterSaving)

instance.Terminate();

}

}

}

}

Running the console application with input variables “C:\temp\messages” and false

________________________________________________________________________________________

Learn how T-Connect EDI technology can improve 5010 processing performance in Microsoft BizTalk Server 2016 for your organization.

TriZetto QNXT is a longstanding leader in Healthcare administration platforms, supporting many lines of business including Medicare and Medicaid.  An important function of QNXT is its strength in claim pricing, member administration and billing management.  However, the provided QNXT toolset lacks flexibility in adapting to new processing requirements.  For example, it would be difficult to perform member lookup and replacement prior to processing through QNXT’s modules.

Understanding the Workflow

QNXT utilizes Microsoft BizTalk Server to intake EDI X12 837 claims and X12 834 enrollments that are utilized in its various modules.  The files are translated from EDI to XML within BizTalk’s native EDI parsing pipeline component deployed as part of QNXT’s ‘QNXT Connect’ BizTalk Application.  The XML is then sent into QNXT where it travels through QNXT’s built-in agents and modules.

However, it is often the case that custom logic is necessary to ensure the success of the message within QNXT.  This can be due to:

• Enrichments or lookups necessary to the file, such as the previously mentioned need for a member lookup and replacement
• Conditional routing based on success or failure of the file
• Pre-validation to prevent a single failed record from causing failure of the entire transaction set

Typical Solutions, and Their Limitations

Typically there are two ways to allow for the application of custom logic within a QNXT implementation – applications deployed in BizTalk, or custom agents deployed in QNXT.

Developing BizTalk applications, while very robust and flexible, require an advanced skill set to employ effectively.  Not only does a developer have to know BizTalk, but also have a high degree of knowledge of XML in order to properly ‘work’ with the EDI.  BizTalk does not supply out of the box APIs or tools that ease the development burden when working with EDI.

Looking back at the scenario of member lookups, a BizTalk application would have to be created that would perform member lookups and replacements.  This however, would require knowledge of XPath navigation of the XML schemas used by BizTalk to update the member fields.

QNXT agents can be developed in C# .NET, and easily deployed using a QNXT provided deployment wizard.  These agents can be positioned to execute prior to processing (Pre Agent) or post-processing (Post Agent).  An executing agent has access to an XML representation of the EDI data received by  QNXT, whether claims, enrollments or other data sets.

Using an agent negates the need for specialized BizTalk knowledge, however presents several limitations that have to be overcome:

• XML: EDI is presented as XML within another XML wrapper containing file specific metadata injected by   Many layers of nesting and knowledge of XPath may present difficulty in developing an agent.
• Testing: Testing custom pre and post agents requires either attaching a debugger to QNXT or careful interpretation of log entries within the QNXT process log browser.
• Tracking: QNXT only surfaces the start and end of a custom agent’s execution, with only basic record counts and a success/failure logged.
• Maintenance: There is a wizard provided to deploy agents, however custom built agents may need frequent updates to ensure compatibility as new QNXT versions are deployed.

A Better Solution

T-Connect is a solution designed to integrate with existing infrastructure providing a robust set of APIs, EDI databases, workflow engine and management portal allowing for rapid implementation of complex workflows.  T-Connect was built from the ground up focused on native X12 EDI support, allowing for parsing, validation, splitting, and conversion of EDI to CMS 1500 form (PDF), along with many other features.  Several implementation scenarios are supported, such as an in-place connector into BizTalk and QNXT.

With T-Connect’s workflow engine, the task of adding custom logic is effortless, presenting a simple interface to author routes composed of several steps.  A step can receive, execute logic, and send the file to a destination.  Logic executed can consist of out of the box steps or custom steps developed using the T-Connect step framework to inject any logic into the route.  Pre-built steps included out of the box include:

• SNIP Validation and routing based on the validity of the file
• Persistence into T-Connect EDI Databases
• Splitting EDI files
• Data lookups and edits
• File renaming

Unlike QNXT Pre and Post agents, T-Connect custom steps have access to the full X12 EDI message, with full access to T-Connect’s robust EDI parser, validator, splitter and API tools.  Upgrades and updates BizTalk or QNXT do not require changes to T-Connect, ensuring stability of the preprocessing workflow.  Errors are surfaced directly within the T-Connect EDI Management portal, allowing seamless editing and resubmission of problem claims or enrollments.

Preprocessing EDI files is well within grasp when using T-Connect within your existing TriZetto QNXT implementation.  Our expansive set of tools and wealth of industry expertise empower your team’s ownership of the EDI lifecycle.

Learn more about Tallan or see us in person at one of our many Events!