Interoperability and open standards: the unglamorous core of digital public infrastructure

Guides · Published 2026-10-07

Silhouettes of a long row of ship-to-shore container cranes against a violet twilight sky — Container cranes at a terminal in the Port of Antwerp: standard boxes, interchangeable equipment. Photo: Trougnouf (Benoit Brummer), CC BY 4.0, via Wikimedia Commons.

The shipping container did not become a global standard because it was clever, but because everyone agreed on its dimensions. Digital public infrastructure works the same way: its value comes less from any single system than from the agreements that let systems work together. Those agreements are called interoperability, and the shared specifications that make it possible are standards.

Interoperability is more than technology

The European Interoperability Framework (EIF), adopted by the European Commission in 2017, describes four layers of interoperability, all of which have to work for two public services to cooperate:

Layer	The question it answers	Example of failure
Legal	Are both organisations allowed to exchange this data, under compatible laws?	A tax office cannot share data with a benefits agency because no law permits it.
Organisational	Are processes, responsibilities and service agreements aligned?	Each agency expects the other to verify the applicant's address.
Semantic	Do both sides mean the same thing by each data element?	"Household income" is gross in one system, net in another.
Technical	Can the systems connect and exchange messages securely?	Incompatible protocols or authentication methods.

The EIF wraps these layers in governance: someone must decide which standards to use, maintain shared vocabularies and resolve disputes. Most interoperability projects that fail do so on the legal, organisational or semantic layers, not the technical one.

What makes a standard "open"?

There is no single legal definition, but most public-sector definitions, including the criteria used in the EIF and in national policies such as the UK's Open Standards Principles, share a core:

Published specification: anyone can read the full specification, free or at nominal cost.
Open development: the standard is developed and maintained through a transparent process open to interested parties.
Fair licensing: it can be implemented without royalties, or on fair and non-discriminatory terms, so that open-source and proprietary implementations can coexist.
No single-vendor control: the standard does not depend on one company's product.

Open standards and open-source software are different things. A proprietary product can implement an open standard; an open-source project can use a closed or undocumented format. For public infrastructure, open standards are usually the more important of the two, because they keep the door open to many implementations. We compare the two in open source versus proprietary software in government.

Standards that matter for DPI

Identity and authentication

OpenID Connect, published by the OpenID Foundation in 2014, is the most common protocol for logging in with an identity provider. National identity platforms such as Singpass and MOSIP's eSignet offer OpenID Connect interfaces, which lets services integrate them with widely available libraries.
Verifiable credentials. The W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation in May 2025. OpenID Foundation specifications for issuing and presenting credentials (OpenID for Verifiable Credential Issuance and OpenID for Verifiable Presentations) and the ISO/IEC 18013-5 standard for mobile driving licences are used in digital wallet projects, including the EU Digital Identity Wallet.

Payments

ISO 20022 is the international standard for financial messaging, carrying richer structured data than older formats. It underpins many instant payment systems and the SEPA schemes in Europe, and the cross-border correspondent banking network has migrated to it.
EMVCo QR code specifications are widely used as the basis for interoperable merchant QR codes.

Health

HL7 FHIR (Fast Healthcare Interoperability Resources) defines how health data is structured and exchanged through web APIs. National programmes, including India's ABDM, publish FHIR profiles that adapt it to local needs.

Data exchange and government services

X-Road's protocols, published openly by the Nordic Institute for Interoperability Solutions, define how security servers exchange signed messages. See the Estonia case study.
GovStack specifications describe functional and technical requirements for reusable building blocks (identity, payments, consent, registration, messaging, information mediation) that governments can use in procurement.
Core vocabularies such as the EU's SEMIC core vocabularies (for persons, businesses, locations and public services) address the semantic layer.

Europe's Interoperable Europe Act

The EU turned interoperability from guidance into law with Regulation (EU) 2024/903, the Interoperable Europe Act, which entered into force on 11 April 2024 and has applied since 12 July 2024. Its main provisions:

public bodies must carry out an interoperability assessment before introducing or significantly changing systems that affect cross-border services;
an Interoperable Europe Board, with representatives of member states and EU institutions, sets the strategic agenda;
reusable solutions can be designated as "Interoperable Europe solutions" and shared through a portal;
the regulation encourages the sharing of solutions, including open-source software, between administrations, and introduces regulatory sandboxes for innovation.

The text is available on EUR-Lex.

Common pitfalls

Standards on paper only. A policy that "mandates open standards" without conformance testing or enforcement in procurement changes little.
National forks. Heavily customised national versions of an international standard can become incompatible with everyone else, recreating the isolation the standard was meant to end.
Ignoring versioning. Interfaces change. Without a published versioning and deprecation policy, every upgrade breaks participants who were not warned.
Treating interoperability as a one-off project. Shared vocabularies, code lists and profiles need permanent owners and budgets, like any other infrastructure.

Practical advice for teams

Adopt before you invent. Use existing international standards with national profiles; inventing a format creates a long-term maintenance burden.
Write standards into procurement, with conformance tests, rather than naming products.
Fund the semantic layer: shared data definitions and code lists need owners and budgets.
Publish your profiles and versioning policy so participants can plan.
Fix the law early: technical interoperability without a legal basis for exchange will sit unused.