NO SNOMED CT DescriptionID in data exchange

When you look at the title, you may be wondering why there is a need for this post in the first place, it is so obvious, no one uses SNOMED CT DescriptionID in data exchange, we all use ConceptID (for the code attribute in CD data type if using ISO21090 data type or HL7v3 R1 data type). However it turns out this is not true in reality in some of the local implementation. The user claimed that end user only cares about the description, in order to uniquely identify each description, the most granular way is to capture the DescriptionID. If the receiving system needs to know the corresponding ConceptID, it can always do lookup to find the value.

Before I explain my argument, let me know first give some background introduction about SNOMED CT.

SNOMED CT is a comprehensive clinical terminology that provides clinical content and expressivity for clinical documentation and reporting. It is a concept-based terminology, which means that each medical concept is uniquely identified and can have multiple descriptions. All descriptions for the same concepts are linked together. Concepts are related to each other by hierarchical relationships, and a concept can be in more than one hierarchy. Relationships are also defined to describe additional attributes of concepts. Relationships can then be used by applications to group and classify SNOMED-encoded data as needed.

Below is the UML diagram to represent Concept, Description and Relationship in SNOMED CT



Each concept is uniquely identified by the conceptID, which has at least two descriptions - fully specified name (FSN) and preferred term, with additional synonyms. The relationship between concepts are modeled in Relationship class - conceptID1 links to the source concept, conceptID2 links to the target concept, and the relationshipType itself is also concept.

The purpose of the FSN is to uniquely identify a concept and clarify its meaning, not necessarily to present the most commonly used or natural phrase for that concept. Each concept has one Preferred Term meant to capture the common word or phrase used by clinicians to name that concept.

Besides FSN and preferred term, another type of description is synonym, which represents any additional terms that represent the same concept as the FSN. Synonyms, like Preferred Terms, are not required to be unique across concepts.

As an example, Asthma has conceptID as "195967001", and FSN is "asthma (disorder)" , and preferred term is "asthma", another 8 synonyms e.g."bronchial hyperresponsiveness". Asthma is of type "disorder of respiratory system" with conceptID as "50043002", the type/subtype is established through Relationship class.


For the same concept, there are multiple descriptions within the same language as shown above, also there are descriptions for different languages, each language specific description has a unique descriptionID in SNOMED CT.

So now we can see that what's the problem of using descriptionID in data exchange ,there are a lot of in-efficiency and overhead since the every system now needs to do extra validation/lookup to check whether the received id is conceptID or descriptionID.

Another issue is that locally installed SNOMED CT 's preferred term may be further refined to suit each institution's needs, so the local preferred term may be different from each other. How to ensure these locally flavored preferred term synchronized with each other at real time is another challenge, and it will eventually lead the use of descriptionID in data exchange to an unworkable solution.