So in summary there has been a few solutions presented:
Using a choice of DV_TEXT or DV_CODED_TEXT
Adding an “other” code to the value set. There are three flavors of this:
** (If the code system is SNOMED CT) Add 74964007 | Other (qualifier value) |
** (For any code system including SNOMED CT) Add a code from a separate code system, e.g. OTH from v3 null flavors
** Choose the most generic code possible in the relevant hierarchy (solution not presented here, but has been used in implementations, e.g. choose 123037004 | Body structure (body structure) | to represent “other body structure”)
Would it be possible to have an agreed on standard recommended solution for this use case?
Thanks,
Daniel
Would be my first choice, particularly in any operational setting.
Adding an “other” code to the value set. There are three flavors of this:
** (If the code system is SNOMED CT) Add 74964007 | Other (qualifier value) |
That would be my first preference in any SNOMED licensed environment.
** (For any code system including SNOMED CT) Add a code from a separate code system, e.g. OTH from v3 null flavors
That would be my first preference in any non–SNOMED licensed environment, though I don’t think this is really a null-flavour in the openEHR world
** Choose the most generic code possible in the relevant hierarchy (solution not presented here, but has been used in implementations, e.g. choose 123037004 | Body structure (body structure) | to represent “other body structure”)
That sounds attractive but assumes that there is a relevant hierarchy for the valueset, which is not always possible.
but for all 3 options, we are really just talking about a ‘convenience’ term, since ‘other’, however we express it can never really have any clear meaning without reference to the original question, and construction of the valueset. If it was openly licensed I would vote for 74964007 | Other (qualifier value) | as that ‘convenience term’
74964007 | Other (qualifier value) | should be an adjective as its sematic tag says (i.e., a qualifier). So it doesn’t have any meaningful meaning without a noun (e.g., a disaease or a anatomical structure…) it is intended to qualify.
and in a pure terminology world, that is , of course correct. But, I think we are starting to see how, although such a world is theoretically possible, it is actually very difficult to achieve, and that combining the strengths of information models along with terminology, is a far more tractable solution.
Broadly speaking in Daniel’s scenario, the information model is acting as the ‘noun’ - it is acting the question, setting the context, because trying to shoehorn all of that into a single term, just becomes hugely complex.
As an example I am working with an app where users are asked about a set of significant co-morbidities partly related to COVID-19. These are further sub-divided into rough groups of conditions e.g Diabetes, cardiovascular, respiratory. Within each group there is an ‘other’ condition.
The context which the terminology would have to squeeze in would be patient-record context (situation), screening for conditions related (roughly) to COVID-19 but somewhat arbitrary, further subdivided into condition- related groups and within each of those groups, this in an ‘other’ condition e.g an ‘other’ Cardiovascular condition, not included the terms already offered.
So I would argue that even combined with a noun like an condition, it is still not meaningfully meaningful, as you cannot know what ‘other respiratory condition’ means unless you know what has been offered.
That does not take away there being utility in having a standard term for ‘Other’ used across various contexts, whether we use SNOMED-CT or not.
well… yes, but to create a structurally correct term include that 7464007 isn’t hard - just grab the closest parent you can get in the hierarchy (as per @danka74’s last bullet point) and post-coordinate with the Other (qualifier value) term.
This approach probably doesn’t improve the semantic situation of the example, but in a lot of other situations it could fairly accurately represent the situation.
Anyway, I don’t think using naked qualifiers is a good idea - it means the terms won’t process properly in software making even the most basic assumptions about Snomed.
but how many systems around the world can work with post-coordination and do we really see that changing in the next 10 years?
If you live in a SNOMED only world , there is no option but we do not live in a SNOMED-only world, we have other more appropriate ways of querying contextually, where SNOMED is a very powerful part of the solution.
Will I agree but that assumes that the processing system is wholly reliant on SNOMED to safely and fully resolve meaning, which I would argue has been an unhelpful, and indeed untenable goal. Within carefully constructed settings (sometimes the headings will work well enough) but that is only because that is already accepting that we are not creating any kind of ‘universal semantic’ . This a purely dataset-specific construct.
I don’t know in fact, but if systems that use Snomed cannot routinely handle the ‘basic’ post-coordinations of laterality, or the example we have here, Snomed isn’t going anywhere…
My understanding is that there is practically no use of even simple post-coordination - that is partly because if introduced (even only minimally) , it would have to be fully supported by the wider community.
There are definitely some places where it might help, but many others where practically speaking, it is just much easier to coordinate attributes using an information model. Through FHIR and openEHR, I think we are starting to see real standardisation of workable ‘universal’ standardised information models, particularly for the big-ticket items like Meds, Allergies, problems etc, which also make it much easier to express wider context. That is not to underplay the very significant role of terminologies, particularly SNOMED CT - they play a critical role in the leaf node values, particularly the power of inferencing.
Allergies is a great example - an ongoing issue in the terminology space has been the need to represent every possible medication substance X (and product Y) as an ‘Allergy to X’ and ‘Allergy to Y’ codes. Before SNOMED-CT this would have been simply a case of creating new allergy codes for every new substance and product. Clearly this is a place where pos-coordination should help since one can simply coordinate a generic ‘Allergy to’ code with a code for the substance. So far so good but in practice, there is no need ot do this, at least in EHR systems, since they invariably have an information model for ‘allergy’ which controls the context of the substance code as ‘causative/substance/agent’. FHIR and openEHR handle allergies pretty well identically, so that string simple use-case has disappeared, unless you try to use only SCT and it’s own concept models.
I’m not sure that ever really makes sense, other than perhaps in some downstream analytics environments and perhaps that is where post-coordination might be useful, assuming that the ‘target’ audience does demand/prefer pure SNOMED expressions.
I am actually increasingly positive about SNOMED CT uptake and use, precisely because it is being understood to have much more value when used in combination with other approaches. Attempts to push past the ‘comfort zone’ have actually held things back.
This is a tricky case
After reviewing the Snomed MCRM, there is not a single attribute that accepts 74964007 | Other (qualifier value) | as part of its range. This means that any postcordination that uses this concept as a value for an attribute is invalid per definition. It’s a leaf node with no other relationship than his parent.
In my opinion, something that when used in a postcordinated expression will always violate the MCRM is not a desirable value to put, and in that case I would go with any other code in any other terminology (probably is even better to define a code in the openEHR one) that really encapsulates the meaning.
PS: If we create a new openEHR code I propose to use the code “666”, as nothing expresses better the feeling of “here be dragons”
Loosely speaking, if the value set is {A, B, C, D, Other} and it’s a concept of fruits, then the option/member “Other” could be defined as being a kind of fruit ANDNOT any member of the set {A, B, C, D}.
Yes, but probably not with that Snomed code if someone would try to automatically generate postcordinations from them.
To elaborate a little more, MCRM tells you which kind of postcordinations are valid and which not. MCRM defines exactly which subset of snomed codes are valid for a given attribute (and attributes domains, etc.)
For example, 733930001 |Regional part of (attribute)| valid values are << 123037004|Body structure (body structure)| (which means all descendants of body structure)
Another example: 363699004 |Direct device (attribute)|valid values are << 49062001 |Device (physical object)|(which means all descendants of device)
These valid ranges can come from several hierarchies (e.g. 118170007 |Specimen source identity (attribute)|can come from 6 different subhierarchies (the expression is << 125676002 |Person (person)| OR << 35359004 |Family (social concept)| OR << 133928008 |Community (social concept)| OR << 276339004 |Environment (environment)| OR << 260787004 |Physical object (physical object)|)
This MCRM defines a Snomed “reference model” of sorts, so you cannot really use any code where you want.
Problem is, that same code would mean 2 completely different things depending on the context where it’s put. Moreover, if (when) snomed releases more codes, the meaning would probably also change. That’s one of the reasons why IHTSDO does not usually put codes such as “other unspecified form of whatever”
While its parent (106232001 |Adjectival modifier (qualifier)|) has 512 direct or indirect children, only 50 are even used as ranges by any attribute of the MCRM.
“Other” is not one of these.
A way of expressing ‘Other’ as the defining_code of what was entered which means what Lin said
We cannot use the SNOMED-CT code for ‘Other’ in any way which fits the SNOMED concept model.
We can use some sort of immediate term in a suitable hierarchy but an appropriate term may not exist or be too broad to be truly meaningful. In that sense it is probably just a placeholder that allows ‘something’ to be said in the SNOMED compute space, but probably not something very meaningful or accurate.
Even if (3) is the recommended approach, we will still need to express ‘Other’ as the defining_code, so there is an argument for having a universal ‘other’ code. I’s exact meaning would be wholly contextual but at least that fact is flagged up.
For 3, there are a few “other” kind of codes in snomed, but seems only when the domain uses them in common practice such as:
258348004 | OTH (body structure) | for anatomical site notations in tumor staging or
346602001 |Other foods (product)| for diets.
There seems to be a common use case in snomed to try to remove every “other” concept they have
e.g. 212495009 | Other specified injuries (disorder)| was made inactive in recent Snomed releases
I understand and support the removal of ‘Other x’ codes from SNOMED CT but I’m not sure why the ones you mention should have any particular significance or use in common practice.
I mean that there are refsets where “other” has an existing code, but not the general one discussed above. And should be ok to use these in their corresponding domain.
But in general the use of “other” is dangerous as they tend to be inactivated.
