The model is not what stalls a healthcare AI product. The integration layer is — and FHIR does not save you from it. That is the uncomfortable claim, and the rest of this article is the defense: standards fix the shape of the data and decide almost nothing about the workflow, the auth surface, or what your system does at 2am when a required field is absent.
The evidence is in the standards themselves. The FHIR R4 specification (HL7, 2024) gives a standardized language for healthcare data exchange, and the SMART App Launch framework (HL7, 2024) standardizes how an application authenticates against an EHR. But a systematic review of FHIR implementations (JMIR Medical Informatics, 2024) makes the practical limitation clear: interoperability standards reduce translation pain, and deployment still turns on workflow fit, versioning reality, and local implementation details. HL7 v2 is worse in the same direction — an analysis of v2 optionality (JAMIA, 2009) counted 4,132 data elements in the standard result message with 85% of them optional, which is a specification that has politely declined to make the decisions for you.
ML LABS built the EHR and FHIR integration layer of the cloud backend behind HeartSciences' AI-ECG platform, and the protocols there split by job rather than by preference: HL7 v2 carries the clinical order and result workflow, FHIR carries data access and launch context, and per-organization authentication prevents cross-tenant data access on both. That split is not a style choice. It follows from what each protocol is actually load-bearing for, and getting it backwards is how a team ships an integration the ordering clinician's workflow cannot reach.
graph TD
A1["Healthcare AI<br/>Product"] --> B1{"Integration<br/>Constraints"}
B1 --> C1["Workflow<br/>Mismatch"]
B1 --> C2["Auth and Identity<br/>Complexity"]
B1 --> C3["Production<br/>Behavior Gaps"]
C1 --> D1["Per-Org Workflow<br/>Contracts"]
C2 --> D2["Per-Org Auth<br/>Bindings"]
C3 --> D3["Hardened Endpoint<br/>Security"]
style A1 fill:#1a1a2e,stroke:#0f3460,color:#fff
style B1 fill:#1a1a2e,stroke:#ffd700,color:#fff
style C1 fill:#1a1a2e,stroke:#e94560,color:#fff
style C2 fill:#1a1a2e,stroke:#e94560,color:#fff
style C3 fill:#1a1a2e,stroke:#e94560,color:#fff
style D1 fill:#1a1a2e,stroke:#16c79a,color:#fff
style D2 fill:#1a1a2e,stroke:#16c79a,color:#fff
style D3 fill:#1a1a2e,stroke:#16c79a,color:#fffFHIR Solves Structure, Not Workflow
FHIR resources are generic by design. Clinical workflows are not. A product needs one narrow combination of patient context, diagnostic output, task routing, and alert behavior, and the standard resources represent that combination only partially — the gap between the generic resource model and the specific clinical action the AI is supposed to drive is engineering work, and it is engineering work that no budget line anticipated.
The semantic layer is where it hurts most. A systematic mapping review of EHR semantic issues with FHIR (JMIR, 2024) found that even with FHIR in place, organizations continue to enter clinical information as free text or local terminologies rather than standardized codes, and that no single approach to bridging that gap has emerged. Concretely: an AI product that expects a coded problem list will meet sites where the same condition appears as a SNOMED code, an ICD-10 code, a local mnemonic, or unstructured note text — sometimes within one organization. The integration layer normalizes all four before the model sees an input, or the model sees garbage and reports it confidently.
Workflow Mismatch Is The Tax
Take a schematic case — illustrative, not a client system. A sepsis early-warning model consumes vital signs, lab results, and active medications. At one site vitals arrive via Observation resources on a regular cadence; at another only the most recent value is exposed and history requires a separate flowsheet pull. Medication status lives on MedicationRequest at one site, MedicationAdministration at another, and a custom extension at a third. The model logic never changes. The data-shaping work multiplies with every organization, and it multiplies in a place nobody put on the roadmap, because the roadmap said "integrate with the EHR" as though that were one task.
The response is to write the workflow contract before broad integration work begins: which resources matter, which fields are required, which states trigger AI behavior, and what happens when the output is wrong. Per-organization configuration makes the contract harder and more necessary at once — each organization may enable different AI models, activate different EHR behaviors, or require different workflow steps, so the contract has to say which behaviors are universal and which are per-site from the very first integration. That is the same discipline that lets the HL7 result-delivery layer serve many hospitals from one codebase: every site-specific value is configuration, and validation refuses to build a message when a required mapping is missing.
Auth Is A Family Of Paths
Authentication in EHR integrations is not one path. It is a family of related paths that vary by organization, by user type, and by launch context, and getting it wrong produces subtle security gaps and intermittent failures rather than clean errors.
The foundation is per-organization authentication: each organization gets its own auth binding, with its own credentials and certificate infrastructure. The auth layer is parameterized by organization from the first integration — hard-coding a single credential set, even temporarily, becomes a structural problem the moment a second organization onboards, and "temporarily" has a way of surviving into production. Session management then has to enforce organizational boundaries, because a clinician working across health systems can present a token issued in one context inside another, and that is a real attack surface rather than a theoretical one.
The hardest part of EHR auth is not implementing OAuth. It is implementing it correctly across organizations that each have their own credentials, certificate infrastructure, and enabled features.
What Breaks After Pilot
Real resource versions, incomplete records, permission differences, and downstream expectations diverge from development assumptions — and the security surface is larger than it looks, because FHIR-sourced users follow a different authentication path than standard users and every endpoint has to handle each correctly. An endpoint that quietly skips the FHIR auth path is the kind of finding that arrives late and costs the most to fix.
The signals worth instrumenting before launch are specific. Endpoints with inconsistent latency across organizations, which can mean one tenant is falling back to a slower query path. Token-refresh errors clustering at shift change, which can mean a session-binding bug that only appears under real concurrency. AI outputs that look correct in staging and drop fields in production, which can mean a profile resolved against the sandbox's version of a resource and fails silently against the live one. Versioning is the underrated case: a resource that works against R4 may behave differently against an organization still on DSTU2 or already on R5, and because so much of these standards is optional by design, the failure presents as a missing value rather than as a hard error — the exact class of bug that passes an integration test and reaches a clinician.
Define production behavior before launch. What happens when a required field is missing, when the user lacks access, when the AI output needs human review before it enters the clinical record. Each of those is cheap to decide in design and expensive to decide during a clinical complaint. The cheapest way to find out which of them you have not decided is to build the thing that asks — which is what an EHR integration simulator is for, and why it exists before sandbox access rather than after.
When Integration Is Premature
Some products are too early for EHR integration, and the integration will not tell them so kindly. If the AI output is still unstable, the user workflow is still moving, or the required clinical action is not well defined, integration work surfaces those upstream problems at integration prices — you pay EHR-integration cost to discover a product question. Where the workflow can prove its value outside the EMR first, doing that is not a detour. It is the cheaper experiment.
First Steps
- Write the workflow contract. The exact clinical event, the target resources, the required fields, and the per-organization configuration surface — on paper, before any connector work.
- Map the auth surface. Per-organization authentication, FHIR launch context, or both. Whichever it is, parameterize by organization from the first integration, not the second.
- Name the real blocker. If the workflow and the auth path are both understood, proceed. If either is still moving, that is the thing to fix, and integration work will only make it more expensive to fix later.
Integration As Workflow-Delivery System
The bar is not "we can call the FHIR API". The bar is a workflow-delivery system: a written workflow contract, per-organization authentication with real credential infrastructure, session management that enforces organizational boundaries at the data layer, hardened endpoints across the whole surface, and defined behavior for every failure the clinical workflow can produce. A team that can hit that bar internally should. A team that reads the list and recognizes three items it has not decided is not behind — it has just found the actual scope of the project, which is better learned now than after the first hospital goes live.
Where the hard part is crossing systems rather than building a model, that is an AI system integration engagement — an AI system integrated across your systems, accepted against written targets, with its first 60 days of Operate included. The integration layer is where healthcare AI products go to stall, and it is also where the ones that work stop being demos and start being clinical infrastructure.
References
- HL7 International. FHIR R4 Specification. HL7 International, 2024.
- SMART App Launch Framework. HL7, 2024.
- Tabari, P., Costagliola, G., De Rosa, M., and Boeker, M. State-of-the-Art FHIR-Based Data Model and Structure Implementations: Systematic Scoping Review. JMIR Medical Informatics, 2024.
- Amar, F., April, A., and Abran, A. Electronic Health Record and Semantic Issues Using Fast Healthcare Interoperability Resources: Systematic Mapping Review. Journal of Medical Internet Research, 2024.
- Sujansky WV, Overhage JM, Chang S, Frohlich J, Faus SA. The Development of a Highly Constrained Health Level 7 Implementation Guide to Facilitate Electronic Laboratory Reporting to Ambulatory Electronic Health Record Systems. Journal of the American Medical Informatics Association, 2009.
