Hospital Quality Reporting (HQR) Modernization Case Study

Problem Statement

The people who understand the clinical data and the people who build the systems to collect it often talk past each other.

One group is fluent in quality measures, regulatory definitions, and clinical intent. The other speaks in APIs, data schemas, and system architecture. Two brilliant minds in a room with no common language. And quietly, invisibly, the gap between them starts making decisions. About which hospitals get flagged. About which data gets reported. About which facilities see a payment adjustment they did not deserve and cannot explain.

I watched that breakdown up close when I led the transformation of the Hospital Quality Reporting system at CMS. Over 14,200 healthcare facilities. More than 5,000 of them subject to direct payment adjustments based on the quality measures my team's system collected, calculated, and reported. The problem was not that the people were not brilliant. The problem was that the infrastructure they were working across had never been designed to speak a common language.

That infrastructure problem has a name: interoperability. And I approached it with one core idea. What if we closed the communication gap not by adding more people to bridge it manually, but by building systems that did not require bridging in the first place?

Building a Solution

When Ad Hoc partnered with CMS and Bellese in 2017, what started as a four person research team became a cross-functional delivery team of engineers, UX researchers, policy subject matter experts, and product managers. We moved the HQR suite off waterfall development and rigid legacy infrastructure into an agile, modular, cloud-based architecture. We redesigned the QualityNet Secure Portal used by over 20,000 healthcare professionals. We embedded human-centered design into policy execution at scale, one of the first federal programs to do that work seriously.

But the hardest problem was never the design. It was the data underneath it.

Hospital quality reporting depends on getting accurate clinical information out of Electronic Health Record systems and into federal reporting pipelines. Every EHR vendor had its own data format, its own conventions, its own interpretation of what a quality measure meant in structured data. Hospitals were bridging those gaps manually. Staff whose entire job was translating between what their EHR produced and what CMS needed to receive. That is not a workforce problem. That is a structural one.

FHIR Gave Us a Common Language. Semantics Are Still the Fight.

The introduction of FHIR, Fast Healthcare Interoperability Resources, was supposed to change that. FHIR established a standardized framework for how clinical data should be structured and exchanged across systems. Instead of each EHR speaking its own dialect, FHIR offered a common language. When quality measure data arrives in a standardized, machine-readable format, you can validate it faster, calculate it more accurately, and report it to the public with far greater confidence.

But here is what the FHIR transition revealed rather than resolved. Standardizing the format of data does not automatically standardize the meaning of data. Two hospitals can both submit FHIR-compliant records for the same quality measure and still be measuring slightly different things, because the clinical definitions got interpreted differently at the point of documentation. The format interoperates. The semantics do not always follow.

That gap is where accountability gets lost. And someone has to own it.

We Have Been Here Before. We Know How to Adapt.

We have already done this once. The shift from siloed legacy systems to modular, cloud-native infrastructure was not inevitable. It required deliberate choices about who was responsible for which data, what standards governed its collection, and what happened when two sources said different things.

The 23 percent reduction in CMS help desk tickets we achieved did not come from better documentation. It came from removing the structural friction that made the system confusing in the first place. The infrastructure we built became a backbone for CMS quality initiatives that are still running today because we made decisions about data architecture that held up over time.

That same discipline is what FHIR-based interoperability requires now. Measure definitions linked to their regulatory source. Data versioned so you can tell when it was last verified against current policy. Pipelines that surface where a number came from, not just what the number is. These are not aspirational features. They are what meaningful accountability looks like in a system that touches payment decisions for thousands of institutions.

Personal Responsibility Does Not Transfer to the Infrastructure

Here is what I keep coming back to. When I led the HQR transformation, I could not hand the consequences of our design decisions to the system we were building. Every structural choice had a downstream consequence for real institutions and real patients. I had to be able to name that and own it.

Impact

  • Human-Centered Policy Innovation: I spearheaded the first federal programs to successfully integrate human-centered design into policy implementation workflows.

  • Recognition: Recipient of the CMS Honors Award for Human-Centered Design.

  • Help Desk Efficiency: 23% reduction in CMS help desk tickets due to streamlined UX and improved system performance.

  • Agile Leadership: Built a nationally distributed, high-performing team of 12+ researchers, engineers, and decision-makers.

  • Infrastructure Modernization: Delivered a modular and cloud-native architecture that now serves as a backbone for CMS quality initiatives.

  • Civic Tech Leadership: Helped establish a civic engagement playbook and thought leadership strategy within CMS and beyond.