Thoughts on OpenHIE interaction in environments with intermittent internet connectivity

16 views
Skip to first unread message

Craig A

unread,
May 22, 2016, 9:26:45 PM5/22/16
to OpenHIE Implementers Network (OHIN)
Hi,

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.

Handset Systems

Data Caching in Handset Systems:
There are three types of data caching happening in systems that interact with Android handsets:
1) Caching metadata between the server and the handset so mobile workers can have the appropriate forms, access controls, etc available for entry.
2) Caching patient data on the handset so the mobile worker can have the information they need locally available regardless of internet connectivity
3) 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:
1) All locations should be able to be mapped between the server and the OpenHIE facility registries.
2) Mobile workers may represent health workers that should be mapped between the server and the OpenHIE HWR or HIS hierarchy.
3) 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 Movement:
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.

Thoughts

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?

Craig




Derek Ritz (ecGroup)

unread,
May 23, 2016, 9:58:00 AM5/23/16
to Craig A, OpenHIE Implementers Network (OHIN)

Hi all.

 

There was a very simple but effective OpenMRS data sync app that Wayne (at Jembi) put together for the Medinfo 2010 demo. Jembi guys… is a version of that app still around? And could you maybe wade in with some of the experience designing/implementing it?

 

Warmest regards,

 

Derek.

 

 

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

 

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality.

--
You received this message because you are subscribed to the Google Groups "OpenHIE Implementers Network (OHIN)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implement...@googlegroups.com.
To post to this group, send email to ohie-imp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/0b7f4adb-14cf-4884-93ad-cf71167b36e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pierre Dane

unread,
May 23, 2016, 10:18:53 AM5/23/16
to Derek Ritz (ecGroup), Wayne Chelliah, Craig A, OpenHIE Implementers Network (OHIN)
Adding Wayne here - he hasn't joined this group yet! 

This was before my time at Jembi so I'm not sure.

By the way, Bahmni uses atom feeds to sync events between openERP and openELIS and other systems - no reason why this couldn't be extended for use with a central repo - we'll just need to transform the feed to FHIR/CDA or whatever.

Pierre 


For more options, visit https://groups.google.com/d/optout.



--
Pierre Dane

Jembi Health Systems
Software Development Manager


Pierre Dane

unread,
May 23, 2016, 10:19:26 AM5/23/16
to Derek Ritz (ecGroup), Wayne Chelliah, Craig A, OpenHIE Implementers Network (OHIN)
The atom feeds are actually just an openMRS module so this should be available for vanilla openMRS as well.


Owen Heckrath

unread,
May 24, 2016, 1:21:55 AM5/24/16
to Craig A, OpenHIE Implementers Network (OHIN)
Hi All... My name is Owen Heckrath - Director Digital Health at Jembi Health Systems. Let me say at the outset that its great to be part of this group and I'm looking forward to some very positive developments coming out of our collective genius.

One post that immediately attracted my attention was Craig's thoughts on working within a setting of intermittent connectivity.

I am a firm believer that one of the major ways we will be able to improve the delivery of healthcare services in low resource environments is to move the locus of care for Primary healthcare from a clinic/hospital/facility closer to the Patients home/work environment.
This means that therapy monitoring, health education and prophylactic healthcare is provided away from the clinic, thus offloading the clinic healthcare staff to focus on Secondary health interventions.

That said, the only current workable solution to move Primary healthcare to the home is via the Community Health Worker (CHW) and one of the most effective ways to support the CHW's in their work is via connected mobile devices (Smartphones, Tablets etc.) This goes straight to the connectivity issue.
There are a multiplicity of projects, from multiple suppliers, on the ground enabling CHW's with mobile devices to provide a range of services to Patients and communities.
This is creating a notable and growing force of healthcare professionals (meaning they get paid for it) who are either providers or consumers of health information (data) and the pipe to collect or deliver that data is becoming increasingly mission critical - hence my interest in Craig's comments and questions.

I firmly believe that the Open Health Information Exchange provides us with a huge opportunity to plug into, and to service, the data flow pipe, from point of collection to point of decision and back to point of need. So I would be particularly interested to see what your creativity comes up with in the coming weeks.
As I said earlier on, its great to be part of this group.




Owen Heckrath
Director - Digital Health

Skype: owenheck

Ryan Crichton

unread,
May 24, 2016, 5:22:03 AM5/24/16
to Owen Heckrath, Craig A, OpenHIE Implementers Network (OHIN)
Hi all,

Intermittent connections are tough challenge. Previously for the Rwanda HIE we implemented a queuing system for OpenMRS that queued requests when a connection fails and retries those on a schedule. This worked well, however, we found ourselves needing that sort of functionality in many other projects. We have though about building a generic retry proxy out of the OpenHIM to handle this scenario for other projects. This tool could be installed locally and transparently and enable requests to be retried when the time is right. We haven't built such a tool yet, but it seems to be generally useful for parties looking to implement OpenHIE. The problem would be how to deal with responses where data is required for the PoC system to continue its work.

Just wanted to share some of the thought we have had around this.

Cheers,
Ryan


For more options, visit https://groups.google.com/d/optout.
--
Ryan Crichton
Lead Developer, Jembi Health Systems  SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

Craig A

unread,
Jun 2, 2016, 8:59:54 PM6/2/16
to OpenHIE Implementers Network (OHIN)
Hi Pierre,

I did a deep dive into the OpenMRS atom feeds. There are three versions currently available for OpenMRS implementers.

1) The legacy atom feed module was built in 2012, but no longer works with recent versions of OpenMRS. This module uses the events module and bubbles up any change in OpenMRS as an atom feed. If fixed, this is the most robust atom feed available. (doc | source code)
2) Bahmni uses an atom feed for the exchange of information between OpenMRS and ELIS. This is meant for the Bahmni implementation and relies heavily on the EMRAPI module.
3) The OpenSRP team recently forked the Bahmini atom feed and removed the dependency on the EMRAPI module. However, this still only provides atom feeds for the savePatient and saveEncounter events in the system.

I think it's a great way to identify changes to the system, but each needs work to be generically applied for implementations.

Sincerely,
Craig
Reply all
Reply to author
Forward
0 new messages