FHIR API Integration
FHIR R4 APIs, SMART on FHIR apps, and Bulk FHIR export.
Explore FHIR API IntegrationHealthcare AI
AI in healthcare fails at the seam, not at the model. We build the integration layer under whichever vendor you pick: ambient scribes, clinical decision support, and imaging tools wired into Epic, Oracle Health, and custom systems via FHIR, CDS Hooks, and SMART on FHIR.
How AI integration works
From trained model to bedside AI.
An algorithm becomes a deployed clinical tool through a few well-worn moves: integration surface, deployment pattern, and go-live. Pick one to jump ahead.
Where it attaches
Healthcare AI fails at the seam, not at the model
Buying the model is the easy part. Every hard problem in a healthcare AI rollout lives where the tool meets the chart: what it is allowed to read, what it is allowed to write, how fast it has to answer, and what happens the first time it does not.
FHIR write-back
Getting the output back into the chart
An ambient scribe that produces a beautiful note in its own web app has solved nothing. The note has to land in the record, attached to the right encounter, attributed to the right author, and visible to the next clinician who opens the chart. That is a FHIR write, and it is where most pilots stall.
- DocumentReference for narrative notes, Composition when the note has required structured sections
- Writes bound to the encounter, not just the patient, so the note appears in context
- Provenance and author attribution set so the chart shows the note came from a tool
- SMART on FHIR scopes requested at write level, which most vendor apps ask for at read level only
- Reconciliation for the write that silently succeeded against the wrong encounter
Failure modes we have actually hit
It fails at the join, not in the model
Across client AI work the failures cluster, and almost none of them are model failures. They are integration failures with a clinical blast radius, which is a different thing from an outage. Here is what actually goes wrong.
- CDS Hooks is synchronous: blow the latency budget and the EHR drops your card with no error anyone sees
- A scribe granted patient/*.read cannot write, and the failure surfaces as a missing note rather than a 403
- Bulk FHIR $export is throttled per tenant, so a cohort pull that worked in a demo org times out in production
- PHI reaching a model endpoint that is outside the BAA, usually through a logging or tracing side channel
- Model output written as free text when downstream reporting needs a coded Observation
Vendor-neutral by construction
The integration layer under whichever vendor you pick
We are not an AI vendor and do not compete with the one you choose. What our clients keep hiring us for is the layer beneath: the connection from a scribe, a decision-support service or an imaging algorithm into Epic, Oracle Health, MEDITECH, athenahealth or eClinicalWorks. Swap the vendor and that layer survives.
- Vendor evaluation scored on integration surface rather than demo quality
- One interface engine fronting every AI tool, so tool number four is a channel and not a project
- Epic Showroom, Oracle Code and athenaOne Marketplace listing paths where the tool needs them
- Contract and BAA review for the data flows the tool actually requires, not the ones it advertises
- An exit path: when a vendor is replaced, the integration layer is reused rather than rebuilt
Minimum necessary, enforced
What the model is actually handed
The safest AI deployment is the one where the model never sees what it does not need. That is a pipeline decision made long before inference, and it is far easier to build in at the start than to retrofit after a vendor security review asks for it.
- De-identification to Safe Harbor or Expert Determination, applied in the pipeline rather than at the vendor
- Date generalisation and geographic truncation on the fields that most often leak identity
- Bulk FHIR $export for training and evaluation cohorts, scoped to the minimum necessary fields
- Audit of every record that reached a model endpoint, which is what a breach review will ask for
- Re-identification held on your side of the boundary when results have to return to a real patient
AI in healthcare
Three surfaces, and every tool uses one of them
Strip away the category names and healthcare AI reaches the chart through exactly three doors. Which door a tool uses determines its latency budget, its failure mode, and how long integration takes.
Ambient documentation, clinical decision support, imaging triage, prior-auth automation and population risk all sit on one of these. A tool that claims a fourth way in is usually describing a screen-scrape, and that is a maintenance liability rather than an integration.
| Feature | FHIR / SMART on FHIR | CDS Hooks | DICOM / Imaging |
|---|---|---|---|
| Primary AI use | Ambient scribe, app launch, data read/write | Real-time risk scores + order recommendations | Imaging AI inference + findings |
| Fires on | EHR launch / scheduled job | order-sign · patient-view · order-select | C-STORE / new study arrival |
| Writes back as | DocumentReference, Observation, ServiceRequest | CDS Cards in the EHR UI | DICOM-SR → PACS worklist |
| Latency profile | Async / on-launch | Synchronous (sub-second) | Near-real-time |
| Fails as | A write that lands on the wrong encounter | A card the EHR silently drops | A finding that never reaches the worklist |
| Core standards | FHIR R4, SMART, OAuth 2.0 | CDS Hooks, FHIR R4 | DICOM, DICOMweb |
Integration & software work shipped for
Choosing a vendor
Evaluate healthcare AI companies on the integration surface
Demos are built to look identical. What separates two AI vendors in practice is what they need from your EHR, how they write results back, and who owns the connection when it breaks at 2am. These are the questions worth asking before a contract, not after.
| Feature | Ambient documentation | Clinical decision support | Imaging AI |
|---|---|---|---|
| Integration surface | SMART on FHIR app launch | CDS Hooks service | DICOM C-STORE + DICOMweb |
| Ask: does it write back? | DocumentReference into the encounter, or a copy-paste workflow? | A CDS Card, or an email? | DICOM-SR to the worklist, or a separate portal? |
| Ask: what scopes? | Write scopes, or read-only with a human re-keying | patient-view and order-sign, or one hook only | Modality worklist access, or manual export |
| Ask: whose latency budget? | Async, so latency is a UX problem | Synchronous: their slowness becomes your dropped card | Batch, so the risk is backlog not blocking |
| Typical integration effort | 3–6 weeks | 4–8 weeks | 6–12 weeks |
| Who owns the connection | Usually you | Usually you | Usually you |
The last row is the one buyers miss. Almost every AI contract leaves the integration on the provider side of the line, which means the tool is only as good as the layer underneath it. That layer is what we build, and it is the reason clients bring us in alongside a vendor rather than instead of one.
Use cases
Six examples of AI in healthcare, and the plumbing behind each
Six AI deployment patterns we ship in production: ambient documentation, early-deterioration alerts, imaging triage, prior-auth and coding automation, population risk stratification, and AI patient intake. Each pairs a real clinical problem with the integration plumbing that lands it in the workflow, plus the outcome metric that justifies the budget.
Deploying healthcare AI on AWS? Buy the EHR integration that powers it through AWS Marketplace.
Procure through AWS Marketplace and draw down your committed AWS spend (EDP). No new vendor onboarding, no new paperwork.
Links to the AWS Marketplace listing ↗ What's next
Beyond ambient scribes: the next AI categories
Ambient documentation is the first wave. Voice AI for patient intake is already live in early enterprise rollouts, with agentic clinical workflows, generative care plans, and synthetic clinical data moving from research toward production. Each category needs the same FHIR, CDS Hooks, and EHR write-back foundations we build today.
Measure first
Score the readiness, then price the case
Two free tools, no sign-up. Run them before a vendor conversation so you arrive with a number rather than an impression.
AI readiness assessment
Seven dimensions, five-point scale, scored
Data quality, integration surface, governance, security posture, clinical sponsorship, workflow fit and measurement. Weighted by the use case you pick, with a vendor-fit recommendation and a shareable score at the end.
Score your readiness Ambient AI scribe ROIPayback period on an ambient scribe rollout
Annual savings, payback and net ROI from your own clinician count, note burden and licence cost, benchmarked against published ambient-scribe pricing so the inputs are defensible in a budget conversation.
Run the numbersHave an AI rollout coming up: scribe, CDS, imaging, or population analytics? Let's scope the integration.
Book a Consultation Case Studies
AI Integrations We've Shipped
Three patterns we deploy most often: ambient documentation, CDS Hooks risk surfacing, and Bulk FHIR population pipelines.
Ambient AI Scribe: EHR Integration & Workflow
A multi-clinic ambulatory organization deploying an ambient AI documentation tool needed the EHR-side plumbing to make it work in production. Saga built the SMART on FHIR launch from inside Hyperspace, the DocumentReference write-back pipeline that returns transcripts to the chart, and the care-team coordination handoffs that keep delegated workflows intact. The AI model is the vendor's; the integration that gets it into production is ours.
Provider Encounter
// Ambient capture begins
"context": "Patient · Encounter"
"launch": "smart-on-fhir"
"audio": "streaming"
"context": "Patient · Encounter"
"launch": "smart-on-fhir"
"audio": "streaming"
AI Transcription
// Vendor processes audio
"transcript": "streaming SOAP"
"vendor": "Abridge"
"latency": "<3s"
"transcript": "streaming SOAP"
"vendor": "Abridge"
"latency": "<3s"
Chart Writeback
CDS Hooks Sepsis Service for a Hospital System
Hospital system fires CDS Hooks on order-sign and patient-view to call a sepsis-risk model, surface evidence-based response cards, and pre-build the sepsis bundle for one-click ordering. Sub-500ms response budget across all hooks.
Order Hook Fires
// CDS Hooks request
"hook": "order-sign"
"context": "Patient · ICU"
"prefetch": "vitals · labs"
"hook": "order-sign"
"context": "Patient · ICU"
"prefetch": "vitals · labs"
Risk Model + Card
// CDS response
"risk": "0.84 · sepsis"
"card": "warning"
"latency": "312ms"
"risk": "0.84 · sepsis"
"card": "warning"
"latency": "312ms"
Bundle Ordered
Bulk FHIR Pipeline for Population Health Analytics
Health-system informatics team uses Bulk FHIR $export to extract Patient, Observation, and Condition resources nightly into a population-health analytics platform. Replaces a fragile nightly CSV pipeline that took hours to reconcile.
$export Request
// SMART backend services
"POST": "/Group/all/$export"
"types": "Patient,Obs,Cond"
"since": "2026-04-30"
"POST": "/Group/all/$export"
"types": "Patient,Obs,Cond"
"since": "2026-04-30"
NDJSON Streams
// Manifest returned
"Patient.ndjson": "2.1M rows"
"Observation.ndjson": "18M"
"size": "192 MB · 4m18s"
"Patient.ndjson": "2.1M rows"
"Observation.ndjson": "18M"
"size": "192 MB · 4m18s"
Cohort Identified
Frequently Asked Questions
Common Questions
Through exactly three doors: FHIR and SMART on FHIR for app launch and read/write, CDS Hooks for real-time recommendations inside the ordering workflow, and DICOM for imaging. Everything else is getting a tool through one of those doors and into production clinical workflows, not just standing up an AI project. That includes vendor selection, FHIR API integration, SMART on FHIR launch, EHR writeback (Epic, Oracle Health / Cerner), HIPAA BAA + compliance validation, clinician workflow design, training, and ongoing monitoring. The AI model itself is ~20% of the work; the other 80% is integration and adoption. For productizing AI as a patient-facing or clinician-facing application, see our healthcare app development practice.
Take our 90-second AI Readiness Assessment. It scores you across the 7 dimensions that determine whether an AI pilot will succeed or stall: FHIR API availability, integration engine maturity, current HIPAA SRA, clinical champion, de-identification pipeline, vendor evaluation process, and change-management capacity. You’ll get a tier (Early Exploration / Ready to Pilot / Production Ready) plus tailored next steps.
It depends on your EHR, specialty mix, and deployment preferences. Epic shops often evaluate Abridge (Epic partnership), Nuance DAX Copilot, and Suki. Oracle Health / Cerner shops lean toward Abridge, Suki, and Ambience. Ambulatory-focused practices frequently pick Freed or Heidi for lower cost per provider. Enterprise deployments with strict compliance often choose Nuance DAX or Commure. Use our ROI calculator to model the financial case, then book a consultation for vendor-neutral selection guidance.
Ambient scribe: 90-120 days for a single-department pilot (vendor selection 4 weeks + contracting 4 weeks + integration + training + go-live). Enterprise rollout across an entire health system: 12-18 months. Clinical decision support: 6-9 months to pilot (longer because of clinical validation and workflow design). Imaging AI: 4-8 months depending on PACS integration complexity. FDA-cleared AI devices: 3-6 months once regulatory and security reviews are complete. The biggest variables are vendor selection speed, HIPAA/BAA cycle, and clinical champion availability.
Most modern AI platforms integrate primarily via FHIR R4 APIs and SMART on FHIR, though some still support HL7 v2 fallback. If you don’t have FHIR APIs live in production, that’s the #1 blocker to flag in any AI vendor evaluation. We can help stand up FHIR endpoints (Patient, Encounter, Observation, DocumentReference, MedicationRequest are table stakes) in parallel with vendor selection. See our FHIR API Integration services.
Every AI vendor requires a Business Associate Agreement (BAA), which in turn requires a current HIPAA Security Risk Assessment on your end (usually within the last 12 months). Beyond the BAA, we manage the subprocessor chain (cloud providers, third-party model hosts, data-labeling vendors) and validate that de-identified training / QA pipelines meet HIPAA Safe Harbor or Expert Determination standards. See our HIPAA compliance services.
Yes. These are our two most-deployed EHR integration environments. For Epic, we handle App Orchard submission, SMART on FHIR launch, Epic Link for note writeback, and Haiku/Canto mobile integrations. For Oracle Health / Cerner, we work with Millennium, PowerChart, and CCL-based integrations, plus the newer Oracle FHIR API surface. We’ve integrated AI scribes, CDS tools, and imaging AI into both platforms.
Score them on the integration surface rather than the demo, because the demos are built to look identical. Ask what scopes the tool needs, whether it writes results back or leaves a human re-keying, whose latency budget it spends, and who owns the connection at 2am (almost always you). Generic AI consultancies focus on the AI itself: model selection, data strategy, MLOps. We focus on the healthcare integration layer that’s 80% of any real deployment: FHIR, HL7 v2, integration engines (Mirth, Rhapsody, Iguana), EHR-specific wiring (Epic SMART on FHIR, Cerner CCL, MEDITECH APIs), HIPAA, IEC 62304 for regulated devices. That’s the work that determines whether your AI ever reaches a patient. See our team’s 15+ years of healthcare integration experience.
Related Services
Explore More Services
Keep reading
Related resources
Ready to deploy AI in your clinical workflows?
Talk to our team about vendor selection, integration architecture, and a 90-day pilot plan.
- 15 min conversation
- Healthcare IT engineers, not sales
- Reply within one business day
Book a 30-min call · or email us and we'll reply within one business day.
Intent
Details
Contact