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]
If you need to sync OpenMRS data across EMR nodes in a health system, you can explore 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.
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.
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.
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.
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.
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.
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.
@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.
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.
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.
