Offline Mode: CHWs & Sites

Summary

This project aims to support offline mode for the scenario of an Outreach Worker leaving a clinic / health site. Support for Offline for clinic / healthcare sites was not part of the initial scope; however, the way we have done the offline work thus far for OpenMRS 3.x means that any widget can use this function and then be used offline. This takes us closer to a future of supporting Offline Mode even in clinics. 

Links to Know

Designs: Public version here. (If you already have a Zeplin account with OpenMRS, you can see the more detailed designs here.)

Technical Documentation & Design: https://o3-dev.docs.openmrs.org/#/main/offline

Jira Epic:

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Repo: https://github.com/openmrs/openmrs-esm-core/tree/master/packages/apps/esm-offline-tools-app 

Talk Thread: about the potential of this work to help with clinic offline mode - see here.




Two Very Different Types of "Offline" Problems

When an OpenMRS user asks for "Offline Mode", they may be referring to 1 of 2 very different problems. Make sure you understand which one is a priority for your use case, since this drastically changes requirements. 

  1. Case #1: Offline Outreach Workers. Support for Outreach Workers who need to travel to remote locations.

  2. Case #2: Offline Sites. Support for sites (e.g. clinics or health posts) where connectivity is low or intermittent.

Types of Locations in Case #1: Offline Outreach Worker scenario

Types of Locations in Case #2: Offline Sites

Types of Locations in Case #1: Offline Outreach Worker scenario

Types of Locations in Case #2: Offline Sites

Priority principles

If you are working on Offline-related problems, your approach & designs should address:   

  1. Users need to clearly understand that they are offline. This is especially important because so much EMR functionality will be limited while they are offline. There should be no surprises/mystery about why something isn't working as it normally would with good connectivity.  (i.e. "Oh, this isn't working - but clearly it's because I'm offline.")

  2. Device storage space is very limited. This means it will be very important to limiting the amount of data that gets stored, and reducing the scope of the required data. Narrower data requirements = better.

  3. Patients move around - a lot. The data will have to as well. This means that their offline record needs to, at some point, sync to a shared database that another site will be able to access and pull from, so that there is greater chance that the patient's care information will be shared across locations, even when connectivity has been spotty for one or both care locations. 


Case #1: Offline Outreach Workers

Summary: Community Health Workers, aka CHWs, are people who are trusted by their community to provide health-related assessments and education. They usually have no medical nor nursing training, and may not have secondary-school-level education; however, they have usually been trained in high-level health topics such as pediatric diarrhea. They may have even experienced a particular condition themselves. (In HIV Maternity care, this role is often instead referred to as a Mentor Mother: A woman who has gone through the HIV + pregnancy journey herself, and now helps coach other women through the experience.) In HIV programming, a nuanced CHW role is the Outreach Worker: a staff member who follows up with clinic patients to make sure they are attending appointments and taking medications successfully (more detail below). 

This use case focuses on the Offline Outreach needed for OpenMRS by Outreach Workers. (For more nuanced CHW/outreach use cases, we recommend tools specifically designed for these users and use cases, such as Medic Mobile/CHT, CommCare, mUzima, etc.)

Offline Outreach Workflow Goals

Type

HIV Outreach Worker at Ampath

Hypertension Peer at Ampath

HIV Testing/Counselling in Community

Counsellors & Psychologists at ICRC

Physical Therapist at ICRC

Type

HIV Outreach Worker at Ampath

Hypertension Peer at Ampath

HIV Testing/Counselling in Community

Counsellors & Psychologists at ICRC

Physical Therapist at ICRC

Role Overview

As an HIV Outreach Worker, I am responsible for the follow-up of dozens to hundreds of patients. If I am employed by a larger site in a rural area, there may only be myself and 1 other Outreach Worker. At the main site, I am responsible to:

  • call patients before their appointment (so they remember to come) - there may be as many as 200 I have to call before a typical busy clinic day!

  • call patients who missed their appointment yesterday (so I can try to re-arrange another date for them)

  • call patients who we haven't heard from in a while

  • If I can't reach a patient by phone, I often have to travel to their known home location to try and find out what has happened to them. This travel scenario is the focus of the offline workflow. 

I need to delivery blood pressure medications to patients who need refills of prescribed medications.

Our peer workers go visit the patients in the community so that they don't need to come back to the clinic.  

CHW goes to where patients live (away from clinic) to do HIV testing in communities. 

Needed for OHRI (post-MVP)

Travel to provide mental health support.

Need to conduct assessments in the field

Current Workflow

  1. (Patient already exists)

  2. I create a list of which patients I need to follow up with, and where I need to go to find them. (Some sites have set up EMRs, like AMRS, that will auto-generate this list for the Outreach Worker; other sites still use paper-based patient tracking systems. In that case the Outreach Worker has to manually review which patients were scheduled vs which didn't attend clinic recently, and manually create a list of missing patients.)

    1. The "where" can be challenging since not all patients have a formal address. A common solution is a hand-drawn map on a form, which the Outreach Worker can follow to find the patient's residence.

  3. I gather the forms I need to help me get there: i.e. existing patient forms, e.g. the hand-drawn home address map

    1. Outreach Locator Form - Ampath (used when patient is seen in person at clinic to document where & how an outreach worker could find them in the future)

  4. I gather the forms I'll need to record information during the visit: e.g. blank outreach documentation forms

    1. Defaulter Tracing Form - Ampath (used for outreach follow up visits) 

  5. I travel to the patient's dwelling

  6. I record notes about the visit

  7. I manually enter the paper notes into the EMR system when I am next physically at the location with a device & connection.   

Background: 

  1. (Patient has already been created)

  2. I can only afford 1 week, I'll need a refill → rather than asking pt to come back, there's a peer who will visit them and deliver drugs. 

  3. (Locator form used?)

  4. Document that drugs were given to patient. (FORM TO BE ADDED)

  1. Go to where patient is

  2. Register patient on offline device





Other Notes

More user stories for HIV Outreach Workers here, with a focus on needs from lists: https://docs.google.com/document/d/1_m7oGdlS07X1M0bztaL1GZX6Q7_8RY7dg3Omo5Jft7U/edit 

They'd ideally like patients to also e-confirm that they received the drugs.









Envisioned Workflow

User Story

Corresponding Offline Feature Requirement

User Story

Corresponding Offline Feature Requirement

At the connected site: I need to identify which patients I need to follow up with, and where I need to go to find them.



At the connected site: I need to pick the patients I will need offline so that I can access their information and complete forms on them while in the field. 

Search for set of patients to use offline - download some set of patients to the device, save some set of their data. 

Ability to review a limited set of data about that patient (see "Data Required" below).

While offline: I need the system to be password-protected, so that my patient's very sensitive data (e.g. personal information, HIV status, etc) is not accessible to others if a tablet or computer is stolen or lost while I am travelling.

Login

While offline: I need to document my findings, so that there is a record of the outcome of the patient for reporting purposes. 

Collect form data offline (Ampath needs AMRS Forms to be supported - not every form needs to be supported though)

Save patients

Back in a place with internet: I need the information to be added to the system when I get back to a location with internet connection, so that I don't have to manually enter the data and so that our program has the information it needs for reporting purposes. 

Send data collected offline to a server

Should probably be an explicit "send the data" workflow.



Current Project Status

Current Project Status

Who: Mekom and Ampath are collaborating through the Microfrontend Squad, based on a shared need (and more general community need) for Offline EMR workflows. Key contact: @Jonathan Dick

When: Starting week of March 20, 2021, there are 2 days/week of dev time focused on Offline mode, starting with the technical background tasks that will need to be handled (probably need more detail on that here?). 

    Design Cycle Timeline: Hopefully a short UX/Design Cycle will start early April, 2021

What this project is not

  • Not trying to solve offline collaboration (like the synchronous collaboration someone can do in a Google Doc). The scope of this project is limited: Anything that requires collaboration or knowledge sharing while still offline shouldn't be visible (e.g. orders, editing).

  • Not a redesign of a whole EMR to an "EMR Lite" that looks very different. The look and feel should still ultimately be the same as much as possible, or at least consistent with the look and feel of the OMRS 3.0 RefApp UX. 

  • Not aiming to include most functionality of a typical EMR. Functionality will be limited to the most basic of workflows.

Basic Offline Extensions: Data Required for Outreach Worker

Extension

Category

Specifics

Notes

Extension

Category

Specifics

Notes

...

Demographics

  • Name

  • Any IDs

  • Contact info (Address, Phone #)





Allergies







Conditions







...








Case #2: Offline Sites

Summary: Users with this problem want to enable healthcare users to have some basic EMR functionality where they typically have low or no internet access, such as in a clinic or in a health post (visual examples of these types of sites below - example photos are mostly from real-world OpenMRS implementations!). These sites may have internet problems for a variety of reasons: there may be no network service in the area, or spotty/poor/intermittent service, or there may be intermittent power problems that can last hours or days causing the routers not to have power (e.g. the solar panel blew off the roof last night and broke, or the generator ran out of petrol and it's going to take a few days to get more fuel). 


Case #2 is not designed to address Community Health Worker (CHW) / Outreach Worker use cases. CHWs' workflows are separated from a clinic or more traditional clinical team, which means they have different offline requirements that don't have to consider clinic workflows, nor do they necessarily need to get data updated at different locations relatively quickly, because there is often only 1 or a few CHWs responsible for a given residential community - they go to the patient. In contrast, patients tend to travel to a variety of clinics/centers. (For more nuanced CHW/outreach use cases, we recommend tools specifically designed for these users and use cases, such as Medic Mobile/CHT, CommCare, mUzima, etc.)Things that Case #2 is not:

  • Case #2 is not a redesign of a whole EMR to an "EMR Lite" that looks very different. The look and feel should still ultimately be the same as much as possible, or at least consistent with the look and feel of the OMRS 3.0 RefApp UX. 

  • Case #2 is not aiming to include most functionality of a typical EMR. Functionality will be limited to the most basic of workflows.

Offline Site Workflow Goals

As a health care worker at a Health Center or Health Post, I may see many, many patients on any given day. There are often only a small number of healthcare staff. At small Health Posts, there may only be 1 clinician such as a nurse, and no one else.

User Story

Corresponding Offline Feature Requirement

User Story

Corresponding Offline Feature Requirement

I need to clearly see when I am working offline, so that I'm not confused about why some data is suddenly no longer available. 



I need the system to be password-protected, so that my patient's very sensitive data (e.g. HIV status) is not accessible to others if a tablet or computer is stolen or inappropriately used.

Login

I need to be able to find my patients' records so that I can see a minimum set of background information that informs my care decisions while I am seeing them, even if my internet goes down at that moment or for that day or for a few days.

Search for set of patients to use offline - Save some set of patients, save some set of their data. 

Ability to review a limited set of data about that patient (see "Data Required" below).



I need to update key things in the patient's record so that this information is available to me if they come back tomorrow. 

Collect form data offline

Save patients

I need the information I update to be available to other nearby locations who might also see this patient sometime soon, so they at least will have access to recent data as much as possible.

Send data collected offline to a server