A family physician in a border-state clinic runs a 20-minute visit with a Spanish-speaking patient. The history of present illness happens in Spanish. The patient’s adult daughter jumps in twice, in English, to clarify a medication name. The plan gets repeated back in Spanish, so the patient can explain it to her husband later. That is not an unusual visit.
According to the U.S. Census Bureau, 67.8 million people in the United States age five and older speak a language other than English at home. For a primary care panel, that number is not an abstraction. It is a meaningful share of the day.
Most AI scribe marketing still talks about “multilingual support” as if it were one feature. It is not. A multilingual AI medical scribe has to solve at least three separate problems, and a tool that solves one does not automatically solve the others.
Single-language accuracy is the easy part
The first problem is straightforward, at least in concept: can the AI scribe transcribe and structure a note when the entire visit happens in one non-English language? Most ambient AI tools handle this reasonably well today. Sunoh.ai, for example, documents English, Portuguese, and Spanish support with more languages reportedly in development, and notes that it handles dialect and accent variation within those languages. Freed claims support for 90+ languages for AI clinical documentation; multilingual healthcare AI tools at this scale are increasingly common in the category.
The catch is dialect. A scribe that lists “Spanish” as supported does not automatically handle Caribbean Spanish, Mexican Spanish, and Castilian Spanish equally well, and the same is true for Levantine Arabic versus Gulf Arabic, or Cantonese versus Mandarin. AI4Docs frames this directly as the gap between a tool that recognizes “textbook” language and one tested against the dialects clinicians and patients actually speak. A physician evaluating an AI scribe language support claim should ask for the specific dialect coverage, not just the language name on a list.
Code-switching is where most tools actually break
The second problem is the one vendors mention least, and patients trigger most: code-switching, where the conversation moves between languages inside the same visit. This is not an edge case in a diverse panel. It is closer to the norm. A patient answers in Spanish, a family member adds detail in English, the clinician explains the plan in a mix of both. Glass Health’s buyer guide makes a useful distinction here: support for a language and support for a mixed-language mode are different capabilities entirely. Single-language support assumes one dominant language for the whole encounter. Mixed-language support assumes the note-generation workflow can tolerate switching without turning the visit into a manual cleanup job afterward.
This is also the scenario AI4Docs calls “code-switching chaos” in its own guide to multilingual scribing, noting that most transcription tools trained primarily on English produce garbled output the moment a conversation shifts language mid-sentence. The practical test for any physician piloting a multilingual AI medical scribe is not “does it understand Spanish.” It is “what happens to the note when my patient answers half the questions in English and half in Spanish, in the same sentence.”
The risk nobody is pricing in: coding, not just notes
Here is the part most multilingual AI scribe content skips entirely. A clean transcript and a readable note are not the finish line for a billable visit. The note has to support accurate ICD-10 diagnosis codes and CPT procedure codes, and that is where language complexity creates a quieter, more expensive failure mode.
Consider the chest pain example. A patient who describes “un dolor que aprieta” is describing a pressure-type pain, which carries different diagnostic weight than sharp or burning pain when a physician is weighing cardiac versus musculoskeletal causes. If an AI transcription multiple languages tool flattens that description into a generic English summary, the resulting note can technically be accurate while still losing the clinical nuance that should drive the diagnosis code. Multiply that across a panel where a meaningful share of visits happen in a second language, and the result is not a documentation inconvenience. It is undercoding, denied claims, or a missed differential.
This is the connection that matters, and that most AI clinical documentation multilingual content does not make: language accuracy and billing accuracy are the same problem wearing different clothes. A scribe who gets the transcript right but stops at the note is solving half the workflow. Notiro’s position in the broader AI medical scribe category is built around exactly that gap. Most AI scribes write the note and stop. Notiro’s differentiator is carrying the visit through to ICD-10 and CPT code suggestions and a one-click EHR sync, because undercoding is one of the most consistent and avoidable sources of lost revenue in small and mid-size practices, language barrier or not.
Patient-facing materials are a fourth, separate job
There is a fourth problem worth naming, even though it sits slightly outside documentation proper: what the patient takes home. A clinical note can be flawless, and the patient can still leave with discharge instructions or an after-visit summary they cannot read. Glass Health’s guide describes a documented language priority policy for exactly this scenario: clinician override first, then the patient’s spoken language pulled from the transcript, then a default to English. That kind of explicit fallback logic, rather than an assumed translation, is what separates a workflow a busy clinic can trust from one that needs manual double-checking every time.
What to actually test before trusting a multilingual AI scribe’s claim
A physician evaluating any AI scribe for a multilingual panel should run three specific tests before the language list on a website matters.
First, a fully non-English visit, in the dialect the practice actually serves, not a generic version of the language. Second, a code-switched visit where the patient and a family member alternate languages mid-conversation, since that is the scenario most tools have not actually been tested against, despite broad language claims. Third, a check on what happens downstream: does the resulting note still support the correct diagnosis and procedure codes, or does language complexity quietly erode coding accuracy along with note quality?
Patients with limited English proficiency already face documented disparities in care, and an AI scribe that gets the language right but the coding wrong is not closing that gap. It is moving it further from the exam room and into the billing department, where it is harder to catch and more expensive to fix.
The bottom line
Multilingual support is not a feature toggle. It is at least three workflows: accurate single-language capture, durable code-switching, and coding that holds up regardless of which language the visit happened in. A practice serving a multilingual panel should ask every AI scribe vendor, Notiro included, to demonstrate all three, not just the first one.
Have a multilingual patient population and want to see how Notiro’s coding automation holds up across visit types? Book a demo to test it against your own clinic’s languages and dialects.
