TL;DR — Most healthcare engineering teams aren’t held back by code quality. They’re held back by missing clinical literacy: the ability to read healthcare workflows, regulatory architecture, and patient-safety implications inside the engineering function itself. Federal breach data, workforce research, and clinical informatics literature all point to the same gap. Clinically literate engineers are scarce in every market. Closing this gap requires a mix of internal training and architecture. However, the most reliable structural catalyst for growth-stage HealthTech is diversifying the talent pipeline—sourcing cross-border engineers from Canada and LATAM who already possess deep exposure to digital health and U.S. regulatory frameworks.
How real is the clinical literacy gap in healthcare engineering?
Real enough to show up in three independent evidence streams: federal breach data, industry workforce research, and clinical informatics literature.
1. Federal breach data points to engineering failures, not clinical ones
In its 2024 Report to Congress on the HIPAA Breach Notification Program, the U.S. Department of Health and Human Services Office for Civil Rights (HHS OCR) — the federal enforcer of HIPAA, the Health Insurance Portability and Accountability Act of 1996 — reported 663 large breaches affecting roughly 242.9 million people in 2024. That’s more than 70% of the U.S. population. Eighty-one percent of those breaches came from hacking or IT incidents. (HIPAA Journal summary of the OCR report)
When OCR investigated, the most commonly cited violations were:
- Risk analysis and risk management failures.
- Information system activity reviews.
- Audit controls.
- Authentication of persons or entities.
Read those again. None of them are clinical mistakes. Every one is an engineering-architectural decision — how systems get designed, who can access what, how access gets logged, how the org keeps verifying that its safeguards still work.
2. Peer-reviewed research shows digital health companies systemically underweight the clinical layer
A cross-sectional analysis of 224 digital health companies, published in the Journal of Medical Internet Research and indexed on PubMed Central, measured what the researchers called “clinical robustness” — the combined count of completed clinical trials and U.S. Food and Drug Administration (FDA) regulatory filings for each company. The findings are stark:
- 44% of the digital health companies studied scored zero on clinical robustness — no completed clinical trials and no FDA filings
- The median clinical robustness score across the entire cohort was 1
- Only 20% of companies scored 5 or higher
Clinical robustness isn’t a direct proxy for clinical literacy inside an engineering team, but it’s the closest available systemic measure of whether digital health companies as a category invest in clinical grounding at all. The published answer: most don’t.
And the market has consolidated around this reality. Rock Health’s Q3 2025 report found that 42% of digital health funding since the first quarter of 2025 has gone to clinical workflow companies, with incumbents like Epic, Oracle, Innovaccer, and Athenahealth “doubling down” on their own workflow products. The competitive edge in current HealthTech is precisely the clinical-workflow layer that most digital health companies were not built to handle — which is another way of saying the clinical literacy gap has moved from a nice-to-have to a market-differentiating capability.
3. Clinical informatics research confirms the dominant failure mode
A 2026 paper in Frontiers in Digital Health, Why digital health fails silently, proposes a sociotechnical theory of health IT risk. Its core finding: clinical risks “emerge through misalignments between system design, configuration, and clinical workflows.” Patient-safety incidents in digital health systems “frequently reflect design–workflow misfits rather than ‘simple mistakes.'”
That’s the gap, stated academically: software designed by engineers who don’t see how the system gets used in real clinical settings produces systems whose failure modes stay invisible until they’re causing harm.
The gap is real. It’s documented federally, industrially, and academically.
What does “clinical literacy” actually mean for an engineer?
The term gets used loosely. Here’s the working definition.
A clinically literate engineer is fluent in three things:
1. Clinical workflows — how care actually gets delivered. What a nurse does between 7 a.m. and 7 p.m. in a hospital unit. How a physician documents an encounter. How an order moves from a prescriber to a pharmacy to a bedside dispensing system. How a discharge summary travels from inpatient to a primary care physician’s inbox.
2. Healthcare data standards — the technical vocabularies that healthcare systems use to talk to each other:
- HL7 (Health Level Seven) — the international body that sets clinical data exchange standards
- FHIR (Fast Healthcare Interoperability Resources) — the modern, web-based standard mandated by the U.S. government for certified electronic health record systems
- ADT (Admission, Discharge, Transfer) — the HL7 message family hospitals use to broadcast patient registration and movement events
- EHR (Electronic Health Record) — the digital chart system that hospitals and clinics use to store patient data; Epic, Oracle Health, and Athenahealth are the dominant U.S. vendors
3. Regulatory architecture — the rules that determine how patient data gets handled. HIPAA. The HITECH Act of 2009 (Health Information Technology for Economic and Clinical Health Act, which extended HIPAA enforcement). The 21st Century Cures Act. The rules issued by CMS (Centers for Medicare & Medicaid Services) and ASTP/ONC (Assistant Secretary for Technology Policy / Office of the National Coordinator for Health Information Technology), which together set the federal framework for healthcare data exchange.
An engineer who can build a scalable API is technically competent. An engineer who can also explain why a poorly timed write to an EHR creates a documentation gap that affects a downstream insurance claim — that engineer is clinically literate.
Most engineering hires have the first capability. Few have both.
The scaling inflection point for HealthTech engineering teams
Most HealthTech companies hit the same inflection point at roughly the same moment.
Early on, the team builds something that works in a controlled environment — one pilot hospital, one payer relationship, a limited dataset. The engineering looks like standard software work.
Then the product enters a real clinical environment at scale. Suddenly you’re managing concurrent integrations with multiple EHR systems, navigating Business Associate Agreement (BAA) scope questions, building audit logging that has to satisfy both internal engineering review and external compliance audit, and explaining to clinical stakeholders why a feature that looked simple on the spec doesn’t map cleanly to their actual workflow.
On top of that, the federal regulatory calendar has compressed. FHIR API mandates, USCDI v3 conformance, CMS Prior Authorization rules — all of it is hitting growth-stage HealthTech engineering teams simultaneously, and most of these companies are running with engineering teams that won the seed and Series A rounds, not with engineering teams configured for clinical-grade complexity.
We covered the regulatory side of this in depth in our previous blog post, Making Digital Healthcare Systems Interoperable: How to Build the Right Team for FHIR and HL7 Compliance. Read that one for the full timeline and standards detail. This post is about what comes after you understand the regulatory pressure — the team configuration that lets you actually meet it.
HIPAA compliance as engineering architecture, not legal checklist
This is the single most expensive misunderstanding in HealthTech scaling.
HHS OCR has been running a formal enforcement initiative targeting noncompliance with the risk analysis requirement of the HIPAA Security Rule for two years now, and is expanding it to also cover risk management. That requirement, codified at 45 CFR §164.308(a)(1)(ii)(A), calls for “an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information.”
That’s not a contract review. That’s an engineering exercise. And OCR’s enforcement record says it’s the most common point of failure for organizations being investigated after a breach.
A second area where engineers without healthcare context routinely get caught: de-identification. Under the Safe Harbor method at 45 CFR §164.514(b), 18 specific identifiers must be removed for data to qualify as de-identified under HIPAA. Engineers without healthcare experience strip the obvious ones — name, SSN, date of birth — and miss the less-obvious ones: device serial numbers, IP addresses, certain biometric identifiers, ZIP code values where the first three digits cover fewer than 20,000 people. The result is data the team thinks is de-identified but legally isn’t.
Then there’s the BAA — the Business Associate Agreement. HIPAA requires a BAA between any healthcare entity (a hospital, a health plan) and any vendor that handles PHI on its behalf. HealthTech vendors are almost always business associates. The HITECH Act of 2009 made business associates directly liable for breach notification — meaning a HealthTech vendor that gets breached has its own federal reporting obligations independent of its customers. (HHS, Breach Notification Rule)
Engineers who haven’t built inside a BAA-governed environment underestimate how much architecture has to be designed in from day one. Audit logging that satisfies the Security Rule’s information system activity review requirement. Authentication frameworks that meet the identification requirements. Encryption configurations that hit the Department’s safe-harbor specs.
Retrofitting these is painful and expensive. Doing them right the first time requires engineers who’ve already done it.
Why doesn’t “engineers will pick up the clinical context on the job” work?
Because the research says it doesn’t.
A 2024 BMJ Health and Care Informatics study, summarized in recent industry analysis, found that “embedding digital tools within clinical workflows is the strongest predictor of broad clinician acceptance.” The software that worked in the demo isn’t the software that survives contact with a real clinic — where the EHR times out under load, one nurse covers two rooms, and the workflow has been calibrated for a decade to compensate for the EHR’s specific quirks.
The 2026 Frontiers in Digital Health paper makes the structural argument: workflow integration can’t be added later because clinical IT risks are emergent properties of the interaction between software design, workflow, and organizational routines. They can’t be designed in isolation.
Here’s what that looks like in practice. A few questions your engineering team will hit:
- Alert design. Which categories in a clinical decision support tool require interruptive alerts (the system blocks the workflow until a clinician acknowledges) versus passive alerts (a visible warning that doesn’t block)? That decision shapes the front-end architecture, the override-logging design, and the audit trail for downstream quality reporting.
- Allergy reconciliation. How does a medication system handle a patient whose allergy documentation in an external EHR hasn’t been reconciled with the internal record? That requires knowledge of HL7 clinical message structures (like ADT and ORU) and an understanding of the clinical consequence of operating on incomplete allergy data.
- Drug mapping. When the product ships into a hospital whose Epic configuration uses custom medication order sets that don’t map cleanly to RxNorm (the National Library of Medicine’s standardized drug nomenclature), which mapping failures matter clinically and which can be handled with a fallback? That requires pharmacy informatics knowledge plus integration engineering.
These aren’t edge cases. They’re the daily work of building software that touches clinical environments. Engineers without clinical exposure encounter them as unexpected blockers that need expensive external consultation. Engineers with clinical IT context recognize them as known problem categories with established patterns.
The velocity difference is significant — and it compounds the further the product gets into the clinical environment.
Sourcing clinical-IT engineering talent from Canada and LATAM
Where does the engineering talent for this actually live? The honest answer: it’s scarce everywhere, and no single market has enough of it. While long-term upskilling and restructuring team roles (like embedding clinical PMs) are vital, growth-stage HealthTechs facing immediate scaling pressures can rarely afford the time. For these companies, the most pragmatic fast-track is expanding the geographic pipeline to pools where this specific intersection already exists: Canada and LATAM.
Canada has a documented clinical-IT engineering cohort
Canada Health Infoway — the federally-funded nonprofit established to accelerate Canadian digital health adoption — has received approximately $2.45 billion in federal funding since 2001. Its work spans pan-Canadian interoperability standards under CA Core+, the Shared Pan-Canadian Interoperability Roadmap, and provincial EHR rollouts — all of which have required engineers operating at the intersection of technical depth and clinical workflow.
That work has produced Canadian engineers with direct exposure to FHIR-based interoperability, clinical terminology services, public health surveillance systems, and EHR integrations — regulatory frameworks that closely mirror the U.S. mandates (FHIR, USCDI alignment, OAuth 2.0 / SMART on FHIR) that HealthTech teams are working under.
LATAM has its own clinical-IT engineering cohort
Latin America has both a deep general engineering talent pool and a real, growing bench of engineers with clinical IT background. Brazil, Mexico, Colombia, Argentina, and Chile all have active HealthTech ecosystems — regional players building EHR integrations, telemedicine platforms, clinical decision support, and payer-side systems. On top of that, LATAM engineers have been working directly with U.S. HealthTech companies for years, which means direct hands-on exposure to HIPAA architecture, FHIR APIs, BAA-governed environments, and U.S. clinical workflows.
The result: LATAM has engineers with the same clinical-IT profile that’s rare in any market, plus a broader base of strong software, data, cloud, and DevOps engineers who can be brought up the clinical learning curve inside a well-structured team.
Why the combination works
Clinical literacy isn’t a Canadian trait or a LATAM trait. It’s a scarce combination anywhere it exists. The reason a Canada + LATAM model works for HealthTech is more practical:
- Wider net for a scarce profile. Sourcing across both markets meaningfully expands access to engineers who have actually built inside clinical environments — instead of hoping one small national pool has the right person available.
- Time-zone alignment with U.S. HealthTech teams. Engineers in both markets work North American business hours, which makes clinical-workflow discussions and incident response actually possible in real time.
- Regulatory adjacency on both sides. Canadian engineers bring exposure to Infoway-driven FHIR work that mirrors U.S. federal mandates. LATAM engineers with U.S. HealthTech experience bring direct HIPAA and Cures Act implementation history.
- Team resilience. Concentrating clinical literacy in one geography or one senior person creates a single point of failure. Distributing it across a hybrid team means the knowledge is redundant — the team keeps working when one person is out.
The failure mode DevEngine designs against is the assumption that geography determines role. Clinical literacy is what determines role, and it exists on both sides of the equator—which is why we build distributed engineering teams for growth-stage HealthTech companies that need both technical depth and clinical IT fluency. If you’re scaling and running into this gap, we’d like to talk.
