TwinEthos homeAPI access

Control

AI coverage or medical-necessity determination not based on the individual's own clinical information

An AI, algorithm or other software tool used to determine medical necessity or coverage bases each determination on the individual enrollee's medical or clinical history, the clinical circumstances the requesting provider presents and other relevant information in the enrollee's clinical record, and never solely on a group dataset (population, cohort or historical approval statistics).

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.

Family: AI is used without bias, fairness, or proxy-discrimination controls · control id cond.ai-coverage-determination-not-on-individual-clinical-data

Reach

3items this one guard addresses
3jurisdictions 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 Alabama (US-AL), California (US-CA), Maryland (US-MD).

Trust and provenance

How far the rules this guard addresses have been checked. Each rule links to its provision, with its citation, official text and its own panel.

This control
Audit-grade: meets all 3 checks of the TwinEthos audit standard that apply to it.
Lanes
Binding law — in force 3
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 3 rules 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: 3.
Audit standard
3 of 3 rules 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
3 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.

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.

What reviewers look for: in each module that sends a utilization-review case to a model or scoring tool, the member's clinical record and the provider's clinical submission in the prompt or features; no prompt or feature set built only from codes, plan data and cohort or historical statistics; a missing-clinical-input check that routes to review instead of deciding; and the inputs stored with the determination.

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

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 (3)

Related incidents

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

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.