Tallan's Blog

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

Posts Tagged "edi"

A HIX 820 Overview

When the Health Insurance Exchange (HIX) network went online in late 2013, the industry was challenged with reconciling new subscribers to their related premium payments and subsidies. Health plans painstakingly assembled Excel eligibility extracts to invoice their Federally Facilitated Marketplace (FFM) or State-based Exchange (SBE) for tax credit reimbursement. However, by the start of 2016, the FFM became the system of record for eligibility, and issuers were required to accept a new variant of EDI representing premium payments.
Traditionally, the 820-Payment Order / Remittance Advice transaction (005010X218) has been transmitted from payroll agencies and government healthcare organizations to insurers in order to provide summary or subscriber-level information regarding premium payments. With the advent of ACA exchanges, enough variations surfaced in this traditional handshake that a new version of the 820 was required. The HIX 820 (005010X306) removes structures unnecessary for exchange reporting, and adds tracking segments for the unique aspects of these plans, such as…

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

Generate HIPAA EDI Testing Files – 4 Easy Steps!

Paul Gutierrez

Need a way to test your systems without compromising patient data? Creating Electronic Data Interchange (EDI) test files from scratch can be an extremely time-consuming option. This leaves many searching for downloadable sample files that often contain only the mandatory loops and hinder the scope of your HIPAA EDI testing.
Fortunately, today’s Healthcare EDI professionals can find an EDI Management Platform to help alleviate their HIPAA compliance headaches.
The T-Connect EDI management suite features the X12 Studio EDI Toolbox, an EDI development toolkit with a wide range of features that are essential to simplifying the EDI development process. There you’ll find the HIPAA Test File Generator which can generate various sample EDI files, for any healthcare EDI transaction type, in the blink of an eye.
This post will demonstrate how to generate EDI test files in X12 Studio EDI Toolbox

1. The process for utilizing the HIPAA Test File Generator is straightforward. To start, click on the “HIPAA Test File…

Splitting 835 Healthcare Claim Payment

The Electronic Data Interchange (EDI) consists of a file in a specific format that represents data exchanged in a transaction from supply chain to healthcare. EDI 835 Claim Payment transaction provides payments information in reference to claims in EDI 837 Healthcare Claim format. The details include transactions such as charges, deductible, copay, payers, payee, etc. The information is stored a hierarchical structure. The standard of EDI format is well defined and the complexity can be very overwhelming. Additionally, we do not want this high degree of detail slowing our processing time.
One of the problems that enterprise systems face with EDI is file size. A single EDI 835 may contain multiple claim records and the quantity of claims in a single file can make it very difficult to process the file. Systems are often bogged down when dealing with a very…

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.
The…

SNIP 3 835 Balancing

835 and 837 EDI transactions have transformed the adjudication cycle for providers and health plans over the last two decades, but challenges remain in reconciling payments with claims. Recently, we’ve broken down the requirements for SNIP 3 claim balancing. Today we’ll focus on the 835 Claim Payment/Remittance Advice. Health plans submit 835s to providers (or their intermediaries) to explain which claims are being paid, and any reductions to the submitted amount and the reasoning for the adjustment. This is an important function – a significant pain point experienced by providers is the reconciliation of their income against claims submitted.
Before this valuable information can be loaded in practice management software, the 835 should pass validation checks. Common issues affecting 835s are balancing errors between the header and detail payment amounts. Imbalanced 835s lower the quality of reporting and can lead to billing…

EDI: Still Essential After All These Years

Tallan Partner

Back in 2011, Gartner analyst Benoit Lheureux wrote a blog post titled: “EDI is Hot, No, Really!”
That was probably stretching it then and six years later…well, let’s just say “hot” is perhaps overstating it. But there’s no overstating the continued importance of EDI to many businesses.
“Bottom line: EDI remains — and will remain for years to come — a high impact, valuable asset to business,” Lheureux wrote in his report. “… EDI is a well-established approach that is still a vital component of most companies’ overall B2B strategy and easily contributes to B2B, cloud computing, business intelligence, et al.”
Like the Internet, EDI has its roots in the military. The scale and complexity of the 1948 Berlin airlift required the exchange of information about transported goods—over a 300-baud teletype modem, no less. The effort led to standards that eventually became EDI as…

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…

\\\