The Community Based Follow-up use case allows any system to make requests to a CHIS for patient follow-up. A common implementation is for Lost to Follow-Up whereby a clinic generates a list of patients who have missed appointments for follow-up through CHIS. During the follow-up, Community Health Workers (CHW) encourage the identified patients to attend their appointments and seek to understand the reason for non-attendance. The follow-up process may involve a CHW physically going to find the patient or reaching out through other communication protocols such as phone call or SMS.
Useful Links
- Interoperability workflows that add value to community health organizations
- Real world use cases that many of the CHIS' have already implemented
Table of Contents for this page
Definitions
- Requesting System: Any system that wants a CHW to find and follow-up a patient. The requesting system will often be an EMR like OpenMRS
- CHIS: A Community Health Information System is an information system that supports the routine and emergency health care of a patient population within community contexts in defined geographic areas.
- CHW: Community Health Workers are the central users of CHIS. CHWs conduct household visits and are responsible for the health of their community.
- SHR: Shared Health Record is a centralized data repository for storing patient’s shared health record.
Flows
Workflow Overview
From a very high level perspective, the workflow is designed around having the Requesting System determine which patients need to be followed-up with and a CHW trying to find the patient and recording the outcome of their attempt(s).
- Requesting System → Determine patients needing follow-up
- Requesting System → Sends list of patients
- CHIS → Gives notification for patients requiring follow-up
- CHW→ Finds patient and records the follow-up outcome
- CHW→ Syncs results captured on CHIS
- CHIS→ Updated with follow-up outcome
Data Flow (High Level)
The flow is centered around the use of the FHIR "ServiceRequest" resource to initiate follow-ups in the community.
- Requesting system determines which patients need follow-up
- Requesting system creates a ServiceRequest for each patient and sends the ServiceRequest to HIE
- CHIS queries the HIE to determine if there are any patients to be followed-up
- Requesting system returns results of CHIS' query
- CHIS determines whether or not to claim the service request
- CHIS "claims" the ServiceRequest to confirm that they will be following up a patient
- CHIS alerts the appropriate CHW with finding and advising the patient through a task
- This step is detailed below - Data Flow (CHIS / CHW Process)
- CHIS records the results of the CHW's efforts
- CHIS updates the ServiceRequest
- Requesting system receives update
- Requesting system updates itself accordingly
Data Flow (CHIS / CHW Process)
The diagram below illustrates the data flow between the SHR / FHIR Server and CHISs.
Draft Indicators
Based on the high level workflow mentioned above, the list of transactional indicators are below:
- Count of ServiceRequests Created
- Count of ServiceRequests Completed
- Count of ServiceRequests Completed with Outcome of X
- Count of ServiceRequests Completed with Outcome of Y
- Average Time from Created to Claimed
- Average Time from Claimed to Completed
- Average Time from Created to Completed
The ultimate goal of these follow-ups is that the patient returns to care. One of the most important indicators to track is % of patients that have returned to care.
Key FHIR Resources
The essential resources for this workflow were created and profiled with minimal fields/concepts and provide only a high level structure to get prototype the workflow. As the results of the Delphi Study become available, these can be profiled in more detail.
Description | Structure Definition | Samples |
---|---|---|
Patient | Patient.StructureDefinition.json | patient_cht.fhir.json |
ServiceRequest | ServiceRequest.StructureDefinition.json | service_request.fhir.json |
Encounter | Encounter.StructureDefinition.json | encounter_cht.fhir.json |
Useful Links
Reference Architecture
The proof of concept uses the Instant OpenHIE architecture interacting with multiple CHIS (CommCare, OpenSRP, and CHT).
The current setup includes the following components.
- OpenHIM Admin Console
- OpenHIM
- HAPI FHIR
- CHIS
Useful Links
- Detailed technical information about the shared infrastructure used by the TWG
- High level architecture considerations
- Review of technical interoperability modifications to existing CHIS
Known Limitations
This proof of concept use case was explored to learn about a number of things among others:
- OpenHIE tooling
- What modifications are required for CHIS' sharing data
- Gain experience with FHIR
- Gain experience with Instant OpenHIE
Hence there are more explorations to be made.