There is no separate onboarding process for the SDS FHIR API. Onboarding is determined by the current process of the API that consumes the SDS FHIR API, for example GP Connect. Once you have approval to use the API that consumes the SDS FHIR API, then we grant SDS FHIR API production access.
Hi Mick, your answer suggest that the SDS FHIR API is not available to consume directly, i.e. in isolation of the use of another API. That’s surely not correct is it? After all the existing LDAP service is readily available for all to use. Or have I just misunderstood your anwer? TIA.
The overview Mick shared suggests so. also, a valid use case is required to onboard,
It’s a good question, Paul, so we’ve reached out to the owning team for some further clarification on use of the two SDS APIs (FHIR and LDAP).
I think we can probably look at other use cases on a case-by-case basis. For example, we are allowing some developers to use SDS FHIR as a replacement for the Query Accredited System Information API, which we have recently deprecated.
If you let us know your use case (either here or by contacting us), we can discuss.
We are currently trying to begin the onboarding process for the Spine Directory Service – LDAP API (the features of FIHR is not suitable for us), but we have encountered difficulties navigating the process. Following the guidance on the API Catalogue, we are directed to the LDAP API page, which then links to the Common Assurance Process (CAP) documentation. However, the CAP link loops us back to the API catalogue without providing a clear form or onboarding initiation instructions. Could you advise us on how to initiate a request for CAP and proceed with onboarding for Spine LDAP access?