Following this call for collaboration and at last week’s FHIR Squad meeting, @moshon suggested setting aside some time to dig into the architectural designs for Bahmni and OpenMRS.
When Thursday, 3 September 2020 at 6:30pm IST | 5pm Nairobi | 4pm Cape Town | 2pm UTC | 9am Boston | 6am Seattle
Just a few comments on the discussion we had yesterday and the decison regarding adopting the propsed architectural design aproach for bahmni, specifically about the use of the atomfeed server
Note that bahmni is not using a fork of openmrs-atomfeed, rather its completely another module.
However that said , The Bahmni Atom feed module doesnt have any dependence on any Bahmni specific module and doesnt require any Bahmni specific module , hence it can easily be adopted in the platform.
But first we need a design meeting to discuss in the first place whether we shall use the atomfeed server , or the Dbsync approach from Mekom
So the Atomfeedmodule of openmrs does contains a hibernate interceptor that captures the hibernate level events. What is the difference between this approach and the atom feed module of bahmini ?.
And Atomfeedmodule of openMRS is firing events beforetransaction means before transaction is committed.
In summary , while the OpenMRS Atomfeed uses Hiberante Interceptors ,
The Bahmni Atom feed simply wraps advise classes around some Core Service classes like PatientService ,PersonService ,ProgramWorkflowService and capture events at the service layer level.
it fires events after the saveMethod in a given service class is called and returns
@mozzy thanks I also had a look yeah it only fires save events. Yeah, It implements AfterReturningAdvice which is better for an analytical solution than firing event before a transaction is committed as we do in openmrs-atom feed module.
But have only a limited set of resources available right but can be extended easily without much effort it seems.
And exactly as u said it doesn’t depend on any other bahmini module. But to save the fired events I think it is using ICT4h atomfeed server if am right. But in openmrs atomfeed also we are using the same way.
It’s actually fairly trivial to use openmrs-eip to listen for whatever changes you’re interested in from OpenMRS, and propagate them as their FHIR representation (to wherever they need to go).
@ruhanga is doing just that with a FHIR bundle patient + service request for a new LIMS integration.
@ayesh where to would your FHIR resources need to go?
in the Proposed architecture ,
we want to push the Fhir resources to a middle ware component ,
Open-HIM, which will forward the Payload to the SHR , HAPI-FHIR server in this case
@mozzy it’s perfectly fine to do a FHIR communication channel between OpenMRS and OpenHIM with openmrs-eip in the middle. It’s exactly for such purposes that it was designed.
In this case you wouldn’t use its dbsync component (that’s an OpenMRS-OpenMRS only thing), it’s just about writing a couple of Camel routes to hydrate Debezium events with FHIR messages, and then making REST calls to OpenHIM.
perfect @mksd , i think thats the approach we would want take for this project . We will dicuss that approach more in the next design call . It woud do us very good if you can even attend our next call
cc @ibacher@dkayiwa@jennifer
@mksd out of nowhere . So isn’t dbsync the component which listens to mysql bin to retrive events ?. Or it is not and camel can be configured directly listen to events ?. I am asking because I am not familliar with any
. So isn’t dbsync the component which listens to mysql bin to retrive events ?. Or it is not and camel can be configured directly listen to events ?. I am asking because I am not familliar with any 