How GP Connect works

GP Connect enables approved health and care systems to exchange information held in GP records. Different GP Connect products use different technical approaches to retrieve, share or update that information.

This page provides a high-level explanation of how GP Connect works, including the different architectural patterns used by its products and the national services that support information exchange.

Integration and implementation
Guidance, APIs and approaches for integrating the service

GP Connect is an intermediary service – it allows multiple 'consumers' to connect to multiple 'providers' to share information.

The 'providers' are the IT systems in GP practices that hold registered patients' records - care details, documents, appointments, prescriptions and more.

The 'consumers' are the point-of-care applications in other care settings, or patient-facing applications, that want to either retrieve or update the patient information.
 

How this all works technically depends on which of the GP Connect products is being used. We call the different methods 'architectural patterns', and the following table summarises which pattern applies to each GP Connect product:

This pattern applies to the following GP Connect products:

• Access Record: HTML
• Access Record: Structured
• Access Record: Access Document
• Appointment Management

In summary, it works like this:

1. The consumer system uses the patient's NHS number to retrieve their registered GP from the Personal Demographics Service (PDS), as an ODS organisation code.
2. The consumer system uses the registered GP ODS code to look up the HTTP 'endpoint' for the registered GP IT system (the 'provider' system), for the relevant GP Connect product.
3. The consumer system calls the Spine Secure Proxy (SSP), passing the details of the patient (NHS number) and the provider endpoint.
4. SSP routes the request to the provider system endpoint.
5. The provider system processes the request and provides an HTTP response with the information requested back to SSP.
6. SSP sends the HTTP response back to the consumer system.

For technical details on how to integrate using this pattern, as either a provider or a consumer, see the relevant API specification.

This pattern applies to the following GP Connect products:

• Update Record
• Send Document

In summary, it works like this:

1. The consumer system sends a message containing the information to update to MESH. The message is structured as per the relevant GP Connect FHIR message specification, and the message header includes a specific MESH 'workflow ID' to indicate that this is a GP Connect message, as well as the patient's NHS number, date of birth and surname.
2. MESH recognises that the message requires 'automated message routing', based on the workflow ID.
3. MESH uses the patient's NHS number to get their demographic details from PDS, including their date of birth, surname and registered GP.
4. MESH verifies the patient's NHS number against their date of birth and surname.
5. MESH uses the registered GP to determine the destination mailbox - the relevant provider system.
6. The provider system periodically polls MESH for new messages and retrieves the message.
7. The provider system processes the message and makes the appropriate update.

For technical details on how to integrate using this pattern, as either a provider or a consumer, see the relevant API specification.

This pattern applies to the following GP Connect products:

• Access Record (Patient Facing)
• Prescriptions (Patient Facing)
• User Permissions (Patient Facing)

In summary, it works like this:

1. The consumer system calls the relevant GP Connect API, hosted on our API platform, including the patient's NHS number and any other relevant information.
2. The GP Connect API uses the patient's NHS number to retrieve their registered GP from the Personal Demographics Service (PDS), as an ODS code.
3. The GP Connect API uses the registered GP ODS code to look up the HTTP 'endpoint' for the registered GP IT system (the 'provider' system), for the relevant GP Connect product.
4. The GP Connect API routes the request to the provider system endpoint.
5. The provider system processes the request and provides an HTTP response with the information requested back to the GP Connect API.
6. The GP Connect API sends the HTTP response back to the consumer system.

For technical details on how to integrate using this pattern, as either a provider or a consumer, see the relevant API specification.

• What GP Connect does
• When to use GP Connect
• Service availability
• Implementation and integration