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 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.
- 1 – Ux Researcher & Designer
- 2 – Ui Developers
- 4 – Back-end Developers
- 3 – Project Managers
- 1 – Product Owners
- 1 – Quality Assurance Tester
- 10+ Stakeholders
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.
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.
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.
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.
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.
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.
I put the prototype in front of individuals who upload files for their respective models.
I gave them each the same seven tasks:
- To locate Model One and upload all the files to the server
- Find out if the modelOneBAF.cvs passed virus inspection
- Learn what to do if a virus was detected
- You’re not apart of Model Two but you need one of their files, go and download modelTwoPAF.cvs
- Go to the activities page does Model Two upload their files every month?
- Did it capture your activity of downloading the file? No? Go and report the bug.
- Navigate to Model Three, go to upload a file.