Obamacare: a lesson in data entry design

The Patient Protection and Affordable Care Act health insurance system (better known as Obamacare) currently being rolled out in the United States is about as complex a project as any data professional is ever likely to face. State-specific portals must be consolidated into a federal data hub, and data from that hub is validated against a number of other data resources, including those holding social security, justice, security and financial data for each individual. Unfortunately, its implementation has been plagued by problems, widely reported and too often experienced by the people trying to register with the system.  Servers have crashed, websites have crawled, security has failed, coding has been poor.

A dog’s life

Evidence suggests that at the site’s back end, data is being injected into other systems garbled and full of errors, complete with syntax errors, transposed data, and duplicates, so that insurance companies are having to create procedures to contact customers directly to check and correct data errors.

More interesting to me have been the failures in data entry systems and in managing the data, aspects which are much closer to the hearts of the customers, and the anecdotes make interesting reading.  One man, for example, trying to create health cover for himself, managed instead to insure his dog.

Remarkable also are the reports of poor personal name and address validation. For example, enter the (disguised) address:

1234 Angeles Drive North

and be faced with an uneditable “correction” to:

1234 Angeles Dr

The system also expects 9-digit ZIP+4 codes, which not all Americans know or use.

Personal name validation is also causing problems. Systems are reportedly not allowing double given names, or middle names used as personal names. Customers using their middle names instead of their first given names (quite common in the USA) are not being allowed to enter their names with an initial because the first given name must be longer than one character. Punctuation is being disallowed.

It is clear that some basic errors have been made in designing the system, and that the developers have considered the process more than the people. Validation, where possible, should be done interactively with the customer, but when the validation fails (and there will always be examples where it does) then customers need to be able to override it.  Designing a system which can allow 95% of the population to add their name, but shuns the other 5%, is never going to be acceptable. Other processes should be removed from the front end so that the customers are not encumbered by them. Punctuation, for example, could be stripped out at the back-end for validation purposes, and there is no need whatever for any system to reject input because it contains punctuation.

Clearly time and political imperatives prevented the Obamacare IT system from being built correctly and tested sufficiently, and both the customers and the administration are suffering the consequences of this. Complicated though it is, this is a national system. Imagine the issues they might have faced if it were international … and bear that in mind when you’re designing your data front ends.