Speaker diarization answers “who spoke when?” It usually produces anonymous, consistent labels such as Speaker 1 and Speaker 2. It is separate from speech recognition, which answers “what was said,” and from speaker identification, which tries to establish a person's identity.
What is speaker diarization?
A diarization system divides an audio recording or stream into speaker-attributed segments. The useful output is not only a transcript. It is a sequence of turns:
The product can later map “Speaker 1” to “clinician” and “Speaker 2” to “patient” when it has reliable workflow context. The diarization label itself does not prove identity.
Why speaker attribution matters in healthcare
A medical transcript can contain the right words and still produce the wrong downstream record if the speaker is wrong. “I stopped taking metformin” has a different meaning when spoken by a patient, a caregiver quoting the patient or a clinician confirming a history.
Speaker turns help products build role-aware notes, preserve questions and answers, distinguish instructions from reported symptoms, and let reviewers return to the relevant moment in the audio. They also create a visible failure surface: a clean paragraph can hide that two people were merged.
Why clinical conversations are difficult
Short acknowledgements
“Yes,” “right,” “okay” and backchannels are brief and acoustically weak. They can be assigned to the wrong person or absorbed into a longer turn.
Overlapping speech
Clinicians and patients interrupt, complete sentences and speak at the same time. A single-speaker timeline cannot always represent two simultaneous voices cleanly.
More than two people
A caregiver, interpreter, nurse, student or family member can enter the room. A system tuned around two fixed speakers may merge or fragment the additional voice.
Changing acoustic position
A laptop on a desk, a phone in a pocket or a room microphone captures each person differently. Movement, masks, doors and background equipment can shift the apparent speaker signal during one encounter.
Similar voices and role changes
People with similar vocal characteristics can be confused. A speaker label also has no inherent clinical role; the application must not assume that the first voice is always the clinician.
Live and batch diarization are different product contracts
Batch processing can use the complete recording before deciding speaker boundaries. Live processing has to produce useful output while the conversation is still happening. Labels or boundaries may therefore be provisional until more context arrives.
When evaluating a live API, ask what remains stable across draft text, confirmed text and the final transcript. Test whether a label can change, whether the product sends corrections, and how your interface or downstream agent applies those corrections. A live transcript that looks fast but cannot reconcile revised speaker turns can create silent state errors.
For batch jobs, inspect how the system handles long silences, people leaving and returning, and the same speaker being split into several labels.
How diarization is measured
Diarization error rate, or DER, is a common summary. It combines missed speech, false speech and speaker confusion relative to reference speaker time. But one DER can hide the failure your product cares about.
- Missed speech: reference speech was not assigned.
- False alarm: non-speech was treated as speech.
- Speaker confusion: speech was assigned to the wrong reference speaker.
For a healthcare product, add task-level measures: how often clinician/patient turns are swapped, whether medication statements are attributed correctly, and whether a note or agent changes behavior because of a speaker error.
Omi includes speaker labels in the hosted API, but the current public medical benchmark measures words, medical terms, drug names and dosages—not speaker attribution. Do not infer diarization accuracy from Omi's WER or M-WER result.
A practical clinical diarization test plan
- Define the roles and output. Decide whether anonymous consistency is enough or the product needs clinician/patient role mapping.
- Collect representative rooms. Include the microphones, distances, specialties and speaker counts the product will actually encounter.
- Include difficult turns deliberately. Mark overlaps, short acknowledgements, interruptions, quiet voices and people entering or leaving.
- Create a time-aligned reference. A reviewer should label who spoke and when, including the policy for overlap.
- Score batch and live separately. Do not transfer a batch result to a live product contract.
- Measure label stability. For live systems, record revisions and whether downstream state is corrected.
- Inspect role-critical statements. Review symptoms, denials, drug names, dosages and instructions by speaker.
- Test failure handling. Decide what the product does when speaker capacity is unavailable or confidence is inadequate. Silent removal of labels is not acceptable.
Questions to ask a medical speech provider
- Are speaker labels available in both batch and live transcription?
- How many simultaneous speakers and sessions does the product support for my plan?
- Are live labels provisional, and how are corrections delivered?
- Does the service ever silently fall back to a transcript without speaker labels?
- Are labels consistent across long pauses and reconnections?
- Can my application map anonymous labels to clinical roles without treating that mapping as identity verification?
- Are speaker labels included in the published rate or sold as an add-on?
- What benchmark covers speaker attribution, and can I test my own audio?
Where Omi fits
Omi's hosted medical speech API includes speaker labels, timestamps and medical vocabulary on Builder, pay as you go and Enterprise. Omi does not charge a separate transcription add-on for speaker labels. Builder includes 25 pooled audio-hours every month.
That packaging does not replace evaluation. Test the speaker patterns, room and live behavior your product depends on. Use the playground for an initial audio check, review medical transcription metrics separately, and inspect the hosted plans and open-source path.