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

Why this matters

If you are deciding what to build into a telehealth product, "add AI" is not a plan — it is six different plans with six different risk profiles. A founder or product lead needs to see the whole board before committing budget: which AI features are mature enough to ship in 2026, which still carry real clinical and legal risk, and what every one of them costs you in compliance work. The expensive mistake is treating AI as a single switch you flip, instead of a set of data flows you have to route carefully around patient privacy and medical-device law. This map gives you the vocabulary to talk to engineers, auditors, and your own board about each feature on its own terms.

First, the one question every AI feature raises

Before we map anything, fix one idea in your head, because it governs everything that follows.

Protected Health Information — PHI for short — is any health data that can be tied to an identifiable person: a name with a diagnosis, a recording of a consult, a transcript that mentions a patient's address. Under the US health-privacy law known as HIPAA (the Health Insurance Portability and Accountability Act), PHI is the unit of risk. The moment PHI moves from your system to someone else's, the law cares.

Now the question. Every AI feature is, underneath, a place where patient data is sent somewhere to be processed. An ambient scribe sends the audio of a visit to a speech model. A translation feature sends a sentence to a translation model. A triage bot sends a patient's symptoms to a language model. So the first question for any AI feature is always the same: does PHI leave my protected boundary, and if so, who is on the receiving end and what have they signed?

Hold that question. We will return to it at every stop on the map.

The map: six places AI shows up in a telehealth product

Picture the patient journey as a line from left to right: the patient books, checks in, has the visit, and gets follow-up. AI hooks into that line at six points. Five of the six are downstream of the same idea — turning the spoken or written content of care into structured, useful text — and one sits on a separate data stream entirely.

Map of six AI features placed along the telemedicine patient journey, from pre-visit triage to post-visit monitoring Figure 1. The six places AI attaches to a telemedicine product, laid along the patient journey. Each is a separate feature with its own maturity and its own PHI path.

1. Ambient clinical documentation (the AI scribe). The breakout feature of the last two years. The system listens to the consult and drafts the clinical note — the structured record a clinician would otherwise type after the visit. It works by chaining three steps: speech recognition (turning audio into words), speaker separation (knowing who said what), and clinical summarization (shaping the conversation into a note). In 2026 this is the most mature and highest-return AI feature in telehealth, and it is where most clinical AI budgets go first. It is covered in depth in the AI scribe article.

2. Real-time transcription and captioning. Live captions during the call, for accessibility and for the record. Technically it is the front half of the scribe — streaming speech recognition — but it is a feature in its own right because captions are also an accessibility requirement, not only a convenience. Mature in 2026 for general speech; the gap is medical vocabulary, where drug names and clinical terms trip up general models. See real-time transcription and captioning.

3. Medical translation and interpreter augmentation. Real-time translation when the patient and clinician do not share a language. This one carries a legal twist most teams miss: federal civil-rights rules require a qualified interpreter for many clinical encounters, and a machine cannot always be that interpreter. AI here augments a human; it rarely replaces one. Covered in medical translation and interpreter augmentation.

4. AI triage, symptom intake, and routing. Before the visit: a symptom questionnaire or chatbot that gathers the complaint and routes the patient to the right provider. This is the feature that flirts most directly with the regulatory line, because the difference between "here is information to help the clinician decide" and "here is your likely diagnosis" is the difference between an ordinary product and an FDA-regulated medical device. See AI triage, symptom intake, and routing.

5. Visit summarization and after-visit notes. After the visit: a summary for the provider and a plain-language recap for the patient. The provider version overlaps with the scribe; the patient version is its own thing, because it must be readable at a low reading level and must not invent instructions. Hallucination — the model confidently stating something that was never said — is the central risk. See visit summarization and after-visit notes.

6. Remote monitoring and anomaly detection. The one feature on a different data stream. Instead of the conversation, AI watches the numbers coming off home devices — blood pressure cuffs, glucose monitors, pulse oximeters — and flags trends or anomalies. The hard problem is not detection; it is alert fatigue, and the regulatory question is whether an alert is a wellness nudge or a regulated medical warning. See remote patient monitoring and anomaly detection.

That is the whole map. Six features, two data streams (the conversation and the device readings), one shared question about where the data goes.

What is mature in 2026, and what is still risky

Maturity here means two things at once: does the technology work well enough to trust, and is the regulatory ground under it stable. A feature can be technically excellent and still risky if it sits on a shifting legal line.

AI feature Maturity in 2026 Does PHI leave the boundary? FDA-device risk Needs a vendor BAA?
Ambient scribe (documentation) High — production-ready Yes — audio + transcript to the model Low (documents, does not decide) Yes
Real-time transcription / captions High — general; medium for medical terms Yes — audio stream to the ASR model Low Yes
Medical translation Medium — augments, rarely replaces a human Yes — text/audio to the translation model Low, but civil-rights rules apply Yes
Triage / symptom intake Medium — works, but near the device line Yes — symptoms to the model High if it diagnoses Yes
Visit summarization Medium-high — gated by human review Yes — transcript to the model Low Yes
RPM anomaly detection Medium — detection easy, alerting hard Yes — device data to the model High if it warns of a condition Yes

Read the table by its two red columns. The "does PHI leave the boundary?" column is "yes" for every feature — that is the rule, not the exception, and it tells you that every AI feature needs the same privacy plumbing. The "FDA-device risk" column is where the features genuinely differ: documentation and transcription are low risk because they record and organize rather than decide, while triage and monitoring are high risk because they edge toward telling someone what is wrong with them.

The four gates every AI feature must pass

A useful way to think about adding any AI feature is a gate sequence. The feature does not ship until it clears all four. The order matters: a feature that fails gate 1 never gets to gate 4.

Four sequential compliance gates an AI feature passes before reaching a patient: BAA, PHI boundary, FDA line, human review Figure 2. The four gates. A feature ships only after clearing all four; failing an earlier gate stops it before the later ones.

Gate 1 — The contract gate: is there a signed BAA?

A Business Associate Agreement (BAA) is the contract that lets an outside vendor handle patient data on your behalf and legally binds them to protect it. Think of it as the signed promise every contractor must make before they get a key to the building. Under HIPAA, any vendor that "creates, receives, maintains, or transmits" PHI for you is a business associate, and a signed BAA is required before they touch a single record (45 CFR §160.103 defines the role; §164.502(e) and §164.504(e) require and shape the agreement).

For AI, this gate has teeth. The major model providers offer a BAA — but usually only on a specific paid tier, not the consumer product. The free, public version of a chatbot has no BAA and is not a place patient data may go. "The vendor offers a BAA" and "we are using the configuration the BAA covers" are two different facts; confirm both. Read the full BAA article for what belongs in one.

One AI-specific clause matters enough to call out: a standard BAA may not stop the vendor from using your patients' data to train its general model. For AI vendors, you often have to add that prohibition explicitly. A vendor can be HIPAA-covered and still, by default, learn from your data unless you say no in writing.

Gate 2 — The boundary gate: where does the PHI actually go?

Encryption is necessary but not sufficient — a feed can be perfectly encrypted and still be a violation if it crosses to a vendor with no BAA. So gate 2 asks a sharper question than "is it encrypted?": does identifiable patient data need to leave the protected boundary at all, or can it be stripped first?

There are two clean ways to satisfy this gate. The first is to keep the model inside the boundary — run it on infrastructure you control or on a vendor under BAA — and send real PHI to it. The second is to de-identify the data before it leaves: remove the details that tie it to a person so that what crosses the boundary is no longer PHI. HIPAA gives two recognized methods (45 CFR §164.514(b)): "Safe Harbor," which means stripping 18 specified identifiers (names, full dates, geographic detail below a state, record numbers, and so on), and "Expert Determination," where a qualified statistician certifies the re-identification risk is very small.

The catch with AI is real and worth stating plainly: large language models can memorize and later surface fragments of their training data, so de-identification has to be done before the data reaches the model, and outputs should be monitored. De-identification is not a checkbox; it is a data-engineering task. The analytics-and-secondary-use details live in de-identification and analytics on health data.

Gate 3 — The regulatory gate: support or diagnosis?

This is the gate that separates a normal product feature from a regulated medical device. The US Food and Drug Administration (FDA) regulates software that diagnoses, treats, or drives clinical decisions — a category called Software as a Medical Device (SaMD). But it does not regulate every piece of clinical software. The line is drawn by the FDA's Clinical Decision Support Software guidance, updated to a new final version in January 2026 (docket FDA-2017-D-6569), which interprets the "Non-Device CDS" criteria Congress wrote into the 21st Century Cures Act.

In plain terms, software stays on the safe (non-device) side of the line when all of these hold: it does not analyze a medical image or a signal straight from a monitoring device; it works from medical information a clinician could review; it offers recommendations to a healthcare professional rather than to a patient directly; and — the load-bearing one — the clinician can independently review the basis for the recommendation rather than having to rely on it. Software that the clinician must trust blindly, or that goes straight to the patient as a diagnosis, falls on the device side and pulls in FDA oversight.

Map that back to our six features. An ambient scribe documents what happened; it does not decide, so it sits comfortably on the non-device side. A triage bot that tells a patient "you likely have strep throat" is making a diagnosis aimed at the patient — that is the device side. The same triage technology, reframed to hand the clinician structured intake and let the clinician decide, can stay on the safe side. The feature's framing often decides its regulatory status as much as its technology does.

The January 2026 update generally loosened FDA's posture on lower-risk decision-support tools and added enforcement-discretion examples, but it kept the hard cases hard: anything analyzing a medical image to produce a diagnostic recommendation remains a regulated device. Treat the device line as a design constraint, not a label you apply at the end.

Gate 4 — The human gate: who reviews the output before it counts?

The last gate is the cheapest insurance in clinical AI: a human in the loop. No AI output becomes part of the record, reaches a patient as instruction, or triggers a clinical action without a qualified person reviewing and accepting it. The scribe drafts the note; the clinician signs it. The summarizer drafts the after-visit summary; a clinician approves it before it sends. The triage bot proposes a routing; it does not page a doctor on its own authority.

This gate does double duty. It catches the model's mistakes — the hallucinated instruction, the misheard drug name — and it keeps many features on the non-device side of gate 3, because a tool that a clinician reviews and can override is decision support, not autonomous decision-making. Designing the review step well is most of what separates a clinical-AI feature that ships from one that scares your compliance officer.

A worked example: is your triage bot a medical device?

Numbers and rules are easier to trust when you walk one through. Suppose you want to add a pre-visit symptom checker. Run it through gate 3 against the four non-device conditions, scoring each as pass or fail:

Condition 1 — Does it analyze a medical image or a device signal directly?
   Your bot reads typed symptoms only.                         → PASS (non-device)

Condition 2 — Does it work from reviewable medical information?
   It uses the patient's stated symptoms and history.          → PASS

Condition 3 — Is the recommendation aimed at a clinician, not the patient?
   Version A: it tells the PATIENT "you likely have X."        → FAIL (device side)
   Version B: it hands the CLINICIAN a structured intake.      → PASS

Condition 4 — Can the clinician independently review the basis?
   It shows which answers drove the routing.                   → PASS

Result: Version A fails one condition → regulated device path.
        Version B passes all four    → non-device CDS.

Same model, same accuracy, two outcomes. The difference is who the output is for and whether the human can see and override the reasoning. That is gate 3 and gate 4 doing their job at design time, before a regulatory submission is ever on the table.

A common, expensive mistake

The most frequent failure we see is not exotic. It is a clinician — or a developer testing a feature — pasting real patient notes into a free, public AI chatbot to "see if it works." By spring 2026, nearly every health organization has at least one AI tool touching PHI, and many of those flows started with no BAA in place.

That single paste is a HIPAA violation whether or not anything bad ever happens, because PHI crossed to a vendor with no signed agreement and, on a consumer tier, possibly into model training. The fix is boring and absolute: every AI tool that can touch PHI is on an approved list, runs under a BAA on the covered configuration, and the public consumer tiers are blocked. Make the compliant path the easy path, or the easy path wins.

Where Fora Soft fits in

We build the telemedicine, video conferencing, and streaming systems these AI features attach to, and the order we work in is the order this article argues for: the compliance boundary first, the capability second. When a client wants an ambient scribe, live captions, or AI triage, our job is to route the patient-data path so the model vendor sits under a BAA or never sees identifiable data at all, to keep the feature on the non-device side of the FDA line where that is the intent, and to build the human-review step into the product rather than bolt it on. The AI is the easy part; placing it correctly relative to the PHI boundary and the device line is the engineering that keeps a launch out of trouble.

What to read next

Download the AI feature map & compliance-gate checklist (PDF)

Call to action

References

  1. FDA, Clinical Decision Support Software — Guidance for Industry and FDA Staff (Final, January 2026; docket FDA-2017-D-6569). The current statement of the Non-Device CDS criteria under §520(o)(1)(E) of the FD&C Act — the support-versus-diagnosis line. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software — tier 1.
  2. 21st Century Cures Act §3060(a) (2016), amending §520 of the Federal Food, Drug, and Cosmetic Act to exclude certain decision-support software from the device definition. The statutory basis FDA's CDS guidance interprets. tier 1.
  3. HHS, HIPAA Privacy Rule — business-associate definition and contract requirement, 45 CFR §160.103, §164.502(e), §164.504(e). Why every AI vendor that touches PHI needs a signed BAA. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html — tier 1.
  4. HHS, Guidance Regarding Methods for De-identification of PHI under 45 CFR §164.514(b) — Safe Harbor (18 identifiers) and Expert Determination. The two recognized ways to take data out of PHI scope before it reaches a model. https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html — tier 1.
  5. ONC/ASTP, HTI-1 Final Rule — Algorithm Transparency / Predictive Decision Support Intervention certification criterion (45 CFR §170.315(b)(11)); Federal Register 89 FR 1192, Jan 9, 2024; DSI maintenance-of-certification from Jan 1, 2025. Transparency obligations for predictive AI in certified health IT. https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program — tier 1.
  6. HHS, HIPAA Security Rule NPRM (RIN 0945-AA22; Federal Register, Jan 6, 2025) — proposed strengthening of technical safeguards, including MFA and encryption. Proposed, not final as of 2026-06-14; cited as proposed. tier 1.
  7. FDA, Software as a Medical Device (SaMD): Clinical Evaluation and the IMDRF SaMD framework — the device-classification frame the CDS guidance sits inside. https://www.fda.gov/medical-devices/software-medical-device-samd — tier 1.
  8. Morgan Lewis, Healthcare AI Deployment: Compliance Through Contracting, BAAs, and Data Governance (May 2026). Practitioner analysis of AI-specific BAA clauses, including the no-train-on-our-data provision. https://www.morganlewis.com/pubs/2026/05/healthcare-ai-deployment-compliance-through-contracting-baas-and-data-governance — tier 5.
  9. HIPAA Journal, When AI Technology and HIPAA Collide and Business Associate Agreement (2026 update) — industry orientation on AI/PHI flows and BAA practice. https://www.hipaajournal.com/when-ai-technology-and-hipaa-collide/ — tier 6, orientation only.

Where sources disagreed, the article follows the controlling rule. Vendor and practitioner pieces (refs 8–9) describe market practice; the support-versus-diagnosis line, the de-identification methods, and the BAA requirement are stated from FDA and HHS primary sources (refs 1, 3, 4), which override any looser vendor framing. The FDA CDS guidance is cited at its January 2026 final version, replacing the September 2022 version some secondary sources still reference.