I want to share some thoughts on working with systems that have the ability to work offline and in environments with intermittent internet access. We work with a number of field implementations that utilize handset applications with CommCare and a local EMR system OpenMRS. As an aside, I feel that other systems that provide two way data sharing between the handset and the server, like ODK 2.0, MagPi and OpenSRP follow similar workflows to CommCare.
Data Caching in Handset Systems:
There are three types of data caching happening in systems that interact with Android handsets:
Caching metadata between the server and the handset so mobile workers can have the appropriate forms, access controls, etc available for entry.
Caching patient data on the handset so the mobile worker can have the information they need locally available regardless of internet connectivity
Server side caching of all handset data in a central location for analysis, sharing among mobile workers, and aggregation
Caching metadata in these handset systems includes a subset of OpenHIE workflows. Here are some examples:
All locations should be able to be mapped between the server and the OpenHIE facility registries.
Mobile workers may represent health workers that should be mapped between the server and the OpenHIE HWR or HIS hierarchy.
Patient data collection forms are cached at the handset level. When interacting with OpenHIE, the forms need to be translated to a XDS.b and posted to the Shared Health Record.That means we need to maintain a map between the end user created form and a standard format.
There are a number of automated and human workflows when metadata changes in OpenHIE that need to be reflected in the local caches of these handset systems. For example, if a new mobile worker is created in the handset system, we may need to push that information to the HWR. Additionally, if a location is changed or renamed in the facility registry, we need to make sure our maps are updated.
Data is cached on the android handset and sync’d up to the server when there’s an internet connection. A bunch of information is pushed from the handset to the server in a short period of time. Each form is treated as a unit that is processed, with triggers to kickoff workflows in other systems. If we were to push data from the server to OpenHIE, there would be a major push of transactions at once. We need to make sure that each request is queued and processed appropriately, with the feedback being tracked for each form that was posted, with a full audit log available in the PoC and IL.
EMR Systems (OpenMRS)
The EMR systems are a little different. I feel that implementers would implement in a centralized architecture if at all possible because it’s a burden to manage a local EMR. Therefore, we can assume that a local installation of an EMR is needed due to challenges with the internet. There are points in the EMR where OpenHIE integration would improve workflows. One point is at patient registration. It would be beneficial to be able to search OpenHIE and pull down information about a patient when they enter the registration workflow. In an environment with intermittent internet connectivity, this item would work a percentage of the time and there needs to be a secondary workflow that activates when there’s no internet. Furthermore, there needs to be a ‘syncing’ workflow that allows PoC workers to match patient records against OpenHIE and merge them locally when possible. This workflow requires a lot of human intervention.
When working with OpenMRS, I noticed that there aren’t a lot of commands to post information to external web services. Instead, it’s up to a third party system to identify the changes in OpenMRS and act on those changes. We do this in a limited way through an atom feed. The atom feed bubbles up a list of changes in the system that kick off a number of queries from MOTECH, trying to discern what changed. Our atom client module pings the atom feed on a regular schedule looking for changes and kicks off a bunch of tasks that query the OpenMRS API and process the changes. Each task event could fail in the middle if the internet drops out and we have a retry mechanism to account for this.
I wanted to get these thoughts out here for others to evaluate. There’s complexity when dealing with offline systems, but it’s manageable. I feel that working through these issues as a community will help adoption of OpenHIE and expand our shared understanding when implementing. What do you think? Do you have experience with data syncing in offline systems? What are the greatest barriers you have run into that kept you from adopting OpenHIE?