AI scribe
AI Scribe Backend on FHIR
An AI scribe captures ambient conversation, drafts a clinical note, and asks the clinician to review and sign. Behind the scenes the data flow is FHIR-shaped: an Encounter for the visit, a DocumentReference for the draft, an audit trail for every model action.
What you can build
- Standard FHIR shape for the captured artifact
Encounter for the visit, DocumentReference for the note, AuditEvent for the model interaction. No bespoke schema for AI-generated content.
- Draft vs signed status is a FHIR concept
DocumentReference.status carries draft, current, or superseded. Workflows do not have to invent a parallel state machine.
- Post-edit workflow is auditable
The clinician's edits are recorded as a new DocumentReference version. The original draft and the signed version are both retrievable.
Who this is for
Product teams building AI-scribe applications and clinical informatics leads evaluating the data model and the access surface of those applications.
Clinical applicability
A primary care clinician runs an AI scribe during a visit. The scribe transcribes the audio, drafts an Encounter note, and writes a DocumentReference linked to the Encounter. The clinician reviews, edits, and signs; the signed note is what enters the record.
Capture flow in FHIR terms
A scribe session begins with an Encounter (existing or new). The transcription is held outside the FHIR backend during capture (a streaming pipeline, often local to the device) and the resulting draft note is written as a DocumentReference linked to the Encounter once the session ends.
The model's contributions are attributable. The DocumentReference.author can be a Device representing the scribe service; the post-edit version is authored by the clinician. AuditEvent records the create, update, and view operations for both identities.
Where the access boundary sits
The scribe service has a service identity with rules that permit Encounter and DocumentReference reads and writes for the patients it is authorized to scribe for. The clinician's identity is the on-behalf-of identity for the session.
Drafts are visible to the clinician (and to anyone the clinician's role permits to see drafts) but typically not to the patient until signed. DocumentReference.status drives the visibility decision; the rule set is a small extension of the standard clinician rules.
Patient-facing scenarios
Some scribes also generate a patient-facing summary (in plain language) alongside the clinical note. The summary is a separate DocumentReference with its own type and its own access scope. Patients see the patient-facing summary; clinicians see the clinical note.
Both documents reference the same Encounter, so they can be reviewed together when needed and accessed independently when not.
Related docs
Related pages
FAQ
Where does the audio go?
Audio is typically processed by a transcription service that runs alongside the scribe, often on-device or in a region-pinned container. The FHIR backend stores the resulting note; whether the audio is retained is a deployment decision.
How do I track the model's contribution to the final note?
DocumentReference versions and Provenance resources cover this. The draft authored by the scribe service is one version; the signed version authored by the clinician is the next. Provenance can record what the model contributed and what the clinician changed.
Can the scribe see prior notes?
Only if the scribe's role permits it. Some deployments give the scribe read access to recent notes for context; others scope the scribe to write-only on the current Encounter. Both are configurable.
What about quality assurance review?
QA reviewers get their own role with read access to draft and signed notes for the patients in scope. The audit log captures their reads alongside the clinician and the scribe.
Does the patient see the draft?
Typically no. DocumentReference.status drives visibility. Patient roles can be scoped to current notes only, not drafts, with a rule that filters by status.
