Towers Built on Sand - Part 1
A Case Study in Fixing Foundational System Flaws
For the last 20+ years, Human Centered Design (HCD) as a field has been working to patch the holes left behind by the first wave of website and system development that occurred with the dawn of the internet age. Although the first websites and systems on the internet were built out of good intentions and lots of hard work, it was a new frontier for everyone, and as such, it was something of a Wild West when it came to creating anything remotely usable for the end user. Entire user groups left behind, different design standards for different pages of a website, nonsensical system architectures, non-existent navigations, and countless other HCD faux pas made websites and systems of this era teetering towers that would eventually crumble, be torn down, or thoroughly patched until they became stable. Naturally, the idea of tearing down an established system and starting from scratch was anathema to the stewards of these systems. And so, The Great Patch Job was undertaken for many of these early websites and systems. But how does one go about patching enormous foundational holes in a system? Where does one start? To tackle problems of this magnitude, it may be of use to examine a case study of how a team went about patching a system with a foundational hole.
The Hospital Quality Reporting (HQR) system was one of the government’s early internet systems, and was one such system that had a major foundational hole. Originally called QualityNet Secure Portal, HQR has been the central hub by which healthcare providers submit quality data to the Centers for Medicare and Medicaid (CMS). The system was originally designed with a provider-centric perspective. This meant that individual healthcare providers (hospitals, ambulatory surgical centers, psychiatric treatment centers etc.) were responsible for directly submitting their quality data to CMS. In practice, many providers often outsourced much of this work through a variety of means. Providers contracted with vendors, who would administer the quality surveys, gather the results, and format the data for submission to CMS on behalf of multiple providers, thus lowering the expended resources for an individual provider. Although vendors have played a large role in healthcare quality on behalf of providers, they are not the only organization type that providers lean on to provide these quality related services.
Healthcare Systems (HCSs) were the final missing piece of the system architecture puzzle for HQR. HCSs are a common business model in the healthcare industry, as corporate entities bring individual providers under one collective administrative umbrella. These umbrellas provide critical administrative services for their providers, including collection, analysis, and submission of quality data (among many other services provided). Unfortunately, HQR was not originally designed with these relationships in mind. HQR required providers to submit their own quality data or contract with a vendor to submit data, but outside of the system, many of these providers were relying on their HCSs to handle all other aspects of their quality assessments. Because HCSs were so critical to the healthcare quality equation, it became increasingly important that they be brought into the HQR system in an official capacity.
When making a big change to an established system, it’s important to break down the problem into more easily digestible steps. Adding HCSs to HQR means taking inventory of all the ways that change will ripple across the system. How will providers interact with HQR differently because of HCSs? Will vendors interact with HQR differently now that HCSs will be introduced? How do we ensure access to the system is simple, yet secure? These are just a few of questions that would need to be ironed out in the process of implementing HCSs.
Let’s dive into the process.
Step 1: Stakeholder buy-in.
Big changes to a system require everybody involved to be on the same page. In the case of HCSs, the UX team at Bellese undertook extensive research studies to gather data around the problem space. Talking to HQR users from providers and HCSs, the team found many pain points with how the current system excluded HCSs. Data in hand, the UX team began conversations with our CMS partners to explore the possibilities of including HCSs into HQR. Critically, the UX team had concrete data from real users of HQR that pointed to widespread need for HCSs to be implemented. This data augmented the conversations between the UX team and our CMS partners, allowing both parties to reference facts that could inform the direction of the suggested changes. Leaning on data in conversations with stakeholders is so critical because it keeps the conversation from devolving into hypotheticals, and instead allows for the conversations to focus on objectives that can be achieved.
With the initial conversations out of the way, the UX team could turn towards getting official approval from our CMS partners for pursuing this system change. Official approval helps both the stakeholders and the UX team by giving both parties a clear start point. From this start point, project expectations may begin to form.
Throughout the entirety of this project, it has been (and will continue to be) critical to maintain stakeholder buy-in from beginning to end. With this in mind, stakeholders should be regularly informed of the process and how the work is progressing. Finding the balance between giving stakeholders enough detail to be informed, but not bogging them down in the weeds of a project can be tricky. But finding that sweet spot will help stakeholders be up-to-date with changes and will reduce the chances of major redesigns down the road.
Step 2: Mapping the Problem Space.
Challenges like including a new user group into a system can be sprawling. Mapping the problem space can ensure we’re anticipating as many of those challenges as possible. For HCSs, the UX team created a diagram of all the user types in HQR, along with the objectives
each user type might have when they enter HQR. Some user types need stories for utilizing every part of HQR. Others only need access to specific parts of the system. Creating this diagram helped our team visualize the objectives each user group had, and make sure we weren’t missing any by the end of the exercise.
After the UX team had created this diagram, we decided this was a perfect opportunity to gather feedback from other team members, and eventually, from stakeholders. Collaborating with developers, product managers, business analysts, and other team members on the HQR team, we went through each user type and each objective, discussing our initial draft and making sure we hadn’t missed anything. The different perspectives not found on the UX team helped fill in the gaps and ensure the user stories were as representative as possible.
After this meeting with the HQR team members, we scheduled a meeting with the project stakeholders to gather their input. This was a great time to include stakeholders, as the diagrams were easily approachable for those not steeped in UX design or application development. With the diagram for reference, the meeting helped the stakeholders and the product team to feel confident we had captured all of the objectives we needed to accomplish through this HCS work.
There’s still lots of work to be done! Check back in tomorrow to read more about how we finished tackling this problem.