Skip to content
CCompareHealthcareAPI

Buyer guide · EHR integration

EHR integration for AI scribes: what actually gates your timeline

The payload is easy. Registration, review programmes and per-customer enablement are what turn a one-week write into a one-quarter project.

Written by Compare Healthcare API Editorial DeskReviewed by Technical ReviewLast reviewed Rubric v1.0

Short answer

How does an AI scribe note get into the EHR?

Usually as a FHIR DocumentReference attached to an encounter, created by an app that has been registered with the EHR vendor's developer programme and enabled by each individual healthcare customer. Some EHRs support richer Composition or structured note writes; several support no documented note write at all, leaving copy-paste or HL7 v2 interfaces. The technical write is rarely the constraint — vendor app review and per-customer enablement are, and they are owned by you, not by your scribe vendor.

Cite as: EHR integration for AI scribes guide, Compare Healthcare API, last reviewed 2026-09-01.

Key findings

  • Read access and write access are governed differently in every major EHR programme; assume nothing from a successful read.
  • Per-customer enablement means your integration timeline is repeated, in part, for every health system you sell to.
  • SMART on FHIR launch solves context and identity elegantly, but it presumes your UI runs inside the EHR — a constraint, not a feature, for many products.
  • A scribe vendor that is EHR-agnostic pushes interoperability work to you; one with prebuilt connectors constrains which EHRs you can serve.
  • Document your write path per EHR before you sign a customer contract that assumes it.

The three integration surfaces

First, FHIR REST APIs: the modern default, with DocumentReference the common write target for a finished note. Second, SMART on FHIR launch: an EHR-embedded app that receives patient and encounter context plus an authorised token, ideal when clinicians should never leave the chart. Third, legacy interfaces — HL7 v2 messages or vendor-specific document intake — still common and often the only supported write path in older deployments.

Most real products use two of the three: FHIR for data, SMART for context and launch, and a legacy fallback for customers whose environment predates the rest.

What gates you, in order

Developer programme registration comes first, and its requirements vary from a self-serve sandbox to a formal application with review. Then comes scope approval: write scopes are frequently held to a higher bar than read. Then per-customer enablement, where the health system's own IT must approve and configure your app in their environment — a step whose duration depends entirely on their queue, not your code.

Budget these separately from engineering. Teams routinely ship the write in days and wait months to use it in production.

Agnostic output versus prebuilt connectors

An EHR-agnostic scribe API returns structured output and leaves the write to you. That maximises flexibility and means the interoperability work — and its maintenance — is yours. A vendor with prebuilt connectors reduces your work for the EHRs it covers and constrains you everywhere else.

For most software vendors serving a range of customers, agnostic output plus your own thin write layer ages better, because your customer mix will change faster than any vendor's connector roadmap.

A realistic write-back sequence

  1. 1Pick the EHR that decides revenue

    Do not attempt breadth first. Choose the one your pipeline actually depends on and get it fully working.

  2. 2Register and read first

    Complete developer registration and prove patient and encounter reads in a sandbox before touching writes.

  3. 3Confirm the documented write path

    Verify DocumentReference or Composition support explicitly, and record the exact scopes required.

  4. 4Model authorship and audit

    Decide how signing clinician, draft state and provenance are represented so the chart record is defensible.

  5. 5Run one live enablement

    Take a single friendly customer through enablement end to end and document every step; that document becomes your repeatable playbook.

  6. 6Add fallbacks deliberately

    For customers with no documented write path, define the supported alternative — attachment, HL7 v2, or export — rather than improvising per deal.

Frequently asked questions

What FHIR resource should an AI scribe note be written as?
DocumentReference is the usual target for attaching a finished note to an encounter, with Composition used where richer structured content is supported. The exact choice and required scopes depend on the EHR's documented capability. See the matrix.
Do all major EHRs support writing AI-generated notes?
No. Support ranges from documented FHIR write paths to no documented note write at all, and where writes exist they are typically gated behind app registration and per-customer enablement. Our matrix records the status and the gate for each major vendor. EHR write-back matrix.
Is SMART on FHIR required?
Not for writing notes, but it is the cleanest way to launch an embedded app with patient and encounter context and an authorised token. If your UI lives outside the EHR, you will use FHIR APIs with your own auth instead. SMART on FHIR, defined.
Who owns the EHR integration, us or the scribe vendor?
With an EHR-agnostic scribe API, you do — including registration, enablement and maintenance. With a vendor that ships connectors, they own the covered EHRs and you are constrained to that coverage. Decide deliberately, because it shapes your roadmap. Build vs buy.
Can I write an AI-generated note back to Epic or Cerner?
Both document note-write mechanisms, but reaching them requires an approved app listing plus per-customer enablement rather than only working code. Plan the review and enablement process as the critical path and ship an interim path — formatted copy or an attached document — so the feature is usable while approval is pending. Write-back matrix.
Which FHIR resource should carry a clinical note?
DocumentReference is the usual carrier for a note document, with Composition used on some platforms and proprietary note endpoints on others. Confirm the platform supports creating, not just reading, the resource — read access proves nothing about write permission.
Does SMART on FHIR let my app write notes?
No. SMART on FHIR standardises launch and authorisation, not write permission. An app can launch cleanly in patient context and still have no approved path to create a note. Glossary definition.
How long does an EHR integration for documentation take?
The engineering is usually weeks. App review, security questionnaires and per-customer enablement commonly dominate the timeline, and they scale with the number of customers rather than with code, so treat enablement as recurring onboarding work. Effort model.
Should the scribe vendor own the EHR integration or should I?
Own it yourself if the EHR relationship is your product's moat, which for an EHR vendor or platform it usually is. Letting the documentation vendor own the integration puts its brand and its roadmap between you and your customer's chart.

Evidence & sources

Every factual claim on this page traces to one of the primary references below. Each entry records what it supports and its evidence tier, so documentation can be told apart from judgement.

  1. [1]HL7 FHIR Release 4 specification

    HL7 International · Standard · Tier A — primary documentation

    Supports: Resource definitions (DocumentReference, Composition, Encounter, Condition, MedicationRequest) that clinical documentation output must map onto.

  2. [2]FHIR DocumentReference resource

    HL7 International · Standard · Tier A — primary documentation

    Supports: The canonical target resource for writing a generated clinical note back to a chart.

  3. [3]SMART App Launch framework

    SMART Health IT / HL7 · Standard · Tier A — primary documentation

    Supports: The launch and authorisation pattern for embedding a documentation app inside an EHR.

  4. [4]United States Core Data for Interoperability (USCDI)

    Office of the National Coordinator for Health IT (ASTP/ONC) · Standard · Tier A — primary documentation

    Supports: The data classes certified EHRs must exchange, which bound what structured output is useful.

  5. [5]HTI-1 final rule — algorithm transparency (DSI) requirements

    ASTP/ONC · Regulation · Tier A — primary documentation

    Supports: Transparency obligations that apply when predictive or generative decision support is surfaced inside certified health IT.

  6. [6]Epic on FHIR developer documentation

    Epic Systems · Vendor documentation · Tier A — primary documentation

    Supports: What an integrator can and cannot write back to an Epic chart, and under which app programme.

  7. [7]Oracle Health (Cerner) FHIR APIs

    Oracle Health · Vendor documentation · Tier A — primary documentation

    Supports: FHIR write capability and app authorisation model for Oracle Health environments.

  8. [8]athenahealth developer portal

    athenahealth · Vendor documentation · Tier A — primary documentation

    Supports: API-based document and note write-back paths for athenahealth practices.

Source tiers are defined on the methodology page. Outbound links are unaffiliated and carry no commercial relationship.

Continue