TwinEthos homeAPI access

Law

Alabama SB 63 (2026; AI in health-plan prior-authorization determinations)

Alabama Department of Insurance · Alabama (US-AL) · 5 provisions encoded · verified against the official source as of 2026-10-03.

Informational data, not legal advice. Summaries and rules have not been reviewed by a lawyer: always verify official law text for decisions. A suggested guard is intended to address each rule; adding it is not a statement of compliance to that law.

Official text: alison.legislature.state.al.us.

Trust and provenance 1 official source · last verified 3 Oct 2026 · not reviewed by a lawyer · 5 of 5 provisions audit-grade · release 2026.10.03.4

Where this instrument's data comes from, how current it is, and what has and has not been checked. Each provision below has its own panel.

Official sources
Lanes
Binding law — in force 5
Verification
Sources last verified 3 Oct 2026; each provision states how.
Data release
Data release 2026.10.03.4, data as of 3 Oct 2026, schema 0.3.9.
Legal review
None of the 5 provisions has been reviewed by a lawyer; no TwinEthos rule has been legally reviewed yet. Treat each as research to check against the official text; it is not legal advice. Open questions for counsel on them: 5.
Audit standard
5 of 5 provisions audit-grade. The audit standard is TwinEthos's own quality bar for provenance, dates, applicability, detectors, fixtures, remediation and licences; it is not a legal review.
Detectors
5 detectors, all experimental: written from the rule's text and not yet measured for precision on real code, so treat a hit as a lead to verify. Each provision lists its detectors' known limits.
Changes
  • 2026.10.03.4 (3 Oct 2026): 5 provisions added

Each data release records which provisions changed; the full list is on Changes.

Binding law — in force

Make prominent written disclosure of the use of AI in utilization review in the plan provider's policies and procedures (Alabama SB 63)

Ala. SB 63 (2026), sec. 1(c)(1) · official text · In force: applies since 1 Oct 2026 · Alabama (US-AL)

From 2026-10-01, a health benefit plan provider must make prominent written disclosure regarding its use of artificial intelligence in utilization review in its policies and procedures (SB 63 sec. 1(c)(1)), satisfied by an authorized representative's attestation based on reasonable reliance on internal policies, procedures and third-party vendors (sec. 1(c)(4)). Detect the absence of a written AI-use disclosure in the utilization-review policies.

Trust and provenance not reviewed by a lawyer · audit-grade · source verified 3 Oct 2026 · release 2026.10.03.4
Lane
Binding law — in force In force: applies since 1 Oct 2026
Official source
Ala. SB 63 (2026), sec. 1(c)(1) · captured 3 Oct 2026 · anchor hash (SHA-256) ccefa2438079… · 10 more anchors in the data release
Verification
Quoted text found word for word in the captured official document (3 Oct 2026). Source last verified 3 Oct 2026: checked against the captured official document.
Data release
Data release 2026.10.03.4, data as of 3 Oct 2026, schema 0.3.9.
Legal review
Not reviewed by a lawyer. TwinEthos derived this rule from the official text it cites: treat it as research to check against that text; it is not legal advice. No TwinEthos rule has been legally reviewed yet. Open questions for counsel on this rule: 1.
Audit standard
Audit-grade: meets all 10 checks of the TwinEthos audit standard that apply to it. The audit standard is TwinEthos's own quality bar for provenance, dates, applicability, detectors, fixtures, remediation and licences; it is not a legal review.
Detectors

1 detector (missing artifact), experimental: written from the rule's text and not yet measured for precision on real code, so treat a hit as a lead to verify.

Known limits:

  • Policies held in a compliance system outside the repository

Who it applies to

  • Duty falls on: insurer, organization
  • Sectors: insurance, healthcare
  • Health benefit plan providers (entities issuing, delivering or renewing health benefit plans in Alabama, including insurers, HMOs, nonprofit health care services plans and nonprofit agricultural organizations offering health benefits, their internal utilization review units, and separate entities performing utilization review as their contractors or agents) that use artificial intelligence to make medical-necessity determinations on prior-authorization requests. In force 2026-10-01.
  • Not covered:
    • Plans that are not 'health benefit plans': accident-only, specified disease, individual hospital indemnity, credit, dental-only, Medicare supplement, long-term care, disability income or other limited benefit policies, and coverage supplemental to liability, workers' compensation or automobile medical payment insurance (SB 63 sec. 1(a)(5)b)
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Notify consumers when AI makes or supports their underwriting, rating, or claims decision, and list that model in the insurer's written AIS Program.

In the code path that calls a model for underwriting, rating, premium quoting, or claims decisions, send or render a consumer notice that AI systems are used (in the quote flow, claim acknowledgement, or decision letter) and record that it was delivered. The model is an entry in the insurer's written AIS Program, covering governance, risk-management controls, internal audit, lifecycle management, third-party systems, and an accountable leader, with an owner; keep the inventory entry or a pointer to it in the repository so each decision path is traceable to its program record.

Where it goes: 9 AI output handling, 14 user-facing text, 12 repository artifacts.

Example (Python + OpenAI SDK), before:

resp = client.chat.completions.create(model=MODEL, messages=claim_msgs)
claim_decision = parse_decision(resp.choices[0].message.content)
claims.update(claim_id, status=claim_decision)

After:

AI_USE_NOTICE = ('An AI system helped evaluate your claim. '
                 'You can ask us how it was used and request review by a claims adjuster.')
resp = client.chat.completions.create(model=MODEL, messages=claim_msgs)
claim_decision = parse_decision(resp.choices[0].message.content)
claims.update(claim_id, status=claim_decision, ais_program_ref='AIS-012')
send_ai_notice(claimant, text=AI_USE_NOTICE)

Control: Insurer AI decision system without a written AIS Program / consumer notice. The same guard addresses 5 items with binding law in 4 jurisdictions. Engineering guidance, not legal advice.

Standards that recommend the same control

Rule id al-sb63.ai-use-disclosure-in-policies · review status: primary source derived

Binding law — in force

Certify yearly that prior-authorization AI is fair and does not discriminate, and review its outcomes periodically (Alabama SB 63)

Ala. SB 63 (2026), sec. 1(b)(2) (to the page break) · official text · In force: applies since 1 Oct 2026 · Alabama (US-AL)

From 2026-10-01, a health benefit plan provider must certify annually to the Department of Insurance that the artificial intelligence used for medical-necessity determinations on prior authorization is fairly and equitably applied, including under HHS regulations and guidance, and does not discriminate, directly or indirectly, against any subscriber group or enrollee in violation of state or federal law (SB 63 sec. 1(b)(2)b-c), and must ensure that its use of AI and the outcomes it generates are reviewed on a periodic basis to maximize accuracy and reliability and ensure compliance with subsection (b) (sec. 1(c)(2)); the requirements are satisfied by an attestation of an authorized representative based on reasonable reliance on internal policies, procedures and third-party vendors (sec. 1(c)(4)). Detect the absence of a periodic accuracy, outcome and disparity review supporting the annual certification.

Trust and provenance not reviewed by a lawyer · audit-grade · source verified 3 Oct 2026 · release 2026.10.03.4
Lane
Binding law — in force In force: applies since 1 Oct 2026
Official source
Ala. SB 63 (2026), sec. 1(b)(2) (to the page break) · captured 3 Oct 2026 · anchor hash (SHA-256) fe13d4b07ed5… · 12 more anchors in the data release
Verification
Quoted text found word for word in the captured official document (3 Oct 2026). Source last verified 3 Oct 2026: checked against the captured official document.
Data release
Data release 2026.10.03.4, data as of 3 Oct 2026, schema 0.3.9.
Legal review
Not reviewed by a lawyer. TwinEthos derived this rule from the official text it cites: treat it as research to check against that text; it is not legal advice. No TwinEthos rule has been legally reviewed yet. Open questions for counsel on this rule: 1.
Audit standard
Audit-grade: meets all 10 checks of the TwinEthos audit standard that apply to it. The audit standard is TwinEthos's own quality bar for provenance, dates, applicability, detectors, fixtures, remediation and licences; it is not a legal review.
Detectors

1 detector (missing artifact), experimental: written from the rule's text and not yet measured for precision on real code, so treat a hit as a lead to verify.

Known limits:

  • Reviews kept in a governance system outside the repository

Who it applies to

  • Duty falls on: insurer, organization
  • Sectors: insurance, healthcare
  • Health benefit plan providers (entities issuing, delivering or renewing health benefit plans in Alabama, including insurers, HMOs, nonprofit health care services plans and nonprofit agricultural organizations offering health benefits, their internal utilization review units, and separate entities performing utilization review as their contractors or agents) that use artificial intelligence to make medical-necessity determinations on prior-authorization requests. In force 2026-10-01.
  • Not covered:
    • Plans that are not 'health benefit plans': accident-only, specified disease, individual hospital indemnity, credit, dental-only, Medicare supplement, long-term care, disability income or other limited benefit policies, and coverage supplemental to liability, workers' compensation or automobile medical payment insurance (SB 63 sec. 1(a)(5)b)
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Compute per-group accuracy and bias metrics in the training pipeline of every consequential-decision model, keep the results per version, and rerun them on a schedule.

A validation stage that runs whenever a decision model is trained, fine-tuned, or retrained (the same module or pipeline step as fit(), Trainer, xgb.train, or fine_tuning.jobs.create) and again on a recurring schedule against recent decisions: accuracy and error rates per group, selection rates and disparity metrics (fairlearn MetricFrame, demographic_parity_difference, AIF360 disparate impact), and drift. Results go to a versioned validation report alongside a datasheet or data card for the training data, and a threshold gate blocks promotion of a model version whose metrics regress until a named owner reviews and records a decision. The validation cadence and owner are written in the model's validation record.

Where it goes: 1 application source code, 11 CI/CD pipeline, 12 repository artifacts, 13 tests and evals.

What this provision adds:

  • Certify to the Department of Insurance every year, through an authorized representative's attestation, that the AI does not rely on a group dataset, is fairly and equitably applied and does not discriminate.

Example (scikit-learn + fairlearn), before:

clf = LogisticRegression(max_iter=1000).fit(X_train, y_train)
joblib.dump(clf, 'models/credit_v4.joblib')

After:

from fairlearn.metrics import MetricFrame, selection_rate, demographic_parity_difference
from sklearn.metrics import accuracy_score

clf = LogisticRegression(max_iter=1000).fit(X_train, y_train)
y_pred = clf.predict(X_test)
mf = MetricFrame(metrics={'accuracy': accuracy_score, 'selection_rate': selection_rate},
                 y_true=y_test, y_pred=y_pred, sensitive_features=A_test)
dpd = demographic_parity_difference(y_test, y_pred, sensitive_features=A_test)
write_validation_report('credit_v4', mf.by_group, dpd)
if dpd > MAX_DPD:
    raise SystemExit('bias gate failed: owner review required before release')
joblib.dump(clf, 'models/credit_v4.joblib')

Control: AI decision system without regular accuracy/bias validation. The same guard addresses 8 items with binding law in 5 jurisdictions. Engineering guidance, not legal advice.

Standards that recommend the same control

Related incidents

No guardrail sits on this exact control; these incidents are cited by guardrails on related controls.

Rule id al-sb63.annual-certification-fairness-and-periodic-review · review status: primary source derived

Binding law — in force

AI prior-authorization determinations must rest on the enrollee's own history and circumstances, not a group dataset (Alabama SB 63)

Ala. SB 63 (2026), sec. 1(b)(1) · official text · In force: applies since 1 Oct 2026 · Alabama (US-AL)

From 2026-10-01, a health benefit plan provider that uses artificial intelligence to make determinations of medical necessity on prior-authorization requests must base them on all of the enrollee's medical history, any clinical circumstances unique to the enrollee presented by the requesting provider, and additional clinical information in the enrollee's medical record (SB 63 sec. 1(b)(1)), and must certify annually to the Department that the AI does not rely on a group dataset to make determinations (sec. 1(b)(2)a). Detect utilization-review model calls built without the member's clinical record or the provider's submission.

Trust and provenance not reviewed by a lawyer · audit-grade · source verified 3 Oct 2026 · release 2026.10.03.4
Lane
Binding law — in force In force: applies since 1 Oct 2026
Official source
Ala. SB 63 (2026), sec. 1(b)(1) · captured 3 Oct 2026 · anchor hash (SHA-256) aa5edd4d53f5… · 12 more anchors in the data release
Verification
Quoted text found word for word in the captured official document (3 Oct 2026). Source last verified 3 Oct 2026: checked against the captured official document.
Data release
Data release 2026.10.03.4, data as of 3 Oct 2026, schema 0.3.9.
Legal review
Not reviewed by a lawyer. TwinEthos derived this rule from the official text it cites: treat it as research to check against that text; it is not legal advice. No TwinEthos rule has been legally reviewed yet. Open questions for counsel on this rule: 1.
Audit standard
Audit-grade: meets all 10 checks of the TwinEthos audit standard that apply to it. The audit standard is TwinEthos's own quality bar for provenance, dates, applicability, detectors, fixtures, remediation and licences; it is not a legal review.
Detectors

1 detector (code pattern), experimental: written from the rule's text and not yet measured for precision on real code, so treat a hit as a lead to verify.

Known limits:

  • Prompt builders imported from another module
  • Feature stores whose columns are not named in the code
  • The clinical record may be assembled in a helper module and passed in under a generic name; trace the prompt or feature builder before reporting.

Who it applies to

  • Duty falls on: insurer, organization
  • Sectors: insurance, healthcare
  • Health benefit plan providers (entities issuing, delivering or renewing health benefit plans in Alabama, including insurers, HMOs, nonprofit health care services plans and nonprofit agricultural organizations offering health benefits, their internal utilization review units, and separate entities performing utilization review as their contractors or agents) that use artificial intelligence to make medical-necessity determinations on prior-authorization requests. In force 2026-10-01.
  • Not covered:
    • Plans that are not 'health benefit plans': accident-only, specified disease, individual hospital indemnity, credit, dental-only, Medicare supplement, long-term care, disability income or other limited benefit policies, and coverage supplemental to liability, workers' compensation or automobile medical payment insurance (SB 63 sec. 1(a)(5)b)
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Build each automated medical-necessity determination from the enrollee's own clinical record and the provider's submission, and refuse to decide on group statistics alone.

In the prompt builder or feature pipeline for each medical-necessity or coverage determination, load the enrollee's clinical history and the requesting provider's clinical documentation for this request (the attached notes, the FHIR Condition, Observation and DocumentReference resources for the member, the provider's letter of medical necessity) and pass the fields the decision needs; group or population data (a diagnosis code's typical length of stay, a cohort's approval rate, a regional benchmark) may be context but never the only input. A guard before the model or rules call raises an error, or routes the case to clinical review, when the individual clinical inputs are empty, and the inputs used are saved with the result so a reviewer or regulator can see what the determination rested on.

Where it goes: 1 application source code, 2 data models, 7 prompt construction, 9 AI output handling.

Example (Python + Anthropic SDK), before:

features = {'cpt': req.cpt, 'icd10': req.icd10, 'cohort_approval_rate': cohort_stats(req.icd10)}
reply = client.messages.create(model=MODEL, max_tokens=400,
    messages=[{'role': 'user', 'content': f'Prior authorization request: {features}'}])

After:

record = member_clinical_record(req.member_id, fields=PA_CLINICAL_FIELDS)   # history, conditions, meds
submission = provider_clinical_submission(req.id)                            # notes, letter of medical necessity
if not record or not submission:
    return review_queue.enqueue(req.id, reason='individual clinical information missing')
reply = client.messages.create(model=MODEL, max_tokens=400, messages=[{'role': 'user', 'content':
    render('pa_review.txt', request=req, clinical_history=record, provider_submission=submission)}])
determinations.save(req.id, inputs={'clinical_history': record.ids, 'submission': submission.ids})

Control: AI coverage or medical-necessity determination not based on the individual's own clinical information. The same guard addresses 3 items with binding law in 3 jurisdictions. Engineering guidance, not legal advice.

Related incidents

No guardrail sits on this exact control; these incidents are cited by guardrails on related controls.

Rule id al-sb63.individual-clinical-data-basis · review status: primary source derived

Binding law — in force

Only a licensed physician or competent health care professional may deny, delay or modify prior authorization (Alabama SB 63)

Ala. SB 63 (2026), sec. 1(b)(3) · official text · In force: applies since 1 Oct 2026 · Alabama (US-AL)

From 2026-10-01, every decision to deny, delay or modify a prior-authorization request on medical-necessity grounds is for a licensed physician or other health care professional able to weigh what the AI recommends or concludes against the clinical issues unique to the enrollee or raised by the treating provider (SB 63 sec. 1(b)(3)). Detect automated output that sets a denial, delay or modification without that professional's decision.

Trust and provenance not reviewed by a lawyer · audit-grade · source verified 3 Oct 2026 · release 2026.10.03.4
Lane
Binding law — in force In force: applies since 1 Oct 2026
Official source
Ala. SB 63 (2026), sec. 1(b)(3) · captured 3 Oct 2026 · anchor hash (SHA-256) e6d34688b5dd… · 10 more anchors in the data release
Verification
Quoted text found word for word in the captured official document (3 Oct 2026). Source last verified 3 Oct 2026: checked against the captured official document.
Data release
Data release 2026.10.03.4, data as of 3 Oct 2026, schema 0.3.9.
Legal review
Not reviewed by a lawyer. TwinEthos derived this rule from the official text it cites: treat it as research to check against that text; it is not legal advice. No TwinEthos rule has been legally reviewed yet. Open questions for counsel on this rule: 1.
Audit standard
Audit-grade: meets all 10 checks of the TwinEthos audit standard that apply to it. The audit standard is TwinEthos's own quality bar for provenance, dates, applicability, detectors, fixtures, remediation and licences; it is not a legal review.
Detectors

1 detector (code pattern), experimental: written from the rule's text and not yet measured for precision on real code, so treat a hit as a lead to verify.

Known limits:

  • Review routing in a separate workflow service or BPM engine
  • Denials applied by a downstream claims system from an exported score
  • The clinical review may live in another module (a workflow engine or a separate review service); confirm the adverse status cannot be reached without it before reporting. Clinician tokens anywhere in the file suppress t…

Who it applies to

  • Duty falls on: insurer, organization
  • Sectors: insurance, healthcare
  • Health benefit plan providers (entities issuing, delivering or renewing health benefit plans in Alabama, including insurers, HMOs, nonprofit health care services plans and nonprofit agricultural organizations offering health benefits, their internal utilization review units, and separate entities performing utilization review as their contractors or agents) that use artificial intelligence to make medical-necessity determinations on prior-authorization requests. In force 2026-10-01.
  • Not covered:
    • Plans that are not 'health benefit plans': accident-only, specified disease, individual hospital indemnity, credit, dental-only, Medicare supplement, long-term care, disability income or other limited benefit policies, and coverage supplemental to liability, workers' compensation or automobile medical payment insurance (SB 63 sec. 1(a)(5)b)
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Route every adverse outcome an AI or algorithm proposes in utilization review to a qualified clinical reviewer, and issue a denial only from that reviewer's recorded decision.

At the point where a model, rules engine or scoring tool returns its result for a prior-authorization, concurrent or retrospective review, the code may auto-approve (where the law allows) or route the case, but any result that would deny, delay, modify or downgrade the request is written as a pending clinical review (status 'pending_clinical_review', a review_queue entry with the tool's output attached as a recommendation), never as the determination. Only a review action by an authenticated reviewer whose role is physician, clinical peer or qualified reviewer, in the same or a similar specialty where the law requires, can set an adverse status; that action records reviewer_id, licence and specialty, the clinical documents opened, the decision and its clinical rationale, and the timestamp, and the adverse-determination notice is generated from it (with the reviewer's signature or attestation where the law requires). Where a law forbids the automated system from making an adverse determination even in part (Texas), the tool's output may only approve, route or support administrative and fraud-detection work; it is not shown to the reviewer as a proposed denial.

Where it goes: 1 application source code, 2 data models, 9 AI output handling, 14 user-facing text.

Example (Python + OpenAI SDK (prior-authorization service)), before:

result = client.chat.completions.create(model=MODEL, messages=build_pa_prompt(request)).choices[0].message.content
if json.loads(result)['decision'] == 'deny':
    prior_auth.update(request.id, status='denied')
    send_denial_letter(request)

After:

result = json.loads(client.chat.completions.create(
    model=MODEL, messages=build_pa_prompt(request, record=member_clinical_record(request))).choices[0].message.content)
if result['decision'] == 'approve' and AUTO_APPROVE_ALLOWED:
    prior_auth.update(request.id, status='approved', ai_assisted=True)
else:                                   # any non-approval goes to a clinician
    review_queue.enqueue(request.id, queue='pending_clinical_review',
                         specialty=request.specialty, ai_recommendation=result)

@app.post('/reviews/{case_id}/decision')
def record_clinical_decision(case_id: str, body: Decision, reviewer=Depends(licensed_clinical_reviewer)):
    decision = clinical_decisions.create(case_id=case_id, reviewer_id=reviewer.id, licence=reviewer.licence,
                                         specialty=reviewer.specialty, documents_reviewed=body.documents,
                                         outcome=body.outcome, rationale=body.rationale)
    if body.outcome in ('denied', 'downgraded'):
        send_adverse_determination(case_id, decision=decision, signed_by=reviewer)

Control: AI or algorithm denies, delays or downgrades care in utilization review without a licensed clinical reviewer deciding. The same guard addresses 9 items with binding law in 8 jurisdictions. Engineering guidance, not legal advice.

Related incidents

No guardrail sits on this exact control; these incidents are cited by guardrails on related controls.

Rule id al-sb63.licensed-reviewer-decides-denial · review status: primary source derived

Binding law — in force

Patient data used by AI in utilization review may not be used beyond its intended and stated purpose (Alabama SB 63)

Ala. SB 63 (2026), sec. 1(c)(3) · official text · In force: applies since 1 Oct 2026 · Alabama (US-AL)

From 2026-10-01, a health benefit plan provider must ensure that patient data used in utilization review functions by artificial intelligence is not used beyond its intended and stated purpose, consistent with HIPAA (SB 63 sec. 1(c)(3)). Detect utilization-review patient data flowing to model training or fine-tuning, marketing lists or product analytics.

Trust and provenance not reviewed by a lawyer · audit-grade · source verified 3 Oct 2026 · release 2026.10.03.4
Lane
Binding law — in force In force: applies since 1 Oct 2026
Official source
Ala. SB 63 (2026), sec. 1(c)(3) · captured 3 Oct 2026 · anchor hash (SHA-256) d0ba550a2a03… · 10 more anchors in the data release
Verification
Quoted text found word for word in the captured official document (3 Oct 2026). Source last verified 3 Oct 2026: checked against the captured official document.
Data release
Data release 2026.10.03.4, data as of 3 Oct 2026, schema 0.3.9.
Legal review
Not reviewed by a lawyer. TwinEthos derived this rule from the official text it cites: treat it as research to check against that text; it is not legal advice. No TwinEthos rule has been legally reviewed yet. Open questions for counsel on this rule: 1.
Audit standard
Audit-grade: meets all 10 checks of the TwinEthos audit standard that apply to it. The audit standard is TwinEthos's own quality bar for provenance, dates, applicability, detectors, fixtures, remediation and licences; it is not a legal review.
Detectors

1 detector (code pattern), experimental: written from the rule's text and not yet measured for precision on real code, so treat a hit as a lead to verify.

Known limits:

  • Exports run from notebooks or warehouse jobs outside the repository
  • A training export may be lawful where the stated purpose and HIPAA permit it (for example quality improvement under a business associate agreement); check the documented purpose before reporting.

Who it applies to

  • Duty falls on: insurer, organization
  • Sectors: insurance, healthcare
  • Health benefit plan providers (entities issuing, delivering or renewing health benefit plans in Alabama, including insurers, HMOs, nonprofit health care services plans and nonprofit agricultural organizations offering health benefits, their internal utilization review units, and separate entities performing utilization review as their contractors or agents) that use artificial intelligence to make medical-necessity determinations on prior-authorization requests. In force 2026-10-01.
  • Not covered:
    • Plans that are not 'health benefit plans': accident-only, specified disease, individual hospital indemnity, credit, dental-only, Medicare supplement, long-term care, disability income or other limited benefit policies, and coverage supplemental to liability, workers' compensation or automobile medical payment insurance (SB 63 sec. 1(a)(5)b)
  • 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.

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 8 items with binding law in 7 jurisdictions. Engineering guidance, not legal advice.

Rule id al-sb63.patient-data-purpose-limit · review status: primary source derived

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.