Voice is the interface: a reference architecture for paramedic handover and patient follow-up on FHIR

The most information-dense moment in an unplanned admission lasts about thirty seconds. A paramedic wheels a patient through the doors and delivers a verbal handover - mechanism, observations, interventions, medications, the things they noticed at the scene that nobody else will ever see. The receiving team hears it once. Then the trolley moves, the next job is dispatched, and what survives into the clinical record is whatever someone later types from memory.

Every serious study of clinical handover says the same thing: detail is lost at exactly the point where it matters most. The fix is not another form. The fix is to treat the spoken handover itself as the source document, and to build a pipeline that can turn speech into structured, coded, standards-shaped clinical data fast enough to beat the trolley to the ward.

This piece walks through a reference architecture for doing that on AWS with FHIR AU Core as the contract - built for the Australian setting, with speech capture at the kerbside, agentic structuring and coding in the middle, and a governance loop supervising the lot.

The architecture at a glance

The spine: from voice to a filed document

The core flow - the one that has to beat the trolley - runs left to right through the middle of the diagram.

Capture. The paramedic speaks; a transcription application in the vehicle streams audio to Amazon Transcribe. Nothing is typed. The audio is ephemeral; the transcript is the artefact.

Structure. The transcript lands with an admissions agent whose entire job is to turn narrative into an AU Core-conformant FHIR Encounter and its supporting resources. It follows a mnemonic-structured handover (IMIST-AMBO, the ambulance handover protocol used across Australian jurisdictions), so the model is extracting into a known clinical shape, not inventing one.

Code. A separate clinical coder agent assigns SNOMED CT and ICD-10-AM codes. It works inside guardrails: clinical guidelines served through Amazon Bedrock, Amazon Comprehend Medical for entity detection, and a terminology server (Ontoserver) as the authority on what a valid code actually is. The agent proposes; the terminology service disposes.

Persist and assemble. Coded resources persist to durable storage and to a HAPI FHIR server profiled for AU Core. A document service assembles the handover into a coherent Bundle and posts a DocumentReference to the receiving EHR.

By the time the patient reaches the ward, the record is already there - structured, coded, queryable, and traceable back to the words the paramedic actually said.

Same backbone, different front doors

The reason this is an architecture and not a demo is the left and top of the diagram: the pipeline does not care where the voice comes from.

• Admissions kiosk. A clinic consult captures clinician and patient voice in parallel; from the transcript onward the pipeline is identical.
• Biomedical device follow-up. Care does not stop at discharge. A home blood-pressure cuff posts an Observation over mutual TLS; a Lambda picks it up, raises an event, and a voice agent telephones the patient for a structured follow-up conversation whose output is a QuestionnaireResponse on the record.
• Inbound symptom check. Sometimes the patient calls first. An inbound call is verified before any clinical conversation happens, then handed to the same voice agent with a clinically bounded script.

One pipeline, five doors. Each new front door is a capture adapter, not a new system.

The part that makes it defensible: governance

Nobody should - and in an Australian public health setting, nobody will - accept "an agent wrote the clinical record" without an answer to the obvious question: who is checking the agent?

The answer in this architecture is structural, not procedural. An agent auditor runs continuously alongside the pipeline. It samples outputs from the admissions agent and the coder agent, compares them against ground truth, and surfaces discrepancies to a governance console where a human reviews them. Corrections feed back into the Bedrock-hosted guidelines, so the guardrails tighten with every cycle. The auditor is itself an agent - but its output goes to a person, and the review trail is part of the record.

Three design positions follow from this, and they generalise well beyond handover:

• Agents are narrow. One agent structures encounters. One agent codes. Neither can do the other's job, and neither talks to the EHR directly. Small scopes are auditable scopes.
• FHIR is the contract. Every hop in the pipeline emits a FHIR resource conformant to AU Core. That is what makes the system testable - a resource either validates or it does not - and what makes every component replaceable.
• Voice is never trusted directly into the record. Speech becomes a transcript, the transcript becomes proposed structure, the structure is validated against terminology and profiles, and the contentious cases go through a human. The microphone is an input device, not an author.

Reading the wire

Architecture diagrams flatter every system; sequence diagrams tell the truth. Below is the same design as a wire-level walkthrough, distilled to the interactions that matter: eight phases from the paramedic opening the recorder to the follow-up conversation landing back on the record as a QuestionnaireResponse. Two details are worth pointing at. Step 10 is the human gate - the paramedic reviews and approves every proposed code before anything touches the record. And step 11 runs $validate on the full transaction Bundle before the real POST - the pipeline earns its way into the FHIR server rather than assuming it.

Why this matters now

The components in this diagram are all boring, in the best sense: Transcribe, Bedrock, Lambda, SNS, DynamoDB, a HAPI FHIR server, Ontoserver. Nothing here is speculative. What has changed in the last two years is the middle of the pipeline - models are now good enough at structured clinical extraction, inside guardrails, to make the thirty-second handover a document rather than a memory. The organisations that benefit first will be the ones whose data layer is already standards-shaped: if your estate speaks FHIR, voice is just another ingestion channel.

If you are weighing up something in this shape - for handover, for referrals, for follow-up - talk to us. This is the lane Basal works in: the FHIR profiling, the integration, and the governance artefacts that let a system like this actually go live in an Australian health service.