HIPAA's Minimum Necessary Standard Applied to an AI Assistant

The easiest way to build a clinical assistant is to put the whole chart in the prompt and let the model find what it needs. That is a design decision with a regulation attached to it, and the regulation is one of the few in HIPAA that speaks directly to how much data you moved rather than to whether you were allowed to move any.

The rule and its exceptions

Section 164.502(b) of the Privacy Rule states the standard: when using or disclosing protected health information, or when requesting it from another covered entity, a covered entity must make reasonable efforts to limit the information to the minimum necessary to accomplish the intended purpose. Section 164.514(d) then sets out the implementation specifications — identify who needs access to what, limit access accordingly, and for non-routine disclosures apply criteria on a case-by-case basis.

The exceptions at § 164.502(b)(2) are short and they matter:

• Disclosures to, or requests by, a health care provider for treatment.
• Disclosures to the individual who is the subject of the information.
• Uses or disclosures made pursuant to a valid authorisation.
• Disclosures to the Secretary of HHS for enforcement.
• Uses or disclosures required by law, and those required for compliance with the rules.

Notice what is not on that list: a disclosure to a business associate. The standard applies to it.

The treatment exception does not cover the vendor

The most common mistake in this area is a chain of reasoning that sounds right. A physician may request an entire record from another provider for treatment without applying minimum necessary. The assistant supports the physician’s treatment of the patient. Therefore the assistant may receive the entire record.

The chain breaks at the second step. The exception is written for a disclosure to or request by a health care provider for treatment. An AI vendor is a business associate, not a health care provider under the definition at § 160.103, and the disclosure being made is the covered entity’s disclosure of PHI to that associate. That disclosure is not within the exception, so reasonable efforts to limit apply to it.

There is a narrower argument available where the assistant is functionally an interface the treating clinician operates on their own data within the covered entity’s own systems — that this is a use for treatment by the provider rather than a disclosure outward. It is not a frivolous argument, and it is also not settled: no OCR guidance addresses the architecture directly, and the answer plainly depends on whether the model provider can access the content. Where you rely on it, write down why, and expect the reasoning to be examined if there is ever an incident.

What this means for a context window

The standard is “reasonable efforts”, not perfection, and it is purpose-relative. Two consequences follow that are directly actionable.

First, the purpose has to be defined narrowly enough to constrain anything. “Assist the clinician” is not a purpose; it justifies everything. “Summarise this encounter’s medications for interaction risk” is a purpose, and it tells you that the problem list and active medications are in scope and eight years of billing history is not. A product with one general-purpose assistant and one general-purpose retrieval step cannot make this argument at all; a product with defined tasks can make it for each.

Second, a large context window is a liability rather than a feature here. The engineering pressure runs the other way: if the model can accept a million tokens, retrieval quality problems disappear by simply including more. Every additional record included for convenience is PHI disclosed for a purpose it was not needed for, and the fact that the model ignored it is irrelevant — the disclosure happened when you sent it. Minimum necessary is about what left your systems, not about what changed the output.

Retrieval scope as a compliance control

Once you accept that the retrieval step is where the standard is satisfied or breached, the design follows. A few patterns do most of the work.

• Field-level rather than document-level retrieval. Return the medication list, not the note that contains it. A vector index built over whole documents makes this structurally impossible, which is a compliance consequence of an indexing decision made for unrelated reasons.
• Enforce the caller’s access rights at retrieval time. Section 164.514(d)(2) requires identifying persons or classes who need access and limiting it accordingly. If the assistant queries with a service account that can read everything, the role-based access control in the record system has been bypassed. The retrieval layer must run as the user.
• Strip identifiers the task does not need. A model reasoning about a drug interaction does not need a name, address or member number. Substituting stable pseudonyms before the prompt leaves the answer unchanged and reduces what a disclosure exposes. This is not de-identification under § 164.514(b) — it remains PHI — but reasonable efforts is the standard, and this is visibly one.
• Cap and record what was included. A hard limit on records per request, with an auditable reason when it is exceeded, converts an unbounded design into one that can be explained.
• Treat conversation history as retrieval. A multi-turn assistant resends prior turns on every call. PHI included for turn one is disclosed again at turn twenty, for a purpose that has since changed. Pruning history is a minimum-necessary control, not just a token-cost optimisation.

The related contractual controls — retention, training prohibition, subprocessor limits — are in the BAA drafting page. They are complementary: the contract limits what the associate may do with what it receives, and this standard limits what it receives.

The log is also PHI

To demonstrate reasonable efforts you have to be able to show what was actually sent, which means logging prompts. That log is a collection of PHI assembled by purpose, and it is now one of the most sensitive stores you operate — frequently more concentrated than the source record, because it contains only what somebody thought was relevant.

The Security Rule applies to it in full: access controls under § 164.312(a), audit controls under § 164.312(b), integrity and transmission security, and the documentation retention requirement at § 164.316(b)(2)(i), which requires policies and documentation to be retained for six years from creation or last effective date. Prompt logs are also the first thing a debugging workflow copies into a less-protected environment, and that copy is a disclosure.

The reconciling design is to log the reference rather than the content where you can: record which record identifiers, fields and model version went into a request, and reconstruct the prompt from the source of truth when you need it, rather than storing the assembled text. It is more work, it costs you the ability to grep prompts casually, and it means the audit trail proves what was disclosed without becoming a second copy of everything disclosed. Where you do store full prompts, scope retention deliberately and hold them under the same controls as the clinical record itself.