Focus on OpenMRS interoperability & integrations at facility-level

Mondays at 9 AM EST, 4 PM EAT - Link: meet.google.com/ksh-mdae-rtw

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

Examples: Laboratory, billing, stock management, etc.

Objectives

Deliverables

Calls and notes

  • Analytics in OpenMRS Distro HIS: Ozone Analytics + Mamba ETL

    • 3 tickets to be worked on:

    • We can assume that MambaETL is supporting incremental changes.

  • OEG integration in progress: Exact extent of the work is identified. Mekom to outline a timeline and provide regular updates on this call.

  • Deployment of dev-his.openmrs.org server in progress: Mekom and OpenMRS devops have met: Need to modify Ozone so that it provides Docker images with the configs+binaries embedded in the image. Work should be started around next week.

  • FHIR specs for ERP Processes completed. Link: https://docs.google.com/document/d/1uvJwYCGZg_wnt5eMCFLBIJoWU4CQaUWSKENvHrR-MEg/edit?usp=sharing

    • Focus on the common parts of ERP processes:

      • Stock levels displayed upon ordering.

      • Product price displayed upon ordering.

    • Comparison between FHIR spec vs OpenMRS designs in progress. Done by Kevin.

  • OEG integration in progress: Define exact extent of the work needed. Mekom to outline a timeline and project manage.

  • Testing of OpenMRS Distro HIS in progress.

    • ERPNext processes confirmed to be working.

    • Documenting how Implementers can adopt OpenMRS Distro HIS-> to be reviewed by Stephen Senkomago Musoke

      • Investigate how OpenMRS Distro HIS can be adopted

  • Deployment of dev-his.openmrs.org server in progress: Mekom and OpenMRS devops to meet tomorrow.

  • FHIR specs for ERP processes progressed. Almost ready to be shared.

  • Stephen Senkomago Musoke is looking into trying Superset within Ozone.

    • Mamba ETL flattened encounters tables must be forwarded to the PostgreSQL analytics table (from Ozone Analytics) as to be available as 1 single datasource in Superset.

  • OEG integration in progress: See Slack conversation between Mekom and UW.

  • Testing of OpenMRS Distro HIS in progress.

  • Deployment of dev-his.openmrs.org server in progress: host is ready on OpenMRS infrastructure. Next step is to actually deploy OpenMRS Distro HIS (need to identify how can do so).

  • No progress on FHIR specs for ERP processes. Romain Buisson will provide updates in next call.

  • Stephen Senkomago Musoke is looking into trying Superset within Ozone.

    • Discuss how we could leverage on Mamba ETL flattening in Ozone Analytics.

    • Superset alone (in Ozone FOSS) is decommissioned for now in favor of running it with Ozone Analytics.

    • Needs to find ways to have Mamba ETL tables available in Superset as part of Distro HIS (via Ozone Analytics?)

  • Testing of OpenMRS Distro HIS in progress.

    • Process of raising issues:

      • Reach out on Slack first if issue is unsure, or needs some bits of troubleshooting first. or missing documentation.

      • Identify the priority.

      • Then create the JIRA ticket.

      • Document the ticket number on the Slack thread.

    • Conflicting names of containers when running multiple Ozone distros side-by-side

      • Provide a better default for Docker Compose project name (maybe to be the project name)

      • Provide the ability to override it at start time.

      • Ticket:

    • start.sh script not documented (only start-demo.sh). Stephen Senkomago Musoke will update the documentation.

    • No demo patients created when running start-demo.sh. Further testing needed. Might need some documentation improvement.

    • Next testing steps: try the actual integration between OpenMRS and ERPNext:

      • Create patient in OpenMRS

      • Create an order for that patient

      • See the patient in ERPNext

      • See the quotation opened in ERPNext

    • Documenting how Implementers can adopt OpenMRS Distro HIS → redirect to Ozone docs here: https://docs.ozone-his.com/create-distro/

  • Deployment of dev-his.openmrs.org server in progress: host is ready on OpenMRS infrastructure. Next step is to actually deploy OpenMRS Distro HIS (need to identify how can do so).

  • Goals for distro HIS (timeline ~Sep 2024)

    • dev-his.openmrs.org available

      • integrates with ERPNext

      • (integrates with OEG)

    • documentation available for implementers to leverage on it.

OpenMRS Distro HIS repo started and initialized.

Will start OpenMRS + ERPNext with default integrations. Needs testing + doc.

The presentation of OpenMRS distro HIS in the TAC call went well.

Some discussion ongoing on Talk: https://talk.openmrs.org/t/integrating-openmrs-offering-a-practical-pathway-to-implementers/42840?u=mksrom

Next step:

  • Create GH the repository: openmrs-distro-his. → Mekom

  • Create the Jira project: OpenMRS Distro HIS [HIS] → Mekom

  • Initialize the repo using the Ozone Maven Archetype → UCSF to create the ticket, Mekom to work on it.

    • Adjust the Group ID to be org.openmrs

    • Artifact ID to openmrs-distro-his

    • Remove Ozone white labelling to keep the default Ref App theme.

    • Update the O3 Ref App dependency to point to latest next version of O3 (in the pom + Docker images)

    • Enable EPRNext integration

    • Disable other integrations (Lab integration should be enabled when OpenElis Global integration is ready)

    • Disable “embedded ERP” features:

      • Billing & Stock OMODs dependencies

      • Billing & Stock ESMs

  • QA/testing of the new distribution.

  • Start a dev server for OpenMRS Distro HIS: dev.his.openmrs.org (test.his.openmrs.org / demo.his.openmrs.org, alternatively dev-his...)

  • Documentation:

    • OpenMRS Atlassian doc:

      • The repository

      • Vision/strategy

      • The specific configuration (components enabled…)

      • Use cases to cover / patient flows

      • Adoption of OpenMRS Distro HIS:

        • How to use that distribution and replace O3 Ref App with your own EMR distro.

Next call:

  • What about analytics?

Romain Buisson Kevin Ngari, Eudson Bambo Wamathaga Kamau

Billing and stock interfaces in OpenMRS (in progress): Interface specs points mostly identified now. Need to write this down in developer-friendly format. (this process is started by Romain Buisson ).

  • Looking specifically at the hybrid EMR/ERP screen (order basket):

    • Price

    • Stock availability

Providing the actual FHIR APIs:

  • Case 1: ERP with OMOD: Extend the FHIR module API from Billing or Stock Management OMODs to bring the ERP-specific domains.

  • Case 2: ERP with dedicated ERP software: Camel routes to expose the FHIR API.

    • This is short/mid term solution: Ideally this should be part of the product itself (Odoo/ERPNext…)

Choice of ERP → choosing ERPNext:

  • has a strategic impact in the region.

  • Is a bit inferior for initialization

Stephen Senkomago Musoke mentions a possibility to have a bare metal version as an alternative to Docker Compose.

Product & Services terminology management:

  • Product catalog VS OCL integration?

    • to be discussed next week.

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

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)

    • 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

Eudson Bambo, Samuel Lubwama, Romain Buisson, Michael Bontyes

Expectations: share common ground and efforts, learn from each other, explore architecture options, share reusable components like routes. 

Context

  • Shared interested expressed from Mekom, UCSF, MSF/Madiro, METS

  • How to balance between backed-in development and integration with existing

  • All looking for vertical and horizontal interoperability (hori: LAB, billing, stock, and verti: MPI, SHR, reference lab system)

  • Samuel:

    • UgandaEMR is using UgandaEMR Sync module to send out FHIR data, which includes a UI for profiles/resources/sync/logs.

    • Scope: HIV surveillance, ART access, LAB requests ALIS, eCBSS, HTS, ART regimen, TB, HIV exposed infant, Client registry, SHR, Cross border 

    • Roadmap: not receiving data at the moment, only sending from facilities. Data consolidation/conflict resolution is pending too.

    • Be careful with scoping, first with the knows, then the unknowns. Need to scope out what belongs to OpenMRS and what belongs to OpenHIE.  Ex: intero with OpenMRS or others? 

  • Romain:

    • Using Apache Camel with XML routes, no UI at the moment, can also write JAVA routes.

    • Questions around using OpenMRS as a start point. Ideally looking at a more centralized architecture, looking at OpenMRS as a FHIR client. Need a place to handle FHIR messages. Ex. FHIR → ODOO or FHIR → ERP Next. 

    • Approach: prioritizing Event bus (like EIP) rather than scheduler. Using API to get events + notifications. Also looking for queues services for handling flows, load of data, statuses, conflicts. 

  • Eudson:

    • What about more synchronous use cases like a patient needing medication → inform pharmacy in SENAITE and billing in ODOO. 

    • Be careful of the meaning of the data, ex. drug order. 

  • Michael: 

    • Early stage, looking at common use cases and architectures

    • Scope: lab tests requests and results (within and outside facility), referrals between facilities, sync with master patient index

Next steps

  • Schedule a call next week to:

    • What: Map/list elements of the ecosystem, ex. OpenMRS vs OpenHIR vs Terminology platform, etc.

    • Why: Map use cases and gaps/challenges - contextualize with examples from facilities and concrete scenarios

    • How: Explore approach and architecture options, incl. async/sync cases + what can we share? which components?

  • Share visibility in Slack #FHIR channel + notes here. 

Links and references

Archives