US Core Assessments Mock Up

--- tags: US Core title: US Core Assessments Mock Up --- # 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) 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.”) 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](https://build.fhir.org/ig/HL7/sdc/) and [SDOH Clinical Care](http://build.fhir.org/ig/HL7/fhir-sdoh-clinicalcare/survey_instrument_support.html) 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] 1. 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. :::info \*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: ```graphviz digraph hierarchy { nodesep=1.0 // increases the separation between nodes node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour edge [color=Blue, style=dashed] //All the lines look like this "Multi-Question Survey\nreferences individual survey responses"->{"Question 1 Response" "Question 2 Response" "Question 3 Multi-select Response 1" "Question 3 Multi-select Response 2"} // Put them on the same level } ``` 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](https://company.findhelp.com/), 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). :::info The Observations may be extracted from QuestionnaireResponse. [SDOH Clinical Care](http://build.fhir.org/ig/HL7/fhir-sdoh-clinicalcare/survey_instrument_support.html) 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](http://hl7.org/fhir/uv/sdc/3.0.0-preview/StructureDefinition-sdc-questionnaireresponse.html) 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. :::info 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 :::info 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 this 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 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 1. a category code of 'survey' 1. a [LOINC] code, if available, which tells you the survey question 1. a patient **Each Observation must support:** 1. a time indicating when survey was taken 1. 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:** - \*For responses to individual survey questions, the question is represented in `Observation.code`, and the answer in `Observation.value`. - \*For responses to multi-select or “check all that apply” questions, each response is represented as individual US Core Survey Observations. For each response, the question is represented in`Observation.code`, and the answer in `Observation.value`. - \*For multi-question surveys and assessments represented in `Observation.code`, the `Observation.value` element should be empty, and the individual survey questions represented as distinct US Core Survey Observations and referenced using `Observation.hasMember`. - See [SDOH Guidance] for how this profile *along with other Observation Profiles or alternatively QuestionnaireResponse* to is used represent SDOH assessments. - {% include obs_cat_guidance.md -%} - {% include DAR-exception.md %} <div id=my-examples /> ##### Examples 1. [10 Minute Apgar Score Panel Example](https://healthedata1.github.io/Healthedata1-Sandbox/Observation-10-minute-apgar-score-panel.html) 2. [HVS Panel Example 88121-9](https://healthedata1.github.io/Healthedata1-Sandbox/Observation-HVS-panel-example-88121-9.html) 3. [AHC-HRSN Panel Example 96777-8](https://healthedata1.github.io/Healthedata1-Sandbox/Observation-AHC-HRSN-panel-example-96777-8) 4. [PRAPARE Panel Example 93025-5](https://healthedata1.github.io/Healthedata1-Sandbox/Observation-PRAPARE-panel-example-93025-5.html)  {% include link-list.md %} ![](https://hackmd.io/_uploads/H1qTXTfzc.png) <div id=my-quickstart /> #### Quick Start {% include quickstart-intro.md %} - The syntax used to describe the interactions is described [here](general-guidance.html#search-syntax). - 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`](SearchParameter-us-core-observation-patient.html)** and **[`category`](SearchParameter-us-core-observation-category.html)** 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]) 1. **SHALL** support searching using the combination of the **[`patient`](SearchParameter-us-core-observation-patient.html)** and **[`code`](SearchParameter-us-core-observation-code.html)** 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]'}} 1. 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]) 1. **SHALL** support searching using the combination of the **[`patient`](SearchParameter-us-core-observation-patient.html)** and **[`category`](SearchParameter-us-core-observation-category.html)** and **[`date`](SearchParameter-us-core-observation-date.html)** 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`](SearchParameter-us-core-observation-patient.html)** and **[`category`](SearchParameter-us-core-observation-category.html)** and **[`status`](SearchParameter-us-core-observation-status.html)** 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]) 1. **SHOULD** support searching using the combination of the **[`patient`](SearchParameter-us-core-observation-patient.html)** and **[`code`](SearchParameter-us-core-observation-code.html)** and **[`date`](SearchParameter-us-core-observation-date.html)** 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 :::info 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 4. 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 - see [above](#my-examples) {% include link-list.md %} :::info The view below is the *Must Support* view which aggregates all the must support elements between the the US Core profiles. ::: ![](https://hackmd.io/_uploads/Sk0hNTMz9.png) ##### Quick Start Same as [above](#my-quickstart) --- ## 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.** :::info 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](http://hl7.org/fhir/uv/sdc/3.0.0-preview/StructureDefinition-sdc-questionnaireresponse.html). **Example Usage Scenarios:** The following are example usage scenarios for this 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* 1. a status 1. a patient 1. 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 1. 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](x) 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](X). #### Examples 1. [Glascow Coma Score Example](https://healthedata1.github.io/Healthedata1-Sandbox/QuestionnaireResponse-glascow-coma-score.html) 2. [Hunger Vital Sign [HVS] Example](https://healthedata1.github.io/Healthedata1-Sandbox/QuestionnaireResponse-hunger-vital-sign-example.html) 3. [AHC HRSN Screening Example](https://healthedata1.github.io/Healthedata1-Sandbox/QuestionnaireResponse-AHC-HRSN-screening-example.html) 4. [PRAPARE Example](https://healthedata1.github.io/Healthedata1-Sandbox/QuestionnaireResponse-PRAPARE-example.html) </div> {% include link-list.md %} :::info The view below is the *Must Support* view which aggregates all the must support elements between the the US Core and SDC profiles. ::: ![](https://hackmd.io/_uploads/Skxaflhxq.png) ### 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? ---

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.