| 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. By creating specific context dependent SFCU data elements like one for clinical tests, each SFCU value will be clearly independent and understood to relate only to the context defined, a test in this case. 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 Procedure SFCU is a sex category that is intended to represent the proper sex categorization that is to be applied for the specific procedure under consideration, independent of the patient gender identity or other clinical sex values that may be known about the patient. In this way the procedure can use the proper reference range, therapeutic, or diagnostic parameters appropriate for the specific clinical situation known for the patient. A procedure-specific SFCU can communicate unique organ inventory or hormonal findings by exchanging “standard” sex categories even when the system using this information does not have access to the more discrete observations or those observations are masked due to privacy concerns. Patients with organ system inventories or hormonal results that are not aligned with traditional values associated with male or female can have multiple different SFCU values depending on the SFCU context under consideration. |
| Estimated number of stakeholders capturing, accessing using or exchanging | Current systems that support Ask At Order Entry (AOE) for clinical test data capture could potentially support a procedure-specific clinical sex value. Even though an AOE value is very similar we do not know of AOE in place for procedure ordering and very few systems have implemented a procedure-specific sex for clinical use value that is persisted for reporting and understood to be a unique value for that specific procedure. In situations where unique patient characteristics are known that affect final reporting or processing, in lieu of an SFCU systems exchange a general patient sex or gender value and then modify this value if needed to properly perform or capture the result of the procedure. It is therefore clear that defining a specific data element for a clinical sex value reduces ambiguity and the risk or incorrect assumptions. |
| Link to use case project page | http://build.fhir.org/ig/HL7/fhir-gender-harmony/branches/main/health_maintanence_use_case.html |
| Use Case Description | Please review the DICOM Use Case linked below |
| Estimated number of stakeholders capturing, accessing using or exchanging | Any imaging system |
| Link to use case project page | http://build.fhir.org/ig/HL7/fhir-gender-harmony/branches/main/dicom_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 | 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. |
| 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. By not requiring those discrete observations, use of SFCU 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 |
| Evaluation Comment | Thank you for your submission. Evaluation Details: Maturity: standards technical specifications: Level 1/2 - represented by LOINC, and in FHIR R5 ballot content which is not yet published, however is undergoing ballot review at time of submission. Maturity - Current use: Level 1 Maturity - Current exchange: Level 2 Breadth of applicability: Level 2 |
Comment