Agile Health Informatics Ltd · Professional resource

Healthcare Interoperability Navigator

A practical, problem-led guide to choosing interoperability patterns, standards and profiles according to the interaction required, the information being exchanged, the semantic obligation and the jurisdiction.

35 specifications & patternsExchange, documents, imaging, semantics, trust, identity and workflow
10 jurisdiction viewsUK nations, EU, US, Canada, Australia and New Zealand
14 problem-led scenariosFrom legacy feeds and APIs to document federation and CDS
Evidence dated 8 Sep 2026Authoritative standards bodies and public-sector sources
Interoperability anatomy

Interoperability is a stack of decisions, not a protocol choice

A technically valid API can still fail to interoperate if the participating organisations disagree about workflow, identifiers, semantics, trust or conformance. The navigator therefore separates seven decisions that are often collapsed into the word “interface”.

1

Purpose

What clinical or operational task crosses the boundary?

2

Interaction

API, event, message, document, query/retrieve, bulk or workflow?

3

Representation

Resources, messages, documents, images or computable knowledge?

4

Semantics

Which terminology, units, value sets and information constraints preserve meaning?

5

Identity

How are patients, people, organisations, systems and assigning authorities resolved?

6

Trust

Authentication, authorisation, consent, audit and cross-organisational policy.

7

Assurance

Versioning, conformance testing, observability, safety and operational fitness.

Design principle: FHIR is an interoperability framework, not a mandate to use REST for every interaction. FHIR itself supports REST, documents, messaging, services, databases and subscriptions. Choose the interaction semantics first, then the FHIR capability if it fits.
Decision aid

Build an interoperability stack around the problem

Choose the job to be done and the jurisdiction. The output deliberately recommends a stack of complementary components rather than pretending that a single standard supplies process, transport, semantics, trust and assurance.

Recommended pattern · Synchronous API

Real-time clinical data access

A consumer needs discrete clinical data from another system on demand.

Interaction
FHIR RESTful API

Use query/search/transaction semantics only where synchronous request/response fits the business interaction.

Information
FHIR profiles

Constrain resources through an implementation guide rather than exchanging unconstrained base resources.

Semantics
Terminology bindings

Bind each coded or quantitative element to the correct semantic system.

Trust
OAuth/OIDC + SMART/IUA

Choose the healthcare profile according to app-launch and cross-enterprise trust needs.

Assurance
Capability + conformance testing

Publish CapabilityStatements, version policy, test artefacts and operational SLAs.

Jurisdiction
UK-wide profile or regulatory layer

Apply the jurisdictional foundation and then the service-specific implementation guide or procurement requirement. Do not infer conformance from base-standard support alone.

Important boundary: a recommended stack is an architecture starting point, not evidence of conformance. Procurement and assurance should identify the exact implementation guide, profile version, terminology release, test artefacts, security policy and operational obligations required by the receiving ecosystem.
Use-case patterns

Common problems should lead to different interoperability choices

These patterns make visible where apparently similar integration requirements actually demand different interaction semantics.

Synchronous API

Real-time clinical data access

A consumer needs discrete clinical data from another system on demand.

Messaging

Integrate an established hospital system

An existing EPR, PAS, LIS or departmental system emits operational events and results.

Event-driven

Notify subscribers about clinical change

Consumers need to react when data or clinical state changes.

Documents

Exchange a persistent clinical document

The communication must remain a coherent, human-readable clinical document with context and persistence.

Store/query/retrieve

Build or federate a cross-enterprise document record

Multiple organisations need to register, discover and retrieve persistent clinical documents.

Imaging

Share diagnostic imaging

Images and imaging metadata must be exchanged or retrieved across systems or organisations.

Synchronous API

Connect a patient or clinician application

A third-party app needs authorised access to FHIR data and possibly launch context from an EHR.

CDS

Invoke clinical decision support in workflow

An EHR or clinical system needs standards-based decision support at a defined workflow point.

Terminology

Provide shared terminology services

Systems need consistent code validation, value sets, terminology lookup or mapping.

Identity

Resolve patient identity across organisations

Systems need to locate or cross-reference the same person across identifier domains.

Bulk

Export data for population analytics

Large volumes of patient-level data need to move from operational systems into analytics or research processing.

Documents

Exchange a patient summary across borders

A concise clinical summary must remain understandable across organisational and national boundaries.

Workflow

Coordinate a referral or work request

Interoperability must support an actionable request, status and hand-offs rather than only transfer clinical data.

Messaging or API

Exchange laboratory orders and results

Ordering and reporting must interoperate across clinical and laboratory systems.

Jurisdiction context

The same base standard does not mean the same implementation

National and regional programmes constrain international standards differently. The navigator therefore treats jurisdiction as part of the interoperability contract rather than a label added after technical design.

UK

UK nations

FHIR UK Core is intended as a reusable UK foundation, but NHS England currently describes it as active work in progress and not for implementation. Service-specific and nation-specific implementation guidance therefore remains decisive.

WEB-06
European Union

EHDS transition

The EHDS Regulation is in force, but the detailed interoperability regime is still being operationalised. Key implementing acts are due by March 2027, with major primary-use obligations starting in 2029 and 2031.

WEB-08 WEB-09
United States

USCDI and certified APIs

USCDI v7 was published in July 2026. US Core, SMART and FHIR APIs operate in a mature regulatory and certification ecosystem, but implementers still need to match the exact required or SVAP-approved versions.

WEB-10 WEB-11
Canada

Pan-Canadian convergence

Infoway’s interoperability roadmap is driving common building blocks, including CA Core+, while provincial and territorial implementation differences remain material.

WEB-12 WEB-13
Australia

AU Core and AUCDI

Australia’s 2026 My Health Record interoperability requirements now identify AUCDI for FHIR data content in scope and require AU Core for FHIR connections, with versions set by the relevant implementation guide.

WEB-15
New Zealand

FHIR-first national direction

Health NZ states that FHIR must be used for new health-data exchange solutions, supported by NZ Base, NZCDI, the NZ Patient Summary and national API standards.

WEB-16 WEB-17
Method and evidence

How to read the navigator

The resource is evidence-informed but intentionally decision-oriented. It separates sourced statements about formal standards and policy from professional assessment of adoption, architectural fit and future strategic value.

FactSource-grounded status

Formal specification scope, published versions, policy statements and regulatory timelines are based on authoritative standards bodies and public-sector sources listed below.

AnalysisUse and potential

Current use estimates how established the component is in the selected jurisdiction. Strategic potential estimates its likely forward role for new or modernised interoperability. A mature legacy technology can therefore score higher for current use than future potential.

Selection discipline

Start with the business interaction and failure modes. Then select representation, semantics, identity and trust. Only after that should a protocol, profile or product implementation be chosen.

Version discipline

Do not write “supports FHIR”, “supports XDS” or “uses SNOMED” as a complete procurement requirement. State the version, implementation guide/profile, required capabilities, terminology edition/release, test evidence and change-control expectations.

Source register

Authoritative sources used

Priority is given to standards bodies, national digital-health authorities and the European Commission. The register is intended to make the resource inspectable and maintainable as standards evolve.