Structural racism in health tech

Press play. Today’s episode: the uncomfortable truth that “innovative” health technology can still carry some very old baggage. Sometimes it’s obviouslike when a device works better on lighter skin. Sometimes it’s sneakylike when an algorithm uses health care spending as a stand-in for health need (spoiler: spending is not the same thing as need).

This topic gets extra real in the KevinMD podcast episode titled “Structural racism in health tech”, featuring Matthew Ko (DeepScribe). The core message is simple: what tech companies choose to prioritizeaccents, languages, workflows, data, and who gets included in testingcan either shrink inequities or quietly cement them into software updates.

Let’s talk about how structural racism shows up across the health-tech pipeline, why it happens, and what “fixing it” looks like in practicewithout pretending a single checklist will solve a centuries-old problem. (If only a firmware patch could do that.)

What “structural racism” means in health tech (and why “neutral tech” is a myth)

Structural racism isn’t just one biased person making one biased decision. It’s the set of policies, systems, and norms that consistently produce unequal outcomesoften even when nobody in the room is twirling a villain mustache.

Health tech sits right in the middle of those systems. It’s built on:

• Health data shaped by unequal access to care
• Medical devices tested in unevenly representative populations
• Clinical documentation influenced by language and bias
• Digital access shaped by the digital divide (broadband, devices, privacy, literacy)
• Reimbursement and policy that decide what gets scaled and what gets sidelined

In other words, health tech doesn’t float above society like a perfect cloud of objectivity. It’s more like a sponge: it absorbs what’s around it, then squeezes it back out at scale.

Where structural racism hides in health tech

1) Data: who gets measured, who gets missed, who gets mislabeled

Most “smart” health tech depends on dataEHR records, claims, wearables, imaging, and patient-reported outcomes. But data quality isn’t evenly distributed. If one community has less access to consistent primary care, fewer lab tests, fewer specialist visits, and more barriers to follow-up, their record can look “thinner” or more fragmented.

That doesn’t mean the patient has fewer health needs. It often means the system has documented them less (or documented them later, when the situation is worse). When models train on that data without context, they can learn the wrong lessonsconfidently.

What it looks like in the real world: A predictive model flags “high-risk” patients based on patterns in prior utilization. But utilization is shaped by transportation, clinic availability, insurance networks, language access, and trustall of which are unequally distributed. The model isn’t “racist” in the cartoon sense; it’s faithfully reflecting a biased system.

2) Proxies: when “cost” gets mistaken for “care need”

One of the most cited examples of algorithmic bias in U.S. health care involved a widely used approach that identified patients for extra support (care management) using predicted health care costs. The problem: if Black patients historically receive less care (and therefore generate lower costs) than White patients with the same level of illness, then cost-based models can systematically underestimate Black patients’ needs.

Why this matters: Many health systems use risk stratification to decide who gets scarce resourcesextra care coordination, nursing outreach, social-work support, etc. If the model is biased, inequity becomes a workflow feature.

The fix isn’t “turn off the algorithm.” The fix is to choose better targets (e.g., clinical severity, uncontrolled disease markers, functional status), test equity impacts, and monitor outcomes after deployment.

3) Devices: pulse oximeters and the “it worked in testing” trap

Pulse oximeters became a household object during COVIDlittle glowing clips of reassurance. But evidence has raised concerns that pulse oximeters can be less accurate for people with darker skin pigmentation, with potential consequences like missed or delayed recognition of low oxygen levels.

This is structural racism in product form: if the original device development and validation pipelines underrepresent darker skin tones, the performance gap can persistespecially when the device becomes ubiquitous and used for high-stakes decisions.

Why this is a health-tech lesson, not just a device lesson: “Validation” isn’t a vibe. It’s a methodology. If the validation sample isn’t representative, the product may still be “accurate” on paperjust not for everyone who has to rely on it.

4) Clinical algorithms: when race gets baked into calculators

Race has been used in clinical calculators for years, sometimes in ways that change diagnoses, eligibility, and treatment thresholds. That includes algorithms where race is treated as if it were a biological variable rather than a social category with complex relationships to environment, exposure, stress, and access to care.

One high-profile example is estimated glomerular filtration rate (eGFR) equations for kidney function that historically included a race adjustment. A major shift has been underway toward race-neutral calculationsbecause when “race correction” changes thresholds, it can delay diagnosis, referrals, and transplant-related steps.

Important nuance: Removing race from an equation is not the same as removing inequity from the system. It’s a necessary step in many cases, but it’s not a victory parade. You still need to ensure the alternative is clinically sound, implemented consistently, and paired with policy steps that address downstream harms.

5) EHR notes: bias that spreads through copy-paste medicine

EHRs aren’t just data warehouses; they’re story machines. Clinicians document impressions, behaviors, and social context. Research has found that stigmatizing or negative descriptors can appear more often in notes for Black patients than for White patients.

Here’s the scary part: notes get copied forward. A biased descriptor can become a persistent “shadow label” that influences future clinicians, future decisions, and even future AI tools trained on clinical text.

Health-tech twist: Natural language processing (NLP) models trained on biased notes can learn biased associations. If your clinical notes are skewed, your clinical AI can inherit that skewthen automate it at scale.

6) Access layer: telehealth, broadband, devices, and “the digital front door”

Telehealth can expand accessuntil it doesn’t. The “digital front door” is only welcoming if someone can actually open it.

• Broadband isn’t universal.
• Devices vary (smartphone-only access is common, but not always sufficient for stable video visits).
• Data plans are finite.
• Privacy is harder when you’re taking a visit from a crowded home, a car, or a workplace break room.
• Digital literacy and health literacy are real barriersand often invisible in product design meetings.

Even when patients have smartphones, telehealth can still fail if the platform assumes quiet space, strong signal, and comfort with multi-step portals. Equity isn’t just about offering telehealth; it’s about designing for real lives.

Why “just remove race” isn’t a complete strategy

There’s a temptation in health tech to treat race like a problematic variable you can delete with the confidence of someone emptying their spam folder.

But structural racism is not a variable. It’s a system. If you remove race without changing what the model is learning from (biased proxies, unequal access patterns, biased documentation, underrepresented testing populations), you can still reproduce inequityjust with cleaner-looking code.

A smarter approach asks:

• What is the model actually predicting (need, cost, utilization, clinician behavior, resource availability)?
• Are we using proxies that are shaped by inequity?
• Do outcomes differ across groupsand if they do, why?
• What happens after deployment when workflows, staffing, and patient context collide with the tool?

Sometimes race should not be in the model. Sometimes measuring disparities by race is essential for accountability. The key is to treat race as a social category tied to exposure and lived experiencenot a biological shortcut.

So what does equity-first health tech look like?

Start with the product question that makes everyone a little uncomfortable

“Who could this hurt, and how would we know?”

If that question isn’t part of the roadmap, structural racism can sneak in through “reasonable assumptions” and “industry standard” defaults.

An equity-first checklist (the practical version)

• Representative validation: Test across skin tones, languages, accents, age groups, disabilities, and comorbiditiesespecially if the tool will be used at scale.
• Disaggregated performance reporting: Track sensitivity/specificity and error patterns by subgroup. If you only report the average, you can hide the harm in the margins.
• Better targets than cost: When triaging support, prefer clinical severity and unmet need markers over spending.
• Algorithmic impact assessments: Evaluate equity effects before and after launch, and repeat when data or workflow changes.
• Documentation hygiene: Train clinicians on stigma-free language and build EHR nudges that reduce biased descriptors (without turning notes into corporate legal disclaimers).
• Community co-design: Involve the people most affectedpatients, community health workers, safety-net cliniciansearly enough that their feedback can change the product, not just the marketing.
• Access-aware design: Build for low-bandwidth use, smartphone-only scenarios, asynchronous options, and multilingual support.
• Governance: Establish clear accountability: who owns monitoring, who can pause deployment, and who responds to harm signals.

Regulators and standards: not the whole solution, but part of it

Federal agencies and standards bodies have been increasingly explicit about the need to manage bias and improve performance across diverse populationsespecially in medical devices and AI-enabled tools. For health-tech teams, this is both a compliance issue and a design opportunity: build equity into your evidence generation instead of treating it like an afterthought.

A podcast-style set of questions to ask any health tech vendor

If you’re a clinician, health system leader, or buyer, here are questions that cut through glossy demos:

1. What populations were included in training and validation? Be specific: language, skin tone, disability status, age, insurance type, setting.
2. How does performance vary across subgroups? Ask for disaggregated metrics, not a single “overall AUC.”
3. What proxy variables drive predictions? If cost or utilization is central, ask how inequities were addressed.
4. What happens when the tool is wrong? Who gets false negatives? Who gets false positives? What are the clinical consequences?
5. How will you monitor drift and equity after deployment? Bias can increase when patient mix or workflows change.
6. What is the feedback loop for patients and frontline staff? If harm is happening, can anyone report it easily?
7. Is the tool accessible? Language, reading level, bandwidth, disability accommodations, and privacy considerations.
8. Who benefits financially if the tool “works”? Follow incentives. Equity and profit can align, but don’t assume they always do.

Conclusion: build tech that deserves trust

Structural racism in health tech isn’t a niche concern for policy panels and conference keynotes. It’s a daily operational issuebecause algorithms decide outreach, devices guide treatment thresholds, and digital tools increasingly determine who gets seen, when, and how quickly.

The KevinMD podcast framing is a useful reminder: health tech reflects priorities. If the priority is speed-to-market and average performance, inequities can widen. If the priority is equitable performance, representative evidence, and real-world usability, health tech can be part of the solution.

So yeslet’s keep building. But let’s build like the stakes are real, because they are.

Experiences related to “Structural racism in health tech [PODCAST]” (composite vignettes)

Note: The following are composite, anonymized “from-the-field” style vignettes based on patterns reported by clinicians, researchers, and health systems. They’re written as experiences to make the dynamics easier to see.

Experience 1: “The device said she was fine.”

An emergency clinician recalls a patient with respiratory symptoms who looked more distressed than the numbers suggested. The pulse oximeter reading hovered in the “reassuring” range, and the triage urgency dropped. Later, a blood gas and clinical course pointed to worse oxygenation than the fingertip reading implied. The takeaway wasn’t “never trust devices.” It was: devices must be validated across skin tones, and clinicians should be trained to recognize when physiology and technology don’t match.

Experience 2: The algorithm that “found the right patients”… but not all the right patients

A population health team launched a risk tool to enroll patients into a care management program. Early dashboards looked great: fewer admissions among enrolled patients and a tidy return-on-investment estimate. Then a clinician asked a simple question: “Where are the sickest patients I see every week?” A deeper review showed the model leaned heavily on historical spending and utilization. Patients with fewer encountersoften tied to access barrierswere less likely to be flagged. The fix required changing the target (clinical risk, not cost), rebalancing features, and adding an equity monitoring view that was as visible as the ROI slide.

Experience 3: Telehealth that worked… for people who already had what it needed

A clinic celebrated a telehealth expansionuntil missed appointments started clustering among patients who relied on smartphones, prepaid data plans, or shared devices. Video visits failed, portals timed out, and “simple” identity verification steps became friction points. Staff discovered that “tech access” wasn’t binary; it was layered: bandwidth, privacy, comfort with apps, and the ability to troubleshoot without a helper. The clinic added low-bandwidth options, simplified logins, expanded language support, and created a small “digital navigator” workflow. Telehealth didn’t stop being helpfulit just stopped pretending everyone starts at the same line.

Experience 4: Building speech tech that understands more than one kind of English

A product team working on clinical documentation tools heard repeated feedback from clinicians: the system handled certain accents poorly, leading to more corrections, more time, and more frustrationoften for clinicians already stretched thin. Instead of treating it as an edge case, the team used it as a design requirement: evaluate performance across accents and speaking patterns, improve training data, and publish subgroup performance internally so it couldn’t be ignored. The lesson matched the podcast’s spirit: equity isn’t an add-on. It’s a product decision.

SEO Tags