Discussion surrounding the proposal to retire from use the WAS-A historical attribute and the inactivation of the existing relationships. The issue originated when a concept slated for inactivation served as a destination concept for a WAS-A relationship to a limited status concept. The tooling required reconciliation of the WAS-A relationship to an active concept. It was reported that historically there was some push back inactivation of a WAS A from a limited inactive concept pointing to a concept that was being inactivated. The palliative action was to redirect the WAS A towards the most specific active subsumer of the concept being inactivated to enable some sort of data healing. As discussed in Montevideo, current WAS As linked to limited, inactive concepts were a one-time compromise for an historical relationship that doesn't make sense in RF2.
6 Comments
Jim Case
Summary of discussions from prior EAG meetings:
2015-10-27 EAG meeting the recommendation was: " The AG recommended the following: if one runs into a limited status concept, which acts as the the WAS-A source for a target concept that one wants to retire, then one can retire the WAS A relationship and then go on and retire the concept that one originally planned to retire."
2015-11-30 EAG Meeting: The AG decided to add to the Editorial Guide guidance on retirement of WAS-A relationships. The WAS-A relationship should be removed and the target concept should be linked to the next proximal higher concept in the hierarchy.
Since these recommendations were made, a formal proposal for the technical approach to batch updating the terminology was created and a notice of the proposed inactivation sent to the Community of Practice. This has stimulated objections to both the approach and the timing of the proposed inactivations.
Jim Case
The remove of WAS A as value for Erroneous and Outdated in the authoring platform is already covered in the following two tickets.
https://jira.ihtsdotools.org/browse/ATF-1125
https://jira.ihtsdotools.org/browse/APDS-9
Jim Case
From Jeremy Rogers:
Ideally, do not get rid of the WAS-A relationship. Although they are now technically redundant under RF2 - you can always find out from an RF2 FULL table what the last-known-and-still-active-proximal-ancestors were for any given inactive concept - it’s a tedious computation to do and so IMHO worth doing centrally and distributing the pre-computed result, even under an RF2 release.
But definitely, definitely, definitely do NOT change them all into REPLACED_BY. They’re not the same.
Functionally, due to the historically confused practice of authors (hampered as they have been throughout by the rather underspecified semantics of historical relationships..) most of the relatively modest extant volume of REPLACED_BY statements are in practice semantically very close to SAME_AS, meaning that if you swap an inactive ID for its REPLACED_BY active substitute you don’t normally actually change the meaning or ‘clinically relevant payload’ of the individual EPR utterance.
The same is however definitely NOT true for WAS_A, where the active substitute is very often rather more general than the original, so that you would often be jettisoning clinical detail if you swapped one for the other. Further, if the original (now inactive) code was actually part of a query specification, and you swapped that code within the query spec for its much more general WAS_A ancestor, you can end up turning a query for a narrow domain of clinical interest into one for a potentially rather broader one. The more general WAS-A alternative is often NOT a viable or correct alternative, depending on what sort of artefact you’re trying to update.
So, if for some reason there is still a strong desire to kill off WAS-A relationships, then I would very strongly prefer/recommend that you simply remove them rather than incorrectly transmogrify them into any other existing but not semantically equivalent type of historical relationship.
Basically, before anybody starts messing about with the historical relationships, it would seem long overdue that time should be spent investigating and documenting exactly what the semantics of the existing set of such relationships actually are, whether the authors have ever or are now applying those semantics consistently (answers: definitely not, and probably not) and how that semantics can be/should be/is within the UK being leveraged to compute clinical safety critical derivative products to mitigate the risk of ‘false negative reporting’ that concept inactivation otherwise necessarily entails.
Jim Case
Jeremy,
Just so that I can be sure that I understand your concerns. The issue occurs when a destination target for a WAS-A relationship is inactivated. WAS-A relationships are only applicable to "Limited" status concepts, so they are already inactive, no?
The original option was to replace the proposed inactivated target with an immediate supertype and leave the WAS-A relationships, but it expanded to include the inactivation of the entire WAS A relationship as that was no longer needed to trace the inactivation of a limited status concept in RF2.
My impression is that the option to retain the WAS-A but point to a supertype is not acceptable to you, and that the current RF2 traceability is technically more difficult than the retention of the WAS-A relationships.
So the conundrum that we need to resolve is what do we do when the target concept for a WAS-A becomes inactive?
Jim Case
When the target of a WAS-A is itself inactivated (as has already happened to a fair volume of the ICD-10 derived [X] content that was bounced back from the International Edition to the UK edition..) then the only sensible response is to shunt the WAS-A upward to the nearest surviving, still active, erstwhile proximal ancestors. This is similar to the unravelling of the recursion that would otherwise have to happen when the active target of a SAME_AS (or, indeed, any other flavour of historical relationship) is itself inactivated. But its still a moderately tricky computation to encode and that’s why I’d recommend (given that the data is static…) doing that centrally and publishing the result as an authoritative pre-computed result, rather than leaving it as an Exercise for the Interested Implementer to get wrong.
Under RF2, of course, its technically redundant info – yes; but its clinical safety critical information and my experience is that this kind of algorithm is more often than not beyond the technical capability of many implementers to get right. Also, precisely because computing it correctly is so clinically important, pushing the computation burden onto suppliers can’t be done without also pushing some kind of per-implementation compliance and clinical safety assurance burden onto member states. Both burdens are and the associated risk are significantly reduced if there is a single authoritative Source of Truth.
But permitting WAS_A relationships to be shunted progressively further up the taxonomy means, of course, that you can no longer tell the difference between WAS-A meaning strictly was-previously-direct-child-of and WAS-A meaning was-previously-some-possibly-more-remote-descendant-of, and so its semantics already necessarily changes from being reliably was-direct-child-of to being always was-some-kind-of-descendant-of.
In practice, however, this isn’t actually a problem because even the was-direct-child-of form never universally guaranteed that the erstwhile direct parent was in fact clinically interchangeable for the child; although the most common historical use of WAS-A is probably to indicate when ‘disease X NOS’ has been collapsed into the clinically extremely similar ‘disease X’, there were from the outset sufficient exceptions to this rule that meant it was not safe to treat WAS_A as basically another form of SAME_AS. So, in practice, you’ve always had to treat WAS-A with the assumption that the referenced active concept might be clinically too semantically different from the inactive concept referencing it.
For the UK, the problem of how to manage concept inactivation is especially acute because we’ve got 10 billion items of historical EPR data that has been coded against either READ2 or CTV3, and some of it has been coded (for better or worse) using codes for which the only reasonable exactly equivalent SNOMED map target is an inactive code. Stuff like ‘Corns and callosities’ or ‘Tracheopharyngitis’ to name but two examples I’ve had cause to consider only today. In seeking to migrate both legacy terminology data like this, and the query specifications also crafted to run over that data, onward to SNOMED as best as we can (and clinically safely) we’ve had to work out rules for how the historical relationships can be used.
Jim Case
A summary of a discussion with JTC/GRE/JRO can be found at:
https://docs.google.com/document/d/17dOZwNITk0cZIqalSbXvG_702lsWlLOhS-FPNSGOv8o/edit
Until the batch fix to the issue is applied, the following steps should be taken when the target of a WAS A relationship is inactivated: