MOVED_TO and MOVED_FROM - Discussion

The MOVED_TO and MOVED_FROM association types combine to form a mechanism by which SNOMED records when jurisdictional control of a concept passes between extensions, or between the international core and an extension, in either direction (ie from CORE to Extension or vice versa, or between extensions maintained within the same release centre).

All such transfers of control therefore have conceptually a "donor" and a "recipient" SNOMED extension/release.

Before the transfer: Pending Move status

For any concept EXCEPT those in the International Edition, whilst that concept is scheduled to be moved to another namespace at some point in the future but this transfer has not yet happened, the concept shall remain active but (therefore, paradoxically) have an entry in the 900000000000489007 Concept inactivation indicator reference set, linking the still active conceptId with the "inactivation" reason 900000000000492006 Pending move (foundation metadata concept).

NB: Concepts currently in the International Edition but scheduled to be MOVED_TO elsewhere e.g. a national extension have empirically been exempted from ever needing to become PENDING_MOVE; the rationale for this exemption is not known.

When the transfer occurs: RF1

Under the older RF1 encoding of SNOMED CT release materials, MOVED_TO and MOVED_FROM associations were the only mechanism for recording the actual transfer - but the mechanism also required that the identifier of the concept would always change as part of that transfer:

A MOVED_TO association type is recorded within the donor release in order to initiate a bilaterally agreed and expected transfer/donation of a PENDING MOVE concept to another recipient namespace, locus of editorial control and extension. At its next release opportunity, the recipient namespace - or more precisely some extension published into it - should instantiate matching, active but different conceptId with associated descriptions and relationships, corresponding to the meaning of the code already inactivated by the donor extension. Simultaneously, the recipient extension also adds a MOVED_FROM association on the active replacement concept, linking it back to the identifier for the inactive conceptId in the donor extension.

• A MOVED_TO association type should only be placed on an inactive concept that, immediately prior to its inactivation, was stated to be "Pending Move" (see above)

• The inactive concept now "MOVED_TO" somewhere else should always be assigned the inactivation reason of 900000000000487009 Component moved elsewhere (foundation metadata concept), within the 900000000000489007 Concept inactivation indicator reference set. 

• The target component of the MOVED_TO association identifies the recipient namespace to which the inactive component has been donated/moved; all permissible values for that target were therefore from within <<370136006 Namespace concept (namespace concept). 
  The implication/expectation of a MOVED_TO associated is therefore that the recipient extension will create semantically duplicate content, in that specified namespace. 
  To identify which extension the stated namespace corresponds to, the namespace identifier must be looked up in SNOMED's namespace registry and the owner of that namespace contacted. 
  This implication is also used by some NRCs as a QA check on their own content: where an International Edition MOVED_TO points to a namespace owned by the NRC, but there is no matching MOVED_FROM within the NRCs own products, then by definition there must be new content missing from those NRC products.

• The matching MOVED_FROM association is entered in the 900000000000525002 MOVED FROM association reference set. Unusually, and unlike all other flavours of 900000000000522004 Historical association reference set, the referencedComponentId is not in fact inactive whilst the linked component is (ie all MOVED_FROM records are an inversion of the normal pattern for all other flavours of historical association reference set).

  Note: this  a MOVED_FROM b pattern is semantically redundant: the same semantics could have been represented with b SAME_AS a and without creating the refset pattern inversion.

It can be seen that all individual MOVED_TO associations are therefore intended to be (eventually) always matched by a corresponding MOVED_FROM association within the recipient extension and namespace. Thus, MOVED_TO and MOVED_FROM associations usually come in pairs: the donor can only record where the component had gone, jurisdictionally. Only the recipient can both acknowledge the transfer and also, uniquely, link the old and new identifiers.

Thus, the transfer of the International Edition concept 223045008 [X]Other antipsychotics and neuroleptics causing adverse effects in therapeutic use (finding) from the International Edition to the UK Extension occurred in the following steps:

...whilst the transfer of the UK Edition concept 785911000000105 Perianal haematoma (disorder) in the reverse direction occurred as follows:

When the transfer occurs: RF2

The RF2 encoding of modern SNOMED CT releases, however, allows for an entirely different mechanism of recording such transfer of editorial and jurisdictional control, and without also requiring a change of component identifiers. Therefore, at least in theory, the older MOVED_TO/FROM mechanism has become functionally redundant:

• recipient extensions can now formally accept and reactivate a MOVED_TO concept and all its descriptions and modelled relationships without creating any new components within the specific namespace, as was required under RF1 and as explicitly implied by the target of the MOVED_TO element being an identifier for the namespace in which the new component identifier would be instantiated. Continued use of the MOVED_TO association under RF2 implies a level of expected identifier churn that is no longer happening. 

• instead of recipient extensions adding new and matching MOVED_FROM associations (to directly link the inactive conceptId with some newly created equivalent in the new namespace), RF2 permits them instead to simply inactivate the MOVED_TO association itself whilst reactivating the original component identifier, in one of their own modules but with a later-dated effectiveTime than the entries in the donor module stating the concept to be inactive and MOVED_TO somewhere else. From the subsequent perspective of users of the recipient extension data, therefore, nothing changes about the transferred concept except the moduleId stating who owns it. This transfer pattern is far less disruptive than the original RF1-era mechanism of transfer-with-identifier-churn. A direct consequence is that the MOVED_FROM relationship will in future never be used, and MOVED_TO and MOVED_FROM relationships no longer appear in pairs.

Proposed changes:

• There is an assumption that the concept being moved is only applicable to the specific recipient jurisdiction(s) and therefore will not have been used by any user not from that jurisdiction. However, this may not always be the case. The ALTERNATIVE association type (qv) already exists for optional use with concepts that have been MOVED_TO to a recipient namespace but where an active concept with sufficiently similar semantics also persists in the donor extension. It is recommended that use of this mechanism should become considerably more common than has historically been the case.
  For instances in which no suitable replacement exists in the donor extension, a text note would be appended which states "No appropriate target replacement exists"

• MOVED_TO <<370136006 Namespace concept (namespace concept) is now potentially misleading since, under the RF2 transfer process, there will in fact never be a new identifier in the nominated namespace. Nor will there ever be a matching MOVED_FROM association. It has also always required a manual lookup against the Identifier Registry on order to resolve the association to a specific release centre as the identified recipient extension. Therefore, some have proposed that the permitted valueset for MOVED_TO be changed to include - or possibly even be limited to <<900000000000443000 Module. However, as greater movement of concepts occurs between modules (e.g. between the SNOMED International Core and Community Edition etc.), we recommend a companion association type to MOVED_TO, dedicated to the new RF2 mechanism: perhaps DONATED_TO. This clear separation would be more helpful to NRC's who must manage exchanges of concepts with both SNOMED International and with other products maintained within the same NRC, or between NRC's.
  
  

Combinatorial Logic

MOVED_TO

NB the combinations of association listed below are highly unlikely to ever be encountered; to date, no namespace identifiers concept has ever been inactivated.

A MOVED_TO B and  B SAME_AS D implies A MOVED_TO D
A MOVED_TO B and  B MOVED_TO D implies A MOVED_TO D

A MOVED_TO B and  B REPLACED_BY D implies A MOVED_TO D
A MOVED_TO B  and  D MOVED_FROM B implies A MOVED_TO D
A MOVED_TO B  and  B MAY_BE (D OR E) implies A MOVED_TO null
A MOVED_TO B  and  B WAS_A (D OR E) implies A MOVED_TO null

MOVED_FROM

The MOVED_FROM association is essentially isosemantic to the SAME_AS association. Therefore, the compositional logic is identical:

B MOVED_FROM A and  B SAME_AS D implies A SAME_AS D
B MOVED_FROM A and  B MOVED_TO D implies B MOVED_FROM A
B MOVED_FROM A and  B REPLACED_BY D implies A REPLACED_BY D
B MOVED_FROM A  and  D MOVED_FROM B implies D MOVED_FROM A
B MOVED_FROM A  and  B MAY_BE (D OR E) implies A MAY_BE (D OR E)
B MOVED_FROM A  and  B WAS_A (D OR E) implies A WAS_A (D OR E)