Integrating OpenMRS: Offering a practical pathway to implementers

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