Exchange · Exchange frameworkHL7 FHIR R4/R5
Synchronous APIMessagingDocumentsClinical data accessSystem integration
Strategic potential · 5/5
A common resource model and interoperability framework that can support several interaction paradigms, not only REST.
UK-wide: FHIR is strategically important across the UK, but implementation must follow the applicable national or programme IG rather than unconstrained base FHIR.
Role, boundaries and companions
Best used for
A common resource model and interoperability framework that can support several interaction paradigms, not only REST.
Boundary
FHIR does not by itself supply a complete business workflow, national semantic policy, identity model or trust framework. Profiles and implementation guides are normally required.
Usually paired with
Jurisdictional core profiles; terminology; SMART/OAuth; IHE profiles where document sharing or identity federation is required.
Exchange · Interaction patternFHIR RESTful API
Synchronous APIClinical data accessCRUD-style exchange
Strategic potential · 5/5
Synchronous resource-oriented access where request/response semantics, search and discrete resource retrieval are appropriate.
UK-wide: Widely relevant but select according to interaction need, not fashion.
Role, boundaries and companions
Best used for
Synchronous resource-oriented access where request/response semantics, search and discrete resource retrieval are appropriate.
Boundary
REST is not automatically the right pattern for every interoperability requirement. It is weak as a substitute for durable asynchronous messaging, workflow coordination or repository-style document federation unless complemented by other mechanisms.
Usually paired with
FHIR profiles; SMART/OAuth; API management; Subscriptions or messaging for event-driven needs.
Documents · Document patternFHIR Documents
DocumentsDischarge summaryPatient summary
Strategic potential · 4/5
When the exchange unit needs document characteristics such as wholeness, attestation context and human-readable narrative while using FHIR artefacts.
UK-wide: Growing opportunity alongside existing CDA and document-sharing estates.
Role, boundaries and companions
Best used for
When the exchange unit needs document characteristics such as wholeness, attestation context and human-readable narrative while using FHIR artefacts.
Boundary
Do not use documents merely to avoid modelling discrete data. Document persistence and workflow expectations still need explicit governance.
Usually paired with
Composition and Bundle profiles; IPS where appropriate; MHD/MHDS or another transport/repository pattern.
Exchange · Interaction patternFHIR Messaging
MessagingCommand/message exchangeAsynchronous integration
Strategic potential · 3/5
When a message event and receiver processing contract are more natural than resource CRUD.
UK-wide: Possible but less common than REST or HL7 v2.
Role, boundaries and companions
Best used for
When a message event and receiver processing contract are more natural than resource CRUD.
Boundary
FHIR messaging is less commonly deployed than FHIR REST or HL7 v2. Operational messaging infrastructure, acknowledgements and retry semantics still need design.
Usually paired with
MessageHeader and Bundles; broker or queue; local event and retry conventions.
Exchange · Event patternFHIR Subscriptions
Event-drivenChange notificationClinical event notification
Strategic potential · 4/5
Notifying consumers that relevant FHIR data has changed, avoiding wasteful polling and enabling event-driven architectures.
UK-wide: Growing relevance as FHIR estates mature.
Role, boundaries and companions
Best used for
Notifying consumers that relevant FHIR data has changed, avoiding wasteful polling and enabling event-driven architectures.
Boundary
Subscription support and semantics vary by FHIR version and implementation. A notification is not a complete enterprise event model or guaranteed business process.
Usually paired with
FHIR profiles; broker/webhook channel design; security; idempotency; retry and delivery policy.
Exchange · Message standardHL7 Version 2.x
MessagingADTOrders
Strategic potential · 3/5
High-volume event-driven integration inside hospitals and established provider ecosystems, especially ADT, order and result feeds.
UK-wide: Very widely deployed in provider integration. Current use exceeds forward strategic potential because installed-base value remains high.
Role, boundaries and companions
Best used for
High-volume event-driven integration inside hospitals and established provider ecosystems, especially ADT, order and result feeds.
Boundary
Local variants, optionality and interface-by-interface agreements can erode semantic interoperability. Modernisation should be risk-based rather than assuming immediate replacement.
Usually paired with
Terminology; conformance profiles; interface engine; FHIR façade or mediation where justified.
Documents · Document standardHL7 Clinical Document Architecture R2
DocumentsClinical summariesDischarge documents
Strategic potential · 3/5
Persistent, human-readable, attestable clinical documents where document semantics matter.
UK-wide: Used in established document exchanges and remains relevant during transition.
Role, boundaries and companions
Best used for
Persistent, human-readable, attestable clinical documents where document semantics matter.
Boundary
CDA can be verbose and implementation-specific. It is not a general-purpose replacement for APIs or event messaging.
Usually paired with
Terminology; IHE XDS/XCA; C-CDA or national templates where applicable; migration path to FHIR Documents where justified.
Exchange · Message standardHL7 Version 3 Messaging
MessagingEstablished national servicesLegacy structured messaging
Strategic potential · 2/5
Maintaining interoperability where a functioning V3-based national or enterprise service already exists.
UK-wide: Still present in important legacy/national patterns but not a preferred default for new builds.
Role, boundaries and companions
Best used for
Maintaining interoperability where a functioning V3-based national or enterprise service already exists.
Boundary
Complexity and declining strategic momentum make V3 messaging a poor default for new designs. Preserve only where replacement cost and risk do not justify change.
Usually paired with
CDA where documents are the real unit; FHIR for new API-centric services; explicit coexistence plan.
Documents · Document-sharing profileIHE XDS.b
Store/query/retrieveDocumentsCross-enterprise record sharingRegional HIE
Strategic potential · 3/5
Federated registration, discovery and retrieval of clinical documents across an affinity domain.
UK-wide: Established in some regional/shared record architectures.
Role, boundaries and companions
Best used for
Federated registration, discovery and retrieval of clinical documents across an affinity domain.
Boundary
XDS is not an order-management workflow and does not itself define the security or business policies of an affinity domain. It is also not ideal for dynamic fine-grained resource access.
Usually paired with
ATNA; XUA; PIX/PDQ; XCA for federation; MHD where FHIR-based access is preferred.
Documents · Federation profileIHE XCA
Store/query/retrieveDocumentsCross-community discoveryFederated document access
Strategic potential · 3/5
Federating document-sharing communities where a patient’s records may exist in more than one affinity domain.
UK-wide: Useful where multiple document-sharing domains must interoperate.
Role, boundaries and companions
Best used for
Federating document-sharing communities where a patient’s records may exist in more than one affinity domain.
Boundary
Adds federation complexity and depends on identity, trust, policy and document metadata alignment across communities.
Usually paired with
XDS.b; PIX/PDQ or XCPD where applicable; ATNA/XUA; governance agreements.
Documents · FHIR document access profileIHE MHD
Synchronous APIStore/query/retrieveDocumentsFHIR document accessMobile/portal access
Strategic potential · 4/5
A standardised FHIR interface for document sharing, including simpler access to XDS-style document infrastructures.
UK-wide: Strong candidate for modernising access to existing document-sharing services.
Role, boundaries and companions
Best used for
A standardised FHIR interface for document sharing, including simpler access to XDS-style document infrastructures.
Boundary
MHD deliberately does not reproduce every capability of XDS. It should not be assumed to make document-sharing governance or federation disappear.
Usually paired with
XDS or MHDS; DocumentReference; Binary; SMART/OAuth or IUA; terminology and document-content profile.
Documents · FHIR document-sharing architectureIHE MHDS
Store/query/retrieveDocumentsSynchronous APIFHIR-native document HIERegional document sharing
Strategic potential · 4/5
Building a document-sharing exchange using FHIR-profiled IHE components rather than classic XDS transactions.
UK-wide: Emerging option rather than established default.
Role, boundaries and companions
Best used for
Building a document-sharing exchange using FHIR-profiled IHE components rather than classic XDS transactions.
Boundary
Trial-implementation status and deployment maturity should be assessed before treating it as a universal replacement for mature XDS estates.
Usually paired with
MHD; PMIR/PIXm/PDQm where appropriate; IUA/ATNA; document content profiles.
Imaging · Imaging standardDICOM
ImagingDiagnostic imagingPACS/VNA
Strategic potential · 5/5
The foundational standard for medical imaging objects, metadata and imaging workflows.
UK-wide: Foundational imaging interoperability.
Role, boundaries and companions
Best used for
The foundational standard for medical imaging objects, metadata and imaging workflows.
Boundary
DICOM interoperability still depends on profiles, workflow conventions, identifiers, modality configuration and conformance statements.
Usually paired with
DICOMweb for web APIs; IHE Radiology profiles; XDS-I for cross-enterprise image sharing.
Imaging · Web API familyDICOMweb
Synchronous APIImagingWeb image accessCloud imaging
Strategic potential · 5/5
Web-native query, retrieve and store of DICOM objects and metadata.
UK-wide: Increasingly relevant to cloud and web imaging.
Role, boundaries and companions
Best used for
Web-native query, retrieve and store of DICOM objects and metadata.
Boundary
It does not replace the need for imaging workflow, lifecycle, identity or diagnostic display requirements.
Usually paired with
DICOM; OAuth/OIDC; FHIR ImagingStudy where clinical API context is useful; XDS-I/MHD for cross-enterprise sharing patterns.
Imaging · Imaging-sharing profileIHE XDS-I.b
Store/query/retrieveImagingDocumentsCross-enterprise imagingRegional imaging exchange
Strategic potential · 3/5
Cross-enterprise discovery and retrieval of diagnostic imaging evidence using XDS-style infrastructure.
UK-wide: Relevant in regional imaging/sharing architectures.
Role, boundaries and companions
Best used for
Cross-enterprise discovery and retrieval of diagnostic imaging evidence using XDS-style infrastructure.
Boundary
Best suited to document/imaging federation. It is not a complete radiology workflow standard and may coexist with DICOMweb for modern access.
Usually paired with
DICOM; XDS.b; XCA; ATNA/XUA; DICOMweb where appropriate.
Documents · International summary specificationInternational Patient Summary (IPS)
DocumentsSynchronous APIPatient summaryCross-border care
Strategic potential · 4/5
A minimal, clinically useful patient summary designed for international and cross-border reuse.
UK-wide: Potentially useful for cross-border and portable summaries.
Role, boundaries and companions
Best used for
A minimal, clinically useful patient summary designed for international and cross-border reuse.
Boundary
IPS is intentionally a summary, not a full longitudinal record. National adaptations must preserve conformance if international interoperability is required.
Usually paired with
FHIR IPS or CDA IPS; SNOMED CT/LOINC/UCUM; national core profiles; document-sharing transport.
Semantics · Clinical terminologySNOMED CT
TerminologyProblemsFindings
Strategic potential · 5/5
Rich, computable representation of clinical meaning and consistent coding across systems.
UK-wide: Core clinical terminology in UK health systems.
Role, boundaries and companions
Best used for
Rich, computable representation of clinical meaning and consistent coding across systems.
Boundary
A terminology does not solve structural or workflow interoperability by itself. National editions, reference sets, binding rules and terminology-service operations matter.
Usually paired with
FHIR terminology services; national edition; LOINC/UCUM where those are the appropriate semantic systems.
Semantics · Observation terminologyLOINC
TerminologyLaboratory testsClinical observations
Strategic potential · 4/5
Universal identifiers for observations, measurements and laboratory/clinical tests, especially when exchanging results across organisational boundaries.
UK-wide: Relevant where national/local policy adopts LOINC alongside existing coding systems.
Role, boundaries and companions
Best used for
Universal identifiers for observations, measurements and laboratory/clinical tests, especially when exchanging results across organisational boundaries.
Boundary
LOINC commonly identifies the observation or test, while result meaning may require SNOMED CT and quantitative values require UCUM. Local mapping quality remains critical.
Usually paired with
SNOMED CT; UCUM; FHIR Observation/DiagnosticReport; HL7 v2 ORU.
Semantics · Units standardUCUM
TerminologyUnits of measureLaboratory results
Strategic potential · 5/5
Machine-processable, unambiguous representation of units in quantitative clinical data.
UK-wide: High semantic value but implementation consistency varies.
Role, boundaries and companions
Best used for
Machine-processable, unambiguous representation of units in quantitative clinical data.
Boundary
UCUM does not define what was measured, only the unit. It must be paired with a correctly defined observation and quantity semantics.
Usually paired with
LOINC; FHIR Quantity; laboratory and observation profiles.
Semantics · Terminology service patternFHIR Terminology Service API
TerminologySynchronous APIValidate codeExpand value set
Strategic potential · 5/5
Runtime terminology validation, value-set expansion, concept lookup and mappings using standard FHIR operations.
UK-wide: Strong strategic fit with national terminology services.
Role, boundaries and companions
Best used for
Runtime terminology validation, value-set expansion, concept lookup and mappings using standard FHIR operations.
Boundary
A service API does not substitute for terminology governance, release management, licensing or authoritative value-set ownership.
Usually paired with
SNOMED CT; LOINC; local/national code systems; ConceptMap; ValueSet; CodeSystem.
Security · FHIR application trust patternSMART App Launch
Synchronous APIPatient appsClinician apps
Strategic potential · 4/5
OAuth-based authorisation, authentication patterns and launch context for applications integrating with FHIR data systems.
UK-wide: Growing relevance for app ecosystems.
Role, boundaries and companions
Best used for
OAuth-based authorisation, authentication patterns and launch context for applications integrating with FHIR data systems.
Boundary
SMART does not define enterprise identity proofing, consent policy or all API security controls. Scope design and issuer trust remain architectural decisions.
Usually paired with
OAuth 2.0/OIDC; FHIR; national identity and consent policy; API gateway.
Security · Security protocolsOAuth 2.0 / OpenID Connect
Synchronous APIEvent-drivenAPI authorisationUser authentication
Strategic potential · 5/5
General-purpose delegated authorisation and identity-layer patterns underpinning modern API security.
UK-wide: Standard foundation for modern APIs.
Role, boundaries and companions
Best used for
General-purpose delegated authorisation and identity-layer patterns underpinning modern API security.
Boundary
Healthcare-specific policy is not supplied by OAuth or OIDC. Token content, assurance level, consent, scopes, delegation and audit must be designed.
Usually paired with
SMART App Launch; IHE IUA; TLS; national IAM; API gateway.
Knowledge & workflow · CDS integration specificationCDS Hooks
CDSSynchronous APIClinical decision supportWorkflow-triggered advice
Strategic potential · 4/5
Invoking remote decision support at defined points in clinical workflow and returning actionable cards or suggestions.
UK-wide: Promising for standards-based CDS integration but not yet universal.
Role, boundaries and companions
Best used for
Invoking remote decision support at defined points in clinical workflow and returning actionable cards or suggestions.
Boundary
CDS Hooks is not a knowledge-representation standard and should not be used where asynchronous workflow or batch analytics is the real requirement.
Usually paired with
FHIR; CQL where computable logic is needed; SMART for app launch; terminology; clinical-safety governance.
Knowledge & workflow · Computable knowledge languageClinical Quality Language (CQL)
CDSBulkDecision logicQuality measures
Strategic potential · 3/5
Representing shareable computable clinical logic used in quality measurement and decision support.
UK-wide: Niche but useful for computable knowledge.
Role, boundaries and companions
Best used for
Representing shareable computable clinical logic used in quality measurement and decision support.
Boundary
CQL does not itself solve workflow integration, data access or terminology governance. Data requirements and execution context must be explicit.
Usually paired with
FHIR Library/PlanDefinition/Measure; CDS Hooks; terminology service.
Identity · FHIR identity profilesIHE PIXm / PDQm
IdentitySynchronous APIPatient identity cross-referencePatient demographics query
Strategic potential · 4/5
FHIR-based patient identifier cross-reference and demographic query in multi-system environments.
UK-wide: Useful where IHE/FHIR identity federation is adopted.
Role, boundaries and companions
Best used for
FHIR-based patient identifier cross-reference and demographic query in multi-system environments.
Boundary
Identity matching quality, authoritative sources, merge/unmerge handling and legal identity policy are outside the profile and remain critical.
Usually paired with
Master/enterprise patient index; MHD/MHDS; IUA/ATNA; national identity services.
Security · FHIR API security profileIHE Internet User Authorization (IUA)
Synchronous APICross-enterprise FHIR API trustToken-based authorisation
Strategic potential · 3/5
Profiling OAuth-style authorisation for protected health-information APIs in cross-enterprise settings.
UK-wide: Selective use.
Role, boundaries and companions
Best used for
Profiling OAuth-style authorisation for protected health-information APIs in cross-enterprise settings.
Boundary
IUA is a profile, not a substitute for the underlying organisational trust framework or entitlement model.
Usually paired with
OAuth/OIDC; SMART where application launch is involved; ATNA; identity federation.
Security · Audit and node security profileIHE ATNA
MessagingSynchronous APIStore/query/retrieveAudit trailTrusted-node communication
Strategic potential · 3/5
Standardised audit-event recording and node-authentication expectations in IHE environments.
UK-wide: Relevant in IHE deployments.
Role, boundaries and companions
Best used for
Standardised audit-event recording and node-authentication expectations in IHE environments.
Boundary
ATNA is not a complete zero-trust or enterprise cyber-security architecture. Modern deployments may need additional controls and cloud-native logging patterns.
Usually paired with
XDS/MHD; XUA/IUA; SIEM; TLS; organisational security policy.
Exchange · Bulk export patternFHIR Bulk Data Access
BulkPopulation exportAnalytics feed
Strategic potential · 4/5
Asynchronous export of large FHIR datasets where interactive resource-by-resource APIs would be inefficient.
UK-wide: Growing relevance for population and secondary-use data flows.
Role, boundaries and companions
Best used for
Asynchronous export of large FHIR datasets where interactive resource-by-resource APIs would be inefficient.
Boundary
Bulk export is not a full analytics architecture. Data quality, semantics, incremental refresh, governance and downstream modelling still need design.
Usually paired with
FHIR profiles; NDJSON; terminology; secure object transfer; analytics/data-platform architecture.
Knowledge & workflow · Workflow coordination patternFHIR Task / workflow resources
Synchronous APIEvent-drivenReferral trackingWork request
Strategic potential · 4/5
Representing actionable work and status when interoperability requires more than exchanging clinical payloads.
UK-wide: Useful for standardised workflow APIs, especially referral/order tracking.
Role, boundaries and companions
Best used for
Representing actionable work and status when interoperability requires more than exchanging clinical payloads.
Boundary
FHIR Task is not a complete business-process engine. Long-running orchestration, exceptions, compensation and human workflow may require BPMN/workflow platforms.
Usually paired with
ServiceRequest; Communication; Subscription; BPMN or workflow engine; national referral IG.
Jurisdictional · National FHIR foundationHL7 FHIR UK Core
Synchronous APIDocumentsEvent-drivenUK FHIR implementationCross-border UK exchange
Strategic potential · 5/5
Common UK FHIR profiles intended to provide reusable foundations for implementation guides and consistent information exchange.
UK-wide: Strategically important but implementation status must be checked carefully.
Role, boundaries and companions
Best used for
Common UK FHIR profiles intended to provide reusable foundations for implementation guides and consistent information exchange.
Boundary
The NHS England catalogue describes UK Core as active but still work in progress and not for implementation. Programme-specific IG status must therefore be checked before procurement or conformance claims.
Usually paired with
FHIR R4; national/service IGs; SNOMED CT UK; dm+d where medicines are involved.
Jurisdictional · US interoperability foundationUS Core + USCDI
Synchronous APIDocumentsBulkUS certified health ITPatient access
Strategic potential · 1/5
Defines a common US data set and FHIR profiles that underpin certified API interoperability and many US implementation guides.
UK-wide: US-specific.
Role, boundaries and companions
Best used for
Defines a common US data set and FHIR profiles that underpin certified API interoperability and many US implementation guides.
Boundary
USCDI and US Core are US-realm specifications. The exact version required for certification or procurement must be checked against the applicable rule and SVAP status.
Usually paired with
FHIR R4; SMART App Launch; terminology; programme-specific US IGs.
Jurisdictional · Australian interoperability foundationAU Core + AUCDI
Synchronous APIDocumentsAustralian FHIR exchangeMy Health Record
Strategic potential · 1/5
Defines Australian core FHIR profiles and data-content expectations for consistent national exchange.
UK-wide: Australia-specific.
Role, boundaries and companions
Best used for
Defines Australian core FHIR profiles and data-content expectations for consistent national exchange.
Boundary
Versions are evolving and may be referenced by specific national implementation guides. Implementers should use the version mandated by the relevant service.
Usually paired with
FHIR; SNOMED CT-AU; AMT; national identifiers; My Health Record conformance profiles.
Jurisdictional · New Zealand interoperability foundationNZ Base + NZCDI
Synchronous APIDocumentsMessagingNew Zealand FHIR exchangeNational patient summary
Strategic potential · 1/5
Provides reusable New Zealand FHIR artefacts and a national core data set for interoperable exchange.
UK-wide: New Zealand-specific.
Role, boundaries and companions
Best used for
Provides reusable New Zealand FHIR artefacts and a national core data set for interoperable exchange.
Boundary
NZCDI and NZ Base are living artefacts. Specific APIs and implementation guides may impose tighter constraints.
Usually paired with
FHIR; SNOMED CT NZ; NZ Patient Summary; HISO API standards; NZ terminology service.
Jurisdictional · Pan-Canadian FHIR foundationCA Core+
Synchronous APIDocumentsPan-Canadian FHIR exchangeProvincial/territorial alignment
Strategic potential · 1/5
A foundational set of pan-Canadian FHIR profiles, extensions and terminology artefacts intended to harmonise jurisdictional specifications.
UK-wide: Canada-specific.
Role, boundaries and companions
Best used for
A foundational set of pan-Canadian FHIR profiles, extensions and terminology artefacts intended to harmonise jurisdictional specifications.
Boundary
Canada is federated and provinces/territories retain important implementation differences. CA Core+ maturity and local adoption must be checked for each use case.
Usually paired with
FHIR; Infoway terminology services; pan-Canadian patient summary and other roadmap building blocks.
Jurisdictional · Regulatory interoperability frameworkEHDS / European EHR Exchange Format
DocumentsSynchronous APICross-border EU carePatient summary
Strategic potential · 2/5
Harmonising priority categories of electronic health data and EHR interoperability across the EU under the EHDS Regulation.
UK-wide: Relevant mainly to UK-EU cross-border considerations and supplier strategy.
Role, boundaries and companions
Best used for
Harmonising priority categories of electronic health data and EHR interoperability across the EU under the EHDS Regulation.
Boundary
This is a regulatory framework and emerging set of implementing specifications, not a single mature wire protocol. Detailed implementing acts are still needed before assuming technical conformance requirements.
Usually paired with
National profiles; EEHRxF datasets and coding systems; FHIR/CDA/IHE components as specified by implementing acts; testing environments.
No catalogue entries match those filters.