Data Element
Recorded Gender for Health Insurance
Description

The recorded gender that is on file with the patient’s insurance. This recorded gender value is for administrative purposes such as patient matching and claim submissions, and is NOT appropriate for evaluating medical necessity of proposed treatment.
Submitted By: Robert McClure / MD Partners, Inc. for HL7 Gender Harmony Project
Data Element Information
Rationale for Separate Consideration This proposed health insurance data element will align with Gender Identity for many patients, however for transgender patients, the gender on file with their insurance may differ from the gender identity they prefer for general use. Having separate data elements for gender identity and the gender on file with the insurance company enables effective interoperability between providers and payers.
Also, insurance companies often have need for a sex value for evaluating medical necessity of proposed treatment. This data element is explicitly NOT for medical necessity checks. The proposed Sex for Clinical Use data elements are more appropriate for that purpose.
Use Case Description(s)
Use Case Description Today, many payers use a single sex/gender value both for patient identification and medical necessity. For transgender and intersex patients, often there are issues with using a single value for both purposes. Splitting that single sex/gender value into separate, semantically precise data elements (Recorded Gender for Health Insurance and Sex for Clinical Use) provides for more accurate communication of patient information between providers and payers.
Estimate the breadth of applicability of the use case(s) for this data element Most revenue cycle systems (including EHRs which have a rev cycle component) either have a designated sex/gender concept for billing, or employ workarounds like swapping administrative sex/gender values back and forth for the purpose of prior auth and claims submission. Nearly any exchange between billing systems and insurance claim systems for transgender or intersex patients must account for this concept today, or risk the rejection of prior authorization or claims.
Link to use case project page http://build.fhir.org/ig/HL7/fhir-gender-harmony/branches/main/health_maintanence_use_case.html
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) Many payers have their own vocabulary, often limited to just M and F. However, we recommend adopting the same value set that is used for the existing USCDIv3 Gender Identity data element. The model or template for representing this particular RSG can align with the FHIR artifact noted in the url link provided.
http://hl7.org/fhir/2022Sep/extension-individual-recordedsexorgender.html
Additional Specifications N/A
Current Use Not currently captured or accessed with an organization
Extent of exchange N/A
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) No restrictions other than changing the perceived approach to this common element.
EHR or revenue cycle systems that submit prior authorization request or claims to payers for care provided to transgender or intersex populations today either have support for this concept today (e.g., Epic), or are implementing workarounds to avoid rejections.
Restrictions on Use (e.g. licensing, user fees) None
Privacy and Security Concerns None
Estimate of Overall Burden For systems that are automatically submitting prior authorization requests and claims for transgender patients today, implementation burden will likely be low.

For systems that are using workarounds or manual workflows to handle claim submissions or rejections for transgender patients likely will experience moderate burden to implement this data element in their IT systems, but the implementation would likely reduce the burden on back office staff that are currently employing the workarounds or manual workflows for processing claim submissions or rejections.
Other Implementation Challenges Adoption of this element by governmental reporting systems.
ONC Evaluation Details
Each submitted Data Element has been evaluated based on the following 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
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 1 - Data element is captured, stored, or accessed in at least one production EHR or HIT module.
Criterion #3
Maturity - Current Exchange		 Level 2 - Data element is electronically exchanged between more than two production EHRs or other HIT modules of different developers using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 0 - Use cases apply to a limited number of care settings or specialties, or data element represents a specialization of other, more general data elements.
Evaluation Comment This data element is a component of a published Level 2 data element Recorded Sex or Gender (RSG) https://www.healthit.gov/isa/taxonomy/term/4601/level-2.

Comment

Log in or register to post comments