You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 12
Next »
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
Share knowledge and use cases about data exchange use cases
Align on practices, tools, and architectures
Deliverables
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
Follow-up call May 13, 2024
Follow-up call May 6, 2024
Follow-up call April 29, 2024
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:
Next:
Call summary March 25, 2024
Call summary March 18, 2024
Objectives of the group:
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
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
National level
Shared Health Record
Master Patient Index
Client registry
Provider registry
Facility registry
Reporting
Machine Learning
Insurances
District level - often similar needs to National level
Implementing Partner level = Cross-facilities level
Facility level
Community-Outreach
Comparaison of tech stacks
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
Exploratory call summary March 4, 2024
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
Links and references
Archives