ClinicalAutomationwith FHIR
Audio → Transcribe → Structure → Generate notes/codes → FHIR resources in EHR
SMART-on-FHIR platform with Medplum. Plan deployment boundaries, clinician review and FHIR integration.
Pilot planning, not measured clinical performance. Reviewed October 7, 2026.
One-shot scribe demos rarely make it into production
Clinicians spend hours per day on documentation, prior-auth letters, patient messages, and structured coding — time that should go to care.
Shadow IT and brittle pilots never scale system-wide because they fail at the integration layer.
Plan an ambient documentation pilot
Define the recording workflow
Agree when recording starts and stops, how participants are informed, who can pause capture and how a failed recording is handled. Specify permitted audio processing, retention and deletion with the organization. Test background noise, multiple speakers and interruptions on representative permitted examples.
Separate transcription from note drafting
Evaluate speaker attribution and transcript omissions before evaluating the generated note. Define required note sections, what context may be retrieved and how contradictory information is displayed. Keep transcript evidence accessible to authorized reviewers and flag uncertain content instead of turning it into a confident statement.
Measure the clinician’s complete task
Compare drafting plus review and correction with the existing process on the same types of encounter. Record unsupported statements, missing facts, wrong attribution and editing effort. Define critical error categories with clinicians and retain difficult examples. A short generation time does not prove a reduction in documentation work.
Test the receiving EHR
Agree the actual resource profiles, patient and encounter identifiers, access scopes and note-status mapping with the EHR owner. Begin in a test environment. Validate duplicate prevention, expired tokens, partial failures, retries, amendments and revoked access. SMART authorization does not by itself prove compatibility with a particular writeback workflow.
Keep approval and rollout explicit
Treat generated notes as drafts until the authorized clinician reviews them. Document who can approve, amend and sign, and where those actions are recorded. Start with shadow operation and a bounded pilot group, with stop conditions and a fallback documentation process.
Hand over an operable system
Include data-flow and retention settings, connector contracts, evaluation findings, versioned prompts and models, monitoring and a rollback runbook. Estimate capture, transcription, generation, storage, integration and support costs separately. Scope acceptance around measured results from the proposed workflow.
Medplum provides FHIR-based developer tools. Its official documentation and SMART demonstration provide integration references; they do not establish the performance or compliance of a completed ambient scribe.
Medplum
Medplum gives FHIR storage, auth, SDKs, and subscriptions so teams can model reviewed outputs as clinical resources. Provenance, permissions and receiving-system compatibility still require explicit implementation and testing.
Architecture
Technical Pipeline
# Schematic pseudocode, not an executable SDK example.
# Extracted facts remain candidates until clinician review.
facts = extract_facts(transcript)
resources = [
Condition(code=snomed_code, subject=patient),
MedicationStatement(medication=rxnorm, subject=patient),
AllergyIntolerance(code=rxnorm, patient=patient),
Observation(code=loinc, value=value, subject=patient),
Composition(section=[...], author=practitioner)
]
for resource in resources:
validate_fhir(resource) # receiving profiles / bindings
reviewed = clinician_review(resources, transcript)
if reviewed.approved:
write_with_identity_scope_and_retry_checks(reviewed)Data Model
Illustrative Pilot Blueprints
Proposed workflows requiring evaluation, not measured client results.
Primary-Care SOAP with Coding & Orders
Prior Authorization Assistant
Specialty (Oncology) Consult Letter
This fragment uses synthetic references and omits authentication setup. Test the selected SDK and receiving profiles in a sandbox. A preliminary Composition is not a signed document; finalization and attestation require the agreed review workflow. See the FHIR R4 Composition specification.
import { MedplumClient } from '@medplum/core';
const medplum = new MedplumClient({
fetch,
baseUrl: process.env.MEDPLUM_BASE_URL
});
// Authenticated test client and synthetic references required.
// Create a preliminary draft, not a signed document.
await medplum.createResource({
resourceType: 'Composition',
status: 'preliminary',
date: new Date().toISOString(),
title: 'Illustrative draft progress note',
type: {
coding: [{
system: 'http://loinc.org',
code: '11506-3',
display: 'Progress note'
}]
},
subject: { reference: 'Patient/123' },
encounter: { reference: 'Encounter/enc-789' },
author: [{ reference: 'Practitioner/doc-456' }],
section: [{
title: 'Assessment & Plan',
text: { status: 'generated', div: '<div xmlns="http://www.w3.org/1999/xhtml">Illustrative draft; clinician review required.</div>' }
}]
});Governance
FHIR-native, governed, and reviewable inside the EHR workflow
Using Medplum as backbone for on-prem/VPC ambient scribe, coding, and prior-auth assistants that write auditable FHIR resources
Frequently Asked Questions
How should an ambient documentation pilot be compared with an existing tool?
Evaluate both tools on the same representative encounters and note requirements. Compare omissions, unsupported statements, editing time and integration behavior; do not assume equivalent accuracy without measured evidence.
How should generated clinical notes be reviewed?
Define a clinician review and approval workflow before release. Test transcription, speaker attribution and note accuracy under representative conditions, and measure editing burden rather than assuming the tool saves time.