In the current implementation of the LTFU workflow document over here. When we create a FHIR subscription resource, we provide a callback for the FHIR subscription which is the URL of the requesting system.
In this document, we will cover a proposed workflow for intercepting the callback request and implementing a cancel Task feature.
Definitions
Requesting System: Any system that wants a CHW to find and follow-up a patient.
CHIS: A community health information system is an information system that supports the routine and emergency healthcare of a patient population within community contexts in defined geographical 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.
Flow
This document discusses an extension to the LTFU workflow which is discussed over here. We'll be skipping some trivia part of the workflow that has been documented and we'll start from when the requesting system sends a request to the mediator for the LTFU workflow.
Workflow Overview
The workflow is designed around the requesting system having the ability to cancel follow up with a patient and the mediator having the ability to cancel request.
Requesting System → Mediator sends a list of patients and a callback URL.
Mediator → FHIR creates subscriptions for patients with the mediator as callback.
Mediator → CHIS creates follow up task for the patients
Mediator → Requesting System returns a the Subscription ID
CHIS → CHW find the patient record and notifies the CHW
CHW → CHIS syncs the LFTU outcome with the CHIS
CHIS → FHIR pushes an Encounter resource to FHIR
FHIR → Mediator notifies the mediator of the LFTU Encounter
Mediator → Requesting System notifies the requesting system via callback URL on the Encounter.
The requesting systems will have the ability to cancel LTFU requests and check up on requests Here is an overview the LTFU request cancelation or update workflow:
Requesting System → Mediator sends a list of Patients and callback URL to the Mediator
Mediator → CHIS checks for a subscription with the callback URL, update the subscription, and notifies the CHIS
CHIS → CHW Finds the patient record and notifies the CHW
CHW → CHIS Syncs with the CHIS and the tasks get updated
Mediator Subscription
interface SubscriptionDocument {
_id: string;
subscription_id: string; // ID received from FHIR
callback_url: string; // callback URL for the Mediator
}
Missing Features
Verifying the requesting system for a subscription update is the same system that created the subscription.
Handling retries on the Mediator for callback URLs that aren't reachable.
Sending a ping to the callback URL to ensure it is an valid callback URL.
In the current implementation of the LTFU workflow document over here. When we create a FHIR subscription resource, we provide a callback for the FHIR subscription which is the URL of the requesting system.
In this document, we will cover a proposed workflow for intercepting the callback request and implementing a cancel Task feature.
Definitions
Flow
This document discusses an extension to the LTFU workflow which is discussed over here. We'll be skipping some trivia part of the workflow that has been documented and we'll start from when the requesting system sends a request to the mediator for the LTFU workflow.
Workflow Overview
The workflow is designed around the requesting system having the ability to cancel follow up with a patient and the mediator having the ability to cancel request.
The requesting systems will have the ability to cancel LTFU requests and check up on requests Here is an overview the LTFU request cancelation or update workflow:
Mediator Subscription
Missing Features
Useful links