OpenMRS Interoperability and Integration Updates

• LIMS integration

  • OEG integration work is halted until the missing features are implemented.

  • Will touch base weekly to assess the progress and resume work when a number of the features are fixed.

  • Enable SENAITE as the default LIMS option currently in progress (PR in review and a bug reported) HIS-15 - Getting issue details... STATUS

• Deployment of dev-his.openmrs.org

  • Work necessary in Ozone to build bundled Docker images is now done and currently being deployed (on the Ozone side).

  • Deployment of OpenMRS Distro HIS should be done through a Bamboo job - done by today or tomorrow.

• FHIR API for Odoo

  • Proposed architecture: https://miro.com/app/board/uXjVKv4-SII=/?share_link_id=473611286361

  

  • Work has started.

    • Odoo Java Client: we will be using the Odoo Java API project as a Java client for Odoo XML RPC API → https://mekomsolutions.atlassian.net/browse/OZ-688 is not necessary anymore.

    • OpenMRS module FHIR Proxy work is started. Will get more updates after the Ozone internal call.

    • HAPI FHIR server work started today. Will get more updates after the Ozone internal call.

• MambaETL

• Ozone Analytics

  • Open sourcing of Ozone Analytics will be started by Kakumirizi Daud this week.

• LIMS integration

  • OEG integration work is halted until the missing features are implemented.

  • Will touch base weekly to assess the progress and resume work when a number of the features are fixed.

  • Will enable SENAITE as the default LIMS option for now. HIS-15 - Getting issue details... STATUS

• Deployment of dev-his.openmrs.org

  • Delayed few days: init. estimate on end of last week. Looking at mid this week now. (technical work is done so that child distributions can build those Docker-embedded images).

  • Unable to reach out to Rafal. Scott has not answered regarding if a Bamboo job already exists or not.

• FHIR API for Odoo

  • Proposed architecture: https://miro.com/app/board/uXjVKv4-SII=/?share_link_id=473611286361

  • 

  • Work has started.

    • https://github.com/openmrs/fhir-structures-backport-r4/pull/1

    • https://github.com/mekomsolutions/odoo-java-client

    • https://github.com/ozone-his/fhir-odoo

• MambaETL

  • Technical architecture call on Thursday

    • Simplicity of deployment (OMODs and/or SQL script)

    • Ability to dynamically flatten encounters and transpose questions as columns

    • Concerns over:

      • Change Data Capture done through monitoring some specific database fields (date_changed, date_voided…) instead of default mechanisms (binlog…)

      • Performance concerns (due to a lot of indexing) for 10M records databases.

      • Little to no testing.

• Ozone Analytics

  • Open sourcing of Ozone Analytics will be started by Kakumirizi Daud this week.

• OEG integration

  • Project updates shared by Suruchi: integration work is being delayed (+1 week already) by low responsiveness from OEG devs. Attempting to setup weekly calls.

  • Eudson advises to not implement any workaround and rather wait for OEG folks to answer.

• Deployment of dev-his.openmrs.org

  • Development work needed to deploy embedded distro Docker images is well advanced. Est. done by mid-week.

  • Then reaching out to Rafal in OpenMRS community to deploy via Bamboo.

  • Q: Emmanuel Nyachoke where to deploy the OpenMRS Distro HIS-embedded Docker images?

• FHIR API for ERPNext (or Odoo)

  • From Slack message Odoo might be a better fit for the default ERP system in Ozone and OpenMRS distro HIS.

  • Work needed to have ERPNext expose a FHIR API still needs to be documented as an example. Current work could be pushed and documented so to be picked up and resumed by other group.

  • ChargeItemDefinition and InventoryItem exposed in Billing & Pharmacy modules needs to start. Mekom will provide guidance. Need to use the https://github.com/ozone-his/fhir-structures-backport-r4/ library.

• MambaETL + Oz Analytics

  • Plan a call this week between UCSF and Mekom to look at Mamba ETL in terms of incremental updates.

• DHIS2 / DHIS Tracker integration:

  • Integration with Tracker. Advises to look at the Ethiori REDCap integration.

  • Integration DHIS2 (analytics). Advises to look at the Ozone Analytics when integrated data analytics.

OEG integration:

• OpenMRS patient and Lab test order is synced in OpenELIS

  Screen Recording 2024-08-05 at 10.20.53 AM.mov

• Results from OpenELIS are synced in OpenMRS

  Screen Recording 2024-08-12 at 11.16.16 AM.mov

• Modification of lab order cancels the existing lab order in OpenELIS and creates a new lab order

  Screen Recording 2024-08-12 at 11.30.42 AM.mov

• Discontinue lab order in OpenMRS cancels the Incoming Order in OpenELIS

  Screen Recording 2024-08-12 at 12.09.02 PM.mov

Deployment of dev-his.openmrs.org.

• In progress: 2 PRs:

  • https://github.com/ozone-his/ozone/pull/83/files

  • https://github.com/ozone-his/ozone-docker-embedded/blob/main/docker/docker-compose-embedded.yaml.template

• Work halted this week due to vacations. Will resume next week.

FHIR API for ERPNext:

• Architecture still in progress. Leaning towards running HAPI FHIR to transform and expose FHIR objects from the ERPNext database.

  • Architecture will be defined this week and implementation started the week after.

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

  • 3 tickets to be worked on:

    • HIS-11 - Getting issue details... STATUS

    • HIS-10 - Getting issue details... STATUS

    • HIS-9 - Getting issue details... STATUS

  • Planned a demo session of Mamba ETL w/ support of incremental changes lead by UCSF. (to be scheduled to next week)

• OEG integration in progress:

  • Notion board: https://www.notion.so/mekom/OpenMRS-disto-HIS-integrated-with-OpenELIS-Global-597eea5b1d6e4305b0dc472b9682d505?pvs=4

  • Automated configuration w/ OEG only supported w/ Liquibase.

  • Unblocked to create Patients visible in new UI.

  • Mid-next week first delivery. Identify exactly what will be demoed by this time. suruchi dhungana to update.

• Deployment of dev-his.openmrs.org server:

  • Will be looked at tomorrow.

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

  • Designs for Price + Stock upon ordering will be added in Zeplin today.

    • Need some architecture call with Wyclif regarding exposing the FHIR API of the ERP (and authenticating to it)

• SSO: Should be configurable to be enabled by implementers.

• Custom systems integration:

  • Ethiori being integrated with a custom LIMS. → good progress done in Ethiori hackathon.

  • Used as an example to add more integrations.

• Enabling SENAITE in OpenMRS distro HIS:

  • Stephen Senkomago Musoke starting evaluation of SENAITE integration.

    • Patients are synced

    • Lab orders not tested as unable create orders with admin users. Reached out on the #ozone channel.

    • Mekom reported some issues with the Lab order basket (unable to revise order).

• DHIS2 integration by Michael Bontyes . Interested in looking UgandaEMR existing DHIS2 integration.

  • MSF scope: Initialize a new OpenMRS instance with DHIS2 patients (w/ DHIS2 ID + demographics)

    • Using OpenFn to send the new patients and data points.

    • Business logic available on GitHub.

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

  • 3 tickets to be worked on:

    • HIS-11 - Getting issue details... STATUS

    • HIS-10 - Getting issue details... STATUS

    • HIS-9 - Getting issue details... STATUS

  • Planned a demo session of Mamba ETL w/ support of incremental changes lead by UCSF. (to be scheduled to next week)

• OEG integration in progress:

  • Notion board: https://www.notion.so/mekom/OpenMRS-disto-HIS-integrated-with-OpenELIS-Global-597eea5b1d6e4305b0dc472b9682d505?pvs=4

  • EDD mid/end-aug

• Deployment of dev-his.openmrs.org server:

  • Will be looked at next week.

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

  • Designs for Price + Stock upon ordering will be added in Zeplin today.

    • Need some architecture call with Brandon regarding the ability for O3 to query multiple backends.

    • Need some architecture call with Wyclif regarding exposing the FHIR API of the ERP (and authenticating to it)

• Custom systems integration:

  • Ethiori being integrated with a custom LIMS.

  • Used as an example to add more integrations.

  • The week after next, prepare a demo/call to run through the Ethiori LIMS integration compared to say, SENAITE integration).

• Enabling SENAITE in OpenMRS distro HIS:

  • Stephen Senkomago Musoke starting evaluation of SENAITE integration. Will provide more updates on #ozone channel by EOD.

• DHIS2 integration by Michael Bontyes . Interested in looking UgandaEMR existing DHIS2 integration.

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

  • 3 tickets to be worked on:

    • HIS-11 - Getting issue details... STATUS

    • HIS-10 - Getting issue details... STATUS

    • HIS-9 - Getting issue details... STATUS

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

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

  • Possible to only send to Ozone Analytics some tables from Mamba: the ones for which we know the model.

  • Creating https://openmrs.atlassian.net/jira/software/c/projects/HIS/issues/HIS-9?jql=project%20%3D%20%22HIS%22%20ORDER%20BY%20created%20DESC

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

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

• FHIR specs for ERP Processes complete. 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.

• 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

      • Direct inheritance from Ozone.

      • Inheritance of OpenMRS Distro HIS.

        • Stephen Senkomago Musoke to try both options.

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

    • Not so straightforward as the table columns is dynamic.

    • Need to find a way to identify a source data model and create the corresponding target database

    • → Set to the agenda next week. Invite Wyclif Luyima Emmanuel Nyachoke Arthur D. Mugume Laureen Omare .

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

• Testing of OpenMRS Distro HIS in progress.

  • No demo patients created when running start-demo.sh. Further testing needed. Might need some documentation improvement → Stephen Senkomago Musoke confirms that demo patient are created.

  • Testing of the actual integration between OpenMRS and ERPNext in progress. Should be done by mid-week by Stephen Senkomago Musoke .

    • 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/

    • Example of Ozone LIME: https://github.com/MSF-OCG/LIME-EMR

    • Example of KenyaHMIS: https://github.com/palladiumkenya/kenyahmis/tree/main

    • Investigate how OpenMRS Distro HIS can be adopted

      • Direct inheritance from Ozone.

      • Inheritance of OpenMRS Distro HIS.

• 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: HIS-7 - Getting issue details... STATUS

  • 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/

    • Example of Ozone LIME: https://github.com/MSF-OCG/LIME-EMR

    • Example of KenyaHMIS: https://github.com/palladiumkenya/kenyahmis/tree/main

• 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)

    • 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

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.