Table of Contents >> Show >> Hide
Health tech loves a good origin story. It promises efficiency, precision, personalization, and dashboards so polished they look like they were designed by caffeinated angels. In theory, that sounds wonderful. In practice, though, technology does not float above society like a neutral cloud of genius. It is built inside institutions, trained on historical data, deployed through unequal systems, and paid for by incentives that are not exactly famous for fairness. That is why examining structural racism in health tech matters so much.
Structural racism in health tech is not just about one biased engineer, one offensive interface, or one glitchy algorithm having a bad day. It is about how policies, funding patterns, clinical assumptions, research gaps, and design choices can work together to repeatedly disadvantage some groups while benefiting others. In health care, those patterns are especially dangerous because the consequences are not just annoying. They can shape who gets flagged as high risk, who gets monitored accurately, who can access telehealth, who is believed, and who gets left waiting while the software smiles politely.
This conversation is bigger than artificial intelligence alone. It includes medical devices, patient portals, predictive models, telehealth platforms, digital triage systems, remote monitoring tools, and the data infrastructure behind them. The central question is simple: when health technology claims to improve care, improve it for whom?
What Structural Racism Means in a Health Tech Context
Structural racism refers to the way institutions and systems produce unequal outcomes through rules, norms, and accumulated disadvantages. In health tech, that means bias can appear long before a clinician clicks a button. It can begin with who is represented in clinical trials, whose medical records are most complete, which hospitals generate the training data, what the model is optimized to predict, and how “risk” gets defined in the first place.
That last point matters more than it sounds. If a tool predicts health care spending rather than actual illness burden, it may confuse lack of access with lack of need. If an app assumes every patient has stable broadband, a private room, strong English proficiency, and a laptop with a working camera, it will quietly reward people who already have advantages. If a clinical rule treats race like biology instead of recognizing racism as the true driver of many inequities, it can hard-code harmful assumptions into care.
Put differently, health tech does not need to say anything openly discriminatory to reproduce discrimination. The bias often arrives in a lab coat, carrying a spreadsheet.
Why Health Tech Is Not Automatically Neutral
Data Reflect Unequal Systems
Many developers talk about “letting the data speak.” That sounds wise until you remember the data learned its accent from the health system. Historical records include unequal access to specialists, delayed diagnoses, lower quality pain treatment, under-testing, language barriers, and uneven follow-up. When a model trains on those records without asking why the patterns exist, it can treat injustice as objective truth.
For example, patients who historically received less care may appear less sick on paper even when their clinical need is high. That does not mean the data are fake. It means the data are social. They carry the fingerprints of policy, segregation, insurance inequality, under-resourced hospitals, and biased decision-making.
Proxies Can Be a Problem in Nice Clothing
One of the sneakiest ways structural racism enters health tech is through proxy variables. Developers might avoid using race directly, then turn around and use cost, ZIP code, utilization history, missed appointments, or insurance type in ways that still capture structural disadvantage. A model can therefore look race-neutral while behaving in deeply unequal ways.
That is why fairness work in health tech cannot stop at asking, “Did you include race?” The better question is, “What historical inequalities are hiding inside the variables you used?”
Deployment Matters as Much as Design
A tool that performs reasonably well in one setting may fail in another. A model trained in a large academic medical center may not transfer cleanly to a safety-net clinic. A symptom checker built for fluent English speakers with high digital literacy may flop in communities where patients share devices, change phone numbers often, or need interpretation support. Structural racism shows up not only in the code, but in who has the infrastructure to benefit from the code.
Examples That Reveal the Problem
The Care-Management Algorithm That Used Cost as a Stand-In for Need
One of the most discussed examples in modern health tech involved an algorithm used to identify which patients should receive extra care management support. On paper, that sounds noble. In reality, the model used health care spending as a proxy for health needs. Because Black patients often face barriers to care and therefore generate lower costs than equally sick White patients, the system underestimated how much care many Black patients needed. In one widely cited analysis, Black patients accounted for 17.7% of those recommended for extra care, but that figure would have been 46.5% under an unbiased approach.
That case is a master class in structural racism. The problem was not simply “the computer was racist.” The problem was that the tool was built on a health care marketplace where spending is shaped by access, trust, referral patterns, and long-standing inequities. The algorithm then converted those inequities into a tidy decision rule.
Race-Based Kidney Function Equations
Another major example comes from kidney care. For years, some estimated glomerular filtration rate calculations used a race adjustment that produced higher kidney function estimates for Black patients. That could delay referrals, transplant evaluation, specialist care, and treatment planning. Eventually, the National Kidney Foundation and the American Society of Nephrology recommended a race-free equation, reflecting a broader shift away from treating race as a biological shortcut.
This matters because race is not a gene. It is a social and political category with real health consequences precisely because racism shapes exposure, stress, treatment, environment, and opportunity. When health tech uses race as a crude biological variable, it can blur that difference and reinforce the myth that unequal outcomes are somehow natural.
Pulse Oximeters and Skin Tone
Not all health tech bias is algorithmic in the machine-learning sense. Sometimes it is a device issue with very human consequences. Pulse oximeters have been shown to be less accurate in patients with darker skin tones, with readings that can overestimate oxygen saturation. During the COVID era, that became more than a technical footnote. It raised concerns that some patients could appear safer on the device than they actually were, contributing to delayed recognition and delayed care.
This example is especially important because it reminds us that “innovation” is not just software. Sensors, optics, validation standards, and study populations matter too. If devices are not adequately tested across diverse populations, the resulting errors can deepen already serious disparities.
Telehealth, Portals, and the Digital Divide
Telehealth expanded access for many people, and that part is real. But access is not evenly distributed. Broadband affordability, device ownership, digital literacy, language support, disability access, and privacy all shape whether remote care is truly reachable. When systems assume video is easy for everyone, they erase the practical reality that some patients are smartphone-dependent, some have unstable internet, and some are navigating care in a language the platform barely supports.
That matters by race and ethnicity as well as income. Research has shown that roughly one-in-five Black or Hispanic adults are smartphone-dependent. That means they rely on a phone for internet access more often than White adults do. Meanwhile, people with limited English proficiency remain far more likely to be uninsured and face greater risk of lower-quality communication, misunderstandings, and medical error. A telehealth platform with weak interpretation support or unreadable instructions can therefore widen disparities while still marketing itself as “convenient.” Convenient for whom is the question that ruins many PowerPoint decks.
How Structural Racism Gets Built Into Health Tech
Underrepresentation in Research and Validation
If the people most affected by health inequities are underrepresented in trials, pilot studies, usability testing, and validation datasets, then the resulting technology may work best for already well-served populations. That problem is not limited to one product category. It affects software, sensors, therapeutics, and digital services. A tool can be statistically impressive and still clinically unfair.
Workflows Built Around Privilege
Many digital health systems are designed around assumptions that map neatly onto middle-class stability: a permanent address, flexible work hours, private transportation, uninterrupted data plans, and confidence using official systems. But real patients live in the messier version of America. Some share phones. Some lose service. Some work hourly jobs and cannot sit through a 20-minute portal registration process. Some need culturally responsive care and interpretation at every step. Health tech that ignores those realities is not merely inconvenient. It is structurally selective.
Procurement Without Equity Standards
Hospitals and health systems often buy technology because it promises efficiency, compliance, or reduced labor costs. Equity is sometimes treated like a bonus feature, somewhere between “dark mode” and “coming soon.” If procurement teams do not require subgroup validation, transparency about training data, accessibility safeguards, and post-deployment monitoring, biased tools can enter clinical workflows with a badge and a budget.
Weak Accountability After Launch
Too many organizations treat fairness like a one-time pre-launch question. But health systems change, populations shift, data drift happens, and new patterns of exclusion appear over time. A tool may look acceptable in testing and become harmful in real-world deployment. Structural racism is persistent, adaptive, and very good at surviving pilot projects. Accountability must therefore continue after implementation, not end at the ribbon-cutting.
What Anti-Racist Health Tech Should Look Like
Move From Race-Based to Race-Conscious Design
The answer is not to pretend race and racism do not matter. It is to stop using race as lazy biology and start examining how racism shapes the care environment. Race-conscious design asks whether a tool reflects segregation, differential access, biased treatment histories, or policy failures. It focuses on structural conditions rather than stereotypes.
Measure the Right Outcomes
Developers should be careful about what they optimize. Predicting cost is not the same as predicting clinical need. Predicting who is likely to comply may reward already advantaged patients. Predicting missed appointments without accounting for transportation or work schedules can punish people for barriers they did not create. Better tools begin with better target definitions.
Test Across Real Populations
Subgroup analysis should not be decorative. Health tech needs strong testing across racial and ethnic groups, language needs, disability status, geography, age, and insurance contexts. Validation should happen in the kinds of clinics where care inequities are most visible, not only in elite settings with unusually clean data and unusually stable patients.
Build Language Access and Accessibility In From the Start
Interpretation, captioning, readable interfaces, disability accommodations, and mobile-friendly design should not be patched in after complaints. They belong in the core architecture. If access depends on perfect English, perfect hearing, perfect vision, or perfect broadband, the product is already failing a large part of the public.
Share Power With Communities
Communities affected by inequitable care should help define problems, review risks, and evaluate whether a technology is actually useful. Health tech companies love the phrase “user-centered design,” but too often the “user” in the room is a clinician with a laptop, not the patient juggling chronic illness, childcare, a prepaid phone plan, and a deep historical reason not to trust the system.
Use Regulation and Governance Seriously
Civil-rights enforcement, procurement rules, audit requirements, and transparent reporting all matter. Section 1557 and related protections make clear that discrimination rules do not disappear when a hospital replaces a clipboard with software. Technology does not get a magical exemption because it can generate a chart in under three seconds.
Conclusion
Examining structural racism in health tech means rejecting a comforting myth: that digital tools are naturally objective because they are technical. They are not. They are social products built inside unequal systems. That is the bad news. The useful news is that biased health tech is not inevitable. It can be redesigned, revalidated, regulated, and challenged.
The real test of health innovation is not whether a tool is faster, shinier, or more automated. It is whether it improves care without reproducing the old hierarchy in new packaging. A system that overestimates oxygen levels in darker skin, delays kidney care through race correction, or treats broadband and English fluency like universal facts is not futuristic. It is just inequity with better branding.
If health tech wants to earn the word innovation, it has to do more than scale. It has to serve people who have historically been underserved, measure what actually matters, and be accountable when it fails. Otherwise, the industry will keep building impressive machines that move fast, break trust, and call it progress.
Experiences Around Structural Racism in Health Tech
In real life, structural racism in health tech rarely announces itself with dramatic music. It usually feels ordinary. That is part of the problem. A patient tries to log into a portal after work, but the verification code goes to an old phone number because housing and service instability made continuity hard. The platform offers English first, Spanish second, and everything else like an afterthought. The patient gives up, misses a refill, and later gets described in the record as “nonadherent.” The technology captures the outcome, but not the obstacle.
In another setting, a clinician is looking at a dashboard that ranks patients by who needs extra outreach. The interface is sleek. The score looks scientific. No one in the room can see the buried assumptions about prior spending, fragmented access, or how often certain patients were historically underdiagnosed. The list feels objective, so staff trust it. But the people floating to the top are often those who already know how to navigate the system. The patients who most need help may remain lower on the list, invisible behind “low utilization.”
There is also the experience of distrust, and that deserves respect rather than dismissal. For many patients from communities that have been studied, surveilled, undertreated, or ignored, a new health app does not arrive in a vacuum. It arrives with history. A symptom tracker asking detailed questions may feel helpful to one person and intrusive to another. An AI assistant that promises personalized care may sound impressive until it gives generic advice that clearly was not designed with your life in mind. Trust is not a marketing problem. It is an earned relationship.
On the clinical side, many health workers experience a different frustration. They can feel that a tool is missing something, but the workflow around it is too rigid to challenge easily. A nurse may know that a pulse oximeter reading looks reassuring while the patient in front of her does not. A nephrologist may understand the history of race-adjusted kidney equations and still be stuck with old defaults in the electronic record. A care coordinator may recognize that video visits are hardest for the very patients who would benefit most from consistent follow-up. Structural racism in health tech often shows up as that gap between lived knowledge and institutional defaults.
Developers and product teams can experience their own version of this issue. Some genuinely want to build fair systems but are handed timelines, datasets, and performance metrics that make equity work look optional. The pressure to ship can be intense. So the team validates on the data they already have, launches in the easiest clinics first, and promises to fix subgroup issues later. Later, of course, is a famous neighborhood where many important things go to disappear.
What makes these experiences so important is that they reveal how racism can feel procedural rather than personal. No one person may say anything explicitly prejudiced. Yet the patient still cannot access care, the device still performs unevenly, the model still underestimates need, and the institution still calls the result efficient. That is exactly why structural racism in health tech has to be examined at the level of systems, not just attitudes. The everyday experience tells the truth: inequity often survives not because it is hidden, but because it has been normalized.
