Ambiguous Component

I would agree that this is stipulating a tighter use of both AMBIGUOUS and, far more importantly, of the closely related POSSIBLY_EQUIVALENT_TO association than is evident in both historically and recently authored content.

But that's the point: there is both a need and an opportunity for a much clearer specification as to what the point of all this 'reason for inactivation' and 'historical association' information actually is. 

What, and who, is it all for?

If its all really no more than arcane jottings in the margins by the authors, but of no practical computational value thereafter or externally, then fine. But then, leaving aside that this would mean that SNOMED offers nothing to help mitigate the false negative reporting and data repair problem that all concept inactivation engenders, why publish it at all, if it can't meaningfully be used in machine processing to achieve such data repair, because it does not follow predictable semantics? 

The notion of true semantic categorial  ambiguity/disjunction is a relatively simple one and the inferences that can be drawn from it are also relatively simple to define. I would therefore strongly recommend locking down use of the AMBIGUOUS reason and POSSIBLY_EQUIVALENT_TO association to that tighter context.

From the comments so far, I sense that the proposed tightening up of the AMBIGUOUS/POSSIBLY_EQUIVALENT_TO mechanism in particular is one of the more contentious parts of this draft. But the concern seems to have less to do with which content would still be permitted to be inactivated in this way and more to do is with all the other content in need of inactivation that would not now clearly or cleanly fit into any of the currently available but more tightly defined reason/association buckets. My request, however, would be not to pollute/degrade/overload the AMBIGUOUS/POSSIBLY_EQUIVALENT_TO mechanism as a dumping ground for these. The acid test for AMBIGUITY should not be either 'my brain hurts thinking about this' or 'its none of the other reasons so it must be ambiguous as the reason of last resort'.

A clearer test could be one based on the thought experiment of considering the universe of patients already given a code now marked for inactivation, and their clinically expected future behaviour in response to the universe of all possible query abstractions. If and only if you can imagine a valid query that should properly return only some of the patients given the code about to be inactivated, then it is AMBIGUOUS. Essentially, the entire mindset for concept inactivation needs to be turned on its head: start from the data repair question, work backward from there to the required association and its targets, and from there to the Reasons for Inactivation - which, incidentally, probably nobody outside authoring centres really care about; they probably really ARE functionally mere jottings in the margins!

Farzaneh's point is therefore an interesting one to consider against this stricter definition. I think her query concerns whether Ambiguous should still be permitted as a reason for inactivation of an (organism) code whose FSN or PT is a common name, but where that same common name can also signify at least one other completely different species and so is concurrently available as a synonym on different code(s). 65534001 Gerbil (organism) and 11534008 Pipit (organism) seem to have undergone that treatment, but I note that 58269001 Hamster (organism) is the same problem but was handled differently.

But consider in this vein a clinician who, having searched for 'peanut', is presented with both 125260015 Peanut and 3635997012 Peanut (note: description IDs). Because the clinical coding interface does not provide further information to allow disambiguation, the clinician accidentally selects the plant genus over the nut as a food allergen - whereas the latter is what they actually intended to record: The patient is allergic to (ingesting) the nut, not (touching) the plant it comes from. In this scenario, the two underlying concepts themselves were not truly and intrinsically ambiguous within SNOMED, but rather the clinical system has rendered them functionally ambiguous at run time by suppressing from display all the information within SNOMED needed to make the distinction clear. Were we minded to try and compensate for the clinical system's behaviour by altering either underlying concept, I don't think either should properly be inactivated as "ambiguous". The clinician miscoded: based on what they actually said (even though it was wrong), there is no doubt about how records with the 75413007 'peanut plant' code within should behave in queries. In the same way, if a clinician records species:X when they mean species:Y, because the common name is not unique to either, this is a miscode not intrinsic ambiguity.

Unfortunately, of course, this is all in turn likely to create a requirement for much of the historical use of this mechanism to be refactored to comply with the newer guidance.

The question of what should or can safely happen when there is a mismatch between the FSN for a concept and its underlying modelling is one that Paul raised (so I shall blame him!). At heart, of course, this represents a challenge to a long established SNOMED position: the Fully Specified Name is the ONLY arbiter of the meaning of a concept identifier, and therefore you both should and also can change the underlying modelling to better fit the FSN but without ever needing to inactivate the concept.

In truth, this mantra of "FSN Primacy" and the freedom to simply remodel wherever modelling doesn't fit the FSN have not been problematic in SNOMED's life to date. So I can certainly sympathise with an "if it ain't broken, don't fix it" pushback.

However, on reflection, it is possible that this apparent lack of a problem may be merely an accident of the fact that - to date - there has been only very low use of the facility to create novel postcoordinated expressions and record these as primary clinical data. Once that begins to happen at any scale, there appears to be scope for "FSN-Model mismatches" to cause some clinically "interesting" consequences.

When users assemble ad hoc postcoordinated modelled expressions, these of course don't come with any FSN. But if the user expression happens to be equivalent to the normal form of an existing precoordinated code, then should both this code and the associated FSN be substituted for the original expression? If yes, when would it matter if in fact that FSN was either more specific or more general than the semantics of its underlying modelling and so, now, also the user postcoordinated expression that has been coerced to it?

Another example: consider a query designer tasked with defining an 'all patients with X' variety of report specification and who accordingly selects the node corresponding to X from the reporting taxonomy on the basis of its FSN alone. However, the underlying modelling is more general than implied by that FSN alone. Postcoordinated expressions are then classified below that modelled definition even though clinically they are not subtypes of the notion conveyed by the FSN alone, and so the designer's query returns false positives.

In these examples, the fundamental problem is that the FSN of course plays no part in determining the relative meanings between precoordinated codes published by The Centre within the body of its  SNOMED releases, and any novel postcoordinated expressions assembled at the clinical coalface periphery. It may fundamentally be a convenient oversimplifcation that the FSN alone could ever be entirely safely considered universally the only arbiter of the meaning embodied by a concept identifier, and we may need to rethink what can safely happen when there is a mismatch between FSN and the modelling.

By way of a final and more concrete example, consider a query framed as:

<<266887003 Family history: Raised blood lipids (situation)

and what a classifier will currently do with patients assigned the following finding, expressed in the EPR only as an ad hoc postcoordinated expression:

416471007|Family history of clinical finding|:246090004|Associated finding|=
  (118245000|Measurement finding|:
    {363713009|Has interpretation|=281302008|Above reference range|,
    363714003|Interprets|=391464008|Urine propionic acid level|)

At present, these "raised urine propionic acid" levels will I think always be misclassified and returned as subtypes of "raised blood lipids" because the modelling of the latter is more general than its FSN. Specifically, the current modelling does not restrict the sample to blood.

Conventionally, the approved solution to this problem is simply to remodel 266887003 in place so that its definition aligns with its FSN, and so changing from the current:

416471007|Family history of clinical finding|:246090004|Associated finding|=124042003|Increased lipid|

to:

416471007|Family history of clinical finding|:246090004|Associated finding|=
  (118245000|Measurement finding|:
    {363713009|Has interpretation|=281302008|Above reference range|,
    363714003|Interprets|=(104780002|Lipids measurement|:116686009|Has specimen|=119297000|Blood specimen|)})

Theoretically, however, this remodelling could have other undesirable clinical consequences on historical clinical data.

Consider now any patient for whom, prior to any remodelling of 266887003, a clinician had previously assembled this expression:

416471007|Family history of clinical finding|:246090004|Associated finding|=124042003|Increased lipid|

...but behind the scenes, and before the clinical utterance was committed to the EPR, this expression had been identified by normal form comparison to be equivalent to the old definition of 

266887003 Family history: Raised blood lipids (situation)

...and so it was that precoordinated code - and not the longer expression - that was persisted to the EPR.

By changing the modelling in the reference data, you would now be asserting for all these patients that the "raised lipid level" entered by the clinicians had in fact all along been statements specifically about blood lipid levels, even though the original clinical statements were explicitly not that specific.

A possible alternative resolution, therefore,  might be to require an inactivation of the 266887003 concept as ambiguous with POSSIBLY_EQUIVALENT_TO associations pointing at both possible meanings. Whether this approach would have to be invoked for all cases of FSN:Model mismatch remains to be discussed, but I would suspect pragmatically not.

However, the first step down this road is to debate whether the above exposition is a reasonable argument for re-examining the 'FSN Primacy' mantra.

Thanks Ed, that's very helpful.

Even as I crafted the already slightly laboured example above, I was aware that it depended on an expression-for-precoordinatedId swap operation that felt instinctively like an unwise thing to be doing in the first place, and so I'm very glad you've dug out the official guidance specifically advising against it. It could perhaps usefully be given more force than it currently has; must not should, for example. And perhaps be linked to an explanation of why it matters: its not simply an echo of the usual medicolegal guidance that the clinician's original utterance should be immutably stored and transferred 'as is'.

I would however be worried that not everybody will follow this guidance; pretty much this operation would underpin any templated GUI crafted to support clinicians in gathering detailed multiaxial "who, what, when, where, why, wherefore, whence, whither..." information about e.g. certain procedures, and the technical preferences of at least some centres for such compositional detail to be subsequently extractable as a smaller number of (excessively) precoordinated codes. Or, to convert NLP extracts to streams of codes.

But personally I remain ambivalent as to whether or not there is really an issue here; although its not so hard to find examples of fully defined concepts whose FSN and current modelling are not entirely in agreement, I'm not aware of (m)any where the difference has proved clinically significant. So I'm still personally minded to accept this phenomenon as an example of a tolerably inexact model and so, mostly, to allow it to be fixed by remodelling in place and without inactivation, with the whole thus incrementally but asymptotically approaching Truth and Beauty.

But equally I have a gut feeling that there are examples out there where the FSN:Model mismatch is "more significant", and so now seems as good opportunity as any to revisit and have a discussion about what problems could at least theoretically arise in some future world where more expression building was going on, and whether we have it all locked down enough. Some examples would, of course, probably help the debate.