Integrating OpenMRS: Offering a practical pathway to implementers

Community
, ,
1

Hi all,

There have been numerous discussions recently across multiple groups about the need for OpenMRS to better support the digitization of primary healthcare service delivery (mostly OPD). In healthcare settings, this quickly translates into OpenMRS being able to integrate better or more easily with various other systems, such as billing, reporting, lab, PACS, and many others.

The key question is: how can we, as a community, help adopters and implementers integrate OpenMRS and leverage interoperability standards in the process?

The problem

Integrating OpenMRS with other systems has always been challenging. However, because it mostly falls outside our core focus (the EMR system itself, OpenMRS), implementers have been left to devise their own solutions, often from scratch. This has resulted in numerous independent or weakly coordinated efforts, all tackling similar issues and recreating similar solutions with varying degrees of success. While we acknowledge that integrations can be somewhat idiosyncratic, we would still like to propose a pathway to help implementers jump-start the technical challenges of integrating OpenMRS with other systems.

What are we proposing?

Our proposal consists of providing a sample software distribution in which OpenMRS is already integrated out of the box with several other systems. The priorities are still being discussed, but the initial focus will likely be on integrating OpenMRS with billing and stock inventory management systems. Other examples that we would like to include in this sample integrated software distribution could see OpenMRS being integrated with a LIMS.

Much like the OpenMRS Distro Ref App provides a starting point for implementers with an EMR system, we aim to publish an OpenMRS Distro ‘sample integrated HIS’ to offer a foundational, integrated system for them to start with. This system will be ready to be adapted, configured, and expanded to meet specific needs.

In practice

Practically, we would like to introduce a new repository to host this upcoming integrated distro of OpenMRS. Our early thinking suggests the following:

  1. Rename openmrs-distro-referenceapplication as openmrs-distro.
  2. Introduce a new repository: openmrs-distro-his.

(Please note that all names are early suggestions to get the discussion going.)

The former, point 1, is optional and can be discarded; we just believe that openmrs-distro might be a better name to designate the core reference OpenMRS distro released by our community for implementers to start with an EMR system.

The latter, point 2, summarizes the core of our proposal. We would add a new repository to host openmrs-distro-his, a sample or reference software distribution that would depend on our OpenMRS Distro Ref App and would repackage it within a wider health information system (HIS).

Your opinion matters – please share it!

We look forward to your feedback and input on this important topic. Why not take it first to the next TAC call and start brainstorming together?

  • What do you think about introducing a sample HIS software distribution to guide implementers?
  • Would you welcome and even help our community to maintain such a distribution?
  • How should we name it?
  • Should it be hosted in a new separate repository or within the current Ref App one?
  • Which business domain systems should we start with? ERP, LIMS, PACS, BI, etc.?
  • In each business domain, which sample software would we showcase as part of our new HIS distro?
  • 


Let us know what you think!

Cc: @AMPATH @Mekom @METS @OpenMRSInc @PalladiumKenya @PIH @Sonder @UCSF @UWash

12 Likes
2

@mksd Thank you for taking a lead on this, a couple of thoughts

  1. Package Naming:
  • OpenMRS distro to openmrs-distro-emr since it will be an EMR based
  • Package distro-his to make it OpenMRS independent even if it is currently hosted under the OpenMRS umbrella
  1. Contents building from Bahmni which has gotten traction within this community, it would make sense to start from a LIS, ERP and some form of BI/analytics/reporting solution
  2. I think this needs to be a separate repository from the Reference App which is just one of the components, that could be replaced by any of the OpenMRS based distributions UgandaEMR, KenyaEM, PIH-EMR, et al

Excited to see where this is going

4 Likes
3

Thanks @ssmusoke for your reply and for sharing your thoughts.

To you an everybody else interested in this thread, please note that we will have a TAC call tomorrow where this will be brought up:

4

@ssmusoke welcome back. two years since then

1 Like
5

Great suggestion

2 Likes
6

About this. and a question to @mksd would this scope be limited to supporting a health care center “Hospital” etc or even focus on exchanging data beyond a facility? If the focus is about a health center shouldn’t we name it like hospital-distro. I also think that this targets big facilities that offer a large scope of care compared to basic care.

7

@slubwama this is still to be discussed and defined. Our suggestion is to publish (and maintain) a sample HIS distro to showcase “all things integration”. Therefore it isn’t just necessarily focused on in-facility integrations and could also showcase sample integrations with remote systems (CR, SHR, etc).

Of course, we need to start somewhere, and perhaps the most needed and most pressing needs might remain around those discussed in Mombassa in January? Eg. in facility billing, stock management, etc.

8

@slubwama The reason it does not matter where it is deployed is that, it could end up only being EMR and the reporting solution (say Apache Superset) at the simplest, following point to point integrations

IMO this is different from HIE in a way, as these are point-to-point application/service integrations but could leverage HIE for some aspects like SHR, client registry

9

And terminology services of course, :slight_smile:

2 Likes
10

Having a demonstration of OpenMRS integrating with other systems would be a benefit both for implementers who need to do these integrations as well as for the OpenMRS community to ensure that OpenMRS can integrate as expected with other systems.

Some important questions


  • Purpose – e.g., demonstration? starting point? production-ready?
  • Scope – e.g., hospital/enterprise system (EMR, lab, radiology, ancillary systems, 
), not a regional/national system (HIE)
  • Messaging – e.g., how do we include integrations with another system without implying this is the only option for that type of integration? Or do we intend to imply preferred systems for integrations?
  • Relationship with existing efforts – to what extent can this effort help convergence of similar efforts (CHT, Bahmni, etc.) rather than yet another stovepipe on the horizon?
2 Likes
11

A few random thoughts on this

  • Definitely, the more complete and comprehensive the system(s) is/are, in terms of the patient journey or care processes, the more attractive and easier to implement. So, a distro of OpenMRS with all the other components would be greatly appreciated by us, the users
  • I also wonder how different it would be from Bahmni. Perhaps just improve Bahmni to add the stuff that Bahmni users are missing?
  • On prioritizing the many possible “other components”: we should be able to see pragmatically find out what systems are used in majority of the clinics we intend to serve and/or which clinical care services are used by majority of patients, but also which have the greatest “return on investment”, e.g. allowing data to be reused multiple times for longitudinal care, reporting, etc.
  • OpenELIS made a selection of lab analyzers to integrate with: openelisglobal-plugins/analyzers at 5e0a2b489817dfaa579b95f15b578d85715d2095 · openelisglobal/openelisglobal-plugins · GitHub I assume they came to this choice by looking at the most frequently used analyzers. Can’t we do the same for imaging systems, etc? Or maybe there are RIS, ERPs, or LIS that already support a wider range of other systems such integration work from OpenMRS starts with those?
1 Like
12

Thanks @johnblack for your sharing your thoughts.

I wonder what you have in mind here? Could you be more specific?

OpenELIS Global is definitely very high in the list as a LIMS contender to be showcased in our sample HIS distro.

1 Like
13

I don’t use Bahmni, so can’t tell you what they are missing. That’s why we have to be pragmatic and find out. However, often, it is not that people need to integrate with this system or that, but rather they are looking for particular functionality relevant to the patient flow in their practice. In my practice, we have previously elicited these features, so we would like OpenMRS to offer them directly or integrate it with other systems that offer them these features: See table 2 here kabukye2020.pdf (906.3 KB) and table 3 here Kabukye2022.pdf (1.4 MB) Not sure if this helps. Also it is for oncology, but many features are relevant for primary/outpatient care

14

@grace / @burke / others, fyi a new GitHub repo and a new Jira projects have been added:

This is just a small infra-related update, more to follow in the next few days/weeks.

2 Likes
15

Thank you everyone who joined last week’s TAC call to discuss this in detail! I wanted to specially summarize that call here because it marks an important inflection point where we agreed to move this forward.

Recording below:

Key Points Raised and Agreed to together in TAC (2024-05-30)

  • Attendees: Dimitri (Mekom), Romain (Mekom), Eudson (UCSF), Samuel L (METS), Mark (PIH), Stephen M (METS/UCSF), Ian (DIGI), Cliff (DIGI), Daniel (OMRS), Grace (OMRS), Burke (Regenstrief), Mwariri (UCSF), Samuel M (OMRS), Herman Muhereza, Tendo M
  • Main Topic: Creating an HIS (Health Information System) distribution.
  • Main Takeaway: There was a strong consensus on moving towards a more production-ready approach, with clear naming conventions (distro-his) and a focus on making the system usable out of the box. This will help us address the non-EMR-core needs that health sites strongly require, while avoiding cramming functionality into OpenMRS and integrating appropriately with other systems. So we will have both a RefApp (distro-emr) and a RefApp+ (distro-his).
  • Background:
    • The proposal builds upon previous discussions held in Mombasa regarding the challenges faced by implementers of health information systems.
    • The main idea is to provide a pre-configured solution that would serve as a starting point for implementers, similar to the current RefApp, but focused on interoperability and integration with other systems. (Like a “RefApp+”). A sample distribution that demonstrates how integration with external systems (such as billing and stock inventory management) can be achieved, and in such a way that allows users to customize and adapt it to their specific needs.
  • Integration with ERP Systems: The distribution is intended to integrate with ERP systems while maintaining consistency in the user interface. It will offer flexibility for both facilities using lightweight modules and those employing ERP systems.
  • Documentation and Recommendations: The distribution will come with documentation on how to integrate with different ERP systems, serving as a reference for implementers. While specific integrations may be recommended, the distribution will provide a starting point for customization.
  • Choosing Default Systems: We agreed there’s a need to select default systems (e.g., ERPNext) to showcase integration with OpenMRS, taking into consideration functionality, open-source nature, adoption, and similarity to OpenMRS’s business domain.
  • Flexibility and Integration: The proposed distribution aims to provide a flexible solution that integrates with existing systems, such as ERP and LIS, without mandating specific choices. The goal is to allow for customization based on the needs of different countries or facilities. Agreed the approach needs to enable features, or like disabling/enabling modules, without affecting the API. Integration with existing systems and standards like FHIR was emphasized. A standardized solution that can be used across different countries.
  • Compatibility with Existing Efforts: The distribution seeks to leverage existing technologies and initiatives, such as Ozone, to minimize duplication of efforts and reduce barriers to adoption. It aims to complement and converge with existing OpenMRS-based distributions rather than create new silos.
  • Production-Ready Approach: There’s a shift in mindset from this RefApp(+) being just a demo/sample to being stamped as a “production-ready system”. We discussed how this means we will need to get even tighter with our release QA community process.
  • Commitment to Quality: So, there was a commitment from the team to dedicate resources to ensure the system is increasingly well-tested, reliable, and suitable for production use.
  • Renaming and Rebranding the RefApp: The team discusses renaming the “reference application” to better reflect its purpose and renaming the new repository to indicate its production-ready status.
  • Strategic Alignment: The proposed distribution aligns with strategic goals of empowering the community to build what they need while avoiding duplication of efforts and encouraging sustainability. It aims to provide a better course strategically by addressing the need for essential functionalities without imposing rigid constraints on implementers.

Direct recording link here.

4 Likes
16

I was there for the last half of the call and agree it was a great call. I think there was a desire to learn from Bahmni and address any shortcomings, but to eventually see if OpenMRS and Bahmni can get on a more similar integrated platform. Looking forward to hearing more about this effort (and of course understanding the terminology/vocabulary implications of a broader application integration


1 Like
17

@akanter fyi it is on Ozone’s roadmap to offer implementers the choice between both O3 and Bahmni EMR1as possible and available EMR components of the HIS that they would spin up with Ozone Platform. Very much in the same way that they can already choose today between Odoo and ERPNext for the billing/stock management component or in the same way that they will be able to choose between OpenELIS Global and SENAITE for the LIMS component, etc etc.

This is close to what you’re alluding to I think but that was an Ozone response in the context of its expanding ecosystem of software, not an OpenMRS Distro HIS response.

However I suppose that OpenMRS Distro HIS, whose goal is to showcase OpenMRS (=O3) being integrated with other systems will, well, showcase O3 as part of the sample/reference HIS.

1 Bahmni EMR only, (aka ‘Bahmni Apps’) not Bahmni as in, the whole HMIS.

3 Likes
18

I wonder if we could work with Bahmni on what an integration roadmap would look like? Would it be that Bahmni would eventually be on O3 or that people could swap out O3 for their Bahmni EMR (and presumably would replace the Bahmni integration with OpenERP/OpenELIS with the Ozone version)
 Just seems if we are proposing a production-ready OpenMRS-centric HMIS, that we should understand the impact on existing OpenMRS-centric HMISs, and what newly starting up HMISs would likely consider


19

I made this diagram to help explain what we mean by HIS and some example components of one - at least, in the context of our strategy, where we are approaching this by bundling together different softwares with focused core competencies:

Screenshot 2024-07-05 at 1.26.12 PM
Screenshot 2024-07-05 at 1.26.12 PM1298×1408 234 KB

4 Likes