The model is not what stalls a healthcare AI product. The integration layer is, and FHIR does not save you. Standards fix the data's shape and decide almost nothing about the workflow, the auth surface, or what your system does at 2am when a required field is absent.
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 limitation clear: interoperability standards reduce translation pain, and deployment still turns on workflow fit, versioning reality, and local implementation details. HL7 v2 is worse: an analysis of v2 optionality (JAMIA, 2009) counted 4,132 data elements in the standard result message with 85% of them optional.
ML LABS built the EHR and FHIR integration layer of the cloud backend behind HeartSciences' AI-ECG platform, and its protocols split by job: HL7 v2 carries the order and result workflow, FHIR carries data access and launch context, and per-organization authentication prevents cross-tenant data access on both. Getting that split backwards is how a team ships an integration that the ordering clinician's workflow cannot reach.
FHIR 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. 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 a single organization. The integration layer normalizes all four before the model sees an input, or the model sees garbage and reports it with confidence.
Workflow Mismatch Is The Tax
Take a schematic case, illustrative rather than 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. Medication status lives on MedicationRequest at one site, MedicationAdministration at another, a custom extension at a third. The model logic never changes. The data-shaping work multiplies with every organization, off the roadmap.
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 turns out to be wrong. 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 discipline that lets the HL7 result-delivery layer serve many hospitals from one codebase: every site-specific value is configuration, not code, and validation refuses to build a message when a required mapping is missing for that site.
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. 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. Hard-coding a single credential set, even temporarily, becomes a structural problem the moment a second organization is onboarded. Session management then has to enforce organizational boundaries, because a clinician working across several health systems can present a token issued in one context inside another.
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. FHIR-sourced users follow a different auth path than standard users, and every endpoint has to handle each correctly. An endpoint that quietly skips the FHIR auth path is a finding that arrives late and costs the most to fix.
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, the failure presents as a missing value rather than a hard error. That is the 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 is cheap to decide during design and expensive to decide during a live clinical complaint. The cheapest way to find out which you have not decided is an EHR integration simulator, built before sandbox access is granted rather than after.
First Steps
- Write the workflow contract. The clinical event, the target resources, the required fields, and the per-organization configuration surface, 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 understood, proceed. If either is still moving, fix that first; integration work only makes it more expensive 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, hardened endpoints, and defined behavior for every failure the clinical workflow can produce. A team that reads the list and recognizes three items it has not decided has found the project's actual scope, which is better learned now than after the first hospital goes live. Where the hard part is crossing systems, not building a model, that is the build: one workflow integrated across your systems, accepted against written targets, kept running by the person who built it.
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.
