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.
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:
[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
nhsMhsEndPointattribute. This element is normally in the format
[fhir_request]is the local portion of the request relating to the FHIR API call being made, including query parameters
GET is used as an example; the actual HTTP method will vary based on API call.
[provider_service_root_url]portion of the above URL does not match that held in SDS (in the
nhsMhsEndPointattribute). Consumer systems must take care not to amend this portion, for example replacing the domain name with an equivalent IP address, or adding an explicit
As an example, to request a patient’s structured record, the following URL would be constructured (HTTP headers and payload are not included):
Please see a worked example of the endpoint lookup process for more information.
The SSP requires a number of Spine specific HTTP headers to be populated when sending a request:
||Consumer Trace ID||GUID/UUID generated per request|
||Consumer ASID||Consumer system ASID; see note below|
||Provider ASID||See SDS queries to lookup the provider’s ASID|
||Spine Interaction ID||See GP Connect Interaction IDs|
Ssp-Fromheader reflects the organisation from where the request originates, rather than the hosting organisation.
The Spine Core FHIR API Framework - SSP Implementation Guide describes the SSP in more depth and provides the following:
- Architectural context
- GP Connect Consuming system responsibilities
- GP Connect Provider system responsibilities