Supporting Multiple Sites using OpenMRS (Cloud & Centralized Hosting vs Multi-Tenancy vs Backups and more...)

Implementing
,
1

Hi all! As part of the work to provide great guidance around implementation, we are trying to figure out what types of large scale implementations there are and what kind of use cases do folks have for managing these large deployments, and what kind of tooling would help with that management? Pre-build dashboards and monitoring comes to mind.

There are a few types of implementations I’m thinking of:

Those with on-site servers, with connections for updates and to connect to central HIE components (Client Registry, Shared Health Record, Facility registry, National data repository, etc). I’m interested to know what kind of tooling would be useful here, and what sort of metrics we’d need (EG: Server Hardware Monitoring (disk space, CPU usage, RAM usage), OMRS is up or down, last time it managed to successfully send data, what version of OpenMRS is used, etc). What are some of the bottlenecks and pain points that exist in managing large deployments for on-site servers?

Those with multiple sites hosted centrally at a data center of some kind: How many sites are using a centralized server, what sort of connections to HIEs are supported, and what if any are unique metrics for these kinds of implementations? Is this feasible now with internet availability or is this part of a future strategy? What sorts of bottlenecks are you facing?

What sorts of tooling and guidance would be helpful? I’m thinking about htings like a scalable backup solution, a semi-automated deployment/update tooling, monitoring tools, and guidance on secondary data use pipelines for dashboarding and reporting at a greater than facility level.

This is all brainstorming, and I’m hoping you can brainstorm with me. We will be setting up some more opportunities for contributing your use cases as well.

12 Likes
2

Thanks @caseynth2 for reaching out to the community about those important topics :pray:

At @Mekom we do a lot of monitoring of our HIS/HMIS instances.

Many things could be said about what we do both at the infrastructure level monitoring and application level monitoring. For the latter, much of it is done alongside the HIS components without needing too much from them directly. However I’ll just show you a tiny example of the kind of stuff that we need to do in Ozone in regards to application monitoring of OpenMRS and that we wished we wouldn’t have to take care of.

Have a look at this Docker Compose file PR and specifically all the overrides that we need to do of OMRS_JAVA_SERVER_OPTS: OZ-546: Expose EIP and OpenMRS metrics endpoints by enyachoke · Pull Request #92 · ozone-his/ozone-docker-compose · GitHub

On the interoperability side of things… turns out that @ibacher helped us recently to put together something pretty amazing that we use a lot within Ozone: the openmrs-fhir Camel component. We have extended openmrs-eip to also behave as a FHIR event bus for OpenMRS by embedding this Camel component as a submodule (this is just awesome). In terms of tooling for all things interoperability within OpenMRS, to be honest, I think that just nails it, at least for us.

5 Likes
3

Some helpful relevant comments @caseynth2 made to me today that I wanted to record:

  • The use case people have when they ask for multi-tenancy is generally, “How can we make a bunch of OpenMRS’s talk to each other, so they can share the patient record across them?" Ultimately, often the underlying need is a Shared Health Record across sites.
  • Many people initially assume the easiest way to do this is by having a single database, a single EMR instance, for every hospital and every user and every patient.
  • Instead, we encourage a model where every piece of your approach is doing what it was built to handle - especially since implementers and Ministries generally end up needing the OpenMRS distribution to function well within a regional or national Health Information Exchange ecosystem.

So: this work probably has 2 major components:

  1. Helping Implementers and Ministries identify their goal underlying the request for multitenancy, to make sure the solution approach actually matches the needs
  2. A Toolkit to make the Shared Health Record-type of multitenancy work well, scale well, and be sustainable, which should include components like:
    • Architecture Diagram for a possible way to set this up
    • Guide with the approach and instructions clearly laid out
    • Central FHIR data repository & examples of how to set up
    • How to flatten tables (e.g. via Google OHS Stack’s fhir-data-pipes)
    • Something to look at the data with (Superset or Power BI, share templates).
    • OCL for Terminology, CIEL for content as a default, so that content is consistent across your many implementations
    • You need a CR (e.g. OpenCR).
    • OpenHIM connections (e.g. InstantHIE v2 package which has a central server part and a local HIS in a box aspect)

Hoping that we can get a conversation with some large-scale implementers organized shortly to verify and discuss more.

2 Likes
4

@michaelbontyes how is this conversation ?