# GP Connect - Endpoint Resolution **Category:** [FHIR](https://openhealthhub.org/c/fhir/31) **Created:** 2016-06-08 14:11 UTC **Views:** 3388 **Replies:** 15 **URL:** https://openhealthhub.org/t/gp-connect-endpoint-resolution/501 --- ## Post #1 by @stuart.dunning Hi, 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_ _2. INPS_ _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. Thanks --- ## Post #2 by @dunmail 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. --- ## Post #3 by @jonny.rylands Where does the Spine service proxy fit into this? Is its role not to perform this kind of lookup and routing for you? --- ## Post #4 by @mayfield.g.kev 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) --- ## Post #5 by @matthew.stibbs 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. --- ## Post #6 by @richardmcewan 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 --- ## Post #7 by @matthew.stibbs Sounds good to me --- ## Post #8 by @adamlees And me. (Spoken with my current hat on!) --- ## Post #9 by @tony +1 for that Richard. --- ## Post #10 by @stuart.dunning That would be really useful. Cheers --- ## Post #11 by @richardmcewan not forgotten about this, will try and sort something for next week.... --- ## Post #12 by @richardmcewan 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. --- ## Post #13 by @mayfield.g.kev Sounds good. I'd prefer a system where we call something like **GET http://england.nhs.uk/fhir/Organization?identifier=|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. --- ## Post #14 by @dunmail @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? --- ## Post #15 by @mayfield.g.kev FYI Looking at GP Connect it breaks down into these parts: **Foundations** SMSP to lookup patient NHS LDAP Queries (Spine Directory Services (SDS)) for Practitioner, Organisation and Location) - **Access** Calls to GP suppliers **Security** 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. --- ## Post #16 by @richardmcewan 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 --- **Canonical:** https://openhealthhub.org/t/gp-connect-endpoint-resolution/501 **Original content:** https://openhealthhub.org/t/gp-connect-endpoint-resolution/501