POSSIBLY_EQUIVALENT_TO - Discussion

The POSSIBLY_EQUIVALENT_TO association is to be used where an inactive concept was previously the conflation or disjunction of two or more distinct possible meanings, at least one of which is also now represented as a current SNOMED concept.

Archetypal examples might be:

From a data repair perspective, the implication of a set of POSSIBLY_EQUIVALENT_TO associations is that all possible EPR instances previously coded to the inactivated code can be re-coded to one or other of the listed association concepts, without exception and also without either adding or losing any semantics not already expressed by the original coding. No other active concept either does - or could ever - exist that would more precisely capture what was expressed by a clinician originally selecting the inactivated code.

Thus, the following (imaginary) patterns would be incorrect:

...because, in the first example , all patients with a testicular contusion and so previously coded to 'contusion of scrotum or testis' now become coded to the somewhat more anatomically vague 'contusion of genital organs' and therefore would not be returned by any query looking specifically for <<262921003 Injury of testis.

Similarly, in the second example, patients actually with an acquired scoliosis are now coded to something considerably more vague both anatomically and pathophysiologically, and would not be returned by specific queries looking for e,g. either <<298380006 Deformity of spine or <<40668007Acquired musculoskeletal deformity

In the same way, therefore, the following examples of real SNOMED data are also incorrect:

In the first, both alternatives would degrade the original 'excision' to merely some unstated kind of 'operation'; the following would have been more precise:

In the second, any historical EPR entries previously coded to the inactive code but now coded to 'inhalational anthrax' would have had additional clinical information added - the inhalational and lower respiratory tract aspect - that was not specified in any of the original code's synonyms.

Proposed Changes

Previously, a concept would be declared ambiguous if it possessed (or had ever possessed) active descriptions that were not true synonyms of the current Fully Specified Name, even if that Fully Specified Name was itself clearly unambiguous. For example, this phenomenon appears to have motivated the inactivation as Ambiguous of the following two examples, and also explains the POSSIBLY_EQUIVALENT_TO associations declared on each that remain present in current SNOMED data:

This prior practice is, however, inconsistent with the longstanding principle that ONLY the Fully Specified Name of a concept ever indicates its true meaning, uniquely determining both its modelling and thereby its subsequent classification.

It is therefore proposed that all future examples of such non-synonymy should instead be dealt with as follows:

• only the offending description should be inactivated, and not also the entire concept (unless its Fully Specified Name is itself ambiguous).

• in the 900000000000490003 Description inactivation indicator reference set, the reason for the description being inactivated should be recorded as 723278000 Not semantically equivalent component

• a single REFERS_TO association should be added between each inactivated description and exactly one concept whose Fully Specified Name correctly corresponds to the meaning of that description. In the rare case where a non-synonymous description is also itself ambiguous, it should still carry only a single REFERS_TO but this will point to a single inactive (ambiguous) concept that accurately captures that ambiguity, and that inactive concept should then itself have appropriate POSSIBLY_EQUIVALENT_TO associations.

Thus, in the first of the above examples, the original concept 30996001 would still become inactivate (as a duplicate of another current concept) but the various associations would now be:

Combinatorial Logic

Whenever an already stated POSSIBLY_EQUIVALENT_TO target itself also become inactive - whether at the same release or later - the combinatorial logic of associations should be:

A POSSIBLY_EQUIVALENT_TO (B OR C)  and  B SAME_AS D implies A POSSIBLY_EQUIVALENT_TO (C OR D)
A POSSIBLY_EQUIVALENT_TO (B OR C)  and  B REPLACED_BY D implies A POSSIBLY_EQUIVALENT_TO (C OR D)
A POSSIBLY_EQUIVALENT_TO (B OR C)  and  B MOVED_TO D implies A POSSIBLY_EQUIVALENT_TO (C)
A POSSIBLY_EQUIVALENT_TO (B OR C)  and  D MOVED_FROM B implies A POSSIBLY_EQUIVALENT_TO (C OR D)
A POSSIBLY_EQUIVALENT_TO (B OR C)  and  B POSSIBLY_EQUIVALENT_TO (D OR E) implies A POSSIBLY_EQUIVALENT_TO (C OR D OR E)
A POSSIBLY_EQUIVALENT_TO (B OR C)  and  B WAS_A (D AND E) implies A POSSIBLY_EQUIVALENT_TO C, WAS_A (D OR E) * tricky one - suggest detailed review!