TwinEthosRequest access

Control

EHR treatment-decision tool does not take the patient's recorded biological sex as an input

An algorithm or decision-assistance tool included in an electronic health record to help a practitioner make treatment decisions receives the patient's biological sex from the record's dedicated biological-sex field.

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.ehr-treatment-tool-omits-recorded-biological-sex

Reach

1items this one guard addresses
1jurisdictions 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 Texas (US-TX).

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 reviewers look for: a recorded_biological_sex / sex_at_birth column or birthsex extension in the EHR model plus a sexual development disorder field; in each treatment tool's feature builder, CDS handler or prompt, an explicit read of that field (features['biological_sex'] = patient.recorded_biological_sex, 'Biological sex (recorded): ...'); no mapping from Patient.gender or a gender-identity field into the sex input, and a no-recommendation branch when the field is empty.

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

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