DocumentationSupportCosta Rica · Contact
ESENPT
Let’s talk
  • Organizational
  • Technical

OpenHIEOpen Health Information Exchange

In short

OpenHIE is an open community that maintains a reference architecture for countries to build their national health information exchange. It describes which shared pieces are needed (registries of patients, facilities and health workers, terminologies, an interoperability layer) and how they communicate. It is not software: it is a common blueprint that each country adapts.

Type
Reference model
Steward
OpenHIE community
Current version
Architecture Specification 5.2
Reviewed
October 25, 2026

Explanation

What it is

OpenHIE describes itself as a community of people building an open framework to support nations in developing health information exchanges. According to its own history, the community of practice formed in early 2013, evolving from work that began in 2009 to establish the Rwandan Health Information Exchange (RHIE).

Its core product is the OpenHIE Architecture Specification, published under a Creative Commons Attribution 4.0 licence. As of October 2026, the current version is 5.2, from August 2024.

The architecture

BlockComponents
Business domain servicesShared health record, health management information system (HMIS), logistics management information (LMIS), finance and insurance
Registry servicesTerminology service ("what?"), client registry or MPI ("for whom?"), facility registry ("where?"), health worker registry ("by whom?"), product catalogue
Interoperability services layerAuthentication of systems, linking health workers with facilities, message orchestration, entity matching
Point of serviceHealth records and mobile applications that read and update the shared information

The interoperability layer receives all communications from external services within a health geography and orchestrates their processing.

How it is specified

Each component has functional and non-functional requirements, and each exchange is described as a workflow with its transactions. Workflows rely on IHE profiles and FHIR alternatives: for example, registering a patient can use the ITI-8 transaction (HL7 v2) or ITI-104 (FHIR). OpenHIE states that its architecture is not limited to the profiles it lists.

Versions

VersionDateNotable change
3.0September 2020laboratory workflows and workflow maturity level
4.0September 2021move from PDF to GitBook, vaccine workflows
5.0July 2022finance and insurance workflows
5.2August 2024finance and insurance service requirements

Common misconceptions

  • Taking it for a product. OpenHIE defines components, requirements and workflows; the architecture aims for services such as the client registry to be interchangeable.
  • Trying to implement everything at once. The specification allows supporting only the workflows each use case needs.

Usage examples

  1. The OpenHIE community grew out of work begun in 2009 to establish the Rwandan Health Information Exchange (RHIE).

  2. In Mozambique, as part of the Ministry of Health's eHealth strategy, a master facility list was built to align the lists of the HMIS subsystems, according to an OpenHIE impact story.

  3. In South Africa, the Human Resources for Health registry was introduced to respond to the COVID-19 pandemic, according to an OpenHIE impact story.

  4. OpenHIE's aggregate reporting workflows use the IHE ADX profile to send numerators and denominators of public health indicators; version 5.0 added mADX.

  5. Version 5.0 of the specification added finance and insurance workflows, such as enrolling beneficiaries, checking coverage eligibility and claiming.

  6. A health record system registers a new patient by sending an ITI-8 message to the interoperability layer, which passes it to the client registry.

Relation to other terms

Relies on5

  • HIERequired

    OpenHIE is a reference architecture for building a health information exchange.

  • IHEStrong

    Its exchange workflows are specified with IHE profiles and transactions, although the architecture is not limited to them.

  • MPI / EMPIStrong

    The client registry (MPI) is one of its registry services, although each implementation adopts only the workflows it needs.

  • Terminology serverStrong

    The terminology service is one of its registry services and has its own workflows, such as expanding value sets or translating codes.

  • FHIRMedium

    Some workflows, such as registering a patient, offer FHIR transactions as an alternative to those based on HL7 v2.

Depend on this one1

  • DPI-HMedium

    The report shows a strong overlap between its components and those of OpenHIE, and aligns them in a table.

Sources

  1. OpenHIE — Homeohie.org
  2. OpenHIE — About (vision, mission and history)ohie.org
  3. OpenHIE Architecture Specification — Architectureguides.ohie.org
  4. OpenHIE Architecture Specification — Version Change Logguides.ohie.org
  5. OpenHIE Architecture Specification — Standards and Profilesguides.ohie.org
  6. OpenHIE Architecture Specification — Client Registry (CR)guides.ohie.org
  7. OpenHIE Architecture Specification — Create Patient Demographic Record Workflowguides.ohie.org
  8. OpenHIE — Master Facility List Experiences and Lessons from Mozambiqueohie.org
  9. OpenHIE — Health Worker Registry Project in South Africaohie.org
Health interoperability glossary