Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

Spine Secure Proxy

Overview of the role of the Spine Secure Proxy (SSP) within GP Connect

Overview

The Spine Secure Proxy (SSP) is a forward HTTP proxy which is used as a broker to control and protect access to GP principal IT systems that expose FHIR based GP Connect APIs.

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.

Spine Security Proxy

Constructing a request

A consumer system queries Spine Directory Service using the provider’s ODS code to determine:

  • the provider’s service root URL (their “base endpoint”)
  • the provider’s ASID, used in headers below

Once these are retrieved, a GP Connect HTTP request is constructed to send to the SSP in the following format:

GET https://[ssp_fqdn]/[provider_service_root_url]/[fhir_request]

Where:

  • [ssp_fqdn] is the fully qualified domain name of the SSP
  • [provider_service_root_url] is the provider’s service root URL as returned from SDS in the nhsMhsEndPoint attribute. This element is normally in the format https://[provider_fqdn]/[path_to_fhir_base]
  • [fhir_request] is the local portion of the request relating to the FHIR API call being made, including query parameters

Please note GET is used as an example; the actual HTTP method will vary based on API call.

As an example, to request a patient’s structured record, the following URL would be constructed (HTTP headers and payload are not included):

POST https://testspineproxy.nhs.uk/https://pcs.thirdparty.nhs.uk/T99999/STU3/1/Patient/$gpc.getstructuredrecord

Please see a worked example of the endpoint lookup process for more information.

HTTP headers

The SSP requires a number of Spine specific HTTP headers to be populated when sending a request:

Header Value Notes
Ssp-TraceID Consumer Trace ID GUID/UUID generated per request
Ssp-From Consumer ASID Consumer system ASID; see note below
Ssp-To Provider ASID See SDS queries to lookup the provider’s ASID
Ssp-InteractionID       Spine Interaction ID         See GP Connect Interaction IDs

Further details

The Spine Core FHIR API Framework - SSP Implementation Guide describes the SSP in more depth and provides the following:

Tags: integration

All content is available under the Open Government Licence v3.0, except where otherwise stated