Setting up an optimal user and contact hierarchy for an offline m:n contact:place scenario

Hello everyone,

Here is an interesting user story to help brainstorm an efficient contact hierarchy.

As a roving nurse serving multiple medical supplies distribution points in my district - one distribution points can be served by multiple health facilities and a distribution point serves clients from more than one health facility - I want to be able to get just records of patients I will be serving at a distribution point for a select day. Eventually, I want to have patient records updated in the EMR from the application.

Background

  • A distribution point is a chosen location by a group of clients where they meet to be served by roving community nurses.

  • The group usually has client appointment dates syncronized so that they are nurse visits are optimized. This means that a nurse can plan their path as they move around the district.

  • A group can have of clients linked to different facilities (1 group : m clients). See diagram below. Note that client records are stored in offline EMR systems - each facility has its own server meaning client records are static.
    Group - Clients

  • A facility serves clients linked to them, meaning that 1 facility serves many distribution points. See diagram below.
    Facility - Groups

The following diagram summarizes the relationship between clients → groups → facilities.

Visits

  • A nurse prepares for a visit by getting a list of clients they expect to serve on the day of. The list of clients is drawn from each facility that has a client in that distribution point.
  • The nurse will request for supplies from each of the facilities of interest and maintain separate visit reports for each facility, which will be manually updated in the EMR system.

Current system

  • The nurses use tablets with an ODK application. Paper acts as backup. ODK aggregate (server) is centralized at the partners HQ.
  • The nurse will obtain and print a list of due visits from each health facility to help request for supplies. They physically go to the health facilities for logistics and reporting purposes.
  • On the day of the visit, they use the ODK application to record visit data and later sync with the server at HQ, accessible via Intranet - nurses travel to HQ to sync.
  • When synced, they download the data, filter by health facility, print hard copies for forwarding back to the health facilities.
  • Data clerks at the facilities will use the printed copies to update the EMR system. See diagram below.

Initial thoughts

  • Each health facility to have their own CHT servers, basically replicate the EMR setup in order to achieve bidirectional data exchange given the offline nature of the EMR.
  • Each facility to have a device for capturing and syncing visit data to the CHT server.
  • The nurse user to have an offline role.
  • The nurse will sync devices for each facility that has a patient being served at a distribution point during a visit. For instance, if there are 5 facilities serving the point/group, the nurse will visit with the 5 devices and dispatch each accordingly. They visit the facilities anyway.
  • For scale, if a central server is availed at HQ and connectivity implemented, HQ will become a parent for each of the facilities.

I have read about Prototyping a fully offline CHT Server environment and is the ideal path in this case. However, I believe getting the hierarchy right is a critical step.

Thoughts, ideas, experiences are all welcome.

cc @antony @michael

@ojwangantony, @andrineM and @Lavatsaleo it would be great to hear your thoughts and ideas. Thanks.

Possible option

One of the possible options I am considering is to link clients to distribution points and have one device roving among facilities. See the diagram below.

  1. A single device would be used for a distribution point, meaning it’d have data for multiple facilities.
  2. To get data to the CHT server, we’d go for filtered replication, utilizing the facility attribute to sync specific facility data.

I have not tested this approach yet, but welcome reactions to it.

1 Like