Introduction

A body of evidence demonstrates social risk correlated to health issues, utilization and outcomes.  360X, building on the work of the Gravity Project (https://www.hl7.org/gravity/) and prior 360X IHE approved standards seeks to develop a closed loop referral specification for SDoH referrals.   The goal will be to once again use ubiquitously adopted technology to have a low development bar and to promote immediate adoption.

Use Cases

Example: Food Insecurity

Patient is 35-year-old single mother.  She is in an encounter with her PCP for follow up for multiple medical conditions.

Due to the COVID 19 Pandemic, patient has been laid off from her job.  She filed for unemployment benefits over a month ago but has yet to receive a check.  She spent the last of her savings paying the rent and reports to her doctor that she is almost completely out of food for herself and her family.  She was counting on her daughter having at least one meal at school during the week, but the school opening has been continually delayed.  She tells her doctor that she is ashamed but brought it up as she hoped that her provider might have some recommendations.  The patient is clearly distraught and depressed.  Her doctor documents the patient’s food insecurity in the EHR and arranges for the patient to be seen immediately by the care coordinator in the office. 

The care coordinator gives the patient an address of a nearby church that provides meals and also refers the patient to the local food bank.  In their state the food bank requires that the patient is Supplemental Nutrition Assistance Program eligible.  The care coordinator has the patient complete a SNAP form which is saved in the EHR as a PDF.  The care coordinator, using 360X refers the patient to the foodbank and includes the PDF of the SNAP form.

On receipt of the 360X referral and SNAP form, the foodbank responds with an “accept” patient.  The following day, when the patient arrives to collect food, the foodbank sends a notification to the PCP that the patient received services.

Example: Diabetic Prevention Referral

Patient is a 49-year-old woman with obesity, hypertension and hyperlipidemia at hUigh risk for developing type II diabetes.  During a telehealth encounter (planned remote encounter due to the pandemic) with her primary care physician (PCP)  where they discuss her risks for developing Type II Diabetes and her difficulties in maintaining a healthy lifestyle on her own.  She recognizes her risk and agrees to a referral to the YMCA Diabetic Prevention Program offered at the local YMCA.  These meetings are currently being held remotely via “Zoom” also due to the pandemic.

Her doctor documents the patient’s referral in the EHR and arranges for the patient to be seen immediately by the care coordinator in the office. 

The care coordinator reviews the program elements with the patient and completes the YMCA Diabetes Prevention Program Intake Form with the patient, which is then saved in the EHR as a PDF.  The care coordinator, using 360X, electronically refers the patient to the YMCA Program, nearest to the patient’s home (anticipating that eventually the meetings may be in-person, rather than remote), and includes the PDF of the YMCA Diabetes Prevention Program Intake Form.

On receipt of the 360X referral and YMCA Diabetes Prevention Program Intake Form, the YMCA Diabetes Prevention Program responds with an “accept” patient, along with the start date of the next program (program’s run for a full year period).  When the patient logs in to the “Zoom” meeting for the first session of the program, the YMCA program sends a notification to the PCP that the patient has started the program. 

Example: San Francisco YMCA Diabetes Prevention Program Intake Form (see below):

360x SDOH Referral

Use Cases:

1. Provider EHR to CBO with referral management software
2. Provider EHR to SDOH Hub which functions as CBO referral management software
1. CBO selected by provider
2. CBO NOT selected by provider, Hub identifies best match CBO
3. Patient identifies CBO, Hub monitors CBOs watching for patient to reach out for services (OOS for 360X and up to the Hubs)
3. Provider EHR to SDOH Hub which makes referral to another SDOH Hub OR to CBO which uses its own referral management software
1. CBO selected by provider
2. CBO NOT selected by provider, Hub identifies best match CBO
4. Provider EHR to SDOH Hub which makes referral to another SDOH Hub OR to CBO which uses its own referral management software
5. Provider EHR to SDOH Hub which identifies additional SDOH needs of the patient and makes additional referrals to CBO(s) beyond the one requested by the provider
6. Self-referrals by patient outside of any clinical context - Out of Scope

Use Case #1 - Provider EHR to Identified CBO with Referral Management Software (Most Simple EHR Requirements)

1. Requirements
   1. Clinical EHR has push referral capabilities with Direct Account
   2. CBO having software with referral management capabilities and own direct account
       
2. Referral Initiation & Receipt
   1. Sending clinical EHR pushes referral to selected CBO
      1. Referring provider selects a specific CBO
      2. Unique referral ID is generated
      3. EHR sends HL7V2 message, per 360X IG, with structured patient demographics, and either default procedure codes:
         1. "Referral to assessment service," SNOMED CT 307378001
         2. "Referral to Social Services," SNOMED CT, 306238000
         3. SDOH diagnosis code, ICD-10 CM/SNOMED CT
      4. Referring provider sends any necessary forms or data (PDF if necessary) as applicable 
         
         
   2. Referral received by CBO with referral management software
      1. It is possible for the CBO system to automatically accept (CBO open to all comers) or decline (CBO has no capacity for additional clients for services) a referral
      2. If there is no auto accept of referral, then Patient eligibility is checked by CBO staff
      3. CBO Staff will send either an “Accept” or “Decline” response back to referring provider: 
         
         
3. Decline Referral Response:
   1. “Decline” response pushed back to referring provider’s EHR
   2. Following decline response, further communication between referring provider, patient and CBO may be required for eligibility.
   3. Once eligibility is granted a new referral can be made (This communication is OOS for 360X)
      
      
4. Accepted Referral Response:
   
   1. CBO management software pushes message back to referring provider
      1. “Services rendered” with SNOMED CT Procedure Code(s) that are used in the Gravity Project.
      2. “No Show”
      3. (Could there be an “opt out” possibility for providers, so they no longer receive notifications)? 
   2. Once the patient is no longer enrolled in the program, CBO sends message to EHR
      1. “Services discontinued complete”
      2. “Services discontinued incomplete” (Referral Loop Closed).
   3. Initiator systems (clinical EHRs) will develop workflow and GUI based on their client feedback.  Directing EHRs on workflow following receipt of these exchanges is OOS for 360X.
      
      
5. Patient is enrolled in an ongoing program (i.e., Meals on Wheels)
   1. Repeat steps a. i-iii - b. i-ii until services discontinued complete / services discontinued incomplete.
      
      
6. One time service for patient
   1. CBO referral management software pushes either
      1. “services rendered”
      2. “no show” via HL7v2 message which includes OBR/OBX segment that can include a SNOMED CT Procedure Codes to the referring provider (Referral loop closed).
   2. Patient is deemed ineligible for referred services
      1. CBOs referral management pushes “Decline” message with reason of “ineligibility” back to referring provider’s EHR (Referral loop closed).
   3. Patient is referred to additional services by CBO
      1. No notification of additional referral
      2. Out of scope for 360x
         
         
7. “No Show” : Unsolicited “No Show” notification
   1. Patient does not go to organization for services in predetermined time frame, specific to each organization
   2. “No Show” message is sent to referring Provider’s EHR
   3. Unlike clinical 360X referrals, there is no expectation of previous appointment information being shared prior to the “No Show” notification being sent.
   4. This does not close the referral loop

*In all scenarios above - patient matching is done through 360x unique referral ID 

Use Case #2 - Provider EHR to SDOH Hub which functions as CBO referral management software for CBO without its own software

(This might be rolled into USE CASE #1)

1. Sending clinical EHR pushes referral of a selected CBO to a Hub (unique referral ID is generated)
   1. Referring provider selects a specific CBO, without referral management software 
   2. Clinical EHR has push referral capabilities to Hub 
   3. EHR sends HL7V2 message, per 360X IG, with structured patient demographics, and either default procedure codes:
      1. "Referral to assessment service," SNOMED CT 307378001
      2. "Referral to Social Services," SNOMED CT, 306238000,  and appropriate, selected SDOH diagnosis code, ICD-10 CM
   4. Referring provider sends any necessary forms or data (PDF if necessary) as applicable 
      
      
2. Receiving referral by Hub with referral management software
   1. It is possible for the Hub to automatically accept (CBO open to all comers) or decline (CBO has no capacity for additional clients for services) a referral
   2. Patient eligibility is checked by Hub staff
   3. Hub Staff will send either an “Accept” or “Decline” response back to referring provider
      
      
3. Decline Referral Response:
   1. Patient is deemed ineligible for services requested by all CBOs, per Hub. “Decline” response pushed back to referring provider’s EHR. Following decline response further communication between referring provider, patient and CBO may be required for eligibility and once eligibility is granted a new referral can be made. (This communication is OOS for 360X)
   2. If Hub finds patient ineligible for specific CBO that provider identified, but identifies CBO where patient is eligible - this will trigger one of the “Accepted” response below with message/correction of newly identified CBO
      
      
4. Accepted Referral Response:

*Patient’s referral is pushed to the specific CBO identified by the referring provider, though Hub software

1. Patient is accepted with several possible outcomes - as follows:
   1. CBO management software pushes message back to referring provider, through Hub software, regarding patient enrollment (need to make consistent with title)
   1. CBO referral management software pushes “services rendered” or  “no show” messages, through Hub software, in ongoing fashion that can include SNOMED CT Procedure Code(s) that are used in the Gravity Project.
   2. (Could there be an “opt out” possibility for providers, so they no longer receive notifications) 
   2. Once the patient is no longer enrolled in the program, CBO marks the patient as “services discontinued complete” or “services discontinued incomplete”  which pushes a message to the provider's EHR, through Hub software
   3. This closes the referral loop
1. Patient is enrolled in an ongoing program (i.e., Meals on Wheels)

• One time service to be received by patient

1. 1. 1. CBO referral management software pushes either a “services rendered” or a “no show” message to the referring provider, through Hub software that can include SNOMED CT Procedure Code(s) that are used in the Gravity Project. (Referral loop closed).
   2. Patient is deemed ineligible for referred services (Referral Loop Closed)
      1. CBOs referral management pushes “Decline” message with reason of “ineligibility” back to referring provider’s EHR, through Hub software
   3. Patient is referred to additional services by CBO
      1. No notification of additional referral
      2. Out of scope for 360x

• “No Show”

1. Patient does not go to organization for services in predetermined time frame, specific to each organization
2. “No Show” message is sent to referring Provider’s EHR, through Hub software
3. This does not close the referral loop

*In all scenarios above - patient matching is done through 360x unique referral ID 

Use Case #3 - Provider EHR to SDOH Hub, without a specific CBO selected 

1. Referring provider DOES NOT select a specific CBO, but referral to HUB includes
   1. SDOH ICD diagnosis code “program type” 
   2. Unique referral ID is generated
   3. HL7V2 with structured patient demographics, default procedure code (306238000, SNOMED CT, Referral to Social Services and appropriate, selected SDOH ICD diagnosis code)
2. Referring provider sends any necessary forms or data (PDF if necessary) as applicable
   1. Patient eligibility is checked by Hub staff
   2. Hub Staff will send either an “Accept” or “Decline” response back to referring provider
   3. Receiving referral by Hub with referral management software
      
      
3. Decline Referral Response:
   1. Patient is deemed ineligible for services requested by all CBOs, per Hub. “Decline” response pushed back to referring provider’s EHR. 
   2. This communication is OOS for 360X: Following decline response further communication between referring provider, patient and CBO may be required for eligibility and once eligibility is granted a new referral can be made
      
      
4. Accepted Referral Response:
   1. Patient’s referral is pushed to the specific CBO identified by the Hub, though Hub software (several options):
      1. CBO management software pushes message back to referring provider, through Hub software, regarding patient enrollment (Enrollment Notice).
      2. CBO referral management software pushes “services rendered” or “no show” messages, through Hub software, in ongoing fashion (any “opt out” for providers viewing these messages is OOS for 360X, but might be configurable for the provider in her/his EHR)
      3. Once the patient is no longer enrolled in the program, CBO marks the patient as “services discontinued complete” or “services discontinued incomplete”  which pushes a message to the provider's EHR, through Hub software (Referral loop closed)
         
         
5. Patient is enrolled in an ongoing program (i.e. Meals on Wheels)
   
   
6. One time service to be received by patient

1. 1. CBO referral management software pushes either a “services rendered” or a “no show” message to the referring provider, through Hub software
      1. A services rendered message closes the referral loop.  A “No Show” message does not close the loop.
   2. Patient is deemed ineligible for referred services
      1. CBOs referral management pushes “Decline” message with reason of “ineligibility” back to referring provider’s EHR, through Hub software (Referral loop closed)
   3. Patient is waitlisted for services (NOTE: this is only a valid option if the required services are non-urgent!) Interim notes are to be sent to initiator with required reason code of “Waitlisted”
   4. Patient is referred to additional services by CBO
      1. No notification of additional referral
      2. Out of scope for 360x

7. “No Show”

1. 1. Patient does not go to organization for services in predetermined time frame, specific to each organization
   2. “No Show” message is sent to referring Provider’s EHR, through Hub software
   3. This does not close the referral loop

*In all scenarios above - patient matching is done through 360x unique referral ID 

Use Case #4 - Provider EHR to SDOH Hub which makes referral to another SDOH Hub OR to CBO which uses its own referral management software

1. 1. Follow all of the steps detailed above in “Use Case #3”

Use Case #5 - Provider EHR to SDOH Hub which identifies additional SDOH needs of the patient and makes additional referrals to CBO(s) beyond the one requested by the provider

1. 1. Follow all of the steps detailed above in “Use Case #3”  
   2. AND Hub then sends message back to referring provider
      1. Additional referrals (HL7V2 message with additional Z code that the secondary referral was based on)
      2. Communication back to provider regarding secondary CBO referrals may require consent – we need a legal opinion on this. (Obtaining and communicating consent is OOS for 360X)

Use Case #6 Self-Referral by patient

1. Out of Scope for 360x at this time

Vassil, can you please review below content for what is duplicative and can be deleted?

http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Procedure)

Procedure.status - preparation | in-progress | not-done | on-hold 
| stopped | completed | entered-in-error | unknown

Gravity Project Clinical Care IG Value Sets

• Task for Referral Management
  • Task.priority

• • TaskStatus

task.focus - The request being actioned or the resource being manipulated by this task. (Reference Any)

Information Exchange

Initiation of Referral

• Referral Initiators
  • Ambulatory Care (e.g. Primary Care, Specialist Provider, (Care Management/Social Work - also acute))
  • Hospitals
  • Home Health Agency
  • LTPAC (e.g. Adult Day Centers, Assisted Living)

Technical Specifications

(Note: all other technical specifications from 360X not listed here would apply).

No C-CDA requirement for initial request

All necessary information is included in the HL7v2 attachment (see “what information needs to be included for Extra-Clinical Referrals” below). In this use case, any fully structured C-CDA will likely include more information than is appropriate to share.

Remove the base 360X requirement for initial referral to include a C-CDA, allow all transactions to simply include HL7v2 status messages.

Optional Initially use: the Unstructured Document Template in C-CDA (2.16.840.1.113883.10.20.22.1.10) includes structured patient demographics and allows for a variety of forms of embedded attachments (e.g. PDF, Word, gif, jpeg, tif, png, txt, rtf, html). 

If/As the C-CDA templates and SDOH standardized vocabulary improve/are adopted, related to SDOH, we can incorporate these.

Code to indicate that this is an SDOH referral

LOINC/ICD/SCT codes?

Proposal for 4 levels:

1. Overall purpose of the request (XD metadata)
   content type code: 57164-6 LOINC
2. Specific purpose of the request (ORC/OBR order code)
   Gravity/ Snomed referral
3. Reason for referral
   Food insecurity determination: ICD-10-CM: Z59. 4
   Pre-Diabetes: R73. 03
4. Expected outcome
   Gravity/Snomed provision

Note: These are not to be considered as requirements for independent data entry at each level

Direct Transport

HL7 V2 Status Messages

Standard 360X Messages, with the following constraints:

<TBD>

Unique Patient and Referral ID

Referral ID terminates when the loop is closed

What information (patient data, reason for referral, etc.) needs to be included for Extra-Clinical Referrals

All Cases: patient demographics (C-CDA and HL7v2), reason for referral (if using C-CDA Unstructured Document Template - this information would be only in an HL7v2 message), individual making the referral and organization making the referral (may be in C-CDA Unstructured Document Template and would be in HL7v2 message)

Specific Cases:  eligibility information

Potentially included as an attachment e.g. completed SNAP form as a PDF

(See the reference below to the work that BSer has done relative to this, which could be included, as necessary, as an attachment)

Clinical to Human Service Provider Referral Models

Due to the variety of human service workflows and services provided multiple referral models are needed. The following referral models differ on:

• Who selects the referral recipient within a program type (e.g. Food Pantry Program) and makes the referral: staff of the clinical provider, patient or HUB?
• When the referral recipient is selected and the referral triggered: when patient is receiving care, or after they have left the clinical provider's office?

HUB Role(s)

• Match referrals made by the clinical provider to the services provided to the patient and pass the intervention data back to the referral initiator, closing the referral loop. They act as a Master Patient/Client Index.
• They could represent a community's source of truth for community resources and could provide the referral initiator with a list of community resources.
• They support the latest standards for documenting SDOH needs, health concerns, goals and interventions (optionally)
• Within a programmatic domain where multiple Human Service Providers deliver the same service a HUB may play a role in identifying the appropriate human service provider. 
  • Managed Care Organization
  • Child Care Resource and Referral
  • HUD Coordinated Entry
  • 211
• The HUB may or may not have a web or mobile interface.

Clinical Provider or HUB Select Human Service Provider

Classic Referral

Referral is made by staff at the point of care. Referral recipient is identified by the clinical staff (optionally with consultation with the patient).

HUB Program-Selection Referral Model

Patient agrees to program intervention (e.g. Meals on Wheels). HUB decides which provider will deliver program.

Patient Selects Human Service Provider after Clinical Appointment

Classic Self-Referral

Patient is provided with a list of community resources (e.g. Food pantries), which are potential referral recipients. Patient selects the referral recipient from the list after leaving the point of care, which triggers the referral payload.

HUB Self-Referral Model

Patient is provided with a list of resources for a given program intervention and HUB is the central point of integration that closes the referral loop. There may or may not be a need for a referral payload beyond patient demographics for patient matching to close the referral loop.

Referral sent from clinical provider to HUB with intervention "Provision of Food" and program name "Food Pantry Program."

• Name of food pantry is not provided because it hasn't been selected yet.
• HUB responsible for matching the patients being checked in at program providers with the patient ID and referral IDs that had been sent with the referral from the clinician for the same type of program (e.g. Food Pantry Program").

Example of Workflow - Food Insecurity Referral to Food Pantry Use Case

1. Send referral
   1. Patient Demographics
   2. Individual and organization making the referral
   3. Unique referral and patient ID
   4. Food Insecurity Risk Assessment Questions and Responses approved by LOINC (e.g. Hunger Vital Signs or PRAPARE)
   5. SDOH need identified
      1. Health Concerns (e.g. unable to obtain adequate food) - automatically generated based on Assessment questions and responses that are filled out by patient
      2. Diagnosis (Requires Clinician Decision)
   6. Reason for referral -  Condition or Diagnosis (SNOMED CT: "Food insecurity (finding)," or ICD-10-CM: “Lack of adequate food and safe drinking water,” Z59.4.)
   7. Optional data and documentation as needed
      
      1. Assessment of goals
      2. Intervention (USCDI Level 2) - could be requested by healthcare provider or submitted with referral request
         1. Education about Supplemental Nutrition Assistance Program
         2. Education about food pantry program
         3. Evaluation of eligibility for food pantry program
         4. Evaluation of eligibility for Supplemental Nutritional Assistance Program
         5. Provision of Food
         6. Assistance with application for Supplemental Nutrition Assistance Program
         7. Referral to food pantry program 
            
            1. PDF of Program Application form

Use Cases 

Direct accounts can be created for coved and non-covered entities, but type of entity is not yet indicated in the Direct Directory.

=====================================================================

What are the necessary components for a 360X-SD implementation

Infrastructure

Direct Protocol

The initiator and recipient need to be able to use Secure Direct Messaging. Usually this means using the service of a HISP. (Expand with references).

Support for XDM payload in Direct Secure Messaging

Make sure that both the recipient and the HISP support full XDM metadata receipt and transmission.

Select appropriate architecture

In many cases the ultimate recipients of the referral may need help in using and maintaining an IT infrastructure. In such cases an intermediary or a consolidation provider may be the destination for the secure messaging, while the service providers used tools provided by the intermediary.

Format

The information about the referral is present in the transaction metadata (In XML format) and in an HL7 v2 message. Both sides will need to be able to create and process these two formats.

Context and Content

Sharing of Assessment Data

The SDOH needs of a patient are usually determined by assessments. Based on the needs that were determined, the referral request should contain the relevant questions and answers from the assessment.

Currently the 360X-SD specification states:

An important part of the assessment is the interpretation of the answers. For this, we will add the use of OBX-8 and OBX-10, Interpretation Codes and Nature of Abnormal Test respectively.

In the cases where additional assessments are done at the intermediary/consolidator or at the service provider, that information will available via the Referral Status Query.

Use standard coding systems (SNOMED-CT and ICD-10CM)

The request contains the determination of the clinician that the patient has specific needs, ranging from "Needs social services assessment" to specific services that need to be provided. In general, the needs are conveyed as "Reason for Referral" using ICD-10CM codes, while the goals/interventions are conveyed using SNOMED-CT codes.

Response to generic SDOH referrals

When the initial request is for a general service need determination, the closing of the loop can contain the results of a follow-up assessment. Further queries can be used to keep the status of the patient's social care services up to date.