Question:
In my brief look at the standards, I can’t seem to find any requirement or convention in SNOMED or HL7 regarding the the use of Description IDs vs Concept IDs in messages or datasets.
Is there any preference or can Description IDs and Concept IDs be used interchangeably?
Answer:
It is correct to use Concept Ids as the code in both HL7 v2 messages and CDA (and other v3 instances). Description Ids should not be used.
Explanation:
This is,unfortunately, not documented anywhere. It is implicit in the language used by the datatypes in both v2 and v3, though this is more obvious in v3,with the explicit focus on concepts. While its true that description ids also uniquely identify concepts, they additionally identify display strings which are duplicated by other fields in the appropriate types.
In CDA, must the Concept ID always be accompanied by the Preferred Term – in the displayName component – or can a Description Term be used?
Though the fully specified name description term should probably be avoided – it is more of an infrastructure/plumbing device used to ensure that each concept can be described uniquely.
It is not meant for use as a display name.
A description term can be used
In SNOMED CT, the *meaning* is carried in the Concept. Synonyms can be (and are) ambiguous.
This means that if you allow selection of a synonym in a user interface, then you can’t be sure that the correct Concept was selected. In this case you should record the Description ID and you are effectively using SNOMED CT as just a giant list of terms and have thrown away its real value and, since you are not using Concepts, you cannot safely perform decision support.
The right way to do this is to only ever allow the selection of a Preferred Term (or a Fully Specified Name, but they can be cumbersome, as mentioned above). You can then be confident that the correct Concept was selected and record the Concept ID along with the text of the Preferred Term.
MIchael,
I can’t agree with this blanket generalisation. I can see perfectly acceptable scenarios for allowing synonyms in user interfaces that don’t throw away the link with Concepts. In fact I feel sure that is the only viable option, in most cases, particularly given limitations of screen real estate, current clinical practice, etc. I don’t see that there is an issue in most cases if reference sets are bound to particular screen fields and those reference sets are used to display a synonym of a preferred term.
I can see two distinct issues that need to be considered. The first is whether users can be relied upon to “choose” a correct Concept based on a Synonym rather than a Preferred term. The second issue is one of disambiguating duplicate Description Terms.
Given that preferred terms are not unique, then what is the difference between using a Preferred Term and some other synonym of the unique fully specified name thereof? They each have a corresponding Description ID that links each one to its corresponding Concept ID.
I think it is a matter of how the user interface is designed; the scope of allowed values that are involved in a particular user interface field; and the context of use that determine whether the correct Concept is chosen.
From memory, the majority of multiply occurring terms in SNOMED CT are dual Preferred Term entries under either the “Substance” or the “Manufactured / biologic Product” hierarchies, e.g. “Amoxycillin with clavulanate potassium”.
#Michael and #Eric.
I think I disagree with both of you. Who’s going to choose Snomed concepts directly using either preferred or other terms? Interface terminologies, my friends…
Hi Eric,
My comment was made in the context of a generic use of SNOMED CT. If you are going to hand-curate a set of terms for display etc, then you’ve got a different scenario (as Graham says, an interface terminology), and it is incumbent on you to ensure that the terms you select match the *meaning* of the corresponding Concept based on its Fully Specified Name.
Note that the real problem with synonyms is not so much that two Concepts may have the same term as a synonym (ensuring that the field is bound to elements from a single hierarchy usually helps here), but that the synonyms can have a subtly different meaning (more general or more specific). For example, does “Fracture of leg” refer to the “lower leg” or the “lower limb”?
Yes, ultimately *if* you design your UI such that the term -> Concept (ie meaning) mapping is unambiguous, then you’re okay at the point of capture (and my blanket statement does not hold), but in this case I think you should be recording the Concept ID rather than the Description ID because doing the latter does not allow down-stream use to safely perform decision support.
Indeed, I think this last aspect is really the crux of what I am getting at: in SNOMED CT, Description IDs do not carry meaning, only Concept IDs carry meaning and thus it is unsafe (high risk) to perform decision support with Description IDs.
For those looking for more “interesting” examples of problematic synonyms, I suggest grabbing your copy of Snapper or Minnow (or other SNOMED CT browser) and looking up the following terms and examine the associated synonyms:
pyogenic arthritis
suppuratives arthritis
bacterial arthritis
septic arthritis
Michael,
Firstly, can you explain what the concept “generic use of SNOMED CT” means?
Secondly, I agree that there can be an issue with the current quality of SNOMED CT synonyms, but the issue of generality vs specificity should rather be dealt with by SNOMED’s IS-A hierarchy, rather than embroiled in synonymity within a concept – easier said than done perhaps. I would have thought, though that “Fracture of leg” should equate to “Fracture of lower limb”, and that “lower leg” might refer to “lower lower limb” as distinct from “upper lower limb”
If that is not the case, then surely that is a quality issue that should be resolved?
I think there are worse issues with the IS-A hierarchy, though. I think it more difficult for users to reconcile and deal with the situation where a kind of “Fracture of the lower limb” can also be a “Fracture of the upper limb”. SNOMED CT certainly contains that – partly a legacy of terminologists not differentiating between singular and plural, and partly due to the overloaded nature of the IS-A concept.
Thirdly, I still don’t understand your safety issue with using Description IDs rather than Concept IDs. Each Description ID has one, and only one, corresponding Concept ID, and so has the potential to refer to a slightly more precise (in the user’s context) “meaning” than its corresponding “Concept ID”. Meaning is only available through description terms and the relationship between those terms. A Concept ID refers to a set of terms that give it meaning. A Description ID refers to one, and only one member of that same set. I’m not sure that a Fully Specified Name for a Concept carries more accuracy in defining a concept than a Preferred Term, nor that a Preferred Term carries more accuracy in meaning than a synonym. If that is the case, I’d be interested to learn where the IHTSDO documentation might state so.
By “generic use of SNOMED CT” I mean the sorts of scenarios involving a broad context such as a “diagnosis” field rather than those with a very narrow context such as gender.
Regarding where the Meaning of a Concept is located, section 4.1.1.1 of the IHTSDO’d Technical Implementation Guide has this to say:
“A SNOMED CT Concept is a clinical idea to which a unique SNOMED CT identifier has been assigned.
Each Concept is associated with:
A unique human-readable Fully Specified Name (FSN), which specifies the meaning represented by the Concept.”
Moreover, the glossary defines the Fully Specified Name as follows:
“A term unique among active Descriptions in SNOMED CT that *names the meaning* of a Concept code…” (my emphasis)
while a Description is defined as:
“A human-readable phrase or name ( Term) *associated with* a particular SNOMED CT concept code.”
Again, my emphasis. Note that “associated with” is a very general relationship that does say anything explicit about the meaning of the Concept.
I think this is pretty clear evidence that the FSN carries significantly more accuracy in meaning than an arbitrary associated phrase.
Finally, the problem with the argument that a Description ID points to a unique Concept ID is that you first need to consider where that Description ID has come from. If I see the term “Pyogenic arthritis” in a user interface, I have no idea which Description ID it is associated with (there’s more than one) nor do I have any idea which uniquely identified Concept ID is subsequently being implicated (it might be 48245008 | Bacterial arthritis | or 372939007 | Suppurative arthritis | or even 372940009 | Acute suppurative arthritis |). That’s why, in the user interface, you need to provide the feedback as to which specific Concept ID is implicated in the selection, and then, since you’ve done that, you can and should record the Concept ID directly.