OpenMRS Interoperability and Integration Updates

Focus on OpenMRS interoperability & integrations at facility-level

Mondays at 9 AM EST, 4 PM EAT - Link:

Represented organizations: UCSF, UgandaEMR, Palladium, Mekom, MSF/Madiro

Examples: Laboratory, billing, stock management, etc.


  • Share knowledge and use cases about data exchange use cases

  • Align on practices, tools, and architectures


  • Map ecosystem of existing solutions and challenges to address them as a group

  • Framework for integration

  • Sets of routes

  • Documentation about how to integrate OpenMRS with other health systems

Calls and notes

@Gilbert Muthee Arthur Mugume @Romain Buisson @Amos Laboso Kevin N. G Ngary

Pre-analysis of user stories for Billing and Stock Management done by Paul Adams. Results to be shared by @Romain Buisson

  • Data points needed for the integration between EMR & ERP (dedicated ERP or embedded ERP modules).

  • Used as support for building the APIs on both ERP solutions.

Draft concept note started by @Gilbert Muthee to be shared.

Regarding choosing between ERPNext VS Odoo: both integration will be available with OpenMRS FHIR (OpenMRS EIP component) - both are a viable option.

Lab Integration:

  • Laboratory app is already implemented in Ref App (Lab results entry).

    • On the same principle of the ERP integration:

      • Laboratory backend module should provide a FHIR interface.

      • Take out the EMR-focused frontend components should be in their own app.

      • Make sure those new frontend components rely on the FHIR API so that the backend can be swapped between the embedded Lab modules and dedicated fully-fledged LIMS.

      • Paul to check the user stories behind that work (initiated by UgandaEMR - also used by Palladium) - @Romain Buisson

Billing integration:

  • ⚠️ KenyaEMR/KenyaHMIS still using a different version of the Ref App. This needs to be aligned.


  • Might not be mandatory, but a nice to have.

Initialization of ERP/LIMS… components:


  • Probably use the Ozone deployment stack to facilitate the deployment (ready-to-use Ozone Docker Compose). This is a standard Docker Compose project to enable and start the various HIS components.

For next meeting:

  • Backup & restore of the various HIS components

  • Error handling in message routing (integration framework)

  • Manual troubleshooting of errors (integration framework)

  • Adoption & Documentation

  • More detailed scope for a potential hackathon.



@Gilbert Muthee @Romain Buisson @Michael Bontyes

  • Scope of the group: facility level

  • What is out of this group:

    • MPI/CR Integration squad

    • FHIR channel

    • Offline discussions

  • Recurrence of call? Weekly in May, then to revisit later.

  • Gilbert/UCSF use case:

    • Looking for a unified UI to integrate ERP data, but also looking to be able to switch from “integrated OpenMRS module” vs. “dedicated ERP” like Odoo - Context statement

    • Common features, no matter the approach and whatever the backend/flavour is (ex. OpenMRS ERP module vs. dedicated ERP system integration). For example:

      • Stock levels upon ordering + moving goods and commodities around

      • Billing features

  • Next:

    • Planning integration Hackathon/Workshop in collaboration with Mekom in ~3 weeks - preparing concept note for it (to be sorted out: Goals, type of devs needed)

      • Started: Identify the boundaries/cut-off point, scope, and features of both flavours (ex. what do users get using billing module vs dedicated?)

      • To be started prior to the workshop:

        • Paul A. to look into overlaps and identify what should live where - also by reviewing the OpenMRS data model

        • Prepare the re-architecture scope

        • Pick tools for dedicated ERP. Ex. Odoo vs. ERPNext. Lab would be later.

        • To consider on the long term: how feasible would be the transition from the “light”flavour to the “dedicated “flavour” - data migration + ERP configurations/metadata to consider.

        • Product Catalogue: where will be the source of truth for the products between OpenMRS and the ERP. Middleware example: OpenConceptLab or Odoo. Considering pulling products from higher levels, that can be consolidated with local products = cascade approach. Limit current scope to facility level for now.

      • Workshop scope:

        • Dev and re-achitecture work for that scope to be “optional” + FHIR for the ERP readiness (format and endpoints)

        • Documentation, guideline-style to facilitate other to reuse - A BA could help

        • Current User Stories for billing and Stock

      • Not in scope:

        • FHIR facade - would be a next step

@Romain Buisson, @Michael Bontyes

  • Discussed the architecture - currently working on a diagram that will be shared here soon for everyone to contribute

@Eudson Bambo@Romain Buisson, @Michael Bontyes@Antony Ojwang

  • Objectives of the group:

    • Share practices and learn from each other

    • Investigate a robust interoperability layer and tech stack at facility level - how to enrich data from connecting systems together

  • Antony - Palladium

    • In house OpenMRS module to exchange data between EMR <> Centralized Messaging (SMS reminder for Apt - w/ route to SMS provider) 

    • Exchange with Pharmacy Mgmt for HIV-ARV dispensing

    • Data exchange with National Data Warehouse - used for ML training

    • Most KenyaEMR hosted on premises = monthly sync need from facilities to central warehouse

    • Intero with Lab systems (referral labs), VL testing, influenza 

    • HIE is sometimes not under Palladium/KenyaEMR control (ex. need to use existing Rest APIs), but often using HL7 format

    • The OpenMRS module also generates Patient IDs

    • Now using OpenHIM instead of Interoperability Layer (custom solution) - also used for patient referrals

    •  HIE with SHR

    • For consolidation > above sites solutions pulling data from facilities (work in progress)

    • Registrations centralized in client registry

    • Difficulty when not in control of tech architecture

  • ICRC

    • Using OpenMRS DB sync = DB to DB, can work offline using queues

  • Describe architecture and outline tools

    • Assumptions and considerations

      • Reusable and modular integration of OpenMRS

      • Connectivity issues

      • Both cloud and on premises infra

      • Limited ownership on architecture and infrastructure decisions

      • Limited ownership of data (integrity and regulation aspects)

      • Variety of technical specifications and performance (laptop, edge devices, or cloud)

    • International level - beyond country level

      • Reporting 

    • National level

      • Shared Health Record

      • Master Patient Index

      • Client registry

      • Provider registry

      • Facility registry

      • Reporting

        • DHIS2

      • Machine Learning

      • Insurances

    • District level - often similar needs to National level

    • Implementing Partner level = Cross-facilities level

      • Reporting

    • Facility level

      • Centralized user management (including roles)

      • EMR

        • Bahmni, OpenMRS

      • Lab

        • Senaite, OpenELIS

      • Product catalog

      • ERP

        • ODOO

    • Community-Outreach

      • Data capture

        • ODK, Android FHIR SDK, OpenSRP, Comcare

      • eCDSS

        • Almanach (ICRC), eCare (MSF), CHT

  • Comparaison of tech stacks

    • Data flattening

      • Mekom: Debezium

    • Data streams

      • Mekom: Flink with Ozone Analytics

      • Palladium: OpenHIM

      • MSF: OpenFN with OpenMRS<>OCL<>DHIS2

    • Aggregation of patient files

      • Mekom: Camel + OpenMRS EIP for event bus (DB Sync)

    • Conflicts Management

      • Mekom: Can view report in DB sync - not resolution

  • Next call:

  • Group per nature/similarities of intero (ex. MPI vs analytics pipelines)

  • Horizontal-vertical

  • Authentication

  • Anonymized, aggregated

  • Terminology + mapping management

  • Frequency and quantity

  • Location and device client of data consumption

  • Level of connectivity

  • How to reflect interoperable data in UX - Ex. level of insurance coverage