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.