Does anyone have any advice on whether the openmrs sync 2.0 module would work with Bahmni? Does anyone have experience using it in this way? @mseaton would this be something you have some insight into based on PIH experience?
We’re already running Bahmni at one site and are interested in setting up a satellite site that syncs data back to the existing site - exactly what the OpenMRS sync module seems to be designed for. Would be great to hear if it works (or should work) with Bahmni.
Thanks
Sync 2 has not been used by anyone in production. It requires some more development resources to be fit for such. @Mekom has developed an alternative solution, dbsync, which you may explore.
Thanks @dkayiwa I’ll get in touch with Mekom solutions. And you raise a good point - I’m actually open to any possible solutions that allow for bidirectional sync between bahmni installations at a central and satellite site
Thanks @dkayiwa for sharing the pointers to @gchan.
Mekom is an active maintainer of openmrs-eip. One of the internal components of openmrs-eip is ‘dbsync’, that helps support OpenMRS-OpenMRS sync through the embedded OpenMRS Camel component.
An important point to understand is that openmrs-eip enforces EIP around OpenMRS, but it is not a substitution to HIE patterns. In English: openmrs-eip solves low-level tech challenges around capturing data changes, orchestrating messages, routing messages, handling errors, … etc at the middleware layer.
There are a number of projects that currently leverage openmrs-eip’s dbsync to achieve one-way OpenMRS-OpenMRS sync as a proxy-HIE pattern within an OpenMRS-only ecosystem. We (at Mekom) do complement this with patient matching at the receiver end for instance, that thereby behaves partially like an MPI. Two-way sync will be on the roadmap for next year most likely.
Please don’t hesitate to get in touch privately if there is anything that you would which to fast-track through us, or publicly if you want to contribute to the current shared roadmap (that we are in the process of establishing.)
Cc @wyclif
Hi. I am unable to sync and push patient visit data that I saved on my Android device in offline mode. When I run a sync process, the data does not get pushed to Mysql database and OpenMRS. Does anyone know what the issue might be? Any help/advice will be highly appreciated.
Hi @mksd, thanks so much for the information.
I’m still trying to get my head around this and some of the concepts are new to me, so my apologies if some of my questions are a bit basic. After reading the documentation you linked to, am I right in understanding that your comment about HIE patterns reflects the fact that because openmrs-eip writes directly to the receiver database, that there is no checking about whether the data from the sender is valid in the receiver database (eg concept_ids exist and represent the same concepts in both databases)? Would this concern be negated if both the sender and receiver were using the same database (other than patient-transactional data)?
Since the sync is one directional then it would be suited to a satellite or mobile facility registering and managing patients and sending that data to a main site.
Can I ask too if there is any inherent reason why openmrs-eip could not be run alongside bahmni-connect on the receiver? Ie to handle some use cases data is synced from a satellite site using openmrs-eip. And for some patients whose data needs to be viewable offline this could be handled using bahmni-connect?
Thanks
Hi @gchan,
No worries at all! This is a complex topic and there is a lot to unpack, all questions are welcome to help yourself and the wider audience grasp the concepts behind exchanging clinical data between OpenMRS/Bahmni instances.
When I said that openmrs-eip’s dbsync module was not a substitution to HIE patterns, I just voiced a caveat to properly outlines what it does or doesn’t do. In short: it allows to exchange clinical data between OpenMRS instances, simplifying some of the typical HIE-related problems because it operates in an OpenMRS-only environment.
You would need to fully embrace HIE patterns when you cannot make much assumptions about the nature of the components within the HIE. For instance if you operate within a network of EMRs instances that need to exchange patient files, and that those EMR systems are from different vendors, then you cannot make too many assumptions. You may just want to require that they all speak FHIR and then orchestrate interoperability on that (high level) principle. But if you know that you operate within a network of OpenMRS EMR instances, then you can simplify a number of things because much of the interoperability potential arises simply from the fact that it is an “all OpenMRS” environment. That is what openmrs-eip’s dbsync does.
There is no concern about mismatching ids between databases, this is solved through the internal mechanics of dbsync.
Note that since you last wrote, the work that ensures that dbsync can support two-way sync has already progressed and is well on track. While it is not ready yet, you can either assume it will eventually be or you could get involved in fast tracking that part of the openmrs-eip roadmap.
Bahmni Connect is a completely different story. It is a mobile app (a PWA actually) that can cache some of the OpenMRS data to function fully offline for some time. It is just about in-browser data caching, it is a completely different topic than EIP or data exchange between EMR systems.
Hi @gchan
Good Day and hope you are doing well.
I just wanted to check if you came across any solution that facilitates bi-directional sync between bahmni.
Thanks in advance
We didn’t really find anything. We were trying to get something custom built but the company that was helping us with the development shut down before the work was complete. There was another group (Possible Health) that reported seting up sync between a commcare and Bahmni using motech but I can’t remember who it was. Bahmni connect didn’t really work for our purposes either. We had some initial discussion with Thoughtworks and they thought it might be possible to develop something.
Not sure what’s changed in the space since I last looked into it. Some of the existing solutions might work if your use case is not too complicated.