Additional Notes
Hierarchies
All direct subtype children of except .
Purpose
These concepts represent a distinct type of clinical concept
Concept Addition Rules
Subtype descendants of the top level clinical concepts may be added in an extension.
Additional Notes
Concepts added in these hierarchies should conform with:
Concept model rules applicable to the relevant concept domain
Quality standards applicable to all SNOMED CT clinical content.
These concepts should be classified to generate a set of inferred relationships in necessary normal form, for inclusion in the extension distribution files.
The SNOMED CT International Edition contains some concept hierarchies that have fundamental roles in supporting the design of SNOMED CT. Additions of concepts to these hierarchies may impact the consistency and integrity of SNOMED CT. The following pages set out guidance on the addition of extension concepts within specific hierarchies. In some cases, this guidance may prohibit extensions from adding concepts in a specific hierarchy or at a particular level of a hierarchy. In other cases, the advice is provided on the use case for making particular additions and notes are included on the implications and potential risks arising from such additions.
These constraints are expressed in tables in the following pages, which are arranged to follow the overall hierarchical structure of SNOMED CT.
Concept Addition Rules
No new subtype children or descendants may be added in an extension.
Namespaces concepts can only be created by SNOMED International to represent allocated namespace identifiers.
Concept Addition Uses Cases
Extending the SNOMED CT concept model to allow sufficient definitions to be applied to concepts that are not sufficiently defined in the International Edition.
Additional Notes
Any attributes created in extensions need to be carefully managed and documented. Extension attributes may also need to be revised or inactivated to align with future changes to the concept model in the International Edition.
Concept Addition Uses Cases
Requirements to support additional types of assertion in clinical records
Hierarchy
Purpose
These concepts provide the values for Relationship.typeId and represent the type of a defining relationship.
Examples
Concept Addition Rules
Additional attributes may be added in an extension, where required to support extensions to the SNOMED CT concept model.
Hierarchy
Purpose
These concepts represent clinical assertions about relationships between instances of clinical statement in an EHR. For example, they may assert that a particular symptom is caused by something.
International Edition Examples
Concept Addition Rules
Additional subtype children may be added in an extension. However, it is recommended that proposed additions be submitted to the International Edition, unless they are highly specific.
Hierarchy
Purpose
This concept is the supertype for all SNOMED CT metadata.
Concept Addition Rules
No new subtype children may be added in an extension.
Please refer to the following pages for guidance on the addition of subtype descendants.
All SNOMED CT metadata concepts are subtypes of and include concepts, descriptions and relationships that are used to describe or provide additional information about SNOMED CT content and reference sets.
The table below lists the subtypes of the hierarchy, and describes the content within these subhierarchies.
Table: Subhierarchies of |SNOMED CT Model Component| and their intended purpose
The following pages provide information about the subtypes of . Each page includes tables which describe the purpose of the content within one of the sub-hierarchies, with examples from the International Edition. The tables also state rules about the additions that are permitted in an extension to the respective subhierarchy. Where additions are permitted to the subhierarchy, notes are added on practical uses cases for addition, potential problems that may arise from these additions and any other relevant considerations.
Concept Addition Uses Cases
To create a new reference set
To define a new reference set type
To define a group of related reference sets
Additional Notes
When a new reference set type is defined, an appropriate set of reference set descriptor rows must be created in the reference set descriptor reference set to specify the order and format of the reference set columns. Furthermore, the intended use and format of the new reference set type must also be documented.
Appropriate documentation should also be provided to describe the specific use of each individual reference set. The addition of reference set descriptor rows for individual reference sets is also recommended. However, this is optional if there are no additional constraints over and above those specified for its reference set type.
Hierarchy
Purpose
The subtype children represent reference set types. Subtype descendents represent either reference sets of the type specified by their supertype parent or groups of reference sets of a type specified by their supertype parent.
Examples
Reference set types
900000000000521006 | Association type|
(This is a grouper concept not an actual reference set)
Concept Addition Rules
New subtype children may be added in an extension, as long as they represent a new and distinct Reference Set Type (i.e. not an individual reference set).
New subtype descendants may be added in an extension, as long as they represent a Reference Set of the type defined by its supertype ancestors.
Hierarchy
Purpose
The subtype children represent named attributes used to represent columns in reference sets.
Also includes two special subtypes: 900000000000459000 | Attribute type| and 900000000000491004 | Attribute value| which are separately documented.
Examples
Concept Addition Rules
Hierarchy
Purpose
These concepts represent data types associated with reference set attributes.
Examples
Concept Addition Rules
Hierarchy
Purpose
These concepts represent values that can be applied to specified columns in a reference set.
Concept Addition Rules
Additional subtype children may be added in an extension to represent values applicable to a newly added reference set or reference set type.
Subtype descendants should not be added in an extension, except where they are descendants of a subtype child added to support a newly added reference set.
Potential Problems
Subtype children can be added in an extension to represent new column names for use in additional reference set type definitions.
See separate notes on subtype descendance of the special subtypes and
No new subtype children or subtype descendants may be added in an extension.
If new subtypes are required these should be requested for addition to the International Edition.
Adding subtype descendant to pre-existing subtype children would have the effect of changing the permitted value set for a pre-existing reference set type and reference sets defined as having that type.
Linkage concept (linkage concept)
Links two or more concepts together to express compositional meanings. All concept codes that can be used as a Relationship Type are included under [
Namespace concept (namespace concept)
Contains concepts that represent an assigned Extension namespace identifier.
OWL metadata concept (OWL metadata concept)
Contains concepts that are used in
OWL ontology reference set (OWL ontology header (OWL metadata concept) and OWL ontology namespace (OWL metadata concept))
OWL axiom reference set (Disjoint classes axiom (OWL metadata concept) and General concept inclusion axiom (OWL metadata concept))
Core metadata concept (core metadata concept)
Provides structural information required to support International Edition data. This supporting information includes sets of enumerated values that apply to attributes of concepts, descriptions and relationships.
Foundation metadata concept (foundation metadata concept)
Provides supporting metadata and structural information for Reference Sets.
Hierarchy
Purpose
This subhierarchy provides the values for Relationship.characteristicTypeId.
Examples
Concept Addition Rules
No new subtype descendants may be added in an extension.
Hierarchy
Purpose
This subhierarchy provides the values for Concept.definitionStatusId
Examples
Concept Addition Rules
Hierarchy
Purpose
This subhierarchy provides the values for Description.typeId
Examples
Concept Addition Rules
Hierarchy
Purpose
This subhierarchy provides the values for Relationship.modifierId
Examples
Concept Addition Rules
Hierarchy
Purpose
This subhierarchy provides the concepts used to identify modules
Examples
Concept Addition Rules
Hierarchy
Purpose
This concept is the supertype for metadata used directly by SNOMED CT components.
Concept Addition Rules
No new subtype children may be added in an extension.
See tables below for concept addition rules for each of the subtypes of 900000000000442005 | Core metadata concept| .
No new subtype descendants may be added in an extension.
Additional types permitted provided these are additive and do not replace the synonym or fully specified name values
Concept Addition Uses Cases
Different lengths of text for different purposes
Different formats for text including HTML
Specialized usage of text for a specific purpose
No new subtype descendants may be added in an extension.
The addition of modules that form part of the extension is required. These new module concepts must either be direct children of or descendants of a child of that is owned by the same extension provider. It is not permitted to add modules as subtypes of modules maintained by another extension provider.
Each module concept added within an extension must have an identifier that contains the extension's namespace identifier.
Concept Addition Uses Cases
The addition of at least one module concept is essential for all extensions. More than one module concept may be added to enable content to be organized into separate modules.