Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

Endpoint Lookup Example - SSP

Worked example of looking up a Spine endpoint from SDS for calls brokered through SSP

Worked example of the endpoint lookup process

Given A consuming system which needs to get the HTML View of a patient record at the patient’s registered practice. The consuming system has the following information about the patient:

  • NHS Number
  • A set of demographic details about the patient

When The consuming system interacts with GP Connect

Then The following steps MUST be followed:

Step 0. PDS Trace (pre-requisite step)

The Consuming system is responsible for performing a PDS Trace to both verify the identity of the patient and retrieve the ODS code of the patient’s registered primary care practice.

For this example, NHS Number 9000000084 with demographic details Mr Anthony Tester, 19 Ficticious Avenue, Testtown returns the ODS code T99999

Step 1. Accredited System Lookup on SDS

The ASID and Party Key is now looked up on SDS. The example below uses ldapsearch:

ldapsearch -x -H ldaps://ldap.vn03.national.ncrs.nhs.uk –b "ou=services, o=nhs" 
"(&(nhsIDCode=T99999) (objectClass=nhsAS)(nhsAsSvcIA=urn:nhs:names:services:gpconnect:fhir:operation:gpc.getcarerecord))" 
uniqueIdentifier nhsMhsPartyKey

This query should return a single matching accredited system object from SDS, the ASID being found in the uniqueIdentifier attribute. In the case, ldapsearch returns the following results:

999999999999, Services, nhs
dn: uniqueIdentifier=9999999999,ou=Services,o=nhs
uniqueIdentifier: 999999999999
nhsMhsPartyKey: T99999-9999999

# search result
search: 1
result: 0 Success

Step 2: MHS lookup on SDS to determine FHIR endpoint Server Root URL

Using the Party Key retrieved from Step 1, and the same interaction ID, the following ldapsearch query is executed:

ldapsearch -x -H ldaps://ldap.vn03.national.ncrs.nhs.uk -b "ou=services, o=nhs" 
"(&(nhsMhsPartyKey=T99999-9999999) (objectClass=nhsMhs) (nhsMhsSvcIA=urn:nhs:names:services:gpconnect:fhir:operation:gpc.getcarerecord))" 
nhsMhsEndPoint nhsMHSFQDN

This query should again return a single endpoint. In this case, the ldapquery returns the following results:

# 472b35d4641b76454b13, Services, nhs
dn: uniqueIdentifier=472b35d4641b76454b13,ou=Services,o=nhs
nhsMhsEndPoint: https://pcs.thirdparty.nhs.uk/T99999/DSTU2/1
nhsMHSFQDN: pcs.thirdparty.nhs.uk

# search result
search: 2
result: 0 Success

Step 3: Consumer constructs full GP Connect request URL to be sent to the Spine Security Proxy

The format of the full URL which the consuming sytem is responsible for constructing is as follows:

https://[URL of Spine Security Proxy]/[Provider Server Root URL]/[FHIR request]

The value returned in the nhsMhsEndPoint attribute in Step 2 should be treated as the FHIR Server Root URL at the provider system.

In this example, to issue a GetCareRecord request, the following request would be made:

POST https://testspineproxy.nhs.domain.uk/https://pcs.thirdparty.nhs.uk/T99999/DSTU2/1/Patient/$gpc.getcarerecord

Provider System Viewpoint

Please refer to Registering provider endpoints for details of requirements for systems wanting to register an API endpoint for consumers to call through the SSP

Tags: design

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