Maine Mangles Medicaid – Charges CIO

Allan Holmes, for CIO Magazine just posted a scathing and detailed autopsy of the disastrous Medicaid Claims System project run by CSNI and launched in January of 2005. Requirements elicitation failures combined with incompetent vendor selection and project mismanagement lead to a $30,000,000 oops for the state of Maine, jeopardizing its credit rating. The system failed to process 300,000 claims in the first 3 months of operations, causing many health care providers to close their doors – and presumably causing citizens of Maine to go without needed services. Maine is the only state in the union (as of April 2005) not complying with federal HIPAA regulations.

Autopsy results

There were crucial failures in essentially every step of the project. We’ll look at each of the following areas:

1. Defining requirements and creating an RFP (request for proposal)
2. Vendor selection
3. Requirements validation
4. Risk management
5. Execution (Project management and development)
6. Testing
7. Deployment / Change Management / Training

Defining requirements

April 2001. Maine issued an RFP for the new HIPPA compliant system. By the end of the year, only two bids were placed – one for $15 million and one for $30 million. Holmes tells us that this is a sign of a bad RFP:

…says J. Davidson Frame, dean of the University of Management and Technology in Arlington, Va. “Only two bidders is a dangerous sign,” he says, adding that the low response rate indicated that potential bidders knew the requirements of the RFP were unreasonable.

Requirements elicitation done poorly is the major source of defects in any project.

Taking a step back, we see from Holmes that Maine decided to use a new (to them) technology and develop the software themselves instead of outsourcing. The justification being that it would be easier to adapt to changing requirements (this becomes ironic later – read on).

The development of the new system was assigned to the IT staff in the DHS, which decided it wanted a system built on a rules-based engine so that as Medicaid rules changed, the changes could be programmed easily into the system.

Vendor selection

Quoting Holmes:

In this case, the low bidder, CNSI, had no experience in building Medicaid claims processing systems. In contrast, Keane had some experience in developing Medicaid systems, and the company had worked on the Maine system for Medicaid eligibility.

OK, maybe not so bad, but wait – more irony. The final costs (to the State) of going with the low-cost vendor exceed the bid from the high cost vendor.

Requirements validation

To begin with, the 65-person team composed of DHS IT staffers and CNSI representatives assigned to the project had difficulty securing time with the dozen Medicaid experts in the Bureau of Medical Services to get detailed information about how to code for Medicaid rules. As a result, the contractors had to make their own decisions on how to meet Medicaid requirements. And then they had to reprogram the system after consulting with a Medicaid expert, further slowing development. [emphasis ours]

We wouldn’t use the same language as Holmes, we would say “… the contractors decided to make their own interpretations of how to meet Medicaid requirements.” They never had to do it – they chose to do it. In Where bugs come from we show the impact of having or not having a feedback loop for validating requirements. Not having that feedback loop was either a decision of incompetence or hubris.

No one is blameless for this mistake. Maine’s IT department is responsible for making sure the contractors are doing what they really want. The contractors are responsible for doing what Maine wants. At a minimum, the SMEs should have been interviewed, and the contractors should have at least used active listening techniques to validate their interpretations of the statutes. All the way down to the developers, who should have required that they understand the context in which they are coding. They should have said “why?” until they got answers.

Risk Management

New vendor. New technology. Maine knew that the requirements were not good.

Thompson decided that the six months that would have been needed to redo the RFP was too much. “We had a requirement to get something in place soon,” Thompson says.

No access to SMEs (subject matter experts). No system tests (more on that later). No backup system. No contingency plans if the system didn’t work.
If there was a risk management plan in place, it certainly didn’t change the course of events.

Execution

Starting with project management:

• Oct 2001. CNSI is selected as vendor – project length: 12 months.
• Fall 2002. Project timeline doubled to an Oct 2003 delivery.
• Fall 2003. No delivery.
• Fall 2004. No delivery.
• Jan 2005. System goes live.
• Apr 2006. System now (claimed to be) operating at same level as legacy system.

And with development (here’s the aforementioned irony):

The development of the new system was assigned to the IT staff in the DHS, which decided it wanted a system built on a rules-based engine so that as Medicaid rules changed, the changes could be programmed easily into the system.

Errors kept cropping up as programmers had to reprogram the system to accept Medicaid rule changes at the federal and state levels.

Wow.

Testing

Hey, testing is optional.

testing the system from end to end was dismissed as an option. The state did conduct a pilot with about 10 providers and claims clearinghouses, processing a small set of claims. But the claims were not run through much of the system because it was not ready for testing.

Conclusion

Holmes presents excellent conclusions about the HIPAA project. Our conclusion – we need more people in Maine to read the blog. If you know someone in Maine, send them a link. In some seriousness, there’s a T-shirt that says “If you can’t be a good example, be a horrible warning.”

Thanks for the warning, Maine!