HIPAA Privacy Rule (45 CFR 160, 164 Subpart E)

Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.

Official text: www.ecfr.gov, www.federalregister.gov.

Binding law — in force

Protected health information may go to an AI vendor only under a business associate contract (HIPAA)

45 CFR 164.502(e)(1) · official text · In force: applies since 14 Apr 2003 · United States (federal) (US)

Under 45 CFR 164.502(e) a covered entity may let a business associate create, receive, maintain, or transmit protected health information on its behalf only after obtaining satisfactory assurance, documented in a written contract that meets 164.504(e), that the business associate will safeguard it; a business associate needs the same from its subcontractors. 164.504(e)(2) lists what the contract must say, including permitted uses, no further disclosure, safeguards, breach reporting, flow-down to subcontractors, and return or destruction at termination. An AI model, transcription, or embedding vendor that processes PHI for a covered entity or business associate fits the pattern the definition of business associate describes (160.103). Detect PHI flowing to a model API with no sign of a business associate agreement, a covered endpoint, or de-identification.

Who it applies to

Duty falls on: deployer, processor
Sectors: healthcare, insurance
HIPAA covered entities (health plans, health care clearinghouses, and health care providers that conduct covered transactions) and their business associates, when an AI vendor creates, receives, maintains, or transmits protected health information on their behalf. Whether a given model provider is a business associate (and not, for example, a treatment provider) is a legal determination. Privacy standards applied from 2003-04-14 (164.534); the current business associate provisions from the 2013 Omnibus Rule, compliance date 2013-09-23.
Not covered:
- Disclosures by a covered entity to a health care provider concerning the treatment of the individual (45 CFR 160.103, 'business associate' (4)(i))
- Health information de-identified under 164.514(a) is not individually identifiable health information, so it is not PHI (160.103, 164.514(a))
Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Send identifiable health data only to AI endpoints registered with a signed BAA or processing agreement and retention and training off; otherwise de-identify first.

A single client factory for model, embedding and transcription calls that handle health information: it looks the endpoint up in a vendor register and refuses to return a client unless the register shows the required contract (business associate agreement, or a processing agreement barring further disclosure) and the endpoint is the covered deployment with data retention and training use turned off. Call sites that cannot meet that de-identify or redact the record before building the prompt, or check a recorded patient authorization for that use. Keep the vendor register in the repository so reviewers can match each AI endpoint to its legal basis, and never route health data into marketing or other non-care generation.

Where it goes: 6 API calls and integrations, 3 config and feature flags, 7 prompt construction, 12 repository artifacts.

What this provision adds:

The written contract on the register covers permitted uses, no further disclosure, safeguards, breach reporting, flow-down to subcontractors, and return or destruction of PHI at termination.
A business associate that passes PHI to an AI vendor needs the same written assurance from that vendor as its subcontractor.

Example (Python + OpenAI SDK (Azure OpenAI)), before:

client = OpenAI()
resp = client.chat.completions.create(model='gpt-4o', messages=[
    {'role': 'user', 'content': f'Summarize: {patient.clinical_note}'}])

After:

VENDORS = load_yaml('vendors/ai_vendors.yaml')   # baa_signed, zero_data_retention per endpoint

def phi_client(name: str) -> tuple[AzureOpenAI, str]:
    v = VENDORS[name]
    if not (v['baa_signed'] and v['zero_data_retention']):
        raise PermissionError(f'{name} is not cleared for PHI')
    client = AzureOpenAI(azure_endpoint=v['endpoint'], api_key=os.environ['AZURE_OPENAI_KEY'],
                         api_version=v['api_version'])
    return client, v['deployment']

client, deployment = phi_client('azure-openai-hipaa')
resp = client.chat.completions.create(model=deployment, messages=[
    {'role': 'user', 'content': f'Summarize: {patient.clinical_note}'}])

Control: Health information sent to an external AI vendor without the contractual or legal basis the law requires. The same guard addresses 2 items with binding law in 2 jurisdictions. Engineering guidance, not legal advice.

Rule id us-hipaa-privacy.ai-vendor-business-associate-contract · review status: primary source derived

Binding law — in force

Send an AI model only the protected health information the task needs (HIPAA minimum necessary)

45 CFR 164.502(b)(1) · official text · In force: applies since 14 Apr 2003 · United States (federal) (US)

45 CFR 164.502(b) requires covered entities and business associates to make reasonable efforts to limit PHI to the minimum necessary for the purpose of a use, disclosure, or request, and 164.514(d) implements it: standard protocols for routine disclosures, case-by-case criteria for others, and no use or disclosure of an entire medical record unless that is specifically justified. The standard does not apply to disclosures to a health care provider for treatment, to the individual, under an authorization, or where required by law (164.502(b)(2)). Detect AI prompts, context, or training sets built by serializing a whole patient record, chart, or FHIR bundle instead of a task-specific field selection.

Who it applies to

Duty falls on: deployer, processor
Sectors: healthcare, insurance
HIPAA covered entities and business associates that use or disclose PHI through an AI model (prompts, retrieval context, fine-tuning data). Whether a given AI workflow is a treatment disclosure exempt under 164.502(b)(2)(i) is a legal determination. Applied from 2003-04-14 (164.534); business associates' duty under the current text from the 2013 Omnibus Rule compliance date, 2013-09-23.
Not covered:
- Disclosures to or requests by a health care provider for treatment (164.502(b)(2)(i))
- Uses or disclosures made to the individual (164.502(b)(2)(ii))
- Uses or disclosures made pursuant to an authorization under 164.508 (164.502(b)(2)(iii))
- Disclosures to the Secretary, uses or disclosures required by law, and those required for compliance with the subchapter (164.502(b)(2)(iv)-(vi))
Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Build AI prompts, context and fine-tuning rows from a per-task allowlist of health-record fields, never by serializing a whole patient record or FHIR bundle.

In the prompt builder or retrieval step for each AI task that reads health records, define the fields that task needs (a TASK_FIELDS allowlist, pydantic model_dump(include=...), FHIR _elements or _summary on the query) and pass only those; do not json.dumps a patient, chart or encounter object, call a get-full-chart helper, or fetch Patient/$everything to feed a model. Keep the per-task field list as the standard protocol for that routine AI use and review it when the task changes. Where a task genuinely needs the whole record, record that justification next to the code path; de-identifying the input is an alternative.

Where it goes: 7 prompt construction, 2 data models, 6 API calls and integrations.

What this provision adds:

Keep standard protocols for routine AI disclosures and case-by-case criteria for non-routine ones; send the entire medical record only where that is specifically justified.
The limit does not apply to disclosures to a health care provider for treatment, to the individual, under an authorization, or where required by law; record which exception a whole-record path relies on.

Example (Python + OpenAI SDK), before:

patient = ehr.get_patient(pid)
prompt = 'Write a discharge summary for: ' + json.dumps(patient)
resp = client.chat.completions.create(model=MODEL, messages=[{'role': 'user', 'content': prompt}])

After:

DISCHARGE_FIELDS = ('age', 'admit_reason', 'procedures', 'discharge_meds', 'follow_up')
patient = ehr.get_patient(pid)
selected = {k: patient[k] for k in DISCHARGE_FIELDS}
prompt = 'Write a discharge summary for: ' + json.dumps(selected)
resp = client.chat.completions.create(model=MODEL, messages=[{'role': 'user', 'content': prompt}])

Control: More health information than the task needs is sent to an AI model. The same guard addresses 1 item with binding law in 1 jurisdiction. Engineering guidance, not legal advice.

Rule id us-hipaa-privacy.minimum-necessary-phi-to-ai · review status: primary source derived