GP Connect - Endpoint Resolution

(stuart.dunning) #1


Reading through the FHIR implementation guide I noticed the following about Endpoint Resolution.

Endpoint Resolution
Clients SHALL perform a sequence of query operations against existing Spine services to enable FHIR endpoint resolution.
1. Clients SHALL perform (or have previously performed) a PDS lookup for a patient.
1. Using the PDS results the client SHALL determine the patient’s primary GP organisation.
2. Clients SHALL perform (or have previously performed) a SDS lookup using the ODS code of the patient’s primary GP organisation.
1. Using the SDS results the client SHALL determine the Principle GP system responsible for hosting the most up to date GP care record.
1. EMIS Health
3. Micotest
4. TTP
3. Clients SHALL construct a FHIR Service Root URL suitable for access to a GP vendor’s FHIR server.
TODO: check if this is correct or if we will be resolving the endpoint from Spine using some other mechanism.

I am wondering why there is the need to perform mandatory SDS and PDS lookups? If you have alternative ways of identifying this information would this not be sufficient?

Any information on this would be appreciated.


(dunmail) #2

Agreed - it seems perverse to mandate PDS/SDS lookups when in may use cases alternatives would be more than sufficient.

I believe that a national record locator service is under consideration; this would be a more natural complement to GP Connect.

(Jonny Rylands) #3

Where does the Spine service proxy fit into this?

Is its role not to perform this kind of lookup and routing for you?

(Kev Mayfield) #4

Agreed, PDS lookup is part of another process for us but would have already been called as part of an episode or encounter. (We’ll be spine connected shortly, so PDS call will be phased out)

Presume the SDS LDAP is being changed to include GP system details? Thats going to be slowly changing data and should be cached locally. (We would already have ODS code for patient)

(Matt Stibbs) #5

I think a national record locator service is key to this - there will be systems wanting to utilise this interoperability for which requiring a spine connection will be a significant barrier.

(Richard McEwan) #6

I think it may be worth us at HSCIC dropping out a few slides on the endpoint lookup piece and how it aligns with record locator to clarify a few things. Happy to arrange a webex for discussion if easier

(Matt Stibbs) #7

Sounds good to me

(adamlees) #8

And me. (Spoken with my current hat on!)

(tony) #9

+1 for that Richard.

(stuart.dunning) #10

That would be really useful. Cheers

(Richard McEwan) #11

not forgotten about this, will try and sort something for next week…

(Richard McEwan) #12

Sorry, been on holiday and not scheduled anything in. Might be worth just quick clarification of what we have in plan and then can follow up with a session as required.

We are looking at various mechanisms for endpoint resolution. First mechanism uses existing capabilities in SDS to resolve an end point (which are described in the current spec). Obvious choice to start with as its existing and fairly straightforward. We are planning to develop a smarter interface for end point resolution and this also brings in record locator functionality (which we are also looking at). We want to have a more sophisticated end point resolution service following the initial deployments.

We have also developed (for the GetCareRecord API) an auto resolve within the Spine Security Proxy based on patients NHS number and resolving that to the registered GP practice on PDS. Clearly some limitations to that e.g. only GP and breaks if multiple endpoints are exposed per practice - but for the GP record we feel its a useful piece of functionality.

We are requiring that consuming systems have a traced NHS number, obtained via direct PDS integration or use of Spine Mini Service. To simplify this process even more we are looking at developing a FHIR API into PDS with the view we can make API interactions as seamless as possible.

Welcome your views and input into this area - we will be doing a wider bit of engagement when we start to look at the new endpoint, PDS and other lookup services over the coming few months . One thing we want to do with any new service is to make it as simple as possible to access national services including the accreditation process.

I hope this helps.

(Kev Mayfield) #13

Sounds good.

I’d prefer a system where we call something like GET|RWY and this returns details on the organisation and it’s endpoints (as extensions) (RWY is the SDS/ODS organisation code). This could be a facade on top of SDS or we could just use a LDAP query instead.

(dunmail) #14

@richardmcewan: Black Pear are involved with the SMSP pilot (Royce Neagle is the NHS-Digital PM). Our strategy is to create a FHIR facade for SMSP - as there is obvious overlap with the plan you’ve outlined above, would there be value in collaborating on this?

(Kev Mayfield) #15

FYI Looking at GP Connect it breaks down into these parts:


SMSP to lookup patient
NHS LDAP Queries (Spine Directory Services (SDS)) for Practitioner, Organisation and Location) -


Calls to GP suppliers


Certs and tokens

I’m pushing for us to develop FHIR facades (ideally as open source) to SDS/LDAP and calls to GP suppliers (HAPI FHIR + Apache Camel/ServiceMix). Probably use Spring Security to lock down our facades but this will be specific to us.

(Richard McEwan) #16

absolutely. Worth getting Richard K involved as I know his team did some PoC work around this area which we were going to use. I’ll ask Richard to drop you some details and we can take it from there