Intercept FHIR Subscription Resource

[samuelimoisili]

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

1. Requesting System: Any system that wants a CHW to find and follow-up a patient.
2. 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.
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.

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.

1. Requesting System → Mediator sends a list of patients and a callback URL.
2. Mediator → FHIR creates subscriptions for patients with the mediator as callback.
3. Mediator → CHIS creates follow up task for the patients
4. Mediator → Requesting System returns a the Subscription ID
5. CHIS → CHW find the patient record and notifies the CHW
6. CHW → CHIS syncs the LFTU outcome with the CHIS
7. CHIS → FHIR pushes an Encounter resource to FHIR
8. FHIR → Mediator notifies the mediator of the LFTU Encounter
9. 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:

1. Requesting System → Mediator sends a list of Patients and callback URL to the Mediator
2. Mediator → CHIS checks for a subscription with the callback URL, update the subscription, and notifies the CHIS
3. CHIS → CHW Finds the patient record and notifies the CHW
4. 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.

Useful links

• Request Community Based Follow-Up