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.
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):
*In all scenarios above - patient matching is done through 360x unique referral ID
*Patient’s referral is pushed to the specific CBO identified by the referring provider, though Hub software
*In all scenarios above - patient matching is done through 360x unique referral ID
7. “No Show”
*In all scenarios above - patient matching is done through 360x unique referral ID
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." |
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. |
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)
(Note: all other technical specifications from 360X not listed here would apply).
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.
LOINC/ICD/SCT codes?
Proposal for 4 levels:
Note: These are not to be considered as requirements for independent data entry at each level
Standard 360X Messages, with the following constraints:
<TBD>
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)
Due to the variety of human service workflows and services provided multiple referral models are needed. The following referral models differ on:
Referral is made by staff at the point of care. Referral recipient is identified by the clinical staff (optionally with consultation with the patient).
Patient agrees to program intervention (e.g. Meals on Wheels). HUB decides which provider will deliver program.
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.
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."
Example of Workflow - Food Insecurity Referral to Food Pantry Use Case
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.
=====================================================================
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).
Make sure that both the recipient and the HISP support full XDM metadata receipt and transmission.
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.
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.
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.
(Add guidance for how the combination of question/response order specific questions and the diagnoses Z-codes correspond to the the FHIR Observation.interpretation). 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.
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.