Date: Thu, 28 Mar 2024 21:06:07 -0400 (EDT)
Message-ID: <2081661221.1387.1711674367735@ip-10-0-0-229.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_1386_1172492471.1711674367733"
------=_Part_1386_1172492471.1711674367733
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
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 approv=
ed standards seeks to develop a closed loop referral specification for SDoH=
referrals. The goal will be to once again use ubiquitously ado=
pted technology to have a low development bar and to promote immediate adop=
tion.
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.&nb=
sp; She filed for unemployment benefits over a month ago but has yet to rec=
eive a check. She spent the last of her savings paying the rent and r=
eports 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 p=
atient is clearly distraught and depressed. Her doctor documents the =
patient=E2=80=99s food insecurity in the EHR and arranges for the patient t=
o be seen immediately by the care coordinator in the office.
The care coordinator gives the patient an address of a nearby church tha=
t provides meals and also refers the patient to the local food bank. =
In their state the food bank requires that the patient is Supplemental Nutr=
ition Assistance Program eligible. The care coordinator has the patie=
nt 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 wit=
h an =E2=80=9Caccept=E2=80=9D patient. The following day, when the pa=
tient arrives to collect food, the foodbank sends a notificati=
on to the PCP that the patient received services.
Example: Diabetic Prevention Referral
Patient is a 49-year-old woman with obesity, hypertension and hyperlipid=
emia at high risk for developing type II diabetes. During a telehealt=
h encounter (planned remote encounter due to the pandemic) with her primary=
care physician (PCP) where they discuss her risks for developing Typ=
e II Diabetes and her difficulties in maintaining a healthy lifestyle on he=
r own. She recognizes her risk and agrees to a referral to the YMCA D=
iabetic Prevention Program offered at the local YMCA. These meetings =
are currently being held remotely via =E2=80=9CZoom=E2=80=9D also due to th=
e pandemic.
Her doctor documents the patient=E2=80=99s referral in the EHR and arran=
ges for the patient to be seen immediately by the care coordinator in the o=
ffice.
The care coordinator reviews the program elements with the patient and c=
ompletes 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 th=
e patient=E2=80=99s home (anticipating that eventually the meetings may be =
in-person, rather than remote), and includes the PDF of the YMCA Diabetes P=
revention Program Intake Form.
On receipt of the 360X referral and YMCA Diabetes Prevention Program Int=
ake Form, the YMCA Diabetes Prevention Program responds with an =E2=80=9Cac=
cept=E2=80=9D patient, along with the start date of the next program (progr=
am=E2=80=99s run for a full year period). When the patient logs in to=
the =E2=80=9CZoom=E2=80=9D meeting for the first session of the program, t=
he 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 manageme=
nt 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 referr=
al 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 referr=
al management software
- Provider EHR to SDOH Hub which identifies additional SDOH needs o=
f the patient and makes additional referrals to CBO(s) beyond the one reque=
sted 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 M=
anagement Software (Most Simple EHR Requirements)
- Requirements
- Clinical EHR has push referral capabilities with Direct Account=
span>
- CBO having software with referral management capabilities and own=
direct account
- Referral Initiation & Receipt
- Sending clinical EHR pushes referra=
l to selected CBO
- Referring provider selects a specific CBO
- Unique referral ID is generated
- EHR sends HL7V2 message, per 360X IG, with structured patient dem=
ographics, and either default procedure codes:
- "Referral to assessment servic=
e," SNOMED CT 307378001 =
span>
- "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 nece=
ssary) as applicable
- Referral received by CBO with referral management software
- It is possible for the CBO system to automatically accept (CBO op=
en to all comers) or decline (CBO has no capacity for additional clients fo=
r 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 =E2=80=9CAccept=E2=
=80=9D or =E2=80=9CDecline=E2=80=9D<=
span> response back to referring provider:
- Decline Referral Response:
- =E2=80=9CDecline=E2=80=9D response pushed back to referring provi=
der=E2=80=99s EHR
- Following decline response, furth=
er communication between referring provider, patient and CBO may be require=
d for eligibility.
- Once eligibility is gra=
nted a new referral can be made (This communication is OOS for 360X)=
span>
- Accepted Referral Response:
- CBO management software pushes message back to referring provider=20
- =E2=80=9CServices rendered=E2=80=9D with SNOMED CT Procedure Code(s) that are used in the Gravity Project.=
span>
- =E2=80=9CNo Show=E2=80=9D
- (Could there be an =E2=80=9Copt o=
ut=E2=80=9D possibility for providers, so they no longer receive notificati=
ons)?
- Once the patient is no longer enrolled in the program, CBO sends =
message to EHR
- =E2=80=9CServices discontinued complete=E2=80=9D
- =E2=80=9CServices discontinued incomplete=E2=80=9D (=
Referral Loop Closed).
- Initiator systems (clinical EHRs) will develop workflow and GUI b=
ased on their client feedback. Directing EHRs on workflow following r=
eceipt of these exchanges is OOS for 360X.
- Patient is enrolled in an ongoing program (i.e., Meals on Wheels)
- Repeat steps a. i-iii - b. i-ii until services disco=
ntinued complete / services discontinued incomplete.
- One time service for patient
- CBO referral management software pushes either
- =E2=80=9Cservices rendered=E2=80=9D
- =E2=80=9Cno show=E2=80=9D via HL7v2 message which includes OBR/OB=
X segment that can include a SNOMED CT Procedure Codes to the referring pro=
vider (Referral loop closed).
- Patient is deemed ineligible for re=
ferred services
- CBOs referral management pushes =E2=80=9CDecline=
=E2=80=9D message with reason of =E2=80=9Cineligibility=E2=
=80=9D back to referring provider=E2=80=99s EHR (Referral loop=
closed).
- Patient is referred to additional services by CBO
- No notification of additional referral
- Out of scope for 360x
- =E2=80=9CNo Show=E2=80=9D : Unsolicited =E2=80=9CNo Show=E2=80=
=9D notification
- Patient does not go to organization for services in predetermined=
time frame, specific to each organization
- =E2=80=9CNo Show=E2=80=9D message is sent to referring Provider=
=E2=80=99s EHR
- Unlike clinical 360X referrals, there is no expectation of previo=
us appointment information being shared prior to the =E2=80=9CNo Show=E2=80=
=9D notification being sent.
- This does not close the referral loop=
span>
*In all scenarios above - patient matching is done through 360x un=
ique referral ID
Use Case #2 - Provider EHR to=
SDOH Hub which functions as CBO referral management software for CBO witho=
ut its own software
(This might be rolled into USE CASE #1)
- Sending clinical EHR pushes referra=
l of a selected CBO to a Hub (unique referral ID is generated)
- Referring provider selects a specific CBO, without referral manag=
ement software
- Clinical EHR has push referral capabilities to Hub =
li>
- EHR sends HL7V2 message, per 360X IG, with structured patient dem=
ographics, and either default procedure codes:
- "Referral to assessment servic=
e," SNOMED CT 307378001 =
span>
- "Referral to Social Services," SNOMED CT, 306238000, and ap=
propriate, selected SDOH diagnosis code, ICD-10 CM
- Referring provider sends any necessary forms or data (PDF if nece=
ssary) as applicable
- Receiving referral by Hub with referral management s=
oftware
- It is possible for the Hub to automatically accept (CBO open to a=
ll comers) or decline (CBO has no capacity for additional clients for servi=
ces) a referral
- Patient eligibility is checked by Hub staff
- Hub Staff will send either an =E2=80=9CAccept=E2=
=80=9D or =E2=80=9CDecline=E2=80=9D<=
span> response back to referring provider
- Decline Referral Response:
- Patient is deemed ineligible for =
services requested by all CBOs, per Hub. =E2=80=9CDecline<=
/span>=E2=80=9D response pushed=
back to referring provider=E2=80=99s EHR. Following decline response furth=
er communication between referring provider, patient and CBO may be require=
d for eligibility and once eligibility is granted a new referral can be mad=
e. (This communication is OOS for 360X)
- If Hub finds patient ineligible for specific CBO that provider id=
entified, but identifies CBO where patient is eligible - this will trigger =
one of the =E2=80=9CAccepted=E2=80=9D respons=
e below with message/correction of newly identified CBO
- Accepted Referral Response:
*Patient=E2=80=99s referral is pushed to the specific CBO identifi=
ed by the referring provider, though Hub software
- Patient is accepted with several possible outcomes - as follows:<=
/span>
- CBO management software pushes me=
ssage back to referring provider, through Hub software, regarding =
patient enrollment (need to make consistent with title)
- CBO referral management software pushes =E2=80=9Cservices rendere=
d=E2=80=9D or =E2=80=9Cno show=E2=80=9D messages, th=
rough Hub software, in ongoing fashion that can =
include SNOMED CT Procedure Code(s) t=
hat are used in the Gravity Project.
- (Could there be an =E2=80=9Copt out=E2=80=9D possibility for prov=
iders, so they no longer receive notifications)
- Once the patient is no longer enrolled in the program, CBO marks =
the patient as =E2=80=9Cservices discontinued complete=E2=80=9D or =E2=80=
=9Cservices discontinued incomplete=E2=80=9D which pushes a message t=
o 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 =E2=80=9Cservice=
s rendered=E2=80=9D or a =E2=80=9Cno show=E2=80=9D message to the referring=
provider, through Hub software that can include SNOMED CT Procedure Code(s) that are used in t=
he Gravity Project. (=
Referral loop closed).
- Patient is deemed ineligible for re=
ferred services (Referral Loop Closed)
- CBOs referral management pushes =E2=80=9CDecline=
=E2=80=9D message with reason of =E2=80=9Cineligibility=E2=
=80=9D back to referring provider=E2=80=99s EHR, through H=
ub software
- Patient is referred to additional services by CBO
- No notification of additional referral
- Out of scope for 360x
- =E2=80=9CNo Show=E2=80=9D
- Patient does not go to organization for services in predetermined=
time frame, specific to each organization
- =E2=80=9CNo Show=E2=80=9D message is sent to referring Provider=
=E2=80=99s EHR, through Hub software
- This does not close the referral loop=
span>
*In all scenarios above - patient matching is done through 360x un=
ique referral ID
Use Case #3 -<=
/strong> Provider EHR to SDOH Hub, without a specific CBO se=
lected
- Referring provider DOES NOT select a specific CBO, but referral t=
o HUB includes
- SDOH ICD diagnosis code =E2=80=9Cprogram type=E2=80=9D
- Unique referral ID is generated
- HL7V2 with structured patient demographics, default procedure cod=
e (306238000, SNOMED CT, Referral to Social Services and appropriate, selec=
ted SDOH ICD diagnosis code)
- Referring provider sends any necessary forms or data (PDF if nece=
ssary) as applicable
- Patient eligibility is checked by Hub staff
- Hub Staff will send either an =
=E2=80=9CAccept=E2=80=9D or=
=E2=80=9CDecline=E2=80=9D<=
/strong> response back to referring =
provider
- Receiving referral by Hub with r=
eferral management software
- Decline Referral Response:
- Patient is deemed ineligible for services requested by all CBOs, =
per Hub. =E2=80=9CDecline=E2=80=9D response p=
ushed back to referring provider=E2=80=99s EHR.
- This communication is OOS for 360X: Following decline response fu=
rther communication between referring provider, patient and CBO may be requ=
ired for eligibility and once eligibility is granted a new referral can be =
made
- Accepted Referral Response:
- Patient=E2=80=99s referral is pushed to the specific CBO identified by =
the Hub, though Hub software (several options):=20
- CBO management software pushes message back to referring provider, through Hub software, regarding patient enrollment (Enrollment Notice).=
span>
- CBO referral management software pushes =E2=80=9Cservices rendered=E2=
=80=9D or =E2=80=9Cno show=E2=80=9D messages, through Hub software, i=
n ongoing fashion (any =E2=80=9Copt out=E2=80=9D for providers viewing thes=
e messages is OOS for 360X, but might be configurable for the provider in h=
er/his EHR)
- Once the patient is no longer enrolled in the program, CBO marks the pa=
tient as =E2=80=9Cservices discontinued complete=E2=80=9D or =E2=80=9Cservi=
ces discontinued incomplete=E2=80=9D which pushes a message to the pr=
ovider's EHR, through Hub software (=
em>Referral loop closed)
- Patient is enrolled in an ongoing program (i.e. Meals on Wheels)
- One time service to be receive=
d by patient
-
- CBO referral management software pushes either a =E2=80=9Cservice=
s rendered=E2=80=9D or a =E2=80=9Cno show=E2=80=9D message to the referring=
provider, through Hub software
- A services rendered message closes the referral loop. A =E2=
=80=9CNo Show=E2=80=9D message does not close the loop.
- Patient is deemed ineligible for re=
ferred services
- CBOs referral management pushes =E2=80=9CDecline=
=E2=80=9D message with reason of =E2=80=9Cineligibility=E2=
=80=9D back to referring provider=E2=80=99s EHR, through H=
ub software (Referral loop closed)
- Patient is waitlisted for services =
(NOTE: this is only a valid option if the required servi=
ces are non-urgent!) Interim notes are to =
be sent to initiator with required reason code of =E2=80=9CWaitlisted=E2=80=
=9D
- Patient is referred to additional services by CBO
- No notification of additional referral
- Out of scope for 360x
7. =E2=80=9CNo Show=E2=80=9D
-
- Patient does not go to organization for services in predetermined=
time frame, specific to each organization
- =E2=80=9CNo Show=E2=80=9D message is sent to referring Provider=
=E2=80=99s EHR, through Hub software
- This does not close the referral loop=
span>
*In all scenarios above - patient matching is done through 360x un=
ique 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 =E2=80=9CUse Case #3=E2=
=80=9D
Us=
e Case #5 - Provider EHR to SDOH Hub which identifi=
es additional SDOH needs of the patient and makes additional referrals to C=
BO(s) beyond the one requested by the provider
-
- Follow all of the steps detailed above in =E2=80=9CUse Case #3=E2=
=80=9D
- AND Hub then sends message back to refe=
rring provider
- Additional referrals (HL7V2 message with additional Z code that t=
he secondary referral was based on)
- Communication back to provider regarding secondary CBO referrals =
may require consent =E2=80=93 we need a legal opinion on this. (Obtaining a=
nd 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 dupli=
cative and can be deleted?
Gravity Project |
360x SDOH |
Comments/Difference |
SDOHCC Goal (http://hl7=
.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Goal)<=
/p> |
360x does not provide related goal information a=
s part of the referral. |
Out of Scope for 360x because 360x focuses on on=
ly 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 simila=
r 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 workflo=
w Management with unique value sets for Task Status and ServiceRequest Stat=
us. The "Focus," of the Task, what the Task is acting on is the ServiceRequ=
est. Whereas the status of the ServiceRequest is controlled by the initiato=
r of that ServiceRequest, the status of the Task is controlled by the "Owne=
r," of the task, the person responsible for carrying it out. |
SDOHCC ServiceRequest (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOH=
CC-ServiceRequest)
ServiceRequest.Category:SDOH - Referrals are categorized by SDOH Cate=
gory Domain
Request.status - draft | act=
ive | on-hold | revoked | completed | entered-in-error | unknown
ServiceRequest.intent - prop=
osal | plan | directive | order | original-order | reflex-order | filler-or=
der | instance-order | option
ServiceRequest.priority - ro=
utine | urgent | asap | stat |
The OBR Code in the HL7v2 message most closely relates to FHIR ServiceRe=
quest.
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 | Devic=
e | 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-sd=
oh-clinicalcare/StructureDefinition-SDOHCC-TaskForPatient.html)=
- Task for Patient provides workflow management data for patient communica=
tion and specifies codes describing the type of task: Make Contact, Review Ma=
terial, 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 re=
cipient can document the outcome of any patient specific task with: (1) Gra=
vity Project's Task for Patient Codes=E2=80=93Make Contact, Review Material=
, General Information, Complete Questionnaire, or (2) documented responses =
to the Order Specific Questions. |
US Core Patient Profile (http://hl7.or=
g/fhir/us/core/StructureDefinition/us-core-patient) |
Primary Language - Supported PID-15 - HL7v2 Mess=
age |
Gravity Project uses FHIR US Core language - The language which can be used to commun=
icate with the patient about his or her health. |
SDOHCC Procedure (
http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Pr=
ocedure)
Procedure.status - pr=
eparation | in-progress | not-done | on-hold | stopped | completed | en=
tered-in-error | unknown
|
The OBR Code in the HL7v2 message most closely relates to the FHIR Proce=
dure.
This can include the very same SNOMED CT Procedure Codes that are used i=
n the Gravity Project. |
Both standards use the same SNOMEDCT codes. Grav=
ity uses the FHIR Procedure resource, whereas 360x uses the HL7v2 message t=
o 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 bet=
ween organization and location from Direct Directory. Direct Addresses can =
be location specific. There is a "System" and "Facility" in a message heade=
r. |
managingOrganization - Organization responsible for provisioning and upkeep
|
US Core PractitionerRole Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitionerro=
le) |
The closest equivalent to PractitionerRole in 36=
0x 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 recipient=
s 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 an=
d other administrative information about an individual practitioner.=
|
The Direct Address and the NPI provide equivalen=
t of Practitioner and PractitionerRole for sender. Referral recipient corre=
sponds to Organization, ParctitionerRole not required. |
360x does not support Practitioner. |
US Core Organization Profile (htt=
p://hl7.org/fhir/us/core/StructureDefinition/us-core-organization)=
a> |
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/l=
ocation. |
SDOHCC HealthcareService (https://build.fhir.org/ig/HL7/fhir-sdoh-=
clinicalcare/StructureDefinition-SDOHCC-HealthcareService.html) |
360x requires a Direct Address and doesn't speci=
fy whether the referral is going to a HealthcareService, Organization or Pr=
actitionerRole. Often Direct is implemented by using one address for schedu=
ling all services and others have departmental Direct Addresses. Others hav=
e Direct Addresses on the facility level. Multiple facilities may even use =
the same Direct Address. |
FHIR HealthcareService provides the ability to r=
epresent much more diverse set of data, which is not available in the Direc=
t Directory: Language, Coverage Area, Eligibility and Characteristic to nam=
e a few. |
US Core CareTeam Profile (http://hl7.=
org/fhir/us/core/StructureDefinition/us-core-careteam) |
The primary care physician is the point of conta=
ct for the patient's care and it is out of scope for how the Care Team is u=
pdated about the referrals. |
Gravity requires CareTeam and 360x does not supp=
ort it. |
SDOHCC Condition (=
http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Conditi=
on)
Conditions are Categorized by SDOH Domain |
Use Health Concern/Diagnosis ICD-10 as reason fo=
r referral with the option of SNOMED-CT Codes as the Service |
Both standards use the same Health Concern/Diagn=
osis codes. |
SDOHCC Observation Scre=
ening Response (http://hl7.org/fhir/us/sdoh-clinica=
lcare/StructureDefinition/SDOHCC-ObservationScreeningResponse)=
p> |
SDOHCC Observation Screening Response (http://hl7.=
org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ObservationScreeni=
ngResponse) |
Out of Scope for 360x because 360x focuses on on=
ly referral process. |
SDOHCC Observation Assessmen=
t (http://hl7.org/fhir/us/sdoh-clinicalcare/Structu=
reDefinition/SDOHCC-ObservationAssessment) |
SDOHCC Observation Assessmen=
t (http://hl7.org/fhir/us/sdoh-clinicalcare/Structu=
reDefinition/SDOHCC-ObservationAssessment) |
Out of Scope for 360x because 360x focuses on on=
ly referral process. |
SDOHCC Consent=
(http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefin=
ition/SDOHCC-Consent) |
Out of Scope for 360x because 360x focuses on on=
ly referral process. Sharing referral data falls under HIPAA Treatment Paym=
ent and Operations. |
360x is providing minimal necessary data on pati=
ents. Gravity's FHIR specification requires consent to be shared under the&=
nbsp; "Coordination Platform Capability Statement." |
Gravity Project Clinical Care IG Value Sets
- Task for Referral Management=20
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 possib=
le - higher priority than urgent. |
stat |
STAT |
The request should be actioned immediately - hig=
hest 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 t=
he task and is evaluating whether to perform it. |
~received |
accepted |
Accepted |
The potential performer has agreed to execute th=
e 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 complet=
e. |
~active |
on-hold |
On Hold |
The task has been started but work has been paus=
ed. |
~suspended |
failed |
Failed |
The task was attempted but could not be complete=
d 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 retain=
ed only because of the possibility it may have used. |
~=
error |
task.focus - The request being actioned or the resource being manipulated by thi=
s task. (Reference Any)
Initiation of Referral
- Referral Initiators
- Ambulatory Care (e.g. Primary Care, Specialist Provider, (Care Ma=
nagement/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 woul=
d apply).
No C-CDA requirement for initial request
All necessary information is included in the HL7v2 attachment (see=
=E2=80=9Cwhat information needs to be included for Extra-Clinical Referral=
s=E2=80=9D 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-CD=
A (2.16.840.1.113883.10.20.22.1.10) includes structured patient demographic=
s 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 re=
ferral
LOINC/ICD/SCT codes?
Proposal for 4 levels:
- Overall purpose of the request (XD metadata)
content ty=
pe 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: R=
73. 03
- Expected outcome
Gravity/Snomed provision
Note: These are not to be considered as requirements for independent dat=
a 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 c=
losed
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 Unstruc=
tured Document Template - this information would be only <=
/span>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 Provi=
der Referral Models
Due to the variety of human service workflows and services provided mult=
iple referral models are needed. The following referral models differ on:=
p>
- Who selects the referral recipient within a program type (e.g. Food Pan=
try Program) and makes the referral: staff of the clinical provider, patien=
t or HUB?
- When the referral recipient is selected and the referral triggered: whe=
n patient is receiving care, or after they have left the clinical provider'=
s office?
<=
strong>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 initiato=
r, closing the referral loop. They act as a Master Patient/Client Index.
- They could represent a community's source of truth for community resour=
ces and could provide the referral initiator with a list of community resou=
rces.
- They support the latest standards for documenting SDOH needs, health co=
ncerns, goals and interventions (optionally)
- Within a programmatic domain where multiple Human Service Providers del=
iver the same service a HUB may play a role in identifying the appropriate =
human service provider. =20
- 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 Huma=
n Service Provider
Classic Referral
Referral is made by staff at the point of care. Referral recipient is id=
entified by the clinical staff (optionally with consultation with the patie=
nt).
HUB Program-Selection Referral Model=
Patient agrees to program intervention (e.g. Meals on Wheels). HUB decid=
es which provider will deliver program.
Patient Selects H=
uman Service Provider after Clinical Appointment
Classic Self-Referral
Patient is provided with a list of community resources (e.g. Food pantri=
es), 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 interve=
ntion 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 p=
roviders with the patient ID and referral IDs that had been sent with the r=
eferral from the clinician for the same type of program (e.g. Food Pantry P=
rogram").
Example of Workflow - Food Insecurity Referral to Food Pantry Us=
e 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<=
/a> (e.g. unable to obtain adequate food) - automatically generated b=
ased on Assessment questions and responses that are filled out by patient=
span>
- Diagnosis (Requires Clinician Decision)
- Reason for referral - C=
ondition or Diagnosis (SNOMED CT: "Food insecurity (findin=
g)," or ICD-10-CM: =E2=80=9CLack of adequate food and safe drinking water,=
=E2=80=9D Z59.4.)
- Optional data and documentation as needed
- Assessment of goals
- Intervention (USCDI Level 2) - co=
uld be requested by healthcare provider or submitted with referral request<=
/span>
- Education about Supplemental Nutrition Assistance Program<=
/li>
- 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 t=
ype of entity is not yet indicated in the Direct Directory.
------=_Part_1386_1172492471.1711674367733--