Use a medical dictation API when one clinician is composing a document, and ambient transcription when the facts live in a conversation with a patient. A radiologist reading a scan has nobody to record, so ambient has nothing to capture. A primary care visit is the reverse: the history comes out in conversation, and the clinician can't narrate a note over the patient.

So the choice is about workflow, not model quality. The harder part comes after you choose: the low error rates quoted for dictation were measured with a paid transcriptionist in the loop, and most products built on an API remove that person.

Key Takeaways

• Choose by workflow. If the clinician is authoring alone, dictation fits. If the information comes from a conversation, ambient fits.
  
  

• Editing does most of the accuracy work. In a 217-note study, raw drafts had 7.4 errors per 100 words and signed notes had 0.3. A transcriptionist made nearly all of that difference.
  
  

• Your review screen replaces that transcriptionist. Studies comparing the two consistently found more errors when clinicians edited their own speech recognition output.
  
  

• Check that features combine. Several vendors document dictation formatting and medical vocabulary features separately, and they don't always run together.
  
  

• Sully's API has a dictation option. If voice commands are a requirement, start with a vendor that publishes a command list.

Dictation vs Ambient Transcription: Who Is Writing the Note?

In dictation, the clinician is the author and the speech API is a typewriter. In ambient, the system listens to a conversation and has to decide what belongs in the note. Much follows from that:

• Speakers. Dictation has one, so diarization mostly disappears as a problem.
  
  

• Failure mode. A dictation error is usually a wrong word that its author may notice. An ambient error can be an omitted fact the clinician no longer remembers hearing.
  
  

• Effort. Dictation still makes the clinician compose the document. Ambient's main appeal is removing that step.
  
  

• Recording. Ambient records the patient, which raises a consent question your counsel should answer. A clinician dictating alone after the visit doesn't.

Federal rules assume this pattern in places. Medicare's hospital conditions say an operative report "must be written or dictated immediately following surgery and signed by the surgeon", and that radiologists must sign reports of their interpretations.

Conversation also looks harder to recognize. A 2018 evaluation of eight engines on unscripted clinical conversation found word error rates from 34% to 65%, far above the 7.4% in the dictation study below. Those studies used different engines and methods, so trust the direction and not the gap. Our word error rate article explains why such figures can't be stacked.

When dictation is the wrong choice

Don't use dictation to drive the EHR. In a study of 35 emergency clinicians doing standardized tasks by voice or by keyboard and mouse, speech recognition was 18% slower (165 vs 140 seconds). Errors with major potential for patient harm rose from 13 to 50. Voice was used there for general input and navigation, not long free text, and the authors say poor EHR integration may explain part of the increase. It's still a warning about short fields and orders.

Don't assume it saves time either. A systematic review reported mixed findings on documentation time across the 20 studies that measured it.

What the Error Evidence Says About Editing

The most useful dictation study is Zhou et al. in JAMA Network Open (2018): 217 notes from 144 physicians at two health systems, dictated in 2016 and measured at three stages. The last column is our own arithmetic, applying the published rates to a 300-word report.

The error count fell from 8,161 to 461 at the transcriptionist stage, a 94% drop ((8,161 - 461) / 8,161). The physician's review took it from 461 to 328, about 29%. That doesn't mean physicians catch only 29%, because little was left to find. But the signed result depended on a professional editor who is absent from most API products.

If your product sends speech directly to the clinician, the 0.3 figure doesn't describe it. A raw draft is what arrives on their screen, and your review interface decides how many of its errors survive.

Other studies look at that case. Comparing 615 breast imaging reports, Basma et al. found at least one major error in 23% of speech recognition reports and 4% of conventionally transcribed ones, and ASR reports were 8 times as likely to contain a major error after adjustment. The systematic review says studies comparing accuracy "unanimously found more errors in self-edited SR-generated reports". Zhou's authors warn that fully shifting editing to clinicians may increase documentation errors.

These numbers are old. The Zhou notes went through one Dragon back-end system in 2016, Basma's reports date from 2009 to 2010, and today's models should do better on raw recognition. But no comparable peer-reviewed study of current dictation APIs turned up in the research for this article, and better recognition doesn't change who catches what remains.

Two details from Zhou should shape your review screen:

• Missing words were the most common error. Deletions were 34.7% of raw errors and insertions 27.0%. A low word-confidence score can't flag a word that was never returned, so highlighting isn't enough. Give reviewers click-to-listen audio tied to word timestamps.
  
  

• A signature doesn't prove review. Transcriptionists marked unintelligible audio with a visible blank, ??__??, for the physician to fill in. 16 of the 217 signed notes (7.4%) still contained one, and in three the missing word was clinically significant. Block signing while any placeholder or unresolved flag remains.

What a Clinical Dictation API Needs That a General Speech API Doesn't

Spoken punctuation and formatting

Clinicians used to dictation often speak their punctuation. A dictation API should turn the spoken command into the symbol instead of transcribing the word "comma".

The catch is that some commands are also medical words. "Colon" is an organ. "Period" is part of a menstrual history. Deepgram, Google and Corti all list both as punctuation commands. Corti says its language model decides from context whether "colon" means the word or the symbol. Google says spoken punctuation can't be disabled on its medical dictation model, and neither its page nor Deepgram's explains how the two uses are told apart. Nothing here was tested, so put those sentences in your test set.

Section navigation

There are two approaches. Google recognizes a fixed list of headings, such as [CURRENT MEDICATIONS], and returns them as tags in the text. Corti lets you define commands such as go to {section_key} section and returns a command object. In both cases, the API detects the command and your application has to act on it.

Correction

Clinicians revise while speaking, so a dictation product has to handle commands such as "scratch that", self-corrections and later edits. There's a real tradeoff in how far to take this. AssemblyAI's Dictation API returns the verbatim transcript and a rewritten version in one response, and its clinical dictation guide is candid about the limit: "Cleanup polishes; it does not correct." A rewritten wrong drug name reads as confidently as a right one. Whichever vendor you pick, store the verbatim text and an audio link next to any cleaned version.

Medical vocabulary that works with dictation mode

A vendor's medical feature and its dictation feature may not run together:

• AssemblyAI says Medical Mode "is not available on the Sync API or the Dictation API". You use prompts and a keyterm list instead.
  
  

• Amazon requires you to state whether audio is DICTATION or CONVERSATION, but radiology is streaming only, so recorded radiology dictation can't use that specialty. Batch jobs must use primary care.
  
  

• On Sully, word_boost is a streaming option, and streaming dictation may vary by account.

Ask each vendor one question: can dictation mode and medical vocabulary run on the same request, in the mode I need?

A way into the EHR

Speech APIs stop at text. Three routes go further:

1. Insert at the cursor. It needs no EHR integration and works anywhere, but the text has no structure and depends on the right field having focus. Microsoft warns that spell checkers can make results land in an unexpected location, and the emergency study above also reported integration errors, including commands landing in the wrong place.
   
   

2. HL7 v2 MDM. This is the older route, built for this job. The T02 event's first scenario is dictation that is transcribed and "requires authentication". Later events cover status changes and addenda.
   
   

3. FHIR. US Core's page on writing notes is informative only, carries no conformance requirement, and leaves draft workflows out of scope. Its direct-write mode files immediately, so review has to finish before you POST. FHIR does define a preliminary document status, but ask each EHR whether it accepts writes at all and how it treats that status.

Whichever route you use, entries must be authenticated by the responsible person in hospital records. So "text arrived" and "report is final" should be separate states in your product.

How Dictation APIs Document These Features

Sully wrote this comparison. It reflects each vendor's documentation as of November 2026, not a test. "Not described" means the page read doesn't cover the feature, not that it can't exist. BAA terms are a separate check, covered in our HIPAA article.

The short version:

• You need voice-driven sections and custom commands: start with Corti, whose docs are the clearest on this.
  
  

• You want a fixed medical command set in US English: look at Google.
  
  

• You want an established dictation SDK rather than an API: look at Microsoft's Dragon Medical SpeechKit. Even Sully's own comparison credits Dragon with "a deep voice-command library".

Whichever you shortlist, have a clinician read these fictional lines aloud.

Colonoscopy showed a small polyp in the sigmoid colon period
Last menstrual period was March third comma cycles are regular period
Start metformin five hundred scratch that one thousand milligrams twice daily period
No evidence of pneumothorax period new paragraph
Patient states quote I feel fine unquote period
Next section physical exam

Colonoscopy showed a small polyp in the sigmoid colon period
Last menstrual period was March third comma cycles are regular period
Start metformin five hundred scratch that one thousand milligrams twice daily period
No evidence of pneumothorax period new paragraph
Patient states quote I feel fine unquote period
Next section physical exam

Colonoscopy showed a small polyp in the sigmoid colon period
Last menstrual period was March third comma cycles are regular period
Start metformin five hundred scratch that one thousand milligrams twice daily period
No evidence of pneumothorax period new paragraph
Patient states quote I feel fine unquote period
Next section physical exam

Check that the organ and the menstrual history survive, that "scratch that" removes only what it should, that "no" stays in place, and that quotes and sections come back in a form your code can use.

Medical Dictation With Sully's API

Sully's transcription API takes a dictation field on upload. This example comes from the current docs and uses the docs' fictional file name:

curl "$SULLY_API_BASE_URL/v2/audio/transcriptions" \
  --request POST \
  --header "X-Account-Id: $SULLY_ACCOUNT_ID" \
  --header "X-Api-Key: $SULLY_API_KEY" \
  --form "audio=@./fictional-visit.mp3" \
  --form "language=en" \
  --form "multichannel=false" \
  --form "dictation=true"

curl "$SULLY_API_BASE_URL/v2/audio/transcriptions" \
  --request POST \
  --header "X-Account-Id: $SULLY_ACCOUNT_ID" \
  --header "X-Api-Key: $SULLY_API_KEY" \
  --form "audio=@./fictional-visit.mp3" \
  --form "language=en" \
  --form "multichannel=false" \
  --form "dictation=true"

curl "$SULLY_API_BASE_URL/v2/audio/transcriptions" \
  --request POST \
  --header "X-Account-Id: $SULLY_ACCOUNT_ID" \
  --header "X-Api-Key: $SULLY_API_KEY" \
  --form "audio=@./fictional-visit.mp3" \
  --form "language=en" \
  --form "multichannel=false" \
  --form "dictation=true"

It returns 201 with an ID and a status of pending, and you poll until the status is completed or failed. Results include transcript and confidence, plus optional words with timings, which is what click-to-listen review needs. The recorded audio article covers that lifecycle.

The docs say the field "enables dictation-oriented formatting", so test it on the lines above. Upload is also asynchronous, which suits recorded dictation better than text appearing as the clinician speaks. For live text you need streaming, where dictation is listed with "availability may vary by account", so ask before you design around it. The real-time article covers streaming in general.

If you do get streaming, one detail matters for hold-to-talk. The server drops audio received before its connected message, and idle time after connected is billable. Opening a socket on each key press clips the first words unless you buffer the microphone until connected arrives. Keeping one open means paying for idle time, and a session lasts two hours at most. Buffering from the key press is the safer default, because a lost first word is hard to spot in review.

For compliance, the trust page says Sully executes BAAs with covered entities, and it also signs them with software companies building on the API.

Sully fits if you want dictation and other clinical steps from one vendor. Text to JSON can map dictated text into fields you define, with extraction restricted to what's explicitly in the source. If you need a documented command set today, another vendor in the table is the better choice.

If you don't need to build at all, Sully Dictation is a Mac and Windows app that inserts text at the cursor, and the medical dictation page gives a wider overview. The app's page describes dropping filler words and following spoken corrections. That describes the app, so test the API's dictation option separately.

To try the API, get a key from the API page and start with the transcription docs.

FAQ

What is a medical dictation API?

It's a speech API built for one clinician deliberately speaking a document. Beyond transcribing, it should handle spoken punctuation, formatting, corrections and medical vocabulary. Vendors differ widely on how much of that they do.

What's the difference between medical dictation and ambient transcription?

Dictation captures one clinician authoring text. Ambient captures a conversation that has to be turned into a note. Dictation suits radiology, pathology, operative reports and addenda. Ambient suits visits where the history comes from talking with the patient.

How accurate is medical dictation?

There's no single figure. A systematic review found word error rates from 7.4% to 38.7% across studies. In the Zhou study, raw output had 7.4 errors per 100 words and signed notes had 0.3 after human editing. Test current APIs on your own audio.

Does a dictation API replace a medical transcriptionist?

It can replace the typing, but not automatically the checking. Studies consistently found more errors when clinicians edited their own output, so a product without a transcriptionist needs a strong review step.

Can a clinical dictation API write directly into Epic or another EHR?

Not by itself. Speech APIs return text, and you get it into the record by cursor insertion, an HL7 interface or a FHIR write, depending on what that EHR and customer allow. Confirm write access early.

Sources

1. Zhou L, et al. Analysis of Errors in Dictated Clinical Documents Assisted by Speech Recognition Software and Professional Transcriptionists. JAMA Network Open, 2018.

2. Basma S, et al. Error rates in breast imaging reports: comparison of automatic speech recognition and dictation transcription. AJR, 2011.

3. Blackley SV, et al. Speech recognition for clinical documentation from 1990 to 2018: a systematic review. JAMIA, 2019.

4. Hodgson T, Magrabi F, Coiera E. Efficiency and safety of speech recognition for documentation in the electronic health record. JAMIA, 2017.

5. Kodish-Wachs J, et al. A systematic comparison of contemporary automatic speech recognition engines for conversational clinical speech. AMIA Annual Symposium Proceedings, 2018.

6. eCFR. 42 CFR 482.24, 482.26, 482.51.

7. Google Cloud. Recognize speech by using medical models.

8. Deepgram. Dictation.

9. AssemblyAI. How to build clinical dictation on AssemblyAI.

10. Corti. Transcribe endpoint, Commands, Punctuation.

11. Amazon Web Services. Transcribing a medical dictation, StartMedicalTranscriptionJob.

12. Microsoft. Set up Dragon Medical SpeechKit (Browser).

13. HL7. Version 2.5, chapter 9, Medical Records/Information Management (hl7.eu copy).

14. HL7. US Core Writing Clinical Notes, FHIR R4 CompositionStatus.

15. Sully. Transcription, Streaming transcription, Text to JSON, API page, Trust page, Dictation, Medical dictation.