A few years ago, while I was supervising HIV surveillance data for a city of more than two million residents, I remember a conversation about whether we had “enough” demographic detail in our case records to say anything meaningful about disparities. The honest answer was: it depended entirely on decisions made long before anyone asked the question — what fields existed on the intake form, what was mandatory versus optional, which categories a dropdown menu offered, and who had been in the room when those choices were made.
That conversation has stayed with me, because it captures something I think gets missed in a lot of public health work: health equity is usually treated as an analysis you run after the data already exists, rather than a property the data system either has or doesn’t have from the start.
The analysis-stage fix comes too late
It’s common, and well-intentioned, to say “let’s disaggregate the results by race, income, and geography” once a report is already being drafted. But by that point, the system has already made its decisions. If a field wasn’t collected consistently, if a category was too broad to be useful, if a population was undercounted because the intake process assumed stable housing or reliable phone access, no amount of careful analysis afterward can recover what was never captured. You can caveat a limitation in a footnote. You can’t un-lose the data.
I’ve seen this across very different settings — immunization registries, outbreak investigations, chronic disease surveillance — and the pattern repeats. The systems that actually produce equity-relevant insight are the ones where someone asked, at the design stage, “who will this undercount, and why?” The systems that struggle are the ones where that question only gets asked once the undercounting has already become visible in a gap nobody can explain.
What “built in” actually looks like
Building equity into the data itself isn’t a single technical fix. It’s a set of habits applied consistently:
Asking, before a data element is finalized, what populations are likely to be missed by the way it’s collected — whether that’s a language barrier in a survey instrument, a registration process that assumes a fixed address, or a category structure that collapses meaningfully different groups into one box because it was administratively convenient.
Treating data quality and equity as the same conversation, not two separate ones. When I worked on vaccine data quality and analytics, the accuracy problems we found weren’t randomly distributed — they clustered in records tied to populations that were already harder to reach through routine systems. Fixing the technical quality issue and addressing the equity gap turned out to be the same project, not sequential ones.
Building the capacity to disaggregate from day one, rather than hoping the existing fields will support it later. A system designed only to count “how many” will never answer “for whom,” no matter how sophisticated the dashboard built on top of it looks.
Why this is harder than it sounds
None of this is free. Collecting more granular data takes more time at the point of contact, often from staff who are already stretched. It raises real privacy questions — more detail can mean more risk of identifying someone in a small subgroup, which is its own equity concern. And it requires people with authority over data systems to treat equity as a design requirement with the same weight as, say, interoperability or reporting timeliness, not as a nice-to-have that gets traded away when the project timeline tightens.
I don’t think there’s a shortcut around that tension. What I’ve found useful is treating it as a design conversation that happens before a single field is built, with someone in the room whose job is specifically to ask who gets left out — the same way a security review asks who could exploit a system, or a budget review asks what happens if revenue comes in low.
Public health data systems outlive the people who build them. The categories we choose today will shape what the next epidemiologist can or can’t say about disparities ten years from now. That’s a reason to get the design right the first time, not a reason to assume it can be patched later.