SNOMED CT is arranged as a polyhierarchy. A hierarchy is defined as an ordered organization of concept codes linked together through IS A relationships. Concept codes are linked to their more general parent concept codes directly above them in a hierarchy. Concepts with more general meanings are usually located at the top of the hierarchy and then at each level down the hierarchy the meanings become increasingly more specialized. 

Selected SNOMED CT attributes have a hierarchical relationship to one another known as attribute hierarchies. In an attribute hierarchy, one general attribute is the parent of one or more specific subtypes of that attribute. Concepts defined using the more general attribute can inherit concepts modeled with the more specialized subtypes of that attribute.


The following are the 19 domains arranged in alphabetical order. 

The following subhierarchies do not have concept models:  

  • Environment or geographical location (environment / location)
  • Organism (organism)
  • Physical force (physical force)
  • Qualifier value (qualifier value)
  • Record artifact (record artifact)
  • SNOMED CT Model Component (metadata)
  • Social context (social concept)
  • Special concept (special concept)
  • Staging and scales (staging scale)

HRCM Attribute Tables

The pages that follow contain tables that are generated by the Human Readable Concept Model (HRCM). The tables contain Attribute Summaries for those domains with attributes, information on Group(ed), Cardinality, and In-group cardinality, and Range constraints.  The HRCM tables in this guide only reflect the ranges for pre-coordinated concepts; there may be post-coordination values that are not reflected in the tables.   All MRCM values for concepts can be viewed via the public MRCM browser at

SNOMED International creates precoordinated content in accordance with the MRCM.  For postcoordinated content, extensions should review the MRCM.  If the MRCM does not specify that a particular value is allowed for a given content type (e.g. using an observable entity value for |Component| in a postcoordinated expression), then it must not be used in that content type (e.g. postcoordinated expressions). The MRCM rules for postcoordination must be strictly followed. This is important for interoperability, being able to query the resulting content consistently, etc. However, the MRCM does provide the option for extensions to extend or adapt the rules in a controlled way if required (see the last section of 6. Considerations). This includes expanding the ranges and/or adding new attributes where required. This needs to be done carefully to ensure consistency and data integrity between editions.

There are special cases in the MRCM where an attribute may have two rows.  This situation is caused by a new cardinality rule:  a row for existing/legacy SNOMED CT content and a row for newly created content.  The row that is applicable to new content will be marked by a "[New]" notation. 

See MRCM Maintenance Process.

Modeling: precoordination patterns

SNOMED CT relies on the rules for usefulness to avoid excessive precoordination (see Scope section of Editorial Guide).

Approved precoordination patterns have been created and are available at: Pre-coordination Naming Patterns Project. For additional information about the fields used in precoordination, see: What the fields in the Pre-coordination Naming Patterns JIRA Project mean.

  • No labels