I would not use anything except for following explicit ‘Maps to’ relations for the purpose of automated handling of the deprecated concepts.
SNOMED CT has their own internal complex process for handling concept deprecation. When SNOMED authors decide to deprecate a concept, they do most often have to pick one or more replacements, depending on the original reason for concept deprecation.
In our more recent vocabulary releases, only a subset of these replacement relationships are now considered when building ‘Maps to’ relationships. Whenever SNOMED uses links that do not confirm semantic equivalency of the source to the replacement (through using ‘possibly equivalent to’ instead of ‘replaced by’ or ‘same as’), or if multiple replacement options are offered, ‘Maps to’ relationship can not be built.
Because of this, a ‘Maps to’ relationship will not always be present even when source offers replacements of a sort. Of course, the context may be different, but in general I would assume that if a concept was not good enough for SNOMED to be inactivated without an unambiguous replacement, it is likely not a good mapping target for us now. Quite possibly, SNOMED did not have anything better at that time the mapping was made, but now well may have.
In addition, SNOMED’s internally produced replacement relationships are not harmonized between different SNOMED editions. Only ‘Maps to’ are important enough to keep clean. There is no guarantee that there are, for example, no circular replacements, ambiguous leads or dead chain ends for old local UK and US concepts.
As such, concepts that used to map to now deprecated targets without a new ‘Maps to’ must be manually remapped on a case by case basis – any rigid systematic logic rule for making a decision will never guarantee a semantic equivalence for the replacement.