Industry: healthcare

Peraton -

The Centers for Medicare and Medicaid Services have a branch called ‘The Innovation Center,’ where they develop new payment and service delivery models.

These models came about to help individuals with Medicare and Medicaid to receive streamlined services when they have health issues like kidney disease, for example. Someone with kidney disease should see a variety of doctors, but not everyone knows this or realizes this. So CMS has created models and allowed providers to sign up to participate in these models stating they agree to work with other providers to provide the whole suite of services for someone with kidney disease.

Why would a provider sign up to be a participant in a model? Because each model receives funding, and when they have helped Medicare save money, they receive a bonus at the end of each calendar year.

the problem

The Kidney Care Choices Model process claims every quarter. They also are constantly checking if providers are meeting all of their criteria.

If a provider fails to see the minimum of 400 kidney disease patients within one quarter, CMS removes them from the records.

In December 2021, a record keeper accidentally deleted providers and participants from the records. Someone noticed the mistake twenty days later.

The result was a loss of over $20 million worth of money for claims and providers without their end-of-the-year bonuses. “If you don’t use it, you lose it.” So the model was discontinued.

the team

  • 1 – Ux Researcher & Designer
  • 2 – Ui Developers
  • 4 – Back-end Developers
  • 3 – Project Managers
  • 1 – Product Owners
  • 1 – Quality Assurance Tester
  • 10+ Stakeholders

the scope

Typically I am brought into a project for discovery before developers are even on the scene. Yet the product team decided to start creating an interface thinking it was just an interface for uploading records. They brought me into the project with three months left to deliver the first version.
The interface I designed for CMMI (The CMS Innovation Center) gathers the records that track the patients and providers participating in a particular model and sends them to a shared system. This shared system determines how claims are processed.

I conducted research:

  • to determine the functionality of the first version
  • if we can standardize the record formats for all innovation models
  • to learn the differences between model types
  • to understand the role the interface played
  • to learn the process of collecting and sending data to the shared system
  • to identify the various users of the new interface

I designed with low-fidelity wireframes and coded a prototype for user testing and stakeholder feedback.

the strategy

user sample

Existing models will not use the new web application. However, they are very different from one another. So to determine how to standardize the records, I needed to meet with the large, small, complicated, and simple innovation model teams.

stakeholder interviews

I simultaneously conducted stakeholder interviews with those that on-boarded innovation models, created the existing apps used to upload records, and those impacted when things go wrong.

contextual inquiries

I meet with those that:

  • Collect model participant and provider information.
  • Manage data from a model’s operating system to create the records sent to the CMS shared system.
  • Upload the files sent to the shared system.
  • Deal with the aftermath of providers and patients accidentally deleted or uploaded to the wrong model.

I created design criteria from my research. I then used that design criterion to create low-fidelity wireframes. I went through four phases of wireframes.

In the first phase of wireframes, I attempted to solve all the problems I came across in my research. The product team and I walked that dream of an interface back to an MVP (Minimum Viable Product). With two months left, we chose functionality we knew could be delivered by the deadline.

So the second phase of wireframes focused on a shorter list of problems to solve. The third and four phases refined the design, copy, and functionality with input from the front and back-end developers.
Since I could code in HTML, CSS, Bootstrap Javascript, and ReactJS I built the prototype with code instead of using Figma. I used it to conduct user testing, design for 508 compliance, refine functionality with the developers, and pass off styling to the Ui Developers.

First Release

I mapped out the process of the MVP after presenting my first round of wireframes to the product team. The developers clarified any misunderstandings I or anyone else had using this visual.

CMMI MVP process
Individuals who uploaded the records sent to the shared systems did not return to ensure that what they had uploaded was eventually accepted. So I did my best to show in real-time if there was an error.

If a file contained an error, the incorrect model name, or an incorrect file type it was rejected. The second version would introduce an email that would notify the team member that the shared system had found issues with the file they had submitted.

When someone uploades the wrong records, CMS inquires who uploaded the file and which file was uploaded?

The current system removes any activity after 45 days. We decided to hold activity information for 180 days. We also track who downloads files, upload files, the file names, failures, successes, date, and time.

user testing

I put the prototype in front of individuals who upload files for their respective models.

I gave them each the same seven tasks:

  1. To locate Model One and upload all the files to the server
  2. Find out if the modelOneBAF.cvs passed virus inspection
  3. Learn what to do if a virus was detected
  4. You’re not apart of Model Two but you need one of their files, go and download modelTwoPAF.cvs
  5. Go to the activities page does Model Two upload their files every month?
  6. Did it capture your activity of downloading the file? No? Go and report the bug.
  7. Navigate to Model Three, go to upload a file.
I invited some team members who requested some design changes that I believed would benefit the intended users to the user testing. They were amazed to see how the interface was interacted used. I went back to some of my initial designs to fix the problems.


  • I delivered the design spec two weeks earlier than expected to the developers
  • I helped with testing for 508 Compliance
  • The team met their deadline!
  • I mapped out the next few versions of functionality for the interface