The CMS Vision versus the Vendor’s Imposed Reality

Again, I start with a caveat.  I only know from what I read in terms of CMS vision and speak to the vendor’s imposed reality from a background in software development and systems administration within the corporate world.  Clearly, my views here are my opinions only!

When I first read documents from CMS on what they asked vendors to do and how the technology should be built and how it should work, I was really impressed.  When I first read the CMS requirements, I was excited to see something really done right.  They specified software that followed specific data standards so that reporting could be done across the entire system without all the data conversion issues they have now from all the various state proprietary systems.  They specified an architecture based on SOA (Service Oriented Architecture) so that various components could be linked together in a modular way with standard communication protocols between them.  Components could be swapped out without damaging other components.  CMS specified the use of rules engines so that when business requirements change, they could be implemented through the definition of English-like rules outside of the code itself.  If the state and federal exchanges were written this way, this would provide sophistication and flexibility unknown in most large government programs and probably all state programs.

To this day, I don’t believe that any of the vendors actually followed these requirements in the way described by CMS.  I know of at least three states who are using one major component of the exchange that was written in VB6 – not even Microsoft VB.NET which was first released in 2002.  Programmers reading this will laugh about how long ago this code must have been written.  They will also cringe when thinking about linking this to a SOA architecture and cringe even more when thinking about modifying it for some purpose other than what it was originally written to do.  Those of us trying to use it are finding it almost non-functional!

Then again, CMS wanted the ability to re-use and share code between the states to reduce the overall cost of the project.  That was naïve.  The commercial companies bidding on this project had no intention of doing anything other than some proprietary approach that they could sell over and over again.  There was no intention of sharing anything.  All the companies came out with bids including COTS (Commercial-off-the-Shelf) software that was already “owned” by commercial companies so couldn’t be shared.

Rather than a highly modularized and flexible system standardized in many ways across the different exchanges, what we have is a hodge-podge of different existing systems that have had to be integrated in very complex ways.  There is little real flexibility.  Most of what I have seen is much worse than it could have been had the companies started from scratch and written to the requirements rather than force everyone down the proprietary COTS path.

I have said before that I think this should have been a federal program and not one where each state could have its own exchange.  If CMS and the Feds had hired the staff to design and write the exchange software so that the government could actually own it, I think they would have been more successful.

The CMS vision was great; the reality imposed upon it by the large contractors hired to implement it was very different.

The Health Insurance Exchange as a True Startup

Having worked through a state exchange ramp-up from vendor selection to the eventual invoicing and collection of premiums, it rings true that anyone attempting this needs to look at it like an entrepreneur involved in a technology startup.  States that want to start now will at least be able to benefit from the experiences of those who have come before but looking at the process as that of a startup would still serve them well.

Objectives and requirements need to be defined up front and not as you go along.  Staffing should match the expertise required to manage the project.  All those participating in the project should believe in it and work to make it a success.

The biggest difference between a technology startup and an exchange startup has been money.  I think it had a profound effect on the state exchanges. The Feds were providing the money – lots of it – for a project that hadn’t yet had its requirements defined.  I am convinced that a private individual or a venture capital organization would have dealt with the funding very differently than did the Federal Government that seemed at time to provide a blank check to state exchanges.

Now we are facing even more money pouring into the process and a feeding frenzy as vendors step up, perfectly willing to fix another vendor’s code.  When will the dollars stop?  When will someone develop the technology can will bring reality to the dream.