SDOH Clinical Care
2.1.0 - STU 2.1
SDOH Clinical Care
2.1.0 - STU 2.1
SDOH Clinical Care, published by HL7 International / Patient Care. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-sdoh-clinicalcare/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
This section describes standardized social risk assessment instruments, their benefits, and how to standardize their capture, coding and output leveraging work from the Regenstrief Institute and the National Library of Medicine (NLM), SDC Questionnaire, SDC QuestionnaireResponse, and StructureMap to automate the creation of SDOHCC Observation Screening Response and SDOHCC Condition.
Social risk assessment instruments are used to gather information about social risks that can impact an individual’s health and well-being. The information collected through social risk assessment instruments can be used by providers, public health organizations, and policymakers to develop interventions and programs aimed at addressing the root causes of health disparities and improving health outcomes for individuals and communities. This IG builds on existing FHIR frameworks to generate Observations (e.g., SDOHCC Observation Screening Response) and Conditions (e.g., SDOHCC Condition) from LOINC-encoded assessment instruments for incorporation into the patient’s health record.
Assessment instruments fit into the SDOH CC Conceptual Framework which illustrates how to: 1) incorporate screening into the care process to assess health concerns and problems. 2) use this information to help the provider and patient establish goals and identify social risk-related interventions to address those goals. 3) use responses from standardized assessment instruments to drive public health analysis of aggregated data from patient populations.
The list of assessment instruments from which questions have been selected and vetted by the Gravity Project as face-valid can be found in the Social Determinants of Health Screening Assessments Value Set.
Advantages of using a standardized social risk assessment instrument include:
Leveraging Gravity-vetted, LOINC-encoded, standardized assessment instruments, and resources (described below) provided by the National Library of Medicine (NLM) should significantly advance the effort to capture and analyze information gathered from assessment instruments.
In the future, to promote interoperability, a single StructureMap instance could ideally be provided by the questionnaire steward for each standardized social risk assessment instrument to ensure consistency in the Observations and Conditions (health concerns) generated from that assessment instrument.
This IG uses the process below for implementing an assessment instrument. The process can be used for assessment instruments vetted by Gravity but can also be applied to other assessment instruments.
When an SDC Questionnaire is completed, stored as an SDC QuestionnaireResponse, and processed using a StructureMap, the resulting instances of Observation and Condition can be integrated into the clinical workflow to assist in guiding care.
Examples of these artifacts for Hunger Vital Signs and PRAPARE are listed below.
This implementation guide includes a complete example of the Hunger Vital Sign (HVS) Survey assessment instrument1 including:
This implementation guide includes a partial example of the PRAPARE Assessment Instrument2 including:
The FHIR QuestionnaireResponse and Observation resources can each be used to present data captured in an assessment instrument. Each resource has advantages and disadvantages. Although DocumentReference can also be used to exchange scanned assessment instrument forms, this IG does not expect support for this legacy approach. This IG expects that all systems can support exposing information about a completed assessment instrument in a computable way.
QuestionnaireResponse allows the precise capture of the assessment instrument version, the exact text of questions and answers presented to the individual, the order of presentation, and whether questions were skipped. Thus, QuestionnaireResponse allows an understanding of the assessment instrument logic flow, packages a point-in-time assessment into a single resource for exchange, and provides a complete and fully contextualized view of the individual’s responses.
However, QuestionnaireResponse cannot be searched based on the answers provided. For example, it is not possible to search a FHIR repository for all Hunger Vital Sign Questionnaires where Question 2 was answered “Often true”. Thus, QuestionnaireResponse is not sufficient for answers that need to be trended, used as a basis for quality measures, or otherwise searched or filtered by in a computable way. In contrast, Observation supports retrieval of specific question-answer pairs, comparison, trending, and searching or filtering. A question-answer pair represented as an Observation can be retrieved and exchanged independently. Observations can also indicate relationships to other artifacts, such as an Observation that is calculated or determined based on other Observations. However, Observations do not convey the context of the assessment instrument from which they are obtained. For example, information about the version of the instrument is not typically or computably captured, the order or presentation of questions is not captured, the exact text of questions and answers is not necessarily retained, and skipped questions are typically not represented. Determining which assessment instrument a specific Observation came from may require searching for ‘grouping’ Observations and trying to use the grouping to determine which assessment instrument the member Observations came from. An additional advantage of QuestionnaireResponse is that the content and rules can be externally defined and managed and systems capturing the data can simply render the questions and enforce the encoded rules (exact text of questions and answers is not necessarily retained). In contrast, data captured directly as Observations needs to have rules manually configured or hard-coded into the software in an application-specific manner.
Therefore, best practice is to be able to capture and share both types of representations. Use QuestionnaireResponse to represent the complete set of question-answer pairs with full context, and then expose as Observations the subset of question-answer pairs that are felt to be useful for searching, filtering, quality measures, etc. If assessment instrument results are represented only as Observation data, a grouping Observation MUST be used to convey the context of the instrument used to gather the data and all question-answer pairs from the instrument must be expressed as Observations to provide necessary context. (An example of this approach using a set of Observations from an assessment instrument, a grouping Observation, and without an associated QuestionnaireResponse can be found here.)
Where information is represented using a QuestionnaireResponse, there is no requirement that all question-answer pairs be surfaced as Observations, but any Observations that are produced SHALL include a derivation link (derivedFrom) to the QuestionnaireResponse. Key questions for deciding which question-answer pairs should be represented Observations include but are not limited to:
Even if systems have the QuestionnaireResponse, some may opt to represent all question-answer pairs as Observations while others may not find this useful and may feel it creates ‘noise’ in the EHR.
When using Questionnaire and QuestionnaireResponse to capture assessment instrument data, it is helpful to be able to automatically create any ‘relevant’ Observations from a Questionnaire without having to manually write code. Ideally, it would also help interoperability and provider burden if standardized assessment instruments incorporated rules to support the automated generation of ‘unconfirmed’ Conditions (health concerns) during this process and provided relevant ‘support’ links for a provider to easily confirm a Condition after their encounter with the patient.
There are a variety of strategies for converting QuestionnaireResponse data into other FHIR resources. This IG has adopted the map-based approach using the FHIR StructureMap resource. This approach was selected because it supports complex transformation of data and allows the conversion process between data and Questionnaire to be maintained independently. The StructureMap-based extraction mechanism (considerations, error handling and other details) is documented in the HL7 Structured Data Capture IG.
The StructureMap resource examples in this IG are generated using the FHIR Mapping Language. This language is then used to generate the StructureMap instances. Authoring the maps in a textual language is much simpler than attempting to craft the XML or JSON StructureMap instances directly. The mapping language also works regardless of the syntax used for the QuestionnaireResponse, i.e., it works the same for JSON, XML and RDF instances.
Instructions and tutorials on how to use the FHIR Mapping Language to convert and transform resources are found here. This page also includes references to existing open-source implementations that are capable of compiling mapping language instances into FHIR StructureMaps as well as being able to ‘execute’ maps - i.e., convert a QuestionnaireResponse into a transaction Bundle of other resources. Implementers are encouraged to leverage one of these existing community-developed implementations rather than creating their own. This will save work and minimize the likelihood of introducing implementation-specific errors into the transformation process.
The overall process for supporting this transformation process is therefore as follows:
Note that the creation of the mapping file and compiled StructureMap only needs to be performed once per Questionnaire. Implementers leveraging the same Questionnaire are encouraged to share the FHIR Questionnaire instance and associated StructureMap to minimize development and maintenance effort.
This guide includes examples of a Questionnaire, QuestionnaireResponse, resulting Observations and Conditions, and the StructureMap used to convert from one to the other:
The Hunger Vital Sign Survey is © 2010 Dr. Erin Hager and Dr. Anna Quigg and the Children’s HealthWatch research team, and the example is included with permission. ↩
This example comes from the national PRAPARE social determinants of health assessment protocol, developed and © 2019 by the National Association of Community Health Centers (NACHC), in partnership with the Association of Asian Pacific Community Health Organization (AAPCHO), the Oregon Primary Care Association (OPCA), and the Institute for Alternative Futures (IAF). For more information, visit www.nachc.org/prapare. It is included with permission. ↩
IG © 2021+ HL7 International / Patient Care. Package hl7.fhir.us.sdoh-clinicalcare#2.1.0 based on FHIR 4.0.1. Generated 2024-03-21
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change