Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Spine Secure Proxy

Overview of the role of the Spine Secure Proxy (SSP) to broker calls to other health and social care systems.

Spine Secure Proxy (SSP)

The Spine Secure Proxy (SSP) is a forward HTTP proxy which will be used as a front-end to control and protect access to GP principal IT systems that will be exposing FHIR based RESTful APIs as defined by the GP Connect programme. It provides a single security point for both authentication and authorisation for consuming systems. Additional responsibilities include auditing of all requests, throttling of requests and transaction logging for performance and commercial remuneration purposes.

Spine Security Proxy

Proxied FHIR Requests

For First of Type (FoT) implementations FHIR endpoint location will be performed internally by the consumer system utilising the patient’s GP organisational identifier (i.e. ODSCode as returned from a separate PDS lookup process) with the provider’s server endpoint being resolved via LDAP queries to the Spine Directory Service (SDS).

Once the provider server’s endpoint is determined using the SDS a HTTP request to the proxy server will be constructed as follows:

GET https://[proxy_server]/https://[provider_server]/[fhir_base]/[fhir_request]

A number of Spine specific HTTP headers also need to be populated with the intended spine interactionID and system ASIDs.

Header Value
Ssp-TraceID Consumer’s TraceID (i.e. GUID/UUID)
Ssp-From Consumer’s ASID
Ssp-To Provider’s ASID
Ssp-InteractionID Spine’s InteractionID

Please refer to the Spine Security Proxy Implementation Guide for full technical details.

Furthermore, the consumer’s client certificate is validated to ensure it includes valid certificate CN and DN details and that the certificate has not been added to the certificate revocation list (CRL).

Tags: design

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