Most healthtech products are described as "integrated" long before anyone checks whether they are interoperable. The two words get used as if they mean the same thing. They do not, and the difference decides whether your tenth hospital customer costs less to connect than your first, or costs more.

The distinction in plain terms

Integration connects two or more systems so that data moves from A to B for a defined purpose. It is the wiring, meaning the interfaces, adaptors, transformations, and workflows that make one exchange work today.

Interoperability is a set of lasting capabilities that let many systems understand, trust, and reuse each other's data safely over time. Integration is a project. Interoperability is a property of an ecosystem.

You can see the difference when something changes. Take a hospital lab feed mapped into a care-coordination app by transforming each HL7 v2 message into the app's own model. The integration works until the hospital changes a field or adds a new test code. Then the bespoke mapping breaks, usually quietly. Interoperability reduces that fragility by relying on common information models, shared code systems, and predictable APIs, so a new element can be discovered and handled without rewriting the pipeline.

The stakes in health are higher than in most sectors, because the data is safety-critical, sensitive, and spread across many organisations. An interoperable setup is one where a hospital discharge summary can be reliably ingested by a GP system, where consent travels with the record, where medicines are coded in a standard dictionary, and where an application asks only for the data it needs.

Why this matters commercially and clinically

Interoperability compounds. When your product speaks a widely used API and shared terminologies, each new connection is easier than the last. You spend less time on one-off mappings and more time on the product. Buyers see lower implementation risk, which shortens the sales cycle and lowers their cost of ownership.

It is also a safety feature. A blood pressure reading recorded with a recognised code, units, and context can be merged into a longitudinal record and used by decision support. The same reading stored in a private format can be misread or dropped. In England, the usual coding choices are SNOMED CT for problems, procedures, and most clinical observations, and dm+d for medicines. LOINC is common internationally, but it is not the NHS default for laboratory results, so confirm which coding your target trusts expect before you commit.

There is a protection against lock-in too. If your product depends on one vendor's private interface, your expansion is limited by that vendor's roadmap and licence terms. Building on open standards such as FHIR, with SMART on FHIR authorisation, lets you serve several markets without re-architecting the core.

And procurement is moving this way. NHS buyers and integrated care boards look for evidence that you follow published standards, minimise data, handle consent, and keep an audit trail. That evidence sits alongside UK GDPR, the Data Protection Act 2018, and clinical risk management under DCB0129 and DCB0160. Standard endpoints and traceable mappings build trust before the first meeting is over.

Integration is not the enemy

Every interoperable ecosystem contains many integrations. HL7 v2 feeds for admissions, discharges, and transfers and for orders and results will be around for years, as will DICOM for imaging and file extracts for legacy migrations. FHIR REST APIs are increasingly common for resources such as Patient, Encounter, Observation, MedicationRequest, and DocumentReference. Each solves a concrete problem. The skill is in choosing patterns that can be reused.

Consider a digital therapeutics company that needs a patient list from a GP practice, sends back weekly outcomes, and surfaces alerts to a clinician. A sensible design combines a bulk extract to seed the cohort, a subscription or polling to keep the list current, and a results interface that posts structured Observations back. If the practice system cannot accept those directly, a small integration engine can route the data into the channel that is available, even a PDF through a document workflow. The platform still keeps the structured version inside. The integration bridges the gap and the interoperable core stays intact.

Where integrations go wrong

The trouble starts when an integration carries your domain logic. Hard-coded mappings between a site's fields and your internal model, custom value lists with no external equivalent, and untyped JSON shaped around one site's quirks all slow you down. Upgrades become risky because nobody is sure what depends on the mapping.

The fix is to use canonical structures at your boundaries and keep site-specific logic in declarative configuration and translation layers. That also makes testing easier, because conformance suites, example payloads, and validation rules can run in your build pipeline before anything reaches production.

Security and consent need particular care. An integration that bypasses consent or relies on a shared service account can survive a pilot and fail at scale. Use standards-based authorisation with OAuth 2.0 and OpenID Connect, scopes that reflect clinical roles, and a consent model that travels with the record. Rotating secrets and revoking access then become routine.

Performance is the fourth trap. Polling a clinical system for every patient every hour upsets the supplier's team and your cloud bill. Prefer event-driven feeds, incremental queries with an updated-since parameter, Bulk FHIR for population extracts, and caching with sensible expiry. Respecting a partner's operational limits earns goodwill.

Building a roadmap around interoperability

Start by deciding the source of truth for each concept. Which system owns identity, demographics, clinical narrative, imaging, scheduling, and metrics. Where your product creates new data, such as algorithm outputs or patient-reported outcomes, model it formally. Even if you must deliver a PDF today, keep the structured data next to it so you can promote it later.

Choose standards your customers already use and your engineers can implement well. FHIR is the natural choice for most transactional workflows. Stay close to mature resources and published implementation guides. openEHR can suit long-term clinical modelling in complex pathways, with FHIR as the exchange layer. DICOM remains the standard for imaging. The aim is not to collect acronyms.

Keep your API boring. Publish a versioned OpenAPI specification with examples and clear error contracts. Validate inputs and fail fast with useful feedback, for example when a glucose value arrives in the wrong units. Be practical about optionality, because real records are messy and an over-strict schema rejects real data. Be strict in what you send and tolerant in what you accept, then transform inbound data into your canonical model with explicit, audited mappings.

Treat governance as part of the product. Define how you capture, store, process, and share data, how long you keep it, and how you respond to data subject requests. Run hazard analyses for new features, keep the safety case current, and show provenance in the interface so a clinician can judge how far to trust a value. Partners will not connect to a product that cannot show this.

Write milestones as outcomes. "Finish EHR integration in Q2" tells an investor nothing. "Support FHIR R4 read and write for Patient, Observation, and DocumentReference, pass conformance tests, run at two pilot sites, publish API documentation, and update the clinical safety case" can be checked.

A short list of moves makes the foundation real.

• Define canonical models for your core entities, and map everything inbound and outbound to them.
• Pick two or three priority standards and build internal libraries that make them easy to use.
• Publish a stable, versioned API with examples and a test harness partners can run without you.
• Use standards-based security, least-privilege scopes, and audit logging from the first release.
• Prepare a governance pack with a data protection impact assessment template, processing terms, retention schedules, and clinical safety artefacts.
• Test with messy real data early, before go-live.

Choosing between a quick integration and a lasting one

This is not a binary choice. It is a set of trade-offs.

Time horizon comes first. If you must prove value on one ward in six weeks, a narrow integration that gives clinicians a clean workflow may be right, even if the data arrives as a PDF. The condition is that you avoid painting yourself into a corner. Capture the structured data alongside, keep mappings in configuration, and keep provenance visible. Later you can promote the data to standard resources.

Cost of change comes second. Integrations look cheaper at the start because they use whatever interface is on hand, and every site-specific tweak then adds interest. Interoperability costs more up front, for standards, conformance tooling, and security evidence, and pays back as you add customers. If you sell to many small providers or several regions, it pays back sooner.

Risk comes third. Where data touches diagnosis, prescribing, or urgent care, there is little room for ambiguity. Shared code systems and consistent models reduce semantic risk. They also make failures visible. An integration with no validation can fail silently until a clinician notices something wrong.

The last test is the user. Clinicians and patients do not care which standards you use. They care that the right data is in the right place at the right time.

Use these rules of thumb.

• If the workflow is one site and one vendor, a targeted integration is fine. Keep an internal model based on standards so you can swap the interface later.
• If the product must work across regions or vendors, put interoperability first, even if it means fewer features this quarter.
• If the data informs clinical decisions or automation, encode meaning with recognised terminologies and resource models from day one.
• If a partner demands a specific feed, such as HL7 v2, provide it, and expose a standards-based API next to it.
• If performance or rate limits matter, design for events, bulk paths, and incremental sync.

A first slice to build this quarter

The way to stop the debate stalling progress is to build one small slice end to end. Pick one outcome users care about, such as surfacing abnormal home blood pressure readings in a hospital's inbox with a clear audit trail.

Build it with a standard resource, an Observation. Code each measurement with a recognised code and units. Limit access with scopes that cover only the relevant patient cohort. Publish conformance tests so the hospital's integration team can validate quickly. If the hospital needs a PDF for now, generate one, and keep the structured Observation as the record of truth.

In parallel, build a reference environment partners can use without your engineers on a call, with sample payloads, test users, and endpoints that behave like production. Include negative tests for invalid codes, missing units, and impossible timestamps.

Treat mappings as artefacts in their own right. Record how each site's local codes map to standard terminologies, who approved each mapping, and when it was last reviewed. Keep them in source control and test them automatically. When a site changes its lab catalogue, you will find out in your pipeline, not during a weekend on call.

Design consent and purpose into the data flow. For direct care, consent is often implicit. For research, secondary use, and patient-facing apps, it is explicit. Let consent state travel with the record and be checked at the point of access, and give people a clear view of who accessed what and when.

Finally, remember the people. Run show-and-tells with the clinical and informatics teams who will use the interface. A ward clerk explaining that a small payload change saves ten minutes per patient is requirements discovery you cannot get from a specification.