Historical Analytics - Query per SNOMED release

Historical Analytics - Query per SNOMED release

Approach

Multiple queries run against successive releases of SNOMED with results collated.

The timeline of the records could be used to restrict the range of releases considered.

Cohort identification often done just using a list of codes which may need further analysis and - depending on the use case - the query changed.   For example for a retrospective data analysis the "question" itself may need to be modified to make sense in a historic context.

Pros / Cons

Pro

Con

Pro

Con

Accounts for both historical concepts appearing in the results, and the concepts that are used in the ECL expression itself.

Becomes prohibitively expensive when SNOMED International moves to more frequent (potentially daily) releases.

Gives the exact view of the data as it was at a particular point in time.

Becomes more expensive as time goes on.

This is the only solution that handles the case of concepts moving or changing parentage as opposed to simply being made inactive.

EHRs do not (that we've heard) record the version of SNOMED that was active at the time the record was created, and - to be entirely accurate - it would need to have been captured at a per field level.

Is very simple to do when a terminology server is available with successive releases available.

If changes over time are corrections, then running against an older version of SNOMED will pick up "bad" results.  It would be better to run against the newest version of SNOMED possible to obtain highest quality results.



Queries written using up to date concepts and modeling cease to become meaningful at some point in the past.   Queries may need to be augmented with historical modeling to make sense in an earlier context.



Target Use Cases

  • Useful for seeing changes over time - counts and so on can be graphed to show movement between releases, or losses highlighted.

  • Could be used to determine WHY concepts have moved over time.

  • Maintenance as part of an upgrade process eg to check concept counts in simple reference sets between one release and the next.   In this case a replacement concept might be needed or the query itself might need to be updated in line with modeling changes.

  • Maintenance for data bindings use cases.



Points to Note

While it may be unwieldly to run queries against EVERY release of SNOMED CT, there may be a use case for picking discrete releases to demonstrate changes over time.

This solution could be used, partially, in combination with another solution as a double check, to see if concepts show up using this approach which have been missed using a different one.





Copyright © 2026, SNOMED International