ArchitectureHealthcare

Connecting AI models to the EHR with FHIR, CDS Hooks and SMART on FHIR

EHR AI integration works best when you design backwards from the moment a clinician should see the output. Population models usually read data in bulk and return work lists; point-of-care models answer a CDS Hooks request or run inside a SMART on FHIR app; event-driven models listen to HL7 v2 or FHIR notifications. Each pattern differs in latency, write-back, identity and audit, and each needs a fallback for when the model is unavailable.

Reviewed 10 October 2026 6 min read

On this page

Start from the screen where the clinician will act
Five EHR integration patterns compared for AI workloads
Reference architecture from EHR event to audited result
Authorization scopes and the minimum necessary data set
Choosing how a model's output enters the legal record
Failure modes in production and the control for each
A readmission risk score shown during discharge planning
Questions and answers
Sources

Start from the screen where the clinician will act

Most stalled EHR integrations started from the data. A team builds a model on an extract, then discovers there is no sensible place in the workflow to show the result, or that the place clinicians would look updates too slowly. Reverse the order: name the role, the screen and the moment, such as a hospitalist opening the discharge navigator or a pharmacist verifying an order, and only then choose the pattern that can reach it.

The same model can need two integrations. A deterioration score might be computed every hour from streamed vitals for a charge nurse's unit board, and fetched on demand when a physician opens the chart. Treat each surface as its own design with its own latency and failure behavior.

Five EHR integration patterns compared for AI workloads

Pattern	Best suited to	Timeliness	Results back to the EHR	Main constraint
HL7 v2 interface feeds (ADT, ORU, ORM)	Event-driven models: admissions, results, orders	Near real time through the interface engine	Possible via outbound result messages	Message variation between sites; interface team capacity
FHIR REST API	Fetching a patient's record when a model is triggered¹	On request	Limited and vendor-specific for writes	Rate limits and which resources the EHR exposes
Bulk FHIR export	Population scoring, cohort building, training data²	Asynchronous batch	None directly; results return by another route	Large files; schedule and storage controls
CDS Hooks service	Suggestions at a workflow step such as opening a chart or signing an order³	Synchronous; must answer fast	Cards with suggested actions a clinician accepts	Late responses may simply not display
SMART on FHIR app	Rich interactive views launched inside the EHR⁴	Interactive	Through FHIR writes the EHR permits	Extra clicks; app review in vendor marketplaces

Most production designs combine two patterns, for example Bulk FHIR to score a population overnight and CDS Hooks to surface the score when a chart is opened.

Reference architecture from EHR event to audited result

Clinical workflow surface
CDS Hooks cards, SMART app panels, work lists, in-basket messages or draft notes inside the EHR.
Integration layer
Interface engine for HL7 v2, FHIR client, CDS Hooks endpoint and the queue that buffers requests.
Inference service
Feature assembly, the versioned model, thresholds and the output contract the EHR side expects.
Identity and data controls
SMART authorization, minimum-necessary data sets, encryption and environment separation for protected health information.
Audit and monitoring
Inputs, model version, output, displayed card and clinician action recorded for every call.

Conceptual layering of an AI integration with an EHR. It is not a specific vendor's architecture or a deployed system.

Authorization scopes and the minimum necessary data set

SMART on FHIR uses OAuth 2.0 so an app or service receives only the scopes it requests and the EHR grants, either in a user's launch context or as a backend service with its own credentials⁴. Ask for the resources the model actually consumes, such as observations, conditions and medications, rather than broad read access. Backend services for Bulk FHIR authenticate with signed assertions rather than a user session².

Narrow scopes are also how you meet HIPAA's minimum necessary standard, which requires covered entities to limit protected health information to the minimum needed for the purpose⁵. Feature lists should be reviewed by privacy staff before the interface build, because adding a field later often means a new security review.

Expect the EHR team to ask for model documentation. Certified health IT must let a limited set of users access and edit source attributes for predictive decision support interventions, including intended use, population, training data, external validation and monitoring⁶. A pending proposed rule would remove those requirements⁷, but having the answers ready shortens any governance review either way.

Choosing how a model's output enters the legal record

If
The output is narrative text, such as a summary or draft note.
Then
Place it as an unsigned draft the clinician edits and signs, never as a filed note.
The signing clinician owns the content; the record should show who accepted it.
If
The output is a score or classification.
Then
Store it as a discrete result with the model name, version and timestamp, displayed beside the inputs that matter.
Clinicians and auditors need to see which version produced the number on that day.
If
The output suggests an order or referral.
Then
Return a CDS Hooks card with a suggestion the clinician must accept, rather than writing the order.
Automated ordering moves the tool toward device territory and removes the human check.
If
The output ranks a population for outreach.
Then
Send it to a care-management work queue, not into individual charts.
A list for planners does not belong in a record clinicians read as patient-specific advice.

Failure modes in production and the control for each

The model service is slow or down

Early signalCards stop appearing with no visible error to clinicians.

MitigationSet timeouts, return no card rather than a stale one, alert the support team and agree a downtime procedure with clinical leads.

Wrong patient or encounter context

Early signalOutputs that reference results from a different admission.

MitigationUse the launch or hook context identifiers, never free-text matching, and test merges and transfers explicitly.

Inputs arrive late or change after scoring

Early signalScores that disagree with the chart a few hours later.

MitigationRecord input timestamps with each output and rescore on material result updates.

Silent version drift

Early signalPerformance shifts after an unannounced retrain or an EHR upgrade that renames codes.

MitigationPin model versions, map codes through a maintained terminology layer and rerun validation after either side changes.

Card overload

Early signalRising dismissal rates and complaints about interruptions.

MitigationReview acceptance and override data with clinicians and raise thresholds or move the output to a passive view.

A readmission risk score shown during discharge planning

Questions and answers

Should we use the EHR vendor's built-in AI platform or integrate our own model?

Vendor platforms reduce interface work and keep data inside the EHR's environment, but limit model choice and portability. External models give control over training, versioning and evaluation, at the cost of building and supporting the integration. Many health systems use the vendor platform for common use cases and a FHIR or CDS Hooks integration where they need a model the vendor does not offer.

Can CDS Hooks write data back into the patient record?

Not directly. A CDS Hooks service returns cards that can carry suggested actions, such as creating or updating a resource, and the EHR applies them only when the clinician accepts³. Links can also launch a SMART app for richer interaction. Writing results as discrete data without a clinician's action needs a separate route, such as FHIR writes the EHR permits or an HL7 v2 result interface.

Is Bulk FHIR suitable for training models?

It is a common route for extracting cohorts because it exports resources for a group of patients asynchronously². Training data still needs a privacy basis, such as de-identification or an approved research or operations use, plus storage controls and a record of exactly which export trained which model version. Export performance and permitted resources vary by EHR, so test with realistic group sizes.

Sources

HL7 FHIR Release 4 — HL7 International · checked 10 October 2026
Bulk Data Access Implementation Guide — HL7 International · checked 10 October 2026
CDS Hooks specification — HL7 International · checked 10 October 2026
SMART App Launch Implementation Guide — HL7 International · checked 10 October 2026
45 CFR § 164.502 Uses and disclosures of protected health information: general rules (minimum necessary) — eCFR · checked 10 October 2026
45 CFR § 170.315(b)(11) Decision support interventions — eCFR · checked 10 October 2026
HTI-5 Proposed Rule Chart — Assistant Secretary for Technology Policy / ONC · checked 10 October 2026

More in Healthcare

Back to Healthcare

Next step

Sketch the integration for one model and one screen

Tell us which EHR you run, the model or use case, and the role and screen where the output should appear. We will come back with a candidate pattern, the data scopes it needs and the governance questions to settle before the interface build.

Describe your use case