DEV Community

Cover image for Architecting a Real-Time AI Medical Scribe System
Ubaid Pisuwala
Ubaid Pisuwala

Posted on

Architecting a Real-Time AI Medical Scribe System

Ask a clinician what they want from an AI scribe and the answer is almost always understated: "just write the note while I talk to the patient." Ask an engineer to build that, and the understatement disappears. Underneath that one sentence is a system that has to capture audio in a noisy exam room, separate clinician speech from patient speech, transcribe medical terminology in real time, map raw language onto structured clinical concepts, and produce a note formatted the way a specific specialty expects — all while the encounter is still happening, and all without ever putting a wrong drug name or a hallucinated symptom into a legal medical record.

This is a substantially harder systems problem than "transcription plus AI," and most of the products that fail at it fail for predictable architectural reasons. This article walks through how a real-time AI medical scribe is actually built, end to end — and where AI Medical Scribe System work has concentrated engineering effort to make the pipeline hold up in a live clinical setting rather than just in a demo.

01 What "real-time" actually has to mean

"Real-time" is doing a lot of work in this category, and most of it is undefined. A scribe that produces a note five minutes after the visit ends is not real-time in any sense a clinician cares about — but a scribe that tries to transcribe and structure every word with zero latency will be wrong constantly, because clinical meaning frequently depends on what's said three sentences later.

The useful definition is a latency budget: the maximum delay between speech and a structured, reviewable note that a clinician will tolerate without the tool feeling broken. In practice, that budget sits in the low single-digit seconds for live transcript display, and well under a minute for a structured note draft ready at the end of the visit. Every architectural decision in the pipeline gets evaluated against that budget.

Indicative per-stage latency for a mid-utterance pipeline pass. Stages run concurrently where possible — note structuring runs on completed segments, not the full transcript, to stay inside the visit-end latency budget.

This budget shapes the entire stack decision: which steps can run in a streaming, incremental fashion, and which steps genuinely need to wait for a complete thought, a complete sentence, or a complete topic segment before they can be trusted to run at all.

02 The pipeline, stage by stage

A production-grade ambient scribe is not one model — it's a chain of purpose-built components, each making a narrower decision than the one before it. Treating the whole thing as "send audio to an LLM, get back a note" is the most common reason early scribe prototypes never make it past a pilot.

Capture
Ambient audio ingestion & voice activity detection
Mobile or in-room hardware streams audio continuously, with on-device voice activity detection (VAD) filtering silence and non-speech noise before anything is sent upstream. In exam rooms, this stage also has to handle HVAC noise, door interruptions, and multiple simultaneous speakers without dropping clinically relevant speech.

Transcription
Streaming ASR tuned for clinical vocabulary
General-purpose speech recognition fails on drug names, dosage units, and anatomical terminology at a rate that makes downstream structuring unreliable. Production scribes use ASR models fine-tuned or biased toward medical vocabulary, with partial-result streaming so the transcript visibly builds in real time rather than appearing in large delayed chunks.

Diarization
Speaker separation: clinician, patient, caregiver
A note is structurally wrong if a patient-reported symptom is attributed to the clinician's assessment, or vice versa. Diarization assigns each transcript segment to a speaker role, which is what allows the downstream model to correctly separate subjective patient report from clinician assessment and plan — the backbone of a SOAP-formatted note.

Clinical NLP
Entity extraction & concept mapping
Raw transcript text is tagged for clinically meaningful entities — medications, dosages, symptoms, durations, negations — and mapped toward structured vocabularies (RxNorm, SNOMED CT) where the deployment requires coded output. Negation handling is disproportionately important here: "denies chest pain" and "chest pain" are opposite findings separated by one word.

Synthesis
LLM-based note structuring, not transcription
The final stage takes the diarized, entity-tagged transcript — not raw audio, and not raw text — and generates a structured note in the target format (SOAP, specialty-specific templates, problem-oriented format). This is where the system makes editorial decisions: what's clinically relevant to the assessment versus conversational filler, and how findings map onto the visit's documented complaint.

Review layer
Clinician confirmation before the note is final
No structured output goes into the chart unreviewed. The interface surfaces the generated note alongside the source transcript for fast clinician edit-and-sign, with confidence indicators on entity extraction so low-confidence mappings — an ambiguous drug name, an unclear dosage — are flagged rather than silently asserted.

Each stage is independently swappable, which matters operationally: a health system might need to change ASR vendors for cost reasons, or swap in a fine-tuned model for a specialty with unusual terminology density (oncology, psychiatry), without rebuilding the structuring layer. Peerbits architects these pipelines with that modularity as a first-class requirement, not an afterthought — see our broader approach to how AI medical scribes work within clinical documentation for the documentation-quality angle on this same pipeline.

The hardest part of an ambient scribe isn't the transcription. It's knowing what to leave out of the note.
— Peerbits Clinical AI Engineering

03 Where these systems actually break

Most ambient scribe failures aren't dramatic model errors — they're quiet, structural problems that surface weeks into a deployment, usually as a clinician trust issue rather than a visible bug report.

RISK 01
Negation and hedge language reversal. "No history of," "denies," "ruled out," and "patient is unsure whether" all materially change the clinical meaning of an adjacent entity. A pipeline without robust negation scoping will tag a denied symptom as present — a serious accuracy failure that's easy to miss on a quick clinician review pass.

RISK 02
Cross-talk and multi-speaker overlap. Exam rooms involve interruptions, caregivers speaking on behalf of patients, and clinicians thinking aloud. Diarization models trained on clean two-speaker call center audio degrade sharply in this setting, misattributing speech and corrupting the subjective/objective split in the resulting note.

RISK 03
Synthesis hallucination under sparse input. When the transcript for a section of the visit is thin (a quiet patient, a noisy capture segment), an LLM-based structuring step under instruction to "produce a complete note" will sometimes generate plausible-sounding clinical content that was never actually said. This is the single highest-stakes failure mode and the reason confidence-aware generation and explicit "insufficient information" fallbacks are non-negotiable design requirements, not nice-to-haves.

Why review-before-sign isn't a compliance checkbox: Given the above failure modes, the clinician review step is not regulatory theater — it's the system's actual error-correction layer. Scribe tools that position themselves as "fully autonomous" are quietly shifting failure-mode risk onto the clinician without giving them the tools (confidence flags, source transcript linkage) to catch it. Peerbits designs the review interface as core product surface, integrated with existing EHR/EMR workflows rather than as a bolt-on approval screen.

04 Building it in sequence

Health systems that succeed with ambient scribe deployments tend to build and validate in a consistent order — resisting the temptation to start with the most visible part (the generated note) before the less visible parts (capture quality, diarization accuracy) are solid.

PHASE 01
Capture validation
Prove audio quality in the real environment first
Pilot in actual exam rooms, not quiet conference rooms. Measure word error rate against the specific ambient noise profile, device placement, and multi-speaker patterns of the target specialty before any structuring work begins.

PHASE 02
Diarization tuning
Get speaker attribution right before trusting structure
Validate diarization accuracy specifically on overlapping speech and caregiver-present visits — the scenarios general-purpose models handle worst and clinical encounters produce constantly.

PHASE 03
Entity & negation QA
Stress-test clinical NLP against edge-case language
Build a test set specifically around negation, hedging, and conditional language ("if the pain returns, we'll consider imaging") before evaluating end-to-end note quality — these are the cases generic NLP benchmarks under-represent.

PHASE 04
Synthesis & review UX
Design for fast, confident clinician correction
Ship confidence-flagged generation with one-click linkage back to the source transcript segment, so a clinician can verify a flagged entity in seconds rather than re-reading the full encounter.

PHASE 05
EHR integration
Land the structured note where it's actually usable
Push structured fields into the correct EHR note sections and discrete data fields — not as a single pasted text blob — so downstream coding, CDI, and care team review can actually use the structure the pipeline produced.

What to validate before scaling beyond a pilot

  • Word error rate measured specifically on medication names, dosages, and specialty terminology — not general speech benchmarks
  • Diarization accuracy on real multi-speaker, overlapping-speech encounters, not clean lab recordings
  • A documented negation and hedge-language test suite with pass-rate tracking over model updates
  • Confidence scoring surfaced at the entity level in the review UI, not just an overall note confidence score
  • A defined escalation path for low-confidence segments — flagged for clinician attention, never silently auto-completed
  • Structured field mapping validated against your specific EHR's note architecture, not a generic FHIR assumption

This is also where infrastructure choices compound. A scribe system built on a clean, modular data architecture can swap ASR vendors or upgrade the structuring model without a full rebuild; one built as a monolithic call to a single model provider inherits that provider's failure modes permanently. Peerbits builds ambient scribe systems as a component of broader healthcare software development engagements specifically so the pipeline can evolve stage by stage as models and vendor options improve.

Top comments (0)