GP Connect Access Record: HTML - FHIR API

Use this API to view a patient's registered GP practice record, with read-only access.

You can:

• view a patient’s primary care record by requesting sections or headings
• define a date range to filter larger sections
• incorporate these views directly into Electronic Patient Record systems

For example:

• GP practices can view all of the patient’s primary care records even when they are held on a different GP system
• care settings such as NHS111, ambulance and emergency care, primary care networks (PCNs), secondary care, pharmacy, care homes, community and dentistry can view the records held by the patient’s GP practice to better inform any care decisions they make for a patient

For more details, see the GP Connect specifications for developers.

This API can be used by developers of clinical systems that support clinicians delivering direct care.

Before you start development, read the GP Connect API v0.7.4 specification and the prerequisites listed below.  

Prerequisites

Technical

You must:

• have access to the Health and Social Care Network (HSCN)
• be Personal Demographics Service (PDS) compliant or capable of performing a PDS search via our web pages or a third-party provider

Information governance (IG)

You must:

• be compliant with the GP Connect Direct Care API Information Governance Model
• manage access to your system locally using local role-based access control (RBAC). This does not need to be compliant with the national RBAC model and GP Connect products do not require smartcards to control access, though they can be used if already implemented

• be using the GP Connect APIs for direct care purposes for NHS patients in England

Clinical safety

You must:

• have a clinical safety officer (CSO) who is responsible for DCB0129 and, if necessary, DCB0160 . For more on clinical risk management, visit Clinical risk management standards

If you are confident that you can meet the prerequisites, contact us to express your interest. See 'Onboarding' below.

The following APIs are also related to this API:

• GP Connect Access Record: Structured - FHIR API – use this API to retrieve structured information from a patient’s GP practice record
• Personal Demographics Service - FHIR API  – use this API to look up the registered GP for the patient
• Spine Directory Service - FHIR API  – access accredited system information and messaging endpoint details

This API (v0.7.4) is in production.

It might not be fully supported by all providing systems. See GP Connect supplier progress for details of provider rollout.

This API is a silver service, meaning it is operational 24 hours a day, 365 days a year but only supported during business hours (8am to 6pm), Monday to Friday excluding bank holidays.

For more details, see service levels.

This API is a FHIR API. 

It sends a FHIR DSTU2 payload over a Spine Server proxy (SSP) transport.

For more details, see FHIR.

You need a Health and Social Care Network (HSCN) connection to use this API.

For more details, see Network access for APIs.

Security

Access to the GP Connect APIs is controlled and protected by the Spine Secure Proxy (SSP), a forward HTTP proxy.

It provides a single security point for both authentication and authorisation for consuming systems. Additional responsibilities include auditing of requests, checking data sharing agreements and transaction logging.

All HTTP communications are secured using TLS MA. This includes both legs of the request, from consumer system to the proxy and then from the proxy to provider system.

Authorisation

Authorisation takes place in two locations: 

• the consumer system
• the SSP

The consumer system must have local RBAC in place and restrict GP Connect APIs to authorised users. With each request, a JSON Web Token (JWT) must be included with the following information:

• details of users, including role
• where smartcards are used in the consumer system, including SDS user and role IDs
• details of the consumer system
• details of the consumer’s organisation, including ODS code

The information in the JWT is retained for audit purposes.

The SSP checks data-sharing agreements to ensure that the consumer system is authorised to communicate with the provider system.

Expressing an interest

If you meet the prerequisites and have a product that can integrate with GP Connect, you should express an interest with us by submitting a use case.

The main purpose of the use case is to help us understand how you plan to use GP Connect APIs and the business issue you are looking to address. Submit your use case to us by completing a use case submission form.

Once we receive your use case, we'll respond within 14 days.

Consumer assurance process

Once we approve your use case, we support you through the assurance process to go live. We will discuss the assurance process and artefacts with you to help you understand our requirements.

Start your development work within 6 months of use case approval. If you miss this date, a review or new submission of the use case will be required. Changes or additional development will also require a review or new use case submission. 

For a full list of interactions for this API, see GP Connect API v0.7.4.

For details on the general structure of the interactions, see FHIR.