This document is a work in progress. This dialog will be removed once the community agrees it is complete. |
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).
See here for a list of interoperability workflows that add value to community health organizations. See here for a list of real world use cases that many of the CHIS' have already implemented.
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).
The flow is centered around the use of the FHIR "ServiceRequest" resource to initiate follow-ups in the community.
The diagram below illustrates the dataflow between the SHR / FHIR Server and CHISs.
Based on the high level workflow mentioned above, the list of transactional indicators are below:
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".
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 |
The Technical Working Group has also put together a high level list of FHIR resources that are important for interoperability. That list is being maintained here.
The proof of concept uses the Instant OpenHIE architecture interacting with multiple CHIS (CommCare, OpenSRP, and CHT).
The current setup includes the following components.
Detailed technical information about this infrastructure, including servers set up on the CoPs shared infrastructure, can be found here. A review of some higher level architecture considerations can be found here. A review of technical interoperability modifications to existing CHIS can be found here.
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.