Overview

All records within ODS organisation, site and practitioner data include the date on which the record was last changed in a substantive way, as part of the Organisation/Practitioner component.

‘Substantive Change’ is defined as any previously existing value being displaced by a new one within any data item that is exposed to users; or, the addition of any new item that was not previously present in the published record. Brand new records will bear the date of their creation in ODS.

LastChangeDate is not the ‘effective’ date for a change. Elements of the ODS record carry their own operational and legal start/end dates (the overarching org record, roles and relationships), legal start dates may be in the future. 

The date published in the LastChangeDate element can be used by consumers to filter amended records.

LastChangeDate Limits

There is no limit to the period that can be searched when using the LastChangeDate parameter within the Organisation Data Terminology FHIR R4 API. The parameter supports greater than, less than and equal to and can be compounded.

In Data Search and Export (DSE), when running a predefined report you can limit records to between any LastChangeDate and 'today' (changes since). When running packs of reports in DSE you can select a 'Last Change Period' that can be changes in the last 7, 30 or 90 days.

ODS Future Date Checker

It is feasible to have a record returned by the API with a LastChangeDate equal to the date on which the query is run. This is due to an ODS pre process that runs at midnight to check for any future start/end dates within the data that have just elapsed. If found, the process will update the LastChangeDate for these records to enable consumers to identify / reflect these updates (i.e. the Status changes from Active to Inactive etc).

The future date checker runs every night at midnight before the daily upload to the API is sent, hence why records found by the future date checker will have an LastChangeDate of 'today'.

Technical Guidance for Users Dependent on LastChangeDate

For consumers who have built a dependency on LastChangeDate, the following guidance should be followed:

• updates to the service are synchronised overnight, so any changes made by ODS analysts on a given day appear in the ODS API/Data Search and Export the following day
• updated records should always be returned by the API service between Tuesday and Saturday after approximately 3am (normal running process - this does not usually include bank holidays - in some cases updates will appear in queries executed on Sunday or Monday morning if ODS has been implementing changes over a weekend or bank holiday for example, to support bulk change/reconfiguration of hierarchies)
• during the normal running process the data updates are automated including the assurance of the data itself
• if the data fails assurance for any reason, updates to the database which supports the service are delayed. Under normal operation this should be resolved on the same business day, and in this scenario clients should consider re-querying throughout the day to pick up any changes. However, there will be occasions when more complex scenarios may result in longer delays and NHS England recommends that users employ a defensive algorithm to ensure no updates are missed, as follows:

If no records are returned during the normal running process clients should be configured to re-query using the same date value for up to 3 working days and only revert to business as usual once data is returned. If no records are returned after 3 working days a log should be raised via ssd.nationalservicedesk@nhs.net.

An example scenario where the data refresh is not resolved until two days later:

Consumers should check that records exist for intervening days from the point at which the query stopped returning records to the latest date that records should appear – in the example above records with a LastChangeDate of 24, 25 and 26 September would be included in the query run on 27 September.