OpenMRS Connection to External Services

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

Thoughts and comments are welcome


Is this related to? About the openmrs-eip category


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?

1 Like

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

1 Like

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.

OAuth 2/OpenID Connect is another story though, for that you need a module, and there is one:

@mksd Where can I find some “OpenMRS” use cases for configuring camel?

I need to send back the question actually, what are your integration use cases?

Examples would be:

  • Integrating OpenMRS with a LIMS.
  • Integrating OpenMRS with a RIS.
  • Integrating OpenMRS with a drug inventory system.
  • Integrating OpenMRS with a billing system.
  • Integrating OpenMRS with a FHIR store (for whatever purposes).
1 Like


  • Integrating OpenMRS with a client registry
  • Integrating OpenMRS with a shared health record server

The question would be how can i setup the configuration for this metadata and provide a way for each site to configure its own values

1 Like

Ok :slight_smile: 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?

Are you intending to use FHIR’s International Patient Summary as a way to wire data to the SHR?

Hopefully we have to do exactly that in another country, if our project happens you may be able to piggyback.

1 Like

thanks @ssmusoke for starting this, seems to be the right season :+1:

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

Hi @gcliff, you are almost correct.

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.

Cc @akimaina :arrow_up:

1 Like

@mksd thanks for the clarification :+1:,

so openmrs eip in this case is doing the work of the middle ware since it relies on Debezium and Camel ?

great job @wyclif on fine tuning openmrs eip

openmrs-eip is the middleware app. In a complex real world setup it would likely be one of the multiple middleware apps.

1 Like