Jeffrey Zients, the advisor appointed by the Obama administration to lead repairs of the troubled Healthcare.gov website, faces a daunting task to have the EDI portion working "by the end of November," as promised last Friday.

EDI (Electronic Data Interchange) is a way of electronically moving data between two organizations in the form of small, tightly-organized packets. EDI is often the best solution when you need to move large quantities of data about standard transactions regularly, so it's no surprise that the insurance industry uses EDI to exchange enrollment information on millions of policy enrollees.  '834' is a code for a type of EDI message that is tailored specifically for the healthcare industry.

The purpose of the 834 message for Healthcare.gov is to route information about new enrollees to insurance companies. Sending an 834 is the last thing Healthcare.gov does in the enrollment process -- from that point forward, the insurance companies theoretically have everything they need to enroll the new policy holders. The 834 contains information on each enrollee such as name, address, family members, enrollment plan and other details.  It is critical that the 834 messages are formatted properly, contain correct information, and are processed correctly by the insurance companies. Given that 7 million people are expected to sign up on Healthcare.gov in the next few months, if there are any mistakes in the 834s, potentially hundreds of thousands of people could have their enrollments jeopardized.

The 834s receive a lot of attention because they are the only means insurance companies have of receiving data about enrollees from Healthcare.gov.  So far there have been two main problems with the 834s. The first is that since Healthcare.gov's start on October 1^st, only a tiny number of 834s have been sent to insurance companies. The number of 834 messages received by the insurance companies corresponds closely to the number of people who have successfully enrolled. The second is that those 834s that have made it have not been correctly formatted, causing them to error in the insurance company's systems.

In response to the bad EDI data, some of the insurance companies resorted to manually entering the data into their systems. This solution is not viable in the near-term, given that millions are expected to sign up in the next few months. Insurance companies simply are not equipped to manually process 834s.

Below is an example of how the President's 834 would look if he were a single man and signed up on October 1^st for a Gold Plan that started on January 1^st 2014.  You can see how difficult it would be for a clerk at an insurance company to read and then manually enter just one of these into an insurance company's system.   

ST*834*0001~

BGN*00*9999*20131001*0900*ET***2~

N1*P5**F1*813129667~

INS*Y*18*021*28*A*E**FT~

REF*0F*987654321~

REF*1L*GOLD PLAN 12345~

DTP*356*D8*20140101~

NM1*IL*1*OBAMA*BARACK*H***34*123456789~

PER*IP**HP*2024561111~

N3*1600 PENNSYLVANIA AVE NW~

N4*WASHINGTON*DC*20006~

DMG*D8*19610804*M*S~

HD*021**HLT*01A1*EMP~

DTP*348*D8*20140101~

SE*15*0001~

This is assuming that the only problem that exists is that the format of the 834s is incorrect.  Based on news reports about the problems in Healthcare.gov, the data contained in the incorrect format may not be correct either.

EDI is a powerful tool that automates exchanges of information, but its downside is its unforgiving nature that makes the initial installation phase time-consuming and costly.  Here are the three biggest hurdles to getting the EDI portion of the project working by the end of November.

1) Time-Consuming Testing Required 

It is difficult to predict how long testing is going to take when installing EDI. By definition, you test new software because it is very complicated and you can't be certain how it is going to act once faced with real-world inputs.  There are 78,437 policy variations that can occur on Healthcare.gov website.  This does not mean that you will need 78,437 test scenarios, because a single EDI test scenario will cover several thousand of these variations. It does mean, however, that you need a robust and thorough test plan, because the EDI will need to be able to process all 78,437 policy variations, and every possible type of enrollee family circumstance.

A typical EDI test plan might look like the following:

Scenario 1: Single Person, no dependents, policy #123456

Scenario 2: Single Person, 1 dependent, policy #123425

Scenario 3: Married Couple, no dependents, policy #223456

Scenario 4: Married Couple, 1 dependent, policy #323456

And on and on

What makes EDI testing between companies so time-consuming is that if any one test scenario does not process properly, both parties involved must troubleshoot through an exchange of e-mails or conference calls to determine which of the two parties caused the issue.  The change to fix the problem might in turn precipitate another problem because sometimes you cannot be certain of how the code will react to the change, so the testing of that scenario must be started over again until both parties determine the scenario is working. Thorough, exhaustive testing of every scenario is important in this case because of the importance of the data involved and the sheer volume expected. The much-publicized situation in which a Healthcare.gov 834 reported an enrollee's children as his spouses is a symptom of not conducting thorough EDI testing

2) Many Parties Involved

An EDI project between just two parties is complex. This project involves dozens of different insurance companies who receive the EDI for 36 different state exchanges. This complicates the testing enormously because, as mentioned above, each possible EDI 834 scenario has to be tested with each of the insurance companies involved.  

If there are any changes to the Healthcare.gov 834s, the testing of each affected scenario must be completed all over again for all of the parties involved. Moreover, EDI testing does not necessarily take place on the timeline of Healthcare.gov. It takes place at the pace of the slowest of the parties involved. The level of urgency, technical competency and amount of technical resources available for EDI varies dramatically among companies.  Some of the insurance companies will be able to complete the testing quickly if few EDI changes are needed and their EDI staff know what they are doing. Other insurance companies, who might lack in-house EDI expertise and have a glacial work pace, will likely lag behind and install dates will be delayed.

3) Changing Internal Architecture

The most challenging aspect to fixing the Healthcare.gov EDI is that the EDI developers don't have a stable platform on which to build their software. EDI software is often called a translator because it translates the internal data format into the external 834 messages that are sent out to insurance companies. According to news reports, the internal workings of Healthcare.gov are a mess, so the internal data architecture will have to be changed over the next few weeks. In other words, the internal data format on which the EDI software is being built is changing. This makes life particularly difficult for EDI, because now you have to adapt to not only the other party's ability to read your 834s, but also to your own ability to create the 834s. Changing the internal data architecture that the EDI translators are built on, without proper coordination with the receiving party, is like assembling a pre-fabricated house at a factory, then showing up to the construction site only to find that the foundation was poured in a different configuration than the original blueprints.

Each change to the internal data architecture can potentially impact the EDI that will be sent out, which in turn means testing again with each of the 30 insurance companies for each scenario that is affected by the internal change.  If you do not conduct these tests and make sure the outcomes are what you expect, you risk potentially sending bad EDI data in production. In other words, changes to the internal data architecture has a cascading effect down to the EDI.  

Given the effort that will be required for the EDI portion of Obamacare, it seems unlikely the EDI will be working by the end of November for all of the insurance companies involved.  

The most likely outcome for Healthcare.gov at the end of November is a Potemkin Village website where the user appears to have smooth sailing but the inner workings are a teetering Rube-Goldberg machine. The EDI will likely to continue to be very problematic, particularly for those with unusual family circumstances or who sign up for policies with smaller insurance companies who lack EDI expertise. The goal will be to have a website that appears to function, so that any blame for problems can be shifted to the insurance companies.

Given the time-consuming nature of EDI testing, the number of insurance companies involved and the changing internal architecture, Healthcare.gov faces an enormous challenge fixing just the EDI portion of the project within 5 weeks. At the very least, an EDI project of this size would require 6 months of work. The next 5 weeks, meanwhile, will be interesting to watch.

West Coast EDIGUY is the pen name of an author with over 5 years of experience in the EDI world.