SNOMED CT Editorial Advisory Group

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »


Ambiguous Concept

POSSIBLY_EQUIVALENT_TO association reference set (foundation metadata concept)

The inactivation reason “Ambiguous Concept” with association type “POSSIBLY_EQUIVALENT_TO” explicitly states that the concept to be inactivated is inherently ambiguous but that each of the potential meanings represented by the ambiguous concept is semantically identical to one of the “POSSIBLY_EQUIVALENT_TO” target concepts, whether currently present or could be created in SNOMED CT.

The implication of this definition is that for any given ambiguous concept there must be 2 or more POSSIBLY_EQUIVALENT_TO target concepts.

  • Resolve all non or partial synonymous synonyms first by inactivation as "Not semantically equivalent component' and the association type of "REFERS_TO" reassigning the description to either an existing concept or if necessary creating a new concept.
  • Where a concept's ambiguity results from a classification disjunction or conjunction use the inactivation reason of "Classification concept".
  • Where the modeling of the concept is at variance with the meaning of the FSN, correct the modeling - this advice may change once the QI project has been completed and ECL is widely used.
  • Identify ALL possible meanings that arise from the ambiguity. Identify semantically equivalent SCT concepts where they exist, and create new concepts where they do not exist.

Annotation
Inactivation ReasonAssociation TypeDescription

Ambiguous

“POSSIBLY_EQUIVALENT_TO”

This inactivation reason explicitly states that the inactivated concept is inherently ambiguous but that each of the potential meanings represented by the ambiguous concept is semantically identical to one of the “POSSIBLY_EQUIVALENT_TO” target concepts, whether currently present or could be created in SNOMED CT.

The implication of this definition is that for any given ambiguous concept there must be 2 or more POSSIBLY_EQUIVALENT_TO target concepts.

Guidance

Identify ALL possible meanings that arise from the ambiguity. Identify semantically equivalent SCT concepts where they exist, and create new concepts where they do not exist.

  • Non or partial synonymous synonyms
    Resolve these by inactivation as "Not semantically equivalent component' and the association type of "REFERS_TO" reassigning the description to either an existing concept or if necessary creating a new concept.
  • Classification concepts
    If the concept's ambiguity results from a classification disjunction or conjunction, use the inactivation reason of "Classification concept".
  • Incorrect modeling
    Where the modeling of the concept is at variance with the meaning of the FSN, correct the modeling - this advice may change once the QI project has been completed and ECL is widely used.

Additional notes:

  1. Identifying true ambiguity rather than lack of specificity or the meaning is "not known" and resolving the full suite of POSSIBLT_EQUIVALENT_To target concepts can sometimes be difficult.
  2. Share difficult ambiguous inactivations in the internal editor's meetings
  3. It is possible that one of the interpretations of the ambiguity gives rise to a concept that is not clinically meaningful. It is still important to create a concept to represent this concept to ensure that there is full semantic equivalence between the sum of the POSSIBLY_EQUIVALENT_TO targets and the ambiguous concept being inactivated as this is the only way of supporting analysis of historically coded clinical data that may have used the ambiguous concept. As a secondary action, the concept that is not clinically meaningful may then itself be inactivated.


Examples:

Inherently ambiguous FSN with only one POSSIBLY_EQUIVALENT_TO target concept

Two possible meanings:

Resolution:


Managing incoming historical associations:

The intention is that this functionality will be seamlessly integrated into the tooling so as to present to the user the appropriate updated historically association to be allocated.

Whenever an already stated POSSIBLY_EQUIVALENT_TO target itself also becomes 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)

(AIntEd) POSSIBLY_EQUIVALENT_TO (BIntEd OR CIntEd) and (BIntEd) MOVED_TO (DNRC) implies (AIntEd) POSSIBLY_EQUIVALENT_TO (CIntEd)

(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) OR (A) WAS_A (D AND E))

Note: Once MOVED_TO the NRC we (SNOMED International) have no knowledge of what has happened to BIntEd

  • No labels