Skip to content

GP2GP Record Transfer

This page tracks GP2GP as a GP-practice registration and record-transfer workflow. It is related to DSIC, Spine, PDS, NHAIS, GP clinical-system migration, and devolved-nation primary-care infrastructure. England's FHIR adaptor implementation reuses GP Connect migration operations; this does not make ordinary GP Connect read or messaging assurance proof of GP2GP capability.

Current Reading

GP2GP adds continuity at the point a patient changes GP practice. It moves the electronic GP record from the old GP practice system to the new GP practice system, rather than giving a third-party care setting a read-only GP record view or sending a care-encounter document back to the registered GP practice.

The implementation reading differs by administration:

Administration Current GP2GP / record-transfer reading InterSystems boundary
England NHS England GP2GP is a live GP-practice system-to-system integration where both practices are in England. It uses Spine and HL7 V3 and starts from patient registration. Its FHIR adaptor route reuses GP Connect migration operations; see GP2GP Requesting Adapter for the receiving-system workflow, dependencies and assurance boundary. No public source found in this pass proves InterSystems as a GP2GP provider, requesting/sending GP practice system, or complete DSIC GP foundation supplier. Health Connect or IRIS could be relevant middleware only if an implementation is explicitly designed and assured for the GP2GP role.
Wales DHCW lists GP2GP in its primary-care digital tools, where a GP can send patient records electronically to other Welsh practices. Current InterSystems Wales evidence is all-Wales LIMS / TrakCare Lab Enterprise, including documented laboratory interfaces with WCP and WRRS. Those interfaces do not establish InterSystems as supplier of either national service or as a Welsh GP2GP provider.
Scotland NHS Scotland / NSS sources support electronic transfer of GP health records to a new GP practice where records are electronic and the move is within Scotland. Public patient guidance says electronic records are normally transferred within two days after release, while moves between different UK parts still fall back to printed records at present. Current Scotland InterSystems evidence is Edinburgh office presence, TrakCare PMS / TrakCare ED, and Ensemble context. It does not prove involvement in Scottish GP2GP, CHI, ECS, KIS, SCI Gateway, ePharmacy, MyCare.scot, or NDP routes.
Northern Ireland BSO / HSCNI material identifies GP2GP as a GP IT Modernisation Programme route for electronic transfer of patient notes or records between clinical systems / practices when a patient moves practice. Current direct Northern Ireland InterSystems evidence remains Caché / NHAIS licensing for GP registrations. It does not prove InterSystems involvement in NI GP2GP, encompass, EpicCare Link, My Care, Digital Identity Service, or ePharmacy.

England Requesting Adaptor

The GP2GP Requesting Adapter initiates transfer from the new practice and converts the incoming HL7 V3 EHR to GP Connect FHIR. The receiving clinical system still owns registration, validation, filing, clinical review and transfer workflow. The detailed page separates NHS specifications, repository implementation and deployment proof.

As checked on 25 September 2026, the NHS requesting catalogue still labels the adaptor in development, while DSIC has effective requesting requirements and a tailored supplier assurance route. These are different evidence layers; neither an effective standard nor a software release proves a named production deployment (SRC-427 to SRC-430).

S94's failed-SDS/absent-ASID example includes a previous Defence Medical Services practice that does not support GP2GP. Treat that as a conditional failure scenario requiring endpoint verification, not a current estate-wide finding about DMS or proof of a DMICP/CORTISONE route.

What It Would Add

If GP2GP were implemented in a named InterSystems-backed architecture, it would add a foundation GP record-transfer capability. The practical value would be:

  • Fuller electronic GP records available after patient registration and practice moves.
  • Less reliance on paper transfer, manual re-entry, and patient recall of previous history.
  • Better continuity for allergies, adverse reactions, medications, diagnoses, test results, and rich coded record content.
  • A safer migration and cutover story when a GP foundation system or primary-care estate changes supplier.
  • A concrete proof point that the solution handles patient-registration and record-transfer workflows, not only shared-care viewing or middleware.

It would not add:

  • GP Connect Access Record read access for third-party care settings.
  • GP Connect Send Document or Update Record write-back.
  • A patient-facing portal.
  • Shared-care-record aggregation by itself.
  • Proof that HealthShare is a complete GP foundation clinical system.

InterSystems Interpretation

The current public InterSystems evidence supports product plausibility, not GP2GP implementation proof:

  • Health Connect and IRIS for Health are relevant to HL7, FHIR, CDA, message routing, transformation, monitoring, and integration patterns.
  • HealthShare is relevant to shared-care record, viewer, EMPI, Provider Directory, analytics, and patient-facing patterns.
  • GP2GP is a foundation GP registration and record-transfer obligation. A HealthShare shared-care record, Clinical Viewer, EMPI, Provider Directory, or GP Connect consumer row does not prove GP2GP.
  • GP Connect supplier-progress rows for IRIS for Health (Middleware) and HealthShare do not prove the registration, migration, filing and assurance responsibilities of GP2GP, even though the FHIR adaptor route reuses GP Connect migration operations.
  • PDS, ODS/SDS, NHAIS, MESH, and Spine adjacency does not prove GP2GP. It only identifies neighbouring dependencies and proof targets.

Evidence Needed Before a GP2GP Claim

Use this checklist before treating any InterSystems, partner, or customer deployment as GP2GP-capable:

Proof area Evidence needed
Supplier role Is the product the sending GP clinical system, requesting/receiving GP clinical system, adaptor, middleware, reporting component, hosted platform, or support component?
Product and version Product/component name, version/build, licensed scope, deployment model, and whether the capability belongs to InterSystems or a partner GP foundation supplier.
Standards and integration GP2GP HL7 V3 scope, Spine / MHS route, FHIR adaptor role if used, management-information route, PDS trace dependency, NHAIS / registration interaction, and MESH or related messaging where applicable.
Assurance and onboarding NHS onboarding, conformance, testing, supplier-progress or catalogue evidence, GP practice system compatibility, clinical-safety case, information-governance approval, and service-management pack.
Migration and cutover Source-system extraction, degraded-data handling, record-size / attachment limits, paper-fallback process, reconciliation, training, support, rollback, and eight-day or local service-level handling where applicable.
Deployment proof Customer-approved architecture, named GP practices or ODS scope where publishable, go-live status, operational owner, support RACI, DSA/DPIA, DCB0129/DCB0160 responsibility split, monitoring, and incident process.

Plain-English Boundary

GP2GP answers "can the GP record move when the patient moves GP practice?" GP Connect provides approved record-access and messaging capabilities, including migration operations reused by GP2GP adaptors. HealthShare answers "can records be aggregated, matched, viewed, or analysed where a deployment proves that role?" Health Connect / IRIS answers "can integration and message transformation be implemented where a deployment proves that role?"

Those are compatible architecture layers, but none of them should be collapsed into another.

Source IDs: SRC-041, SRC-099, SRC-110, SRC-124, SRC-184, SRC-206, SRC-207, SRC-263, SRC-264, SRC-265, SRC-427 to SRC-430, SRC-433.