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.
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…
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.
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.
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…
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,…
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.
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.
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…
Dell Boomi’s AtomSphere integration platform provides a simple, yet very powerful feature – the ability to utilize temporary, and semi-temporary files system folders. Coming from a Microsoft BizTalk integration background, the ability to store documents to a temporary directory is a huge advantage over storing into a database such as the BizTalk MessageBox, especially with larger files. While BizTalk does provide the necessary mechanism to save files to a local folder through the use of the file adapter, Boomi provides an easier way of achieving this.
The Tallan Integration Practice heavily utilizes Azure Infrastructure as a Service (IaaS) virtual machines for quickly setting up isolated environments for prototypes and BizTalk development environments. However, with so many virtual machines it is often difficult to remember to shut them off when not needed. With Azure‘s Automation features, we can setup a scheduled job to shut down non mission critical VM’s, saving on hosting costs.