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

Streamline representation of SDOH screening instruments

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Published (View Workflow)
    • Medium
    • Resolution: Persuasive with Modification
    • US Core (FHIR)
    • 4.0.0
    • Cross-Group Projects
    • (NA)
    • 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. It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile. These observations are distinct from observations representing individual clinical assessments made by an individual about a patient’s social history and not derived from an assessment tool or survey. These types of observations should use the US Core Social History Assessment Observation Profile instead.

      ...

      Each Observation must have:

      1. a status
      2. a category code of ‘survey’
      3. a LOINC code, if available, which tells you the survey question
      4. a patient

      Each Observation must support:

      1. a time indicating when survey was taken
      2. who answered the questions
      3. the answer or a reason why the data is absent*
        • if the result value is a numeric quantity, a standard UCUM unit is required
      4. related questionnaire responses or observations that this observation is made from
      5. component results

      US Core is a jurisdictional Implementation Guide whose stated goal is to defines the minimum set of constraints on the FHIR resources to create the US Core Profiles. It also defines the minimum set of FHIR RESTful interactions for each of the US Core Profiles to access patient data. In line with those goals this profile represents the SDOH Assessment data element in part as responses to survey instruments such as a form or questionnaire like PRAPARE or Hunger Vital Signs and others as individual question/answer pair or question/multiselect answers. As the commenter correctly points out it *does not* retain the context or the form's structure via grouping elements such as `hasMember`.

      Additionally 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. Other options were considered.

      Prior Art

      Since 2016 the Structured Data Capture Implementation Guide is the authoritative guide on how to provide the infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR using forms and questionnaires. It include detailed guidance on using Questionnaires and QuestionnaireAnswers and turning completed forms into a FHIR resource or Bundle of FHIR resources for subsequent analysis.

      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.

      Reasoning

      We admit there is limited testing and real world experience is lacking so either approach is untested.

      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)

      Proposed Changes

      For US Core it was decided to represent surveys/assessments using Observations and optionally QuestionnaireResponse. Specifically For Observations to represent multi-question SDOH surveys and “check all that apply” questions by referencing individual response using the 'hasMember` element.

      (The full draft proposal can be seen is archived below as attachment)

      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. It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile. These observations are distinct from observations representing individual clinical assessments made by an individual about a patient’s social history and not derived from an assessment tool or survey. These types of observations should use the US Core Social History Assessment Observation Profile instead. ... Each Observation must have: a status a category code of ‘survey’ a LOINC code, if available, which tells you the survey question a patient Each Observation must support: a time indicating when survey was taken who answered the questions the answer or a reason why the data is absent* if the result value is a numeric quantity, a standard UCUM unit is required related questionnaire responses or observations that this observation is made from component results US Core is a jurisdictional Implementation Guide whose stated goal is to defines the minimum set of constraints on the FHIR resources to create the US Core Profiles. It also defines the minimum set of FHIR RESTful interactions for each of the US Core Profiles to access patient data. In line with those goals this profile represents the SDOH Assessment data element in part as responses to survey instruments such as a form or questionnaire like PRAPARE or Hunger Vital Signs and others as individual question/answer pair or question/multiselect answers. As the commenter correctly points out it * does not * retain the context or the form's structure via grouping elements such as `hasMember`. Additionally 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. Other options were considered. Prior Art Since 2016 the Structured Data Capture Implementation Guide is the authoritative guide on how to provide the infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR using forms and questionnaires. It include detailed guidance on using Questionnaires and QuestionnaireAnswers and turning completed forms into a FHIR resource or Bundle of FHIR resources for subsequent analysis. 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. Reasoning We admit there is limited testing and real world experience is lacking so either approach is untested. 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 ) Proposed Changes For US Core it was decided to represent surveys/assessments using Observations and optionally QuestionnaireResponse. Specifically For Observations to represent multi-question SDOH surveys and “check all that apply” questions by referencing individual response using the 'hasMember` element. (The full draft proposal can be seen is archived below as attachment)
    • Floyd Eisenberg / Bob Dieterle: 8-0-2
    • Enhancement
    • Compatible, substantive

    Description

      http://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-observation-screening-response.html proposes an approach that decomposes SDOH responses into unordered bags of Question/Answer pairs, providing grouping only for “select-many” questions like “check all that apply”. 

      If we’re going to use Observations here, we might as well model a screening instrument with a top-level code for the instrument (e.g., Observation.code of https://loinc.org/93025-5 for PRAPARE), and use components for each question/repetition. That allows a full set of responses to be conveyed together as a unit, rather than breaking it up by question – this way you don’t have to guess or do timestamp-based matching to re-assemble the parts. Another benefit is we avoid confusion about whether to look at the top level vs “inside” for answers. Even if only a single question is used, this pattern allows search by top-level instrument that the question came from, or by component code for the specific question.

      Alternatively we could follow the pattern in FHIR’s vital signs profiles and use a single grouping Observation with hasMember.

      Either of these approaches would provide better context for the individual parts of a single screening instrument.

       

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              jmandel Josh Mandel
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: