GP2GP Requesting Adapter

Last substantive research: 25 September 2026. NHS sources usually spell the name GP2GP Requesting Adaptor; repository names also use Patient Switching and the parent API catalogue uses Receiving Adaptor.

The adapter lets a receiving GP system request an existing patient's record from a practice using legacy GP2GP HL7 V3 and receive the result as GP Connect-style FHIR. It is a bridge within a registration-and-record-transfer workflow. It is not a complete GP clinical system, a shared-care viewer, or evidence that an InterSystems product has implemented GP2GP. The GP2GP Record Transfer parent retains the four-nation comparison.

Read-only Access and Registration

The supported use is record transfer following permanent GP registration. The adapter returns FHIR data and document references; it does not supply a viewer or an ongoing read-only query of the previous practice's record. A receiving application could display transferred data read-only, but that presentation choice does not replace the required integration and acknowledgement workflow.

Question	Answer
Can it provide the full record for viewing without changing GP registration?	A different requesting practice cannot obtain the record through a conforming sender while PDS still names the existing practice: the sender must reject that mismatch with NACK 19. For approved direct-care viewing while registration remains with the existing practice, assess GP Connect Access Record: HTML.
Does the adapter move or “pull” registration?	The receiving GP system owns registration. For a new transfer, it stores the previous GP details, updates PDS to the new permanent registration, waits for success, and then requests the record through the adapter. A failed PDS update stops that process.
Does it look up the patient's current registered GP?	That is a PDS lookup performed by the consuming/receiving system. SDS supplies the relevant system addressing. The adapter is not a substitute for the registration and demographic workflow.
Does “full record” guarantee every item?	It means the transferable GP record, subject to source content, mappings, degrades and missing-document placeholders. It does not mean all records across the NHS, guaranteed original attachments, or a continuously refreshed view. See Clinical Content and Translation Limits.

The registration sequence follows S94 requirements 1, 10 and 18–20; the read-only alternative is defined by the NHS HTML API catalogue. HTML sections/provider coverage and Access Document retrieval need separate assessment against the required view. An existing transfer's resend is not a new registration.

Technical enforcement occurs at the sending system. S94 Step 10 requires the sender to query PDS before releasing the EHR and return response code 19 if the requesting practice is not the patient's current registered GP. The adapter's documented validation and migration call are separate from the receiving system's PDS update, but omitting that update does not bypass the sender's check. An initial 202 Accepted only acknowledges adapter processing; it does not prove the sender will release the record. If PDS already names the legitimate requesting practice, this particular check does not require a fresh registration change, as in an existing transfer's retry/resend; that is not a general third-party viewing route. This is the specified protocol behaviour, not an executed test against a live supplier.

Current Status and Version Boundaries

These are different evidence layers, checked on the research date:

Layer	Verified position	How to use it
NHS Requesting Adaptor catalogue	In development; page edited 17 February 2026.	Preserve the published maturity label. Approval is required before a supplier's software goes live.
Requesting standard S94	1.0.2, effective 22 October 2025; canonical page updated 22 July 2026.	Current requirements baseline, not a software release number.
GP2GP standard S43	6.0.1, effective 4 December 2025.	Distinguishes existing HL7 implementations from new/FHIR solutions.
GP Connect dependency	S99 1.0.4; its current guide identifies 1.6.2, FHIR STU3.	Do not substitute UK Core R4 or treat an old 1.6.0 reference as the current contract.
Repository maintenance	Latest changelog entry verified: 3.3.1, 1 June 2026.	Latest published image, digest, release tag and current HEAD were not independently verified.
Adjacent services	GP2GP is live; the Sending Adaptor is separately labelled production beta.	Neither proves this Requesting Adaptor's live deployment or support baseline.

Sources: Requesting catalogue, S94, S43, current GP Connect guide, changelog, and Sending catalogue.

There is no contradiction in an effective standard coexisting with a development-labelled implementation: they describe different objects. However, the catalogue label, repository releases and NHS component-assurance statement do not establish one unambiguous production baseline. This remains an evidence gap.

Relationship to GP Connect and the Sending Adapter

GP2GP describes the practice-move transfer; GP Connect supplies migration operations used by its FHIR implementation. Distinct service purposes do not mean technically independent protocols. RM290 removed fixed GP Connect version references from the adaptor standards and made the Access Record Structured standard control that dependency.

Situation	Role
New receiving system needs a record held by a legacy HL7 GP2GP sender	Requesting Adapter: initiates the HL7 request and translates the returned record into FHIR.
FHIR-based sending system must serve a legacy HL7 GP2GP requester	Sending Adapter: retrieves the FHIR record/documents and produces the legacy response.
Approved third-party direct-care access, document submission or structured update	Separate GP Connect capabilities and assurance scopes; ordinary consumer status does not establish GP2GP migration support.

The implementation README explains why the requesting bridge exists: a new entrant can receive a legacy sender's record without requiring that sender to adopt the newer GP Connect migration interface first.

Transfer Architecture

The following is a synthesis of the repository's getting-started architecture, not a verified customer deployment.

flowchart LR
    GP[Receiving GP clinical system] -->|Start and poll| F[API facade]
    F --> Q[AMQP work queue]
    Q --> T[Translator]
    T -->|EHR request| M[MHS and Spine]
    M --> O[Previous GP system]
    O -->|HL7 record and attachments| M
    M -->|Inbound queue| T
    F <--> DB[(PostgreSQL state)]
    T <--> DB
    T --> S[(Attachment storage)]
    F -->|FHIR Bundle| GP
    S -->|Documents| GP
    GP -->|Integration acknowledgement| F

The facade and translator are separate Java/Spring Boot containers. The facade queues work; the translator handles asynchronous GP2GP messaging and conversion. Both use PostgreSQL. MHS is a separate messaging component with its own state storage. Do not copy the sending-adapter diagram's GP Connect Consumer/MongoDB dependencies into this requesting stack.

Registration and Responsibility Split

The GP system owns patient registration, user workflow and clinical filing. The adapter owns the bridge. From S94: permanent registration qualifies; an authorised user selects the PDS match, retains the previous practice before updating PDS, and resolves its GP2GP ASID through SDS. Sensitive-patient and failed-registration paths need separate handling. Missing SDS addressing stops the request; missing ODS contact details alone does not.

The operational implication is that installing containers cannot supply the missing registration, demographic reconciliation, clinical record, prescribing, user-task or support functions. A solution design must allocate each of those to a named component and owner.

Facade API and Transfer State

The documented repository contract describes the following. This is an internal supplier-hosted API, not a public NHS endpoint to call without onboarding.

Operation	Contract and interpretation
Start transfer	`POST /Patient/$gpc.migratestructuredrecord` with FHIR JSON Parameters, `patientNHSNumber`, full-record selection and the sensitive-information parameter.
Address and correlate	ASID and ODS headers identify both practices. Retain `ConversationId`, generated by the adapter if omitted, throughout the transfer.
Accepted	Initial HTTP `202` means accepted for asynchronous processing; it does not mean that the record is received, validated or filed.
Poll	Repeat the migration call using the same conversation. `204` means pending; `200` returns the FHIR Bundle. Use the assurance-agreed polling schedule rather than a tight retry loop.
Failure	The README documents `400`, `404`, `500` and `501` with OperationOutcome. Validation also has standard-specific media/body errors; an HTTP code alone is not a sufficient clinical workflow decision.
Final acknowledgement	`POST /$gpc.ack` with the same conversation and `ConfirmationResponse` of `ACCEPTED` or `FAILED_TO_INTEGRATE`. Successful retrieval and integration must precede success acknowledgement. The README documents `200` success and retryable `500`; migration must first have returned `200`.

Resolve the header discrepancy before implementation. The README assigns TO-* to the old/losing practice and FROM-* to the new/winning practice. S94 requirement 30 describes those roles in reverse. Examples also differ in parameter spelling/capitalisation. This wiki deliberately supplies no copy-and-paste payload: confirm the supported build's contract through NHS assurance and an end-to-end test, rather than choosing one example silently.

The 2025 resend uplift requires support for a sender's resend using the failed transfer's existing conversation, and preservation of original codes for future transfers. The changelog records corresponding resend work. A resend is not automatically a new patient registration or a new independent transfer.

Clinical Content and Translation Limits

The mapping repository contains both directions. For this adapter, use the HL7 XML-to-FHIR JSON sections. It covers consultations, problems, observations/results, allergies, immunisations, medicines, referrals, documents and contextual resources using STU3 CareConnect-GPC profiles. Listed mappings are design evidence; they are not a test report for a proposed release.

Area	Verified mapping or requirement	Consequence for a receiving solution
Patient identity	Patient mapping includes the NHS number but explicitly leaves several demographics unmapped.	Reconcile demographics through the authoritative registration/PDS workflow; do not reject or overwrite them merely because a transfer Patient is sparse.
Clinical codes	CodeableConcept mapping carries codes/translations, recognised coding systems and local terminology lookups.	Preserve source code, display, system and provenance. Mapping is not proof of universal semantic equivalence.
Medicines	MedicationStatement mapping uses `taken=unk` and may supply fallback dosage text; some fields are unmapped.	Do not infer adherence or complete prescribing intent from defaults. Verify linked medication/request resources and clinical presentation.
Attachments	DocumentReference mapping points to adapter file storage; missing-original placeholders also have URLs.	A nonempty URL does not prove the original document exists. Distinguish placeholders from usable attachments.
Degraded medicines and allergies	RM290 retains requirements to flag degraded current medicines and prevent prescribing until degraded drug allergies are resolved.	These are receiving clinical-system controls, not something a successful FHIR response proves.
Original codes and return transfers	RM261 adds preservation of historical/source coding.	Include round-trip and A–B–A cases in validation, alongside the terminology governance model.

S94 also sets important receiving-system timings: unresolved document retrieval after one hour needs a placeholder and user follow-up; the sender does not automatically know. Automatic integration is due within 20 minutes of receipt, without partial filing or loss of concurrent work. Unresolved integration after 72 hours requires a failure acknowledgement. These are different clocks, not a single transfer timeout. Returning records require reconciliation; resends must preserve newer local entries.

Imported active repeats must be deactivated for clinical re-authorisation. Automatic filing does not complete medication/degrade review. The interaction between the one-hour attachment window and twenty-minute integration target needs an agreed interpretation of receipt and exceptions.

For A–B–A returns, S94 uses the local patient index and existing permanent record, with additions identified by their entry date since departure. Retain the received extract and integration audit. Mandatory safety tasks cannot be deleted/archived; the local reviewed/unreviewed indicator must not travel onward. S94 also prohibits a per-attachment size cap; this requirement is separate from proving adequate infrastructure capacity.

S94's audit-retention interval is inconsistent: “four” further years is labelled years 4–10. Obtain NHS clarification before setting retention policy. Detailed responsibilities remain in requirements 41–103; this research summary is not the implementation specification.

The linked structured-degrade supplementary specification is an approved 2006 document. It preserves degraded record types and structure on onward transfer, keeps allergies as allergy records and prevents issue of degraded medication. Its older original-code exception must be read alongside the later code-preservation uplift; it is not permission to discard codes now.

Redactions and Release-Specific Behaviour

The changelog records confidentiality propagation and redaction fixes, including Observation fixes in 3.1.1 and DocumentReference propagation in 3.1.2. Later changes include blood-pressure deduplication, prescription mapping, skeleton matching and Condition/practitioner details. These are reasons to pin and test a release, not evidence that every resource and downstream screen now preserves restrictions.

A meaningful acceptance test should compare source content with imported content and subsequent onward transfer: coded meaning, provenance, links, attachments/placeholders, restricted data, medicine/allergy tasks and acknowledgements. This is the wiki's assurance synthesis, not a claim that those tests have been run.

Hosting, Security and Operations

The NHS implementation is published under MIT/OGL licensing. Its setup documentation describes PostgreSQL schema migration and SNOMED import, an AMQP 1.0 broker, attachment storage, MHS connectivity, SDS configuration and the translator/facade connection. Development instructions specify JDK 21, Docker, local mocks and Path to Live smoke testing.

MHS setup includes an HSCN-reachable inbound address, NHS FQDN, certificates/private key, party key, SDS registration and trusted certificates. The underlying GP2GP API also places authentication and RBAC obligations on the calling solution. These controls must be designed at the correct boundary; the existence of the facade does not establish authentication on it.

Operational decision	Evidence to establish for the selected deployment
Supported build	Approved image digests, paired facade/translator versions, database migrations, terminology release and upgrade/rollback plan.
Availability	Monitoring of queues, translator, facade, MHS, database and storage; an owner for stalled transfers and failed clinical filing.
Failure recovery	Agreed timeout/retry/resend behaviour, duplicate handling, dead-letter recovery, final acknowledgement and user escalation.
Data protection	Access to stored records/documents, storage-link lifetime, encryption, backup, audit, deletion and restoration controls.
Clinical continuity	A usable fallback for missing records/documents, reconciliation tasks and evidence that fallback is closed when the record arrives.

These questions specialise the existing GP2GP proof checklist; they are not an additional certification scheme. Published performance examples are environment-specific benchmarks, not a service-level commitment. Removal of an older processing-size limit in the changelog does not establish unlimited record capacity.

Version 3.0.0 also removed incoming attachment MIME allowlist checking. If a deployment requires attachment-type screening, allocate and test that control explicitly rather than assuming the adapter provides it.

The research could verify setup and changelog documents, but not the full operating, component-failure or redactions documents through the available retrieval routes. Consequently storage retention defaults, URL expiry, complete retry/error policy and production logging controls remain unverified. No adapter was installed, run against NHS infrastructure or tested with patient data in this research pass.

Management Information and Fallback

The GP Registrations Management Information API reports registration and transfer lifecycle events, including receipt, integration, errors and degrades. It replaces the older weekly GP2GP MI submission over MESH; MI reporting is separate from the clinical payload and is required by S43 for the applicable supplier groups.

Current GP2GP service guidance allows digital NDR fallback for a summary and attachments as well as paper backup. Orphaned Record Continuity is live for eligible records it holds after practice closure. Neither establishes this adapter's ORC routing support, and neither justifies saying every failed or orphaned transfer is now handled electronically.

S94 distinguishes fallback by failure class: sender extract-generation failure (NACK10) and signalled integration failure (NACK11) trigger paper handling. Sender NACKs 06/07/18/19/24/99 and several adapter timeout/reassembly failures do not automatically do so. Receiver-created attachment placeholders require contact with the sender. Support workflows must retain that distinction.

Assurance and InterSystems Relevance

R9 onboarding v2.7.0, updated 18 September 2026, describes NHS-developed/assured components and a Tailored Assurance Approach for the integrating solution, covering technical and clinical activities. Suppliers may build their own adapters with additional assurance. The Supplier Manager allocates an assurance lead; obtain the current toolkit from that route. The page is not the whole DSIC contracting process.

For an InterSystems-backed architecture, a plausible arrangement is a GP foundation application calling the NHS facade, with Health Connect/IRIS handling explicitly allocated integration tasks. That is an architectural inference. A native InterSystems FHIR server, HL7 engine, HealthShare record, or GP Connect consumer row does not prove implementation of this contract, receiving-system clinical controls or NHS approval.

The Defence boundary is especially material: S94 uses a Defence Medical Services practice without a GP2GP ASID as an example of a route that cannot proceed. That is a specification scenario, not a current survey of all DMS/DMICP endpoints. This adapter alone cannot establish DMICP/CORTISONE interoperability or a cross-border transfer service.

Adjacent deployment evidence is also narrower than it first appears. Medicus's GP2GP workflow guide describes inbound/outbound transfer and retry functions. It does not name this adapter's build, hosting or any InterSystems GP2GP role. The repository's Medicus-labelled performance tests likewise do not prove a particular live deployment.

Research Limits and Implementation Gate

The direct evidence now explains the adapter's purpose, lifecycle, standards dependencies, documented interface, mapping design and assurance route. Before proposing a deployment, resolve the bounded validation items: supported release/maturity, header contract, retention wording, operational defaults, ORC handling and named deployment proof. Exact current repository HEAD and image digests were unavailable; cached release and newer changelog views differed.

There is also an apparent editorial error in the NHS Requesting catalogue: one bullet gives the sending conversion direction. The page introduction, requesting standard and repository agree on returned HL7 V3 → FHIR, which is the direction used here.

No current public evidence reviewed establishes an InterSystems Requesting Adapter implementation. That finding is bounded to the sources searched; it is not evidence that no private implementation exists.