Historical Analytics - transitive closure augmented
Approach
In this case we're not suggesting that we put the concept back where it was, but we use the replacement concept to determine the 'best' location for the historic concept.
Alternatively could have secondary source of concepts which are mapped in to currently active concepts.
Pros / Cons
Pros | Cons |
|---|---|
Accounts for concepts that were wrongly parented | Doesn't recognise that the concept was being used 'as it was' at the time. |
Logically very straight forward to implement, simple solution. | Some legacy content doesn't even have inactive relationships! |
| May lead to transitive closure looping at build time where inactive concepts are replaced in the table in a place that their descendants have been moved over time to become ancestors. This can also exist where legacy historical associations reference back on each other. |
| Limited to hierarchy type questions. Less effective when working with ECL queries using attributes where concept modelling may have changed over time. Because of this, it also does not lend itself well to Post Coordinated data (these would HAVE to classify correctly to be picked up). |
|
|
In addition the result set does not need to be a flat list. A "confidence level" could be supplied to indicate how concepts have been added in to the result set eg "MAY BE A" will have a lower confidence level than "REPLACED BY"
Implementation Notes
This approach works using a number of passes:
Firstly a full transitive closure table is obtained using the most current edition available
This table is then augmented with historically inactive concepts using a separately curated substitution table.
(Advanced) Any expressions in the data must also be populated into the transitive closure table (and therefore treated somewhat as a pre-coordinated concept - potentially substituting the Post Coordinated expression with a single identifier)
Uses a substitution table that provides a 1:1 mapping between inactive and active concepts (which had wider uses including keeping maps to SNOMED up to date if the target of the mapping were to become inactive)
Solution could consider the reactivation of previously active IS A relationships regardless of whether or not the concept itself is either active or inactive. This might be a situation where these more-suspect relationship usage could be flagged in the output.
Use Cases
This is the approach taken by the NHS in the UK
Copyright © 2026, SNOMED International