TwinEthosRequest access

Control

Health information sent to an external AI vendor without the contractual or legal basis the law requires

Identifiable health information reaches an AI model, transcription, or embedding vendor only under the legal basis the governing law requires (a business associate contract, a statutory disclosure exception, or the patient's authorization) and with limits on the vendor's own use of the data.

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.

Control id cond.health-data-sent-to-ai-vendor-without-required-safeguards

Reach

2items this one guard addresses
2jurisdictions where binding law on it is in force
0more where it is enacted, not yet applying
0standards and frameworks on the same control

Law in force in United States (federal) (US), California (US-CA).

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 reviewers look for: on every path from a patient record, FHIR read or clinical note to a model API, either a vendor-register check (baa_signed, processing_agreement, zero_data_retention) bound to the endpoint actually called, a recorded authorization check, or a deidentify / redact_phi step before the prompt is built; no health data sent to a general consumer endpoint or an account with training or retention left on, and no diagnosis or medication fields in marketing prompts.

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}'}])

Engineering guidance, not legal advice. Each provision below may add its own details (a cadence, a deadline, a required notice element): open it for those.

Every rule this guard addresses

Binding law — in force (2)