Data Element

Information from the submission form
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.
Estimated number of stakeholders capturing, accessing using or exchanging 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
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.
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 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 1 - Used in limited production environments, 1 or 2 different systems
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
Evaluation Comment Thank you for your submission.

Evaluation Details:

Maturity: standards technical specifications: Level 1

Maturity - Current use: Level 1

Maturity - Current exchange: Level 2

Breadth of applicability: Level 2

Comment

Log in or register to post comments