There are a number of reasons for an organization to modernize their legacy systems. Doing so enables it to support the adoption of technologies such as cloud, big data, IoT and mobile. The system may no longer be able to respond or adapt to business needs. It may even be built on a codebase with an increasingly disappearing domain knowledge.
The Centers for Medicare and Medicaid Services (CMS) was recently faced with the reality that its legacy system needed to be modernized for all of these reasons and more. Recently, Scott Haselton, a Senior Software Engineer on the Health and Human Services team at the United States Digital Service (USDS) and the lead on the Medicare Payment Modernization project described how his team took on this challenge. This is the story of what his team is doing to address the situation and keep a mission critical system online.
Why Medicare’s 50 year old system is ripe for modernization
The CMS is a federal agency within the US Department of Health and Human Services that administers the Medicare program. It is a trillion dollar agency and 25% of all federal spending flows through Medicare alone. At its heart the agency provides health insurance to over 53 million subscribers while paying out claims to healthcare providers. In order to pay providers, CMS has 4 legacy systems - comprised together they are called the “shared system” - responsible for paying $500 Billion per year or, looked at another way, nearly 4% of the total US GDP flows through this system.
This is a staggeringly important system that is in need of modernization to ensure that it can continue to serve the goals of CMS in the long-term. As it stands the shared system faces several risk factors. The first is simply that the system is old, in some cases more than 50 years old.
The next issue is that the system runs on 8 million lines of COBOL and 1.5 million lines of proprietary assembly language which live on 15 disparate mainframe computers. Today’s developers coming out of school aren’t being taught these languages and the domain knowledge that was around when the system was written is rapidly disappearing.
The third issue is that the system is unable to adapt to the business requirements that are coming into CMS through policy from lawmakers. The traditional model on which Medicare pays providers is something called “fee for service.” This is a model where providers get paid for all of the services they administer to the patient. If a doctor orders five x-rays, he or she will get payment for all five. In recent years, the healthcare industry has begun to see a fundamental shift and payors are very slowly migrating to a value-based payment model. In this model, if five x-rays are ordered but only one is really needed, the provider gets paid for that single x-ray since that was the actual value that was provided.
The business requirements coming into CMS are requiring value-based payments but the system was written with a fee for service mindset. Due to this, as well as certain constraints from its age, the system can’t really respond or adapt to these requirements. Certain pieces of policy could not be implemented in a timely manner as required by law. Haselton sees a massive risk in trying to patch a system to do something it wasn’t designed for.
The final risk is the inevitable overload of the system. As the baby boomer population ages into Medicare, there is a rapid growth in the number of people enrolling. Currently there are around 10,000 new beneficiaries joining Medicare everyday. For some systems, Florida was mentioned as one in particular, the amount of time that it takes to handle the number of transactions is getting to the point where the system is struggling to keep up. Eventually there will come a time where there won’t be enough hours in the day for the system to handle the number of calculations required. At that point the system will go down or a queue will be created that can never be finished.
Why the USDS is positioned to help the CMS
An imminent problem of this scale needs thinking that extends beyond the traditional way that the government approaches IT projects. Luckily there is a group equipped to take on such a challenge. In 2014, the USDS was created as part of the healthcare.gov recovery effort.
It is a group that operates out of the White House and is comprised of designers, engineers, and product managers that come to DC for a three, six, or 12 month digital tour of duty.
As Haselton describes it, “we’re a group of technologists, that have startup backgrounds. We have seen a lot of scenarios. We can take our particular skill sets and those experiences and we bring them into government and help out with some of these larger projects that are at high risk and that have an extremely high impact.”
As a result of the healthcare.gov recovery, the government saw what could happen if you put a small group of experts together and empower them to make decisions ie. cut through the bureaucracy - they can move quickly, safely, and get stuff done.
From that model, the USDS was born and teams have been deployed across various agencies including the VA, Department of Defense, Department of Homeland Security, and the Small Business Association among others. They have even engaged with CMS previously, helping them to launch the Blue Button API. Haselton describes their goal as lending their skill sets to make sure that high risk projects cross the goalline and that they are successful.