Missing services in the OpenHIE Framework
Designing digital health architectures that build trust, not just connections.
The Open Health Information Exchange (OpenHIE) framework has guided countries for more than a decade, helping them move from disconnected systems to structured, interoperable architectures. It remains one of the most pragmatic and adaptable frameworks available — particularly in low- and middle-income countries where resources are limited, and alignment among stakeholders is essential.
But the world it was designed for is not the world we’re in today. The rise of patient-facing applications, AI-assisted analytics, and cross-sector data platforms means that personal and health data is now being collected, processed, and used in ways that the original OpenHIE model never had to anticipate.
And while interoperability is still essential, it’s no longer the only requirement. The next phase of digital health transformation will depend on digital trust: the confidence that data can move safely, transparently, and with the user’s consent. This calls for two new components in the framework: Identity and Access Management (IAM) and Consent Management.
Overview of the OpenHIE Framework
If you’re already familiar with the OpenHIE architecture, feel free to skip ahead. But if you need a quick reminder, here’s the gist.
OpenHIE is a framework that outlines how digital health software and applications can talk to each other by organising the flow of data through a set of shared services and registries. These are typically positioned upstream of an interoperability layer. Together, these structures make it possible for information to move safely between different parts of the health system.
Each building block in the architecture has a specific role. This simple organisation of structures needed for data exchange remains one of OpenHIE’s greatest strengths. But as national systems mature and data begins to move more fluidly, trust, privacy, and accountability have become as essential to interoperability as the technical connections that make it possible.
Updating interoperability architecture
The WHO Global Strategy on Digital Health, the OECD’s Recommendation on Health Data Governance, and the World Bank’s guidance on Digital Public Infrastructure (DPI) all point in the same direction: interoperability must rest on a foundation of trust, accountability, and rights-based governance.
This can’t be achieved through policy documents alone. It needs to be engineered into the architecture itself. This is where IAM and Consent Management come in — two core services of modern interoperability frameworks.
In an updated OpenHIE architecture, IAM sits in front of the interoperability layer acting as the secure gateway that authenticates and authorises every system or user before data moves through the exchange layer. The Consent Management Service operates behind the interoperability layer, enforcing patient permissions and data-sharing rules whenever information is requested or transmitted.
Identity and Access Management (IAM)
IAM answers two simple but fundamental questions: who are you, and what are you allowed to do? In a national health ecosystem with hundreds of users and applications, this is what keeps the entire system safe and accountable.
At first glance, the OpenHIE framework may seem to already include this - you may have noticed “authentication” appears within the interoperability layer in the images above. What this refers to, however is system security handled by the interoperability layer (often implemented through OpenHIM). OpenHIM issues a client ID and secret (or certificate) to each system that connects to it. When that system sends a request or message, OpenHIM authenticates it by confirming:
this request came from a known and registered system
it’s using valid credentials
it’s allowed to use a specific channel or endpoint
This prevents rogue or unauthorised software from pushing or pulling data through the exchange layer.
A full IAM service goes much further. It includes the people, roles, and policies that govern how data is accessed across the entire ecosystem. At a technical level, IAM combines a few key functions:
Authentication: confirming identity through passwords, tokens, or biometrics, often implemented using standards like OpenID Connect (OIDC) or Security Assertion Markup Language (SAML).
Authorisation: determining what actions an authenticated user or system can perform, using OAuth2 scopes, role-based access control (RBAC), or attribute-based access control (ABAC) models.
Single Sign-On: allowing a verified user to log in once and access multiple connected health systems securely, without needing separate usernames and passwords for each platform.
Audit and accountability: recording who accessed what, when, and from where, turning digital footprints into a governance trail.
Beyond turning trust from a policy goal into an architectural capability, the IAM service also simplifies implementation across government systems. It removes the need for every new application to build its own login or user management feature by providing a central authentication service that all systems can connect to. This not only reduces duplicated development effort but also ensures consistent access control and security standards across the ecosystem.
It also cuts down on maintenance overhead. Updates to user roles, access privileges, or password policies can be made once in the IAM platform and applied automatically to all connected systems, rather than being reconfigured in each application separately.
Most importantly, IAM improves the user experience for health workers and administrators. Through single sign-on, users can log in once and move seamlessly between digital systems without juggling multiple passwords or accounts. A simple but transformative change in health systems where dozens of platforms are deployed side by side.
Consent Management
The consent management service brings ethics and human rights into the technical fabric of digital health. In many health information exchanges today, data moves between systems automatically once connections are established. There is no mechanism for patients to see, approve, or restrict how their information is used. The consent management service fills that gap by managing consent as structured, machine-readable data rather than as paper forms or static policy documents.
A well-designed Consent Management service supports a few essential functions:
Capture: obtains informed consent from individuals for specific types of data sharing.
Store and manage: keeps consent decisions in a secure repository linked to the data. Behind this, a rules engine codifies the conditions for consent by translating national data protection laws, ethics board requirements, and programme-specific privacy policies (such as those governing HIV or mental health data) into machine-readable logic.
Enforce: applies consent rules automatically before sharing or exchanging data and information.
Audit and transparency: gives both patients and system administrators a clear view of what data was shared, with whom, and when.
In short, consent management operationalises digital ethics and enables three complementary forms of governance:
Rights-based governance: ensuring that individuals have visibility and control over how their personal data is collected, shared, and used. For example, a patient can decide whether their health record may be shared across facilities or used for secondary purposes like research.
Context-based governance: applying different consent rules depending on the purpose of data use or the type of organisation requesting it. For instance, a patient’s vaccination data might be shared with the national immunisation registry for public health reporting, but not with third-party analytics or insurance platforms.
Programme-specific governance: enforcing policies defined by specific health programmes, where privacy expectations and legal frameworks differ. For example, an HIV or mental health programme may require explicit consent before information can be shared beyond the care team, while an antenatal care programme might operate under implied consent within a public health mandate.
It also helps close the common gap between policy and implementation. When a new data protection rule or programme-specific privacy requirement is approved, it can be added directly to the consent service’s rules engine and enforced across all connected systems without waiting for each application to update its own code. This not only accelerates compliance but can also reduce long-term maintenance costs for governments and implementers.
The next frontier of digital health isn’t more applications or faster data flows, it’s governance by design. As countries modernise their digital health systems, embedding IAM and consent management into national architectures will do more than strengthen security. It will simplify implementation, accelerate compliance, and reduce the long lag between policy and practice.
Building trust into the architecture from the start prevents costly redesign later and ensures that as data moves, it does so safely, transparently, and in line with public expectation.