Skip to content

Standards and Interoperability

For current laboratory and imaging connections, use Diagnostic Results and Image Exchange: it distinguishes live EDIFACT/MESH, the pathology FHIR pilot and NIR beta from later rollout plans.

This page is the overview for standards and interoperability evidence in the wiki.

Use Standards and Interoperability Evidence Domain as the source/evidence routing layer for standards surfaces, supplier-role boundaries, and implementation-proof questions. This page remains the human-readable synthesis overview.

How the Standards Fit Together

Healthcare interoperability needs agreement about the information, its meaning, its representation and the way systems use it. The standards below answer different parts of that problem.

Practical question Relevant layer What it contributes
What information should be recorded or shared? PRSB record-content standards, including CIS Common content for a care record or handover. CIS describes shared-record information; it does not prescribe a complete database or screen design.
What do the clinical codes mean? SNOMED CT, dm+d and terminology resources Clinical concepts and medicine identifiers. A CodeSystem defines codes, a ValueSet selects codes for a context, and a ConceptMap describes mappings between them (SRC-278 to SRC-283, SRC-353).
How is that information represented for exchange? FHIR resources; HL7 messages and CDA documents; DICOM for imaging Structured exchange formats. FHIR supports several exchange approaches, so using FHIR does not require every exchange to be a REST API call.
Which rules apply to this particular use? FHIR profiles and implementation guides; IHE profiles A FHIR profile constrains a resource, while an implementation guide brings related rules together. IHE profiles specify how standards work together for a defined clinical or operational need.
Which service carries out the exchange? GP Connect, MESH and ITK3 GP Connect defines approved service capabilities, MESH carries messages/files, and ITK3 specifies relevant messaging-distribution rules. Their roles and onboarding conditions remain distinct.
Who may access the information, and how is use made safe? Access controls, audit and clinical risk management FHIR provides useful security-related resources but relies on implemented security controls. DCB0129 addresses manufacture of health IT; DCB0160 addresses its deployment and use.

For example, sharing a medicines entry requires agreed record content, a medicine identifier, an exchange format, an approved route and permitted access. Health Connect can mediate the exchange and HealthShare can aggregate or present the information. Those product roles sit within the standards model; the exact content, route and configuration depend on the implementation.

For the GP-practice transfer implementation, use GP2GP Requesting Adapter: it separates the clinical workflow, FHIR/HL7 conversion, current standard, software status and solution assurance. Its GP Connect migration dependency does not confer ordinary consumer or InterSystems deployment approval.

Evidence Set

Evidence area Current conclusion Detail page
InterSystems product standards positioning Official product pages and selected technical docs position IRIS for Health, FHIR Services, Health Connect, HealthShare Unified Care Record, and HealthShare Clinical Viewer around FHIR, HL7, DICOM, IHE, API, data-normalisation, managed infrastructure, shared-record content, clinical presentation/access, FHIR Server, profiles/packages, OAuth/security, Network Connect, Health Connect Cloud, Cloud Services Portal deployment settings, BFC, OMOP, SDA/CDA transformation, AI Assistant / Navigation Application adjacency, and IRIS for Health ITK-documentation themes. The high-risk row audits now cover Health Connect, IRIS for Health, FHIR Services, HealthShare Unified Care Record, HealthShare Clinical Viewer, and HealthShare / PRSB CIS. InterSystems Standards Product Map
NHS England / DHSC standards direction and directory map NHS England continues to describe information standards as legal requirements for consistent capture, governance, sharing, and digital exchange of health and care data. DAPB/DAB governance, mandatory information-standard compliance, the NHS Standards Directory, and current standards collections remain the stronger evidence of ongoing standards stance. The directory now has a dedicated relevance map for FHIR/UK Core, GP Connect, GP2GP/NHAIS, MESH, PDS/events, terminology, medicines, clinical safety, transfer-of-care, shared-record, life-stage, imaging, and diagnostics entries, plus a GP Connect / MESH / ITK3 child page and a GP2GP record-transfer page for distinct routing boundaries. NHS Standards Directory and DHSC Standards Direction
Terminology code management and Read-to-SNOMED mapping Read Version 2 and CTV3 are retired or deprecated for active content management; NHS TRUD provides Read / CTV3 to SNOMED CT migration artefacts, with the generic Read Version 2 to SNOMED CT tables final in April 2020 and static thereafter. Current standards management routes through SNOMED CT UK Edition, dm+d, TRUD releases, NHS England's Terminology Server, FHIR terminology resources, and governed local CodeSystem / ValueSet / ConceptMap handling for local or extension codes. Terminology Code Management and Read-to-SNOMED Mapping
Data (Use and Access) Act 2025 DUAA received Royal Assent on 19 June 2025 and is being commenced in stages. ICO guidance now says all DUAA data-protection provisions are in force as of 19 June 2026. For this wiki, the key health point remains that DUAA clarifies that health and adult social care information standards in England can include IT and IT services, and can apply to providers of IT, IT services, or information-processing services used or intended for health/adult social care in or in relation to England. DUAA does not itself prove any InterSystems conformance or DSIC catalogue status. Data (Use and Access) Act 2025
UK healthcare recording legal and professional position The UK position on healthcare records is layered across UK GDPR, Data Protection Act 2018, PECR, common law confidentiality, Caldicott, NHS Act 2006 section 251, professional standards, provider governance, candour, nation-specific records-management codes, public records, access-route separation, NHS information standards, terminology, clinical safety, provenance, and Health and Care Act 2022 / DUAA England information-standard changes. This proves the assurance model and required evidence categories, not compliance by any named product or deployment. UK Healthcare Recording Legal and Professional Position
Healthcare record source layers Repeated source-layer labels now have a canonical routing map so acronyms and shorthand such as GMC, NMC, HCPC, GPhC, CQC, NICE, PRSB, provider governance, professional duties, DSA/DPIA, records-management code, DCB0129/DCB0160 clinical safety, and public-records routes resolve to source-layer pages or sections. Healthcare Record Source Layers
NHS ITK accreditation claim InterSystems makes a UK NHS Interoperability Toolkit accreditation claim, current IRIS for Health docs repeat the historical ITK accreditation context, and the NHS ITK conformance-process and conformance-catalogue routes exist, but the 2026-06-20 current-source recheck did not find a current public non-vendor row naming InterSystems. The NHS Solution Assurance compliance catalogue explicitly excludes ITK Accreditation. NHS ITK Accreditation
GP Connect GP Connect is an NHS service/API integration context, not an InterSystems product. It now has capability pages and mirrored due-diligence pages, current NHS API/status context, a September supplier-table check retaining specific HealthShare Access Record: Structured cells but omitting the IRIS middleware Send Document row recorded in June, and an evidence request pack for turning those NHS rows into product/version, validation-scope, exclusion, component-coverage, adjacent-standard, and deployment-artefact requests when they are used for assurance. GP Connect Deep Dive
GP2GP GP2GP is a GP-practice record-transfer route, not GP Connect. England, Wales, Scotland, and Northern Ireland have record-transfer evidence, but no current public source proves InterSystems GP2GP implementation or DSIC GP foundation-provider capability. GP2GP Record Transfer
DSIC / NHS England digital primary care DSIC is the England-only digital primary-care procurement, capability, standards, assurance, migration, and Buying Catalogue environment. It maps GP foundation capabilities to national services and standards such as PDS, NHAIS, GP2GP, SCR, GP Connect, GPAD, GPES, MESH/MNS, eMED3, Yellow Card, EPS, e-RS, NHS login, ITK, NDO, and NEMS. NHS England Digital Primary Care
Cross-UK NHS connectivity GP Connect remains an England route in this evidence set. Spine infrastructure also serves Wales and the Isle of Man; that does not establish devolved GP Connect or DSIC adoption. Scotland, Wales, and Northern Ireland need nation-specific functional comparison based on their own summary-record, GP record-transfer, messaging, identifier, prescribing, portal, and national-platform routes. GP Connect and Spine Equivalents by Nation
PRSB standards PRSB is a health and care record-content standards body. Its standards are relevant to shared care records, transfer of care, person-authored information, care plans, pharmacy, child health, maternity, end-of-life care, pathway content, provenance, and supplier conformance. The operating model needs a caveat because PRSB says the NHS England CISS contract ended in December 2025 while NHS England moves standards development/maintenance into a new model. PRSB Standards
PRSB Core Information Standard The published standard is CIS v2.01. PRSB independently lists InterSystems Healthshare as CIS Version 2, Level 2 conformant, valid until 17.06.2028. That listing identifies a standard version, not the HealthShare software version or local adoption of v2.01. CIS Version 3.0 remains in review/final approval in the tracked sources. PRSB Core Information Standard (PRSB CIS)
Programme CORTISONE / UK Defence healthcare MOD CORTISONE evidence is standards-relevant because the programme vision describes open standards, NHS interfaces across the four UK nations, an Integration Platform, and EMPI. InterSystems evidence now supports a HealthShare / IRIS for Health CORTISONE role plus a Contracts Finder OCDS FY25-30 licence-award summary, but public CORTISONE-specific PRSB conformance and full technical architecture evidence remain open. Programme CORTISONE / UK Defence Healthcare
HL7 UK OIDs HL7 UK lists InterSystems-related West Midlands OIDs, which support identifier existence but not current operational status. HL7 UK InterSystems OIDs

Working Interpretation

InterSystems' UK healthcare proposition is strongly interoperability-led. The official website connects the product portfolio to healthcare standards, record aggregation, FHIR infrastructure, integration engines, API-based data exchange, GP Connect, and NHS/public-sector connected-care needs.

Evidence should stay separated by type:

  • Product-positioning evidence from InterSystems pages.
  • External standards evidence from NHS England Digital, DHSC, PRSB, or HL7 UK.
  • Customer or programme evidence that proves configured implementation, live use, or operational status.

The current public reading is not that NHS England has stopped caring about standards. It is that PRSB's NHS England-funded CISS role ended in December 2025, while NHS England/DHSC continue national information-standard governance through DAPB/DAB, the NHS Standards Directory, mandatory standards compliance, and the proposed Health Bill transfer of digital and data functions into the Secretary of State / restructured DHSC model.

The Standards Directory is now mapped separately because it contains several standards families that affect this wiki beyond PRSB: GP Connect APIs, UK Core/FHIR, MESH/ITK3, PDS/events, GP2GP/NHAIS, terminology/medicines, DCB0129/DCB0160 clinical safety, transfer-of-care, shared-record/life-stage content, DICOM, and pathology. Directory presence is standards-surface evidence; it still needs product, conformance, supplier-progress, or customer evidence before becoming an InterSystems implementation claim. GP Connect / MESH / ITK3 now has a child page because the role split across GP foundation system, consumer, document sender, middleware, viewer, and patient-facing component is too dense for the parent map. GP2GP has its own record-transfer page because it is often conflated with GP Connect but asks a different foundation-system and migration question. Terminology now has its own page because Read-to-SNOMED migration, SNOMED CT UK Edition releases, dm+d, NHS Terminology Server APIs, and local-code ConceptMap governance cross several standards families (SRC-182, SRC-183, SRC-184, SRC-185, SRC-186, SRC-187, SRC-194, SRC-263, SRC-278 to SRC-285).

DUAA adds a statutory supplier-facing pressure point to the standards model. Section 121 / Schedule 15 does not replace the NHS Standards Directory, DSIC, GP Connect onboarding, PRSB conformance, or clinical-safety evidence, but it strengthens the question of whether a named information standard applies to the IT supplier or IT service provider, not only to the care organisation using the system. ICO topic guidance now replaces factsheet-only treatment where available; the main subject-access guide and Right of Access in brief are published, while SARs Q&A, research, automated decision-making/profiling, and IDTA/Addendum updates remain tracked until final guidance is published.

The healthcare-recording legal and professional synthesis adds the wider assurance frame around the standards pages. UK GDPR, DPA 2018, PECR, common law confidentiality, Caldicott, NHS Act 2006 section 251, professional record-keeping, provider governance, candour, records-management codes, public-records/access-route separation, SNOMED CT, PRSB/provenance, DCB0129/DCB0160, Health and Care Act 2022, and DUAA should be handled as separate layers. For InterSystems analysis, the key consequence is that Health Connect / HealthShare technical suitability must be paired with deployment artefacts: legal basis, confidentiality route, PECR controls where applicable, record amendment/export/search procedures, access-control/provenance/audit design, records-management retention, clinical safety, information-standard applicability, and supplier RACI (SRC-241 to SRC-260).

For terminology-specific questions, use the Read-to-SNOMED and terminology page before product pages. The current standards model is that historical Read-coded content needs provenance, versioned map artefacts, and clinical review; new clinical coding should use SNOMED CT UK Edition; medicines / devices should use dm+d where electronic medicines transfer is in scope; and local or extension codes should be governed through CodeSystem, ValueSet, and ConceptMap resources in a terminology-service model rather than undocumented application values (SRC-278 to SRC-285).

Follow-up Validation

  • Use the NHS ITK evidence request template to seek current accreditation, conformance, or certificate records naming InterSystems; do not use Solution Assurance compliance-catalogue rows as ITK proof.
  • Add accessible official InterSystems technical documentation for remaining IRIS for Health and HealthShare interoperability features not covered by the new product-depth pages or account-gated HealthShare 2026.1 documentation.
  • Keep Programme CORTISONE / UK Defence healthcare contained unless a new primary source appears or the user explicitly reopens it; do not use it as the default validation path.
  • Validate supplier-specific GP Connect progress records against product documentation, assurance artefacts, and named customer deployments.
  • Validate any supplier-specific GP2GP claim against product documentation, GP2GP conformance/onboarding evidence, migration/cutover artefacts, and named customer deployments.
  • Use the GP Connect InterSystems Supplier Progress request pack when supplier-progress rows are being used as assurance evidence rather than only source-register evidence.
  • Validate HealthShare, Health Connect, IRIS for Health, and FHIR Services implementation details against current InterSystems technical documentation.
  • Keep product capability claims separate from configured implementation patterns in customer deployments.

Standards Pages