Bahmni uses ATOM Feed synchronization (event notification over REST APIs) to allow services to pull for changes occurring in Bahmni. The Bahmni EMR (OpenMRS) publishes various event feeds, like Patient, Encounter, Lab, Drug feeds, and the other systems subscribe to these event feeds, to be notified of changes. Based on the "notification", the downstream consuming systems make a REST API call to OpenMRS, to pull relevant data. Typically a sync service is written for each consumer, that listens to these events, constructs the relevant data packets, and then pushes to downstream system (like ELIS, ERP, etc).
Different Components like OpenMRS, OpenERP and OpenELIS are kept in Sync using the "Atom Feed Based Synchronization". The following is the depiction:
Lets take an example of Drug creation in bahmni. The following are the sequence of events:
Administrators create Drugs using OpenMRS or using the "CSV Upload" feature on Bahmni's Admin module
Once the drug is created, an event is published (in the Drug Feed)
The "OpenERP atom feed service" contains batch jobs that are scheduled to consume these atom feed events.
The job then creates an event in OpenERP (or Odoo).
Bahmni uses an Atom Feed based framework created by ThoughtWorks ICT4H team for data synchronization between OpenMRS, OpenELIS and OpenERP (in fact also with Reference Data app). For more information on the underlying atomfeed implementation please refer to:
Underlying Database Tables for Atom Feed Synchronization Book-Keeping
The tables used behind the scene in Atom Feed are:
Used in Mode
This tables holds the list of events which are to be published by Atom Feed for others to consume. The category column is used to indicate the event types (like patient, encounter, etc).
Note: For the same patient updates there might be multiple rows. So to see unique rows: "select distinct object from event_records where category = 'patient';"
This table holds marker entries to indicate the records which have ALREADY been processed.
This table holds cached records for faster event process by the CONSUMER.
This table holds the list of events which failed and could not be consumed. They are retried later by a different event handler.
Note: The PUBLISH mode is when the system is publishing its events on an Atom Feed. The CONSUME mode is when the system is reading events from another system and writing/updating its own data based on consumed events. OpenMRS, OpenELIS, Odoo – all act as Publisher and Consumer depending on the scenario. For instance, when a Patient is created in Bahmni(OpenMRS), then Bahmni is PUBLISHER and ELIS/Odoo are CONSUMERS. When a Lab result is entered in ELIS, then ELIS is PUBLISHER and Bahmni/OpenMRS is CONSUMER of results. Therefore, these 4 tables will exist in each sub-system that acts as Atom Feed publisher & consumer.