Taken from April 2019 Business meeting at 00:19:44
Jim: The red value sets are our sets of qualifiers that essentially describe the status of the element within the resource. The issue with some of those is that the same terms are contained within different value sets, but they have different meanings, and so that would require that we add context to all of FHIR to determine how that qualifier is supposed to be used, which is not really what the purpose of a qualifier is.
Secondly, the values in the valueset are only of use within the context of the binding to the element within the resource. So it's not something that might be analytically collapsed or joined with data from other resources, or other elements within a resource. So because these are primarily qualifier values (and really, the definition is implicitly or explicitly defined within the resource for each of the values), they don't fit into the SNOMED model all that well as qualifier values. They they look more like fully defined contextual terms that are used in association with an element of the resource.
So the choice is to either:
- just provide a qualifier as a word within SNOMED without any explicit definition or implication about how it's going to be used, and allow the context of use to be defined by the element that it's bound to, OR
- we would have to create fully specified situation type concepts that represent all the context that was implied within the qualifiers themselves, OR
- we could say that there's really not much benefit in creating four or five terms that are only going to be used in the context of this one element that they're bound to and thus, there's no real benefit in using SNOMED terms to represent them.
So those are the three options that we have in determining what to do with these these values.
Peter: I know your feelings on not wishing to add more context into SNOMED. Do you have a preference, then, for these valueset items?
Jim: Do I have a preference? Yes, I think because of the nature of the way the terms are being used that there's really not much benefit in adding them to SNOMED, and that they should be local value sets that are defined by FHIR, maintained by FHIR and used by FHIR.
Update July 2019:
Jim: While SNOMED International might, in general, wish to avoid adding a large number of context-less adjectives to the qualifier value hierarchy, we have to consider their use in a particular information model - in this case a FHIR Resource. Resource elements provide comprehensive definitions as to their meanings and thus provide adequate context; so that the use of a qualifier value - bound to that resource element - has an unambiguous meaning. The current hierarchical structure of the qualifier values causes more confusion than benefit. The use of standardized (coded) values in value sets bound to a data element reduces the variability in representation of equivalent values where lexical and language differences exist.
The challenge comes when SNOMED CT users try to find appropriate qualifiers to use in value sets and choose words instead of looking at the location in the terminology to determine the implied meaning. For example, the term "above" is a synonym for the concept 352730000 |Supra- (qualifier value)|, which is a topographic modifier. This then restricts the use of that "word" to a specific context.
If we look at some of the terms requested by HL7, such as "resolved", this could have many meanings, but when it is bound to a specific data element, the intended meaning is clear. It would be unmanageable to try and represent all of the intended meanings of the word "resolved" in SNOMED CT and would provide little benefit to users since the meaning is intrinsic to its use in the information model. The information model itself completes the full semantics of an instance of a data element. Since values from a particular element binding should usually not be mixed with values from another element, there is little risk for erroneous analytical results.
We are never going to stop users from using the same word to mean different things in their implementations, but we can at least provide them with the words they need in a standardized way. However, I do not believe we should go down the path of creating findings, nor do I recommend the use of clinical findings for these types of ordinal/nominal value sets.
As for the hierarchical relationships of qualifier values, these too are context dependent and should not be instantiated in SNOMED, CT since the needed hierarchical relationships would be inferred from the element binding. This, in essence, means that the definition of the hierarchy within a value set would need to be used for subsumption testing as opposed to relying on the SNOMED CT hierarchy.