OpenMRS Interoperability and Integration Updates

@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.

SSO:

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

Initialization of ERP/LIMS… components:

• Metadata (eg, list of products) needs to be aligned within the HIS.

  • As a first step, probably fine to manually align the products list (via each system initializers)

    • Odoo comes with Odoo Iniz

    • ERPNext comes with an initialization mechanism with some limitations. See in Ozone: https://github.com/ozone-his/ozone/blob/main/scripts/erpnext/data_import/generate-import-script.groovy . This only assumes being able to create new metadata or edit existing metadata, but not both at once.

    • SENAITE initialization must be done by starting the system, manually configuring it, and exporting the config. This config file can then be fed to the Plone Initializer.

    • OpenELIS Global - @Romain Buisson to identify how OEG can be initialized.

  • Longer term solution:

    • Product catalogue: ERP might be the one driving the list of products & services. Appropriate products & services would be broadcast to their corresponding component (EMR, LIMS…)

Deployment:

• 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