Reminder: Do not include any PHI or PII in Confluence. If you require 508 accessibility assistance or any other support for this system, then please send an email to onc-jira-questions@healthit.gov
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 high 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:
- Provider EHR to CBO with referral management software
- Provider EHR to SDOH Hub which functions as CBO referral management software
- CBO selected by provider
- CBO NOT selected by provider, Hub identifies best match CBO
- Patient identifies CBO, Hub monitors CBOs watching for patient to reach out for services (OOS for 360X and up to the Hubs)
- Provider EHR to SDOH Hub which makes referral to another SDOH Hub OR to CBO which uses its own referral management software
- CBO selected by provider
- CBO NOT selected by provider, Hub identifies best match CBO
- Provider EHR to SDOH Hub which makes referral to another SDOH Hub OR to CBO which uses its own referral management software
- 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
- 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)
- Requirements
- Clinical EHR has push referral capabilities with Direct Account
- CBO having software with referral management capabilities and own direct account
- Referral Initiation & Receipt
- Sending clinical EHR pushes referral to selected CBO
- Referring provider selects a specific CBO
- Unique referral ID is generated
- EHR sends HL7V2 message, per 360X IG, with structured patient demographics, and either default procedure codes:
- "Referral to assessment service," SNOMED CT 307378001
- "Referral to Social Services," SNOMED CT, 306238000
- SDOH diagnosis code, ICD-10 CM/SNOMED CT
- Referring provider sends any necessary forms or data (PDF if necessary) as applicable
- Referral received by CBO with referral management software
- 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
- If there is no auto accept of referral, then Patient eligibility is checked by CBO staff
- CBO Staff will send either an “Accept” or “Decline” response back to referring provider:
- Sending clinical EHR pushes referral to selected CBO
- Decline Referral Response:
- “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.
- Once eligibility is granted a new referral can be made (This communication is OOS for 360X)
- Accepted Referral Response:
- CBO management software pushes message back to referring provider
- “Services rendered” with SNOMED CT Procedure Code(s) that are used in the Gravity Project.
- “No Show”
- (Could there be an “opt out” possibility for providers, so they no longer receive notifications)?
- Once the patient is no longer enrolled in the program, CBO sends message to EHR
- “Services discontinued complete”
- “Services discontinued incomplete” (Referral Loop Closed).
- 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.
- CBO management software pushes message back to referring provider
- Patient is enrolled in an ongoing program (i.e., Meals on Wheels)
- Repeat steps a. i-iii - b. i-ii until services discontinued complete / services discontinued incomplete.
- Repeat steps a. i-iii - b. i-ii until services discontinued complete / services discontinued incomplete.
- One time service for patient
- CBO referral management software pushes either
- “services rendered”
- “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).
- Patient is deemed ineligible for referred services
- CBOs referral management pushes “Decline” message with reason of “ineligibility” back to referring provider’s EHR (Referral loop closed).
- Patient is referred to additional services by CBO
- No notification of additional referral
- Out of scope for 360x
- CBO referral management software pushes either
- “No Show” : Unsolicited “No Show” notification
- Patient does not go to organization for services in predetermined time frame, specific to each organization
- “No Show” message is sent to referring Provider’s EHR
- Unlike clinical 360X referrals, there is no expectation of previous appointment information being shared prior to the “No Show” notification being sent.
- 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)
- Sending clinical EHR pushes referral of a selected CBO to a Hub (unique referral ID is generated)
- Referring provider selects a specific CBO, without referral management software
- Clinical EHR has push referral capabilities to Hub
- EHR sends HL7V2 message, per 360X IG, with structured patient demographics, and either default procedure codes:
- "Referral to assessment service," SNOMED CT 307378001
- "Referral to Social Services," SNOMED CT, 306238000, and appropriate, selected SDOH diagnosis code, ICD-10 CM
- Referring provider sends any necessary forms or data (PDF if necessary) as applicable
- Receiving referral by Hub with referral management software
- 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
- Patient eligibility is checked by Hub staff
- Hub Staff will send either an “Accept” or “Decline” response back to referring provider
- Decline Referral Response:
- 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)
- 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
- Accepted Referral Response:
*Patient’s referral is pushed to the specific CBO identified by the referring provider, though Hub software
- Patient is accepted with several possible outcomes - as follows:
- CBO management software pushes message back to referring provider, through Hub software, regarding patient enrollment (need to make consistent with title)
- 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.
- (Could there be an “opt out” possibility for providers, so they no longer receive notifications)
- 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
- This closes the referral loop
- Patient is enrolled in an ongoing program (i.e., Meals on Wheels)
- One time service to be received by patient
- 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).
- Patient is deemed ineligible for referred services (Referral Loop Closed)
- CBOs referral management pushes “Decline” message with reason of “ineligibility” back to referring provider’s EHR, through Hub software
- Patient is referred to additional services by CBO
- No notification of additional referral
- Out of scope for 360x
- “No Show”
- Patient does not go to organization for services in predetermined time frame, specific to each organization
- “No Show” message is sent to referring Provider’s EHR, through Hub software
- 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
- Referring provider DOES NOT select a specific CBO, but referral to HUB includes
- SDOH ICD diagnosis code “program type”
- Unique referral ID is generated
- HL7V2 with structured patient demographics, default procedure code (306238000, SNOMED CT, Referral to Social Services and appropriate, selected SDOH ICD diagnosis code)
- Referring provider sends any necessary forms or data (PDF if necessary) as applicable
- Patient eligibility is checked by Hub staff
- Hub Staff will send either an “Accept” or “Decline” response back to referring provider
- Receiving referral by Hub with referral management software
- Decline Referral Response:
- Patient is deemed ineligible for services requested by all CBOs, per Hub. “Decline” response pushed back to referring provider’s EHR.
- 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
- Accepted Referral Response:
- Patient’s referral is pushed to the specific CBO identified by the Hub, though Hub software (several options):
- CBO management software pushes message back to referring provider, through Hub software, regarding patient enrollment (Enrollment Notice).
- 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)
- 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)
- Patient’s referral is pushed to the specific CBO identified by the Hub, though Hub software (several options):
- Patient is enrolled in an ongoing program (i.e. Meals on Wheels)
- One time service to be received by patient
- CBO referral management software pushes either a “services rendered” or a “no show” message to the referring provider, through Hub software
- A services rendered message closes the referral loop. A “No Show” message does not close the loop.
- Patient is deemed ineligible for referred services
- CBOs referral management pushes “Decline” message with reason of “ineligibility” back to referring provider’s EHR, through Hub software (Referral loop closed)
- 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”
- Patient is referred to additional services by CBO
- No notification of additional referral
- Out of scope for 360x
- CBO referral management software pushes either a “services rendered” or a “no show” message to the referring provider, through Hub software
7. “No Show”
- Patient does not go to organization for services in predetermined time frame, specific to each organization
- “No Show” message is sent to referring Provider’s EHR, through Hub software
- 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
- 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
- Follow all of the steps detailed above in “Use Case #3”
- AND Hub then sends message back to referring provider
- Additional referrals (HL7V2 message with additional Z code that the secondary referral was based on)
- 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
- Out of Scope for 360x at this time
Vassil, can you please review below content for what is duplicative and can be deleted?
Gravity Project | 360x SDOH | Comments/Difference |
---|---|---|
SDOHCC Goal (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Goal) | 360x does not provide related goal information as part of the referral. | Out of Scope for 360x because 360x focuses on only referral process. |
SDOHCC Task for Referral Management | 360x uses HL7v2 Messages to update the status of the referral. The ORC segment is the part of the HL7v2 message most similar the FHIR Task. ORC uses two fields to update the state: Status, Business Status (which is use case specific) and Reason. | FHIR & Gravity Project uses Task for workflow Management with unique value sets for Task Status and ServiceRequest Status. The "Focus," of the Task, what the Task is acting on is the ServiceRequest. Whereas the status of the ServiceRequest is controlled by the initiator of that ServiceRequest, the status of the Task is controlled by the "Owner," of the task, the person responsible for carrying it out. |
ServiceRequest.Category:SDOH - Referrals are categorized by SDOH Category Domain Request.status - draft | active | on-hold | revoked | completed | entered-in-error | unknown ServiceRequest.intent - proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option ServiceRequest.priority - routine | urgent | asap | stat | The OBR Code in the HL7v2 message most closely relates to FHIR ServiceRequest. Initially 360x will limit: a) Requester to Practitioner and Practitioner Role. b) Performer limited to Organization or HealthcareService References. | FHIR ServiceRequests can be made of a much wider variety of "Performers": Reference(HealthcareService | Device | RelatedPerson | US Core Patient Profile | US Core Practitioner Profile | US Core PractitionerRole Profile | US Core Organization Profile | US Core CareTeam Profile) |
SDOHCC Task for Patient (https://build.fhir.org/ig/HL7/fhir-sdoh-clinicalcare/StructureDefinition-SDOHCC-TaskForPatient.html) - Task for Patient provides workflow management data for patient communication and specifies codes describing the type of task: Make Contact, Review Material, General Information, Complete Questionnaire. | Patient communications is out of scope for 360x. | A 360x referral can specify the requirement that a patient task needs to be completed. This could take the form of Gravity Project's Task for Patient Codes, or as part of the V2 message the questions and answers can be specified as "order specific questions." The referral recipient can document the outcome of any patient specific task with: (1) Gravity Project's Task for Patient Codes–Make Contact, Review Material, General Information, Complete Questionnaire, or (2) documented responses to the Order Specific Questions. |
US Core Patient Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient) | Primary Language - Supported PID-15 - HL7v2 Message | Gravity Project uses FHIR US Core language - The language which can be used to communicate with the patient about his or her health. |
SDOHCC Procedure ( http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Procedure) | The OBR Code in the HL7v2 message most closely relates to the FHIR Procedure. This can include the very same SNOMED CT Procedure Codes that are used in the Gravity Project. | Both standards use the same SNOMEDCT codes. Gravity uses the FHIR Procedure resource, whereas 360x uses the HL7v2 message to update the status of the referral with the requisite codes. |
US Core Location Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-location) | Organization of the referral initiator provided in HL7v2 message. Referral Recipient Location fetched from relationship between organization and location from Direct Directory. Direct Addresses can be location specific. There is a "System" and "Facility" in a message header. | managingOrganization - Organization responsible for provisioning and upkeep |
The closest equivalent to PractitionerRole in 360x is the ability of a direct address to be associated with a Practitioner. However PractitionerRole is not required in 360x. | Gravity's FHIR standard supports a more flexible definition of PractitionerRoles. It could also enable referrals to Practitioner/Organization referral recipients using PractitionerRole.endpoint where a FHIR or Direct address may be represented. | |
US Core Practitioner Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitioner) - basic demographics and other administrative information about an individual practitioner. | The Direct Address and the NPI provide equivalent of Practitioner and PractitionerRole for sender. Referral recipient corresponds to Organization, ParctitionerRole not required. | 360x does not support Practitioner. |
US Core Organization Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-organization) | 360x Referrals are made to organizations. Direct Address serves as identifier for the organization. Organizations have ORG_SPEC and Individuals with Direct Addresses have PROV_SPEC_CODE (NUCC Codes) that describe these services. | Both standards need a standard for Organization Matching. For example, Employer ID Number and address of the organization/location. |
SDOHCC HealthcareService (https://build.fhir.org/ig/HL7/fhir-sdoh-clinicalcare/StructureDefinition-SDOHCC-HealthcareService.html) | 360x requires a Direct Address and doesn't specify whether the referral is going to a HealthcareService, Organization or PractitionerRole. Often Direct is implemented by using one address for scheduling all services and others have departmental Direct Addresses. Others have Direct Addresses on the facility level. Multiple facilities may even use the same Direct Address. | FHIR HealthcareService provides the ability to represent much more diverse set of data, which is not available in the Direct Directory: Language, Coverage Area, Eligibility and Characteristic to name a few. |
US Core CareTeam Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-careteam) | The primary care physician is the point of contact for the patient's care and it is out of scope for how the Care Team is updated about the referrals. | Gravity requires CareTeam and 360x does not support it. |
SDOHCC Condition (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Condition) Conditions are Categorized by SDOH Domain | Use Health Concern/Diagnosis ICD-10 as reason for referral with the option of SNOMED-CT Codes as the Service | Both standards use the same Health Concern/Diagnosis codes. |
SDOHCC Observation Screening Response (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ObservationScreeningResponse) | Out of Scope for 360x because 360x focuses on only referral process. | |
Out of Scope for 360x because 360x focuses on only referral process. | ||
SDOHCC Consent (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Consent) | Out of Scope for 360x because 360x focuses on only referral process. Sharing referral data falls under HIPAA Treatment Payment and Operations. | 360x is providing minimal necessary data on patients. Gravity's FHIR specification requires consent to be shared under the "Coordination Platform Capability Statement." |
Gravity Project Clinical Care IG Value Sets
- Task for Referral Management
- Task.priority
Code | Display | Definition |
routine | Routine | The request has normal priority. |
urgent | Urgent | The request should be actioned promptly - higher priority than routine. |
asap | ASAP | The request should be actioned as soon as possible - higher priority than urgent. |
stat | STAT | The request should be actioned immediately - highest possible priority. E.g. an emergency. |
- TaskStatus
Code | Display | Definition | Canonical Status |
draft | Draft | The task is not yet ready to be acted upon. | ~draft |
requested | Requested | The task is ready to be acted upon and action is sought. | ~requested |
received | Received | A potential performer has claimed ownership of the task and is evaluating whether to perform it. | ~received |
accepted | Accepted | The potential performer has agreed to execute the task but has not yet started work. | ~accepted |
rejected | Rejected | The potential performer who claimed ownership of the task has decided not to execute it prior to performing any action. | ~declined |
ready | Ready | The task is ready to be performed, but no action has yet been taken. Used in place of requested/received/accepted/rejected when request assignment and acceptance is a given. | ~on-target |
cancelled | Cancelled | The task was not completed. | ~abandoned |
in-progress | In Progress | The task has been started but is not yet complete. | ~active |
on-hold | On Hold | The task has been started but work has been paused. | ~suspended |
failed | Failed | The task was attempted but could not be completed due to some error. | ~failed |
completed | Completed | The task has been completed. | ~complete |
entered-in-error | Entered in Error | The task should never have existed and is retained only because of the possibility it may have used. | ~error |
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:
- Overall purpose of the request (XD metadata)
content type code: 57164-6 LOINC - Specific purpose of the request (ORC/OBR order code)
Gravity/ Snomed referral - Reason for referral
Food insecurity determination: ICD-10-CM: Z59. 4
Pre-Diabetes: R73. 03 - 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
- Send referral
- Patient Demographics
- Individual and organization making the referral
- Unique referral and patient ID
- Food Insecurity Risk Assessment Questions and Responses approved by LOINC (e.g. Hunger Vital Signs or PRAPARE)
- SDOH need identified
- Health Concerns (e.g. unable to obtain adequate food) - automatically generated based on Assessment questions and responses that are filled out by patient
- Diagnosis (Requires Clinician Decision)
- 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.)
- Optional data and documentation as needed
- Assessment of goals
- Intervention (USCDI Level 2) - could be requested by healthcare provider or submitted with referral request
- Education about Supplemental Nutrition Assistance Program
- Education about food pantry program
- Evaluation of eligibility for food pantry program
- Evaluation of eligibility for Supplemental Nutritional Assistance Program
- Provision of Food
- Assistance with application for Supplemental Nutrition Assistance Program
- Referral to food pantry program
- 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.