My role
Project lead, working with three other researchers as contractors to the Centers for Medicare and Medicaid Services (CMS).
Activities
- Secondary research
- Semi-structured interviews
- Journey mapping
- Service blueprinting
- Stakeholder education
The Hospital Quality Reporting (HQR) System is how hospitals and the Centers for Medicare and Medicaid (CMS) communicate around required quality improvement programs
The HQR System is a web application that hospital facilities use to report their healthcare quality data to the Centers for Medicare and Medicaid Services (CMS). CMS scores this data, and the facilities’ Medicare reimbursement rates may be adjusted based on the outcome. The results also appear on the public Care Compare website, and the system sends performance reports to the facility. The aim is to incentivize best practices for quality of care and give feedback to facilities on how they can improve.
Our product teams needed to see the bigger picture
Our team had been rapidly designing and developing functionality in the HQR system in an agile methodology, but we lacked some foundational understanding, and most teams were focused on narrow areas of the product. We realized the benefit in zooming out to the larger picture of the product and service and considering front stage and back stage processes.
We reviewed existing data, conducted interviews with end users of various roles, and created a service blueprint and three journey maps.
Understanding performance feedback is more difficult than it needs to be
The step of understanding performance feedback stood out as an area ripe for improvement. Quality directors at facilities are managing feedback from multiple internal and external sources. They are also the interface between sources like HQR and executive leadership, so they need to dig into details, understand root causes, and summarize findings for their stakeholders. The reports that HQR gives them do not make this easy.
The journey maps and service blueprint highlighted performance feedback as a problem area, showing redundancy in steps and low satisfaction. Before this, we had mainly been focused on improving the earlier data submission process, as that seemed to be the most cumbersome.
We educated the team on how to refer to service blueprints and journey maps
We presented to a program-wide audience and gave suggestions like “look at the service blueprint to describe mostly internal processes” and “look at the journey maps to focus on the end user experience”. Anecdotally, we had various stakeholders engage with and ask us questions about these documents for the next few months, thinking about how they might apply the learnings to their area of the program.