HealthCare.gov set poor requirements. Here's how to avoid the same trap.

This week the Las Vegas Review-Journal carried a story about a man who signed up for Affordable Care Act insurance via the Nevada health care exchange, paid several premiums but later discovered (after a heart attack) that the exchange failed to send his selection on to the insurer. He is now stuck with a $407,000 medical bill. 

The man also “received nothing to confirm he had insurance,”  according to the story. Elsewhere, a Florida woman who was unable to disenroll from ACA insurance was quoted as saying, "I was blown away that they had not thought forward enough to realize that people are going to disenroll."  Confirmation is a basic requirement for any transaction system. If people enroll in a system, it is a basic requirement that they be able to disenroll. 

Most of the public’s attention until now has focused on the front-end of creating an ACA account: qualifying for assistance, comparing plans and selecting a plan. The failures noted above have to do with the back-end of the system, where a lack of proper requirements definition is hampering the system.

My personal experience using HealthCare.gov confirms this. 

I recently created an account, shopped for plans and completed an application on HealthCare.gov.  After selecting the plans I wished to enroll in, the website told me I was finished and to remember to pay my first premium.  And then – nothing. I never received any information or notification confirming my selection or keeping me up to date on the status of my application. 

If we compare this process to ordering a product on Amazon.com, as the President did after the site’s launch, this would be like placing an order on Amazon.com and then receiving no confirmation of the order, no status information on when it was shipped and no tracking information.  So, as the deadline approached, I took the only reasonable course of action: I went to the insurance company’s site and re-applied myself. 

About a week later, I received a confirmation letter and bill to pay my first premium for the policy I selected on HealthCare.gov.  So, like the Florida woman, I had two insurance policies as the result  of a blatant lack of forethought in defining the requirements for the exchange. (Unlike the Florida woman, I was able to then cancel the policy on HealthCare.gov.)

Why all this poorly engineered software for a marketplace – a type of software system commonly available from thousands of online vendors?  Where is the concept of operations that envisioned a marketplace in accordance with the President’s comparison of buying a “plane ticket on Kayak or a TV on Amazon”?  Where is the functional requirements document or set of agile user stories that walks through all the obvious use cases from start to finish and includes notification of the consumer on the back-end of the process?

If you think this is obvious and these tools clearly must exist, think again. I recently ran across an article that quoted a government CIO as saying that,  “the onus of requirements at inception also ends up creating a surfeit of software features.”  

To me, such a statement is shocking, sends the wrong message to government agencies and flies in the face of the many documented failures of HealthCare.gov related to the basic problem of capturing functional requirements. 

So, if you agree that such features are basic and should have been captured as functional requirements, we are left with two questions for government organizations: Is a requirements definition part of your systems development lifecycle?  And, if so, what is the “right” amount and level of detail for requirements specification? 

The right amount of requirements definition starts with a minimal requirement for all software development projects and then is further defined based on tailoring the level of detail to the scope of the system.  This is where project managers focus on the end user and define the expected behavior of the system for all key use cases.  This is done in agile via user stories.  Again, these types of requirements should be mandatory and non-negotiable. 

Unfortunately, this is also precisely where HealthCare.gov and the Nevada exchange failed.

The second part of determining the right amount of requirements definition is in the tailoring.  I am a big fan of tailoring the amount of rigor (and documentation) in a process to the scope and complexity of the system being built.  The smaller the scope, the less rigor required. 

Tailoring requirements definition calls for asking two additional questions. First, how are you partitioning development of your system? And second, how experimental or innovative is your system?  The answers to these two questions will determine how much effort you need to exert in deriving technical requirements from functional requirements.  In general, requirements tell you what should be done, and your design tells you how you are going to do it. 

Suffice it to say, that “the onus of requirements at inception” does NOT necessarily lead to a surfeit of features. In the case of the health care marketplaces, if done properly, this process will ensure that key end-user features are not neglected or omitted. 

In the end, it is the service to the citizen that is paramount.

Michael C. Daconta (mdaconta@incadencecorp.com or @mdaconta) is the Vice President of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department. His new book is entitled, The Great Cloud Migration: Your Roadmap to Cloud Computing, Big Data and Linked Data.