FHIR Bootcamp - Registrations now open for the July batch!

Register Now

Extensions to SNOMED CT

S. B. Bhattacharyya

S. B. Bhattacharyya

Clinical Modeller

Extensions to SNOMED CT

Frequently, the existing concepts and/or terms in the latest SNOMED International release are found to be insufficient for the requirements of a system. While the language for the terms may be something other than the official releases like English (US & GB), Spanish, etc., more frequently it is found that terms and phrases required are either not present as a pre-coordinated expression or the exact term is unavailable although the concept that it represents is available as a pre-coordinated expression.

In such cases, SNOMED permits the creation of extensions to the official release. These extensions must however adhere to certain rules to ensure that the sanctity of “standards” is maintained at all times.

Consequently, all extensions that are meant for public release must make in exactly folder and data file structure. All data files must be in their designated folders, as they are for all international releases. This must be done even if the data files themselves have no content in them (various fields as columns that the data file should have will always be present).

For all terms that are mapped to existing pre-coordinated concepts, it is best to publish them as mappings. Alternatively, they can be published as description data files with the terms identified synonyms. Normally, such a need arises when certain terms are preferred by the users and this needs to be catered to. These preferred terms are what is referred to as “interface terminology”. Being special requests, the need to publish these officially is low to none.

For terms that require post-coordination as none of the pre-coordinated concepts can be considered to be the same as any of the existing pre-coordinated concepts. Once the terms have been successfully converted to their post-coordinated expressions, these need to be published for semantic interoperability and adherence to standards. In these cases, all the new concept identifiers, terms (FSN & acceptable) and relationships (concept definitions) that the concepts representing the terms have with other concepts need to be published.

To ensure provenance, each identifier, be it a concept or a description or a relationship must include a “namespace” in them. These are allocated by SNOMED International to member countries or on special request from those who hold an affiliate license and must be located left of the partition identifier. All such extension identifiers are consequently longer as they have a truly random number attached to the left of these namespace identifiers. Furthermore, all extension identifiers have the digit ‘1’ in place of ‘0’ as the first digit of the two-digit partition identifier. The tables below help illustrate these.

Example of an extension identifier (concept, in this particular case): 683851000189105

tables illustrates example of an extension identifier

Only the item identifier is a truly random number. The check digit represents a computed value (using Verhoeff's Dihedral Group D5 algorithm). The rest are fixed.

Partition Identifiers:

Table illustrates example of a partition identifiers

Use Cases for Extensions

* Frequently-used terms that are synonyms of existing concepts
* Frequently-used terms that are new concepts requiring post-coordination
* Terms in local language or dialect

Subscribe to our newsletter

We send you a digest every week!