Our system contains a list of providers (General Practices). To keep track of name changes we call the ODS API every night and ask for organisations that have changed since the last time we asked.
https://directory.spineservices.nhs.uk/ORD/2-0-0/organisations?LastChangeDate=2025-07-07&Status=Active
This returns a list of organisations. For each organisation we make a further call to get the details so we can then check the name.
https://directory.spineservices.nhs.uk/ORD/2-0-0/organisations/F81029
The problem we now have is that this does not appear to be reliable. I’ve just had a request from the users to update the name of the above F81029. On investigating I find that the last change date for F81029 is 2025-10-08, but when I make the first call asking for changed organisations since 2025-07-07 it is not included in the list. Which is why our system didn’t pick up the change.
Hi Michael
The organisation search endpoint returns a max of 20 records per page by default. This is why you were not seeing the practice in question in your results. You can add the Limit parameter to increase the default records returned to 1000, and then also use the Offset parameter to page through where you have more than 1000 results.
https://directory.spineservices.nhs.uk/ORD/2-0-0/organisations?LastChangeDate=2025-07-07&Status=Active&Limit=1000&Offset=2000&_format=xml
Alternatively, you could use the Sync endpoint which has no default record limit:
https://directory.spineservices.nhs.uk/ORD/2-0-0/sync?LastChangeDate=2025-07-07&_format=xml
Organisation Data Service - ORD API - NHS England Digital
Please note the planned deprecation of the ORD API by Sept 2026. ODS have now gone live with an Organisation Data Terminology FHIR R4 API:
Choosing an Organisation Data Service API - NHS England Digital
Many thanks
Laura
When I posted by question above I was using the swagger interface to call the API. You’re right in that I forgot about the limit and offset. Repeating my swagger query and using limit 500 returns the “missing” organisation.
However reviewing the code that calls the API we are taking limit and offset into account:
But perhaps we have not implemented this correctly. The investigation continues 
Thanks
Consider this organisation showing a last change date 2025-10-08
When was that change made to your database? Was it on the 8th, or is there a possibility that the database was updated on the 9th or even later?
In our normal schedule of calling ODS API, we do this every day at 4am. We know when we last called the API (the previous data at 4am) so we make a call asking for changes from the previous day. I’ve checked our logs and we have run every day for months yet have missed some updates.
When I force a manual call to the API having first reset our database so it thinks the last run was 01/10/25, resulting in us asking for changes on or after 01/10/25, all the “missing” changes come through. The only explanation I can think of is if your changes are applied not on the day of the reported LastChangeDate value, but in the following days.
We have no record of any issue with the overnight processing on our side, but we have contacted our API supplier to confirm that the files were detected and changes loaded before 4am on 9 Oct. I will update you asap.
We offer the following guidance to try to guard against missing data if overnight processing failures do occur:
Organisation Data Service : LastChangeDate
The above link is very interesting. I think it bears out the scenario I had in mind. An organisation will have a Last Change Date set to 10/1/25, but it may not be applied to the database until several days later. That’s not a problem if I call the API asking for anything changed in the last 10 days. We’ll see the change. But instead we call the API every day asking for any change since Now - 1 day.
Hi Michael
ODS, and our API supplier, can confirm there were no issues with the overnight update process on 8/9 October 2025. The audit trail for F81029 confirms that the record was updated at: 2025-10-09T01:05:19.086+00:00. That time is in UTC so local time of 2:05 am on the 9th of October (e.g. picked up in the 2am run).
Thanks
Laura
We are now confident we know why we missed some of the updates. We’ve made adjustments to our schedule and query.
Thanks for the info. I’ve always found this forum very useful.
