SNOMED CT Editorial Advisory Group

Page tree

Versions Compared

Old Version 2

changes.mady.by.user Paul Amos

Saved on

compared with

New Version 3

changes.mady.by.user Paul Amos

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Erroneous Concept

REPLACED_BY association reference set (foundation metadata concept)

The inactivation reason “Erroneous Component” explicitly states that the inactivated concept (A) has an FSN which contains an error that when corrected potentially changes the semantic meaning of the concept and that in the judgment of the author/editor the true original meaning is now represented by the “REPLACED_BY” concept (B).

Please note: this inactivation reason should not be used to correct, punctuation, word order changes, or minor spelling mistakes that do not change the meaning of the FSN - these changes can be made by inactivation and replacement of the FSN.



Additional notes:

  1. Where a decision is taken to inactivate and replace the FSN:

    1. Establish whether the changes that need to be made to correct the FSN do indeed make a potential change to the meaning of the concept. If they do not, inactivate and replace the FSN but not also the entire concept.

    2. Where the error gives rise to potential ambiguity, use the inactivation reason of “Ambiguous Concept”

  2. In some instances, the decision to use ‘Erroneous’ or ‘Non-conformance to editorial policy’ is not straightforward. Take for example the issue relating to CT angiography in which we now understand that ALL CT angiograms necessarily use contrast. Technically, this represents an error in the FSN which changes the meaning. Therefore, the correct approach would be to inactivate all concepts which do not state the use of contrast and replace them with one that does include contrast. However, this would result in the significant churn of concepts and a simple replacement of FSN was agreed with the EAG and Community of practice. Therefore, consider internal discussion if there is any doubt as to the most appropriate solution.

...

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 REPLACED_BY target itself also becomes inactive - whether at the same release or later - the combinatorial logic of associations should be:

(A) REPLACED_BY (B) and (B) SAME_AS (C) implies (A) REPLACED_BY (C)

(A) REPLACED_BY (B) and (B) REPLACED_BY (C) implies (A) REPLACED_BY (C)

(AIntEd) REPLACED_BY (BIntEd) and (BIntEd) MOVED_TO (CNRC) implies (AIntEd) MOVED_TO (CNRC)

(A) REPLACED_BY (B) and (B) POSSIBLY_EQUIVALENT_TO (C, D) implies (A) POSSIBLY_EQUIVALENT_TO (C, D)

(A) REPLACED_BY (B) and (B) WAS_A (C AND D) implies (A) WAS_A (C AND D)

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