Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-41352

Clarification on Sex vs. Birthsex

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Core (FHIR)
    • 6.1.0-snapshot1
    • Cross-Group Projects
    • US Core Birth Sex Extension
      US Core Patient Profile
      US Core Sex Extension
    • Hide
      • Certified systems must support population of USCDI v3 ‘Sex’ with a SNOMED CT concept
      • Current US core (6.0.0) does not provide a place to record ‘Sex’ with SNOMED CT
      • The updated 6.1.0 will include a new ‘Sex’ extension to allow systems to populate with a SNOMED CT concept.
      • The updated 6.1.0 will not require systems send ‘Birth Sex’. In a future release we will consider deprecating.
      • Whether system transform/copy or add a new field in their product to meet this requirement is out of scope for the US Core implementation guide.

       

      We will ensure that we are aligned with CCDA  CDA-20689 Clarification on Sex vs. Birthsex - Jira (hl7.org) and  CDA-20692 Sex Observation Purpose Statement Needs to be clearer - Jira (hl7.org).

       

      1) Here propose description for Sex:

      The Sex Extension is used to reflect the documentation of a person’s sex. Systems choosing to record sources of information should use the Provenance resource.

      USCDI v3 includes a data element for sex, intended to support the exchange of a sex value that is not characterized as sex assigned at birth or birth sex which has been identified as problematic in terms of quality and reliability. This Sex extension supports USCDI v3. Sex assigned at birth or birth sex can be recorded using the more specific Birth Sex Extension. 

      Future versions of this extension may be informed by the content of the HL7 Cross Paradigm IG: Gender Harmony - Sex and Gender Representation, which may include additional guidance on the relationship to administrative gender (Patient.gender).

       

      2) We will update the current binding to point to a new value set that is defined in THO that includes the three SNOMED codes in VSAC 2.16.840.1.113762.1.4.1099.53 value set plus 'asked-declined'.  We will ask Structured Documents to align their guidance on this.

       

      Show
      Certified systems must support population of USCDI v3 ‘Sex’ with a SNOMED CT concept Current US core (6.0.0) does not provide a place to record ‘Sex’ with SNOMED CT The updated 6.1.0 will include a new ‘Sex’ extension to allow systems to populate with a SNOMED CT concept. The updated 6.1.0 will not require systems send ‘Birth Sex’. In a future release we will consider deprecating. Whether system transform/copy or add a new field in their product to meet this requirement is out of scope for the US Core implementation guide.   We will ensure that we are aligned with CCDA  CDA-20689 Clarification on Sex vs. Birthsex - Jira (hl7.org) and  CDA-20692 Sex Observation Purpose Statement Needs to be clearer - Jira (hl7.org).   1) Here propose description for Sex: The Sex Extension is used to reflect the documentation of a person’s sex. Systems choosing to record sources of information should use the Provenance resource. USCDI v3 includes a data element for sex, intended to support the exchange of a sex value that is not characterized as sex assigned at birth or birth sex which has been identified as problematic in terms of quality and reliability. This Sex extension supports USCDI v3. Sex assigned at birth or birth sex can be recorded using the more specific Birth Sex Extension.  Future versions of this extension may be informed by the content of the HL7 Cross Paradigm IG: Gender Harmony - Sex and Gender Representation, which may include additional guidance on the relationship to administrative gender ( Patient.gender ).   2) We will update the current binding to point to a new value set that is defined in THO that includes the three SNOMED codes in VSAC 2.16.840.1.113762.1.4.1099.53 value set plus 'asked-declined'.  We will ask Structured Documents to align their guidance on this.  
    • Eric Haas / Jason Vogt : 6-0-0
    • Clarification
    • Compatible, substantive

    Description

      Based on the draft instance of the new genericized C-CDA “Sex Observation” template and FHIR US Core Patient Sex extension, our understanding is that the new template and extension are replacements for the previous “Birth Sex Observation” template and FHIR US Core Patient Sex extension. This is understood to be for the exclusive purpose of updating the code system to align with the SNOMED-CT vocabulary cited as standard in USCDI. However, and if so, that is not clear in the current drafts. If this is the intent, then that needs to be clarified by (1) deprecating the predecessor C-CDA  “Birth Sex Observation” template and FHIR US Core Patient Birth Sex extension and (2) providing additional implementation guidance clarifying that the new template/extension are a replacement and should start to be continue being used to exchange data previously exchanged with the now deprecated C-CDA “Birth Sex Observation” template and FHIR US Core Patient Sex extension but using new standard codes.

      If the intent is for the new template/extension to be additive (i.e., the C-CDA “Birth Sex Observation” template and the FHIR US Core “Patient Birth Sex” extension are not being deprecated) then that implies systems need to be recording and exchanging another sex concept that is not already covered with its own unique template/extension or field. It is unclear what concept that may be. Additionally, this intent would be misaligned with ONC’s stated intent for the USCDI “Sex” data element in the HTI-1 proposed rule where they state “We note that this is presently a change in the name of the element and will have no immediate impact on health IT developers of certified health IT, which will continue to exchange the value of patient's sex they have been historically exchanging using USCDI” (https://www.federalregister.gov/d/2023-07229/p-339). Accordingly, this would be an inappropriate direction to take with the changes.

      Attachments

        Activity

          People

            Unassigned Unassigned
            hbuitendijk Hans Buitendijk
            Hans Buitendijk
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: