US Digital Service helps CMS with ‘novel’ approach to IT modernization

Ask the CIO

US Digital Service helps CMS with ‘novel’ approach to IT modernization

Jonathan Sullivan, a digital services expert at the U.S. Digital Service, said modernizing the Quality Payment Program for CMS required a change in approach.

Jason Miller@jmillerWFED

May 10, 2018 3:18 pm

4 min read

Best listening experience is on Chrome, Firefox or Safari. Subscribe to Ask the CIO’s audio interviews on Apple Podcasts or PodcastOne.

As Medicare transitions to a new type of payment program focused on quality instead of quantity, its systems also had to change.

This major change gave the Centers for Medicare and Medicaid Services an opportunity to take an old, bulky system and transform it into a modern one using agile and user-centered design approaches.

Jonathan Sullivan, a digital services expert at the U.S. Digital Service working on the Quality Payment Program for the Department of Health and Human Services, said the approach the digital services team took to create a modern system for healthcare providers to report data was driven by two major factors. The first was making sure the new reporting tools were easy to use for the doctors, nurses, healthcare clinicians.

The second factor focused on the technology side so future updates weren’t a heavy lift.

“The platform was going to be hosted in the cloud,” Sullivan said on Ask the CIO. “We were going to do application programming interfaces first development. This is a way of doing development that allows you to build a bunch of different components for software that can work with each other in a flexible, scalable way, but also work with components outside of your platform as well. This was a fairly novel approach for CMS to take when developing a system like this. Not only was it novel in terms of starting out on the cloud and being 100 percent cloud based, but also having it be an API-first type of development.”

Jonathan Sullivan is a digital services expert at the U.S. Digital Service working on the Quality Payment Program for CMS.

USDS and CMS laid out its development priorities in six-week increments, using two-week sprints to develop and launch the new capabilities.

Sullivan said USDS also built a user interface on top of the APIs, and released some of the software code to the public so third-party developers could develop additional features using the API.

He said the release of the APIs was in response to requests by the private sector to access the software code.

Congress required CMS to change its approach to paying healthcare providers in the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA). The Quality Payment Program gives Medicare providers new tools and resources to choose how to participate based on the practice’s size, specialty, location or patient population.

USDS’s work with the HHS is one of several projects USDS highlighted in its annual report to Congress.

Sullivan said USDS and CMS’s goal for the new system was to make it similar to commercial software where users input a lot of data such as TurboTax.

He said the QPP tool uses an interrogatory format for presenting questions and users giving response back, and it gives the user a lot of flexibility of working on reports, taking a break and then coming back to it.

“There is a benefit for the staff at CMS in that we are aggregating this data and putting it into a system that makes it a lot easier for them to retrieve the data and do the processing that they have to do on their side,” Sullivan said. “We did build a new data store for this program. Part of the reason we did that is because the Quality Payment Program was replacing a bunch of previously existing similar programs. The point was to try to bring those altogether into one coherent program and as part of doing that, we also created one coherent data store. One of the challenges we faced was that we had to pull in data from elsewhere in the organization particularly around what we call eligibility so information that helps us build up a profile of a user.”

He said USDS and CMS wanted to try to limit how often users had to input the same data and take advantage of information the agency already owns. This was a bigger technical challenge than just building a new database.

Another challenge USDS and CMS faced was they are dealing with personal information so they had to build both the technology and culture to protect the information.

“It was very important to insatiate this culture of think more broadly than just the code you are writing, but think about security more broadly,” he said. “How is the security of the thing you are building going to effect the security of other people’s work? Really get down to the programmer’s level to say, ‘you always need to be thinking about security.’ Every person on this program is accountable for thinking about security for the code they write.”

USDS and CMS also relied on third-party experts to look at and test their code to ensure they achieve their goals of protecting the data.

Sullivan said in 2016 and 2017, the USDS and CMS team did a lot of original development so for 2018 and beyond the focus is two-fold—refining the system based on user needs and incorporating legislative changes as necessary.