Appendix A: Case studies

Medicare Payment Systems Modernization (MPSM)

Project background

The Centers for Medicare & Medicaid Services (CMS) is the largest medical insurer in the world. CMS pays providers roughly $500 billion dollars a year for fee-for-service claims. The systems that handled these payments were running on outdated technology, were extremely fragile when making updates, and inhibited the ability to quickly make changes to healthcare policy.

CMS had tried to modernize these systems three separate times in the past, and all attempts resulted in various degrees of failure. The attempts to modernize all involved waterfall approaches to software delivery. Two of the three planned for a “big bang” switch between systems and resulted in lost data, system downtime, and business logic that didn’t match the original legacy system. CMS was forced to roll back all efforts to the original system to ensure that payments were still being made.

“Big bang” is a common term in software development when switching from one system to another. You can think of this as turning off the lights on one system and then turning on the lights on another. This approach is very risky with a high probability of failure.

Meanwhile, the effort to simply maintain these critical systems became so resource-intensive that there was no actionable roadmap for modernizing them. The continued maintenance and development of the system was driven through a traditional SOW that required many contract modifications to include new work as it came to light. The contract value was hundreds of millions of dollars over the course of five years.

Project scope

The need for modernization didn’t go away with the failed attempts. CMS decided to look at different approaches for modernization that would be smaller, less risky, and deliver business value in months instead of years. The scope of the project had to be broken into two parts to cover a longer-term initiative as well as a smaller, discretely-scoped body of work.

CMS started by defining goals to guide the whole modernization effort. Once a set of goals was defined, they created a rough, long-term vision and identified specific pieces of work that could get underway in the immediate term.

CMS decided to start by moving to a cloud-based infrastructure. The claims processing system was running on powerful, expensive mainframe computers. By moving from mainframe computers to the cloud, CMS would be able to:

Cut down on the cost of computing
Make changes to the programs in a modular fashion instead of having to make edits to the monolithic codebase
Change pieces of the system at a much more rapid pace
Provide real-time analytics and feedback to the CMS policy team

To do this successfully, CMS needed a new approach to procurement that could deliver business value much more rapidly than before.

The procurement strategy

Because the modernization initiative was going to be a long, multi-year effort, CMS needed a contracting vehicle that could be tailored to support the project’s short- and long-term objectives.

CMS put together an analysis of alternatives to help them decide which vehicle would be best suited to supporting the new procurement needs. (See Appendix F). Ultimately, they selected a blanket purchase agreement (BPA) as the best vehicle to:

Quickly create a small pool of vendors that would become experts in the system
Allow for rapidly issuing modular contracts
Bake common requirements into each contract into the BPA to avoid copying and pasting common language into each SOO and vendor proposal

Constructing the BPA required an analysis of the types of skillsets that would be necessary to successfully execute on the long-term vision of MPSM. CMS didn’t understand — nor did it attempt to try to understand — all of the requirements that would be necessary for the initiative. And because CMS was at the very beginning of the project, they recognized the possibility that the objectives could change over the project’s lifetime. CMS elected to write a Performance Work Statement (PWS) for the BPA that outlined the skillsets it needed to work on this modernization initiative. This would clear the way for CMS to write SOOs for the specific modular contracts that would be awarded through the BPA.

Awarding the BPA

The PWS in the BPA consisted of a mix of requirements that included the vendor’s ability to:

Develop software in an agile fashion
Demonstrate the ability to conduct modern user research and product development
Show how user-centered design was plugged into the development lifecycle

CMS knew that all of these skills would be necessary in the successful delivery of the modernization effort. The BPA also included a past-performance requirement, a voluntary down-select phase, and a design challenge phase. There were roughly 100 vendors to start, and a large percentage of the overall pool was eliminated at each phase. By the design challenge phase, only 15 vendors remained.

Once CMS had a good idea of the skills that’d be necessary, they wrote a design challenge that closely matched the first sets of work that would be coming through the BPA. The challenge required vendors to prove that they could execute on all of the different disciplines. By taking this approach, CMS could be assured that all vendors awarded a spot on the BPA would be ready to work in an agile fashion, saving time down the road.

Modular contracting

Now that CMS had a contracting vehicle in place to support the product through its lifetime, it shifted focus to individual pieces of work. Modular contracting was vital for CMS to chunk out the work as it came up during the process of modernization.

The outcome (so far…)

It’s early days for this new approach at CMS, but there are some promising signs. The first modular contract to come out of the newly created BPA was for building the cloud infrastructure that all future development could be built on top of. CMS was able to competitively bid this task of work to all of the BPA winners and award the contract in less than 45 days from initial inception.

Summary

CMS had a complicated problem to solve on a massive scale. By shifting to an agile approach, the agency’s able to:

Retain flexibility for the modernization effort — even at this massive scale
Reduce the risks inherent in putting all resources into one vendor’s hands
Adapt its approach to align with the changes in technology and best practice that are inevitable over such a long-term initiative