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-ballot 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 added text to the "Referral Use Care Overview" to provide guidance on how to include additional relevant information in a referral request, such as completed questionnaires, assessments, procedures, etc. We would encourage balloters to review this guidance and provide feedback.
This section describes the interactions between the actors in an SDOH referral starting both at a high-level and at the level of FHIR API calls. First, a high-level overview of the interactions is provided. This description abstracts technical details and should be accessible to the non-technical reader. For the sake of simplicity, only relationships critical to the Referral Workflow are provided. (For additional details on task status updates see Checking Task Status, and on relationships between profiles see Data Modeling Framework.)
The use cases here relate to the Gravity Use Cases. Implementers will benefit from looking at the detailed technical description of the exchange work flow for each use case, as well as the Capability Statements associated with each workflow and the conformance artifacts generally.
This implementation guide supports additional interactions with a patient/client application (on a smartphone or portal) including:
| Functional Use Case | Task.code |
Description | Actors |
|---|---|---|---|
| Complete Questionnaire Request | complete-questionnaire |
Requesting party (e.g., provider, CBO, or CP) asks a patient to complete a questionnaire. This functionality can be used to assess social risks, inform service qualification or application, indicate reasons for cancellation, or determine the patient’s view of their interaction with the CBO and whether the service provided met their needs. | , , , ![]() |
| General Information Request | general-information-request |
Requesting party sends a patient a free text question and receives a free text response. | , , , ![]() |
| Make Contact Request | make-contact-directions |
Requesting party provides contact information for the CBO (in cases where the patient does not want the CBO to initiate contact). | , , , ![]() |
| Review Material Request | review-material |
Requesting party requests that the patient review a document (usually a PDF), video, etc. | , , , ![]() |
In the examples below, it is assumed that the patient has been equipped with the patient application, and authenticated communication between the patient application and the requester has already been established. See Connecting Applications with API Data Sources for more details. The referenced data instances are all in their completed state. In practice, they would move through the state transitions indicated, with the requester initializing their input fields, and the patient completing the output fields, and updating the status.
Here we provide a detailed view of an example interaction between a patient application and a requester (provider, CBO, or CP) for the completion of a questionnaire. The example shows one of the four ways the questionnaire can be transmitted and the response received from the patient.
| # | From | Description | Instances involved |
|---|---|---|---|
| 1 | Patient | Get Task | Patient Task |
| 2 | Patient | Get Questionnaire, Questionnaire PDF, or Questionnaire URL | Questionnaire |
| 3 | Patient | Update Task (in-progress) | Patient Task with status changed |
| 4 | Patient | Post Questionnaire Response or Document Reference with Filled Out PDF | QuestionnaireResponse |
| 5 | Patient | Update Task (completed and .Output references QuestionnaireResponse) | Patient Task with status changed |
Here we provide a detailed view of an interaction between a patient application and a requester (provider, CBO, or CP) for a general information request. The example shows the patient returning an optional response.
| # | From | Description | Instances involved |
|---|---|---|---|
| 1 | Patient | Get Task | Patient Task |
| 2 | Patient | Update Task (in-progress) | Patient Task with status changed |
| 3 | Patient | Update Task (completed and .Output.value includes text of response) | Patient Task with status changed |
Here we provide a detailed view of an interaction between a patient application and a requester (provider, CBO, or CP) for providing one or more options from which to select to make contact with a service, provider or organization. The example shows the patient returning an optional response.
| # | From | Description | Instances involved |
|---|---|---|---|
| 1 | Patient | Get Task | Patient Task |
| 2 | Patient | Get Contact | HealthCareService |
| 3 | Patient | Update Task (in-progress) | Patient Task with status changed |
| 4 | Patient | Update Task (completed and .Output includes chosen contact) | Patient Task with status changed |
Here we provide a detailed view of an interaction between a patient application and a requester (provider, CBO, or CP) for providing review material.
| # | From | Description | Instances involved |
|---|---|---|---|
| 1 | Patient | Get Task | Patient Task |
| 2 | Patient | Get DocumentReference | DocumentReference |
| 3 | Patient | Update Task (in-progress) | Patient Task with status changed |
| 4 | Patient | Update Task (completed) | Patient Task with status changed |