Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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. Sendingclinical 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
      4. Unique referral ID is generated
      5. , and either default procedure codes:
        1. "Referral to assessment service," SNOMED CT 307378001
        2. "
        Default procedure code (306238000, SNOMED CT,
        1. Referral to Social Services
        (or one of the specific intervention SNOMED codes developed by Gravity) and appropriate, selected
        1. ," SNOMED CT, 306238000
        2. SDOH diagnosis code, ICD
        )
        1. -10 CM/SNOMED CT
      6. 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”
      2. “no show”
      3. with SNOMED CT Procedure Code(s) that are used in the Gravity Project.
      4. “No Show”
      5. ((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 a “services rendered” or a “no show” HL7v2 message which includes OBR/OBX segment that can include a SNOMEDCT 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

...

  1. Sendingclinical 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 code (306238000, SNOMED CT, codes:
      1. "Referral to assessment service," SNOMED CT 307378001
      2. "Referral to Social Services
      and
      1. ," SNOMED CT, 306238000,  and appropriate, selected SDOH diagnosis code, ICD
      )
      1. -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:

...

    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 fashionthat can include SNOMED CT Procedure Code(s) that are used in the Gravity Project.
        2. (Could there be an (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. CBO referral management software pushes either a “services rendered” or a “no show” message to the referring provider, through Hub software
  1. This closes the referral loop
      1. that can include SNOMED CT Procedure Code(s) that are used in the Gravity Project. (Referral loop closed).
    1. Patient is deemed ineligible for referred services
  2. This closes the referral loop
    1. (Referral Loop Closed)
      1. CBOs referral management pushes “Decline” message with reason of “ineligibility” back to referring provider’s EHR, through Hub software
    2. 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

...

  1. Referring provider DOES NOT select a specific CBO, but referral to HUB includes
    1. SDOH ICD diagnosis code “program type”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

...

SDOHCC Procedure (

http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Procedure)
360x is providing minimal necessary data on patients.
Gravity Project360x SDOHComments/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. 

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

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)

US Core Patient Profile (httpSDOHCC Task for Patient (https://hl7build.fhir.org/fhirig/us/coreHL7/fhir-sdoh-clinicalcare/StructureDefinition/us-coreSDOHCC-patient)

Primary Language - Supported PID-15 - HL7v2 MessageGravity Project uses FHIR US Core language - The language which can be used to communicate with the patient about his or her health. 

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.

The OBR Code in the HL7v2 message most closely relates to the FHIR Procedure. 

This can include the very same SNOMEDCT 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)patient)

Primary Language - Supported PID-15 - HL7v2 MessageGravity Project uses FHIR US Core language - The language which can be used to communicate with the patient about his or her health. 


SDOHCC Procedure (

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 upkeepUS Core PractitionerRole Profile (
http://hl7.org/fhir/us/
core
sdoh-clinicalcare/StructureDefinition/
us
SDOHCC-
core-practitionerrole
Procedure)

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.

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 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.

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

US Core PractitionerRole US Core Organization Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-organizationpractitionerrole)

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.  Need to discuss with Google, United Way about what identifiers will be used for Community Based Organization (CBO) without NPIs.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

SDOHCC Healthcare Service (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. 

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.

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.  Need to discuss with Google, United Way about what identifiers will be used for Community Based Organization (CBO) without NPIs.

SDOHCC Healthcare Service (https://build.fhir.org/ig/HL7/fhir-SDOHCC Condition (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/-SDOHCC-Condition)

Use Health Concern/Diagnosis ICD-10 as reason for referral with the option of SNOMED-CT Codes as the ServiceBoth standards use the same Health Concern/Diagnosis codes.

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. 

SDOHCC Observation Screening ResponseUS Core CareTeam Profile (http://hl7.org/fhir/us/sdoh-clinicalcarecore/StructureDefinition/SDOHCCus-core-ObservationScreeningResponse)

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.

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.

SDOHCC Observation AssessmentSDOHCC Condition (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ObservationAssessment)SDOHCC Observation AssessmentCondition)

Use Health Concern/Diagnosis ICD-10 as reason for referral with the option of SNOMED-CT Codes as the ServiceBoth standards use the same Health Concern/Diagnosis codes.

SDOHCC Observation Screening Response (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ObservationScreeningResponse)

SDOHCC Observation Screening Response (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ObservationAssessment)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..org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ObservationScreeningResponse)Out of Scope for 360x because 360x focuses on only referral process.

SDOHCC Observation Assessment (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ObservationAssessment)

SDOHCC Observation Assessment (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-ObservationAssessment)

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 Project Clinical Care IG Value Sets

  • Task for Referral Management
    • Task.priority
CodeDisplayDefinition
routineRoutineThe request has normal priority.
urgentUrgentThe request should be actioned promptly - higher priority than routine.
asapASAPThe request should be actioned as soon as possible - higher priority than urgent.
statSTATThe request should be actioned immediately - highest possible priority. E.g. an emergency.
    • TaskStatus


CodeDisplayDefinitionCanonical Status
draftDraftThe task is not yet ready to be acted upon.~draft
requestedRequestedThe task is ready to be acted upon and action is sought.~requested
receivedReceivedA potential performer has claimed ownership of the task and is evaluating whether to perform it.~received
acceptedAcceptedThe potential performer has agreed to execute the task but has not yet started work.~accepted
rejectedRejectedThe potential performer who claimed ownership of the task has decided not to execute it prior to performing any action.~declined
readyReadyThe 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
cancelledCancelledThe task was not completed.~abandoned
in-progressIn ProgressThe task has been started but is not yet complete.~active
on-holdOn HoldThe task has been started but work has been paused.~suspended
failedFailedThe task was attempted but could not be completed due to some error.~failed
completedCompletedThe task has been completed.~complete
entered-in-errorEntered in ErrorThe 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

...