HealthCare.gov: Boat of Gloat v.5b

The failure of HealthCare.gov is epic and groWING. We are 25 days past the live date and the number of enrollments are still at a trickle. The administration is trying to stifle all reports of actual enrollments because they are in a fog and because it is embarrassing.

The House of Representatives held a hearing on what went wrong this week and there were several vendors present, all pointing fingers at one another and at the government, who was apparently in charge of integration testing, or end-to-end testing. We've also learned that there are major flaws in every major part of the system regardless of the claims of the vendors. Worse than the technical problems, the management failures at all levels of this project are classic and numerous. A nice case study for academics to pour over for a generation.

There is so much goodness to discuss (by goodness, I mean badness), it can make one dizzy. Today, I want to focus on the data corruption issues with the electronic enrollments being sent to insurers, for those lucky few that make it all the way. To understand what is happening, you need to start in 1996 with the enactment of HIPPA. HIPPA was supposed to simplify and speed up health care transactions, and improve patient privacy. A set of data standards were published for all health care organizations to use for standard transactions like: enrollment, disenrollment, claims, payments, benefit inquiries, etc. Each transaction was assigned a number. An electronic enrollment is an 834 transaction. A claim is an 837 transaction. An eligibility inquiry is 270 and the response is a 271 transaction.

The data specification for each transaction type, when printed, fills a large binder. I implemented and maintained an EDI claims system for dental billing from 2003-2004 so I know many of these formats intimately. In general, each transaction consists of a set of variable length records. There is usually a header record to start, followed by a variable number of information record types or segments, followed by a trailer record. The headers and trailers are easy. The segments are variable length, with a variable number of elements, separated by asterisks (*). Segments are separated by tildes (~). Beyond deciphering the correct format, each insurer may or may not have been in 100% compliance with the standard. Some required extra segments or special values in certain elements or they would reject the transaction. It was not enough to be in 100% compliance with the standard, you also had to handle the quirks of each insurer's IT and transmission requirements. All transactions were supposed to be encrypted (we used PGP) and files were exchanged via FTP or dial up. I worked with about 25 different insurance companies and it was a nightmare. HealthCare.gov has to deal with hundreds or maybe a thousand on the back end. Major nightmare.

Here is what a partial HIPPA transaction looks like:

ISA*00* *00* *ZZ*CALIFORNIA-DHCS*ZZ*777888999 *111025*1127*^*00501*000000001*0*T*:~GS*BE*CALIFORNIA-DHCS*777888999*20111025*112755*1*X*005010X220A1~ST*834*0001*005010X220A1~BGN*00*DHCS834-DA-20110712-777888999-001*20111025*11275500****2~QTY*TO*6~N1*P5*California Department of Health Care Services *FI*68-0317191~N1*IN*Medical Plan 123*FI*777888999~INS*Y*18*001*AI*A*C**AC~REF*0F*12345678C~REF*1L*111111111~REF*23*0;20100204;~REF*3H*11101111111373;;~REF*6O*Q;;A;Y;A;11;78~REF*F6*010203040A~REF*DX*B5555;E777;20110323~NM1*IL*1*MCGEORGE*GEORGE*G~PER*IP**TE*7025551212~N3*777 GEORGE AVENUE APT 222~N4*LOS ANGELES CA*CA*900201111**CY*19~DMG*D8*19570709*M**:RET:2106-3~NM1*31*1~N3*PO BOX 12345~N4*LOS ANGELES CA*CA*900481234~HD*021**HLT*123;01~DTP*348*D8*20110901~DTP*349*D8*20110930~REF*17*D;49101;;;~REF*9V*3;2;2~REF*CE*10;001;80;301;;;;~REF*RB*10~REF*ZX*19~HD*021**HLT*123;01~DTP*348*D8*20110801~DTP*349*D8*20110831~REF*9V*3;2;2~REF*CE*10;301;80;301;;;;~REF*RB*10~REF*ZX*19~HD*001**HLT*123;P4~DTP*348*D8*20110701~DTP*349*D8*20110630~REF*9V*3;1;2~REF*CE*14;001;80;891;;;;~REF*ZX*19~INS*Y*18*001*AI*A*E**AC~REF*0F*23456789E~REF*1L*222222222~REF*17*201205;~REF*23*1;20061214;~REF*3H*193NXXX7772101;SMITH AMY;038~REF*6O*A;;A;Y;;11;~NM1*IL*1*PLANK*FRAN*M~PER*IP**TE*2135551212~N3*THIS IS LINE ONE OF THE ADDRESS*123 FRANCIS LANE~N4*LOS ANGELES CA*CA*900391111**CY*19~DMG*D8*19841125*F**:RET:2106-3~HD*021**HLT*123;01~DTP*348*D8*20110901~DTP*349*D8*20110930~REF*17*N;49201;;;~REF*CE*3N;401;;;;;;~REF*RB*3N~REF*ZX*19~HD*021**HLT*123;01~DTP*348*D8*20110801~DTP*349*D8*20110831~REF*CE*3N;401;;;;;;~REF*RB*3N~REF*ZX*19~HD*021**HLT*123;01~DTP*348*D8*20110701~DTP*349*D8*20110731~REF*CE*3N;401;;;;;;~REF*RB*3N~REF*ZX*19~HD*021**HLT*123;01~DTP*348*D8*20110601~DTP*349*D8*20110630~REF*CE*3N;401;;;;;;~REF*RB*3N~REF*ZX*19~HD*021**HLT*123;01~DTP*348*D8*20110501~DTP*349*D8*20110531~REF*CE*3N;401;;;;;;~REF*RB*3N~REF*ZX*19~INS*Y*18*001*AI*A*E**AC~REF*0F*34567890D~REF*1L*333333333~REF*17*201203;~REF*23*8;20050531;~REF*3H*197JQQQQ555103;WHITE JESSICA;051~REF*6O*A;;W;Y;;56;~NM1*IL*1*PUNTER*GUNTHER~PER*IP**TE*9165551212~N3*69001 BRIAN WAY~N4*SACRAMENTO CA*CA*958141234**CY*19~DMG*D8*19900817*M**:RET:2054-

When you read about insurers getting bad data for enrollments, they are getting 834 HIPPA EDI transactions that don't work in their systems. In some cases it is bad data, meaning the format might be OK, but the data is incorrect. In some cases, the format might be right, and the data might be right, but the insurer is not 100% compliant so it fails in their system. In some cases, the format might be wrong, but the data is right. In other cases, the format might be wrong and the data may be wrong. Multiplied by as many insurers as receive transactions from HeathCare.gov. And this is only one small part of the processing on the back end.

Kathleen, this boat's for you!