Looking through Spine Services & trying to separate into Synchronous vs Async.
So far my list is:
PDS
SDS
Mesh
CP-IS
SCR
e-RS
EPS
RAF (is that live yet?)
Smartcards?
Anything missing from that list? Anything up coming which going to be added?
TIA
Adam
This is a great question and one that I was discussing with some of the API and Developer Hub people at NHSD last week.
I can think of one that’s missing: FGM-IS, which is (I think) somewhat similar to CP-IS, but a separate service.
There is apparently some disagreement/debate even within NHSD as to which services are ‘officially’ under the Spine brand or banner. Which seems bonkers, but hey ho.
As to which are asynchronous and which are synchronous… presumably that would be in the documentation somewhere.
Maybe we could create a resource here that lists them all? With expansion of the acronyms and links to main documentation sites? This would make a great Markdown table. I could make the topic into a Wiki so that a wider number of people can edit?
Excellent idea… Would have to subdivide something like Mesh so that as new message types etc are added to that… etc.
What do you mean by async and sync.
A business interaction where a request is sent and a response would be delivered at a latter time
Technical interaction where a response may be instantaneous or delayed (some spine interactions do this).
The business ones tend to be MESH, NEMS and Transfer of Care based. Both flavours of EPS is also traditional messaging.
I personally prefer to use the Business Setting filter on the catalogue API catalogue - NHS Digital
What is RAF - Is it reasonable adjustments? Under this filter API catalogue - NHS Digital
There’s a table in the External Interface Spec which lists the pattern for each interaction: https://nhs-prod.global.ssl.fastly.net/binaries/content/assets/website-assets/spine-eis/eis12.3–part-3–messageinteractionmap.doc
It’s dated but probably does what you want, and has the detail as in lots of cases the pattern differs between different interactions in the same service.
Aled.
Yes RAF = Reasonable Adjustments
By Sync vs Async I mean Synchronous use cases (e.g. PDS Lookup) vs Asynchronous (for example sending a message via Mesh )
Cheers Aled,
Kinda shocked that LRS is still existing…
Bit of a history lesson about the legacy spine (BT design). Broadly speaking two key documents cover the legacy interfaces:
- The External Interface Specification - (inc. integration patterns)
- The Message Implementation Manual (MiM) - (inc. the HL7v3 message payloads e.g. PDS, SCR, EPS, etc)
Across each spine domain (PDS, SCR, e-RS, EPS, …), the interactions are mapped to either sync and async business responses. All very complicated and difficult to identify within a mass of documentation.
Thankfully with the new NHS Digital API Management platform, all the APIs are synchronous, so the complexity of handling async patterns has gone away.
As Kevin mentioned, pretty much all of the service details are published here - API catalogue - NHS Digital
My quick list:
PDS Legacy HL7v3 - mixture of sync and async patterns
SCR Legacy HL7v3 - mixture of sync and async patterns
EPS Legacy HL7v3 - mixture of sync and async patterns
e-RS Legacy HL7v3 - async pattern
GP2GP HL7v3 - async pattern
ACS HL7v3 - sync pattern
LRS HL7v3 - async pattern
SDS LDAP - sync pattern
TES Alerts HL7v3 - async (Alerts Implementation Manual)
PDS SOAP Web Service Mini-service - sync pattern
PDS new FHIR API - sync pattern
SDS LDAP - sync pattern
FGM - sync pattern
NRLS - sync pattern
NEMS - sync pattern
CPIS - mixture of sync and async patterns
e-RS API - sync
EPS Prescription tracker - sync
Reasonable Adjustment flag - sync
MESH transport - an async ‘slow’ channel
Spine Secure Proxy - a sync ‘fast’ channel used for GP Connect (Spine Secure Proxy Implementation Guide | CareConnectAPI)
Wow… cheers… Sad to see so much of my stuff now defined as legacy (sniff & sob) but…it’s not like I regretted trying to get rid of edifact & ftp so…
It terms of live volumes, it’s far from legacy Adam 
Yeah we’re just trying to work out the path from existing to the new & shiny fhir future…
Re async and sync. Most sync interfaces should be coming out as Fhir r4 restful api’s (however the hl7 v3/fhir stu3 document approach may take longer to remove).
For async they are probably coming out as fhir messages, more similar to hl7v2 than hl7 v3/fhir stu3.
Both involve a move away from spine data model (sds) back to nhs data dictionary (/ods). Sds will still be present in oauth2/NHS identity
erm… refer to my clarification comment on patterns (its still there but fingers crossed nobody will use it)
Hi there, I’m the lead product owner for API Management at NHS Digital. I echo Kev and Richard’s comments above - the best way to get a full list of NHS Digital APIs, including details of the payload format and transport mechanism, is via our new API catalogue at API catalogue - NHS Digital. The catalogue includes tags and filters so you can filter by care setting, business use, technology or API type (central service, intermediary service or standard).
Moreover, we’re keen to receive your feedback and suggestions via our interactive product backlog at https://nhs-digital-api-management.featureupvote.com/, where you can comment, upvote or suggest new features and APIs for us to consider.
There have been recent updates on the API Catalogue section and API Specifications pages.
These updates include:
If you want to suggest something or get involved directly with the catalog team, you can do so at the link below.