Work in Progress
This document is a work in progress. This dialog will be removed once the community agrees it is complete.
Summary
This use case allows other systems to make requests 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).
Definitions
- 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
- 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.
Workflows
High Level Overview (Requesting System / CHIS)
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 → Send list of patients
- CHIS → Notify
- CHW→ Find patient and record outcome
- CHW→ Sync results
- CHIS→ Update with outcome of follow-up
High level data flow (Requesting System / CHIS)
- Requesting system 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 follow-up with
- Requesting system returns results of query
- CHIS determines where or not to claim the service request
- CHIS "claims" the ServiceRequest to confirm that they will be following up with the patient
- CHIS tasks the appropriate CHW with finding and advising the patient
- CHIS records the results of the CHW's efforts
- CHIS updates the ServiceRequest
- Requesting system receives update
- Requesting system updates itself accordingly
Draft Indicators
Based on the high level workflow mentioned above, the list of transactional indicators are below:
| # | Description | Notes |
|---|---|---|
| 1 | Count of ServiceRequests Created | |
| 2 | Count of ServiceRequests Claimed | |
| 3 | Count of ServiceRequests Completed | |
| 4 | Count of ServiceRequests Completed with Outcome of X | |
| 5 | Count of ServiceRequests Completed with Outcome of Y |
Key FHIR Resources
The essential resources for this workflow are as follows.
| Description | Structure Definition | Samples |
|---|---|---|
| Patient | Patient.StructureDefinition.json | |
| ServiceRequest | ServiceRequest.StructureDefinition.json | |
| Encounter | Encounter.StructureDefinition.json |
Reference Architecture
The proof of concept uses the Instant OpenHIE architecture which utilizes a HAPI FHIR Server as a Shared Health Record component and OpenHIM for the Interoperability Layer. Detailed technical information and instructions for the CoPs shared infrastructure can be found here.
Data Flow Diagram (CHIS Processing Only)
The diagram below illustrates the dataflow between the SHR / FHIR Server and CHISs.
