Introduction

The Challenge

Clinicians need accurate, timely and complete information for decision-making but healthcare information solutions are often siloed making it difficult to share information across different systems, different facilities and different locations.

For example, see this case-study titled: Interoperability opportunities and challenges in linking mhealth applications and eRecord systems: Botswana as an exemplar (NIH 2021)- Link: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8379582/. Some key points in this case study to note (involves OpenMRS, OpenHIE, FHIR/HL7, MySQL, DHIS2, Optima, etc):

1. The lack of agreement on national data and security standards are barriers to interoperability.

2. Non-conformity with available interoperability standards of existing eRecord systems and the mHealth application is another challenge.

3. The health-sector interoperability architecture (based on open standards e.g. OpenHIE or OpenHIM) supporting common data registries, terminology services, authentication, and security services, could simplify complexities of interfaces that will be built between mHealth applications and eRecord systems through common APIs.

4. Although a priority, the adoption of global goods should not deter innovation and the development of a home grown EMR as envisioned in the eHealth Strategy.

5. To be sustainable, mHealth applications need to be integrated with diverse eRecord systems within the public and private sectors.

Introducing OpenHIE

A Health Information Exchange (HIE) makes sharing health data across information systems possible. It enables data to be shared between databases, facilities, and across regions or countries.

OpenHIE’s Architecture (see the component diagram here) is made up of patterns that ensure that health information from various external systems is gathered into a single, unified HIE. To accomplish this, the exchange normalizes the context in which health information is used by focusing on the “for whom”, ”by whom”, “where”, and “what” of a patient’s health visit, bringing relevant information through a layer of interoperability and directly to the point of service. Additionally, OpenHIE also integrates medical supply data. This supports enhanced decision-making, improves the quality, safety, and continuity of care, and facilitates the appropriate use of information to improve health in a population.

OpenHIE is a diverse mission-driven community of practice including countries, organizations, individuals and donors working to promote sharing of health data across many different software products. OpenHIE makes and improve standards-based software to improve the exchange of health information.

Digital Public Goods (see Guidebook), like Bahmni, OpenMRS, DHIS2 and others are striving to be interoperable by supporting global standards of information exchange, recommended & shaped by OpenHIE community. This ensures that when countries/states/districts/facilities adopt a DPG like Bahmni, the data is not siloed and can be exchanged between various health & reporting systems at various levels, unlocking quality decision making at all levels, while protecting/respecting patient privacy. Middleware tools like OpenHIM, that enable integration/interop through connectors that respect standards like FHIR and OpenHIE, enable different software systems to exchange information in a seamless manner.

Bahmni Continued Support for Open Global Standards

Bahmni, right since its inception in 2012 has believed in building software on top of the shoulders of giants, which means, adopt existing health standards and opensource products and innovate on-top-of them. For instance, from the beginning, Bahmni was built by integrating OpenMRS, OpenELIS, Odoo and DCM4chee, to ensure that each sub-product was already standards compliant in its field (EMR, Lab, ERP, Radiology, etc) and that these products were integrated seamlessly using ATOMFeed/HL7/DICOM standards, for easy field use. This also ensures, that individual product communities, continue to harness and evolve along with new standards. The following section details out the various standards already supported / evolving in Bahmni (or its sub-products):

FHIR Support via OpenMRS & ABDM Certification

1. Bahmni supports FHIR out-of-the-box via the underlying OpenMRS components. Bahmni exposes REST and FHIR APIs that allow any client to pull clinical data from Bahmni using FHIR. Documentation of APIs and FHIR can be seen here:

   1. Bahmni REST APIs: Bahmni REST API & FHIR APIs and https://wiki.openmrs.org/display/projects/FHIR+Support+in+FHIR2+Module+version+1.3.0

   2. OpenMRS FHIR APIs: The community-created, community-maintained OpenMRS FHIR Module acts as a translation layer between the FHIR standard and OpenMRS' custom data model. It maps OpenMRS data model items to FHIR Resources, and provides a FHIR REST API developers can use to query data for purposes of client-side rendering (e.g. a frontend widget) or data exchange with another system. The FHIR Module allows both export and import of data in the form of FHIR Resources - a "two-way street". For more details please see this documentation: https://wiki.openmrs.org/display/projects/FHIR+101%3A+OpenMRS+Strategy%2C+Tools%2C+FHIR+API%2C+and+Help . Note that The FHIR module suppports both FHIR R4 and DSTU3. The Bahmni team has also added FHIR Extension APIs on top of OpenMRS FHIR APIs.

2. Additionally, Bahmni has been ABDM Certified (India’s National Digital Health Architecture), which is a Federated Architecture with components similar to OpenHIE (registries, gateway, exchange, FHIR based, etc), and supports India FHIR/HL7 based Profile. Read more here:

   1. https://www.nrces.in/ndhm/fhir/r4/index.html (FHIR Profile for India, maintained and published by NRCeS from CDAC India)

   2. NDHM Architecture blueprint. See slide on Page 17: Figure 2.2 Federated Architecture of NDHB (with Building Blocks)

   3. Bahmni is ABDM Certified (govt website, faq)

3. Integrated with SNOMED / Snowstorm FHIR Terminology Server: See details here: SNOMED FHIR Terminology Server Integration with Bahmni

4. OpenHIM support for exporting Bahmni data as FHIR.

   1. See here: Sample Endpoint Schemas | OpenHIM Mapping Mediator .

   2. Also see this alternative strategy for integrating OpenMRS and OpenHIM: Interoperability Layer for OpenMRS

HL7 Support

1. HL7 support right from the start.

2. Integrations with other systems using HL7. E.g. Integration with Senaite LIMS uses HL7/Mirth: Introducing Bahmni HL7 LIS Integration (with Senaite LIMS) , and see this: Use Mirth as Bahmni ESB

3. HL7 v2 ORM - Order messages, HL7 V2 ORU - Order responses (some cases).

Clinical Standards such as LOINC, ICD10 and SNOMED (CIEL/OCL)

1. Reference Term Mappings: The underlying OpenMRS concept dictionary supports storing multiple reference maps for terms to their corresponding LOINC, ICD10, or SNOMED mappings. See this example from one of our Bahmni LITE demo environments showing SNOMED/ICD10 mappings for concept “HIV Positive”:

   Open

   

    

2. CIEL Dictionary: Bahmni LITE ships with CIEL Dictionary (published by Dr Andrew Kanter in OCL), and therefore comes out of the box with thousands of clinical terms and corresponding mappings. CIEL is almost entirely mapped to SNOMED (including multiple maps where SNOMED does not have SAME-AS concepts). Also, CIEL drugs are mapped to RxNORM in addition to SNOMED (and WHO’s ATC) as most drug-drug interaction engines use RxNORM. Whenever a new version of the CIEL dictionary is published in OCL, Bahmni pulls this into its next release. For more details on CIEL dictionary please read: https://wiki.openmrs.org/display/docs/Getting+and+Using+the+CIEL+Concept+Dictionary

3. OCL: Open Concept Lab provides real-time electronic access to terminological resources and straightforward integration with independent software platforms. OpenMRS/Bahmni ship with OCL subscription module that lets you connect your OpenMRS instance to an OCL instance containing standard terminology and pull the terms into your server. This allows for disparate systems to agree and use a central terminology system (or a mixed terminology system). Read more about OCL and Subscription module here: https://wiki.openmrs.org/pages/viewpage.action?pageId=224527062

4. SNOMED: As mentioned above, Bahmni has also integrated, over FHIR to a SNOMED FHIR Terminology server (opensource SNOWSTORM). This allows a facility to record its data in SNOMED CODES, and then use Reporting/CDSS systems to benefit from the hierarchichal classification of diseases by SNOMED. The future roadmap of this work involves, publishing a WHO ICD10 report, integration with SNOMED Data Analytics tool (over FHIR bulk export of patient data), integration with Snomed Query Service (for offline purpose) and CDSS use-cases for Drug-Drug interactions with alerts. Read more about this initiative here: SNOMED FHIR Terminology Server Integration with Bahmni

Radiology Support for DICOM via DCM4Chee

1. For Radiology purposes, XRay/CT/etc, Bahmni ships with opensource Dcm4chee package. DCM4chee has in-built support for DICOM, HL-7, WADO interfaces and acts as a PACS server, to connect Bahmni to modalities. For reference please see:

   1. DCM4chee support for standards: https://dcm4che.atlassian.net/wiki/spaces/ee2/overview

   2. This is LIVE in many Bahmni implementations, including at JSS. See here: How to Integrate Bahmni with Fuji CR

2. As Bahmni continues to upgrade the underlying Dcm4chee packages, we get support for more latest standards/interfaces related to DICOM/Radiology purposes.

Integrating Bahmni at Scale with National Open InterOp Exchanges

Bahmni Deployment in Lesotho with OpenHIE / OpenHIM

1. Read this case study: Strengthening Strategic Information Activities in the Kingdom of Lesotho (Key Findings Report) - PEPFAR, ICAP. (Link: Bahmni, DHIS2 and HIE rollout in the Kingdom of Lesotho (External Report)).

2. This report talks about the adoption and rollout of DHIS2, eRegister (built on Bahmni) and HIE (built on OpenHIM, OpenEMPI and OpenSHR) across 170+ facilities in the Kingdom of Lesotho. The goal of this rollout in Lesotho was to enhance ability of national institutions to plan and coordinate HMIS and surveillance activities.

3. Code repo for eRegister with openhim: Lesotho eRegister

Bahmni Deployment in Bangladesh, as SHR (Shared Health Record) with Central Exchange

1. Bahmni was deployed in Bangladesh across multiple facilities along with an HIE and a Shared Health Record architecture. See architecture diagram here: Overall architecture of SHR with Bahmni & DHIS2 .

2. Read the case study from Thoughtworks website here: https://www.thoughtworks.com/insights/blog/implementing-shared-health-record-platform-rural-bangladesh (2016)

3. Announcement on OpenHIE Forum here: https://discourse.ohie.org/t/public-showcase-of-bangladesh-hie-work/1162

Bahmni is ABDM Certified for India’s National Health Architecture (using a Federated Architecture and Exchange over FHIR/UHI/etc)

1. Bahmni has been ABDM Certified (India’s National Digital Health Architecture), which is a Federated Architecture with components similar to OpenHIE (registries, gateway, exchange, FHIR based, etc), and supports India FHIR/HL7 based Profile. Read more here: https://abdm.gov.in:8081/uploads/ndhb_1_56ec695bc8.pdf (See page17 of the document for the full architecture).

2. For more details please see this: https://bahmni.atlassian.net/wiki/spaces/BAH/pages/2901114904

Bahmni Roadmap Evolution in 2023-2024

1. As can be seen from the details provided above, Bahmni has fully adopted and worked towards ensuring interop through various sub-products and standards.

2. As these products continue to evolve, their interop roadmap affects and enhances Bahmni. E.g OpenMRS Roadmap for InterOp can be seen here: https://wiki.openmrs.org/pages/viewpage.action?pageId=235278551 (Section 3: Data Exchange). These features will be adopted by Bahmni, when we upgrade the underlying OpenMRS in 2023 again.

3. From an ABDM perspective, Bahmni has been certified to be standards compliant, and as the ABDM standards evolve, we will continue to support the new requirements for interop. For instance, Patient Consent based approval of Data Records (OTP/NationalID based), or UHI (for Universal Insurance), or CDS (for CDSS use-cases), etc. This is a moving target, as and when ABDM reaches out to Bahmni/Thoughtworks to make changes. TW Bahmni team is also involved in drafting the standards for the ABDM (esp our SMEs @Angshuman Sarkar and Dr. Akhil @Akhil Malhotra ).

4. The Bahmni / TW coalition team is working with SNOMED International (cc: @Kai Kewley ) to create a deeper integration and support for SNOMED in Bahmni. Details already provided above. In the next 6 months the work will focus on ICD10 reports, CDSS use-cases, Data Analytics with SNOMED, Data Export with Anonymisation, etc.

5. From an identity/privacy perspective, the Bahmni team is working on integrating an IDM tool like Keycloak with OpenMRS/ELIS/Odoo, to provide a single place for user management & authX/authZ. This is being piloted in one of the state wide deployments in India in 2023. Also with ABDM OTP integration with Aadhar for Consent by Patient, Bahmni already has Patient driven registration process in place.

6. With support for OCL and CIEL dictionary, any new coding standards (LOINC, ICD10, RxNorm, etc) which are adopted by OCL, will become available to Bahmni via the Bahmni-OCL subscription module.

7. For all roadmap items/initiatives of Bahmni please see this page: https://bahmni.atlassian.net/wiki/spaces/BAH/pages/1645674497