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 organization, 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 organization'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 defense. 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 labeled 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.

Standardize 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 standardizes 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 recognized 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 recognized 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¶

Favor 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 program 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¶

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 organizations 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.

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 modernizes 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 amortized across the whole estate. The return on investment (ROI) shows up as reduced integration labor, 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 modernization programs 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 recognize 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: Initial. 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 unrecognized.
• Level 2: Managed. Common formats such as JSON or XML are used, and some APIs are documented. 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: Defined. Open data-exchange standards (OpenAPI, and the relevant domain standard such as FHIR or ISO 20022) are mandated. 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: Optimizing. Interoperability is governed as an asset: versions and profiles are managed, certification is required of suppliers, and organizational interoperability (agreements, consent, process alignment) is handled systematically. The organization contributes to the standards it depends on, measures lock-in risk deliberately, and treats portability as a permanent design constraint.

Ideas for discussion¶

1. For your most critical data exchange, at which of the four levels (technical, syntactic, semantic, organizational) is it weakest today?
2. If your primary vendor doubled its price at renewal, how long and how expensive would it be to switch, and what makes it so?
3. Which of your integrations are point-to-point, and what would it take to move them behind a shared open standard?
4. Where are you storing free text that a published code system or terminology could replace, and what errors does the free text hide?
5. Does "supports the standard" in your contracts require passing an independent conformance or certification test, or is it merely asserted?
6. 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.
• Standardize the API and data-exchange layer (OpenAPI, JSON/XML, gRPC/Protobuf) and adopt your domain's recognized 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