Continuing from this Slack conversation.
We have several emerging projects that require integration / communication between OpenMRS and external systems. These range from PACS systems, lab systems, client registries, and shared health records in both facility-level networks and national HIEs.
I am aware of many different initiatives and approaches that have been used to cover similar use cases, from Ozone’s approach that utilizes a number of separate “EIP” applications that run independently of OpenMRS, to the Bahmni approach that leverages Atom Feeds, to a number of modules that have been authored to achieve specific integrations.
In all of these cases, there is a common workflow that needs to be solved:
- Listening for a particular event or events to occur in OpenMRS
- Adding entries to a persistent queue in response to these events
- Asynchronously performing some logic (usually constructing a message and sending to a remote endpoint) for each queue entry
- Tracking whether the logic was successful or not, and recording this status and any relevant error messages
- Retrying any failed queue entries on some sort of schedule, depending on the application and the nature of the failure
- Providing a mechanism for administrators to be alerted to failed queue entries and a mechanism to view and manage the queue and resolve any persistent issues.
It seems that some (though generally not all) of this workflow has been implemented many different times in various places.
-
OpenMRS EIP has it’s management database, which consists of
debezium_event_queue
which contains all messages, andsender_retry_queue
which contains failed messages in need of reprocessing. -
The Atom Feed module creates
event_records
,event_records_queue
,failed_events
,event_records_offset_marker
,markers
, andchunking_history
-
The labonfhir module appears to create a
task_request
and afailed_task
table -
The PIH pacsintegration module creates a pacsintegration_outbound_queue table.
-
The Client Registry module appears to acknowledge the need for this in it’s optional
clientregistry_item
table
Other module that do similar things include:
- sync
- ugandaemr-sync
- Many others that I haven’t listed
It seems that we might be well served by tackling this problem generically in a module that can provide support for the workflow described above, that can be shared across various use cases. Many of the above modules may still create their own specific data model tables where needed, though the hope would be that they could leverage this common module for tracking success or failure and retries of communication with external systems.
I’m interested in gathering perspectives as to pros and cons of working towards such a general-purpose module.