Home > EDI Integration, General EDI > EDI and Healthcare.gov
 

EDI and Healthcare.gov

November 23rd, 2013

The technical glitches of healthcare.gov, America’s new insurance marketplace have been widely reported in the news. Some of the problems stem from the EDI transmissions used by healthcare.gov to communicate enrolment data to health insurance providers. In this post, I’ll describe the EDI transmissions used by the new marketplace and summarize a few of the problems that cropped up.

There are two types of EDI documents in use with the new marketplace: 834s and 999s. “834” is an EDI code that refers to a benefit enrolment and maintenance document. When a shopper on healthcare.gov chooses an insurance plan, the marketplace is designed to send an 834 to the insurance provider selling the user’s selected plan. This document contains information like the user’s name, their address, their phone number, their spouses or children on the plan and other details that the insurer needs to complete the enrolment.

Once an insurer receives an 834 from healthcare.gov, they respond with another document called a 999. 999s are an acknowledgement that the provider received the 834. The 999 tells healthcare.gov that the 834 was accepted by the insurance provider, that it was rejected or that it was accepted with errors. When the user pays their first premiums, the healthcare provider sends an 834 to healthcare.gov to confirm that the customer completed their enrolment. The marketplace responds with a 999 to acknowledge the insurer’s 834.

These EDI transmissions are backed up by an translator that converts the data into XML, a format that the marketplace’s systems can read. The Center for Medicare & Medicaid Services (CMS) has published an diagram that shows how this all works:

Healthcare.gov went live on October 1. At first, there were technical problems unrelated to EDI and very few people were able to enrol in plans. However, meeting minutes show that EDI problems quickly became apparent as the marketplace began to work properly. In a meeting on October 8th, administrators noted that “Issuers are not receiving 834s when they should be.”
An EDI dashboard was created to monitor the success rate of transactions, however the dashboard did not provide cumulative data. Again, this is described in the meeting notes from October 8th:
“News websites are reporting issuers who say they are receiving flawed 834s; because we use a daily dashboard, it is hard to see the cumulative number of 834s sent out that we don’t have a response back for.”
They added that: “There were 700+ enrollments last night. There are 300+ failed 999s”.

Other EDI problems that were reported after go-live included duplicate 834s, 834s with incorrect relationships — for example, one man was reportedly recorded as having three spouses — and 834s that lacked important information, like county codes. In some cases, the minutes show that issues that were identified through EDI may have been rooted in upstream components of the marketplace, like the XML provided to the EDI translator.

In hindsight it is easy to say that extra testing would have been beneficial for healthcare.gov before it went live on October 1. It seems like it was especially challenging for administrators and insurers to resolve EDI problems after the website had already been launched. You can read more about the EDI issues with healthcare.gov on the Washington Post blog and here at CNN.com.

EDI Integration, General EDI , , , , ,

  1. Tony
    | #1

    Problem is clear: architecture of the EFT system. A flat-file integration will never create a reliable solution.

    The EFT syste, is blindly placing files in temporary holding, with the Issuers accessing these files, operating on them, then providing more flat-files back to the HUB via EFT. In this configuration, the Hub, and the Issuers, have no choice but to assume that all information was successfully and accurately communicated.

    This is clearly an integration method from the early 90’s, and will not be a viable solution.

  1. No trackbacks yet.