| Submitted By: Robert McClure, MD / HL7 International | |
|---|---|
| Data Element Information | |
| Rationale for Separate Consideration | The existing USCDI Data Element “Sex (Assigned at Birth)” is is not a reliable representation of a patient gender identity, nor is it a contextually specified sex for clinical use. Additionally, many jurisdicitions allow modification of this element for other purposes so the meaning is unclear. While “Sex (Assigned at Birth)” which may, or may not be the “Gender Marker on Original Birth Certificate” (perhaps more accurately termed “assigned gender at birth”) is a common data element in a number of jurisdictions, it currently lacks a consistent definition from jurisdiction to jurisdiction and is open to clinically dangerous misuse. Therefore we recommend that it be represented as a specific RSG with the source field identifier of “Sex assigned at birth.” |
| Use Case Description(s) | |
| Use Case Description | Clinical and administrative data is filled with data fields named in some way as “sex” or “gender” that are not well defined gender identity or sex for clinical use based upon specific clinical observation. Each of these data fields, exchanged millions of times a year, are better understood as a particular recording of some value considered a representation of the patient “sex” or the patient “gender”, yet very rarely is that field a demonstratably clear SFCU or gender identity. For instance, a trans woman may be able to update her driver’s license to ‘F’ but her state might not allow changing a value on her birth certificate, which may still read ‘M’. Depending on the system or record, either of these values may be present as “sex”. Therefore what we propose is to identify all this frequenly exchanged information for what it actually is: a “recorded sex or gender” and include the clarifying information as described in the HL7 Gender Harmony informative guide . Additional information is also found in the JAMIA article discussing the project . International H. HL7® Informative Document: Gender Harmony - Modeling Sex and Gender Representation, Release 1. 2021.http://www.hl7.org/implement/standards/product_brief.cfm?product_id=564 (accessed 21 Nov 2021). McClure RC, Macumber CL, Kronk C, et al. Gender harmony: improved standards to support affirmative care of gender-marginalized people through inclusive gender and sex representation. J Am Med Inform Assn 2022;29:354–63. doi:10.1093/jamia/ocab196 |
| Estimated number of stakeholders capturing, accessing using or exchanging | This element is included in almost every clinical and administrative record. |
| Link to use case project page | https://confluence.hl7.org/display/VOC/Cross+Paradigm+Use+Cases |
| Use Case Description | Sex assigned at birth rendered as a Recorded Sex or Gender element is provided in the attached pdf |
| Estimated number of stakeholders capturing, accessing using or exchanging | The majority of patient data records currently include a sex assigned at birth RSG. |
| Supporting Attachments |
RSG SAAB example.pdf |
| Healthcare Aims |
|
| Maturity of Use and Technical Specifications for Data Element | |
| Applicable Standard(s) | LOINC “Recorded sex or gender” 99502-7 https://loinc.org/99502-7/ |
| Additional Specifications | HL7 Gender Harmony informative publication http://www.hl7.org/implement/standards/product_brief.cfm?product_id=564 |
| Current Use | In limited use in production environments |
| Supporting Artifacts |
There are systems, such as Epic, and other locally configured systems, such as at the Fenway Institute in Boston, that support an approach similar to RSG. |
| Number of organizations/individuals with which this data element has been electronically exchanged | N/A |
| Potential Challenges | |
| Restrictions on Standardization (e.g. proprietary code) | No restrictions other than changing the perceived approach to this common element. |
| Restrictions on Use (e.g. licensing, user fees) | None |
| Privacy and Security Concerns | Some RSG data items may represent PHI |
| Estimate of Overall Burden | Many systems will simply internally identify any RSG element with a tag to indicate it is an RSG and therefore should not be considered a gender identity or be used as a sex for clinical use. Implementation strategies will vary but should not be difficult once adopted. |
| Other Implementation Challenges | None |
| ONC Evaluation Details Each submitted Data Element has been evaluated based on the following 4 criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI |
|
|---|---|
| Maturity – Standards/Technical Specifications | Level 1/2 - Must be represented by a vocabulary standard or an element of a published technical specification |
| Maturity - Current Use | Level 2 - Used at scale in more than 2 different production environments |
| Maturity - Current Exchange | Level 2 - Demonstrates exchange between 4 or more organizations with different EHR/HIT systems |
| Breadth of Applicability - # Stakeholders Impacted | Level 2 - Used by a majority of patients, providers or events requiring its use |
Submitted by cmayo@med.umich.edu on 2022-09-11
Gender
The AAPM Operational Ontology for Radiation Oncology ( https://aapmbdsc.azurewebsites.net) evaluated several systems for identifying gender. HL7 Reference system was recommended. http://hl7.org/fhir/2018May/codesystem-gender-identity.html Values are transgender-female transgender-male non-binary male female other non-disclose Other systems evaluated were CDC https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.1.11.1 DICOM http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7455.html#table_CID_7455 Health IT https://www.healthit.gov/isa/representing-patient-gender-identity LOINC https://loinc.org/76691-5/