Agile Health Informatics Ltd · Professional resource
Healthcare Standards Navigator
A practical, interactive guide for professionals who need to choose standards according to the problem being solved, the information lifecycle, the jurisdiction and the assurance context rather than simply starting with a familiar specification.
104 standards & frameworksCurated for practical relevance
5 domainsProcess, data, assurance, analytics and professional
UK, Europe, US, Canada, Australia & New ZealandJurisdiction and mandate kept distinct
Standards stacksComplementary artefacts selected by role
Orientation
Start with the problem, not the standard
Healthcare standards are difficult to navigate because terminology, information content, exchange, persistence, analytics, assurance and professional competence are often discussed as though they were alternatives. They are not. A useful architecture normally combines several standards, each with a distinct role.
Agile Health Informatics resource, not an endorsement or conformance statement. Current-use and future relevance scores are evidence-informed editorial estimates as at 9 September 2026. They support professional judgement and do not replace legislation, regulation, national standards notices, contractual requirements, procurement rules or local assurance.
Selection principleUse a stackChoose complementary artefacts by function and lifecycle role.
Core questionWhat problem?Define the use case and decision boundary before choosing technology.
Important distinctionMandate ≠ relevanceA useful UK-wide standard may have different national status.
Assurance principleTest evidenceConformance alone does not prove interoperability, safety or fitness.
Taxonomy
First identify what kind of standard you need
A standards catalogue becomes more useful when each artefact is understood by the job it performs.
Exchange / integration specification Defines how information is technically represented, constrained and transported. Explore related catalogue entries →
Access-control / identity standard Establishes identity, authentication, authorization, policy or enforcement patterns. These are related but distinct concerns. Explore related catalogue entries →
Future relevance scale 1 declining or highly specialised · 2 limited future role · 3 continuing but not expanding materially · 4 strong continuing or growing relevance · 5 strategically important and likely to expand. How scoring works →
PRSB information-record standards UK-wide content standards defining what health and care information should be recorded or shared for particular use cases. Explore the PRSB suite →
Health-specific versus cross-sector:
the catalogue now labels each entry by scope origin. Cross-sector standards are included only when they provide a distinct foundational capability that is directly depended on by health-specific specifications, recur across multiple healthcare architectures, or provide a governance/control layer that health-specific standards do not replace. This is why OAuth, OpenID Connect, ISO/IEC 27001/27002, BPMN and similar foundations are present while the navigator does not attempt to list every RFC, generic cyber framework or IT management standard used somewhere in healthcare.
National cyber baseline schemes:
Cyber Essentials and Cyber Essentials Plus are deliberately omitted from the international catalogue. They can still be relevant to UK procurement, but listing one country's generic baseline certification without equivalent national schemes would distort the expanded international scope. Local procurement overlays should still be checked separately.
UK information-record standards
PRSB standards apply as a UK-wide reference set, but national adoption is not identical
The Professional Record Standards Body describes itself as UK-wide and develops standards with health and care professionals, suppliers and people across the four nations. The navigator therefore marks the published PRSB information-record standards as relevant to England, Scotland, Wales and Northern Ireland. Relevance is not the same as mandate: each nation retains its own policy, commissioning, terminology, technical implementation and assurance arrangements.
Stewardship matters: from 1 January 2026, a number of established PRSB standards transferred to NHS England ownership and management. They remain important PRSB-originated content standards, but an NHS England ownership statement does not create an equivalent statutory or procurement mandate in Scotland, Wales or Northern Ireland. Always check the current PRSB catalogue and the responsible national standards authority.
EnglandUK-wide relevance, with the strongest direct NHS England commissioning, standards-directory and ownership links for many established PRSB standards.
ScotlandUK-wide relevance as information-record content. Adoption should be reconciled with NHS Scotland, Public Health Scotland and Scottish national information and interoperability requirements.
WalesUK-wide relevance as information-record content. Adoption should be reconciled with NHS Wales, Digital Health and Care Wales and Welsh national data and interoperability requirements.
Northern IrelandUK-wide relevance as information-record content. Adoption should be reconciled with Department of Health and HSC Northern Ireland policy, architecture and implementation requirements.
Portfolio basis: current published PRSB standards indexed in this navigator as at 9 September 2026. The live PRSB standards catalogue remains the authority for additions, withdrawals, stewardship changes and release status.
Interactive catalogue
Find standards by problem, domain or jurisdiction
Search by name, role or problem, then filter by domain, jurisdiction relevance and landscape position. The catalogue is embedded locally so it remains usable offline.
Future relevance is not an adoption ceiling: a standard can have higher current use than future relevance. Future relevance estimates its expected continuing or growing strategic importance over roughly the next five years.
Jurisdiction-sensitive use score: select a jurisdiction to see the current-use estimate recalculated for that context. The score is an editorial assessment of practical adoption and policy relevance, not a measured market-share statistic.
Process & computable knowledgeFormal modelling standardScaleCross-sector foundation
BPMN 2.0.2
OMG · 2.0.2 formal
Current use (baseline) 2/5
Future relevance 4/5
Modelling predictable processes, roles, events, hand-offs and orchestration.
What it does not solve: Does not define clinical meaning, data content or clinical knowledge.
Usually pair with: DMN for decisions; FHIR or other exchange standards for information; clinical safety where execution affects care.
Mandate / applicability: Voluntary unless required by an organisation or contract
Use cases:Care pathway modellingWorkflow orchestration
Process & computable knowledgeContinuity-of-care system of conceptsWatchHealth-specific
ISO 13940:2026 (Contsys)
ISO/TC 215 · Edition 2, August 2026
Current use (baseline) 1/5
Future relevance 4/5
A shared system of concepts for continuity of care across clinical and social care, supporting semantic interoperability, information models and care-process descriptions.
What it does not solve: Contsys defines concepts and relationships for continuity of care. It does not prescribe a specific EHR architecture, database schema, message format, workflow implementation or clinical terminology.
Usually pair with: Information models, terminology, process models and implementation specifications.
Mandate / applicability: Voluntary unless adopted by policy, procurement or local architecture
Use cases:Care pathway modellingShared care recordsSemantic interoperabilityEHR architecture and functional requirementsEHR communication and information modelling
What it does not solve: Early in routine UK deployment. It cannot compensate for poor source semantics, weak evidence provenance or absent knowledge governance.
Usually pair with: FHIR, CQL, terminology, provenance, clinical safety and a governed knowledge lifecycle.
Mandate / applicability: Voluntary; applicability depends on programme and product
Use cases:Clinical decision supportComputable guidelinesCare pathway modelling
Process & computable knowledgeWorkflow-triggered clinical decision support API standardWatchHealth-specific
HL7 CDS Hooks 2.0
HL7 International · 2.0 current published release
Current use (baseline) 2/5
Future relevance 4/5
Invoking external clinical decision support services at defined points in a clinician or system workflow and returning context-sensitive guidance, suggestions, links or SMART app launches.
What it does not solve: CDS Hooks is an invocation and interaction pattern, not a clinical knowledge representation, rule language, terminology, workflow model or evidence standard. Conformance does not demonstrate clinical validity, usability, safety, data quality or appropriate alerting behaviour.
Usually pair with: FHIR for clinical data access, SMART App Launch where additional interaction is required, terminology and value-set governance, CQL or other computable knowledge where appropriate, provenance, clinical-safety assurance and local workflow governance.
Mandate / applicability: Voluntary unless adopted by a national implementation guide, programme, product or procurement. No general UK-wide or EU-wide mandate identified.
Use cases:Clinical decision supportComputable guidelinesClinical API interoperabilityAI governance
Data & interoperabilityInternational health data exchange standardFoundationHealth-specific
HL7 FHIR R4 (base specification)
HL7 International · R4 Technical Correction 4.0.1
Current use (baseline) 4/5
Future relevance 5/5
The base HL7 standard for structured healthcare data exchange used by many national and programme-specific implementation guides.
What it does not solve: FHIR R4 is the base specification, not a national core profile, semantic model, workflow agreement or assurance regime. HL7 R5 supersedes R4 as the current base release, but major deployed national profile ecosystems continue to depend on R4.
Usually pair with: The applicable national or programme implementation guide, terminology, identity, provenance, conformance testing and workflow governance.
Mandate / applicability: Voluntary as a base standard unless adopted by a jurisdiction, programme, procurement or implementation guide. Required versions must be checked locally.
Use cases:Clinical API interoperabilityShared care recordsMedicines interoperabilityCross-border summaryImaging interoperabilityPathology interoperabilityClinical messaging and integrationStructured data capture
Data & interoperabilityUK FHIR profile foundation and governance standardScaleJurisdiction-specific health standard / rule
UK Core FHIR R4
HL7 UK / NHS England · R4-based; DAPB4020 governance active
Current use (baseline) 3/5
Future relevance 4/5
A reusable UK foundation for constraining FHIR R4 profiles, extensions, value sets, code systems and concept maps for UK health and care interoperability.
What it does not solve: UK Core is not the FHIR base specification and is not automatically the mandated implementation profile for every UK nation, programme or use case. Service-specific and nation-specific guidance remains decisive.
Usually pair with: HL7 FHIR R4, SNOMED CT, dm+d, national or service implementation guides, identity, provenance and conformance testing.
Mandate / applicability: In England, DAPB4020 governs development and publication of UK Core for organisations in scope. Elsewhere in the UK, applicability and required versions depend on the relevant national or programme guidance.
Use cases:Clinical API interoperabilityShared care recordsMedicines interoperabilityCross-border summaryImaging interoperabilityPathology interoperabilityNational core data requirements
Data & interoperabilityInternational patient-summary content standardScaleHealth-specific
ISO 27269:2025 International Patient Summary
ISO/TC 215 · Edition 2, September 2025
Current use (baseline) 2/5
Future relevance 5/5
Defines the core data set and abstract content model for a concise international patient summary supporting continuity and coordination of care.
What it does not solve: It is not a technical implementation guide and does not define workflow, coding schemes, lower technical layers or the act of generating the summary.
Usually pair with: HL7 International Patient Summary, HL7 FHIR R4 or another implementation representation, terminology, provenance and national profile requirements.
Mandate / applicability: Voluntary unless adopted by legislation, national policy, procurement or an implementation programme.
Use cases:Cross-border summaryShared care recordsNational core data requirementsSemantic interoperability
Data & interoperabilityClinical terminologyFoundationJurisdiction-specific health standard / rule
SNOMED CT UK Edition
SNOMED International / UK release centres · Continuously maintained UK Edition
Current use (baseline) 5/5
Future relevance 5/5
Machine-processable clinical meaning for detailed point-of-care recording, retrieval and decision support.
What it does not solve: Not a message format, information model or statistical classification.
Usually pair with: Terminology services, value-set governance, information models and national implementation rules.
Mandate / applicability: England: mandatory National Information Standard for capturing clinical terms; devolved nations maintain their own programmes and requirements
Use cases:Semantic interoperabilityShared care recordsClinical API interoperabilityMedicines interoperabilityPopulation analyticsClinical decision support
Data & interoperabilityClinical observation, measurement and document terminologyFoundationHealth-specific
LOINC
Regenstrief Institute · 2.83, August 2026
Current use (baseline) 3/5
Future relevance 5/5
Universal identifiers and structured names for laboratory tests, clinical observations, measurements, surveys and documents.
What it does not solve: LOINC identifies observations and related artefacts but does not by itself define units, full clinical context, workflow, transport or the complete meaning of a result.
Usually pair with: UCUM, SNOMED CT where appropriate, HL7 V2 or FHIR, specimen and method semantics, local mapping governance and terminology services.
Mandate / applicability: Voluntary internationally, but required or strongly adopted in a number of national and programme-specific interoperability contexts.
Use cases:Pathology interoperabilitySemantic interoperabilityOrders and resultsClinical reportingClinical API interoperability
Data & interoperabilityIdentification, automatic data capture and traceability standardsScaleCross-sector with healthcare application
GS1 standards in healthcare
GS1 · Current GS1 system and healthcare application standards
Current use (baseline) 4/5
Future relevance 4/5
Global identification and traceability of products, locations and supply-chain events using identifiers such as GTIN and GLN, data carriers and standards such as EPCIS.
What it does not solve: GS1 does not define clinical terminology, the EHR information model, patient identity policy or clinical workflow. Healthcare use requires sector and regulatory context.
Usually pair with: Product and device regulatory identifiers, procurement and inventory systems, point-of-care scanning, clinical records where product use must be recorded, and local traceability governance.
Mandate / applicability: Adoption depends on jurisdiction, product regulation, procurement and sector programmes. Specific healthcare applications can be required even though the GS1 system is cross-sector.
Use cases:Healthcare supply chain and traceabilityMedicines interoperabilityDigital product assurance
Data & interoperabilityClinical information content standardScaleJurisdiction-specific health standard / rule
Core Information Standard v2.01
NHS England; originally developed by PRSB · v2.01
Current use (baseline) 3/5
Future relevance 5/5
Defining a common core of health and care information for sharing across settings and geographies.
What it does not solve: Defines content, not transport, persistence, authorisation policy or user-interface design.
Usually pair with: FHIR/other transport, terminology, local views, information governance, identity and provenance.
Mandate / applicability: PRSB is UK-wide and the Core Information Standard is relevant as a record-content reference across England, Scotland, Wales and Northern Ireland. NHS England specifies it for shared care records in England and took ownership from 1 January 2026. That English stewardship and mandate should not be assumed to apply identically in Scotland, Wales or Northern Ireland, where national policy and implementation requirements must be checked separately.
Use cases:Shared care recordsClinical API interoperabilitySemantic interoperabilityUK health and care record content
Data & interoperabilityMedical and personal health device interoperability standards familySpecialistHealth-specific
ISO/IEEE 11073 health device interoperability series
IEEE 11073 Standards Committee / ISO · Multi-part family; current parts vary by device and architecture
Current use (baseline) 3/5
Future relevance 4/5
Standardised information models, nomenclature and communication approaches for point-of-care, personal health and service-oriented medical device interoperability.
What it does not solve: ISO/IEEE 11073 is a family rather than one protocol. The applicable part must be selected for the device context, and conformance does not replace medical-device safety, cybersecurity, regulatory or clinical-risk obligations.
Usually pair with: ISO 14971, IEC 62304 where software lifecycle applies, cybersecurity controls, FHIR or other enterprise integration, DICOM for imaging and device-specific regulatory requirements.
Mandate / applicability: Voluntary unless required by regulation, recognised consensus standards, procurement or a specific device ecosystem.
Use cases:Medical device interoperabilityDigital product assurance
Data & interoperabilityEHR communication reference model and archetype-based information architectureWatchHealth-specific
ISO 13606 EHR communication series
ISO/TC 215 · Part 1: ISO 13606-1:2019 current; Edition 3 under revision as ISO/DIS 13606-1 in 2026
Current use (baseline) 2/5
Future relevance 4/5
A standards family for communicating part or all of an electronic health record using a stable reference model with archetype-based constraint, supporting exchange between EHR systems, repositories and clinical applications.
What it does not solve: ISO 13606 is not a complete EHR product specification, user-interface standard, workflow model or national implementation guide. Part 1 explicitly does not prescribe the internal architecture or database design of EHR systems.
Usually pair with: Clinical terminology, archetype governance, identity, provenance, access control, national exchange specifications and conformance testing. Contsys and ISO 18308 can provide complementary conceptual and architectural context.
Mandate / applicability: Voluntary unless adopted by national policy, procurement or architecture. ISO 13606-1:2019 remains published but is being revised; ISO/DIS 13606-1 Edition 3 was in enquiry during 2026.
Use cases:EHR communication and information modellingSemantic interoperabilityShared care recordsLongitudinal EHR and data platformClinical API interoperability
Data & interoperabilityRequirements for electronic health record architectureWatchHealth-specific
ISO 18308:2011 EHR architecture requirements
ISO/TC 215 · ISO 18308:2011 remains current; Edition 2 under development as ISO/DIS 18308 in 2026
Current use (baseline) 1/5
Future relevance 4/5
Defines requirements for an EHR architecture intended to ensure that EHR information is clinically valid and reliable, ethically sound, legally appropriate, supportive of good clinical practice and suitable for analysis.
What it does not solve: ISO 18308 is a requirements standard for EHR architecture, not a full EHR system specification, implementation model, exchange format or conformance-tested product profile.
Usually pair with: ISO 13606 for EHR communication, ISO 13940 (Contsys) for continuity-of-care concepts, HL7 EHR-S FM for functional requirements, security/privacy standards and national implementation requirements.
Mandate / applicability: Voluntary unless adopted by policy or procurement. ISO 18308:2011 remains current while ISO/DIS 18308 Edition 2 is under development and intended to replace it.
Use cases:EHR architecture and functional requirementsLongitudinal EHR and data platformSemantic interoperabilityDigital product assurance
A structured catalogue of EHR system functions and conformance criteria that can support requirements definition, procurement, profiling and functional assurance without prescribing a particular technical architecture.
What it does not solve: EHR-S FM specifies functional expectations, not a data model, persistence architecture, API specification, clinical terminology or complete implementation guide. It does not by itself demonstrate that an EHR is safe, usable or interoperable.
Usually pair with: ISO 18308 for architecture requirements, ISO 13606/openEHR/FHIR as appropriate for information and exchange architecture, clinical safety, security/privacy, terminology and local or national EHR requirements.
Mandate / applicability: Voluntary HL7 functional model. It can be profiled or adopted within procurement and assurance but is not a general UK-wide or EU-wide mandate.
Use cases:EHR architecture and functional requirementsDigital product assuranceClinical informatics capabilityLongitudinal EHR and data platform
Data & interoperabilityMachine-readable units code systemWatchHealth-specific
UCUM 2.2
UCUM Organisation / Regenstrief · 2.2, June 2024
Current use (baseline) 2/5
Future relevance 4/5
Unambiguous electronic communication of quantities and units.
What it does not solve: Correct unit codes cannot rescue systems that use unsuitable numeric types, lose precision or transform quantities incorrectly.
Usually pair with: FHIR/observation models, laboratory semantics, validation and data-quality controls.
Mandate / applicability: Voluntary unless required by an implementation specification
Use cases:Pathology interoperabilityClinical API interoperabilitySemantic interoperabilityPopulation analytics
Security, privacy & clinical safetyCertifiable information security management standardFoundationCross-sector foundation
ISO/IEC 27001:2022
ISO/IEC · 2022 Edition 3 + 2024 amendment
Current use (baseline) 4/5
Future relevance 5/5
Organisation-wide information-security management, risk treatment, assurance and continual improvement.
What it does not solve: Certification does not demonstrate clinical safety, interoperability, privacy compliance in every context or product effectiveness.
Usually pair with: NCSC CAF/DSPT where applicable, privacy management, clinical safety, supplier assurance and technical controls.
Mandate / applicability: Voluntary certification; often required or strongly weighted in contracts and assurance
Use cases:Cyber securityDigital product assuranceAI governancePrivacy and information governance
Security, privacy & clinical safetyInformation security control guidanceFoundationCross-sector foundation
ISO/IEC 27002:2022
ISO/IEC JTC 1/SC 27 · Edition 3, February 2022
Current use (baseline) 4/5
Future relevance 5/5
Detailed guidance and good practice for information-security controls supporting risk treatment and an ISO/IEC 27001 information-security management system.
What it does not solve: It is generic rather than health-specific and is not itself a certifiable management-system standard. It does not demonstrate clinical safety, privacy compliance or healthcare effectiveness.
Usually pair with: ISO/IEC 27001, ISO 27799 for health-specific control guidance, ISO/IEC 27701 for privacy management and applicable national healthcare assurance.
Mandate / applicability: Voluntary guidance unless incorporated into contracts, policy or an organisation's information-security management system.
Use cases:Cyber securityPrivacy and information governanceDigital product assurance
Security, privacy & clinical safetyHealth-specific information security control guidanceScaleHealth-specific
ISO 27799:2025
ISO/TC 215 · Edition 3, December 2025
Current use (baseline) 3/5
Future relevance 5/5
Health-sector implementation guidance for information-security controls based on ISO/IEC 27002:2022, covering healthcare organisations, health information and healthcare-specific systems.
What it does not solve: It is guidance rather than a replacement for ISO/IEC 27001 certification, health law, clinical safety, device regulation or local risk assessment.
Usually pair with: ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 27701, national health-sector cyber frameworks and clinical-safety governance.
Mandate / applicability: Voluntary unless adopted by policy, procurement, contract or organisational assurance.
Use cases:Cyber securityPrivacy and information governanceDigital product assurance
Security, privacy & clinical safetyUnited States federal health privacy and security rulesFoundationJurisdiction-specific health standard / rule
HIPAA Privacy, Security and Breach Notification Rules
US Department of Health and Human Services / Office for Civil Rights · Current rules; proposed Security Rule changes are not treated as final
Current use (baseline) 5/5
Future relevance 5/5
Legally binding US requirements for privacy, security and breach notification concerning protected health information for regulated entities.
What it does not solve: HIPAA is US law, not a technical interoperability standard or a general international security framework, and it does not apply to every health app or organisation.
Usually pair with: Applicable HITECH provisions, organisational risk management, technical security controls, contracts and other federal or state requirements.
Mandate / applicability: Legally binding in the United States for covered entities and business associates within scope.
Use cases:Privacy and information governanceCyber securityDigital product assurance
Jurisdiction relevance:United States
Scope origin: Jurisdiction-specific health standard / rule
ISO/TC 215 · Parts 1–3: 2014; reviewed and confirmed current in 2026
Current use (baseline) 2/5
Future relevance 4/5
Principles, policy management, formal models and implementation concepts for privilege management and access control to health information and functions, particularly across organisational and policy-domain boundaries.
What it does not solve: It defines a health-informatics access-control framework, not a complete identity service, authentication protocol, token format or turnkey policy engine. Local policy, identity proofing, role and attribute governance, emergency access and audit still need implementation.
Usually pair with: Identity and authentication services, OAuth/OpenID Connect where appropriate, SMART or IHE profiles for API access, policy-decision/enforcement technology, audit, consent and information-governance controls.
Mandate / applicability: Voluntary unless adopted by policy, procurement or local architecture. The ISO 22600 family remains current following ISO review in 2026.
Use cases:Access control and authorizationShared care recordsClinical API interoperabilityPrivacy and information governance
Delegated authorization for APIs using access tokens, with current security guidance for safer OAuth deployments.
What it does not solve: OAuth authorizes client access. It is not itself user authentication, identity proofing, fine-grained clinical policy, consent management or a guarantee that the resource server applies the correct healthcare access decision.
Usually pair with: OpenID Connect for user authentication, SMART App Launch or IHE IUA for healthcare profiles, TLS, scoped authorization, token validation, policy enforcement, logging and least-privilege design.
Mandate / applicability: Open internet standard and best current practice. Use is normally driven by architecture, implementation guides or procurement rather than a general healthcare mandate.
Use cases:Access control and authorizationClinical API interoperabilityDigital product assuranceAI governance
Security, privacy & clinical safetyFederated user authentication and identity layerFoundationCross-sector foundation
OpenID Connect Core 1.0
OpenID Foundation · Core 1.0 Final
Current use (baseline) 5/5
Future relevance 5/5
Interoperable authentication and identity claims layered on OAuth 2.0, enabling clients to verify end-user identity and receive basic identity information.
What it does not solve: Authentication is not the same as authorization. OpenID Connect does not decide whether an authenticated clinician, patient or application is permitted to access a specific record, function or data element.
Usually pair with: OAuth 2.0, organisation or national identity services, assurance levels and MFA, role/attribute sources, authorization policy and healthcare-specific access profiles.
Mandate / applicability: Open standard widely used for federated identity. Applicability depends on local, national or programme identity architecture.
Use cases:Identity and authenticationAccess control and authorizationClinical API interoperabilityDigital product assurance
Standard patterns for launching and authorizing apps against FHIR systems using OAuth 2.0, including scopes, launch context, client authentication and backend services.
What it does not solve: SMART App Launch constrains authorization interactions but does not define the underlying clinical access policy, identity proofing, consent model, detailed record-level authorization or clinical safety of the application.
Usually pair with: FHIR, OAuth 2.0 security best practice, OpenID Connect where user identity is needed, CDS Hooks where workflow invocation is needed, terminology, audit and local authorization policy.
Mandate / applicability: Voluntary unless required by an implementation guide, national programme, platform or procurement.
Use cases:Access control and authorizationClinical API interoperabilityClinical decision supportDigital product assurance
Security, privacy & clinical safetyHealthcare authorization profile for RESTful transactionsSpecialistHealth-specific
IHE Internet User Authorization (IUA)
IHE International · Current published ITI profile
Current use (baseline) 2/5
Future relevance 4/5
Adds OAuth-based authorization information to HTTP RESTful healthcare transactions, including access-token acquisition, incorporation, introspection and authorization-server metadata.
What it does not solve: IUA conveys and supports authorization but does not define the organisation's full access policy, user-authentication method, consent policy or the detailed decision logic used by a resource server.
Usually pair with: OAuth, OpenID Connect where applicable, IHE transaction profiles such as MHD, identity services, resource-server policy enforcement, audit and local/national security policy.
Mandate / applicability: IHE profile. Voluntary unless selected in a national architecture, interoperability specification or procurement.
Use cases:Access control and authorizationClinical API interoperabilityShared care recordsImaging interoperability
Security, privacy & clinical safetyAttribute-based access-control policy language and decision architectureSpecialistCross-sector foundation
OASIS XACML 3.0
OASIS · XACML 3.0
Current use (baseline) 2/5
Future relevance 3/5
A standard language and architecture for expressing and evaluating fine-grained access-control policies using subject, resource, action and environmental attributes.
What it does not solve: XACML does not supply authoritative healthcare identities, roles, attributes or consent facts, and adoption can add policy-management complexity. A standards-conformant policy engine still needs good policy design and trustworthy attribute sources.
Usually pair with: Identity and attribute services, ISO 22600 concepts, OAuth/SMART/IHE access tokens, policy enforcement points, audit, consent and information-governance processes.
Mandate / applicability: Voluntary OASIS standard. Best treated as a policy-expression option where fine-grained attribute-based authorization is justified.
Use cases:Access control and authorizationPrivacy and information governanceShared care records
Security, privacy & clinical safetyCertifiable AI management system standardWatchCross-sector foundation
ISO/IEC 42001:2023
ISO/IEC · Edition 1, December 2023
Current use (baseline) 2/5
Future relevance 5/5
Enterprise AI governance, accountability, policy, lifecycle controls and auditable management-system practice.
What it does not solve: Not healthcare-specific and does not demonstrate clinical safety, model performance, lawful processing or medical-device compliance by itself.
Usually pair with: ISO/IEC 23894, information security/privacy, clinical safety, model validation and regulation where applicable.
Mandate / applicability: Voluntary unless adopted by organisation, regulator or contract
Use cases:AI governanceDigital product assuranceClinical safety
Professional standardsHealth and care informatics competence and registration standardScaleHealth-specific professional framework / credential
FEDIP Standard and professional registration
Federation for Informatics Professionals (FEDIP) · Current
Current use (baseline) 3/5
Future relevance 5/5
Demonstrating competence, ethics, CPD and professional accountability across health and care informatics roles.
What it does not solve: Does not replace specialist competence, statutory clinical registration or organisational assurance.
Usually pair with: SFIA, specialist standards competence, continuing professional development and the code of conduct required by the relevant professional body.
Mandate / applicability: NHS England is actively promoting/expecting professional registration for relevant digital staff; exact employment requirements vary
Use cases:Professionalisation and workforce assuranceClinical informatics capability
Professional standardsHealthcare digital leadership credentialSpecialistHealth-specific professional framework / credential
CHIME Certified Healthcare CIO (CHCIO)
College of Healthcare Information Management Executives (CHIME) · Current CHCIO programme
Current use (baseline) 2/5
Future relevance 3/5
A healthcare-specific credential demonstrating executive digital-health leadership knowledge and experience for CIO and equivalent roles.
What it does not solve: CHCIO is an executive credential rather than a profession-wide registration standard, technical skills framework, statutory registration or organisational assurance mechanism.
Usually pair with: FEDIP where applicable, SFIA or equivalent role frameworks, employer leadership expectations, continuing professional development and specialist technical or clinical competence.
Mandate / applicability: Voluntary professional credential; relevance depends on role, employer and jurisdiction.
Use cases:Professionalisation and workforce assuranceClinical informatics capabilityRole design and skills planning
CODATA / WorldFAIR community · CDIF Book; framework first released May 2024 and under continuing refinement
Current use (baseline) 1/5
Future relevance 4/5
Provides cross-domain patterns for discovery, access, controlled vocabularies, data integration and universal elements so FAIR data can be combined across disciplines.
What it does not solve: A framework of recommendations and profiles, not a healthcare exchange format, repository model or conformance regime.
Usually pair with: DDI-CDI, DCAT or Schema.org, SKOS or XKOS, provenance, domain standards such as FHIR or OMOP, and local governance.
Mandate / applicability: Voluntary research-data interoperability framework; adoption depends on the research infrastructure or programme.
Use cases:Cross-domain research interoperabilityMetadata and data governanceSemantic interoperabilityResearch data access
Analytics & researchStatistical data and metadata exchange standardSpecialistCross-sector foundation
SDMx 3.1
SDMx Sponsors · Technical Specifications 3.1, May 2025
Current use (baseline) 2/5
Future relevance 4/5
Defines an information model, APIs and XML, JSON and CSV formats for exchanging statistical data, structural metadata and reference metadata.
What it does not solve: Not a patient-level clinical interchange standard or observational research common data model; value depends on governed statistical structures and code lists.
Usually pair with: DDI for study and microdata documentation, classifications and code lists, provenance, and analytical models or source systems that produce the statistics.
Mandate / applicability: Published as ISO 17369 and widely used by international statistical organisations; adoption in health programmes depends on reporting and exchange requirements.
Use cases:Statistical data and metadata exchangePopulation analyticsMetadata and data governanceClinical reporting
Analytics & researchResearch-data metadata coreWatchCross-sector foundation
DDI Common Core / ISO/PAS 25955:2026
DDI Alliance / ISO · DDI Common Core v1 (2025); ISO/PAS 25955:2026
Current use (baseline) 1/5
Future relevance 4/5
Defines common variable, unit and value-domain concepts that underpin DDI products and support consistent research-data metadata across the data lifecycle.
What it does not solve: A metadata core rather than a full study lifecycle specification, exchange protocol or healthcare data model.
Usually pair with: DDI-Codebook, DDI-Lifecycle or DDI-CDI according to use case, plus domain terminologies, identifiers and provenance.
Mandate / applicability: Voluntary. Publication as ISO/PAS 25955:2026 gives the common core formal international-standard status but does not itself mandate adoption.
Use cases:Research data documentationMetadata and data governanceCross-domain research interoperability
Analytics & researchDataset and study metadata specificationSpecialistCross-sector foundation
DDI-Codebook 2.6
DDI Alliance · Version 2.6, 15 April 2026
Current use (baseline) 2/5
Future relevance 4/5
Provides structured documentation of a dataset’s content, meaning, provenance, access, variables, questions, files and related study metadata.
What it does not solve: Focused on descriptive documentation of datasets; it does not model the full research lifecycle or integrate heterogeneous data at datum level.
Usually pair with: DDI-Lifecycle for richer lifecycle management, DDI-CDI for cross-domain integration, SDTL for transformation provenance, persistent identifiers and domain terminologies.
Mandate / applicability: Voluntary metadata specification; adoption is driven by repositories, research programmes and data-management requirements.
Use cases:Research data documentationResearch data accessMetadata and data governanceClinical research data management
Analytics & researchResearch data lifecycle metadata specificationSpecialistCross-sector foundation
DDI-Lifecycle 3.3
DDI Alliance · Version 3.3, 15 April 2020
Current use (baseline) 2/5
Future relevance 4/5
Supports planning, capture, processing, storage, discovery, dissemination, preservation and reuse of metadata for complex, longitudinal and linked research datasets.
What it does not solve: A comprehensive research metadata lifecycle model, not a clinical record standard, direct-care API or analytical common data model.
Usually pair with: DDI Common Core, DDI-Codebook for simpler dataset documentation, DDI-CDI for cross-domain integration, controlled vocabularies and repository governance.
Mandate / applicability: Voluntary; most relevant where research infrastructure needs reusable, versioned metadata across multiple lifecycle stages.
Use cases:Research data documentationClinical research data managementLongitudinal research metadataResearch data accessMetadata and data governance
Analytics & researchCross-domain data and provenance metadata specificationWatchCross-sector foundation
DDI Cross-Domain Integration (DDI-CDI) 1.0
DDI Alliance with CODATA collaboration · Version 1.0, January 2025
Current use (baseline) 1/5
Future relevance 5/5
Provides a model-driven, domain-neutral description of variables, data structures, processing and provenance across wide, long, multidimensional and key-value data.
What it does not solve: Not healthcare-specific and does not supply clinical semantics, governance, legal basis or an operational persistence architecture.
Usually pair with: CODATA CDIF, DDI Common Core, DDI-Codebook or DDI-Lifecycle, controlled vocabularies, provenance services and domain-specific standards.
Mandate / applicability: Voluntary emerging standard; particularly relevant to research infrastructures integrating heterogeneous data across domains.
Use cases:Cross-domain research interoperabilityStatistical data and metadata exchangeMetadata and data governanceSemantic interoperabilityResearch data accessPopulation analytics
Data & interoperabilityEU interoperability frameworkWatchJurisdiction-specific health standard / rule
European Electronic Health Record Exchange Format (EEHRxF)
European Commission / EU Member States · EHDS implementation framework; detailed specifications continue through implementing acts
Current use (baseline) 2/5
Future relevance 5/5
A common European exchange framework for priority categories of electronic health data, supporting cross-border access and exchange under the European Health Data Space.
What it does not solve: EEHRxF is not a single universal data model or a replacement for terminology, identity, clinical workflow, national implementation rules or local persistence models. Detailed requirements are being progressively specified through EHDS implementing acts.
Usually pair with: EHDS requirements, MyHealth@EU, national EHR specifications, FHIR and other implementation standards where adopted, terminology, identity, provenance, security and conformance testing.
Mandate / applicability: EHDS requires harmonised EHR interoperability components to support import/export in EEHRxF on a phased timetable. Detailed specifications are being defined through implementing acts.
Use cases:Clinical API interoperabilityShared care recordsMedicines interoperabilityPathology interoperabilityImaging interoperabilityCross-border summaryEuropean cross-border health data exchange
Jurisdiction relevance:Europe / EU
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityEuropean cross-border interoperability infrastructureScaleJurisdiction-specific health standard / rule
MyHealth@EU / eHealth Digital Service Infrastructure
European Commission / participating countries · Operational and expanding under EHDS
Current use (baseline) 3/5
Future relevance 5/5
Operational cross-border exchange of health information through National Contact Points for eHealth, including patient summaries and ePrescriptions/eDispensations.
What it does not solve: It is an interoperability infrastructure and governance arrangement, not a general-purpose EHR standard or a substitute for national systems, local clinical semantics or the wider EHDS secondary-use infrastructure.
Usually pair with: EEHRxF, national contact-point infrastructure, terminology and translation services, identity, security, provenance and national implementation requirements.
Mandate / applicability: Participation and implementation are governed through EU and national arrangements; EHDS progressively strengthens cross-border primary-use obligations.
Use cases:Cross-border summaryMedicines interoperabilityClinical API interoperabilityEuropean cross-border health data exchange
Jurisdiction relevance:Europe / EU
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityUS national core health data standardFoundationJurisdiction-specific health standard / rule
USCDI Version 7
ASTP/ONC, US Department of Health and Human Services · Version 7, published 23 July 2026
Current use (baseline) 5/5
Future relevance 5/5
Defines the baseline set of health data classes and elements for interoperable exchange in the United States and provides the content foundation used by US implementation and certification programmes.
What it does not solve: USCDI defines data content requirements, not a transport protocol, API implementation guide, persistence model or complete semantic specification. Publication of a new version does not mean every certified product immediately implements it.
Usually pair with: US Core, HL7 FHIR R4, terminology standards, SMART App Launch, certification requirements, information-blocking obligations and implementation-specific exchange rules.
Mandate / applicability: USCDI is adopted through US federal health IT policy and certification mechanisms. Version 7 is the latest published version, while earlier versions remain relevant to specific certification and SVAP contexts.
Use cases:Clinical API interoperabilityShared care recordsSemantic interoperabilityNational core data requirementsDigital product assurance
Jurisdiction relevance:United States
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityUS FHIR core implementation guideFoundationJurisdiction-specific health standard / rule
HL7 US Core 9.0.0
HL7 International, US Realm · 9.0.0 STU9, published 2026; aligned to USCDI v6
Current use (baseline) 5/5
Future relevance 5/5
Defines the minimum FHIR profiles and RESTful interactions used to access core clinical data in the United States, providing a reusable national base for APIs and downstream implementation guides.
What it does not solve: US Core does not replace USCDI, and the latest US Core release does not automatically align to the latest USCDI version. US Core 9.0.0 meets USCDI v6 requirements, while USCDI v7 was published later in July 2026.
Usually pair with: USCDI, HL7 FHIR R4, SMART App Launch, terminology and value sets, certification test methods and use-case-specific US implementation guides.
Mandate / applicability: Widely used in US federal interoperability and certification contexts. Exact required version depends on the applicable certification criterion, SVAP choice, programme or contract.
Use cases:Clinical API interoperabilityShared care recordsSemantic interoperabilityNational core data requirementsDigital product assurance
Jurisdiction relevance:United States
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityUS nationwide health information exchange governance and technical frameworkScaleJurisdiction-specific health standard / rule
TEFCA and QHIN Technical Framework
ASTP/ONC and the Recognized Coordinating Entity · Common Agreement 2.1 with current QHIN Technical Framework
Current use (baseline) 4/5
Future relevance 5/5
Provides a nationwide network-of-networks framework for trusted electronic health information exchange among Qualified Health Information Networks and their participants.
What it does not solve: TEFCA is not a replacement for FHIR, US Core, USCDI, local EHR interfaces or organisational information governance. It establishes exchange rules, governance and technical requirements for the TEFCA ecosystem.
Usually pair with: QHIN Technical Framework, US interoperability standards, identity resolution, security, consent and privacy controls, USCDI/US Core where relevant and participating network requirements.
Mandate / applicability: Federal framework created under the 21st Century Cures Act. Participation is structured through the Common Agreement and QHIN arrangements rather than a blanket requirement that every healthcare organisation connect directly.
Use cases:Shared care recordsNational health information exchangeClinical API interoperabilityPrivacy and information governanceAccess control and authorization
Jurisdiction relevance:United States
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityPan-Canadian core health data content standardScaleJurisdiction-specific health standard / rule
Canadian Core Data for Interoperability (CACDI) Version 2
Canadian Institute for Health Information (CIHI) · Version 2, published 31 March 2026
Current use (baseline) 3/5
Future relevance 5/5
Defines a standardised set of essential health data elements and value sets within a common data architecture to support meaningful exchange across Canadian healthcare systems and jurisdictions.
What it does not solve: CACDI defines content and value sets, not the FHIR exchange profiles themselves. It does not remove provincial and territorial implementation differences or substitute for local clinical and legal requirements.
Usually pair with: CA Core+, the Pan-Canadian Health Data Content Framework, terminology standards, provincial and territorial specifications, identity, provenance and conformance testing.
Mandate / applicability: Pan-Canadian data standard intended to support connected care and vendor interoperability. Application depends on federal, provincial, territorial, programme and procurement arrangements.
Use cases:Clinical API interoperabilityShared care recordsSemantic interoperabilityNational core data requirementsMetadata and data governance
Jurisdiction relevance:Canada
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityPan-Canadian FHIR core profile setWatchJurisdiction-specific health standard / rule
CA Core+
Canada Health Infoway with jurisdictional partners · v1.2.0 DFT in 2026
Current use (baseline) 2/5
Future relevance 5/5
Defines Canada's national core set of reusable FHIR profiles, extensions and terminology artefacts to harmonise data exchange across common use cases and jurisdictional health systems.
What it does not solve: CA Core+ is still evolving and does not eliminate provincial or territorial requirements. Draft status must be checked before procurement or conformance claims.
Usually pair with: CACDI, HL7 FHIR R4, pan-Canadian and jurisdiction-specific implementation guides, terminology, conformance testing and local policy.
Mandate / applicability: National interoperability specification under active development. Version and conformance expectations must be checked against the relevant Canadian programme or jurisdiction.
Use cases:Clinical API interoperabilityShared care recordsSemantic interoperabilityNational core data requirements
Jurisdiction relevance:Canada
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityAustralian national core health data content standardScaleJurisdiction-specific health standard / rule
Australian Core Data for Interoperability (AUCDI) Release 2
Australian Digital Health Agency / Sparked community · Release 2 referenced in 2026 national digital health guidance
Current use (baseline) 3/5
Future relevance 5/5
Defines reusable, standardised Australian health data content for interoperability and acts as the content foundation for national FHIR implementations and My Health Record exchange.
What it does not solve: AUCDI is a data-content standard, not the FHIR API specification, terminology service, identity framework or complete My Health Record conformance specification.
Usually pair with: AU Core, FHIR implementation guides, SNOMED CT-AU, Australian Medicines Terminology, Healthcare Identifiers, provenance and My Health Record conformance requirements.
Mandate / applicability: Australian Digital Health Agency guidance states AUCDI is the reference for FHIR data content shared with My Health Record where its scope covers the information uploaded; exact version is set by the relevant implementation guide.
Use cases:Clinical API interoperabilityShared care recordsSemantic interoperabilityNational core data requirementsMetadata and data governance
Jurisdiction relevance:Australia
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityAustralian FHIR core implementation guideScaleJurisdiction-specific health standard / rule
HL7 AU Core
HL7 Australia · 2.x current implementation line; 3.0.0 balloted in August–September 2026
Current use (baseline) 3/5
Future relevance 5/5
Defines Australian minimum expectations for FHIR resources and RESTful API interactions and provides the national base for downstream Australian implementation guides.
What it does not solve: AU Core does not by itself specify a complete clinical use case, and active development means implementers must identify the exact published version required. It does not replace AUCDI, terminology, identity or My Health Record programme rules.
Usually pair with: AU Base, AUCDI, HL7 FHIR R4, SNOMED CT-AU, Australian Medicines Terminology, national identifiers and downstream Australian implementation guides.
Mandate / applicability: National FHIR core specification. Australian Digital Health Agency guidance now requires AU Core for FHIR connections to My Health Record, with the exact version specified by the relevant implementation guide and conformance profile.
Use cases:Clinical API interoperabilityShared care recordsSemantic interoperabilityNational core data requirements
Jurisdiction relevance:Australia
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityAustralian national clinical and medicines terminologyFoundationJurisdiction-specific health standard / rule
SNOMED CT-AU and Australian Medicines Terminology (AMT)
Australian Digital Health Agency / National Clinical Terminology Service · Continuously maintained national releases
Current use (baseline) 5/5
Future relevance 5/5
Provides the nationally governed terminology foundation for Australian clinical concepts and medicines, supporting consistent recording and exchange across digital health systems.
What it does not solve: Terminology does not define the FHIR structure, workflow, persistence model, access-control policy or complete information model.
Usually pair with: AUCDI, AU Core, FHIR implementation guides, terminology services, value-set governance and My Health Record conformance requirements.
Mandate / applicability: Australian Digital Health Agency interoperability requirements specify SNOMED CT-AU and Australian Medicines Terminology for relevant production use and require current national terminology releases within defined implementation windows.
Use cases:Semantic interoperabilityMedicines interoperabilityShared care recordsClinical API interoperabilityNational core data requirements
Jurisdiction relevance:Australia
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityNew Zealand national core health data standardScaleJurisdiction-specific health standard / rule
NZ Core Data for Interoperability (NZCDI) 2026
Health New Zealand | Te Whatu Ora / HISO · HISO 10100:2026; 2026 draft release available
Current use (baseline) 3/5
Future relevance 5/5
Defines the core set of data concepts, elements and value domains for interoperability across the New Zealand health system, with source standards and national terminology bindings.
What it does not solve: NZCDI defines national core content, not the FHIR API profiles or complete exchange architecture. The 2026 release is identified as a draft and should not be treated as final without checking current HISO publication status.
Usually pair with: NZ Base, FHIR-first policy, SNOMED NZ Edition, NZ Health Terminology Service, NZ Patient Summary, HISO identity standards and implementation-specific requirements.
Mandate / applicability: Health NZ identifies NZCDI as a national data standard. Published HISO standards, roadmaps and architecture guidelines are expected to be followed by health organisations; draft release status must still be checked.
Use cases:Clinical API interoperabilityShared care recordsSemantic interoperabilityNational core data requirementsMetadata and data governance
Jurisdiction relevance:New Zealand
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityNew Zealand national FHIR base implementation guideScaleJurisdiction-specific health standard / rule
HL7 FHIR New Zealand Base 3.1.0
HL7 New Zealand · 3.1.0 release line, August 2026
Current use (baseline) 3/5
Future relevance 5/5
Provides common reusable FHIR artefacts for New Zealand, including extensions, identifiers, terminology artefacts, naming systems and profiles, forming the national base for downstream FHIR implementation guides.
What it does not solve: NZ Base is deliberately not a complete use-case implementation guide and does not specify every resource, interaction or profile that a particular solution must support.
Usually pair with: HL7 FHIR R4, NZCDI, NZ Patient Summary, NHI/HPI identity standards, SNOMED NZ Edition, NZ Health Terminology Service and downstream implementation guides.
Mandate / applicability: Health NZ's FHIR-first policy requires FHIR for new health data exchange solutions and identifies NZ Base as the national base implementation guide.
Use cases:Clinical API interoperabilityShared care recordsSemantic interoperabilityNational core data requirementsIdentity and authentication
Jurisdiction relevance:New Zealand
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityNational interoperability policy and standards frameworkFoundationJurisdiction-specific health standard / rule
Health NZ FHIR-first interoperability policy
Health New Zealand | Te Whatu Ora · Current principal interoperability standards guidance, 2026
Current use (baseline) 4/5
Future relevance 5/5
Establishes FHIR as the required standard for new New Zealand health data exchange solutions and positions NZ Base, NZCDI, SNOMED CT and patient-summary standards as principal components of the national interoperability approach.
What it does not solve: FHIR-first is a policy direction and standards framework rather than a single technical specification. It does not remove the need for specific implementation guides, terminology, identity, governance, safety and conformance requirements.
Usually pair with: NZ Base, NZCDI, SNOMED NZ Edition, NZ Patient Summary, HISO standards, identity services and NZ Health Terminology Service.
Mandate / applicability: Health NZ states that FHIR must be used in new health data exchange solutions and that the FHIR-first policy applies to all new builds and may be enforced when modernising existing solutions.
Use cases:Clinical API interoperabilityNational health information exchangeNational core data requirementsDigital product assurance
Jurisdiction relevance:New Zealand
Scope origin: Jurisdiction-specific health standard / rule
Data & interoperabilityEvent-driven healthcare messaging standard familyFoundationHealth-specific
HL7 Version 2.x messaging
HL7 International · Version 2.9 reference release; extensive installed base uses earlier 2.x versions
Current use (baseline) 5/5
Future relevance 4/5
Widely deployed event-driven messaging for operational healthcare interfaces including ADT, orders, observations/results, scheduling and departmental workflows.
What it does not solve: HL7 V2 does not prescribe a common application architecture, complete semantic model, API style, workflow layer or security architecture. Local optionality and site-specific profiling can reduce plug-and-play interoperability.
Usually pair with: Local or national message profiles, terminology and code-set governance, interface conformance testing, identity, security, acknowledgements and operational monitoring. FHIR may complement rather than automatically replace V2.
Mandate / applicability: Extensively used internationally. Exact version and profile are normally determined by national specifications, local interface contracts, programme requirements or installed-system constraints.
Use cases:Clinical messaging and integrationOrders and resultsPatient administrationMedicines interoperabilityPathology interoperabilityShared care records
HL7 International · CDA R2.0 normative; current FHIR logical-model representation 2.0.3-sd (2026)
Current use (baseline) 4/5
Future relevance 4/5
Defines the structure and semantics of persistent, stewarded, human-readable clinical documents for exchange.
What it does not solve: CDA is a document architecture rather than an API, document registry, longitudinal EHR repository or workflow standard. CDA conformance does not guarantee common clinical content unless templates and terminology are also constrained.
Usually pair with: CDA templates and implementation guides such as C-CDA, terminology, IHE XDS/XDR/XDM, identity, provenance, security and national content specifications.
Mandate / applicability: International HL7 standard with substantial installed use. Specific CDA templates and document types are mandated or recommended in some jurisdictions and programmes rather than CDA R2 universally.
Use cases:Clinical document exchangeShared care recordsDischarge summariesCross-border summaryEHR communication and information modelling
Data & interoperabilityModel-driven healthcare interoperability frameworkLegacy / specialistHealth-specific
HL7 Version 3 and Reference Information Model (RIM)
HL7 International · Normative V3 family; RIM remains foundational to CDA and other V3-derived artefacts
Current use (baseline) 2/5
Future relevance 2/5
Provides the model-driven foundation for the HL7 Version 3 family, including the RIM, data types, vocabularies and domain-specific specifications.
What it does not solve: HL7 V3 should not be treated as the default choice for new interoperability solely because it is more formally modelled than V2. Greenfield API implementation is usually better considered through FHIR or other contemporary profiles unless a V3 dependency already exists.
Usually pair with: CDA, terminology, existing V3 message profiles, national specifications and transformation or mediation where V2/FHIR coexist.
Mandate / applicability: Historically adopted in some national and enterprise architectures. Current applicability is predominantly legacy, specialist or derivative through standards such as CDA.
Use cases:Legacy interoperabilitySemantic interoperabilityClinical document exchangeEHR communication and information modelling
Data & interoperabilityCross-enterprise clinical document sharing integration profileFoundationHealth-specific
IHE Cross-Enterprise Document Sharing (XDS.b)
IHE International · Final Text in current IHE ITI Technical Framework
Current use (baseline) 4/5
Future relevance 4/5
Defines actors, registry/repository behaviour and transactions for registering, finding, distributing and retrieving clinical documents across healthcare enterprises.
What it does not solve: XDS.b manages documents and metadata as units of information. It does not define internal clinical content, provide field-level data query, replace patient identity management or establish the governance policies of the sharing community.
Usually pair with: CDA or other document content standards, patient identity profiles, ATNA/security, consent/privacy profiles, XCA and XDS-I.b.
Mandate / applicability: Widely adopted IHE profile, especially in regional and national document-sharing architectures. Use is determined by the relevant programme, network or procurement.
Use cases:Clinical document exchangeShared care recordsNational health information exchangeCross-border summaryEHR communication and information modelling
Data & interoperabilityCross-enterprise imaging document and object sharing profileScaleHealth-specific
IHE Cross-Enterprise Document Sharing for Imaging (XDS-I.b)
IHE International · XDS-I.b Final Text in IHE Radiology Technical Framework
Current use (baseline) 3/5
Future relevance 4/5
Extends cross-enterprise sharing patterns to imaging, allowing image-related documents and references to DICOM objects to be discovered and accessed across organisational boundaries.
What it does not solve: XDS-I.b does not replace DICOM, PACS/VNA functionality or the broader XDS document-sharing governance. The original XDS-I profile is deprecated and replaced by XDS-I.b.
Usually pair with: DICOM, XDS.b, patient identity, XCA-I, ATNA/security and relevant imaging workflow profiles.
Mandate / applicability: IHE Radiology Final Text profile. Applicability depends on regional, national or enterprise imaging-sharing architecture.
Use cases:Imaging interoperabilityClinical document exchangeShared care recordsNational health information exchange
Data & interoperabilityUS CDA template and clinical document implementation guideFoundationJurisdiction-specific health standard / rule
HL7 Consolidated CDA (C-CDA)
HL7 International, US Realm · 5.0.0 current release line in 2026
Current use (baseline) 5/5
Future relevance 4/5
Constrains CDA R2 into a common set of US clinical document templates such as continuity-of-care documents, discharge summaries, consultation notes and care plans.
What it does not solve: C-CDA is US-specific and should not be treated as a universal CDA implementation model. It remains document-oriented and does not replace FHIR APIs, US Core or USCDI.
Usually pair with: CDA R2, USCDI, US certification requirements, terminology, provenance, document exchange infrastructure and FHIR where API access is also required.
Mandate / applicability: Long-standing component of US health IT certification and exchange. Exact required release depends on the applicable certification and programme requirements.
Use cases:Clinical document exchangeShared care recordsDischarge summariesNational core data requirements
Jurisdiction relevance:United States
Scope origin: Jurisdiction-specific health standard / rule
Process & computable knowledgePath navigation and expression languageFoundationHealth-specific
HL7 FHIRPath
HL7 International · FHIRPath Release 2; normative in current FHIR use
Current use (baseline) 4/5
Future relevance 5/5
Provides a standard expression language for navigating, extracting and testing data in FHIR and related information models.
What it does not solve: FHIRPath is an expression language, not a terminology, query service, complete rule engine, workflow notation or clinical guideline representation.
Usually pair with: FHIR, CQL, Structured Data Capture, implementation-guide conformance rules and test tooling.
Mandate / applicability: Normative part of the FHIR ecosystem where referenced by FHIR specifications and implementation guides.
Use cases:Computable guidelinesClinical decision supportStructured data captureClinical API interoperabilitySemantic interoperability
Process & computable knowledgeFHIR questionnaire and structured form implementation guideScaleHealth-specific
HL7 FHIR Structured Data Capture (SDC)
HL7 International · 4.0.0 STU4, published March 2026
Current use (baseline) 3/5
Future relevance 5/5
Defines reusable patterns for authoring, rendering, pre-populating, controlling and extracting data from FHIR Questionnaires and QuestionnaireResponses.
What it does not solve: SDC is not a general-purpose EHR information model, case-report-form standard for every research context, workflow engine or clinical terminology.
Usually pair with: HL7 FHIR R4, FHIRPath, CQL where expressions are required, terminology/value sets, provenance, consent and workflow-specific implementation guides.
Mandate / applicability: HL7 trial-use implementation guide. Use depends on programme or product requirements rather than a general international mandate.
Use cases:Structured data captureClinical decision supportResearch data capturePatient-reported informationClinical API interoperability
Data & interoperabilityUK health and care information-record content standardScaleJurisdiction-specific health standard / rule
PRSB About Me Standard
PRSB (originator; check current stewardship) · v2.01
Current use (baseline) 3/5
Future relevance 4/5
Structures the information a person considers most important for health and care professionals to know about them, including communication, preferences, needs and what matters to the person.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: PRSB Core Information Standard, Personalised Care and Support Plan, provenance, terminology and the nation-specific exchange specification.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentShared care recordsPerson-centred careSemantic interoperability
Data & interoperabilityUK health and care information-record content standardFoundationJurisdiction-specific health standard / rule
PRSB Provenance Data Standard
PRSB (originator; check current stewardship) · v1.2
Current use (baseline) 2/5
Future relevance 4/5
Defines reusable provenance information describing who recorded or performed an activity, where it happened and when, for reuse across PRSB information standards.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Other PRSB standards, audit, identity, record lifecycle governance and the technical provenance representation used by the implementation.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentProvenanceShared care recordsDigital product assurance
Data & interoperabilityUK health and care information-record content standardScaleJurisdiction-specific health standard / rule
PRSB Personalised Care and Support Plan Standard
PRSB (originator; check current stewardship) · v2.0
Current use (baseline) 3/5
Future relevance 4/5
Defines information for a single shared personalised care and support plan developed with the person and usable across health and social care.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: About Me, Core Information Standard, Palliative and End of Life Care, provenance, terminology and local/national care-plan exchange specifications.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentCare planningShared care recordsPerson-centred care
Data & interoperabilityUK health and care information-record content standardScaleJurisdiction-specific health standard / rule
PRSB Palliative and End of Life Care Standard
PRSB (originator; check current stewardship) · v1.11
Current use (baseline) 3/5
Future relevance 5/5
Defines the core information needed to record and share palliative and end-of-life care plans, preferences, decisions and anticipatory information.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Personalised Care and Support Plan, About Me, Core Information Standard, ISO 27269 data types where used, terminology, provenance and EPaCCS implementation rules.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentCare planningShared care recordsPalliative and end of life care
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Diabetes Information Standard
PRSB (originator; check current stewardship) · v1.0
Current use (baseline) 2/5
Future relevance 4/5
Defines information needed for diabetes management across care settings, including a diabetes record model and self-management information from people, apps and medical devices.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: SNOMED CT, LOINC where appropriate, ISO/IEEE 11073 for device data where applicable, FHIR or other exchange specifications, provenance and local diabetes pathways.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentLong-term condition managementPatient-generated dataMedical-device interoperability
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Wound Care Information Standard
PRSB (originator; check current stewardship) · v1.0
Current use (baseline) 2/5
Future relevance 4/5
Defines standardised information for wound assessment and treatment, treatment planning and supported self-care.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Core Information Standard, Personalised Care and Support Plan, terminology, images where relevant, provenance and local wound-care pathways.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentCare planningCommunity carePatient-generated data
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Social Prescribing Information Standard
PRSB (originator; check current stewardship) · v1.1
Current use (baseline) 2/5
Future relevance 4/5
Defines information for referral to social prescribing, interaction with the link worker and feedback to the referrer and GP.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Core Information Standard, About Me, referral specifications, provenance and local community-service directories.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentSocial prescribingReferralPerson-centred care
Data & interoperabilityUK health and care information-record content standardScaleJurisdiction-specific health standard / rule
PRSB Digital Maternity Record Standard
PRSB (originator; check current stewardship) · v2.1.2
Current use (baseline) 3/5
Future relevance 5/5
Defines structured maternity record information spanning antenatal, intrapartum and postnatal care to improve continuity and safe information sharing.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Obstetric Anaesthetic Standard, terminology, provenance, national maternity specifications and the exchange/profile standards adopted by the relevant nation.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentMaternityShared care recordsLongitudinal EHR and data platform
Data & interoperabilityUK health and care information-record content standardWatchJurisdiction-specific health standard / rule
PRSB Obstetric Anaesthetic Standard
PRSB / Obstetric Anaesthetists’ Association · v1.1.0, March 2026
Current use (baseline) 1/5
Future relevance 4/5
Defines a minimum dataset for obstetric anaesthesia and analgesia, intended to complement the Digital Maternity Record Standard.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Digital Maternity Record Standard, SNOMED CT/value sets, provenance, local anaesthetic record systems and national maternity requirements.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentMaternityAnaesthesiaQuality improvement
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Nursing Care Needs Standard
PRSB (originator; check current stewardship) · v1.0
Current use (baseline) 2/5
Future relevance 4/5
Defines information needed to record and share a person’s nursing care needs across health and social care settings.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Core Information Standard, About Me, care plans, terminology, provenance and local nursing documentation requirements.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentNursingShared care recordsCare planning
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Healthy Child Record Standard
PRSB (originator; check current stewardship) · v2.2
Current use (baseline) 2/5
Future relevance 4/5
Defines child-health record information including screening, immunisation and developmental milestones and supports digital personal child health records.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Terminology, vaccination standards, identity, provenance and nation-specific child-health programme requirements.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentChild healthVaccinationShared care records
Data & interoperabilityUK health and care information-record content standardScaleJurisdiction-specific health standard / rule
PRSB Community Pharmacy Standard
PRSB (originator; check current stewardship) · v3.01.3
Current use (baseline) 3/5
Future relevance 4/5
Defines information for recording and sharing community-pharmacy services with GP practices and other health and care services.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: dm+d, SNOMED CT, medicines/allergy transfer standards, FHIR or messaging specifications, identity and provenance.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentMedicines interoperabilityCommunity pharmacyClinical messaging and integration
Data & interoperabilityUK health and care information-record content standardScaleJurisdiction-specific health standard / rule
PRSB Clinical Referral Information Standard
PRSB (originator; check current stewardship) · v1.0
Current use (baseline) 3/5
Future relevance 4/5
Defines the structured clinical information needed in referrals so that receiving professionals have consistent information about the person, referral and relevant clinical context.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Booking/referral transport specifications, Core Information Standard, terminology, identity, provenance and nation-specific referral workflows.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentReferralClinical messaging and integrationShared care records
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB 111 Referral Standard
PRSB (originator; check current stewardship) · v1.0
Current use (baseline) 3/5
Future relevance 3/5
Defines information to be shared when a person is referred from 111 or 999 services to another service and includes associated GP post-event messaging content.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Nation-specific urgent-care workflows, booking/referral transport specifications, terminology, identity, provenance and receiving-service requirements.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentUrgent and emergency careReferralClinical messaging and integration
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Ambulance Handover to Emergency Care Standard
PRSB (originator; check current stewardship) · v1.0
Current use (baseline) 2/5
Future relevance 4/5
Defines information that should be transferred from an ambulance service to emergency care at or immediately before handover.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Emergency-care workflow specifications, terminology, identity, provenance, observations and nation-specific ambulance standards.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentUrgent and emergency careTransfer of careClinical messaging and integration
Data & interoperabilityUK health and care information-record content standardFoundationJurisdiction-specific health standard / rule
PRSB Transfer of Care – Acute Inpatient Discharge Standard
PRSB (originator; check current stewardship) · v2.1
Current use (baseline) 4/5
Future relevance 4/5
Defines the information content and structure for an acute inpatient electronic discharge summary transferred to primary and community care.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Medicines/allergy transfer requirements, terminology, document or FHIR exchange specifications, provenance, identity and national discharge requirements.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentDischarge summariesTransfer of careClinical document exchange
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Emergency Care Discharge Standard
PRSB (originator; check current stewardship) · v2.2
Current use (baseline) 3/5
Future relevance 4/5
Defines structured discharge information from emergency care for onward transfer to general practice and other services.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Terminology, medicines/allergy transfer standards, exchange specifications, identity and provenance.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentUrgent and emergency careDischarge summariesTransfer of care
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Mental Health Inpatient Discharge Standard
PRSB (originator; check current stewardship) · v2.1
Current use (baseline) 3/5
Future relevance 4/5
Defines discharge-summary information for adults leaving inpatient mental-health services to support continuity across mental, physical and social care.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Terminology, medicines/allergy transfer requirements, care plans, exchange specifications, identity and provenance.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentMental healthDischarge summariesTransfer of care
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Outpatient Letter Standard
PRSB (originator; check current stewardship) · v2.2
Current use (baseline) 4/5
Future relevance 3/5
Defines consistent structured content for outpatient correspondence between specialists, general practice, other professionals and the person.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: CDA/FHIR/document exchange as selected locally, terminology, identity, provenance and national correspondence requirements.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentClinical document exchangeOutpatient careTransfer of care
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Information Provided by Local Authorities in Shared Care Records
PRSB (originator; check current stewardship) · v1.1
Current use (baseline) 2/5
Future relevance 4/5
Defines information held by local authorities that is useful to health and care professionals through shared-care-record services.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Core Information Standard, care-home views, identity, information governance, provenance and the local shared-care-record architecture.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentShared care recordsSocial careCommunity care
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Care Homes View of Shared Care Records
PRSB (originator; check current stewardship) · v1.1
Current use (baseline) 2/5
Future relevance 4/5
Defines the health information that care-home staff should be able to view from shared-care records to support safe care.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Core Information Standard, local-authority information, identity/access control, information governance and local shared-care-record implementation.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentShared care recordsSocial careCare homes
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Hospital Referral for Assessment for Community Care and Support
PRSB (originator; check current stewardship) · v1.1
Current use (baseline) 2/5
Future relevance 4/5
Defines information needed when a hospital refers an adult for assessment of ongoing health and social-care support following discharge.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Core Information Standard, discharge standards, local-authority information, identity, provenance and nation-specific discharge/community-care processes.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentReferralTransfer of careSocial care
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Shared Decision Making Standard
PRSB (originator; check current stewardship) · v1.0
Current use (baseline) 2/5
Future relevance 4/5
Defines information for recording the shared decision-making process, including options, benefits and harms, what matters to the person and the decision reached.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Core Information Standard, About Me, care planning, terminology, consent/decision-support guidance and provenance.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentShared decision makingPerson-centred careCare planning
Data & interoperabilityUK health and care information-record content standardSpecialistJurisdiction-specific health standard / rule
PRSB Urgent Transfer from Care Home to Hospital Standard
PRSB (originator; check current stewardship) · v1.3
Current use (baseline) 2/5
Future relevance 4/5
Defines clinical, demographic and social information needed when a person is transferred urgently from a care home to hospital.
What it does not solve: Defines information content and recording/sharing requirements for a health or care use case. It does not by itself define the transport protocol, FHIR profile, persistence architecture, terminology service, identity model, access-control mechanism or nation-specific legal implementation.
Usually pair with: Core Information Standard, About Me, care plans, medicines/allergy information, identity, provenance and local transfer workflows.
Mandate / applicability: PRSB describes itself as UK-wide and develops standards with engagement across England, Scotland, Wales and Northern Ireland. This entry is therefore marked as relevant across all four UK nations. That does not mean identical mandate or adoption: commissioning, statutory status, national implementation policy, terminology bindings and technical specifications must be checked with the responsible body in each nation. For a number of established PRSB standards, stewardship transferred to NHS England from 1 January 2026; that transfer should not be read as creating an equivalent mandate in Scotland, Wales or Northern Ireland.
Use cases:UK health and care record contentTransfer of careCare homesUrgent and emergency care
The decision aid ranks relevant artefacts according to the primary problem, nation, lifecycle stage and additional safety or AI concerns. It is a starting point for architecture and assurance decisions, not an automated compliance determination.
Selection principle: Choose a primary use case above.
Use-case patterns
See how standards combine in practice
These patterns are architectural starting points. The important question is the role each artefact plays within the stack, including what it deliberately does not attempt to solve.
UK shared care and record content
Use PRSB standards to define the information that should be recorded or shared, then add the nation-specific exchange, terminology, identity, access-control and assurance requirements. Do not infer identical mandate from four-nation relevance.
HL7 V2 remains a core operational integration standard for ADT, orders, results and departmental workflows. Profile it explicitly and govern local codes, identifiers, acknowledgements and interface behaviour.
Keep document content and document-sharing infrastructure separate. CDA describes the persistent clinical document; C-CDA constrains it for US use; XDS.b provides cross-enterprise registration, discovery and retrieval.
Many health systems will operate HL7 V2, CDA, V3-derived artefacts and FHIR together for years. Treat coexistence, mediation and migration as explicit architecture concerns rather than assuming that FHIR immediately eliminates established standards.
Use FHIR Questionnaire and SDC where forms need structured definition, population, calculation or extraction. FHIRPath and CQL can add computable behaviour, while clinical meaning and workflow still need separate governance.
Core datasets and FHIR core profiles play different roles. Use the national content standard to define what information matters, then the national profile set to define how it is represented and exchanged.
National exchange needs more than a payload format. Combine the exchange framework with content, API profiles, identity, authorization, terminology, privacy, security, provenance and conformance testing.
Do not treat an EHR standard as a single technical specification. Use Contsys for the continuity-of-care conceptual basis, ISO 18308 for architectural requirements, HL7 EHR-S FM for system functions, and then select information, exchange, persistence and assurance standards separately.
ISO 13606 provides a reference-model and archetype-based approach to communicating EHR information. It should be considered alongside terminology, provenance, identity, access control and the national or European exchange specifications relevant to the deployment.
Use a layered model: identity and authentication establish who or what is acting; OAuth or healthcare profiles convey authorization; policy models determine what is permitted; enforcement points apply the decision; audit and governance provide accountability.
Do not conflate identity with authorization. OpenID Connect can provide interoperable user authentication and identity claims, while OAuth and healthcare-specific profiles govern access to APIs and resources.
Start with EHDS and EEHRxF obligations, then combine the European interoperability layer with the relevant national profiles, terminology, identity, security, provenance and conformance testing. MyHealth@EU provides the operational cross-border context for priority services.
Computable knowledge requires explicit knowledge representation plus trustworthy clinical semantics, provenance and clinical-safety governance. CDS Hooks can provide the workflow-triggered invocation layer that connects a clinical system to an external decision-support service.
Use ISO/IEC 27001 for the management system, ISO/IEC 27002 for control guidance and ISO 27799 to apply those controls in the health context. Add jurisdiction-specific legal and assurance requirements, such as HIPAA in the United States or DSPT/NCSC CAF in England.
Use GS1 identifiers, data carriers and traceability standards for products, locations and supply-chain events. Connect these to point-of-care and clinical-record workflows without treating product identifiers as clinical terminology.
Select the applicable ISO/IEEE 11073 part for device-level communication, then add enterprise integration, cybersecurity, medical-device risk management and clinical-safety controls appropriate to the deployment.
Use a transport or API standard together with observation semantics and computable units. LOINC identifies the observation, UCUM represents units, and local-to-standard mappings must preserve specimen, method and provenance.
Separate the abstract patient-summary content definition from its technical implementation. ISO 27269 defines the core dataset and abstract model; HL7 IPS provides an interoperable implementation artefact that is then combined with the applicable national and regional constraints.
Treat the base FHIR release and national profile layers separately. Several in-scope national ecosystems use FHIR R4 but constrain it through different core or base artefacts; a profile from one jurisdiction is not a substitute for another.
Use CODATA CDIF to frame cross-domain FAIR interoperability and DDI-CDI to describe data structure, variables, processing and provenance. Add domain standards for clinical meaning and operational exchange.
Use SDMx for governed exchange of aggregate statistical data and metadata. Pair it with DDI where richer study, variable, microdata or provenance documentation is needed.
Use DDI metadata standards to document datasets, variables, questions, provenance and access in a reusable machine-readable form. Choose Codebook for simpler datasets and Lifecycle for richer longitudinal management.
Use DDI-Lifecycle where metadata must be managed and reused across planning, collection, processing, preservation, linkage and dissemination of complex or longitudinal research datasets.
Compare current use with strategic future relevance
A high-future relevance standard is not automatically ready for immediate adoption. The landscape is intended to make the gap between present UK use and possible strategic value visible. The landscape uses the baseline editorial score so that the two-dimensional comparison remains stable; jurisdiction-sensitive scores are shown in the interactive catalogue and decision aid.
Select a standard in the landscape.
Interpretation
How to read the scores
Current use estimates practical penetration or maturity in the selected jurisdiction. A score of 5 means pervasive, mandatory or deeply embedded within the applicable domain, not flawless use everywhere. Future relevance estimates strategic usefulness over the next several years if implemented competently. The measures are deliberately independent.
Score
Current use
Future relevance
1
Niche, experimental or little visible UK deployment
Limited, speculative or highly contingent value
2
Early adoption or restricted specialist use
Useful in selected contexts
3
Established in some settings or sectors
Material value within a bounded scope
4
Widely used or strongly established
High strategic value
5
Pervasive or mandated in the applicable domain
Foundational or strategically critical
Foundation means established and strategically important. Scale means adoption is growing. Watch means future relevance materially exceeds present routine use. Specialist means high value in a bounded domain. Transition means current use remains substantial but future change is likely.
Jurisdiction
Jurisdictional interpretation
International standards can be technically relevant across many health systems, but national content standards, implementation guides, terminology editions, legal rules and assurance requirements differ. Use the jurisdiction filter to identify the local overlay rather than assuming a globally applicable standard has identical status everywhere.
PRSB four-nation interpretation: PRSB is a UK-wide body and states that its standards are developed through consultation across all four nations. The navigator therefore shows PRSB standards as applicable/relevant in England, Scotland, Wales and Northern Ireland. This is a statement of scope and potential reuse, not evidence that each standard is mandated, implemented or governed identically in all four nations.
FHIR layering note: the base FHIR release and a national profile set are separate artefacts. Terms such as base, core, core data and implementation guide are not used identically across jurisdictions. The navigator therefore records FHIR R4, UK Core, US Core, CA Core+, AU Core and NZ Base separately and does not assume that one jurisdiction's “core” is structurally or legally equivalent to another. Implementers should follow the published dependency and version chain for the service they are building.
England
The NHS Standards Directory provides the most explicit public catalogue of national information standards and assurance requirements among the four nations. SNOMED CT, relevant classifications, UK Core governance, DSPT and the DCB clinical-safety standards have formal status within defined scopes. DTAC adds a national product-assessment baseline. Professionals should always inspect the current standard page and Information Standards Notice rather than relying on the name alone. PRSB-originated standards have particularly direct links to NHS England commissioning and, since January 2026, NHS England stewardship for a number of established standards.
Scotland
Scotland’s health and social care data strategy identifies the importance of common information standards and specifically cites SNOMED CT, ICD-10, OPCS, DICOM, FHIR and openEHR within the interoperability landscape. Its 2025 update reported that the Data Standards Sub-board was developing and piloting an assurance process for preferred standards. English mandates should not be assumed to apply. PRSB standards are relevant as UK-wide information-content references, but Scottish adoption and implementation should be checked against NHS Scotland and Public Health Scotland requirements.
Wales
Digital Health and Care Wales maintains national information standards, classifications, reference data and terminology services. NHS Wales has adopted FHIR R4 as a foundation through a Welsh Health Circular, contributes to UK Core and develops Welsh profiles where needed. The Welsh Reference Data and Terminology Service supplies SNOMED CT and FHIR-compliant code systems, value sets and concept maps. PRSB standards are relevant as UK-wide information-content references, but Welsh adoption and implementation should be checked against NHS Wales and Digital Health and Care Wales requirements.
Northern Ireland
Northern Ireland should be treated as a distinct HSC governance environment. Published strategy emphasises standardised pathways, system integration, cyber security and data-enabled decision-making, but a detailed public standards catalogue comparable to England’s is less visible. International and UK-wide standards remain relevant, but HSCNI and Department of Health requirements should be verified at procurement and design. PRSB standards are relevant as UK-wide information-content references, but Northern Ireland adoption and implementation should be checked against Department of Health and HSCNI requirements.
Europe / European Union
The European standards context is increasingly shaped by the European Health Data Space (EHDS). The Regulation entered into force in March 2025 and is being implemented progressively. For primary use, the first priority categories, patient summaries and ePrescriptions/eDispensations, are due to apply from March 2029, with medical images, laboratory results and hospital discharge reports following from March 2031. The European Electronic Health Record Exchange Format (EEHRxF) becomes particularly important because harmonised EHR interoperability components will be expected to import and export priority health data using that format.
Europe should therefore be treated as a distinct jurisdictional option, not as another UK nation. International standards such as HL7, DICOM, IHE, ISO, openEHR, OMOP, CDISC, DDI, SDMX and CODATA may be technically relevant across Europe, but their legal or procurement status varies by Member State and by EHDS implementation. MyHealth@EU provides the operational cross-border infrastructure for services including patient summaries and ePrescriptions, while HealthData@EU addresses secondary use. National requirements remain relevant alongside the common European layer.
United States
The US overlay is unusually influential because federal policy links data-content standards, FHIR implementation guides, certification and nationwide exchange. USCDI v7 is the latest published national core dataset, while US Core 9.0.0 is the current published US Core release and aligns to USCDI v6 rather than v7. That version gap is important: 'latest USCDI' and 'latest US Core' are not automatically a matched pair. TEFCA adds a separate nationwide exchange-governance layer.
Canada
Canada combines pan-Canadian content and exchange standards with provincial and territorial implementation. CACDI Version 2, published in March 2026, defines the core data content, while CA Core+ provides the corresponding national FHIR profile foundation. CA Core+ remained under active development in 2026, so implementers need to distinguish a pan-Canadian direction from the exact version adopted by a province, territory or programme.
Australia
Australia now has a comparatively explicit national stack. AUCDI provides core data content, AU Core defines minimum FHIR profiles and RESTful interactions, and SNOMED CT-AU plus Australian Medicines Terminology provide national terminology. Australian Digital Health Agency guidance updated in August 2026 states that AU Core is required for FHIR connections to My Health Record and AUCDI is the reference for shared FHIR data where applicable, with exact versions defined by implementation guides and conformance profiles.
New Zealand
New Zealand has one of the clearest national policy positions in the navigator. Health NZ states that FHIR must be used for new health data exchange solutions and applies a FHIR-first policy to all new builds. NZ Base is the national FHIR foundation, NZCDI defines the core data content, and SNOMED CT is required for important clinical data. Health NZ also maintains HISO standards and the NZ Health Terminology Service.
Interpretive rule: A jurisdiction tag means that a standard or framework has material relevance there. It does not imply identical legal status, procurement status, implementation guidance or mandated version. International standards should be combined with the applicable national or regional overlay.
Avoidable mistakes
Common category errors
Starting with a favoured standard rather than a defined problem. Specify the use case, lifecycle stage and decision boundary first.
Assuming exchange equals persistence. A FHIR payload, an openEHR longitudinal repository and an OMOP analytical database are different architectural concerns.
Assuming syntactic conformance creates semantic interoperability. Terminology, information content, units, metadata, provenance and contextual interpretation remain essential.
Using a terminology as though it were the whole data standard. SNOMED CT represents clinical meaning but still requires structures, bindings and governance.
Using a classification for point-of-care meaning. ICD and OPCS support aggregation and statistics; they do not replace detailed clinical terminology.
Confusing assurance with certification or regulation. DTAC, DSPT, DCB0129/DCB0160, ISO certification and medical-device regulation answer different questions.
Buying the supplier’s safety case. Deployment and operational safety responsibilities remain with the deploying organisation where the applicable framework says so.
Assuming data that exchanges correctly is analysis-ready. Research and analytics require provenance, quality, transformation, modelling and appropriate governance.
Ignoring professional competence. Standards do not implement themselves. The competence to interpret, profile, test, govern and assure them is part of the solution.
Assuming CDS Hooks is the decision logic. CDS Hooks defines when and how decision support is invoked and returned. The clinical knowledge, evidence, rules, terminology, safety case and governance still need to be specified separately.
Confusing authentication with authorization. Proving identity does not establish that the user or application is entitled to access a particular patient, record, function or data element.
Treating an access token as the access policy. OAuth, SMART and IUA can convey authorization context, but the resource server still needs explicit, governed policy and enforcement logic.
Ignoring emergency, consent and purpose-of-use rules. Healthcare access control often needs context beyond role membership, including relationships, care context, patient preferences, legal basis and break-glass procedures.
Treating an EHR functional model as though it were an implementation architecture. HL7 EHR-S FM describes functions and conformance criteria; ISO 18308 describes architectural requirements; ISO 13606 and openEHR address information architecture in different ways; FHIR primarily addresses exchange. They occupy different layers of the problem.
Assuming a national core dataset is the same thing as a national FHIR profile. USCDI/US Core, CACDI/CA Core+, AUCDI/AU Core and NZCDI/NZ Base are complementary pairs with different responsibilities.
Assuming FHIR replaces HL7 V2 everywhere. HL7 V2 remains deeply embedded in operational event-driven integration. FHIR often complements it.
Treating CDA and XDS as the same standard. CDA defines clinical document structure and semantics. XDS.b defines the infrastructure for registering, discovering and retrieving documents across enterprises.
Treating HL7 V3 as simply an obsolete messaging format. V3 messaging is largely a legacy concern, but the RIM remains conceptually important because CDA and other artefacts were built from the V3 modelling framework.
Assuming XDS-I replaces DICOM. XDS-I.b supports cross-enterprise imaging sharing; DICOM remains the core standard for imaging objects and services.
Selection method
A practical method for choosing standards
The method deliberately separates semantics, exchange, persistence, assurance and professional accountability so that one standard is not forced to solve the entire information lifecycle.
Define the use case and success criteria. Separate direct care, workflow, secondary use, assurance and professional-capability needs.
Identify jurisdiction and mandatory requirements. Determine national information standards, safety, cyber, privacy, regulatory and contractual obligations before choosing technology.
Choose semantics and information content. Define terminology, content, classifications, units, identifiers and metadata.
Choose representation and transport. Select FHIR, DICOM, IHE or other technical specifications only after the information requirements are understood.
Choose persistence and analytical models separately. Do not force a single canonical representation across the whole data lifecycle.
Add assurance according to risk. Include clinical safety, cyber security, privacy, AI governance and medical-device lifecycle requirements where relevant.
Specify professional accountability. Identify the competence, authority and professional standards expected of those making and assuring the decisions.
Profile, test and govern. Name versions and implementation guides, test conformance and real data fitness, and manage change throughout the lifecycle.
Scoring interpretation: Current use estimates present-day adoption in the selected jurisdiction. Future relevance estimates expected continuing or growing strategic importance over roughly the next five years. A mature standard can therefore score higher for current use than for future relevance.
Scope and maintenance
A curated, living professional resource
This is a curated international navigator rather than an exhaustive inventory. It combines globally relevant standards with jurisdiction-specific overlays for the UK, European Union, United States, Canada, Australia and New Zealand. Inclusion is based on whether a standard or framework represents a distinct and practically important part of the health informatics landscape.
A six-month formal review cycle is appropriate, with event-driven updates for national standards notices, major version changes and regulatory developments. Particularly volatile areas in 2026 include FHIR implementation guides, clinical-safety standards, AI assurance, professional registration expectations and future classification transitions.
Research and secondary-use coverage now includes cross-domain FAIR interoperability, research-data documentation and provenance, longitudinal research metadata, and statistical data and metadata exchange. These areas should be reviewed alongside changes to CODATA CDIF, the DDI product suite and SDMx.
Evidence note:Current-use scores are editorial estimates, not measurements from a census. In the interactive catalogue the estimate changes with the selected jurisdiction. Where jurisdiction-specific evidence is incomplete, the navigator uses cautious editorial judgement and retains the stated confidence level rather than presenting the score as measured adoption.
The PRSB portfolio is treated as a coherent UK information-record standards family rather than as an England-only catalogue. The four-nation tags express relevance and applicability of the information models; national mandate and implementation are assessed separately.
References
Authoritative source register
The catalogue register below contains one primary or authoritative reference for every standard, framework, rule or credential included in the interactive catalogue. It is grouped by catalogue domain and alphabetised within each domain. The link is the principal verification source used for the catalogue entry; it does not imply that a single page exhausts all implementation guidance. Additional jurisdiction and policy sources used for contextual commentary follow separately.
SDMx 3.1 · SDMx Sponsors · Cross-sector foundation
Professional standards
CHIME Certified Healthcare CIO (CHCIO) · College of Healthcare Information Management Executives (CHIME) · Health-specific professional framework / credential
