Use of the MOVED TO historical association

Description

When we demote a concept from an upstream module (such as the International Edition core) to a downstream module (such as the UK Edition), this is performed by inactivating the concept with an inactivation indicator of 370126003 |Moved elsewhere (inactive concept)| and creating an entry in the 900000000000524003 |MOVED TO association reference set| with a target value of the concept representing the Namespace that the concept is expected to be reactivated in.   This works because the International Edition contains all Namespace concepts.   We might have preferred to give an indication of the destination module, but this is not visible within the International Edition.

At some point in the future, the destination edition will re-activate the concept and inactivate both the inactivation indicator and the historical association in their own extension module.

The trouble with this approach is that for anyone else consuming the (for example) International Edition, that concept has pretty much just disappeared.   Unless they already have the destination edition as a dependency, they have no way to retain visibility of the moved concept, nor anything to replace it with in EHRs or Reference Sets.

Consider

Historically, historical associations have been used in combination.  Here are a few examples (asterisk denotes inactive concept):

Secondly, given that the new location of the concept in question is not computable, is there actually much benefit to using the MOVED_TO association at all?   In my mind (PWI) there are two minor points:  1.  It allows us to see that we're being deliberate about not providing an alternative concept and 2. If we came across the concept in the future, authors would think twice before reactivating it.   It's also handy for producing a list of moved concepts to give to the destination organisation, but this is more about process than content at that point.

Proposal

I propose that we allow the Moved To historical association to be used in combination with zero to many PossEquivTo associations to allow consumers to find an alternative concept if they do not have access to the downstream module that is receiving the concept.   It seems unlikely or unuseful that we would use the SAME AS association in this case, since if we were effectively retaining an identical concept, there'd be no need to demote one.   

I suggest that the existing combinations of historical associations should be reworked to converge with existing practices.   This simplifies the issue for consumers and also resolves tooling validation complaining about legacy associations that are no longer legal combinations.

2025 Revision

Is the Moved To association actually of any use to anyone?  Is it just an unnecessary complication we could simplify out of our lives?  @Guillermo Reynoso mentioned that he considers this mechanism to be broken.  Given a concept inactivated in the International Edition, what difference does it make to an extension maintainer to know where that concept might have been reactivated?  It seem like they only have two choices, either a) argue for the concept to be reactivated in the International Edition (since it is now required by more than one extension), or b) reactivate the concept in their own extension.  

The reason for pursuing this point is that the hierarchy of Namespace Concepts have - until someone tells me otherwise - no purpose other than as a workaround for the fact that we cannot directly reference the module concept of the receiving organisation since it cannot be "seen".   This might be of some help if there was a way to determine the receiving organisation from the Namespace but those things are pretty opaque - and this might be a GDPR thing or protection from changes to these 3rd party names: 

Open

The organisation that a namespace relates to can be looked up in the CIS application.

The owning module of a concept can be looked up via the concept URI...at least of the extensions that we host in the International Browser.   Actually I'm not sure that that mechanism would prioritise an active concept in an extension module if it also existed inactive in the International Edition.   I'll test that and schedule a code change if so.

But:  If we deprecate the Moved To association, we could - I would argue - also inactivate all namespace concepts.    Is there any other reason to be able to refer to a namespace, that we need an SCTID to do so?

Tagging @Jeremy Rogers (Unlicensed) and @Stuart Abbott (Unlicensed) as many of our Moved To associations point to the NHS Namespace.