GP2GP Requesting Adaptor: Introduction updated

The GP2GP Requesting Adaptor is designed to allow a System Supplier who does not have GP2GP HL7 and instead uses GP Connect - Access Record Structured API v1.6.0 GP Connect Access Record Structured to request an Electronic Health Record (EHR) from a System Supplier using GP2GP HL7. Specifically, this uses ‘Migrate a Patient’s structured record' and ‘Migrate a document’.

GP2GP Requesting Adaptor: Requirements updated

Requirement ID

Requirement Text

Level

GP2GP_Req_34

As soon as the Requesting System has posted the GP C 1.6 migratestructuredrecord request to the Requesting Adaptor GPC API Facade endpoint URL it should receive a 202-accepted response. This means the adaptor has received the request and is validating and making the relevant requests. The Requesting System now begins to poll the endpoint for a response. Polling details are set out in Step 14.

MUST

GP2GP_Req_75

All problem links, where possible, are to be retained. Further information can be found in the GP Connect Linkages ‘Linkages’ page.

MUST

GP2GP_Req_79

The Requesting System flags any current medications that have been degraded on import into the active record so that clinicians can re-code any that are clinically appropriate.
Further information can be found in the GP Connect Medication Guidance ‘Medication Guidance’ page.

MUST

GP2GP_Req_80

Where any Drug Allergies have been degraded on import into the active record, the Requesting System flags these and prevents the prescribing of any medication for the Patient until the degraded items have been either re-coded or removed from the record.
Further information can be found in the GP Connect Allergies Guidance ‘Allergies Guidance’ page.

MUST

GP2GP Requesting Adaptor: Dependencies updated

There may be dependencies for implementing this Standard, however, there are no Interoperability Standards within the Capabilities and Standards model that are dependents.

Creating a compliant implementation requires implementing the following dependent interface Standards:

• GP Connect Access Record Structured - Refer to ‘Migrate a Patient’s structured record' and ‘Migrate a document’ for more information

GP2GP Sending Adaptor: Introduction updated

The GP2GP Sending Adaptor is designed to allow a System Supplier using GP Connect - Access Record Structured API v1.6.0 GP Connect Access Record Structured as a Provider to send a requested Electronic Health Record (EHR) to a System Supplier using GP2GP HL7. Specifically, this uses ‘Migrate a Patient’s structured record' and ‘Migrate a document’.

GP2GP Sending Adaptor: Requirements updated

Steps 2 and 3 are requirements from the GP Connect 1.6 specification but listed here for completeness. Full details on this can be found on their developer page GP Connect - Access Record Structured API v1.6.0 GP Connect Access Record Structured.

Steps 14 and 15 are Sending System requirements specific to this process that sit outside of GP Connect, the GP2GP Adaptor and the Requesting System and are numbered for reference.

Step 1 (GP2GP Adaptor - GP Connect ‘Migrate Record’ request)

The GP2GP Sending Adaptor will receive the HL7 request from the Requesting Site. It will convert this to a FHIR migrate structured record request as documented in GP Connect ‘Migrate a Patient’s structured record'. here:

Migrate a Patient’s structured record | gpconnect

It will now make a call to the Sending Systems GP Connect Provider endpoint to retrieve the FHIR record bundle.

Should the HL7 request not be well formed or fail to convert to a FHIR migrate structured record request, the GP2GP Sending Adaptor will send a negative acknowledgment to the Requesting Site indicating a total failure. The GP2GP Sending Adaptor will send the following error to the Requesting Site.

Step 2 (GP C Provider - Identity checks)

The Sending Systems GP Connect 1.6 Provider solution will receive the Migrate Structured Record request and as per the GP Connect 1.6 requirements:

The providing system MUST check that the ODS code supplied in the requesting_organization claim in the JWT matches the Patient’s registered practice on PDS.

If this check fails (i.e. the Requesting Site is the not the Patients registered practice on PDS), or it can not complete this action, or the Patient is not registered at the Sending Site, the Sending Sites GP Connect Provider 1.6 solution will provide one of the following error responses and the the GP2GP Sending Adaptor will translate this and send a HL7 negative acknowledgment with the relevant error code:

Step 3 (GP C Provider - Checks request well formed)

If the previous step was successful the Sending Systems GP Connect 1.6 Provider must now determine if the GP Connect request (migratestructuredrecord) sent from the GP2GP Sending Adaptor is well formed and it can respond successfully. If it is not, one of the following error codes will be provided to the GP2GP Sending Adaptor dependent on the issue that the GP2GP Sending Adaptor will translate to the relevant HL7 error.

Step 4 (GP2GP Adaptor - Retrieves FHIR record bundle)

If the above checks are successful the Patient's full FHIR record bundle (EHR) will retrieved via the Sending Systems GP Connect API and sent to the GP2GP Sending Adaptor, as documented in GP Connect 'Migrate a Patient’s structured record'.

Migrate a Patient’s structured record | gpconnect

This will include the Document Reference resources as described in GP Connect ‘DocumentReference’.:

DocumentReference | gpconnect

These represent the Patient’s documents and must include any references where it is known the document can not be returned (there is no corresponding URL as the document was either too large, over 100mb, or not found).

Step 5 (GP2GP Adaptor - Migrate documents)

Once the GP2GP Sending Adaptor has received the Patients FHIR record it must identify and find all the Patients documents using the supplied URLs. It will then make a ‘Migrate a Document’ call from the Sending Systems GP Connect 1.6 Provider solution for each identified document. See GP Connect ‘Migrate a Document’ for more information.

Migrate a document | gpconnect

For any document it can not retrieve (receives an error - RECORD_NOT_FOUND) the adaptor must create a GP2GP HL7 .txt placeholder file as described in Step 6.

GP2GP Sending Adaptor: Dependencies updated

There may be dependencies for implementing this Standard, however, there are no Interoperability Standards within the Capabilities and Standards model that are dependents.

Creating a compliant implementation requires implementing the following dependent interface Standards:

• GP Connect Access Record Structured - Refer to ‘Migrate a Patient’s structured record' and ‘Migrate a document’ for more information

GP2GP FHIR Implementation

For Suppliers of new Solutions and Solutions that have implemented the GP2GP FHIR Implementation:

A risk-based assurance to be followed by all New Foundation Solution Suppliers (NFSS).

• Technical Assurance - The Suppliers need to demonstrate that the GP2GP Sending Adapter and GP2GP Requesting Adaptor are successfully integrated and technically assured through a specific set of Technical risks.

• E2E Solution Assurance - The Suppliers need to demonstrate that the GP2GP FHIR Implementation Solution meets the E2E functional interoperability requirements through a set of Clinical and Technical risks covering the below high-level scenarios:

  • NFSS as a winning Practice

  • NFSS as losing Practice

  • Pathways assurance from NFSS to Incumbent all other live GP Core Clinical Solutions

  • Pathways assurance from Incumbents all other live GP Core Clinical Solutions to NFSS Solutions

  • Export of data from NFSS Solutions

Suppliers must contact Solution Assurance team through the Tech Innovation mailbox (gpit.techinnovation@nhs.net) to arrange a witness testing slot to provide evidence. Successful completion of the witness testing and evidencing will constitute compliance against this Roadmap Item.

An Assurance Statement will be provided when a supplier completes their testing and assurance related activities. The report will be used as the readiness for further onboarding stages and progression to Live assurance.

GP2GP FHIR Implementation

For Suppliers of new Solutions and Solutions that have implemented the GP2GP FHIR Implementation:

• GP2GP Requesting Adaptor

• GP2GP Sending Adaptor

• Personal Demographics Service (PDS) - using FHIR API

• Spine Directory Service - FHIR API

• GP Connect - Access Record Structured API v1.6.0 GP Connect Access Record Structured - Refer to ‘Migrate a Patient’s structured record' and ‘Migrate a document’ for more information

• GP Registrations Management Information API