As OpenMRS starts integrating with external services, I think it is time consideration was given to a module which provides the ability to connect to external services in a consistent predictable way using various connection methods
While this may be complex, my thoughts are that this should be a wrapper around various Java connection libraries for basic authentication, OAuth, OpenID etc with a UI to store the connection information in a secure local file storage so that it can persist across restarts
This can also allow for specific connection names to be created without credentials which can be filled later
I have seen lots of connection information in the global property table, and this will bring that sprawl under control
It would make sense to me to use Camel wherever possible. For everything else, I’m thinking we should leverage Spring maybe with a few handy wrappers?
Actually no, this is just to provide secured connections to other services, Email servers (there is a mail component), SMS Services (users should be able to receive messages, reminders etc from the EMR), Lab Systems (you do not want your EMR to just post data)
Basically this is to support authentication with external systems and services, in a consistent matter, no idea if Camel can do SMTP, FTP, Key based authentication, Basic Authentication, OAuth etc and whatever else is out there to send or pull data
The short answer is that yes, Camel can do most of those things and more, i.e., it’s not primarily a tool for authenticating to external services, but a tool for sending and receiving messages from external services that has authentication built-in to enable doing that. It has a large number of components to talk to various kinds of services.
@ibacher I did not know Camel had all those, so that makes alot of sense. The question is to how to integrate it into an OpenMRS module, so that it can use the global property table or local configuration files
@ssmusoke the short answer is that you don’t. You would keep all integration routes at the middleware level outside of OpenMRS. However it is fine (as in “doable”) for your routes to be driven by OpenMRS global properties, although we would definitely not do it like that in most cases.
Ok I don’t pretend that we can setup your HIE through one liner exchanges here but…
Typically your Camel routes (within openmrs-eip) are being configured through Spring Boot app properties defined in an XML config file. So each Spring Boot app deployment will need its configuration XML file. I guess you will have a common configuration for a whole bunch of sites?
thanks @ssmusoke for starting this, seems to be the right season
I am new to openmrs connection with other systems through different eip patterns , so feel free correct me if am wrong in any way.
Some of the use cases @mksd has listed above like the one of OpenMRS with FHIR store is going to be implemented in the coming analytics engine work .
Also the proposed architectural structure of PLIR shows away to extract data from an openmrs instance by using camel with embedded debezium to track db changes in the mysql binlog and generate the corresponding fhir resources to be sent to the middle ware system which finally connects the fhir resources to the SHR ie HAPI FHIR server
Except that it is just the middleware that does it all:
It comes with Debezium to track events from the source. The source is OpenMRS’ MySQL binlog.
From each event an appropriate Camel route decides whether it is relevant or not. For instance if the business requirement only involves the integration of orders, then you don’t need to take action on persons, or patients.
It hydrates the Debezium event into a model.
The default model should be FHIR.
If FHIR can’t be used, the model can be anything else, such as OpenMRS REST WS resources.
The hydrated event, so the model, is routed to wherever it needs to go with further Camel routes.
Btw for those who have not been using openmrs-eip (yet) for whatever reason(s), I would like to notify them that a lot more stuff was added recently by @wyclif. Specifically an entire mechanism of error handling and replay of failed events.