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

Remove USCDI marker for Patient.gender

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Core (FHIR)
    • 6.1.0
    • Cross-Group Projects
    • US Core Patient Profile
    • Hide

      Decision: 

      Update our generalized approach to flagging Must Support vs Additional USCDI Requirements Obligations as follows:

      1. flag
        1. Must Support only elements
        2. Additional USCDI Requirements only elements
          1. Using the existing extension and rendering flags
            1. update extension definition to clarify that is applied only to elements that are Additional USCDI Requirements 
            2. update rendering to (Add'l USCDI)
      2. Clarify that g(10) certification merges US Core Must Support + additional USCDI elements in the USCDI Requirements section and USCDI pages.

       
      All data elements and operations indicated as “mandatory” and “must support” and Additional USCDI Requirements  by the standards and implementation specifications must be supported and are in-scope for [g(10) certification] testing.

       

      For example the patient resource

      Add'l USCDI Requirements:

       

      renderes Differential View:

       

      Background:

      IN FHIR 6.1.0, we added the Additional USCDI Requirements category to distinguish between elements that are additional Must Support requirements for certified system vs Must Support for other users of US Core profiles whose use cases may not require them.

      Since there are USCDI Data Classes without USCDI Data Elements ( e.g Immunizations, Clinical Test, Goals, Vital Signs) and  USCDI Data Classes with USCDI Data Elements (e.g, Patient, Encounter, Medications) we assigned all existing Must Support as USCDI Requirements for a single simple consistent approach.

      So currently we have two types of Must Support conformance elements

      Must Support Additional USCDI Requirement
      Yes Yes
      No Yes

       

      Our decision would replace these with two types of Must Support conformance elements

      Must Support Additional USCDI Requirement
      Yes No
      No Yes

      This does not change certification requirements or conformance requirements for US Core Profiles.  This approach would be more informative for which elements are Additional USCDI Requirements at the element level when not covered by the general US Core Must Support requirements, and it aligns closely with the Profile narrative introduction.  The reader will need to understand that both  MS and Additional USCDI Requirement are required for g(10) certification, which we will document in the Conformance rules page and USCDI page.  It does not map all USCDI elements to the US Core Profile elements, the reader must reference the USCDI mapping table for that.

       

       

       

      Show
      Decision:   Update our generalized approach to flagging Must Support vs Additional USCDI Requirements Obligations as follows: flag Must Support only elements Additional USCDI Requirements only elements Using the existing extension and rendering flags update extension definition to clarify that is applied only to elements that are Additional USCDI Requirements   update rendering to (Add'l USCDI) Clarify that g(10) certification merges US Core Must Support + additional USCDI elements in the USCDI Requirements section and USCDI pages.   All data elements and operations indicated as “mandatory” and “must support” and Additional USCDI Requirements  by the standards and implementation specifications must be supported and are in-scope for [g(10) certification] testing.   For example the patient resource Add'l USCDI Requirements:   renderes Differential View:   Background: IN FHIR 6.1.0, we added the Additional USCDI Requirements  category to distinguish between elements that are additional Must Support requirements for certified system vs Must Support for other users of US Core profiles whose use cases may not require them. Since there are USCDI Data Classes without USCDI Data Elements ( e.g Immunizations, Clinical Test, Goals, Vital Signs) and  USCDI Data Classes with USCDI Data Elements (e.g, Patient, Encounter, Medications) we assigned all existing Must Support as USCDI Requirements for a single simple consistent approach. So currently we have two types of Must Support conformance elements Must Support Additional USCDI Requirement Yes Yes No Yes   Our decision would replace these with two types of Must Support conformance elements Must Support Additional USCDI Requirement Yes No No Yes This does not change certification requirements or conformance requirements for US Core Profiles.  This approach would be more informative for which elements are Additional USCDI Requirements at the element level when not covered by the general US Core Must Support requirements, and it aligns closely with the Profile narrative introduction.  The reader will need to understand that both  MS and Additional USCDI Requirement are required for g(10) certification, which we will document in the Conformance rules page and USCDI page.  It does not map all USCDI elements to the US Core Profile elements, the reader must reference the USCDI mapping table for that.      
    • Eric Haas/Brett Marquard: 17-0-0
    • Clarification
    • Non-substantive

    Description

      In US Core, Patient.gender is marked as being a USCDI data element.  However, the USCDI Sex data element is exchanged using the US Core Sex Extension, not Patient.gender, so we should probably remove the USCDI marker from Patient.gender.

       

      The USCDI mapping page correctly references the extension, so removing this marker seems a low-ish priority to me.

       

      Related Zulip chat:  https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/gender

       

      Attachments

        Activity

          People

            Unassigned Unassigned
            cooper.thompson Cooper Thompson
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: