Most comparisons of Amazon Transcribe Medical argue about accuracy. In practice, accuracy is rarely the thing that stops a team.

What stops them is a line in the documentation. The service handles one language. It supports six specialties, and only one of them can be processed from an uploaded file. And the AWS service that actually writes a clinical note runs in a single region.

None of that is hidden. It is spread across several documentation pages, which is why teams usually find it after the integration work has started.

Key Takeaway: Amazon Transcribe Medical is an automatic speech recognition service for medical speech, available in batch and real-time streaming, and it supports US English only. It returns a transcript, not a clinical note. To get a note on AWS you either add Amazon Comprehend Medical and your own generation layer on top, or switch to AWS HealthScribe, which does produce preliminary clinical notes but runs in a single AWS region, US East in Northern Virginia. Both services restrict you to a fixed list of supported medical specialties, and on Transcribe Medical only primary care supports batch audio at all. For teams whose audio is multilingual, whose specialties fall outside that list, or who need the finished note rather than the transcript, those three constraints decide the build before accuracy ever enters the conversation. Clinical APIs built for this workload, Sully among them, transcribe 30+ languages and return the finished note in your own template rather than a transcript you still have to process.

What Amazon Transcribe Medical Actually Does

Amazon Transcribe Medical is an automatic speech recognition service built for medical speech. AWS designed it for physician-dictated notes, drug safety monitoring, telemedicine appointments, and physician-patient conversations [1].

AWS markets three use cases for it: conversational voice scribes, medical dictation applications, and drug safety monitoring [2].

It is ASR and nothing more. That single fact shapes every decision that follows. How a transcript becomes a usable clinical note is a separate problem, and a bigger one.

Batch and Streaming Medical Transcription

You get two modes. Real-time streaming from a microphone, and batch transcription of an uploaded file [1].

Batch runs through StartMedicalTranscriptionJob [3]. The dictation workflow has its own path in the documentation if you are building a front-end dictation product rather than an ambient one [4].

The audio requirements matter more than they look. AWS asks for lossless audio such as FLAC or WAV, with PCM 16-bit encoding and a sample rate of 16,000 Hz or higher [1].

That constraint reaches all the way back into your capture layer. If your mobile app compresses audio to save bandwidth, you are rebuilding that part before you write a line of transcription code.

The Specialties AWS Supports and the Ones It Does Not

Here is the supported list [1]:

Read the right-hand column twice. Primary care is the only specialty you can process from an uploaded file.Cardiology, neurology, oncology, radiology and urology are all streaming only.

That is the single most consequential line in the documentation, and it is easy to miss. If you are building asynchronous processing, where a visit uploads and a note comes back a few minutes later, Amazon Transcribe Medical supports exactly one specialty: primary care. Everything else has to be captured live, as it happens.

Most teams find that out during the sprint rather than during the evaluation.

Then there is everything missing. Dermatology, psychiatry, orthopedics, endocrinology and most of the rest of the specialty map are not on this list at all.

To be fair to AWS, they are on HealthScribe's list, which runs to 22 specialties [5]. That is the trade this article keeps coming back to, and it is covered below.

Why It Returns a Transcript and Not a Note

Transcribe Medical gives you words. A clinical note needs structure, sections, and judgment about what belongs in each one.

AWS does not pretend otherwise. The developer guide points you to other services for analysis of your transcripts, naming Amazon Comprehend Medical [1][6].

So the real question is not whether Transcribe Medical is accurate. It is how many services you are signing up for.

The Three Services AWS Splits Clinical Speech Across

AWS does not sell one clinical speech product. It sells three, and the assembly is yours.

You can wire Amazon Transcribe Medical to Amazon Comprehend Medical and build the note generation layer yourself. You can adopt AWS HealthScribe and let it do more of the work inside tighter boundaries. Or you can go to a vendor that returns the finished note from one call.

AWS makes the point better than any competitor could. The HealthScribe documentation describes the service as combining its capabilities to "remove the need to integrate and optimize separate AI services" [5].

That sentence is a selling line for HealthScribe. It is also an honest description of what the rest of the AWS stack costs you.

Amazon Transcribe Medical for Raw Transcription

The transcription layer. Audio goes in, text comes out, in batch or streaming [1]. It hands off at the transcript.

Amazon Comprehend Medical for Extracting Terms

The analysis layer AWS directs you to from the Transcribe Medical guide [1]. It pulls medical terms out of text [6].

It is a separate service, with separate pricing and a separate integration.

AWS HealthScribe for Generated Clinical Notes

The bundled path, and the one most teams end up weighing seriously.

HealthScribe is a HIPAA-eligible capability that combines speech recognition and generative AI to transcribe patient-clinician conversations and generate clinical notes that are easy to review. It identifies speaker roles, classifies dialogue, extracts medical terms, and produces preliminary clinical notes [5].

It has its own API operations. StartMedicalScribeJob for batch, StartMedicalScribeStream for streaming [5].

This is a capable service, and for a US-only product in a supported specialty it may be the right answer. Worth knowing what it still leaves you: HealthScribe returns a preliminary note, so the layer that turns that note into structured fields your EHR accepts is yours to build either way. The constraint that decides it for everyone else is in the next section.

Where Clinical Teams Hit the Limits

None of these are secrets. Every one is published by AWS. They are just published in places you read after you have already chosen.

English Only in Both Services

Amazon Transcribe Medical is available in US English, en-US[1]. AWS HealthScribe supports US English only as well [5].

That is the whole language list.

If your product records visits in Spanish, or operates anywhere outside an English-speaking market, neither service has a supported path. Speechmatics built a dedicated FAQ entry around whether these two services work outside the US [7], which tells you how often the question comes up in real evaluations.

HealthScribe Runs in One AWS Region

AWS HealthScribe is available in the US East, Northern Virginia region [5].

One region. Not one country, one region.

For a team with data residency obligations in the EU, the UK, Canada or the Middle East, that ends the evaluation before it starts. It also means the service writing your clinical notes carries a single-region dependency, which is a conversation your own reliability review will want to have.

Transcribe Medical itself runs in 22 AWS regions, including Ireland, London, Frankfurt, Canada and Bahrain [8]. The single-region restriction belongs to HealthScribe alone, which is why the note layer, not the transcription layer, is usually what breaks a residency requirement.

The Specialty Allowlist Decides What You Can Build

Your product roadmap is bounded by someone else's list, and adding a specialty is not a setting you can change.

The two AWS services do not share a list, and the gap between them is large. Transcribe Medical supports six specialties [1]. HealthScribe supports 22, including dermatology, psychiatry, orthopedics, ophthalmology, nephrology, rheumatology and surgery [5].

That is the real shape of the AWS offer, and it is worth stating plainly: you get specialty breadth or you get regional reach, not both. Transcribe Medical runs in 22 AWS regions but covers six specialties. HealthScribe covers 22 specialties but runs in one region.

So the choice is not which service is better. It is which constraint your product can absorb.

Audio Format Requirements Shape Your Capture Pipeline

Lossless audio such as FLAC or WAV, PCM 16-bit encoding, 16,000 Hz or higher. Both services ask for the same thing [1][5].

Lossless audio is large. Every recorded minute costs more to send and more to store, and that bill arrives before any transcription charge does. Worth modeling at your actual visit volume rather than at a sample size.

Pricing Is Tiered by Region and Volume

AWS prices Transcribe on a pay as you go basis, billed per second of audio with no minimum. Rates are tiered, so the per-minute price drops as your monthly volume rises, and the tiers vary by region. There is a free tier of 60 audio minutes a month for the first 12 months [8].

Here is the practical problem. You cannot read one number off the pricing page and model your unit economics. You have to fix a region and a volume tier first, then do it again for the note layer, which is priced separately from transcription.

What to Check Before You Commit to the AWS Stack

Five checks, each one answerable in a day.

1. Map Your Specialties Against the Supported List

Take the specialties you serve now and the ones on your next four quarters of roadmap. Check them against both published lists [1][5].

Pay particular attention to the batch restriction. If your architecture uploads recordings and processes them afterwards, the supported list is not six specialties, it is one. A batch-first design plus any roadmap beyond primary care is a contradiction that surfaces late and expensively.

2. Confirm Your Regions and Data Residency Requirements

Check your signed customer contracts, not your team's assumption about them.

If any contract names a data residency region other than US East, HealthScribe is out before you begin [5].

3. Count the Services You Will Have to Integrate

Write down what the finished feature needs. Transcription. Clinical term extraction. Note generation. Structured output your EHR can accept.

Then mark which of those AWS gives you and which you build [1][6][5]. Each one is a separate integration, a separate failure mode, and a separate line on the bill.

4. Test Drug Names and Medication Dosages on Your Own Audio

This is the most useful hour in the entire evaluation, and almost nobody spends it.

Take 20 real recordings from your own product. Not a vendor sample, not a clean studio file. Count the errors specifically on drug names, dosages and clinical abbreviations, rather than looking at an overall word error rate.

A transcript can score well on overall accuracy and still be unusable if it gets the medication wrong. Headline accuracy numbers hide exactly the errors that matter most in clinical audio.

5. Decide Whether You Need the Transcript or the Note

This is the architectural fork, and it is worth making explicitly.

If your product needs words, Transcribe Medical may be enough. If it needs a finished, structured note in your own template, you are buying a note generation product, and you should evaluate it as one [5].

How Sully Handles the Same Workload

AWS does several things well here. Transcribe Medical runs at scale, it is available across many regions, and your finance team already has billing set up for it. Those are real advantages and they are the reason the service gets picked.

Sully builds and runs its own clinical models, and sells access to them as APIs [9]. Set against the constraints above:

Languages. Transcription across 30+ languages, against US English only.

Specialties. 40+ specialties running on the APIs in production, with no published allowlist to check your roadmap against.

Note generation. Send a transcript and your own note template, and Sully returns the finished note. Your format, not a fixed preliminary one.

Structured output. Text to JSON takes a note or transcript plus your own JSON Schema and returns validated fields, ready for the EHR. That is the layer teams otherwise build themselves on top of Comprehend Medical.

Audio length. Recorded visits up to 24 hours, with polling or a webhook when the transcript is ready.

One note on the wider market, because it would be dishonest to skip it. Medical-specific speech models are no longer unusual. AssemblyAI ships a medical mode [10] and Deepgram ships a medical model of its own [11]. The question to ask any vendor, including this one, is not whether they have a clinical model. It is which languages, which specialties, and what comes back from the call.

Tebra's AI Scribe is built on Sully, white-labeled inside its EHR. Separately, across all customers, the APIs handle more than 100,000 notes a month at 99.96% uptime [9].

One API Instead of Three Services

Transcription, note generation and structured output are endpoints on the same API rather than three services to wire together.

The note call takes a transcript, your template and the clinical context, and returns the finished note:

client.post("/v3/notes", {
  body: { transcript, template, clinicalContext },
});

client.post("/v3/notes", {
  body: { transcript, template, clinicalContext },
});

client.post("/v3/notes", {
  body: { transcript, template, clinicalContext },
});

One integration, one bill, one place to look when something breaks [9].

Word Boosting for Drug Names and Clinical Vocabulary

The drug-name test in the checklist above is the one that separates transcription vendors. Sully's streaming transcription lets you boost the words that matter, such as drug names, so the terms most likely to break a clinical transcript are the ones you can weight ahead of time [9].

You can run that test yourself today. Get an API key at dashboard.api.sully.ai, point it at 20 of your own recordings, and count the drug names. No demo required.

FAQ

Is Amazon Transcribe free?

Amazon Transcribe and Transcribe Medical both include a free tier of 60 audio minutes a month for the first 12 months, starting from your first transcription request. After that, or above that volume, you pay standard pay as you go rates billed per second of audio, with tiered pricing that varies by region and monthly volume [8].

What languages does Amazon Transcribe Medical support?

US English only. The AWS developer guide states that Amazon Transcribe Medical is available in US English, en-US[1]. AWS HealthScribe carries the same restriction [5]. If your product records visits in Spanish, Arabic or any other language, neither service has a supported path. Sully's transcription API covers 30+ languages [9].

Does Amazon Transcribe Medical work outside the United States?

Yes, with a catch. Transcribe Medical runs in 22 AWS regions, including Ireland, London, Frankfurt, Canada, Bahrain and São Paulo [8], so data residency is usually workable for transcription. It transcribes US English only [1], which is the real limit outside English-speaking markets. AWS HealthScribe is the one with the residency problem: it is available only in the US East, Northern Virginia region [5], so teams with EU, UK, Canadian or Middle East obligations can use AWS for the transcript but not for the generated note.

What is the difference between Amazon Transcribe Medical and AWS HealthScribe?

Transcribe Medical returns a transcript. HealthScribe returns a preliminary clinical note, and also identifies speaker roles, classifies dialogue and extracts medical terms [5]. The trade is scope for reach. HealthScribe does more of the work, in one region, against its own specialty list. Teams that want the transcript alone generally use Transcribe Medical. Teams that want the finished note evaluate HealthScribe, a note generation API such as Sully's [9], or build the layer themselves on top of Amazon Comprehend Medical [6].

Which medical specialties does Amazon Transcribe Medical support?

Six: cardiology, neurology, oncology, primary care (covering family medicine, internal medicine, obstetrics and gynecology, and pediatrics), radiology and urology [1]. Only primary care supports batch audio. The other five are streaming only, so an uploaded recording cannot be processed in those specialties at all. Specialties outside that list, including dermatology, psychiatry and orthopedics, are not supported by Transcribe Medical, though AWS HealthScribe does cover them across its own list of 22 [5]. Sully's APIs run across 40+ specialties with no published allowlist [9].

Sources

[1] Amazon Web Services — Amazon Transcribe Medical, Developer Guide [2] Amazon Web Services — Amazon Transcribe Medical [3] Amazon Web Services — StartMedicalTranscriptionJob API Reference [4] Amazon Web Services — Transcribing a medical dictation [5] Amazon Web Services — AWS HealthScribe, Developer Guide[6] Amazon Web Services — Amazon Comprehend Medical [7] Speechmatics— Speechmatics vs Amazon Transcribe [8] Amazon Web Services — Amazon Transcribe Pricing [9] Sully.ai — Sully API [10] AssemblyAI — Best medical speech-to-text in 2026 [11] Deepgram — Models and languages overview