This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Roughly one in twelve people in the United States speaks English less than "very well," and language-discordant care produces measurably worse outcomes: more errors, longer stays, worse comprehension of discharge instructions. If you are building a telemedicine product, language access is not a nice-to-have feature for a future release — it is a federal civil-rights obligation the moment you serve patients, and getting it wrong is both a safety risk and a compliance risk. This article is for the founder, product manager, or engineer who has to decide what the "translate" button in their app actually does, which vendor sits behind it, and where a human interpreter is not optional. It draws the line between where AI genuinely helps and where the law, and patient safety, require a person.

Two different jobs that get blurred together

People say "translation" for everything, but the law and the product both depend on three different jobs. Getting them straight is the first step.

Interpretation is the spoken job: a person listens to one language and speaks it in another, live, while the visit happens. This is what a cross-language video consult needs in real time.

Translation is the written job: turning a document — discharge instructions, a consent form, a medication list, an after-visit summary — from one written language into another. It happens before or after the live visit, not during it.

Sign-language interpretation for a deaf or hard-of-hearing patient looks similar but sits under a different legal frame. A patient who is deaf has a disability; a patient who speaks Haitian Creole has limited English proficiency. Both have a right to communication, but the governing rules differ, and an American Sign Language interpreter is not interchangeable with a spoken-language interpreter. We cover the deaf-access path in our companion piece on real-time transcription and captioning; this article is about spoken and written language for patients with limited English proficiency.

One term you will see throughout: limited English proficiency, abbreviated LEP. It means a patient who does not speak, read, write, or understand English well enough to communicate effectively about their care in English. LEP is the trigger. When a patient is LEP, the obligations below switch on.

The law sets the floor, and the floor is high

The controlling rule for US telemedicine is Section 1557 of the Affordable Care Act, the healthcare anti-discrimination law, and its 2024 implementing regulation at 45 CFR Part 92 (published at 89 FR 37692 on May 6, 2024).¹ It applies to almost every health program that receives federal money — which, through Medicare and Medicaid, is most of US healthcare. The rule is detailed about language, and a product team needs to know five of its requirements by heart.

A qualified interpreter, not just any bilingual person. When interpretation is required, the entity must offer a qualified interpreter (45 CFR §92.201(c)(1)).¹ "Qualified" is a defined term, not a compliment: the interpreter must interpret effectively, accurately, and impartially, follow interpreter ethics including confidentiality, and be proficient in both languages including the specialized medical vocabulary the visit needs. A nurse who took two years of high-school Spanish is not, by this definition, a qualified medical interpreter.

Free, accurate, and timely. Language assistance must be provided free of charge to the patient, be accurate and timely, and protect the patient's privacy and independent decision-making (§92.201(b)).¹ "Free" is literal — you cannot bill the patient or ask them to bring their own interpreter. "Timely" means available when the visit happens, which for an unscheduled urgent consult means within minutes.

No family members. No children. Ever, except a true emergency. This is the rule teams most often break by accident. A covered entity must not rely on an accompanying adult to interpret unless the patient specifically asks for it, in private, with a qualified interpreter still present and the request documented — and must not rely on a minor child at all, except as a stopgap in an emergency with an imminent threat to safety while a qualified interpreter is being found (§92.201(e)).¹ "Let the patient's daughter translate" is not a feature; it is a violation waiting for a complaint.

Video and audio remote interpreting have a quality standard. Because telemedicine leans on remote interpreters, the rule sets explicit technical requirements. Video remote interpreting must deliver "real-time, full-motion video and audio over a dedicated high-speed, wide-bandwidth" connection with no lags, choppy, blurry, or grainy images, a picture large enough to show the interpreter's and the patient's faces, clear audio, and trained users (§92.201(f)).¹ For a telemedicine engineer this is the rare case where call quality is not just user experience — it is a written compliance requirement.

Machine translation has a hard limit. The rule permits machine translation but draws a bright line: if the underlying text is critical to the patient's rights, benefits, or meaningful access, when accuracy is essential, or when the source contains complex, non-literal, or technical language, the machine translation must be reviewed by a qualified human translator (§92.201(c)(3)).¹ Read that list against a medical document. Discharge instructions are critical to access. Dosing is a case where accuracy is essential. Clinical language is, by definition, technical. For most of what a telemedicine product would want to translate, machine translation alone does not clear the bar.

A note on the rule's status, because it matters in 2026: parts of the 2024 Section 1557 rule have been challenged in court. The litigation (Tennessee v. Becerra and related cases) stayed the rule's gender-identity provisions nationwide; the language-access provisions described here were not the target of those stays and remain in effect, with a full-implementation deadline that has already passed (June 5, 2025).² Treat the language rules as live law, and re-confirm status with counsel before launch — appeals are ongoing.

Three side-by-side cards comparing spoken interpretation, written translation, and sign-language interpretation by what each is and who counts as qualified Figure 1. Three jobs that get called "translation." Spoken interpretation carries the live visit, written translation handles documents, and sign-language interpretation for deaf patients sits under disability law — each needs a different qualified person.

Where machine translation is allowed, and where it is not

The §92.201(c)(3) test is the single most useful thing in this article, so let us make it concrete. The rule says human review is required when any of three conditions is true. Walk a candidate text through all three gates.

Gate 1 — Is the text critical to the patient's rights, benefits, or access to care? Consent forms, discharge and aftercare instructions, medication directions, eligibility and coverage notices, and anything the patient must act on all pass this gate. They are critical. They need a human.

Gate 2 — Is accuracy essential here? Dosages, allergy warnings, "do not" instructions, symptoms that should send the patient back to the ER — these are places where a single mistranslated word causes harm. Accuracy is essential. They need a human.

Gate 3 — Is the language complex, non-literal, or technical? Clinical notes, anything with idiom, anything where "negative" means "good news," anything dense with medical terminology. They need a human.

If a text clears none of the three gates, machine translation alone may be acceptable — think of a generic appointment-reminder banner, an in-app navigation label, or a "your provider will join shortly" notice. If it trips any gate, a qualified human translator must review the output. Most clinical content trips at least one. The safe default for a telemedicine team is: machine translation is fine for chrome and convenience, and never the final word on anything a patient acts on medically.

Decision diagram showing three gates — critical to rights, accuracy essential, complex language — converging on a required qualified human review Figure 2. The Section 1557 machine-translation test. If the text trips any one of the three gates, a qualified human translator must review the machine output. Most clinical content trips at least one.

How good is clinical machine translation, really?

The honest answer is "better than it was, and still not safe on its own for clinical content." The research is unusually clear here, and the numbers are worth walking through because they explain why the law insists on human review.

A widely cited 2019 study evaluated Google Translate on emergency-department discharge instructions and found it accurately translated more than 80% of sentences into Spanish and Chinese — but the inaccuracies that remained were potentially harmful, and the authors concluded the tool should not be used in clinical care without additional quality checks.³ Later work put numbers on the danger: roughly 2% of Spanish sentences and 8% of Chinese sentences carried potential for significant harm.³

Newer large-language-model translation is meaningfully better. A 2024–2026 wave of studies found GPT-class and Google models reaching roughly 96–97% accuracy English-to-Spanish and 90–95% English-to-Chinese, and rated them statistically non-inferior to professional interpreters for most domains on common discharge text.⁴ That is real progress. But the same body of work shows the gains are uneven: for a lower-resource language such as Haitian Creole, machine outputs carried clinically significant errors far more often than professional translation (roughly 23–33% of segments for the machine tools versus about 8% for professionals).⁴

Now do the arithmetic that a product owner should do. Suppose a discharge sheet has 12 instructions and your engine produces "harmful error" on 8% of them, as the Chinese figure suggests. That is 0.08 × 12 ≈ 1 dangerous sentence per discharge sheet. Across a thousand discharges a month, that is roughly a thousand chances for a patient to misunderstand a dose or a warning. The aggregate accuracy looks reassuring — 92% sounds like an A — but the errors are not spread evenly; they cluster in exactly the high-stakes sentences the law cares about. That distribution, not the headline percentage, is why §92.201(c)(3) exists.

The takeaway for design is not "machine translation is bad." It is "machine translation is a draft." It can give a human interpreter or translator a fast first pass to verify and fix, it can power convenience features that are not clinically load-bearing, and it can help in a genuine emergency when no human is yet on the line. It cannot be the thing a patient relies on to take a medication correctly.

The compliance boundary: a translation engine is a business associate

Here is the part most language-access discussions skip and most engineers get wrong. A clinical conversation, a discharge document, a symptom description — all of it is Protected Health Information (PHI), which is any health information tied to an identifiable person. The moment you send that text or audio to a translation service, that service is handling PHI on your behalf, which makes it a business associate under HIPAA. And a business associate may not touch PHI until you have a signed Business Associate Agreement (BAA) with it — the contract in which the vendor promises to guard the data and accept HIPAA liability (45 CFR §160.103 and §164.502(e)).⁵

Think of the BAA as the signed promise every contractor makes before they get a key to the building. No signature, no key — no matter how good the contractor is.

This single rule disqualifies the tool most teams reach for first. The free, consumer Google Translate website and app do not come with a BAA and are not built for PHI; pasting a patient's symptoms into the public Google Translate box, or into a consumer chatbot, is a HIPAA breach regardless of how accurate the translation is. Remember the distinction that runs through this whole section: encrypted is not the same as compliant, and "the vendor has a famous brand" is not the same as "the vendor signed a BAA covering this service."

The enterprise cloud services are a different story, and most do offer a BAA — but you have to use the enterprise product, not the consumer one, and confirm the BAA covers the exact service. Amazon Translate has been HIPAA-eligible under the AWS BAA since 2018.⁶ Google Cloud Translation (the paid enterprise API, not the free site) and Microsoft Azure AI Translator are likewise covered under their respective providers' BAAs.⁷ The pattern is identical to the one in our transcription and captioning and AI scribe articles: the engine is a commodity you can buy under a BAA; placing it correctly relative to the PHI boundary is the work.

If you build a real-time speech-to-speech translation flow yourself — speech recognition, then text translation, then speech synthesis — every hop in that chain receives PHI, so every vendor in it needs a BAA, not just the translation step. The deep engineering of that pipeline (streaming recognition, latency budgets, voice synthesis) lives in our AI for Video Engineering section; this article is about wiring it into the clinical and compliance frame.

Compliance boundary diagram showing a cross-language consult with a human interpreter and an enterprise translation engine inside the BAA-covered boundary and a consumer app outside it Figure 3. The compliance boundary for a cross-language consult. The qualified human interpreter and any enterprise translation engine sit inside the HIPAA boundary under a BAA; the free consumer app sits outside it and must never receive patient data.

Augmentation, not replacement: where AI actually helps

If a qualified human is required for the load-bearing work, what is AI for? A great deal, as it turns out — as long as you frame every AI feature as something that makes the human better, faster, or cheaper to reach, rather than something that removes them. This framing is the heart of the article's title: interpreter augmentation.

Reaching a human faster and cheaper. The biggest practical barrier to language access is not technology; it is getting a qualified interpreter on the line in the seconds a clinician has. Smart routing, presence, and a well-built video remote interpreting layer — meeting the §92.201(f) quality bar — turn "we'll reschedule when an interpreter is free" into "tap to add an interpreter now." That is augmentation through plumbing, and it is the highest-value thing most products can build.

Drafting and terminology support for the human. A machine-translation first pass can give a human translator a draft to correct instead of a blank page, cutting the time to produce a verified document. Real-time terminology assist can surface the right rendering of a drug name or a procedure to a working interpreter. The human still signs off; the AI removes friction.

Dual-language captions during the visit. Showing live captions in both the clinician's and the patient's language — clearly labeled as machine-generated support, not a certified record — can improve comprehension alongside a human interpreter, the same way subtitles help even when you mostly follow a film. Keep these transient and clearly marked, and keep the human interpreter as the channel of record.

After-visit summary translation, with review. Translating a plain-language after-visit summary into the patient's language is high-value and squarely inside §92.201(c)(3): generate the draft with a BAA-covered engine, then route it to a qualified human for review before it reaches the patient. The AI does the 90%; the human guarantees the last, dangerous 10%.

Emergency stopgap, honestly labeled. When there is a genuine imminent-threat emergency and no interpreter is yet available, machine translation is better than nothing and the law's emergency exception contemplates exactly that gap — but it must be a labeled stopgap that a qualified interpreter confirms or supplements the moment one is reachable, never the steady state.

The line to hold in every design review: AI can carry the patient to the qualified human and make that human more effective, but for anything a patient acts on clinically, the qualified human is in the loop. A product that quietly swaps the interpreter for a model has not built a feature — it has built a liability. For the full PHI-handling, BAA, and FDA framing that applies to every AI feature in a telemedicine product, see our compliance and safety layer for clinical AI.

A reference design for a cross-language consult

Put the pieces together into something you could build. A patient who speaks Vietnamese books a visit; the clinician speaks English. Here is a compliant, AI-augmented flow.

At scheduling, the patient's language preference is captured as structured data, so the system knows before the visit that an interpreter is needed — not discovered at minute one. When the consult starts, the platform adds a qualified Vietnamese medical interpreter as a third party to the call over a video remote interpreting connection that meets the §92.201(f) quality bar; this is the same multi-party-consult mechanism described in our article on multi-party and multi-role consults, with the interpreter as a typed role under HIPAA's minimum-necessary rule. The interpreter carries the conversation.

Alongside, optional machine-generated captions render in both languages as labeled support, powered by a BAA-covered engine inside the boundary. After the visit, the clinician's plain-language after-visit summary is machine-translated into Vietnamese by the same BAA-covered engine and then reviewed by a qualified human translator before it is released to the patient — clearing the §92.201(c)(3) gate. Every component that touches audio, text, or the summary is inside the HIPAA boundary under a signed BAA; the patient's own phone and any consumer app stay outside it and never receive PHI.

That design gives the patient a human interpreter where the law and safety demand one, uses AI to make the interpreter reachable and the document fast, and keeps every piece of PHI inside a contracted boundary. It is the shape of a system that passes both a clinical review and an Office for Civil Rights inquiry.

A common, expensive mistake

The single most common language-access failure in telemedicine builds is not exotic. A team under deadline wires the patient-facing app to free consumer translation — the public Google Translate API or a consumer chatbot — because it is one line of code and "good enough to ship." In one move they have done two things wrong: sent PHI to a vendor with no BAA (a HIPAA breach), and substituted unreviewed machine output for a qualified interpreter on clinical content (a Section 1557 violation). The feature demos beautifully and is a double liability the day a real patient uses it.

The close cousin is the human version: letting the patient's bilingual family member or, worse, their child interpret because an interpreter is not instantly available. It feels kind and practical in the moment. It is specifically prohibited by §92.201(e) outside a true emergency, it produces well-documented clinical errors, and it puts a minor in the position of relaying a parent's diagnosis. Build the qualified-interpreter path so that it is the easy path, and these mistakes stop being tempting.

Where Fora Soft fits in

The requirement comes first: a cross-language telemedicine visit must put a qualified interpreter in the room, meet the video-quality bar the rule sets for remote interpreting, and keep every word of PHI inside a BAA-covered boundary. Fora Soft has built real-time video, WebRTC, and multi-party conferencing since 2005, including telemedicine platforms where interpreters, specialists, and caregivers join a clinical call as distinct roles. We wire AI translation and captioning in as augmentation — reaching a human faster, drafting documents for human review — inside the compliance boundary, never as a quiet replacement for the qualified human the law requires.

What to read next

Download the Medical Translation & Interpreter Compliance Checklist (PDF)

Call to action

References

  1. Section 1557 — Meaningful Access for Individuals with Limited English Proficiency, 45 CFR §92.201 — HHS (eCFR), source 89 FR 37692, May 6, 2024. Tier 1. Qualified interpreter and translator requirements; free/accurate/timely; the no-family/no-minor restrictions; VRI quality standard; the machine-translation human-review rule.
  2. Section 1557 of the Affordable Care Act — Nondiscrimination Final Rule and litigation status — HHS Office for Civil Rights. Tier 1. The 2024 final rule, the June 5, 2025 implementation deadline, and the Tennessee v. Becerra stays limited to the gender-identity provisions (language-access provisions in effect). Time-sensitive.
  3. Assessing the Use of Google Translate for Spanish and Chinese Translations of Emergency Department Discharge Instructions — Khoong et al., JAMA Internal Medicine (2019). Tier 5. >80% accurate, but ~2% of Spanish and ~8% of Chinese sentences carried potential for significant harm.
  4. Comparative and non-inferiority evaluations of machine translation of ED discharge instructions (GPT and Google Translate vs professional translation) — Academic Emergency Medicine and related 2024–2026 literature. Tier 5. ~96–97% (Spanish) and ~90–95% (Chinese) accuracy; non-inferiority on common text; markedly higher error rates for lower-resource languages such as Haitian Creole. Time-sensitive.
  5. HIPAA Privacy Rule — Business Associates (45 CFR §160.103, §164.502(e)) — HHS. Tier 1. Any translation vendor that receives PHI is a business associate and needs a signed BAA before any data reaches it.
  6. Amazon Translate Achieves HIPAA Eligibility — Amazon Web Services. Tier 4. Example of a translation engine usable for PHI under the AWS BAA. Time-sensitive.
  7. HIPAA-eligible enterprise translation: Google Cloud Translation and Microsoft Azure AI Translator under their BAAs; free consumer Google Translate is not covered — vendor BAA documentation and analysis. Tier 4. The enterprise-vs-consumer distinction that decides whether a translation service may touch PHI. Time-sensitive.
  8. ADA Requirements: Effective Communication (28 CFR §36.303) — U.S. Department of Justice. Tier 1. The parallel disability-access duty for deaf and hard-of-hearing patients, distinct from LEP language access.