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 |
|
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. |
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. |
||||||||||||
|
Comment