Skip to end of metadata
Go to start of metadata


An attribute represents a characteristic of the meaning of a concept or the nature of a refinement.

An attribute has a name which is represented by a concept. All the concepts that can be used to name attributes are subtypes of the concept | conceptmodelattribute |. An attribute is assigned a value (attribute value pair) when used in the definition of a concept or in a postcoordinated expression. The permitted attribute values (range.) for an attribute depend on the attribute name and on the domain of the concept being refined.

Example: 116676008 | Associated morphology


  • Concept Model Attribute
  • Relationship Type
  • Role

Attribute value pair

A combination of an attribute name and an attribute value used to represent a specific type of information in a generic way without altering the underlying structure of an information model. The attributename identifies the type of information and the attribute value provides a value.

Attribute value pairs are used by SNOMED CT in relationships and postcoordinated expressions. In both cases, the attribute name and attribute value are expressed using SNOMED CT concept identifiers. In the Relationship file, the attribute name if represented by the Relationship.typeId and the attribute value by the Relationship. destinationId.


A computer application or software tool used for exploring and searching terminology content. A typical SNOMED CT browser can locate concepts and descriptions by Identifiers and by searching the text of descriptionterms. Various views of located concepts may be displayed including the set of related descriptions, the hierarchical relationships and other defining relationships.


  • SNOMED CT browser

Check digit

The check-digit is the final (rightmost) digit of the SNOMED CT Identifier (SCTID). It can be used to check the validity of SCTIDs. Clinical Information Systems can use the check-digit to identify SNOMED CT codes that have been entered incorrectly (typo errors, etc). It is calculated using the Verhoeff algorithm.

SNOMED CT Component

Refers to any item identified by an SCTID in the main body of SNOMED CT, or in an authorized Extension. The partition-identifier indicates the type of component referred to by that SCTID. Each component is a uniquely identifiable instance of one of the following:

  • Concept
  • Description
  • Relationship

  • Component


A clinical idea to which a unique Concept Identifier has been assigned. The term concept may also be used informally with the following meanings:

  • The concept Identifier, which is the key of the Concept file (in this case it is less ambiguous to use the term "conceptId" or "concept code");
  • The real-world referent(s) of the ConceptIdentifier, that is, the class of entities in reality that the Concept Identifier represents (in this case it is less ambiguous to use the term "meaning" or "code meaning").


  • SNOMED CT concept

Concept equivalence

Equivalence is the state of two SNOMED CT concept codes or postcoordinated expressions having the same meaning. Concept equivalence can occur when a postcoordinated expression has the same meaning as a precoordinated concept code; or when two different postcoordinated expressions have the same meaning.

ConceptId (field in RF1)

A SNOMED CT Identifier that uniquely identifies a Concept (meaning).

Example: For the meaning named | Pneumonia (disorder) |, the ConceptId is 233604007.

Field name in SNOMED CT Release Format 1

Concepts table (RF1)

A table that includes all SNOMED CT concept codes. Each concept code is represented by a single row.

Core file

A distribution file used to represent the main SNOMED CT components (concepts, descriptions and


In the past the term "core" has also been used to refer to the content of the SNOMEDCT International Release but this usage is deprecated.


  • SNOMED CT core 

  • Core table

  • SNOMED CT core table 

  • SNOMED CT core file 

Cross Map (RF1)

A CrossMap is a reference from a Concept code to a CrossMapTarget. Each CrossMap is represented as a row in the Cross Maps Table. It links a single SNOMED CT concept code to one or more codes in a target classification (such as ICD-9-CM) or terminology. A Concept code may have a single Cross Map or a set of alternative Cross Maps

CTV3ID (field in RF1)

A five-character code allocated to a meaning or term in Clinical Terms Version 3 (CTV3, previously known as Read Codes). Each row in the SNOMED CT concepts table has a field for the corresponding concept code from CTV3.

Note: Field name in SNOMED CT Release Format 1
Note: The CTV3ID and SNOMEDID fields are no longer supported in Release Format 2. Instead a |Simple map (reference set)| is used to document the link between legacy codes and SNOMEDCT.
Note: The CTV3ID field should no longer be relied upon for mapping to and from the ReadCodes. Additional mapping work in the UK identified some anomalies and resulted development of more flexibility table for Read Code Mapping


An association between a human-readable phrase (term) and a particular SNOMEDCTconcept code. Each

description is represented by a separate row in the Descriptionfile.

Note: Each description has a unique identifier and connects concept with a term of a specified descriptiontype.


  • SNOMED CT description

DescriptionId (field in RF1)

A SNOMED CT Identifier that uniquely identifies a Description.

Descriptions table (RF1)

A data table consisting of rows, each of which represents a Description.


A language modified by the vocabulary and grammatical conventions applied to the language of a particular geographical or cultural environment.

Enabled application

A software application designed to support the use of SNOMEDCT.


  • SNOMED CT enabled application 

  • SNOMED enabled application 

  • SNOMED CT application 

  • SNOMED application

SNOMED CT Extension

A set of terminology components and derivatives that add to and are dependent on the SNOMEDCT International Edition, and are created, structured, maintained and distributed in accordance with SNOMED CT specifications and guidelines.


  1. Components that are created in an extension are identified using extensionSCTIDs. These identifiers include an extension namespace which ensures that they do not collide with other SCTIDs, and can be traced to an authorized originator.
  2. Namespace identifiers are allocated in response to requests from IHTSDO Members and Affiliates. For further information about this process and for access to the current SNOMED CT Namespace Register please refer to the IHTSDO web page onNamespaces.
  3. IHTSDOMembers may create, maintain and distribute extensions to address specific national, regional and language requirements. IHTSDO Affiliates may also create, maintain and distribute extensions to meet the needs of particular software solutions and customers.
  4. See also Edition which refers to the combination of an extension with the International Release and, where relevant, any modules from other extensionson which it depends.


  • Extension

Fully defined concept


  • Sufficiently defined concept

FullySpecifiedName (field in RF1)

A term unique among active Descriptions in SNOMED CT that names the meaning of a Concept code in a manner that is intended to be unambiguous and stable across multiple contexts.


An ordered organization of concept codes linked together through | is a | relationships. Concept codes linked to their more general parent concept codes directly above them in a hierarchy Concept codes with more general meanings are usually presented as being at the top of the hierarchy and then at each level down the hierarchy code meanings become increasingly more specific or specialized . Formally, a hierarchy is represented as a Directed AcyclicGraph.

History mechanism (RF1)

The history mechanism is the information distributed with SNOMED CT designed to track the history of changes to its logic definitions and descriptions. The history mechanism is supported by two distribution tables:

  • Component HistoryTable
  • ReferencesTable

SNOMED CT Identifier

A unique integer identifier applied to each SNOMED CT component (Concept, Description, Relationship, Subset, etc.). Each SCTID includes an item identifier, a check-digit, a partition identifier and, depending on the partition identifier, may also include a namespaceidentifier.


  • Identifier SCTID

Intermediate primitives

Concepts that cannot be fully defined using the current concept model are called primitive concepts. Primitive concepts cannot be fully acted upon by the classifier; consequently subtype concepts are not assigned via the classification process. Instead, to create subtypes, each relevant concept must be identified and the IS_A relationship stated manually. 

SNOMED CT International Release

The set of releasefiles provided on a specified release date, to represent the part of the content of SNOMED CT that forms the common foundation to the terminology available to all IHTSDO Members and Affiliates.

  1. The International release, provided by the IHTSDO, may be supplemented by Extension releases provided by IHTSDO Members and Affiliates to meet additional national, local and organizational requirements.
  2. See also InternationalEdition which refers to the same general content, without specifying a particular release date.


  • International Release


For purposes of SNOMED CT translations, a language is a vocabulary and grammatical form that has been allocated an ISO639-1 language code. See also dialect.

Language subset (RF1)

SNOMED CT can be translated into virtually any human language or dialect. These translations attach new language -specific terms as descriptions of existing concept codes and may also use existing descriptions if translation is not necessary. A language subset is a set of references to the descriptions that are members of a language edition of SNOMEDCT. Additionally, data in the languagesubset specifies the DescriptionType of each description (Fully Specified Name, Preferred Term or Synonym).

Mapping mechanism

A set of data structures for representing maps to other terminologies and classifications. The Mapping Mechanism data structures are distributed as three tables:

  • Cross Map SetsTable
  • Cross MapsTable
  • Cross Map TargetsTable


A person who directly edits the logic definitions and other structures of the terminology; aka Clinical Editor or Terminology Manager.


  • SNOMED CT modeler

  • Modeller

  • SNOMED CT author


The process of editing logic definitions to reflect the meaning intended by the Fully SpecifiedName.


  • SNOMED CT modeling

  • Modelling

  • SNOMED CT authoring

Namespace identifier

A seven digit number allocated by the IHTSDO to an organization that is permitted to maintain a SNOMED CT Extension. The namespace identifier forms part of the SCTID allocated every component that originated as part of an Extension. Therefore, it prevents collision between SCTIDs issued by different organizations . The namespace-identifier indicates the provenance of each SNOMED CTcomponent.

Short format SCTIDs,which are used for components that originate in the InternationalRelease, do not include a namespace-identifier. In this case the partition identifier provides sufficient information
about the origin of the component


  • Extension namespace identifiers

  • NamespaceId


The second and third digits from the right of the string rendering of the SCTID. The value of the partition-identifier indicates the type of component that the SCTID identifies (e.g. Concept, Description, Relationship, etc) and also indicates whether the SCTID contains a namespace identifier.


  • PartitionId

Postcoordinated expression

Representation of a clinical meaning using a combination of two or more conceptidentifiers is referred to as


Some clinical meanings may be represented in several different ways. SNOMED CT technical specifications include guidance for transforming logical expressions to a common canonicalform.

Example:SNOMED CT includes the following concepts:

125605004 | fracture of bone |

363698007 | finding site |

71341001 | bone structure of femur |

SNOMEDCT also includes a precoordinatedconcept for 71620000 | fracture of femur |. Therefore It is possible to represent the clinical meaning "fracture of femur" in different ways:

  • as a precoordinatedexpression:

    • 71620000 | fracture of femur |

  • or as a postcoordinatedexpression:

    • 125605004 | fracture of bone | : 363698007 | finding site | = 71341001 | bone structure of femur |


  • Postcoordinated

  • Postcoordination

Precoordinated expression

Representation of a clinical meaning using a single concept identifier is referred to as a precoordinated expression.

Note: In contrast, expressions that contain two or more concepts Identifier are referred to as postcoordinated expressions. For more information and examples see the glossary entry for postcoordinatedexpression.


  • precoordinated expression

  • Precoordinated

  • Precoordination

Primitive concept

A concept with a formal logic definition that is not sufficient to distinguish its meaning from other similar concepts

The meaning of SNOMED CT concept is expressed in a human-readable form by its Fully SpecifiedName. Each concept also has a formal logic definition represented by a set of defining relationships to other concepts. This logic definition is computer processable. A primitiveconcept does not have sufficient defining relationships to computably distinguish them from more general concepts (supertypes). See also sufficiently defined concept.

Example: The concept 5596004|atypical appendicitis (disorder)| is primitive because the following definition is not sufficient to distinguish "atypical appendicitis" from any other type of "appendicitis".

  • •116680003 | is a | = 74400008 | appendicitis |
  • 116676008 | associated morphology | = 23583003 | inflammation |
  • 363698007 | finding site | = 66754008 | appendix structure |

Figure 15: Definition of: |atypical appendicitis (disorder)| (primitive)

Qualifying characteristic

An attribute-value relationship associated with a concept code to indicate to users that it may be applied to refine the meaning of the code. The set of qualifying relationships provide syntactically correct values that can be presented to a user for postcoordination. Example: 'Revision status ' = 'First revision' is a possible qualifying characteristic of 'Hip replacement'. A qualifying characteristic is contrasted with a defining characteristic. It is referred to in CTV3 as a 'Qualifier.


  • Qualifier


A sphere of authority, expertise, or preference that influences the range of components required, or the frequency with which they are used. A Realm may be a nation, an organization , a professional discipline, a specialty, or an individual user.


An association between a source concept and a destination concept. The nature of the association is indicated by a reference to another concept referred to as the relationshiptype.


  1. Each relationship provides information about the source concept. In the example below
  2. Relationships are represented by rows in the RelationshipFile


Table 90: Illustrative example of aRelationship


74400008 |

appendicitis |

363698007 |

finding site |

66754008 |


structure | 


  • SNOMED CT relationship

RelationshipType (field in RF2)

The nature of a Relationship between two Concepts. Relationship Types are represented in SNOMEDCT by Concept codes. In the RelationshipsTable, the RelationshipType field contains the ConceptId for the concept in SNOMEDCT that forms the relationship between two other concepts (ConceptId1 and ConceptId2). For defining and qualifying relationships, the RelationshipType is an Attribute code. RelationshipType should not be confused with CharacteristicType.

RelationshipId (field in RF2)

A SNOMEDCTIdentifier that uniquely identifies a Relationship. RelationshipId is the key of the Relationships Table. Each row in the Relationships Table represents a relationship triplet (ConceptId1 RelationshipType - ConceptId2).

Relationships table (RF1)

A data table consisting of rows, each of which represents a Relationship.


The content of a version of a SNOMEDCTEdition that has been made available to licensees at a particular point in time.

Root concept

The single concept that is at the top of the | SNOMED CT Concept | hierarchy.

Root metadata concept

The single concept that is at the top of the | SNOMED CT Model Component (metadata) | hierarchy.

Most of the data in the metadata hierarchy is only relevant to Release Format 2. Therefore, this
concept may not be present in some Release Format 1 files.


  • Root metadata code


An acronym for the SystematizedNomenclature of Medicine originally developed by the College of American Pathologists and now owned and maintained by the IHTSDO. SNOMED Clinical Terms is the most recent version of this terminology. It was preceded by SNOMED RT and SNOMEDInternational.

SNOMED Clinical Terms

SNOMED CT is a clinical terminology maintained and distributed by the IHTSDO. It is considered to be the most comprehensive, multilingual healthcare terminology in the world. It was created as a result of the merger of SNOMED RT and NHS Clinical Terms Version3.



Sufficiently defined concept

A concept with a formal logic definition that is sufficient to distinguish its meaning from other similar concepts.

The meaning of SNOMED CT concept is expressed in a human-readable form by its Fully SpecifiedName (FSN) and has a formal logic definition represented by a set of defining relationships to other concepts. A Sufficientlydefinedconcept has sufficient defining relationships to computably distinguish it from other concepts.

See also primitiveconcept.

Example: The concept 74400008|appendicitis (disorder)| is sufficiently defined by the following definition because any concept for which this definition was true would be the disorder "appendicitis".

  • 116680003 | is a | = 18526009 | disorder of appendix |
  • 116680003 | is a | = 302168000 | inflammation of large intestine |
  • 116676008 | associated morphology | = 23583003 | inflammation |
  • 363698007 | finding site | = 66754008 | appendix structure |

Figure 16: Definition of: |appendicitis (disorder)| (sufficiently defined)


  • Fully defined concept


A set of components which part of and fully included with a larger set (e.g. a specified set of Concepts or Descriptions)

  1. In Release Format 2 the standard way to represent a subset of components is by using a Simple ReferenceSet
  2. In Release Format 1 the term subset has the following special meaning:
    • A group of components (e.g. Concepts, Descriptions or Relationships) that share a specified common characteristic or common type of characteristic. Subsets represent information that affects the way the components are displayed or otherwise accessible within a particular realm, specialty, application or context.

This special meaning arose from the "Subset Mechanism" which has now been replaced by ReferenceSets. Therefore, except when referring to RF1 files the term subset should should now be used for its more correct general meeting.


A term that is an acceptable way to express a the meaning of a SNOMEDCTconcept in a particular language.

Synonyms are represented as SNOMEDCTdescriptions with the typeId value 900000000000013009

  1. Synonyms allow representations of the various ways a concept may be described.
  2. Synonyms (unlike fully specified names) are not necessarily unique because the same term can be used to describe more than one concept.
  3. The preferred term is the synonym marked as preferred for use in the Language reference set for a given language or dialect.

Top level concept code

A Concept Code that is directly related to the RootConcept Code by a single Relationship of the Relationship Type | is a |. All Concept Codes (except for metadata concepts) are descended from at least one Top-Level Concept Code via at least one series of Relationships of the Relationship Type"| Is a | ".

Top level metadata code

A Concept Code that is directly related to the RootMetadataCode by a single Relationship of the RelationshipType | is a |. All Metadata Concept Codes are descended from at least one Top-Level Metadata Concept Code via at least one series of Relationships of the Relationship Type " Is a | ".

Most of the data in the metadata hierarchy is only relevant to Release Format 2. Therefore, this concept may not be present in Release Format 1 files.