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

Why this matters

Writing the note and writing the patient's takeaways are the two most time-consuming things a clinician does after a visit, and they are exactly the tasks generative AI is fastest at — which is why nearly every telehealth platform is adding them in 2026. The upside is real: a good draft saves minutes per visit and gives the patient something they can actually understand instead of a wall of medical shorthand. The risk is just as real: a summary that quietly drops the dose change, invents a diagnosis the clinician never made, or tells a low-literacy patient something they misread is a patient-safety event with the platform's name on it. This article is for the founder, product manager, or engineer deciding what their summarization feature is allowed to write, who has to approve it, and where it lands — and it draws the compliance lines in plain language so the feature ships as help, not liability.

Two summaries, two readers — keep them apart

The word "summary" hides two different products, and a team has to build them as two things because they serve two readers.

The clinical visit summary is written for the provider and the care team. It condenses the consult into the medical note — the reason for the visit, findings, assessment, plan, and any orders — in clinical shorthand, and it becomes part of the legal medical record. Its job is accuracy and completeness; its reader already speaks the language.

The patient-facing after-visit summary, often called the AVS, is written for the patient at home. It explains what happened and what to do next — the plan, the new medication, the follow-up, the warning signs — in plain, everyday words. Its job is comprehension by someone with no medical training, possibly tired, anxious, or reading in a second language.

These pull in opposite directions. The clinical note prizes precision and uses terms like "SOB on exertion"; the patient summary must say "you get short of breath when you walk." Build one document and try to serve both readers and you get a note too vague for the chart and too technical for the patient. The reusable rule for the rest of this article: decide who reads each output before you decide what the model writes.

Three columns comparing a clinician visit summary, a patient after-visit summary, and the rules both share Figure 1. Two summaries, two readers. The clinician note and the patient after-visit summary differ in audience, reading level, and risk — but both are drafts that a human must approve, and both carry PHI inside a contracted boundary.

The patient probably reads the note too

For years teams treated the clinical note as private to the care team. That assumption is no longer safe, and the reason is a federal rule.

The information-blocking rule under the 21st Century Cures Act (45 CFR Part 171) makes a provider's electronic health information available to patients without delay, generally through the patient portal. It has applied to health care providers since April 5, 2021. In practice, the clinical notes a clinician writes — the same notes an AI might draft — are released to the patient, often within minutes of being signed. There is a narrow Preventing Harm exception (45 CFR §171.201) that permits delay in specific, documented circumstances, but it is the exception, not the workflow.

Two consequences follow for a summarization feature. First, a sloppy or wrong AI-drafted note is not an internal problem the patient never sees; it is something the patient reads, sometimes before the clinician has reread it. Second, the line between "clinical note" and "patient document" blurs, which raises the bar on the note's tone and accuracy, not just the after-visit summary's. Design as if the patient is reading everything, because legally they usually can.

The reason a human must sign: models still invent and omit

Here is the uncomfortable fact under every summarization demo. Large-language-model summaries of clinical text are good, but not safe enough to trust unread — and they fail in two distinct ways. A hallucination is a fact the model added that was never in the source (a medication, a diagnosis, a number that did not exist). An omission is a fact in the source the model dropped (the dose change, the red-flag instruction). Both are dangerous; omissions are easy to miss precisely because nothing looks wrong.

The measured rates are small but not zero. A 2025 clinical-safety framework that reviewed 12,999 clinician-annotated sentences from LLM note summaries found a hallucination rate around 1.5% and an omission rate around 3.5%.¹ Other evaluations are harsher: in a study drafting emergency-department encounter summaries, only about a third of GPT-4 summaries were entirely error-free across all checked categories, and a separate review of AI discharge summaries flagged potential safety risks in nearly 40% of cases.² Real-world deployment data agrees that the problem is rare-but-present: ambulatory clinicians using AI encounter summaries flagged hallucinations or factual errors in about 3% of entries.³

Do the arithmetic a product owner should do. Suppose your tool drafts summaries for 3,000 visits a month and carries a 3% omission rate. That is 90 summaries a month with a missing fact — and if even a third of those omissions touch something that matters, like a dose or a follow-up, that is roughly 30 patients a month who could be handed an incomplete plan. The percentage sounds trivial; the monthly count of affected patients is the safety story. This is why the law's "administrative support" comfort and good engineering both require a person between the model and the record.

The review-gate pattern: draft, never file

Put that fact to work and one architecture protects both summaries. The model produces a draft; a clinician reads, edits, and signs; and only the signed version is filed to the record or released to the patient. Draft, never file. The AI is a fast typist, not the author of record.

Concretely, after the consult ends, the transcript or note flows to a contracted model that returns two drafts — the clinical note and the plain-language after-visit summary — clearly labeled as unverified. The clinician sees both alongside the source, edits anything wrong or missing, and signs. The signature is the moment the document becomes real: before it, the AI output is a suggestion; after it, the clinician owns every word, exactly as they would for something they typed themselves. The system logs the draft, the edits, and the sign-off, so there is an audit trail of what the model proposed and what the human changed.

This pattern does three jobs at once. It catches hallucinations and omissions before they reach the chart or the patient. It keeps a licensed human accountable for the medical content, which is what keeps the feature on the administrative-support side of the regulatory line. And it produces the record an auditor or a clinical reviewer will ask for. A summarization feature without a review gate is not a time-saver; it is an unsupervised author of the medical record.

Pipeline diagram showing a consult feeding a BAA-covered model that drafts two summaries, a clinician reviewing and signing, then release to the record and patient portal Figure 2. The review-gate pattern. The consult (PHI) enters the HIPAA boundary; a contracted model drafts both summaries; a clinician edits and signs; only the signed version reaches the record and the patient. The consumer chatbot stays outside the boundary.

The patient summary has two extra duties: reading level and language

A clinician note has one reader who speaks the language. The patient summary has a reader who often does not — and that creates two obligations a build must meet.

The first is reading level. Federal health-literacy guidance is consistent: patient materials should be written in plain language at roughly a sixth-grade level, sometimes lower. The Agency for Healthcare Research and Quality's Health Literacy Universal Precautions Toolkit recommends short sentences, common words, and an assessment of every patient-facing document for understandability, and the CDC's Clear Communication Index gives a scoring method for the same goal.⁴⁵ Showing the math: a sentence like "Continue metoprolol 25 mg PO BID and monitor for orthostatic hypotension" is unreadable to most patients; the AI's job is to render it as "Keep taking your heart medicine, metoprolol, one pill twice a day. Stand up slowly — it can make you dizzy." Same facts, sixth-grade words. A summarization feature that produces patient text at a clinical reading level has failed the patient even when every fact is correct.

The second is language access. Under Section 1557 of the Affordable Care Act, a covered entity must provide meaningful access to people with limited English proficiency, including qualified interpreters and translated materials, and the rule limits reliance on raw machine translation for critical content (45 CFR §92.201).⁶ For an after-visit summary that means the patient's language is a first-class requirement, not a nice-to-have — and that machine-translating a safety-critical plan without a qualified human in the loop is a compliance risk, not just a quality one. The clinical side of when machine translation is acceptable is covered in our medical translation and interpreter augmentation article.

Every word is PHI — so the model is a business associate

A visit transcript is the densest Protected Health Information you will ever handle — PHI being any health data tied to an identifiable person. The moment that text leaves your servers for a model to summarize, the model's provider is handling PHI on your behalf, which under HIPAA makes it a business associate, and a business associate may not touch PHI until you have a signed Business Associate Agreement, or BAA — 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 getting a key to the building. No signature, no key — no matter how good the model.

This disqualifies the free, consumer chatbots a team often reaches for first: they ship no BAA and are not built for PHI, so pasting a transcript into one is a HIPAA breach regardless of how clean the summary looks. The enterprise model APIs from the major cloud providers are different — they are offered under a BAA — but you must use the covered enterprise service, confirm the BAA names it, and add a no-training clause so your patients' visits are never absorbed into the vendor's future models. This is the same boundary work as our ambient clinical documentation (AI scribe) and real-time transcription features; the full treatment of PHI handling and model-vendor BAAs lives in the compliance and safety layer for clinical AI.

The FDA line: recap is administrative, decision is a device

One regulatory question decides how heavily your feature is regulated: does it summarize, or does it decide? The U.S. Food and Drug Administration treats software that merely facilitates clinical documentation as administrative support, outside device regulation. Its Clinical Decision Support guidance, issued in final form in January 2026, keeps a "not a device" carve-out for tools that support a clinician who can independently review the basis, and signals openness to documentation tools that keep a human in the loop.⁸

A summary that recaps the visit and routes through a clinician's signature sits comfortably on the administrative side. The feature drifts toward being a regulated device when it stops recapping and starts deciding — generating a new diagnosis the clinician did not make, recommending a treatment the visit did not cover, or being directive and opaque enough that a clinician cannot review its basis. The practical test mirrors the review-gate rule: if a human reads and owns the output, and the output describes the visit rather than making a fresh medical call, you are doing summarization; if the software is effectively making the decision, you are building a device and need to talk to a regulatory specialist. The full diagnosis-versus-support line is drawn in our AI triage article.

Decision diagram showing three triggers that push a summary tool from administrative support into FDA device territory Figure 3. What pushes a summary tool over the FDA line. Issuing a new decision instead of a recap, being a black box a clinician cannot review, or auto-filing without a human signature each move the tool out of administrative support toward device regulation.

Once signed, the summary is part of the record

A signed visit summary does not just sit in a folder — it becomes part of the patient's designated record set, the collection of records a provider uses to make decisions about a patient (45 CFR §164.501). That status carries two patient rights a build must support. The patient has a right of access to a copy (45 CFR §164.524), and a right to request amendment if something is wrong (45 CFR §164.526). For an AI-drafted summary, the amendment right is the one teams forget: if the model wrote something the patient believes is incorrect, your platform needs a path to flag, review, and correct it — and a way to record that the correction happened. The audit trail from the review gate is what makes this possible.

A reference design for safe visit summarization

Make it concrete. A telehealth consult for a medication adjustment ends. The transcript and the clinician's structured inputs sit inside the HIPAA boundary as PHI. A BAA-covered model — under a contract with a no-training clause — drafts two outputs: a clinical note in medical shorthand and a sixth-grade after-visit summary in the patient's language, both labeled "AI draft — unverified." The clinician sees both next to the source, corrects the dose the model rounded wrong and the follow-up it dropped, and signs. Only then does the note post to the EHR and the after-visit summary appear in the patient portal, where information-blocking rules make it promptly available. Every step — draft, edit, sign, release — is logged, so the audit trail exists and the amendment path is ready if the patient disputes a fact.

That design uses AI where it genuinely helps — fast first drafts of two documents nobody enjoys writing — while a clinician owns the content, the patient gets something readable in their language, and every word stays inside a contracted boundary. It is the shape of a feature that passes a clinical review, a HIPAA review, and an information-blocking check at once.

Comparison table of visit-summary approaches by reader, review, reading-level fit, and regulatory plus BAA posture Figure 4. Visit-summary approaches compared. Read the last column first: who reads the output, and whether a human signs before it counts, decide the regulatory and PHI posture.

A common, expensive mistake

The signature failure is auto-filing: wiring the model straight into the chart so its summary posts without a human reading it, because a review step "slows clinicians down." It does save seconds — until the first hallucinated diagnosis or dropped dose lands in a legal record the patient reads through the portal the same afternoon. The team has shipped an unsupervised author of the medical record and an information-blocking delivery system for its errors, in one move.

The quieter cousin is the literacy mismatch: a patient summary that is factually perfect but written at a clinical reading level, so the anxious patient at home misreads the plan. It passes every accuracy check and still fails the one reader it was built for. Build the review gate so signing is required, and run a reading-level check on patient text so plain language is automatic, and neither mistake survives contact with the product.

Where Fora Soft fits in

The requirement comes first: a summarization feature must keep a clinician accountable for every filed word, write patient text at a reading level real patients can use and in their language, hold every transcript inside a BAA-covered boundary, and stay on the recap side of the FDA's documentation line. Fora Soft has built real-time video, conferencing, and clinical-workflow software since 2005, including telemedicine platforms where the consult, the note, and the patient's takeaways are one connected flow. We wire AI summarization in as a drafting aid — two labeled drafts, a clinician review-and-sign gate, a reading-level pass on patient text, and a full audit trail — never as a tool that files itself to the record.

What to read next

Download the Visit-Summary Review-Gate & Plain-Language Checklist (PDF)

Call to action

References

  1. Development and evaluation of a clinical note summarization system using large language models — Communications Medicine (2025). Tier 5. A clinical-safety framework over 12,999 clinician-annotated sentences reporting a hallucination rate of roughly 1.5% and an omission rate of roughly 3.5% in LLM note summaries. Time-sensitive — re-verify the exact figures.
  2. Evaluating large language models for drafting emergency department encounter summaries — PMC (2025). Tier 5. Only about a third of GPT-4 encounter summaries were entirely error-free across evaluated domains; companion reviews flagged potential safety risks in nearly 40% of AI discharge summaries.
  3. Artificial intelligence-generated encounter summaries: early insights from ambulatory clinicians at a large academic health system — PMC (2025). Tier 5. Real-world ambulatory clinicians flagged hallucinations or factual errors in about 3% of AI encounter-summary entries; some providers relied on the summary in place of the full note.
  4. Health Literacy Universal Precautions Toolkit (Tool 11 — assess, select, and create easy-to-understand materials) — U.S. Agency for Healthcare Research and Quality. Tier 1. Patient materials should use plain language and short sentences at a low reading level (about sixth grade), with every patient-facing document assessed for understandability.
  5. Clear Communication Index — U.S. Centers for Disease Control and Prevention. Tier 1. A scored method for developing and evaluating patient and public communication materials for plain-language comprehension.
  6. 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. Duty to provide qualified interpreters and translated materials, and the limit on relying on raw machine translation for critical content. Time-sensitive — confirm provisions remain in force.
  7. HIPAA Privacy Rule — Business Associates (45 CFR §160.103, §164.502(e)) — HHS. Tier 1. Any model provider that receives PHI is a business associate and needs a signed BAA before any transcript reaches it.
  8. Clinical Decision Support Software — Guidance for Industry and FDA Staff (Final, January 2026) — U.S. Food and Drug Administration, docket FDA-2017-D-6569. Tier 1. Software that facilitates clinical documentation is administrative support; tools that keep a clinician able to review the basis stay outside device regulation, while directive or opaque tools may be regulated. Time-sensitive.
  9. Information Blocking (45 CFR Part 171, including the §171.201 Preventing Harm exception) — HHS / Assistant Secretary for Technology Policy (ONC). Tier 1. Electronic health information, including clinical notes, is made available to patients without delay; only narrow documented exceptions permit a delay. Applicable to providers since April 5, 2021.
  10. Right of access (45 CFR §164.524), amendment (§164.526), and the designated record set (§164.501) — HHS (eCFR). Tier 1. A signed summary is part of the designated record set; the patient may obtain a copy and request correction of errors.