National health information systems.

Centralised authentication, a trusted register of health workers and a working interoperability layer are the foundations the rest of a national health information architecture is built on. This page sets out how we approach them and what we already have running.

Single sign-on OpenHIM Shared Health Record HL7 FHIR

Foundations first.

A hospital system, a DHIS2 instance and a supply chain tool each keep their own list of users and their own list of health workers. That duplication is where data quality problems and access-control problems begin. A shared identity layer and shared registries fix the cause rather than the symptom.

Central Authentication

Single sign-on

Single sign-on across every connected system, so a health worker signs in once and reaches everything they are entitled to use.

Built on open standards — OpenID Connect, OAuth 2.0 and SAML 2.0 — rather than a proprietary login that ties the institution to one supplier.
Open-source identity platforms, self-hosted, so the identity layer and the user data inside it stay under the institution's own control with no per-user licensing.
Role-based access control defined centrally, instead of separately and inconsistently inside every application.
Onboarding and offboarding in one place — when a person leaves, access is revoked everywhere at once.
Multi-factor authentication, password policy and session policy applied consistently across connected systems.
Complete authentication and authorisation audit trail for oversight and incident investigation.
Integration of existing applications as standards-based clients, including legacy systems never designed for federated login.

Interoperability & Data Exchange

Integration

An OpenHIM-based interoperability layer that mediates, routes, logs and secures traffic between systems, so integrations do not multiply into an unmaintainable web of point-to-point links.

A Shared Health Record that assembles a consolidated patient record from the systems that contribute to it, rather than becoming yet another parallel database.
Documented REST APIs with versioning, authentication and explicit contracts — so an integration can be maintained by someone who did not write it.
Integration with platforms already in place, including DHIS2 and existing hospital information systems, rather than replacing them.
Scheduled synchronisation and reconciliation for environments where real-time exchange is not realistic.
Clear failure behaviour: retries, dead-letter handling and alerting, so a broken integration is noticed before the data is missed.
Mapping between local code sets and international standards where health data crosses institutional boundaries.

Analytics & Oversight

Reporting

Dashboards built around a decision someone has to make, not a wall of charts.

Statutory and development-partner reporting generated from live data, with every figure traceable to its source record.
Data quality surfaced as part of reporting — missing, late and implausible entries flagged rather than silently averaged.
Disaggregation by province, district, facility and cadre.
Export to Excel, CSV and PDF, because that is how reports actually move between institutions in Nepal.

Reference architecture

How the pieces fit together.

Point-of-service systems talk to an interoperability layer, not to each other. The registries hold the authoritative records. One identity provider covers every layer. Each block can be replaced without rewriting the others.

Reference architecture. Registries, the identity layer and the interoperability layer stay separate and independently replaceable — so no single component becomes the thing nobody dares to change.

Standards & architecture

What we build to.

These are the standards and technologies we design against. We name them because a procuring agency should be able to check our assumptions, not because a logo list proves anything.

Ref	Component	Standard / technology
S-01	OpenHIE-style architecture	registries, a shared identity layer and an interoperability layer kept as separate, replaceable components.
S-02	GOFR (Global Open Facility Registry)	we work with GOFR, the open-source facility registry built on HAPI FHIR and the IHE mCSD profile, including its DHIS2 synchronisation.
S-03	OpenHIM	an open-source interoperability layer that mediates, routes, logs and secures the traffic between systems, instead of point-to-point links that multiply.
S-04	Shared Health Record (SHR)	a consolidated patient record assembled from the systems that contribute to it, rather than yet another parallel database.
S-05	HL7 FHIR	Location, Organization and Practitioner resources as the exchange format between institutions.
S-06	OAuth 2.0 / OpenID Connect / SAML 2.0	open standards for single sign-on, authentication and authorisation.
S-07	DHIS2	integration with the national reporting platform rather than duplicating it.
S-08	Role-based access control and audit	every read and write attributable to a person and a role.
S-09	Data protection	least-privilege access, encrypted transport, and retention rules agreed with the data owner.

Evidence

What we already have running.

A capability statement is worth more when part of it is already deployed. These are delivered systems that exercise the same building blocks — workforce data, approval workflow, role-based access, audit trails and API-driven integration.

Working on registries or national identity infrastructure?

We are glad to walk through architecture options, effort estimates or an existing specification — no obligation.

Start a conversation