3.8 Interoperability and open standards

Overview and motivation

Interoperability is the ability of two or more systems to exchange information and to use the information that has been exchanged, without either side having to know the internal workings of the other. An open standard is a specification that is publicly available, developed and maintained through a transparent and consensus-based process, and free (or fair, reasonable, and non-discriminatory) to implement, so that anyone can build a conforming system without permission from a single vendor. Designing for interoperability means building systems that connect through these shared, published specifications, rather than through bespoke integrations: one-off, custom-built connectors that link exactly two systems and must be rebuilt every time either side changes.

For a large organisation, interoperability is not a nicety. It is the substrate on which everything else runs. Enterprises acquire companies, replace vendors, and stitch together dozens of internal and third-party systems, and open standards are what let a new component slot in without a rewrite. For government the stakes are higher still. Public services are delivered across many agencies, tiers of government, and private suppliers, and no single body controls the whole estate. A citizen applying for a benefit may touch identity, tax, health, and welfare systems owned by different departments. Those systems must interoperate, or the service fails. Public bodies also change suppliers on procurement cycles measured in years, so any dependence on a single vendor’s proprietary interfaces becomes a long, expensive trap.

The recurring failure mode is the opposite of interoperability: proprietary lock-in, where an organisation’s data and processes are so entangled with one vendor’s non-standard formats and interfaces that switching, integrating, or even reading the data later becomes prohibitively costly. Open standards are the primary defence. This chapter covers the levels at which systems must interoperate, the standards that make it possible, and how to design, procure, and certify for it. It connects closely to APIs and interface design (chapter 2.3), distributed systems (chapter 3.3), data strategy and governance (chapter 7.1), procurement and open source (chapter 10.3), and compliance and governance (chapter 4.6).

Key principles

Interoperability is designed in, not bolted on. Decide the standards before the build, because retrofitting them means rewriting interfaces and migrating data.
Prefer open standards over bespoke integrations. A conforming interface serves every current and future partner; a custom connector serves exactly one.
Interoperability has levels. Getting bytes across the wire (technical) is worthless if the two sides disagree on what the bytes mean (semantic).
Meaning lives in shared vocabularies. Identifiers, code systems, and terminologies are what make exchanged data usable, not just transmittable.
Standards are only real if you conform to them. A “supports FHIR” claim without conformance testing is marketing, not interoperability.
Lock-in is a total-cost-of-ownership decision. The cheap proprietary option today is often the expensive trapped estate tomorrow.
Government multiplies the need. Public services span organizational boundaries no one controls, so open standards are frequently a mandate, not a preference.

Recommendations

Design for all four levels of interoperability

The European Interoperability Framework and related models describe four levels, and a system must satisfy all of them to truly interoperate. Technical interoperability is the plumbing: networks, protocols, and transport (for example HTTPS) that move bytes between systems. Syntactic interoperability is agreement on structure and format, the grammar of the message, such as JSON (JavaScript Object Notation, a lightweight text data format) or XML (eXtensible Markup Language). Semantic interoperability is agreement on meaning: that a field labelled gender or a code 250.00 means the same thing to both parties. Organizational interoperability is alignment of processes, governance, roles, and legal agreements: who is allowed to send what to whom, under which data-sharing agreement, and for what purpose. Most integration projects nail the first two levels and fail on the third and fourth. Treat semantic and organizational interoperability as first-class design work, not afterthoughts.

Standardise the data-exchange and API layer

Adopt open, widely implemented standards for how systems describe and expose their interfaces. For web APIs (Application Programming Interfaces, the defined contract through which one system calls another), use the OpenAPI Specification, a vendor-neutral, machine-readable description of a REST (Representational State Transfer) API that both documents the interface and generates client code, servers, tests, and mocks. For payload formats, prefer JSON for its ubiquity and human readability, and use XML where an ecosystem already standardises on it. Where you need high-performance, strongly typed communication between services, consider gRPC (a remote-procedure-call framework) with Protocol Buffers (Protobuf), a compact, schema-defined binary format, which itself is an open specification. The point is not the specific technology. It is that the contract is published, machine-readable, and independently implementable. See chapter 2.3 for interface design depth.

Adopt the recognised standard for your domain

Most sectors have converged on domain-specific interoperability standards. Use them rather than inventing your own. Healthcare is the leading example. HL7 (Health Level Seven, a standards body and its older messaging standards) has been largely superseded for new work by FHIR (Fast Healthcare Interoperability Resources), a modern standard that models clinical concepts (patient, observation, medication) as web resources exchanged over REST APIs using JSON or XML. In finance, ISO 20022 is the open standard for structured, richly annotated payment and financial messaging, now adopted by payment systems worldwide. In geospatial data, the OGC (Open Geospatial Consortium) publishes standards such as WMS and WFS for map and feature services. Other examples include OASIS and UBL for business documents, and IFC (BuildingSMART) for construction. Choosing the recognised standard buys an entire ecosystem of conforming tools, suppliers, and trained staff.

Anchor meaning in identifiers, code systems, and ontologies

Semantic interoperability requires shared vocabularies. Use standard identifiers so that the same real-world thing has the same reference everywhere (for example an ISO country code, a LEI for a legal entity, or a national patient identifier). Use published code systems and terminologies (controlled lists of coded concepts with defined meanings) instead of free text: SNOMED CT and LOINC for clinical terms, ICD (International Classification of Diseases) for diagnoses, Unicode for text. Where relationships between concepts matter, use an ontology (a formal, machine-readable model of concepts and how they relate) expressed in standards such as RDF and OWL (the W3C Web Ontology Language). Governance of these vocabularies is a data-governance responsibility; see chapter 7.1.

Integrate through standards-based patterns, not point-to-point wiring

Favour architectural patterns that keep the number of integrations linear rather than combinatorial. N systems wired point-to-point can require up to N×(N−1)/2 bespoke connectors. The same N systems each conforming to a shared standard require only N implementations of that standard. Use gateways, published API contracts, and canonical data models so a new participant integrates once against the standard, rather than against every existing system. This is also the antidote to lock-in: because the contract is open, a vendor can be replaced without touching everyone connected to it.

Require conformance and certification

A standard delivers value only when implementations actually conform to it. Insist on conformance testing (automated checks that an implementation meets the specification) using published test suites and validators (for example FHIR’s validators and Touchstone testing, or OpenAPI schema validation in your build pipeline). Where a formal certification programme exists (an independent body attesting conformance, as in national health-IT certification schemes), prefer certified products and require certification in contracts. Bake conformance checks into continuous integration, so that drift from the standard fails the build rather than surfacing in production.

Trade-offs: pros and cons

Approach	Pros	Cons / cost
Open standard	Many suppliers, no lock-in, ecosystem tools, future partners integrate cheaply	Standard may be broad/complex, slower to adopt niche features, committee-paced evolution
Bespoke point-to-point integration	Fast for the first connection, exact fit, minimal upfront learning	Cost grows combinatorially, brittle, re-done on every change, breeds lock-in
Proprietary vendor format/API	Rich features, vendor support, quick start within one ecosystem	Lock-in, switching cost, data hard to extract later, pricing power shifts to vendor
Domain standard (FHIR, ISO 20022)	Shared meaning, trained workforce, regulator-aligned	Learning curve, mapping legacy data, versioning and profile management overhead

The master trade-off is short-term convenience versus long-term optionality. A bespoke or proprietary integration is almost always faster to stand up for the very first connection, which is why organisations drift into lock-in one reasonable decision at a time. Open standards front-load cost (learning the specification, mapping existing data, building conformance tests) and repay it every time a new partner, supplier, or system joins without a rewrite. For a system with a long life and many participants, which describes nearly every enterprise and government platform, the standards-based path wins decisively. For a genuinely throwaway one-to-one link, bespoke may be rational. The error is treating long-lived platforms as if they were throwaway links.

Questions to discuss with your team

Who owns the organizational interoperability (the data-sharing agreements, consent models, and process alignment) that your technical integration depends on? Most projects nail the technical and syntactic levels and stall on the organizational one: the bytes arrive and parse, but no agreement governs who may send what to whom, for what purpose, under which consent. In government a citizen’s data crosses agencies that each own their systems and answer to different legal bases, so a perfect FHIR interface is worthless until the sharing agreement and consent model exist. Bring your most important cross-boundary exchange and name the legal instrument and the accountable owner on each side, not just the API. If that owner is unnamed, the integration will pass every technical test and still be blocked in production. Treat these agreements as design artifacts with the same rigour as the message schema.
How heavily do you lean on a standard’s proprietary extensions, and could another conforming implementation still talk to you? Standards include escape hatches, and overusing them is de facto lock-in wearing an open badge: you claim FHIR or ISO 20022 but no independent vendor can actually interoperate with your dialect. This creeps in one reasonable customisation at a time, which is why a large estate should measure it deliberately. Bring a real message and count how much of its meaning rides on standard fields versus custom extensions; the higher the custom share, the weaker your portability and the stronger the incumbent vendor’s pricing power. Prefer profiling within the standard’s rules, and contributing gaps back to the standard, over private extensions. The whole point of the open path is that a vendor can be replaced without touching everyone connected, and extensions quietly erode that.
Which version and profile of each standard are you on, and who governs that choice across the estate? “Supports the standard” is meaningless without version and profile discipline, because two systems can both claim FHIR or ISO 20022 and still fail to talk if they implement different versions or profiles. In a large organisation with many suppliers and long procurement cycles, versions drift apart silently until an integration breaks. Bring an inventory of every interface, its standard, its version, and its profile, and name who is accountable for keeping them aligned and for planning upgrades. Bake the version and profile into conformance tests in the pipeline so drift fails the build rather than surfacing in production. Without this governance, nominally conformant systems still cannot interoperate, which is the exact failure open standards were meant to prevent.
When a contract or a supplier says “supports the standard”, what independent test actually proves it, and where does that test run? A conformance claim with no test behind it is marketing, and it fails in the worst place: in production, after money has changed hands and the system is live. For a large organisation buying from many suppliers, the temptation is to accept a checkbox on a questionnaire, because insisting on validated conformance slows procurement and narrows the bidder pool. Bring the published validator or test suite for each standard you depend on (for example FHIR validators and Touchstone, or OpenAPI schema validation), a sample of real messages run through it, and the clause in your contract that ties acceptance and payment to passing it. The competing pull is speed versus proof: a certified product may cost more and take longer to onboard, but an unverified one transfers the failure to your integration team. In government and regulated settings, where national health-IT or payment certification schemes exist, require certification in the contract and wire the validator into continuous integration so drift fails the build, because an assertion you never tested is a liability you will discover during an audit or an outage.
How many of your integrations are still point-to-point, and what is the true combinatorial cost of leaving them that way? Bespoke one-to-one connectors are the fastest thing to build for the first link and the most expensive thing to own across an estate, because the count grows toward N×(N−1)/2 while a shared standard needs only N implementations. In a large organisation this sprawl accretes one reasonable decision at a time until the integration map is unmaintainable and every system change ripples through a dozen brittle connectors. Bring an inventory of your integrations classified as point-to-point versus standards-based, the number of connectors touched by your last major system replacement, and an estimate of the engineering time spent maintaining custom links. The tension is that migrating live point-to-point wiring behind a gateway or canonical model is real work with no immediate feature payoff, so it loses to the roadmap unless someone quantifies the carrying cost. For enterprise and government platforms that live for decades and add participants continuously, the point-to-point path is a slow tax; name an owner for the integration architecture and a plan to route new participants through the standard rather than against every incumbent.
Where are you conveying meaning as free text that a published code system or terminology should carry, and who governs those vocabularies? Semantic interoperability is where most integrations quietly fail: the bytes arrive and parse, but a diagnosis, currency, or country stored as an unconstrained string means one thing to the sender and something subtly different to the receiver. For a large organisation the cost is invisible until reporting, analytics, or a regulator exposes that the same concept was coded three ways across three systems. Bring examples of fields currently held as free text, the standard identifiers and code systems that could replace them (SNOMED CT and LOINC for clinical data, ISO codes for countries and currencies, a LEI for legal entities), and the error rates or reconciliation effort the free text is hiding. The competing consideration is that mapping legacy data to controlled vocabularies is painstaking and never demoed, so it is chronically underfunded relative to the transport layer. In government, where a citizen’s record is assembled from many independent systems and a mismatched code can deny a benefit or corrupt a health record, treat vocabulary governance as a named data-governance responsibility (chapter 7.1), not an implementation detail left to each team.

Sector lens

Startup. Speed wins, and open standards are how a tiny team reaches many customers without building many connectors. Speak the formats every partner already supports (OAuth for sign-in, iCalendar for scheduling, webhooks for events, JSON over an OpenAPI contract) so one integration reaches thousands of customers and a vendor swap touches a single adapter. Avoid inventing your own format or hand-wiring each customer’s stack; that is future maintenance you cannot staff. The standards path costs a little more upfront and keeps switching cheap in a market you cannot yet predict.

Small business. With no integration specialists and a tight budget, treat interoperability as a buying decision rather than a build project. Prefer tools that already speak the open standard for your sector and expose a documented API, so your data stays portable if you change suppliers. Ask a would-be vendor how you get your data out and in what format before you sign, because the cheap proprietary option today is the trapped estate tomorrow. You will rarely run a conformance test yourself, so lean on products that are certified or widely interoperable.

Enterprise. The challenge is governing interoperability across many teams, suppliers, and long procurement cycles. Mandate the domain standard (FHIR, ISO 20022, OGC) and a published OpenAPI contract, then keep an inventory of every interface with its version and profile and an accountable owner, so nominally conformant systems do not drift apart. Route new participants through gateways and canonical models rather than point-to-point wiring, wire conformance validation into continuous integration, and measure how much of your traffic rides on standard fields versus proprietary extensions. Manage lock-in and portability as a deliberate total-cost-of-ownership position, not an accident.

Government. Open standards are frequently a mandate, because public services span agencies no single body controls and suppliers change on multi-year cycles. Require conformance testing and, where schemes exist, national certification in every contract, and demand data portability so a departing vendor cannot hold the public’s data hostage. Anchor meaning in national identifiers and published terminologies so a citizen’s record means the same thing across departments, and handle organizational interoperability through explicit data-sharing agreements and consent models with named accountable owners. Transparency and the public purse both argue for the open, independently implementable path over any proprietary convenience.

Examples

Startup. A small startup building a team-productivity app wires up to its customers’ existing tools through open standards rather than bespoke connectors: OAuth for sign-in, iCalendar for scheduling, and webhooks for events. Because it speaks formats every calendar and identity provider already supports, one integration reaches thousands of customers instead of one, and swapping a payment or email vendor later touches a single adapter. Had it hand-built a custom link to each customer’s stack, every new logo would have meant another connector to write and maintain.

Enterprise. A multinational bank modernises its cross-border payments by migrating from a legacy proprietary message format to ISO 20022. Because the standard carries structured, richly annotated data (payer, payee, purpose, regulatory fields) rather than free text, downstream systems for fraud screening, reconciliation, and reporting consume one canonical format instead of a dozen bespoke parsers. When the bank later replaces its payment-gateway vendor, the new supplier already speaks ISO 20022, so the switch touches the gateway and not the hundred systems behind it. The open standard converted a vendor migration from a multi-year rebuild into a contained replacement.

Government. A national health service needs hospitals, clinics, laboratories, and a patient-facing app (built by different suppliers over two decades) to share records safely. It mandates FHIR for data exchange: each system exposes patient, observation, and medication data as FHIR resources over REST APIs, using standard identifiers (a national patient ID) and clinical terminologies (SNOMED CT for conditions, LOINC for lab results) so the codes mean the same thing everywhere. Suppliers must pass FHIR conformance validation and hold national health-IT certification before connecting. A new clinic system integrates once against the FHIR standard rather than building bespoke links to every incumbent, and a citizen can view a unified record assembled from many independent systems. Organizational interoperability is handled through data-sharing agreements governing who may access what and why, satisfying compliance obligations (chapter 4.6).

Business case: motivations, ROI, and TCO

The financial argument for open standards is an argument about total cost of ownership (TCO) over the life of a system, not the sticker price of the first integration. Bespoke integration cost scales with the number of connections and is paid again on every change. Standards-based integration cost is paid once per participant and amortised across the whole estate. The return on investment (ROI) shows up as reduced integration labour, faster onboarding of new partners and suppliers, lower switching costs when vendors underperform, and avoidance of the classic lock-in tax where a sole supplier raises prices because no competitor can bid.

For leadership, frame the case around optionality and competition. Open standards keep procurement competitive (chapter 10.3). When interfaces are published and conformance-tested, multiple vendors can bid on equal terms, which drives price down and quality up over successive contracts. They also de-risk the future, because regulatory changes, mergers, and modernisation programmes all become cheaper when data and interfaces are portable. The largest hidden cost of ignoring standards is the eventual forced migration: extracting data from a proprietary format after the fact, with the original vendor gone or uncooperative, routinely costs many times what standards-based design would have cost up front. Governments increasingly recognise this and mandate open standards precisely to protect the public purse from lock-in over decades.

Anti-patterns and pitfalls

Technical interoperability mistaken for the whole job. The message arrives and parses, but the two sides disagree on what a field means, so the data is silently wrong.
“Standards-based” in name only. A product claims to support a standard but has never passed conformance testing and diverges in practice.
Free-text where a code system exists. Storing diagnoses, currencies, or countries as unconstrained strings destroys semantic interoperability.
Proprietary extensions that swallow the standard. Using a standard’s escape hatches so heavily that no other implementation can interoperate: de facto lock-in wearing an open badge.
Point-to-point sprawl. Adding one more bespoke connector each time, until the integration map is an unmaintainable combinatorial mess.
Version and profile chaos. No governance over which version or profile of a standard is in use, so nominally conformant systems still cannot talk.
Ignoring organizational interoperability. Perfect technical exchange blocked because no data-sharing agreement, consent model, or process alignment exists.
Building your own standard. Inventing a bespoke format when a mature, adopted domain standard already exists, and inheriting all its maintenance forever.

Maturity model

Level 1: Initiate. Integration is ad hoc and point-to-point. Formats are proprietary or undocumented. Meaning is conveyed by free text and tribal knowledge. Replacing any system or vendor is a major project. Lock-in is pervasive and largely unrecognised.
Level 2: Develop. Common formats such as JSON or XML appear, and some APIs are documented, but practice varies team by team. Interoperability is still mostly syntactic; semantic agreement is inconsistent and per-project. Standards are chosen reactively, and conformance is asserted but not tested.
Level 3: Standardise. Open data-exchange standards (OpenAPI, and the relevant domain standard such as FHIR or ISO 20022) are documented and mandated org-wide. Shared identifiers, code systems, and terminologies provide semantic interoperability. Conformance testing is part of the delivery pipeline, and integration follows standards-based patterns rather than point-to-point wiring.
Level 4: Manage. Interoperability is measured and controlled against baselines. Metrics are tracked and reviewed: the share of integrations that are standards-based versus point-to-point, the proportion of message meaning riding on standard fields versus proprietary extensions, conformance-test pass rates in the pipeline, version and profile drift across the estate, and integration lead time and defect rates for onboarding a new participant. Versions and profiles are governed, certification is required of suppliers and verified, and lock-in risk is quantified rather than sensed. Decisions to adopt, upgrade, or retire an interface are made on this evidence.
Level 5: Orchestrate. Interoperability is continuously improved and integrated across the organisation. Organizational interoperability (agreements, consent, process alignment) is handled systematically alongside the technical layers, the organisation contributes back to the standards it depends on, and portability is a permanent design constraint. The estate adapts as standards evolve and participants join or leave, rebalancing integration architecture and vocabulary governance on the measured evidence rather than on incident.

Ideas for discussion

For your most critical data exchange, at which of the four levels (technical, syntactic, semantic, organizational) is it weakest today?
If your primary vendor doubled its price at renewal, how long and how expensive would it be to switch, and what makes it so?
Which of your integrations are point-to-point, and what would it take to move them behind a shared open standard?
Where are you storing free text that a published code system or terminology could replace, and what errors does the free text hide?
Does “supports the standard” in your contracts require passing an independent conformance or certification test, or is it merely asserted?
Which open-standards mandates (national or sector) already apply to you, and are you actually meeting them or only claiming to?

Key takeaways

Interoperability means using exchanged information, not just transmitting it; design for all four levels: technical, syntactic, semantic, and organizational.
Prefer open, published, independently implementable standards over bespoke integrations and proprietary formats, which breed lock-in and combinatorial cost.
Standardise the API and data-exchange layer (OpenAPI, JSON/XML, gRPC/Protobuf) and adopt your domain’s recognised standard (FHIR in health, ISO 20022 in finance, OGC in geospatial).
Anchor meaning in shared identifiers, code systems, terminologies, and ontologies; semantic interoperability is where most integrations quietly fail.
Require conformance testing and, where available, certification; a standard is only real when implementations demonstrably conform.
Judge the choice on total cost of ownership and optionality over the system’s life; for long-lived, multi-party platforms (nearly all enterprise and government systems), open standards win, and government increasingly mandates them.

References and further reading

HL7 International, FHIR (Fast Healthcare Interoperability Resources) specification (hl7.org/fhir)
ISO 20022, Universal financial industry message scheme (iso20022.org)
OpenAPI Initiative, OpenAPI Specification (Linux Foundation)
Open Geospatial Consortium (OGC) standards (WMS, WFS, and successors)
European Commission, European Interoperability Framework (EIF) and the Interoperable Europe Act
UK Government, Open Standards Principles and the Technology Code of Practice (GOV.UK)
W3C, RDF, OWL (Web Ontology Language), and semantic-web standards
SNOMED International (SNOMED CT), Regenstrief Institute (LOINC), and WHO (ICD) terminologies
gRPC and Protocol Buffers specifications (Cloud Native Computing Foundation / open source)
NIST and IEEE literature on systems interoperability and conformance testing