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).
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.
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 are as follows.
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 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.
The diagram below illustrates the dataflow between the SHR / FHIR Server and CHISs.