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:

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.

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. 
   
   

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

Envisioned Workflow

Basic Offline Extensions: Data Required for Outreach Worker

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.