Interoperability



Exploratory call summary March 4, 2024 - @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. 

Call summary March 18, 2024 - @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

Call summary March 25, 2024 -  @Romain Buisson, @Michael Bontyes

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