| Submitted By: Robert McClure / MD Partners, Inc. for HL7 Gender Harmony Project | |
|---|---|
| Data Element Information | |
| Rationale for Separate Consideration | A Sex For Clinical Use (SFCU) is intended to be a context-specific summarization of relevant clinical observations. The existing USCDI data class of SFCU that includes a general (context independent) SFCU data element is problematic because neither is context specific. A better approach is to have a context specific SFCU where the specific intended use is clear. While a “patient level” SFCU is only useful as a potential default value for use in situations where the clinical sex is needed, this type of value is currently most consistent with existing implementations. There is a need for other context specific SFCU data elements to clarify that SFCU can be included to support other data classes. Each of these unique data elements should be considered as a unique element representing a common approach. We expect industry maturity for SFCU to vary for different data classes. There is already some industry adoption of Patient SFCU. We expect Laboratory SFCU adoption may increase relatively quickly. SFCU for other data classes may require more investment by the industry to achieve maturity. Having separate data elements for the different contextual SFCUs allows the industry to advance the maturity of these contextual SFCU concepts independently. |
| Use Case Description(s) | |
| Use Case Description | The Sex For Clinical Use categorization is intended to communicate the summary sex category (such as Male or Female) that would best align with the expected observations based upon the identified observation context used to determine the value. When male or female is not a proper categorization, then “Specified” is to be used to indicate that default behavior that is safe for both male and female populations should be used, or a provider should review treatment options individually with the patient. A Patient SFCU is a sex category that is intended to represent the proper sex categorization that can be applied in most situations, but particular situations, such as a mammogram screening, may require a context-specific SFCU. |
| Estimated number of stakeholders capturing, accessing using or exchanging | Some systems (e.g., Epic) have implemented a sex for clinical use value at the patient level and that element aligns with this proposed data element. Most systems exchange a patient sex or gender value. Senders may consider that sex or gender value to be administrative, while some recipients may incorrectly assume that sex or gender value to be clinically relevant. Defining a specific data element for a clinical sex value reduces ambiguity and the risk or incorrect assumptions. We do note that this data element has not been widely implemented but is central to many use cases in clinical care and is expected to be necessary in any system that requires information on the clinical sex characteristics of a patient. |
| 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) | LOINC “Sex for clinical use” 99501-9 https://loinc.org/99501-9/ HL7 Patient SFCU extension: http://hl7.org/fhir/2022Sep/extension-patient-sexforclinicaluse.html http://hl7.org/fhir/2022Sep/extension-patient-sexforclinicaluse.html |
| Additional Specifications | Gender Harmony Logical model (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=564) Gender Harmony Implementation Guide (http://hl7.org/xprod/ig/uv/gender-harmony/2022Sep/index.html) This guide provides an approach to representing context specific SFCU in CDA, V2, and FHIR. |
| 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 Patient SFCU. |
| Number of organizations/individuals with which this data element has been electronically exchanged | 1 |
| Supporting Artifacts |
Epic currently supports exchanging a value that aligns with patient sfcu, but does this in a non standard way |
| 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 | SFCU will likely contain information with privacy concerns. But it is our expectation that contextual SFCU could achieve desired clinical outcomes without revealing discrete organ inventory and other physiological measurements for many patients, but by not requiring those discrete observations, may have a reduced privacy impact and provider documentation burden. |
| Estimate of Overall Burden | Most systems will require updates to implement the SFCU element, differentiating it by context and previously recorded Sex information. |
| 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 |
Comment