SDOH Clinical Care
3.0.0-draft -
SDOH Clinical Care, published by HL7 International / Patient Care. This guide is not an authorized publication; it is the continuous build for version 3.0.0-draft 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 |
The Gravity Project team has created a new narrative page providing guidance on the Referral for Further Assessment use case. We would encourage balloters to review this guidance and provide feedback.
This page describes the use case, actors, systems, and information flows for referring an individual for a more comprehensive assessment of their health-related social needs (HRSN).
In many clinical situations, an initial screening may indicate the presence of one or more health-related social needs, but the clinical care team may not have the time, resources, or specialized skills to perform a deeper, more comprehensive assessment. The primary goal of this use case is to enable a healthcare provider or other entity (e.g. behavioral health or other non-healthcare entity) to refer an individual to a community-based organization (CBO) or another partner organization that is equipped to conduct a more thorough assessment.
This exchange is intended to:
For example, a patient might screen positive for food insecurity. During the follow-up conversation, the healthcare provider suspects other needs may be present but lacks the capacity to investigate further. The provider can then send a "Referral for Further Assessment" to a trusted CBO to gain a more complete understanding of the individual's situation and identify appropriate services.
The actors and systems involved in this workflow are the same as those in other referral workflows described in this guide.
The technology systems involved in the exchange mirror those in the established referral workflows and may include:
The exchange flow for a referral for further assessment follows the exact same closed-loop direct, direct referral light, indirect, and indirect referral light patterns described on the Referral Workflow page. The core mechanics of creating a ServiceRequest and Task, sending the referral, and closing the loop by updating the Task remain unchanged.
The primary difference in this use case lies in the intent of the request and the nature of the result. Instead of requesting a specific service (e.g., meal delivery), the provider is requesting a comprehensive or domain-specific assessment. Consequently, when the loop is closed, the information returned in Task.output consists of the findings from that assessment in addition to a confirmation of a service provided.
While the referring provider may use these assessment results to adjust the clinical care plan, a common outcome is for the CBO to take ownership of creating a comprehensive social care plan based on the findings. This plan, potentially developed in collaboration with other social care providers, aims to help the individual achieve their goals. Before executing this plan, the CBO may need to seek authorization from the original referring entity or another responsible party to ensure reimbursement for subsequent services. In this scenario, the referring provider may be made aware of not only the assessment results but also the broader social care plan. It is important to note that sharing this information raises privacy considerations. This Implementation Guide assumes that the individual's consent and preferences are managed in accordance with all applicable policies and regulations; the specific mechanisms for managing authorization, reimbursement, and consent from a non-covered entity to a covered entity are currently out of scope for this guide.
The following diagram illustrates the indirect referral pattern as one example of this flow, highlighting where the assessment-specific details fit into the established pattern. While there are slight variations to adapt each of these flows, the general pattern is consistent. It is recognized that many CBOs may not have FHIR-enabled servers as depicted in this example. For exchanging a referral with a CBO that does not have a FHIR-enabled server, see the direct light and indirect light referral scenarios on the Referral Workflow page.
IMG
This use case employs the same core FHIR resources (ServiceRequest, Task) as other referral workflows. The key to implementing this use case is using specific elements within these resources to differentiate an assessment request and its corresponding results.
Differentiating the Assessment Referral
Two key fields distinguish this referral:
ServiceRequest.code: This field specifies that the object of the request is an assessment procedure. This CodeableConcept is what differentiates a request to "assess for food insecurity" from a request to "provide food."
Task.output: When closing the loop, this element carries the results of the assessment. The Task.output.value[x] will contain a Reference to the FHIR resource(s) that document the assessment's findings. This may include Observation Screening Responses, Questionnaire Response, Observation Assessments, Conditions, CarePlan, Goal, and Procedures.