Adding new features to the sync module

AMPATH is investigating the sync module. We’d like to add two features:

  1. The ability to limit sync from parent to child by location. This allows us to limit the amount of data going back to children sites to only which is needed.

  2. The ability to request records from patients in parent on demand. This allows us to see patients at a facility who are either there for a one-time visit or transfer-ins.

Does anyone have a sense of how complex it would be to implement either of these features? How much dev time might be required?

1 Like

The short answer is probably tricky.

The first question would be location of what? Of the encounter? This in itself might be straightforward to implement but it might you might run into a lot of complications trying to prevent any related data (child obs, etc) from being synced. Sync fails hard / stops cold when it runs into an issue like this.

The second question definitely seems like something more appropriate for a MPI/Shared Health record.

And my general advice is to not use sync, especially in a large implementation. Sync does what it does relatively well, but the problem is when it doesn’t work you can easily get yourself into a big mess. My position here when talking about rolling it out across multiple implementations at Haiti is that we should consider another solution, or if we must use it, make sure we have a full-time resource to both maintain it and improve it.

Hey Burke,

First, I’ll say that our Rwanda program has been asking for these enhancements for while now, and we would definitely welcome this. @rubailly might be able to comment further. Specifically, we are interested in syncing everything up from child->parent, but only automatically syncing back down to the child any updates to patients who already exist on the child. and providing a means for syncing on demand other patients who exist on the parent and not the child. Theoretically I think this should be doable without too much pain, but overall my sense is that any major time investment in sync might be better spent on alternative technologies.

Our thinking of late has been that we would strategically try to move off of the sync module in favor of integrating with an MPI and SHR (as well as Terminology/Metadata servers for distributing content). We haven’t made it super far down this path, though @cioan has been working with the Thoughtworks team to evaluate adapting their FreeSHR project for this use: https://github.com/SharedHealth/FreeSHR

Would love to have more extensive design discussions around the best approaches here.

2 Likes

This is certainly disappointing to hear. We were very much hoping sync would be at least a decent medium term answer. @mogoodrich, when you say a full time resource - would a system admin suffice or did you specifically mean a developer?

We would be willing to invest programmer time into developing an alternative solution. Besides the thoughtworks option, did you look into the jembi option that was presented at the openmrs conference last year?

Would love to get a collaborative project going with PIH (and others) on this. Let’s set up a call in the near future.

For us here in Rwanda, we are much more interested in having feature #2. We want to automatically sync everything from the child to the parent server, but only few objects (…like patient identifiers, concepts, locations and other metadata) back to the child servers.

Other patient data (…like encounters and obs) would only be synced back to the child servers if requested.

We have two sync networks, one with a parent server and 21 child servers and another with 1 parent server and 12 child servers. Syncing everything back to the child servers results in a lot of errors and much of it is unnecessary traffic on the network as some patients may never travel to that particular health center/hospital where the data is being sent.

I’m also in favor of spending more time investigating other solutions but having this feature added to the sync module would help implementations that are already using the module while we are searching for better solutions.

For feature #1, the only objects I can think of that would be filtered base on location (health center/hospital location) in our case are reporting objects. Trying to limit obs and encounters or even forms and other metadata would probably results in a lot of errors and bugs as they always have references/dependencies among them.

@jdick, …based on the kind of errors thrown by the module, I think it would be better to have a developer doing the maintenance. You can check the sync bug blog to see the frequent errors and how they are fixed.

1 Like

The long-term solution for sharing data across disparate servers is not sync, but a (mini) health exchange, where only the information needed to be exchanged is exchanged (e.g., metadata and patient record updates pushed to remote servers and new patient data sent upstream) and the sharing can be distributed across different types of systems. Sync was designed to keep data on two or more OpenMRS servers synchronized and can do a good job of it with adequate supervision.

It might be worth considering how we could adopt/adapt work from OpenHIE, where the central server becomes the shared health record, metadata can be distributed across sites, remote sites send only the data needed upstream, the data exchange is far less fragile & easier to manage, and it can be made to work across different versions of OpenMRS, different distributions of OpenMRS, and even non-OpenMRS servers.

@jdick, as @rubailly says, you will need someone with technical skills. Whether is actually needs to be full-time, I don’t know. How many nodes would you be creating?

@rubailly about how much time per week do you think the team in Rwanda spends keeping sync up and running?

We will start with 11 nodes over the next 12 months. But ideally, we’d like to scale over the next two years to many more (number unknown and probably only limited by our ability to support from a technical perspective).

Yes, unfortunately that seems big enough that using sync could end up eating up a lot of support resources. Would be willing to discuss. Maybe at the summit, though I know that is still a few months away.

What really makes sync maintenance cost much time for us is the slow network we have. Most of our sites are using GSM modem connection and that was our last solution as we couldn’t get internet to most of our remote health centers. We spend one to two hours every morning monitoring sync to make sure that everything is working fine.

I don’t think it would be that hard to maintain a sync network if you have a good internet connection as most of the bugs are now known and can be fixed directly if you have quick access to the servers.

1 Like