Tallan's Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

Posts Tagged "x12"

TriZetto QNXT – EDI Reporting and Tracking

Each day health plan administrators look forward to the challenge of loading 834 enrollments and 837 claims into their adjudication systems.
From a distance, it seems simple to report and reconcile the EDI transactions submitted by providers and clearinghouses through a plan’s intake workflow. Drilling into the steps along the inbounding process, challenges emerge which can present insurmountable obstacles to answering a question as basic as: How long has this claim been held up in my intake process?
TriZetto QNXT is a common adjudication platform we’ll use to illustrate this point. In a typical workflow, loading claims might involve:
Handoff: The day’s 837s are pulled from an SFTP server and moved to the start of the intake process.
Archive: Move files into processing workflow, and archive a copy.
EDI Structural Validation – Basic checks are performed to ensure the 837 transactions are well-formed. This level of validation is…

Notes from the 2018 WEDI Spring Conference

This year’s WEDI Spring Conference mixed deep dives into emerging X12 standards with sessions centered on Open APIs and a greater unification of clinical and administrative data. Here are a few of the topics that jumped out at me, with some thoughts on what these trends might mean for T-Connect customers.
FHIR – The maturing FHIR standards arguably represent the most dynamic developments in HIT at present. FHIR (Fast Healthcare Interoperability Resources) is set of specifications developed by HL7 that most immediately concerns clinical data in EHR systems, but also extends to the exchange and content of administrative transactions, such as claims and eligibility requests.
FHIR is an implementation of modern web standards present in most other industries:

XML and JSON messages
OAuth 2.0 as the security mechanism

FHIR also defines resources which represent discrete data elements. Here’s a partial view of a FHIR claim resource:
It’s important to note that these standards are…

Claim Balancing – SNIP 3 for 837s and Post-Adjudicated Encounters

Ensuring that 837 EDI transactions meet validity checks is critical to improving auto-adjudication and encounter submission acceptance rates. SNIP Type 3 describes the rules for balancing header and detail levels of the Claim, Premium Payment and Remittance Advice transaction sets. Previously, our blog covered the logic required to balance 835 transactions. Now we’ll look at the steps necessary to balance claims with service lines, including Coordination of Benefits loops in multiple payer scenarios.
Claims and encounters may be represented by a variety of X12 transaction types: 837 Professional, Institutional and Dental, as well as their corresponding post-adjudicated variants (298, 299, 300), intended for submission to All-Payer Claims Databases. The following logic applies to all versions of the 837 equally, with a few caveats noted below.
Rule 1 – Balancing Claim Charge Amounts
The first claim balancing rule is straightforward: given the parent-child relationship of 2300 claim loops to their 2400 service…

Edit and Resubmit X12 HIPAA EDI with the T-Connect Management Suite

Kevin Morillo

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

All-Payer Claims Database Submission – Common Data Layout and PACDR X12

As we strike out into 2018, the implementation of All-Payer Claims Databases (APCD) across states remains variable and dynamic. Massachusetts maintains a comprehensive implementation, aggregating data feeds from over 80 public and private payers.  Massachusetts has leveraged their APCD to create a state-specific risk adjustment model to meet the ACA provision which balances funds from healthier populations to higher risk pools. Late in 2016, Minnesota concluded a feasibility study which determined their APCD could significantly improve risk adjustment vs. the federal model.
On the other hand, West Virginia and Tennessee have put APCD development on hold. California payers optionally submit claims and encounters to a public benefit corporation. Legal, fiscal and political concerns guarantee a fluid situation for insurers.
This blog post is focused on the technical obstacles that health plans face in states requiring APCD submission. Since these databases have phased in over the last decade through both voluntary and legislated…

X12 EDI Databases for HIPAA Transactions

The X12 HIPAA transaction set is used across the healthcare industry to transmit claim, enrollment and payment information. Given the importance and ubiquity of these EDI files, you might assume that translating them from ANSI to a relational database format would be well-supported with a range of options.
In practice, a task as common as parsing a claim or encounter and storing it in a database can quickly escalate into a significant problem.
One solution we’ve seen involves archiving a snapshot of the EDI file using filestream storage. This can satisfy some retention requirements, but provides little in terms of fine-grained tracking or analytic capabilities.
A more complete approach is to parse the X12 file into its discrete elements and store them in a relational database. The ideal solution captures the full extent of the EDI transactions while also applying a reasonable leveling of flattening to keep in the number of table joins under control.

Dell Boomi X12 Trading Partner Feature Overview

Mike Agnew

The Dell Boomi AtomSphere provides users with the ability to create and configure trading partners for EDI transactions. Users can create trading partners to be used with the X12 Interchange format.
The X12 Interchange Format is a standard used for the sending and receiving of EDI files, it allows us to define different pieces of information about the file and communicate information about what is expected of the file between the respective trading partners. It uses the ISA and GS segment definition headers within sent EDI messages to set this information.
This post will cover how to create a basic X12 Trading Partner and the different configuration options available for them.
First we can create our trading partner by creating a new component and selecting “Trading Partner”, we can configure items such as the name and whether or not this is our company…

Considerations About HL7 Integration

On the provider side of healthcare integration, HL7 (particularly v2) is a critical message type to understand. While it is standardized and heavily used by various EHRs/EMRs, it’s used in slightly different ways. There are efforts to further standardize and normalize its use across the board (such as with v3/FHIR), many EHRs and EMRs continue to use 2.x messages.  Common HL7 messages include admissions/transfer/discharge (ADT), scheduling (SIU), lab orders and results (ORU, ORM), and medical reports (MDM).  Choosing the right platform can be challenging.
Some of the challenges of HL7 2.x messages include:

The ability to add non-standard custom segments or additional data anywhere in the message (whether they are completely custom “Z Segments” or other segments that aren’t typically part of the message, such as IN1 segments in an ADT message to include additional insurance information).
A myriad of parsing and manipulation libraries…

Working with HIPAA Professional Claim (837P) Messages in BizTalk (Part2)

Dan Field

In the last post, I wrote about the overall structure of 837P claim messages.  837I and 837D messages have similar structures, though with some differences – for example, the 837I has many more diagnosis code options, and the 837D has more specific nodes for tooth identification, etc.  One important thing to note is that 837P, 837I, and 837D files are very similar, but not the same.  It’s not enough to simply change the version numbers in the GS and ST segments and then try to process one the same as the other!  If it were that easy, we wouldn’t need separate schemas for them in BizTalk!
BizTalk provides out of the box functionality to support these message types, with well developed functionality to translate the X12 EDI to XML and vice versa.  The schema nodes also have friendly names, translating something like this:

Working with HIPAA Professional Claim (837P) messages in BizTalk (Part 1)

Dan Field

Updated: part 2
Application integration is challenging in that it requires a wide breadth of knowledge: server and network architecture, object oriented programming and design patterns, messaging and communication patterns, workflow design, message translation, database design and programming, business rule processing, data validation and quality handling… the list goes on and on.  On top of that, it’s important to be familiar with the data you’re working with from various sources and feeds to be able to effectively transform it.
EDI presents a whole host of challenges, and the 837 Professional, Institutional, and Dental transactions are among the most challenging to grapple with.  This will be the first in a series covering a high level introduction and overview of the 837 Claim format in the BizTalk HIPAA EDI schemas.  It is not quite going to the level of a competent EDI Analyst, but…