A few years ago, we had experimented with an “offline mode” for O3 with the goal of allowing users to be able to download and interact with the EMR offline and then resync data back to the EMR. This post is a formal notification that we are retiring this iteration of offline mode and removing it from the O3 framework for now.
The existing offline-mode infrastructure did genuinely work and could support the use-case it was built for, namely users who wanted to be able to “download” patients create forms related to those patients and later reconnect to OpenMRS and upload those forms, etc. It’s really cool that this works and I think that much of the work here will serve as a model for how we pick-up and resume work on O3 offline, when that becomes possible.
There are two technical and one structural short-coming of offline mode as it was implemented that made it unable to be deployed in real-world settings. The two structural problems are:
- It was entirely built with the assumption that “connected to the internet” and “online” were identical. But, in point of fact, the relevant meaning of “offline” is “able to connect to the OpenMRS instance” regardless of whether the broader internet was available. This meant that, in some situations, the app would try to load in “online” mode even though it couldn’t reach the OpenMRS server and, worse still, that users who could reach the OpenMRS server but not the internet (as is common in many of the clinics we serve!) were treated as being offline.
- The offline-mode used a library from Google called Workbox to implement much of it’s app-saving and information downloading functionality. While Workbox is a great toolkit to make building service-workers (the technical bit that makes this all work) easier, it still requires a great deal of care. Unfortunately, our version of offline mode wound up being built around a caching policy that broke our ability to properly cache resources while online. Caching is one key way we make Javascript-heavy single-page applications performant. With caching broken, everything was being constantly re-downloaded.
Finally, the “structural” flaw I mentioned is that the app was being built to support users working with patient records away from the EMR, largely Community Health Workers. A community health worker program is important and being able to exchange data between a phone app that Community Health Workers can carry with them and an EMR is still a goal we support. However, building this into the EMR directly appears to be a mistake. There are enough differences between the kinds of data we want to be available and how it might be convenient to capture them in the field and how things wind-up structured in the clinic.
I still think there’s a future for an offline-mode in O3, but something a little narrower than what was built, focused on trying to keep users productive during intermittent unavailability of the EMR. This is functionality I strongly think the community would benefit from and we will try to identify resources and opportunities to build this out. In so doing, we’ll like use many of the same concepts. Workbox is solid, but it needs some more and careful consideration. The queueing mechanism built for the offline tools, storing data in the IndexDB and the pushing to the server is genuinely useful. We’ll also have to build out a way for a client to detect whether or not it can reach the server. Other things we’ll need to build are things like: a workflow for handling out-of-sync data (i.e., you made changes to a patient’s registration record while disconnected, but someone else did while connected and we can’t merge the two cleanly).