Setting up Bahmni with the Data Synchronization Module

Hello, I am a member of ASHA NPO.

We are planning to set up a system where Bahmini-docker runs on a cloud server and connects with two health posts in Nepal. The data should be synchronized among all sites. For initial testing, I ran three Bahmini-docker instances with sync-module (not sync-module2) in my local VirtualBox and verified that data was syncing properly among the containers.

Can I get any advice for further testing and operational workflow to set up the real system? In advance, thank you all readers.

◆ System Features

  • No other EMR systems exist
  • Only use the services which related the the following modules:
    • Patient Registration Module
    • Clinical Module
    • Reports Module

◆ Local Test Environment

[Bahmni Test Data Generator DefaultConf] — API —> [Child0_bahmni-docker] <— synced —> [Parent_bahmni-docker] <— synced —> [Child1_bahmni-docker]

Hi @masayuki.kubo :waving_hand:

If you need to sync OpenMRS data across EMR nodes in a health system, you can explore
:backhand_index_pointing_right: dbsync.

The dbsync project is used at scale by at least two implementations, however with non-Bahmni OpenMRS distributions. This should not be a major impediment but may have implications depending on the version of OpenMRS Core that you are running.

1 Like

Thank you @mskd for reply.

Could undestood some of the overview by checking the readme and your old some posts. I will talk about this with other members and gonna plan implementation test near future.

BTW Does sync-module also could be one of the choise in our system? I’d like to have more than option for our challenge.

We use the core version below

OpenMRS Version 2.5.10 Build 0

To be my knowledge there’s ever been three OpenMRS tools/software to achieve this:

  1. openmrs-module-sync
    • This should probably be ruled out because it is ancient and was designed for much older versions of Core. It’s worth noting that it has been used at scale in at least one implementation.
  2. openmrs-module-sync2
    • This should probably be ruled out because it never took off. It was meant to be a standards-based upgrade to the former but it never got traction, suffered some design flaws that became difficult to address and got abandonned.
  3. openmrs-dbsync
    • This is a different approach to the first two.
      Whilst it is still specific to OpenMRS, it is not a module and is run through a middleware (a Spring Boot app leveraging openmrs-eip under the hood). We had contemplated to make it much less specific to OpenMRS—which would be much better for a piece of middleware that syncs data between nodes—by exchanging Debezium payloads rather than OpenMRS-specific model entities. However, funding waned and this work was never executed. Not a huge deal though, it’s perfectly useable as it is.
2 Likes

1 openmrs-module-sync

→ Oh, I thought this was still maintained. Version 3.0.0 module requires OpenMRS core version 2.5.6 or higher, and the master branch keeps updating.

Anyway, the comparison will help me understand the background.

@mksd, thanks again.

1 Like

Apologies @masayuki.kubon, my bad, you are right, it looks like PIH/@mseaton did work on the older sync module to adapt it to more recent versions of Core (I hadn’t followed that this had happened).

This possibly makes it a contender as well as dbsync.

2 Likes

As far as i remember, the old sync module is not recommended for new installations. I think PIH is maintaining it for the sake of the installations that they already had in place running that module. If they were just starting afresh, they would probably use something else. dbsync is more modern than that old sync module, and hence more recommended.

2 Likes

@dkayiwa Appreciate your comment. We will try dbsync module soon. Let me post updates or qustions if there are any.

@masayuki.kubo it’s totally fine and appropriate to continue the discussion here, and we will be looking forward to your updates about trying out dbsync, but just a fyi that dbsync can also be discussed on the channel #openmrs-eip on Slack.

1 Like

I’d say this is accurate. We do continue to make fixes to openmrs-module-sync and PIH does use it in production at scale in Rwanda and Malawi, so it could certainly be something to at least evaluate and compare. However, it certainly is showing it’s age and does not get the kind of maintenance, upgrades, and active development these days that might be needed to truly rely upon it without developer capacity and processes to monitor sync.

A few additional points (@mksd please correct me if I misrepresent):

  • My understanding is that dbsync only supports 1-way sync, where as the sync module supports bidirectional sync. If bidirectional sync is needed, that might be an important factor.

  • Many implementations still prefer to manage a single application (eg. OpenMRS + modules) rather than multiple applications in a micro-service architecture. dbsync is a separate application which (I believe) requires yet another application (eg. a JMS server like ArtemisMQ). So there may be factors that make one more appropriate than another for a given implementation environment.

2 Likes

Well, 2-way sync is supported as implied by the sync mode here, it was never thoroughly tested though, neither has it been used in production by an implementation we know of, but it should work if fully tested.

2 Likes

@wyclif that’s great if it is supported. I was mostly going off of this documentation, and anecdotal comments I’ve read in the past.

1 Like

Yes the documentation was never updated, I guess because we were yet to fully test to guarantee functionality before updating it.

1 Like