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:
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.
Case #1: Offline Outreach Workers. Support for Outreach Workers who need to travel to remote locations.
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 |
---|---|
Priority principles
If you are working on Offline-related problems, your approach & designs should address:
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.")
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.
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 |
---|---|---|---|---|---|
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:
| 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 |
| Background:
|
| ||
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 |
---|---|
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 |
---|
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:
|
Basic Offline Extensions: Data Required for Outreach Worker
Extension | Category | Specifics | Notes |
---|---|---|---|
... | Demographics |
| |
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 |
---|---|
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 |