How Large Language Models Should Handle Adolescent Confidential Information in Patient Portals

How adolescent information reaches a proxy through an LLM

Portals already struggle with adolescent privacy. Setting up varied portal access for patients aged 12 to 17 is described as particularly tricky, because adolescents may want their information kept private and the rules differ from state to state. An LLM adds new paths around the access controls a portal has already configured.

There are three main paths. The first is retrieved context: a summarization or question-answering feature pulls notes or results into the prompt, and a sensitive segment is included because retrieval ran with the service's privileges rather than the requester's. The second is generated text: a summary of a visit history or a drafted message reply restates confidential content in fluent prose that no portal filter recognizes. The third is inference: even when the sensitive note is excluded, the model can reveal the existence of a service through medication lists, appointment types, referrals, or the way it phrases a refusal.

Static prompt instructions such as "do not mention sensitive topics" do not control any of these paths. They ask the model to behave, but they do not decide what data it may receive or what text may be delivered. Review after the fact finds a disclosure only after the proxy has seen it. The control has to sit where data enters the model and where output leaves it.

From legal context to policy attributes

Three bodies of rules interact. Under HHS Privacy Rule guidance, rights rest with the individual or the individual's personal representative. HHS gives an example: where state law lets an adolescent consent to mental health treatment without parental consent, and the adolescent obtains that treatment that way, the parent is not the personal representative for that treatment. State law therefore determines the outcome, and it varies. Separately, HIPAA does not permit a covered entity or business associate to use or disclose PHI except as the rules permit or require. An LLM response delivered to a proxy is a disclosure and should be evaluated as one.

The third body is information blocking under 45 CFR Part 171. As of October 2026, not fulfilling a request to access, exchange, or use electronic health information in order to protect an individual's privacy is not information blocking when the practice meets all requirements of at least one sub-exception in paragraphs (b) through (e). Withholding from a proxy is therefore defensible only when you can show which sub-exception applies. Read the current regulatory text for the conditions of each.

These rules translate into five policy inputs. Requester role identifies whether the user is the patient or a proxy. Patient age is necessary but not sufficient. Sensitivity category comes from tagging at the segment level, for example sexual health, mental health, or social history. Jurisdiction selects the applicable state rule set. Consent or treatment status records whether the adolescent consented to and obtained the specific care. Because personal representative status depends on the specific service, the engine needs service-level or encounter-level attributes, not only patient-level age. Authority to access data is also distinct from medical decision-making authority, so a proxy role should never be treated as equivalent to consent authority.

Choosing between allow, redact, block, and escalate

Allow when the attributes show the requester is entitled to everything in context, for example the adolescent using their own account, or a proxy interacting with content that carries no restricted tag. Redact when a response is otherwise appropriate but contains a restricted segment. Redaction at retrieval is safer than redaction at output, because the model never sees the content and cannot paraphrase it. Block when the request itself targets restricted content, or when output checks find restricted material that cannot be cleanly removed. A block should return a neutral response that does not confirm the restricted service exists.

Escalate for human approval when the policy cannot decide with confidence: jurisdiction cannot be resolved, consent status is missing or conflicting, a drafted reply mixes restricted and unrestricted content, or the legal basis for withholding is unclear. Escalation should be rare and its queue owned by someone with authority to decide. Failing closed on ambiguity is a reasonable default for adolescent records.

There is a tradeoff. Over-redaction frustrates legitimate proxy use and can create information blocking exposure if withholding cannot be tied to a privacy sub-exception. Under-redaction is a disclosure. Keep a maintained jurisdiction rule table, record the legal basis of each decision, and distinguish personal representative status from portal access configuration. Tell patients and caregivers whether and how AI is used in the portal.

Where Trussed fits and how to evaluate it

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, with outcomes of allow, redact, block, rate limit, and escalate for human approval. The scope is individual interactions and tool calls, which matches the unit of decision described above. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence mapped to HIPAA. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency, and it runs in production with healthcare organizations.

Whatever platform you evaluate, ask five questions. Can it enforce on requester role, age, sensitivity tag, jurisdiction, and consent status at each retrieval, prompt, tool call, and response? How do sensitivity tags propagate into context and into generated summaries? How is jurisdiction determined and kept current? What per-interaction record shows what was allowed, redacted, blocked, or escalated? How are human escalations handled and recorded? Start with tagging, build the jurisdiction table, and put portal messaging in scope of your LLM risk assessment.