TwinEthosRequest access

Law

Texas SB 1188 (EHR and AI, Health & Safety Code ch. 183)

Texas Attorney General; Health and Human Services Commission and health licensing agencies · Texas (US-TX) · 3 provisions encoded · verified against the official source as of 2026-09-27.

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: capitol.texas.gov.

Binding law — in force

Texas practitioners using diagnostic AI must review every record the AI creates (Texas SB 1188)

Tex. Health & Safety Code 183.005(a) · official text · In force: applies since 1 Sep 2025 · Texas (US-TX)

Texas Health and Safety Code 183.005(a) lets a practitioner use AI for diagnostic purposes, including AI suggestions about a diagnosis or treatment course based on the patient's record, only while acting within the scope of their license, where the use is not otherwise barred by state or federal law, and if the practitioner reviews every record created with AI in line with Texas Medical Board medical-records standards. The code-visible piece is the review step: an AI-drafted note, summary, or diagnostic entry should not become part of the chart as a final record until a practitioner has reviewed it. Detect AI-generated clinical documentation or diagnostic output written to the EHR as final or signed without a recorded practitioner review.

Who it applies to

  • Duty falls on: individual professional
  • Sectors: healthcare
  • Texas health care practitioners (anyone licensed, certified, or otherwise authorized to provide health care in Texas) who use AI for diagnostic purposes, including AI recommendations on a diagnosis or course of treatment drawn from a patient's medical record; it reaches the EHR and clinical-AI software they use. Applies to EHRs prepared on or after 2025-09-01.
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Hold AI-generated clinical output as a draft until an accountable clinician reviews and signs it, and record who approved it before it reaches the chart or the patient.

A clinician sign-off step between the model call and every clinical sink: AI-drafted notes, summaries, diagnostic suggestions, triage levels, and treatment plans are stored as drafts (FHIR DocumentReference.docStatus 'preliminary', DiagnosticReport.status 'preliminary', CarePlan.status 'draft') and become final, active, or visible to the patient only through an action by an authorized clinician that records reviewed_by and reviewed_at. Configuration flags that auto-sign or auto-finalize AI-drafted records stay false, and provenance shows the AI as a contributing device and the clinician as verifier. The deployment also names who is accountable for AI-assisted decisions and gives patients a complaint or redress route.

Where it goes: 1 application source code, 2 data models, 9 AI output handling, 3 config and feature flags.

What this provision adds:

  • The practitioner reviews every record created with AI, in line with Texas Medical Board medical-records standards, before it becomes a final or signed part of the chart.
  • Apply the review gate to EHRs prepared on or after 2025-09-01.

Example (Python + OpenAI SDK + FHIR REST), before:

note = client.chat.completions.create(model=MODEL, messages=msgs).choices[0].message.content
requests.post(f'{FHIR_BASE}/DocumentReference', json=doc_ref(patient_id, note, doc_status='final'))

After:

note = client.chat.completions.create(model=MODEL, messages=msgs).choices[0].message.content
requests.post(f'{FHIR_BASE}/DocumentReference',
              json=doc_ref(patient_id, note, doc_status='preliminary'))   # AI draft

def practitioner_review_and_sign(doc_id, practitioner):   # only path to 'final'
    doc = requests.get(f'{FHIR_BASE}/DocumentReference/{doc_id}').json()
    doc['docStatus'] = 'final'
    doc['authenticator'] = {'reference': f'Practitioner/{practitioner.id}'}
    requests.put(f'{FHIR_BASE}/DocumentReference/{doc_id}', json=doc)
    audit.record(doc_id, reviewed_by=practitioner.id, reviewed_at=utcnow())

Control: Health AI without clinician oversight/accountability + redress. The same guard addresses 3 items with binding law in 2 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 tx-sb1188.ai-created-records-practitioner-review · review status: primary source derived

Binding law — in force

Texas practitioners must tell patients when they use AI for diagnostic purposes (Texas SB 1188)

Tex. Health & Safety Code 183.005(b) · official text · In force: applies since 1 Sep 2025 · Texas (US-TX)

Texas Health and Safety Code 183.005(b) requires a health care practitioner who relies on AI for diagnostic purposes, including AI recommendations on a diagnosis or treatment course drawn from a patient's record, to tell their patients that they use the technology. The statute does not prescribe the notice's form or timing, so a patient-facing statement in intake, consent, portal, or visit-summary materials is the practical evidence. Detect a diagnostic-AI path (clinical decision support, a diagnostic model, or an LLM diagnosis prompt) with no patient-facing AI-use disclosure anywhere in the product.

Who it applies to

  • Duty falls on: individual professional
  • Sectors: healthcare
  • Texas health care practitioners (anyone licensed, certified, or otherwise authorized to provide health care in Texas) who use AI for diagnostic purposes, including AI recommendations on a diagnosis or course of treatment drawn from a patient's medical record; it reaches the EHR and clinical-AI software they use. Applies to EHRs prepared on or after 2025-09-01.
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Send the person an AI-use notice on the decision path, before or when an AI system makes or substantially factors a consequential decision about them, and record its delivery.

A notice step in the decision workflow itself (application intake, underwriting, eligibility, applicant or employee scoring, diagnostic support) that runs before the model call, e.g. send_admt_notice(consumer) ahead of underwrite(), or a notice block rendered on the intake page the person submits from. The notice says that AI is used in the decision, for what, and how to get more information or ask for review, and its delivery is stored with the decision (notice id, channel, timestamp). The template lives in the repo so its content is reviewable; a privacy-policy paragraph alone is not on the decision path.

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

What this provision adds:

  • Tell patients the practitioner uses AI for diagnostic purposes, including AI recommendations on a diagnosis or course of treatment drawn from their record; form and timing are not prescribed, so intake, consent, portal, or after-visit-summary text serves.

Example (FastAPI + OpenAI SDK), before:

@app.post('/applications')
def apply(app_in: Application):
    resp = client.chat.completions.create(model=MODEL, messages=underwriting_prompt(app_in))
    return {'decision': underwrite(resp.choices[0].message.content)}

After:

@app.post('/applications')
def apply(app_in: Application):
    notice = send_admt_notice(app_in.applicant_id, template='ai_decision_notice_v2')
    resp = client.chat.completions.create(model=MODEL, messages=underwriting_prompt(app_in))
    decision = underwrite(resp.choices[0].message.content)
    db.decisions.insert(app_in.id, decision, notice_id=notice.id)
    return {'decision': decision, 'ai_notice': notice.text}

Control: Consequential AI decision without consumer notice. The same guard addresses 6 items with binding law in 5 jurisdictions. Engineering guidance, not legal advice.

Standards that recommend the same control

Rule id tx-sb1188.ai-diagnostic-use-patient-disclosure · review status: primary source derived

Binding law — in force

Treatment-decision algorithms in Texas EHRs must use the patient's recorded biological sex (Texas SB 1188)

Tex. Health & Safety Code 183.007 · official text · In force: applies since 1 Sep 2025 · Texas (US-TX)

Texas Health and Safety Code 183.007, added by SB 1188, tells the Health and Human Services Commission, the Texas Medical Board and the Texas Department of Insurance to jointly make sure of two things for electronic health records that covered entities in Texas prepare or maintain. First, the record has its own field for the patient's biological sex, entered as male or female from the sex a practitioner observed and recorded at birth, and a field for any sexual development disorder. Second, any algorithm or decision assistance tool built into the record to help a practitioner make treatment decisions takes the biological sex from that dedicated field as an input. Additional sex or gender identity fields remain allowed (183.007(b)). The statute states the duty as one the agencies must ensure; the chapter's investigation, licensing-discipline and Attorney General penalty provisions reach covered entities that violate the chapter, and how they apply here is flagged for legal review. Detect a treatment-decision tool, including an AI or LLM recommendation path, that runs on EHR patient context without the recorded biological sex or substitutes an administrative-gender or gender-identity value for it, and an EHR data model with no dedicated biological-sex field.

Who it applies to

  • Duty falls on: deployer, individual professional
  • Sectors: healthcare
  • Covered entities in Texas (including health care practitioners) whose EHRs contain an algorithm or decision assistance tool that assists treatment decisions; in practice it reaches the EHR and clinical decision-support software they use. The statute frames the requirement as something HHSC, the Texas Medical Board and TDI must jointly ensure, not as a direct command to the covered entity or its vendor. Applies to EHRs prepared on or after 2025-09-01.
  • Not covered:
    • EHRs of entities outside 'covered entity' (183.001(2)(A)-(G)): licensed home and community support services agencies, nursing facilities, continuing care facilities, assisted living facilities, intermediate care facilities, day activity and health services facilities, and TxHmL or HCS waiver providers
    • EHRs prepared before 2025-09-01 (SB 1188 Section 2(a))
    • Algorithms or tools in the EHR that do not assist a practitioner in making medical treatment decisions (183.007(a)(2) reaches only those)
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Feed every EHR treatment-decision tool the patient's sex from the record's dedicated recorded biological-sex field, never from administrative gender or gender identity.

Two parts. In the EHR data model (database schema or FHIR profile), keep a dedicated recorded biological-sex field constrained to its allowed values and a separate field for any sexual development disorder; other gender fields can sit beside them. In the input mapping of every treatment-decision tool (CDS Hooks service, risk-model feature builder, dose calculator, LLM treatment-recommendation prompt), read that dedicated field (for FHIR, the us-core-birthsex extension valueCode) and pass it explicitly. If it is missing, return no treatment recommendation and flag the record instead of falling back to Patient.gender or a gender-identity value.

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

What this provision adds:

  • The dedicated field holds male or female, entered from the sex a practitioner observed and recorded at birth; additional sex or gender identity fields may sit alongside it.

Example (Flask CDS Hooks service (FHIR)), before:

@app.post('/cds-services/dose-check')
def dose_check():
    patient = request.json['prefetch']['patient']
    sex = patient.get('gender')            # administrative gender
    return {'cards': dose_cards(sex, request.json['context'])}

After:

BIRTHSEX_URL = 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex'

@app.post('/cds-services/dose-check')
def dose_check():
    patient = request.json['prefetch']['patient']
    ext = next((e for e in patient.get('extension', []) if e['url'] == BIRTHSEX_URL), None)
    if ext is None or ext.get('valueCode') not in ('M', 'F'):
        return {'cards': [missing_recorded_sex_card()]}   # no recommendation without it
    return {'cards': dose_cards(ext['valueCode'], request.json['context'])}

Control: EHR treatment-decision tool does not take the patient's recorded biological sex as an input. The same guard addresses 1 item with binding law in 1 jurisdiction. Engineering guidance, not legal advice.

Rule id tx-sb1188.ehr-treatment-tool-biological-sex-input · review status: primary source derived