A few years ago, while I was supervising HIV surveillance data for a city of more than two million people, we had a conversation about whether our case records had “enough” demographic detail to say anything meaningful about disparities. The answer depended entirely on decisions made long before anyone asked: which fields existed on the intake form, which were required and which were optional, what categories the dropdown menus offered, and who was in the room when those choices were made.
I still think about that conversation. A lot of public health work treats health equity as an analysis you run once the data exists. In practice, a data system either can show inequities from the start or it can’t.
Fixing it at the analysis stage is too late
It’s common, and well meant, to say “let’s break the results down by race, income, and geography” once a report is already being drafted. By then the system has already made its choices. If a field wasn’t collected consistently, if a category was too broad to be useful, or if a group was undercounted because intake assumed stable housing or a working phone, careful analysis can’t recover what was never captured. You can note the limitation in a footnote. You can’t get the data back.
I’ve seen this in very different settings: immunization registries, outbreak investigations, chronic disease surveillance. The systems that produce useful equity findings are the ones where someone asked at the design stage, “who will this undercount, and why?” The ones that struggle only ask that question after the undercount shows up as a gap nobody can explain.
What building it in looks like
There’s no single technical fix. What works is a few habits, applied every time.
First, before a data element is finalized, ask who is likely to be missed by the way it’s collected. That could be a language barrier in a survey, a registration process that assumes a fixed address, or categories that lump different groups together because it was administratively convenient.
Second, treat data quality and equity as one conversation. When I worked on vaccine data quality and analytics, the accuracy problems we found weren’t random. They clustered in records for people who were already harder to reach through routine systems. Fixing the quality problem and closing the equity gap turned out to be the same project.
Third, make sure the data can be broken down from day one instead of hoping the existing fields will support it later. A system built only to count how many will never tell you for whom, however good the dashboard on top of it looks.
Why it’s harder than it sounds
None of this is free. Collecting more detailed data takes more time at the point of contact, often from staff who are already stretched. It raises real privacy questions, since more detail can make it easier to identify someone in a small subgroup, and that is an equity concern of its own. It also requires the people who control data systems to treat equity as a requirement on par with interoperability or reporting timeliness, not something that gets cut when the timeline tightens.
I don’t know of a shortcut around that tension. What has helped me is having the conversation before any field is built, with someone in the room whose job is to ask who gets left out. A security review asks who could exploit a system. A budget review asks what happens if revenue comes in low. This is the same kind of check.
Public health data systems outlast the people who build them. The categories we choose today will decide what the next epidemiologist can say about disparities ten years from now. That’s a good reason to get the design right the first time.