The Community Based Follow-up use case allows any system to make request to a CHIS to follow-up for any reason.  A common implementation might be for Lost to Follow-Up whereby a clinic generates a list of patients that have missed appointments and wants community based systems to help find the patient and encourage them to attend their appointment or to understand why they cannot or will not. This might be achieved either by having a health worker physically go find the patient or by other communication protocols (SMS, for example). 

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

1. Requesting System: Any system that wants a community based health worker to find and follow-up with a patient. The requesting system will often be an EMR like OpenMRS
2. 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.
3. CHW: Community Health Workers are the central users of CHIS. CHWs conduct household visits and are responsible for the health of their community.
4. 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).  

1. Requesting System → Determine patients needing follow-up
2. Requesting System → Send list of patients
3. CHIS → Notify
4. CHW→ Find patient and record outcome
5. CHW→ Sync results
6. CHIS→  Update with outcome of follow-up

Data Flow (High Level)

The flow is centered around the use of the FHIR "ServiceRequest" resource to initiate follow-ups in the community.

1. Requesting system determines which patients need follow-up
2. Requesting system creates a ServiceRequest for each patient and sends the ServiceRequest to HIE
3. CHIS queries the HIE to determine if there are any patients to follow-up with
4. Requesting system returns results of CHIS' query
5. CHIS determines where or not to claim the service request
6. CHIS "claims" the ServiceRequest to confirm that they will be following up with the patient
7. CHIS tasks the appropriate CHW with finding and advising the patient
   1. This step is detailed below - Data Flow (CHIS / CHW Process)
8. CHIS records the results of the CHW's efforts
9. CHIS updates the ServiceRequest
10. Requesting system receives update
11. Requesting system updates itself accordingly

Data Flow (CHIS / CHW Process)

The diagram below illustrates the dataflow between the SHR / FHIR Server and CHISs.

Draft Indicators

Based on the high level workflow mentioned above, the list of transactional indicators are below:

1. Count of ServiceRequests Created
2. Count of ServiceRequests Completed
3. Count of ServiceRequests Completed with Outcome of X
4. Count of ServiceRequests Completed with Outcome of Y
5. Average Time from Created to Claimed
6. Average Time from Claimed to Completed
7. Average Time from Created to Completed

The ultimate goal of these follow-ups is that the patient returns to care, so the most important indicator is probably "% 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. 

Useful Links

• High level list of FHIR resources that are important for CHIS interoperability. 

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.

1. OpenHIM Admin Console
2. OpenHIM
3. HAPI FHIR
4. 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: OpenHIE tooling, what modifications might be required to CHIS', gain experience with FHIR, gain experience with Instant OpenHIE, etc...  with that in mind, there are known limitations.