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

Feedback on the inclusion of Observation.component as a Must Support element for systems to record multiple answers for a screening question in a single Observation

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • US Core (FHIR)
    • 4.1.0 [deprecated]
    • Cross-Group Projects
    • STU
    • US Core Screening Response Observation Profile [deprecated]
    • General Guidance
    • 10.122.1.1
    • Hide

      Background

      See commenters Description:

      The commenter is referring to this Observation Profile:

      Resource Profile: US Core Screening Response Observation Profile

      ...

      This profile sets minimum expectations for the Observation resource to record, search, and fetch retrieve observations that represent the questions and responses to form/survey and assessment tools such as the Protocol for Responding to and Assessing Patients’ Assets, Risks, and Experiences (PRAPARE) Survey. This profile encompasses single, multipart, and derived responses. ...

      ...

      Each Observation must have:

      1. ..

      Each Observation must support:

      1. ...
      2. component results

      Note to Balloters

      We are seeking feedback on the inclusion of Observation.component as a Must Support element for systems to record multiple answers for a screening question in a single Observation. Based on how broadly this is supported in current implementations, we may remove the constraint on Observation.component and recommend multiple Observations.

      As the commenter correctly points out it component results are marked as Must Support  to support multi-select answers.

      Prior Art

      The SDOH Clinical Care IG enables Enabling Survey Instruments by standardizing the capture, coding and output of SDOH risk surveys. This guide provide the necessary framework for preserving "the context for the individual parts of a single screening instrument." It leverages the SDC guide to extract the specific survey results into FHIR Observation and other resources.


      These design decisions were made after soliciting feedback from ONC, the Gravity project SDOH clinical Care IG development team, and feedback from EHR vendors and FindHelp.org, a provider of social service assistance tool used by several EHRs. After considering other options, the decision was made to follow these SDOH models with changes to simplify the structure terminology:

      http://build.fhir.org/ig/HL7/fhir-sdoh-clinicalcare/StructureDefinition-SDOHCC-ObservationScreeningResponse.html

       http://build.fhir.org/ig/HL7/fhir-sdoh-clinicalcare/StructureDefinition-SDOHCC-ObservationAssessment.html

      Reasoning

      Based on ONC’s objectives, The CGP WG decided these functional requirements are in scope:

      1. Every US Core system SHOULD be able to represent multi-question SDOH surveys (e.g., instruments like PRAPARE)
      1. Every US Core system SHOULD be able to represent “check all that apply” SDOH questions (e.g., “In the past year, have you or any family members you live with been unable to get any of the following when it was really needed? Check all that apply.”)

      (https://confluence.hl7.org/pages/viewpage.action?pageId=90342002)

       

      And due to implementer feedback remove the Must Support from the Observation.component element and instead represent the relationship between panels and individual questions and  multiselect questions and individual responses by referencing observations using the hasMember element.

      Proposed Changes

       See proposal for FHIR-35364

      Show
      Background See commenters Description: The commenter is referring to this Observation Profile: Resource Profile: US Core Screening Response Observation Profile ... This profile sets minimum expectations for the  Observation  resource to record, search, and fetch retrieve observations that represent the questions and responses to form/survey and assessment tools such as the  Protocol for Responding to and Assessing Patients’ Assets, Risks, and Experiences (PRAPARE) Survey . This profile encompasses single, multipart, and derived responses. ... ... Each Observation must have: .. Each Observation must support: ... component results Note to Balloters We are seeking feedback on the inclusion of Observation.component as a Must Support element for systems to record multiple answers for a screening question in a single Observation. Based on how broadly this is supported in current implementations, we may remove the constraint on Observation.component and recommend multiple Observations. As the commenter correctly points out it component results are marked as Must Support  to support multi-select answers. Prior Art The  SDOH Clinical Care IG  enables Enabling Survey Instruments by standardizing the capture, coding and output of SDOH risk surveys. This guide provide the necessary framework for preserving "the context for the individual parts of a single screening instrument." It leverages the SDC guide to extract the specific survey results into FHIR Observation and other resources. These design decisions were made after soliciting feedback from ONC, the Gravity project SDOH clinical Care IG development team, and feedback from EHR vendors and FindHelp.org, a provider of social service assistance tool used by several EHRs. After considering other options, the decision was made to follow these SDOH models with changes to simplify the structure terminology: http://build.fhir.org/ig/HL7/fhir-sdoh-clinicalcare/StructureDefinition-SDOHCC-ObservationScreeningResponse.html   http://build.fhir.org/ig/HL7/fhir-sdoh-clinicalcare/StructureDefinition-SDOHCC-ObservationAssessment.html Reasoning Based on ONC’s objectives, The CGP WG decided these functional requirements are in scope: Every US Core system  SHOULD  be able to represent multi-question SDOH surveys (e.g., instruments like PRAPARE) Every US Core system  SHOULD  be able to represent “check all that apply” SDOH questions (e.g., “In the past year, have you or any family members you live with been unable to get any of the following when it was really needed? Check all that apply.”) ( https://confluence.hl7.org/pages/viewpage.action?pageId=90342002 )   And due to implementer feedback remove the Must Support from the Observation.component element and instead represent the relationship between panels and individual questions and  multiselect questions and individual responses by referencing observations using the hasMember element. Proposed Changes  See proposal for  FHIR-35364
    • Floyd Eisenberg / Bob Dieterle: 8-0-2
    • Enhancement
    • Compatible, substantive

    Description

      Section 10.122.1.1 Mandatory and Must Support Data Elements. US Core Screening Response Observation Profile should include a MUST SUPPORT element for recording multiple answer for a screening question in a single observation. These components do not necessarily stand on their own, they are generally validated as useful only in context of the full set of components of an evaluation tool. LOINC may include a stand-alone observation that seems similar to a component of an existing evaluation tool but that is because the item is separately collected and validated. The suggestion that using multiple observations seems to contradict that concept and flatten out a purposely integrated set of questions. The result may lead to inaccurate decision making by clinicians and patients alike. Implementations should not be encouraged to break apart terminology to enable inaccurate conclusions.

      Attachments

        Activity

          People

            Unassigned Unassigned
            feisenberg Floyd Eisenberg
            Floyd Eisenberg
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: