Submitting WG/Project/Implementer Group

Justification and Objectives

For details on the approved scope for the Gravity Project SDOH Data Element FHIR IG, read the HL7 PSS.

Gravity demo 2020.05.15: View here

Gravity Report Out 2020.05.15: Download here

Gravity Report Out with Lessons Learned 2020.05.26: Download here

This track will use R4 version of FHIR.

Clinical input requested (if any)

Zulip Chat for SDOH CC: https://chat.fhir.org/#narrow/stream/233957-Gravity-sdoh-cc

Sign up for Zulip: https://chat.fhir.org/register/

Related tracks

2020-05 Care Coordination Track

Virtual Connectathon Schedule:

Related  Track Actors-Transactions-Payload Review 

Proposed Track Leads:

Track Orientation

Gravity SDOH FHIR Connectathon Preparation Meetings

Meeting Schedule:

Wednesdays at 3:00pm ET

• Feb 26 – Connectathon participation overview
• March 4 – PMEHR interactions with Screening App
• March 25 – PMEHR documenting SDOH information in a clinical care encounter
• April 1 – Clinical Data R/R interactions with PMEHR
• April 15 – Review of OAuth 2.0 implementation considerations; Options for the “patient participant” role; Aegis Touch Stone demo and CDex Test Script use
• April 29 - Logistics preparation for the May 13 - 15 virtual Connectathon:  Schedule, Roles, Procedures, Tools

Multiple Sign-ups:

• Click here to sign up for FHIR Connectathon Participation (Tells Gravity Project Community you have interest in Connectathon testing in general)
• Click here to register for testing with the Aegis testing tools
• Sign up to participate for specific roles for Scenario 1 below 

Participants

Add your feedback on SDOHCC Track: 

Gravity Scenario 1 - Gather and Share Social Determinants of Health (SDOH) Information in a Clinical Encounter

Link to Social Determinants of Health (SDOH-CC) IG

System Roles

Other Participant Roles

Personas and Patient Stories

Review Gravity Personas and Patient Stories here: http://build.fhir.org/ig/HL7/sdoh-cc/GravityProjectPersonasandPatientStories.html

Care Coordination Patient Story download here

Actor Transaction Diagram

Use Case 1 - Sequence Diagram

Scenario 1: Use Case 1 Gather and use SDOH information in the clinical care setting

Use charts below to express the role(s) you intend to participate in

http://gravity.meteorapp.com/baseR4
GET http://gravity.symptomatic.io/baseR4/metadata

Scenario 1 Scene 1: Gather Screening Information

Scenario 1 Scene 1 Step 1: Initial Screen Patients Task

Action: PMEHR initiates a task for screening patients via the Screening App FHIR API. PMEHR supplies the Questionnaire and Patient List for the requested screening task.

Precondition: PMEHR has a developed Questionnaire screening tool that conforms to SDC Questionnaire and has a means to determine the right list of patients to be screened. Establish the endpoint to be used by Screening App for workflow requests.

Success Criteria: Screening App receives the Task request, Questionnaire, Patient List, and any other needed resources such as the Organization requesting the task to be performed and the Endpoint where Consent and QuestionnaireResponses information should be returned.

Bonus point: Develop more than one type of SDOH Questionnaire using Coded questions and Answers using the LHC Form Builder Tool.

Link to guidance from the Structured Data Capture IG.

Scenario 1 Scene 1 Step 2: Perform Screen Patients Task

Action: Screening App interacts with Patient App to initiate consent to share SDOH questionnaire responses and, if agreed, administers the questionnaire and gathers the responses. Upon receiving a submitted questionnaire response, the Screening App returns the Consent and  QuestionnaireResponse to the endpoint indicated in the Questionnaire. 

Precondition: PMEHR endpoint for processing QuestionnaireResponses and Consent Resources was indicated in the Questionnaire using the SDC Questionnaire extension to support this element (sdc-questionnaire-endpoint)

Success Criteria: Patient's Consent and QuestionnaireResponse can be accepted, stored (associated with the correct patient), and viewed on the PMEHR.

Bonus point: Process more than one patient in a single task.

Scenario 1 Scene 1 Step 3: Notify Task Initiator that Task is Completed

Action: Screening App sends message to PMEHR (task initiator) to indicate the requested task has been completed.

Precondition: Establish the endpoint to be used by PMEHR for workflow updates. Task has an expiration date/time set so task completion can be established when responses have been received from all requested patients on the list or when the task expiration date is reached.

Success Criteria: PMEHR App can display the status of the Task, and it shows as completed. (Dashboard previously showed "active")

Bonus point: At the point of receiving the Task completed message, and based on received QuestionnaireResponses, PMEHR computes what portion of the requested list of patients completed the screening task.

Scenario 1 Scene 2: Perform the patient visit

Scenario 1 Scene 2 Step 4: Complete a Patient Encounter that includes viewing results from a prior screen

Action: PMEHR actor initiates a patient encounter and gathers medical as well as sdoh related information. The gathered information can be exchanged via a Progress Note for the Patient following the visit.

Precondition: PMEHR has previously received the patient's screening results and consent to share them with the PMEHR.  That screening is linked to the patient's medical record to allow the physician to easily review and potentially incorporate the screening information into the documentation of the visit.

Success Criteria: PMEHR gathers documentation during the encounter and records SDOH information in the same system using consistent mechanisms to permit the SDOH information to be part of the visit "SOAP NOTE" documentation.

Bonus point: Use the CDS on-patient-view hook to enable the clinician to view and select information from the screening results to be added to the current visit documentation.

Scenario 1 Scene 3: Notify Task Initiator that Task is Completed

All systems need to register for Scene 3: Register for Aegis Testing 

For assistance, review: Touchstone Onboarding_GravityProject.pdf

Scenario 1 Scene 3 Step 5: Request a Progress Note Document Generated Following the Clinical Encounter

Scenario 1 Scene 3 Step 6: Communicate a Progress Note Document Generated Following the Clinical Encounter

Action: Clinical Data Requestor/Recipient communicates a request to the PMEHR for a Progress Note for the Patient following the visit.

Precondition: PMEHR gathered documentation during the encounter and recorded SDOH information in the same system using consistent mechanisms to permit the SDOH information to be part of the visit "SOAP NOTE" documentation.

Success Criteria: PMEHR receives and processes the request then returns a solicited Communication that includes the requested document.

Bonus point: Use the RESTful data processing mechanisms defined by CDex to query for the Patient's Food Insecurity Observation.

Link to Clinical Data Exchange (CDex) IG.

Link to Prior CDex Connectathon Track guidance.

Data Representation Reference Information

Structured Document Clinical Note Types

Use this information to request clinical note(s) (DocumentReference or Composition, DiagnosticReport, CarePlan).

The Pull (Solicited Request) information exchange mechanism enables Information Request Sender to request a general type of document and permits the Information Request Recipient to respond with any of the more specific document types defined to be in that note type category.

The Pull (GET) information exchange mechanism requires the Information Client to use specific codes when querying the Information Source. 

Reference the various types of clinical note types via the concepts in the associated value sets.

Helpful Communication Request Recipient Organization Endpoint format codes (this is only relevant for the Request (Solicited Communication) Information Exchange mechanism

Sample Structured Data Codes

Note: there are many search parameters and other details for the FHIR search API.  Refer to the FHIR specification for details.

72166-2 Tobacco Smoking Status (LOINC)

TestScript(s)

Indicate any test scripts that will be used to help verify system behavior. TBD.

Security and Privacy Considerations

Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate