US Core Assessments Mock Up

Server Can Use Multiple Observations and optionally QuestionnaireResponse to Record and Store Assessments Responses in FHIR

Background

Based on ONC’s objectives, we 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)

  2. 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.”)

To meet the requirements there are several options in FHIR. However, there is no consensus nor enough testing and production experience to decide which approach is best. For US Core it was decided to represent surveys/assessments using Observations and optionally QuestionnaireResponse. Transforming the data between them is out of scope. SDC and SDOH Clinical Care guides define how data captured in a QuestionnaireResponse can be extracted and used to create or update Observations or other FHIR resources.

Pro and Cons of Each Approach:

Criterion QuestionnaireResponse Observations
Keep related data together :heavy_plus_sign: :heavy_plus_sign: :heavy_minus_sign:
Allow queries for “All SDOH” responses :heavy_minus_sign: :heavy_plus_sign:
Allow queries about specific responses/items :heavy_minus_sign: :heavy_plus_sign: :heavy_plus_sign:
Convey details about language, source, author :heavy_plus_sign: :heavy_minus_sign:
Communicate question text :heavy_plus_sign: :heavy_plus_sign:
Communicate all answer choices :heavy_plus_sign: :heavy_minus_sign:
Minimizes changes from Jan 2022 US Core ballot :heavy_minus_sign: :heavy_minus_sign:

US Core Assessments Overview

Assessment Screenings

Assessment Screenings can represent a structured evaluation of risk (e.g., PRAPARE, Hunger Vital Sign, AHC-HRSN screening tool) for any Social Determinants of Health domain such as food, housing, or transportation security. They are often captured using a screening tool such as a survey or questionnaire. US Core provides two ways to represent SDOH assessment screening results using:

  1. Observation: [US Core Observation SDOH Assessment Profile]
  2. QuestionnaireResponse: [US Core QuestionnaireResponse Profile]

US Core Servers SHALL support [US Core Observation SDOH Assessment Profile] for SDOH Assessments and MAY support the [US Core QuestionnaireResponse Profile] for SDOH Assessments.

*Not all questions and answers in an assessment tool may or should be represented as FHIR Observations. For example, patient demographic information is best represented in the FHIR patient resource.

Additionally, the [US Core Social History Assessment Observation Profile] is for simple observations made by an individual during the course of care about a patient’s social history status. These Observation can contribute to the identification of SDOH Problems and can be the reason for SDOH Service Requests or Procedures.

Assessment Screenings Using Observations

US Core defines the [US Core Observation Survey Profile] to record responses from a survey or questionnaire for any context including SDOH. To keep related data together and preserve the survey structure, this profile can be used to represent multi-question “panels” of responses, individual responses (including multi-select or “check all that apply” responses). The figure below illustrates the relationship between the Observation “panel” and the individual Observations survey responses. Each box represents a US Core Observation Survey Profile:







hierarchy



Multi-Question Survey\nreferences individual survey responses

Multi-Question Survey
references individual survey responses



Question 1 Response

Question 1 Response



Multi-Question Survey\nreferences individual survey responses->Question 1 Response





Question 2  Response

Question 2  Response



Multi-Question Survey\nreferences individual survey responses->Question 2  Response





Question 3 Multi-select Response 1

Question 3 Multi-select Response 1



Multi-Question Survey\nreferences individual survey responses->Question 3 Multi-select Response 1





Question 3 Multi-select Response 2

Question 3 Multi-select Response 2



Multi-Question Survey\nreferences individual survey responses->Question 3 Multi-select Response 2

Note that the panels can be nested to create additional groupings of responses. See the [US Core Observation Survey Profile] profile page for detailed documentation on how the observations are linked, examples, and search requirements.

To meets the USCDI v2 requirements for SDOH Assessments, US Core defines the [US Core Observation SDOH Assessment Profile] which is derived from the [US Core Observation Survey Profile]. This profile constrains the category and terminology to SDOH and is used the same way as described above.

Assessment Codes

US Core has created the [US Core Common SDOH Assessments ValueSet] - commonly asked social questions as identified by FindHelp.org, a social service assistance tool. It also include several common SDOH panel concepts referenced in USCDI v2. This is not intend to replicate the complexities and robustness of the FHIR Questionnaire and QuestionnaireResponse resources developed for SDOH assessment screening tools and other questionnaires. The Gravity Project is working on a more comprehensive set of codes to meet these challenges (this guide may leverage that work in the future).

The Observations may be extracted from QuestionnaireResponse. SDOH Clinical Care guides define how sdoh data captured in a QuestionnaireResponse can be extracted and used to create or update Observations or other FHIR resources.

Assessment Screenings Using QuestionnaireResponse

Survey instruments may be represented by a Questionnaire including a FHIR Questionnaire. A FHIR QuestionnaireReponse captures the responses to the survey and may be stand-alone or may point to the definition of the questions in a questionnaire (typically a FHIR Questionnaire). The US Core QuestionnaireResponse Profile profile which is based on the SDC Questionnaire Response is used to capture, exchange and persist the response data. It represents the response data to the individual questions on the form and is ordered and grouped corresponding to the structure and grouping of the Questionnaire being responded to. Although QuestionnaireResponse can be searched using the standard FHIR RESTful API search parameters, individual responses are not directly searchable in QuestionnaireResponse. In order to search directly for and individual responses, they must be “parsed” into a searchable form - i.e. to a local FHIR or non-FHIR data store such as a database or FHIR Observations.

The basic workflow for the creation, discovery and retrieval and data-extraction of FHIR Questionnaire and QuestionnaireResponse is thoroughly documented in the SDC specification.

See the profile page for detailed documentation, examples and search requirements.

Option 1 (MANDATORY): Multiple Observations to Record and Store Assessments Responses in FHIR

US Core Survey Profile

This is a generic survey profiles for panels of questions and individual questions. It contains the hasMember element for referencing other Observations to represent multi-question SDOH surveys and “check all that apply” questions. This is similar with the current ballot’s 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. It can be used to represent individual responses, panels of multi-question surveys, and multi-select responses to “check all that apply” questions. 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.

Example Usage Scenarios:

The following are example usage scenarios for the US Core Survey Panel Profile:

Mandatory and Must Support Data Elements

The following data-elements must always be present ([Mandatory] definition]) or must be supported if the data is present in the sending system ([Must Support] definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The [Formal Profile Definition] below provides the formal summary, definitions, and terminology requirements.

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. the answer or a reason why the data is absent*
    • if the result value is a numeric quantity and coded quantity units are used, [UCUM] is required.
  3. who answered the questions
  4. related questionnaire responses or observations that this observation is made from
  5. reference to observations that make up this observation*

Profile specific implementation guidance:

Examples
  1. 10 Minute Apgar Score Panel Example
  2. HVS Panel Example 88121-9
  3. AHC-HRSN Panel Example 96777-8
  4. PRAPARE Panel Example 93025-5

{% include link-list.md %}

Quick Start

{% include quickstart-intro.md %}

  • The syntax used to describe the interactions is described here.
  • See the [General Guidance] section for additional rules and expectations when a server requires status parameters.
  • See the [General Guidance] section for additional guidance on searching for multiple patients.
Mandatory Search Parameters:

The following search parameters and search parameter combinations SHALL be supported:

  1. SHALL support searching using the combination of the patient and category search parameters:

    GET [base]/Observation?patient={Type/}[id]&category=http://terminology.hl7.org/CodeSystem/observation-category|{{include.category | default: '[category]'}}

    Example:

    1. GET [base]/Observation?patient=1134281&category=http://terminology.hl7.org/CodeSystem/observation-category|{include.category default: ‘[category]’}

    Implementation Notes: Fetches a bundle of all Observation resources for the specified patient and a category code = {{include.category | default: '[category]'}} ([how to search by reference] and [how to search by token])

  2. SHALL support searching using the combination of the patient and code search parameters:

    • including optional support for OR search on code (e.g.code={system|}[code],{system|}[code],...)

    GET [base]/Observation?patient={Type/}[id]&code={system|}[code]{,{system|}[code],...}

    Example:

    1. GET [base]/Observation?patient=1134281&code=http://loinc.org|{include.code1 default: ‘[code]’}
    2. GET [base]/Observation?patient=1134281&code=http://loinc.org|2339-0,http://loinc.org|{include.code2 default: ‘[code]’},{include.code3 default: ‘[code]’}

    Implementation Notes: Fetches a bundle of all Observation resources for the specified patient and observation code(s). SHOULD support search by multiple report codes. The Observation code parameter searches `Observation.code only. ([how to search by reference] and [how to search by token])

  3. SHALL support searching using the combination of the patient and category and date search parameters:

    • including support for these date comparators: gt,lt,ge,le
    • including optional support for AND search on date (e.g.date=[date]&date=[date]]&...)

    GET [base]/Observation?patient={Type/}[id]&category=http://terminology.hl7.org/CodeSystem/observation-category|{{include.category | default: '[category]'}}&date={gt|lt|ge|le}[date]{&date={gt|lt|ge|le}[date]&...}

    Example:

    1. GET [base]Observation?patient=555580&category=http://terminology.hl7.org/CodeSystem/observation-category|{include.category default: ‘[category]’}&date=ge2018-03-14T00:00:00Z

    Implementation Notes: Fetches a bundle of all Observation resources for the specified patient and date and a category code = {{include.category | default: '[category]'}} ([how to search by reference] and [how to search by token] and [how to search by date])

Optional Search Parameters:

The following search parameter combinations SHOULD be supported:

  1. SHOULD support searching using the combination of the patient and category and status search parameters:

    • including support for OR search on status (e.g.status={system|}[code],{system|}[code],...)

    GET [base]/Observation?patient={Type/}[id]&category=http://terminology.hl7.org/CodeSystem/observation-category|{{include.category | default: '[category]'}}&status={system|}[code]{,{system|}[code],...}

    Example:

    1. GET [base]/Observation?patient=1134281&category=http://terminology.hl7.org/CodeSystem/observation-category|{include.category default: ‘[category]’}&status=final

    Implementation Notes: Fetches a bundle of all Observation resources for the specified patient and category = {{include.category | default: '[category]'}} and status ([how to search by reference] and [how to search by token])

  2. SHOULD support searching using the combination of the patient and code and date search parameters:

    • including optional support for OR search on code (e.g.code={system|}[code],{system|}[code],...)
    • including support for these date comparators: gt,lt,ge,le
    • including optional support for AND search on date (e.g.date=[date]&date=[date]]&...)

    GET [base]/Observation?patient={Type/}[id]&code={system|}[code]{,{system|}[code],...}&date={gt|lt|ge|le}[date]{&date={gt|lt|ge|le}[date]&...}

    Example:

    1. GET [base]Observation?patient=555580&code=http://loinc.org|{include.code1 default: ‘[code]’}&date=ge2019-01-01T00:00:00Z

    Implementation Notes: Fetches a bundle of all Observation resources for the specified patient and date and report code(s). SHOULD support search by multiple report codes. ([how to search by reference] and [how to search by token] and [how to search by date])

:thinking_face: More? or Less?

SDC has:

Parameter Conformance Type Definition & Chaining
derived-from SHOULD reference Allows filtering for observations derived from a particular QuestionnaireResponse

{% include link-list.md %}

US Core Observation SDOH Assessment Profile

lock down the category, terminology, and reference the SDOH screening Item Profiles!

This profile is based on the US Core Observation Survey Panel Profile and sets minimum expectations for representing responses to assessment tools such as the [Protocol for Responding to and Assessing Patients’ Assets, Risks, and Experiences (PRAPARE) Survey]. It can be used to represent individual responses, panels of multi-question surveys, and multi-select responses to “check all that apply” questions. It and identifies the additional mandatory core elements, extensions, vocabularies and value sets which SHALL be present in the Observation 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.

Example Usage Scenarios:

The following are example usage scenarios for the US Core-Results profile:

  • Query for survey SDOH screening results for a patient.
  • [Record or update] SDOHscreening results results belonging to a Patient

Mandatory and Must Support Data Elements

In addition to the mandatory and must support data elements in the US Core Observation Survey Profile,The following data-elements must always be present ([Mandatory] definition]) or must be supported if the data is present in the sending system ([Must Support] definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The [Formal Profile Definition] below provides the formal summary, definitions, and terminology requirements.

Each Observation must support:

  1. a category code of ‘sdoh’
  2. an SDOH [LOINC] code, if available
  3. references to other US Core SDOH assessments

Profile specific implementation guidance:

  • See the [US Core Survey Profile] page for how to represent individual responses, panels of multi-question surveys, and multi-select responses to “check all that apply” questions.
  • See [SDOH Guidance] for how this profile along with other Observation Profiles or alternatively QuestionnaireResponse to is used represent SDOH assessments.
  • {% include DAR-exception.md %}
Examples

{% include link-list.md %}

The view below is the Must Support view which aggregates all the must support elements between the the US Core profiles.

Quick Start

Same as above

Option 2 (OPTIONAL): QuestionnaireResponse to Record and Store Assessments Responses in FHIR

US Core Questionnaire Response Profile

A FHIR [QuestionnaireReponse] captures the responses to a survey and it may be stand-alone or may point to the definition of the questions in the survey.

Surveys may be represented in various formats including FHIR [Questionnaire].

This profile sets minimum expectations for the QuestionnaireResponse resource to record, search, and fetch retrieve captures the responses to form/survey and assessment tools such as the [Protocol for Responding to and Assessing Patients’ Assets, Risks, and Experiences (PRAPARE) Survey]. It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile. This profile is based on the SDC Questionnaire Response.

Example Usage Scenarios:

The following are example usage scenarios for the US Core Questionnaire Response Profile:

  • Query for survey screening results for a patient.
  • [Record or update] screening results results belonging to a Patient

Mandatory and Must Support Data Elements

In addition to the mandatory and must support data elements in the SDC QuestionnaireResponse Profile, the following data-elements must always be present ([Mandatory] definition]) or must be supported if the data is present in the sending system ([Must Support] definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The [Formal Profile Definition] below provides the formal summary, definitions, and terminology requirements.

Each QuestionnaireResponse must have:

  1. a reference back to the assessment upon which it is based*
  2. a status
  3. a patient
  4. the date the answers were gathered

Each QuestionnaireResponse must support:

  1. a tag to indicate context like SDOH :point_left: this is like a category
  2. a practitioner who recorded the answers
  3. the questions and boolean, decimal, string, coded, and Attachment(a.k.a., binary) type answers
    • each question must have a identifier the pointing to question

Profile specific implementation guidance:

  • *The SDC profile (from which this profile is derived) focuses on the constraints appropriate to capturing the “answer(s)” to a pre-defined form and demands that the Questionnaire’s canonical URL be specified. A non FHIR form may be minimallyy represented as FHIR Questionnaire by populating only the relevant metadata and not the actual questions.

    :thinking_face: We could a) DAR it. b) use an extension that just communicates the Q’s identifier instead of canonical if that’s all there is… or b) we could abandon the SDC profile.

  • See SDOH Guidance for how this profile or alternatively Observations is used represent SDOH assessments.

  • The basic workflow for the creation, discovery and retrieval and data-extraction of FHIR Questionnaire and QuestionnaireResponse is thoroughly documented in the SDC specification.

Examples

  1. Glascow Coma Score Example
  2. Hunger Vital Sign [HVS] Example
  3. AHC HRSN Screening Example
  4. PRAPARE Example
{% include link-list.md %}

The view below is the Must Support view which aggregates all the must support elements between the the US Core and SDC profiles.

Quick Start

QuestionnaireResponse can be searched using the standard FHIR RESTful API search parameters. The associated Questionnaire may be fetched as well to provide context to the responses. for example, the Questionnaire.code can represent the overall questionnaire. (e.g., the questions and answers from the PRAPARE questionnaire represented in LOINC code 93025-5). Although chained searches to the associated Questionnaire can query QuestionnaireResponse by item, individual responses are not directly searchable in QuestionnaireResponse. In order to search directly for and individual responses, they must be “parsed” into a searchable form - i.e. to a local FHIR or non-FHIR data store such as a database or FHIR Observations (see Option 2 below).

Search Parameter Summary

Parameter Conformance Type Definition & Chaining
_id SHALL token Allows retrieving known QuestionnaireResponse records - and more specifically, retrieving more than one in a single call to poll for updates
patient SHALL reference Allows retrieving QuestionnaireResponses associated with a particular patient. Some systems may only permit searches that are patient-specific
status MAY token Allows retrieving QuestionnaireResponses that are complete (or incomplete)
_tag MAY token Allows filtering for QuestionnaireResponse that have tag of “sdoh”
authored MAY date Allows filtering for QuestionnaireResponses by when they were created/last edited
questionnaire MAY reference Allows retrieving QuestionnaireResponses that have been completed against a specified form

Search Parameter Combo Summary

Parameter combo Conformance
patient + status SHOULD
patient + _tag SHOULD
patient + authored SHOULD
patient + authored + _tag SHOULD
patient + questionnaire SHOULD

:thinking_face: More? or Less?