Offline-first apps are appropriate for many clinical environments

A nurse using the offline-first Simple app in rural Punjab

With an offline-first approach, apps like Simple are always snappy and responsive, so clinicians are never waiting while they treat patients.

Let me set the scene. A nurse named Ravdeep works in a busy clinic in a rural hospital in India. Patients are lined up outside her door in a chaotic line all of the way down the hall. Ravdeep is responsible for taking blood pressures and blood sugar measures for each patient. She quickly enters their data into the Simple app on her tablet, and sends them to the doctor if they appear to be hypertensive or diabetic.

This public hospital isn’t fancy, but you might be surprised to know that Ravdeep’s clinic has excellent 4G internet. In fact, much of India is covered with strong, affordable mobile networks. So, why would we choose to make an app like Simple using an offline-first approach?

Offline-first has several upsides, but the primary benefit is that the app is always snappy and responsive, so clinicians aren’t waiting for their app to talk to the cloud during patient interactions. In a busy clinic like Ravdeep’s, this is a crucial feature. In countries like India, Bangladesh, or Ethiopia where a patient encounter is often less than 5 minutes, every second counts and therefore every call to the server matters.

The big secondary benefit is that the app will work in the corners of India with limited internet. In a country as diverse as India, this is crucial.

What is offline-first?

A typical clinical app is in constant contact with a remote server, so each time patient data is updated it gets saved on the server. Designing an app offline-first is different because that data is saved locally on-device and is later “synced” or saved to a remote server. That means that the app will always be able to function with or without online internet. But, it also means that you need two databases with one on the device itself and one on the server and they must be kept in sync.

Pros

  • Works fast every time. Every second counts in a healthcare facility. Offline-first software is incredibly snappy. For us, this is the #1 benefit to going offline-first.
  • Works offline. The most obvious benefit of offline-first is that the app works when internet connectivity is low or really spotty. This gives Simple the flexibility to work in places where internet access is intermittent.
  • Works on a wide range of devices. The Android app is being used in public health facilities by users on their own personal devices. Having the ability to adjust how often we push and pull data allows us to optimize resources like battery, network usage, device storage, etc.
  • App continues to work without a central server. A user can continue using a fully-functional app without syncing with a central server if they wish to do so. This lets small private practitioners track the health of their patients without sharing their data, if they wish to do so.
  • Minimises the loss of data. Data is never lost even if our servers are unavailable. This gives us some breathing room during maintenance and upgrades.

Challenges

  • Sync is really hard. We constantly run into challenges with syncing. If the app doesn’t sync regularly enough to the server, nurses get confused and frustrated. But if we sync data too aggressively we can drain the nurse’s battery. Striking the right balance is tricky.
  • Doubles some of the work. As you can imagine, having two complete databases means a lot of back-end and front-end coordination and duplication of effort.
  • Multiple users in one facility. Inconsistent sync is a problem for one healthcare worker, but in team-based care it is even more problematic. The local database on each of the nurses’ phones is not consistent, and this can lead to confusion where one nurse will often see a different (more recently updated) view of the data.
  • Deleting data and resolving conflicts. With multiple users, it’s very possible to end up with data conflicts that must be resolved. For instance, one user edits a patient record but before she syncs data another user edits the same data on their device. It’s possible to resolve conflicts, but this adds to the complexity of the software.
  • Maintaining backwards compatibility. Making changes to the API can be very difficult. The API needs to work across many versions of the app, each of which have a slightly different understanding of how data is structured.

What we learned so far

The Simple app is being used in over 400 hospitals in India to manage over 190,000 patients with hypertension. We are constantly learning. Here are a few lessons we learned so far:

Physical BP Passports — the QR code contains a UUID

UUIDs are your friends
Since the records are created on the mobile app and synced to server, we need an identifier that is easy to generate and is unique across all the devices. This makes UUIDs an ideal choice for our primary keys.

  • We also use UUIDs in our BP Passports (temporary identity cards issued to patients to easily find them in future visits). This allows us to print these cards from any location without fear of duplication.
  • The spec for UUID v3 allows us to deterministically generate new UUIDs based on a hash. Using this version, we can easily integrate data from external systems without having to maintain references in either of the databases.

Tracking time is really important
In an offline first app, the changes made by a user may not be reflected on the server for a long time, which results in old changes overwriting newer ones. To prevent this, we track when the change was made on the mobile app and the time when the change was seen by the server. With both times we can determine and keep the relevant changes. This is also known as bi-temporal modelling and this blog post provides a nice introduction to the concept.

Limit what data gets synced
When we started, every time a user registered with Simple we would sync all of the data from the server starting from the earliest record. This worked fine when we only had a few facilities, but as the number of patients in the database grew, we started facing two problems:

  1. The user would have to download the entire dataset, a large part of which was irrelevant to the user. It is uncommon that a patient visits facilities in two different districts.
  2. Syncing from the earliest record first would result in users waiting for an unknown amount of time to get all the patients in their facility.

To improve the user experience we now sync data only for facilities within their district and we sync data for the user’s own facility first. This reduces the initial load and lets the clinician to start recording her patients quickly.

Is offline-first worth the added effort?

Going offline-first was one of the best decisions we made in our technical architecture. When we watch a nurse in a busy outpatient department, it’s apparent how crucial performance is to her day. We have seen clinicians treating up to 200 patients in a single day — every extra second in a patient interaction at that velocity multiplies quickly.

Committing to offline-first also has opened up more deployment opportunities for Simple. In the next few months we will deploy to several locations where internet access is inconsistent. When our government partners asked if we could handle these environments, we could confidently say “yes!”

Simple is a free, open source, project through Resolve to Save Lives. If you are working on similar software and you have questions about our offline first approach, look at our code and documentation and get in touch with us. We’ll be happy to chat with you and explain in more detail what we’re doing. Thanks!


Offline-first apps are appropriate for many clinical environments was originally published in Simple on Medium, where people are continuing the conversation by highlighting and responding to this story.

Training, the Simple way

We experimented with several training methods: a short video combined with in-person support works best for us.

One year ago (in October 2018), we piloted the Simple app in five public health facilities in Punjab, India. The original process of teaching healthcare workers to use Simple in pilot hospitals involved in-person trainings from members of our team. We flew from Bangalore to Bathinda, spent a week visiting one facility each day, and taught healthcare workers how to use the app. We’ve come a long way since then.

Simple is now used in over four hundred health facilities in two states. Intensive in-person training is hard to scale, so we had to figure out how to make it easier.

Most other clinical software requires significant investment in training. One goal of Simple is to be able to get a healthcare worker up and running with minimal assistance, within an hour of installing the app. It’s a high bar, so we tried many approaches to explain Simple to our users.

In brief: A short, instructional training video with examples worked best by a long shot, but here are some other ideas we tried.

Tour on the home screen

Our first attempt at onboarding had a basic ‘tour’ with static, abstract screenshots of the functions of Simple.

First attempt at onboarding users

When our user tester Tanushree Jindal watched users trying the app for the first time, she observed that most users went straight for the “Get started” button, without scrolling through the screenshots that we had put together. Not great.

Paper training handbooks

We created a quick handbook that we could leave behind at in-person trainings. The handbook was pretty helpful, but keeping it updated was a challenge. Besides, they were not easily accessible unless we hand-delivered them.

Training manuals

Coach marks!

We then came up with the idea of using ‘coach marks’ to guide the user through the functions of the app. Maybe we could introduce each feature contextually to our users?

Coach marks to contextually introduce new features

We ran extensive usability tests with nurses and realised that there were simply too many coach marks to read. Coach marks were either ignored or got in the way. This didn’t work well either.

A simple video worked best

During field visits, we identified that a brief, engaging training video with demonstrations could have a lot of impact. So we quickly recorded a friendly video where we enacted the key activities in Simple. This worked really well during user tests and we learned:

  • Almost all healthcare workers watched the video
  • After 5 minutes, users became restless and lost interest
  • After watching the video, users could explain the app back to us
  • Nurses felt relatively confident that they could use the app after watching the training video

We edited the original video down to a crisp 5-minute film that showed a healthcare worker (me!) caring for a patient with hypertension at their clinic. This really hit home, as it was a very relatable setting for the primary users of our app.

We plan to make the recording available in multiple regional languages, so users can watch it in the language of their choice.

Where we are now

Today, the video is part of our short, in-app onboarding process for Simple. A nurse or a doctor can install the app from the Play Store, watch the training video as part of the registration flow, and learn how to use Simple.

The video is always available inside the app, within the built-in HELP section. One key benefit is that the video is nice, but not too fancy. As Simple evolves, we can easily replace it with an updated film that is more relevant.

Current onboarding flow

In addition to users, trainers have given us very positive feedback on the video, as it has proven to be a valuable tool for in-person trainings. Program managers, who go to the point of care to guide users on how the India Hypertension Control Initiative program should be implemented, play the video to demonstrate how Simple fits into the clinic workflows.

What trainers and users have to say about the video

What’s next?

Our takeaway from this exercise? Every mode of training had merits, but a contextual demonstration is a powerful tool that seems to hold a user’s attention. We have since recorded a few other videos that demonstrate specific flows in the app, and these have been received with equal enthusiasm.

The goal for the program is for it to eventually be entirely self-sufficient. We believe that by empowering users to teach themselves, we are taking the first important steps in that direction.

Credits

Thanks to Daniel Burka for scripting the first draft, and Anand Rama Krishnan for making us look good in the video. Also, thank you to Akshay Verma and Tanushree Jindal for user testing in the field. :)

Opening shot from the training video

Training, the Simple way was originally published in Simple on Medium, where people are continuing the conversation by highlighting and responding to this story.

From wings to cups

I have been using Whisper winged sanitary napkins (also called pads) for as long as I can remember. Actually, always. I remember this really well. When it all began, I didn’t know there were alternatives. There was no one to talk about the alternatives. I learnt about tampons somewhere down the line, high school I think. But somehow that never made me change my mind.

I had gotten comfortable with my usage of pads.

I had always known (at least whole of my 20s) that using pads is ecologically damaging. I am regularly creating non-compostable, non-recyclable waste that is probably burnt or ends up in a landfill. But that is not what triggered me to make this change. It was the rashes, the irritation, the discomfort, and the smell.

It took me close to 10 months to make the switch. I bought my menstrual cup in September 2018. I started using it on and off. At first, my worry was leakage. I got over that in the first month by wearing a panty liner with the cup whenever I was worried. It took a couple of months, but eventually I stopped worrying about that and using liners. Then my worry was using it day to day, in office, in public spaces, specially emptying it or washing it in a public bathroom. Luckily, I am not a heavy bleeder and slowly I got used to using for a stretch of time without checking on it every few hours. And today finally, I am using it outside in an office space without giving it a second thought. It feels like an accomplishment, to be honest. No more unmanaged garbage, no more stealth black polybag or brown paper bag wrapped pad buying from middle aged men and women at pharmacies who think just a glimpse of the pad to the outside world can cause a natural disaster.

A lot of people I know got comfortable with a cup quite easily. One of the reasons I wanted to write to this is to say that it is okay to take your time. If it feels uncomfortable in the beginning, give it a little bit of time, try a different size maybe. Don’t get discouraged and chalk it up to “it is not my cup of tea”. Use it once in a while on your 3rd or 4th day when the flow is decreased. Practice cleaning it in the comfort of your home before you try wearing it outside. Read about other people’s experience or talk to them to see how they went about using it. It is definitely worth the effort, I can say that for sure.

I didn’t do a lot of research into choosing my cup. It was an impulse buy, really. I saw it in a storefront (not in India) and asked the lady in the store a couple of questions before buying it. But post buying it, I read a lot about how to use, how to choose etc before I started using it. I found the information on the Mooncup website(https://www.mooncup.co.uk/) really helpful. You can read that or even ask questions here and I will try to answer them as much as possible.

While I was transitioning from pads to cup, I started using Carmesi (https://mycarmesi.com/) instead of Whisper and that helped me a lot as it is all-natural, completely biodegradable sanitary pads. If you are unsure about the cup, and want to continue using pads — switch to Carmesi.

I have never written a post before so please pardon my writing. Yes, it can happen. I am 28, a software developer, and not a blogger. I just wanted to share this small little accomplishment in the hopes that it might inspire someone else out there to make the switch. Hope it does. :)