In this chapter, we describe the logical design of the SNOMED CT MRCM.
Each SNOMED CT Module may have a concept model that is captured using a MRCM. A MRCM contains a set of domains and a set of attributes, which may be applied to one or more domains. The MRCM specifies the cardinality and valid range of each attribute, and indicates whether or not the attribute should be grouped. The domain, range, cardinality and grouped indicator for each attribute is also combined into a single 'attribute rule', which is represented using a SNOMED CT Expression Constraint. For each domain, the set of valid attributes and their associated rules are compiled into two SNOMED CT 'domain templates' – for precoordinated concept authoring and postcoordinated expression authoring respectively. These domain templates may be further specialized to support customized authoring of specific subdomains.
The figure below illustrates the major components of the MRCM described above.
Abstract Model of the SNOMED CT MRCM
Details
The figure below illustrates the logical design of the SNOMED CT MRCM using a UML class diagram.
Logical Model of the SNOMED CT MRCM
This UML class diagram illustrates that a SNOMED CT Edition contains a set of modules, which may each be associated with a set of MRCM domains and attribute rules.
Each domain has exactly one domainConstraint represented using a SNOMED CT Expression Constraint (which specifies the valid concepts in the domain). A domain also has a proximalPrimitiveConstraint (which specifies the domain constraint used for proximal primitive modelling in this domain), a proximalPrimitiveRefinement (which specifies any mandatory refinements that must be applied when proximal primitive modelling in this domain) , a precoordinatedDomainTemplate (which provides a general template of all possible attributes that may be applied to this domain when defining a precoordinated concept), and a postcoordinatedDomainTemplate (which provides a general template of all possible attributes that may be applied to this domain when defining a postcoordinated expression). A domain also includes a reference to where further human-readable information about the domain is captured within the Editorial Guide.
Each attribute rule is associated with a specific rule strength (e.g. ) and content type (e.g. ). An Attribute Rule may either associate an attribute with the domains to which it may be applied (i.e. an Attribute Domain Rule), or it may associate an attribute with the range of valid concepts that may be used as its value (i.e. an Attribute Range Rule). Attribute Domain Rules also define whether or not each attribute is considered to be grouped (by a Description Logic reasoner) for the given domain, and the attribute cardinalities for that domain.
The MRCM distribution format (as illustrated below) includes the following reference set types:
MRCM Domain Reference Set
MRCM Attribute Domain Reference Set
MRCM Attribute Range Reference Set
MRCM Module Scope Reference Set
In this section, we will define and describe these reference set types. Further design considerations, such as versioning and localization, will be discussed in .
Requirements
In this section, we present the key requirements of the SNOMED CT MRCM. These requirements are grouped into 'constraint requirements' and 'design requirements'.
The constraint requirements for the SNOMED CT MRCM include:
The MRCM must be able to specify the set of concepts to which a given attribute may be applied.
The MRCM must be able to specify the set of concepts which may be used as the value for a given attribute.
The MRCM must be able to specify the minimum and maximum number of times that a given attribute may appear in a concept definition. Additionally, it must be able to specify the minimum and maximum number of times that a given attribute may appear in each relationship group in a concept definition.
The MRCM must be able to specify whether an attribute may or may not belong to a relationship group.
The MRCM should indicate the strength with which each rule should be applied – for example, whether a rule is mandatory (resulting in an error), or optional (resulting in a warning).
There should be a clear specification of which concept model rules apply to a given SNOMED CT module.
The design requirements for the SNOMED CT MRCM include:
In order to facilitate easy adoption, the MRCM must represent the concept model rules in a form that is machine computable.
The MRCM must be computationally transformable into a representation that is human readable, to support human review, validation, education and understanding of the rules. Additional text explaining the rules should be able to be added to further aid its understanding.
The MRCM must provide an unambiguous representation of the SNOMED CT concept model rules.
The MRCM must be useful in supporting the use cases described in Chapter 2, including the authoring and validation of SNOMED CT concepts, expressions, constraints and queries, natural language processing (NLP) and terminology binding.
The SNOMED CT concept model rules must be able to be changed between releases to fix identified issues and enhance future releases (in conjunction with clear editorial guidelines). As such, the MRCM must be versioned to retain a history of changes, and to enable the concept model to evolve gracefully over time.
The international MRCM rules defined by the IHTSDO must be able to be extended and adapted by organizations developing SNOMED CT extensions, to support the concept model requirements of their extension content. This may include the addition of new attributes, the addition of new rules, and the customization of existing rules. Principles need to be defined as to how MRCM rules may be extended and adapted, to ensure consistency and data integrity between SNOMED CT editions.
The design of the MRCM should be consistent with existing SNOMED CT formats and languages, including the SNOMED CT Release Format 2 (RF2) and the SNOMED CT Expression Constraint Language. The goals of appropriate use of existing formats and languages include:
Leverage the work that has already been performed to support common requirements, such as versioning and intensional constraint definition,
Make it easier for the SNOMED CT community to understand the design and correctly interpret the meaning of the MRCM rules,
Facilitate the easier adoption of the MRCM rules by existing SNOMED CT implementers, and
Allow common terminology services to be reused to support the implementation of the MRCM.
Requirement D.7 : Consistency with existing SNOMED CT formats and languages
Introduction
Background
SNOMED CT is a clinical terminology with a comprehensive scope covering a wide range of clinical specialties and requirements. The SNOMED CT Concept Model is a set of rules that govern the ways in which SNOMED CT concepts are permitted to be modelled using relationships to other concepts. These rules are critical to the consistent modelling of SNOMED CT content, which in turn determines the extent to which reproducible logical inferences can be drawn. These logical inferences are the foundation for effective use of SNOMED CT for retrieval and reuse of clinical information.
The Machine Readable Concept Model (MRCM) represents rules in the SNOMED CT concept model in a form that can be read by a computer and applied to test that concept definitions and expressions comply with the rules. The MRCM may be used for a variety of purposes, including the authoring and validation of SNOMED CT concepts, expressions, expression constraints and queries, Natural Language Processing and terminology binding to support semantic interoperability.
History
In 2007, IHTSDO approved a project to develop a prototype MRCM for SNOMED CT. In 2009, a MRCM draft release 0.1 was published containing 234 constraints, including domain, range and cardinality constraints. This draft MRCM was released in two formats - an XML representation, and a set of MS-Access 2007 database files. It also came with a prototype MRCM browser and editor written in MS-Access.
Since then, two important developments have occurred. Firstly, in 2012 a new standard distribution format for SNOMED CT (Release Format 2) began to be used. Release Format 2 (RF2) included a few key enhancements, including more robust and consistent version representation, an extensibility mechanism called 'reference sets', and a new hierarchy to represent metadata about the structure of SNOMED CT. Secondly, in 2015, the first official version of the Expression Constraint Language was published, replacing earlier informal constraint representations. These two developments have provided the opportunity for the SNOMED CT MRCM to be developed in a more standardized, consistent and version controlled way than was previously possible.
In January 2017, the beta release of the international SNOMED CT MRCM was published, and a period of community evaluation followed.
The first production version of the international SNOMED CT MRCM will be released as part of the July release (20170731) of the SNOMED CT international edition.
The purpose of this document is to define and describe the structural design of the SNOMED CT MRCM, and to discuss the background and considerations that were taken into account during its design.
This document presents the specification of the SNOMED CT MRCM, including the reference sets and attributes used to represent and distribute the international SNOMED CT MRCM. It also documents the background, use cases, requirements and design considerations, including versioning and extensibility of the MRCM.
While the document refers to the RF2 format and the Expression Constraint Language, the specification of these standards are out of scope. Additionally, this document does not go into details about how to implement the MRCM within a terminology authoring or Electronic Health Record environment.
The scope of the MRCM includes rules that define the domain, range, cardinality and groupability of each attribute in the SNOMED CT concept model. Other related information, such as property chains (including attribute transitivity), expression templates for authoring, and description templates are not within the scope of the MRCM.
The target audiences of this document include:
SNOMED National Release Centers;
SNOMED CT terminology developers, including content authors, concept model designers, map developers, subset and constraint developers and release process managers;
SNOMED CT implementation designers and developers, including designers and developers of EHR systems, terminology services, decision support systems, retrieval and analysis systems, and healthcare information standards.
This document presents the design of the SNOMED CT MRCM. Chapter 2 begins by describing the use cases in which it is anticipated that the SNOMED CT MRCM may be used. Chapter 3 then describes the requirements used to guide the MRCM design. The logical design of the MRCM is then described in Chapter 4, followed by the design of the reference sets used to distribute the MRCM rules in Chapter 5. Chapter 6 then discusses a range of topics that were considered in the design of the MRCM.
The following table contains the definition of terms used within this document. Please refer to the for additional definitions.
Term
Definition
A structured combination of one or more concept identifiers used to express a clinical idea.
A computable rule that can be used to define a bounded set of clinical meanings.
A representation of the rules that comprise the SNOMED CT Concept Model in a form that can be processed by computer software and applied to validate content.
A representation of a clinical meaning using a combination of two or more concept identifiers.
A representation of a clinical meaning using a single concept identifier.
The set of concepts that are allowed as the value of an attribute.
A SNOMED CT file structure consisting of a set of references to SNOMED CT components.
The SNOMED CT content over which an expression constraint is evaluated or a query is executed.
The set of rules that govern the way in which SNOMED CT expressions are represented as a plain text string.
A set of rules that determines the permitted sets of relationships between particular types of concepts.
The set of concepts which may be refined using a given attribute.
The SNOMED CT Concept Model is a set of rules that govern the ways in which SNOMED CT concepts are permitted to be modelled. The Machine Readable Concept Model (MRCM) represents these concept model rules in a machine readable form. The SNOMED CT MRCM may be useful in a number of use cases, including:
Development of precoordinated terminology content;
Authoring and validation of SNOMED CT expressions, constraints and queries;
Natural Language Processing;
Terminology binding to information models, for purposes such as data capture and semantic interoperability.
In the following subsections, we describe each of these key use cases.
One of the key uses of the SNOMED CT MRCM is to assist in the consistent development of precoordinated terminology content. This includes terminology content authoring, validation and testing. The authoring and validation of SNOMED CT content may be performed in the SNOMED CT International Edition or in a SNOMED CT Edition that incorporates one or more National or Local extensions. In the case of the International Edition, the SNOMED CT International concept model will be used. Other SNOMED CT Editions may be authored and validated using either the international concept model or an alternative concept model that has been customized to meet specific national or local requirements, while ensuring consistency and data integrity between editions is maintained.
When precoordinated SNOMED CT concepts are authored, the MRCM can be used to suggest the possible attributes that may be used to define a concept, based on the hierarchy or subhierarchy it belongs to. The MRCM can also assist in limiting the number of times each attribute can be used in a concept definition, and restricting the possible value of these attributes to the valid range.
An example scenario, in which the MRCM is being used during concept authoring, is:
Author creates a concept, with fully specified name and synonyms;
Author assigns one or more supertypes for the concept;
The MRCM is used to determine the domains to which a concept belongs, based on its supertypes;
In addition to its use during concept authoring, the MRCM can also assist in the validation of concept definitions, by enabling the testing of defining relationships against the rules in the concept model. The MRCM can also enable significant optimizations for batch terminology content validation, by minimizing the repetition of processing through the appropriate selection of relationships to be tested.
In a similar way, the MRCM can be used to enable effective testing of proposed changes to the Concept Model.
In a similar way, the SNOMED CT MRCM can be used to assist the authoring and validation of SNOMED CT postcoordinated expressions, SNOMED CT expression constraints, or SNOMED CT queries.
When authoring expressions, constraints or queries, the MRCM can be used to suggest possible attributes that may be applied to the selected focus concepts. Similarly to the authoring of precoordinated content, the MRCM can also restrict the possible value of each attribute refinement to the valid range.
The use of MRCM cardinality constraints differs between expressions, expression constraints and queries. When authoring postcoordinated expressions, an attribute cardinality constraint may be used to limit the number of times each attribute can be used in each concept definition. When authoring expression constraints and queries, however, the MRCM cardinality constraints serves to influence the cardinality constraints that are appropriate to apply to specific attribute refinements.
The SNOMED CT MRCM can also be used to validate expressions, expression constraints and queries to confirm that they conform to the expected concept model rules. In the case of close-to-user expressions, these rules may be less strict to support additional flexibility of expression (including allowing 'laterality' to be applied to a clinical finding that is defined using a lateralizable finding site).
As with precoordinated content, the authoring and validation of SNOMED CT expressions, expression constraints and queries can be performed using the international MRCM rules, or using the rules from a localized MRCM.
Natural Language Processing (NLP) enables a computer program to analyze and extract meaning from human language. When processing clinical free text using a NLP tool, SNOMED CT's concepts, relationships and descriptions can be used to extract the clinical meaning that has been captured.
The SNOMED CT concept model can also be used to identify potential connections between words and possible postcoordination opportunities. For example, if a term such as 'open fracture' (which is found to be a ) occurs in close proximity to the term 'femur' (which is found to be an ), then this may indicate that there is a 'finding site' relationship between the concepts. By capturing the concept model rules in a machine-processable way, the SNOMED CT MRCM can be used to assist a range of NLP-supported tasks, including:
Encoding clinical free text using SNOMED CT expressions;
Indexing and retrieving large repositories of clinical healthcare information and knowledge;
Searching;
For more information on using SNOMED CT in Natural Language Processing, please refer to .
When binding SNOMED CT to information models, it is important to ensure that the bindings are consistent (at least at a high level) with the SNOMED CT concept model. Terminology binding using the MRCM may be used to support a range of purposes, from data capture on the user interface through to data integration and semantic interoperability.
There are two main types of terminology binding:
Value set bindings, which record the set of possible values that can be used to populate a coded data element or attribute;
Model meaning bindings, which define the meaning of an information model artifact using terminology.
Value set bindings that correspond to a particular concept model attribute (e.g. ) can be designed to be consistent with the appropriate attribute range (e.g. < ) defined in the MRCM. Similarly, the MRCM can be used to suggest possible model meaning bindings for an information model, to suggest new data elements that could be added (at either design time or runtime) to represent relevant attribute refinements, and to test existing model meaning bindings for consistency with the concept model.
Expression templates (designed with the support of the MRCM) can also be used to define a canonical representation of meaning for an information model, where this meaning may be recorded either using a single precoordinated concept, or using multiple data elements. This can provide a useful mechanism to support consistent querying of data that has been integrated from multiple sources, and to support semantic interoperability in general.
The MRCM is used to determine the appropriate attributes, ranges and cardinality for the given domain;
The author is allowed to assign an appropriate number of values to each of the attributes, from the relevant range, subject to the associated cardinality constraints.
Analyzing clinical phrases entered into a health record to suggest potential postcoordinated expressions that may match the intended clinical meaning;
Analyzing search terms to determine the strength of the semantic relationship to matching records or documents.
An 723563008 | MRCM module scope reference set| specifies the set of MRCM reference sets that should be applied to the content in each module. Within a SNOMED CT Edition, the MRCM rules applied to the included modules must be consistent, to ensure data integrity within an edition is maintained.
A 128 bit unsigned Integer, uniquely identifying this reference set member.
Different versions of a reference set member share the same id but have different effectiveTime. This allows a reference set member to be modified or made inactive (i.e. removed from the active set) at a specified time.
NO
YES
(Full /Snapshot)
effectiveTime
Time
The inclusive date or time at which this version of the identified reference set member became the current version.
Note: In distribution files the effectiveTime should follow the short ISO date format (YYYYMMDD) and should not include the hours, minutes, seconds or timezone indicator.
The current version of this reference set member at time T is the version with the most recent effectiveTime prior to or equal to time T .
YES
YES (Full)
Optional (Snapshot)
active
Boolean
The state of the identified reference set member as at the specified effectiveTime .
If active = 1 (true) the reference set member is part of the current version of the set, if active = 0 (false) the reference set member is not part of the current version of the set.
YES
NO
moduleId
SCTID
Identifies the SNOMED CT module that contains this reference set member as at the specified effectiveTime .
A reference to the SNOMED CT component to be included in the reference set.
Identifies the SNOMED CT module to which the given concept model refset is applied.
The value must be a subtype of 900000000000443000 | Module| within the metadata hierarchy.
NO
NO
mrcmRuleRefsetId
SCTID
A subtype of 723564002 | MRCM reference set| that defines the concept model rules that are applied to content in the module identified by referencedComponentId.
Notes on the tables used to show descriptors and examples
The reference set example tables on this page have been revised as follows to aid clarity and understanding:
The first four columns which are present in all release files are not shown. The omitted columns (id, effectiveTime, active, moduleId) are used in the same way in all referenced sets to support identification, versioning and packaging. They do not directly affect the specific features of a particular reference set or reference set type.
Reference set columns that contain SNOMED CT identifiers are expanded to show details of the concept or description referenced by that identifier. In some cases, the term is shown in the same column using the expression syntax, in other cases an additional column with a name suffix '_term' has been added. In the standard reference set files only the identifier is present in the column and there is no added column for the term. When using reference sets, the term and other details of the component are looked up from the relevant component release files.
In this section, we discuss a range of topics that were considered in the design of the SNOMED CT MRCM, including:
How the MRCM will be authored and quality checked,
How the MRCM will be used to support the use cases described in Use Cases,
How the MRCM will be versioned when corrections or enhancements are made, and
How the MRCM can be extended and adapted for use with SNOMED CT extensions.
The MRCM has been designed to include minimal redundancy, to make the authoring and maintenance of these rules less error-prone. For example, by using separate reference sets to represent the attribute domains and ranges, each range does not need to be repeated for each of the attribute's domains.
To support implementers who prefer to process string-based representations of the rules, three MRCM attributes have been provided that concatenate information from other fields (as per the table below). These attributes have been populated automatically to avoid inconsistencies between the structural and string-based representations of the rules. The MRCM attributes that may be generated from other attributes are:
MRCM Reference Set
Attribute
In addition, the quality of the international SNOMED CT MRCM is checked using a range of mechanisms, including:
Manual review, supported by the inclusion of human-readable terms for each concept identifier in the reference sets;
Automated testing, including checks for the following:
All MRCM reference sets conform to the associated Descriptor Template,
Another important consideration in the design of the MRCM is how it can best be used to support the range of anticipated use cases. In this section, we describe the ways in which the MRCM design supports each of the use cases presented in .
As described in , one of the key use cases for the SNOMED CT MRCM is to assist with the consistent authoring and validation of SNOMED CT concepts.
To support the authoring and validation of SNOMED CT precoordinated content, the following MRCM process can be used:
Identify the parents of the concept being authored;
Please note - Either proximal primitive parents or proximal parents may be selected, depending on the authoring approach used;
Determine which domains the parent concepts belong to using the .
Please note that when the above process is being applied to the authoring of new precoordinated content, then only rules with a contentType = << may be used. However, when the process is applied to the validation of (both new and existing) precoordinated content, only rules with a contentType = << may be used. Rules with a ruleStrength of should be enforced when authoring and cause an error during validation, while rules with a ruleStrength of should be used as a recommendation for authoring and result in a warning during validation.
An alternative approach to authoring and validating precoordinated concepts is to use the domainTemplateForPrecoordination from the to ensure compliance with the full set of attribute rules. The domainTemplateForPrecoordination can also be specialized into a concept authoring template that meets the needs of a subclass of concepts, while still conforming to the overall rules of the domain.
Other features provided by the MRCM that are helpful for precoordinated content development include:
The and the use domains defined in terms of a single top-level hierarchy. This enables concepts being authored to be tested for subsumption with each domain concept, using techniques that are relatively simple to implement (e.g. using a transitive closure table).
The includes a set of attribute rules that combine the domain, grouping, cardinality and range constraints into a single expression constraint, which can facilitate the efficient implementation of content validation.
The ruleStrengthId attribute in the and the allows both mandatory rules (resulting in errors) and optional rules (resulting in warnings) to be specified.
describes using the SNOMED CT MRCM to assist the authoring and validation of SNOMED CT postcoordinated expressions, SNOMED CT expression constraints, and SNOMED CT queries. These languages allow one or more focus concepts to be defined, which when tested against a domain in the MRCM enables possible attribute refinements, cardinalities and valid ranges to be found.
To support the authoring and validation of SNOMED CT postcoordinated expressions the following MRCM process can be used:
Determine which domains the expression belongs to using the
An expression belongs to a given domain if any focus concept is either:
Valid when tested against the associated domainConstraint; or
Please note that in the above process only rules with a contentType = << should be used. Rules with a ruleStrength of should be enforced when authoring and cause an error during validation, while rules with a ruleStrength of should be used as a recommendation for authoring and result in a warning during validation.
An alternative approach to authoring and validating postcoordinated expressions is to use the domainTemplateForPostcoordination from the to ensure compliance with the full set of attribute rules. The domainTemplateForPostcoordination can also be specialized into an expression authoring template that meets the needs of a particular use case, while still conforming to the overall rules of the domain.
To support the authoring and validation of SNOMED CT expression constraints and queries the following MRCM process can be used:
Determine which domains the constraint or query belongs to using the
An expression constraint or query belongs to a given domain if either:
Any focus concept is valid when tested against the associated proximalPrimitiveConstraint; or
Please note that if the expression constraint or query is being applied to a substrate that includes only precoordinated content, then only the MRCM rules with a contentType = << should be used. However, if the expression constraint or query is being applied to a substrate that may include both precoordinated and postcoordinated content, then the less restrictive rules (e.g. with broader ranges) that apply where contentType = << may be used. Rules with a ruleStrength of should be enforced when authoring and cause an error during validation, while rules with a ruleStrength of should be used as a recommendation for authoring and result in a warning during validation.
The MRCM can also be used to support Natural Language Processing (NLP), as described in . When terms used in free text are associated with a particular SNOMED CT concept, this concept can be tested for membership in specific MRCM domains using the process above for authoring postcoordinated expressions. As per this process, if the concept is found to belong to one of the domains, then the can be used to determine its possible attributes, and the used to determine the valid values of these attributes. This process can thus be used to indicate possible ways in which the discovered concept may be linked (via suitable SNOMED CT attributes) to concepts found in the surrounding text.
Optimizations to the MRCM rules may also be adopted by NLP implementations to simplify the testing of membership in a potential range. For example, each range constraint could be split into its separate subhierarchies to allow simple techniques, such as a transitive closure table, to be used.
For more information on using SNOMED CT in Natural Language Processing, please refer to .
describes using the MRCM to suggest possible SNOMED CT terminology bindings for an information model, to ensure that the bindings are consistent (at least at a high level) with the SNOMED CT concept model, and to support the design of expression templates.
The processes above for authoring SNOMED CT postcoordinated expressions, expression constraints and queries can similarly be applied to support terminology binding. Alternatively, new use case specific MRCM reference sets could be developed, which restrict the available attributes and ranges that may be used in a specific implementation scenario.
As mentioned in (D.5), the concept model must be able to be changed between releases to fix identified issues and enhance future releases.
The RF2 reference set format used in the design of the MRCM provides a standard way of versioning the MRCM and retaining a history of changes, to enable the concept model to evolve over time. Using this standard approach, the effectiveTime field is used to reflect the date on which each rule version comes into effect, while the active field is used to indicate whether a rule is active or inactive. A new version of an MRCM rule may be created to update the mutable fields in the reference set, while changing immutable fields requires the rule to be inactivated, and a new rule to be created.
When a new or updated rule is introduced to the MRCM, it may take a period of time before all existing content conforms to the new rule. In these situations, a content type of can be used, to ensure that all new content obeys the rule. Over time, as the old content is updated to reflect the new rule, the content type may be changed to either or . This approach can be used to ensure that all new content added to SNOMED CT conforms to high quality concept model rules, even though reviewing and correcting existing content may take additional time.
As described in (D.6), the international MRCM rules defined by SNOMED International must be able to be extended and adapted by organizations developing SNOMED CT extensions, to support the concept model requirements of their extension content.
To support this requirement, SNOMED CT extension developers will be able to copy the international MRCM rules defined by SNOMED International into one or more extension MRCM reference sets and edit these reference sets to add new rules and restrict or extend the existing rules as required. New MRCM reference sets created for a SNOMED CT extension must be designed to ensure consistency and data integrity between editions. Please note that if no changes to the SNOMED CT concept model are required to support an extension, no additional MRCM reference sets need to be created, as the international MRCM can be reused by the extension.
The is designed to allow extension developers to specify which MRCM reference sets should be applied to the content in each module. The should therefore be referred to, to determine whether an extension is reusing the international MRCM, or using a customized extension MRCM to support its content.
All concept identifiers refer to active concepts in the relevant SNOMED CT international edition,
All concept identifiers refer to concepts from a value set appropriate for that field,
All parsable strings (e.g. expression constraints) are syntactically valid (based on the associated ABNF syntax) and refer to concepts that are active in the relevant SNOMED CT international edition,
Feedback from direct use by SNOMED International staff in the SNOMED CT authoring tools, and
Feedback from the SNOMED CT member, vendor and user communities.
If the proximal parent modelling approach is used, the stated parents should be tested for membership in each domain using the domainConstraint;
If the proximal primitive parent modelling approach is used, the stated parents should be tested for membership in each domain using the proximalPrimitiveConstraint and all required refinements in the proximalPrimitiveRefinement should match at least one defining relationship stated on the concept being authored;\
Please note - If any of the proximal parents belong to a given domain, then the authored concept belongs to that domain.
Please note - Irrespective of the modelling approach used, the concept being authored can be tested for membership in a domain by checking if its inferred parents (i.e. after classification) are valid against the associated domainConstraint.
Determine the set of valid attributes for the given domains using the | MRCM attribute domain reference set| and allow defining relationships to be added from this set;
For each attribute used to define the concept, ensure that the grouping and cardinality are valid according to the rules specified in | MRCM attribute domain reference set| for the given attribute and parent domain;
– for rules which apply to newly authored (i.e. stated) precoordinated content, which may not necessarily be valid for all existing content; and
– for rules which apply to all postcoordinated content (but not to precoordinated content).
Valid when tested against the associated proximalPrimitiveConstraint and all required refinements in the proximalPrimitiveRefinement either match a defining relationship on the given focus concept, or match a refinement condition added to the expression being authored;
Determine the set of valid attributes for the given domains using the | MRCM attribute domain reference set| and allow refinements to be added using attribute concepts from this set;
For each attribute used to define the concept, ensure that the grouping and cardinality are valid according to the rules specified in | MRCM attribute domain reference set| for the given attribute and parent domain;
The constraint or query belongs to a parent domain of the given domain.
Please note: The concept model requirements for constraints and queries are more relaxed than those for postcoordinated expressions, because their role is to define the membership of a set of concepts or expressions, rather than restrict the manner in which a single concept or expression may be defined.
Determine the set of valid attributes for the given domains using the | MRCM attribute domain reference set| and allow refinements to be added using attribute concepts from this set;
For each attribute used to define the concept, ensure that the grouping and cardinality are consistent with the rules specified in | MRCM attribute domain reference set| for the given attribute and parent domain. In particular:
An attribute should only be grouped in an expression constraint or query if it specified as grouped = 1 for that domain in | MRCM attribute domain reference set| . Any attribute can appear as ungrouped in an expression constraints.
A cardinality constraint used in an expression constraint or query should be the same, or stricter than the cardinality specified for the given attribute and domain in | MRCM attribute domain reference set| .
Each attribute is identified by its concept id, while each domain is identified by the same concept id used in the referencedComponentId of the 723589008 | MRCM domain reference set| .
The column entitled PK indicates if the attribute is part of the primary key of thi
Field
Data type
Purpose
Mutable
PK*
The following metadata hierarchy supports this reference set:
The table below shows the reference set descriptor for a reference set that follows the pattern.
refsetId
referencedComponentId
attributeDescription
attributeType
attribute Order
The table below shows some example rows from a reference set that follows the format of the .
refsetId
referencedComponentId
domainId
grouped
attribute Cardinality
attribute InGroup Cardinality
ruleStrengthId
contentTypeId
Boolean
The state of the identified reference set member as at the specified effectiveTime .
If active = 1 (true) the reference set member is part of the current version of the set, if active = 0 (false) the reference set member is not part of the current version of the set.
YES
NO
moduleId
SCTID
Identifies the SNOMED CT module that contains this reference set member as at the specified effectiveTime .
The value must be a subtype of within the metadata hierarchy.
YES
NO
refsetId
SCTID
Identifies the reference set to which this reference set member belongs.
In this case, a subtype descendant of:
NO
NO
referencedComponentId
SCTID
A reference to the SNOMED CT component to be included in the reference set. A reference to the SNOMED CT attribute concept to which the attribute-domain rule defined by this member applies.
NO
NO
domainId
SCTID
A reference to the SNOMED CT concept that identifies the relevant concept domain.
NO
NO
grouped
Boolean
Whether or not the given attribute (identified by referencedComponentId) is treated by a Description Logic reasoner as belonging to a relationship group, when applied to a concept in the given domain.
If grouped = 1 (true) then the given attribute (identified by referencedComponentId) is treated by a Description Logic reasoner as belonging to a relationship group.
If grouped = 0 (false) then the given attribute (identified by referencedComponentId) is treated by a Description Logic reasoner as not belonging to a relationship group.
YES
NO
attributeCardinality
string
The number of times the given attribute can be assigned a distinct (non-redundant) value within the definition of each concept or expression.
This string can be parsed using the following ABNF rule (together with the subrules defined in the Expression Constraint Language):
attributeCardinality = minimum to maximum
YES
NO
attributeInGroupCardinality
string
The number of times the given attribute can be assigned a distinct (non-redundant) value within a single relationship group as part of the definition of a concept or expression.
This string can be parsed using the following ABNF rule (together with the subrules defined in the Expression Constraint Language):
attributeInGroupCardinality = minimum to maximum
YES
NO
ruleStrengthId
SCTID
A subtype of which specifies whether the given rule is mandatory (resulting in an error) or optional (resulting in a warning).
YES
NO
contentTypeId
SCTID
A subtype of which indicates the type of SNOMED CT content over which this rule applies. In many cases, this will be set to .
A 128 bit unsigned Integer, uniquely identifying this reference set member.
Different versions of a reference set member share the same id but have different effectiveTime. This allows a reference set member to be modified or made inactive (i.e. removed from the active set) at a specified time.
NO
YES
(Full /Snapshot)
effectiveTime
Time
The inclusive date or time at which this version of the identified reference set member became the current version.
Note: In distribution files the effectiveTime should follow the short ISO date format (YYYYMMDD) and should not include the hours, minutes, seconds or timezone indicator.
The current version of this reference set member at time T is the version with the most recent effectiveTime prior to or equal to time T .
Notes on the tables used to show descriptors and examples
The reference set example tables on this page have been revised as follows to aid clarity and understanding:
The first four columns which are present in all release files are not shown. The omitted columns (id, effectiveTime, active, moduleId) are used in the same way in all referenced sets to support identification, versioning and packaging. They do not directly affect the specific features of a particular reference set or reference set type.
Reference set columns that contain SNOMED CT identifiers are expanded to show details of the concept or description referenced by that identifier. In some cases, the term is shown in the same column using the expression syntax, in other cases an additional column with a name suffix '_term' has been added. In the standard reference set files only the identifier is present in the column and there is no added column for the term. When using reference sets, the term and other details of the component are looked up from the relevant component release files.
Descriptor Template
Note to table:
The column entitles PK indicates if the attribute is part of the primary key of this table.
An 723592007 | MRCM attribute range reference set| allows attributes to be associated with a valid value range for a given SNOMED CT content type and rule strength. The range of each attribute is defined using an Expression Constraint. This expression constraint represents the set of concepts, expressions, or concrete values that may be used as the value of the given attribute.
The 723592007 | MRCM attribute range reference set| also provides a summary of the concept model rule associated with each attribute (including all valid domains and the given range) using an Expression Constraint representation. This attribute rule can be completely auto-generated by combining information from the 723604009 | MRCM attribute domain reference set| and the 723592007 | MRCM attribute range reference set| .
The column entitled PK indicates if the attribute is part of the primary key of this table.
Field
Data type
Purpose
Mutable
PK
The following metadata hierarchy supports this reference set:
The table below shows the reference set descriptor for a reference set that follows the pattern.
refsetId
referencedComponentId
attributeDescription
attributeType
attributeOrder
The table below shows some example rows from a reference set that follows the format of the .
refsetId
referencedComponentId
rangeConstraint
attributeRule
ruleStrengthId
contentTypeId
Boolean
The state of the identified reference set member as at the specified effectiveTime .
If active = 1 (true) the reference set member is part of the current version of the set, if active = 0 (false) the reference set member is not part of the current version of the set.
YES
NO
moduleId
SCTID
Identifies the SNOMED CT module that contains this reference set member as at the specified effectiveTime .
The value must be a subtype of within the metadata hierarchy.
YES
NO
refsetId
SCTID
Identifies the reference set to which this reference set member belongs.
In this case, a subtype descendant of:
NO
NO
referencedComponentId
SCTID
A reference to the SNOMED CT component to be included in the reference set. A reference to the SNOMED CT attribute concept to which the range defined by this member applies.
NO
NO
rangeConstraint
string
A parsable string, which defines the valid set of values that may be used for the given attribute (identified by the referencedComponentId).
If the attribute in the referencedComponentId is a subtype of then the rangeConstraint must be an expression constraint, which can be parsed using the ABNF rules defined by the Expression Constraint Language .
If the attribute in the referencedComponentId is a subtype of then the rangeConstraint must be parsable using the concreteValueReplacement ABNF rule specified in the SNOMED CT Template Syntax. For example, the following rangeConstraint includes the set of all positive integers: int (>#0..)
YES
NO
attributeRule
string
An Expression Constraint that captures the domain, range and cardinality constraints for the given attribute, rule strength and content type.
This string can be parsed using the ABNF syntax defined for the Expression Constraint Language .
If ranges with concrete values are required, the Expression Constraint Language can be extended as described above (for rangeConstraint).
YES
NO
ruleStrengthId
SCTID
A subtype of which specifies whether the given rule is mandatory (resulting in an error) or optional (resulting in a warning).
YES
NO
contentTypeId
SCTID
A subtype of which indicates the type of SNOMED CT content over which this rule applies.
A 128 bit unsigned Integer, uniquely identifying this reference set member.
Different versions of a reference set member share the same id but have different effectiveTime. This allows a reference set member to be modified or made inactive (i.e. removed from the active set) at a specified time.
NO
YES
(Full /Snapshot)
effectiveTime
Time
The inclusive date or time at which this version of the identified reference set member became the current version.
Note: In distribution files the effectiveTime should follow the short ISO date format (YYYYMMDD) and should not include the hours, minutes, seconds or timezone indicator.
The current version of this reference set member at time T is the version with the most recent effectiveTime prior to or equal to time T .
Notes on the tables used to show descriptors and examples
The reference set example tables on this page have been revised as follows to aid clarity and understanding:
The first four columns which are present in all release files are not shown. The omitted columns (id, effectiveTime, active, moduleId) are used in the same way in all referenced sets to support identification, versioning and packaging. They do not directly affect the specific features of a particular reference set or reference set type.
Reference set columns that contain SNOMED CT identifiers are expanded to show details of the concept or description referenced by that identifier. In some cases, the term is shown in the same column using the expression syntax, in other cases an additional column with a name suffix '_term' has been added. In the standard reference set files only the identifier is present in the column and there is no added column for the term. When using reference sets, the term and other details of the component are looked up from the relevant component release files.
The SNOMED CT Machine Readable Concept Model (MRCM) represents the SNOMED CT concept model rules in a form that can be read and tested by a computer. A human readable version of the SNOMED CT concept model can be found in the SNOMED CT Editorial Guide, along with additional guidance for SNOMED CT authors. A computable version of the MRCM is published as a set of reference sets in the SNOMED CT international edition, and can be browsed via the MRCM browser.
This specification defines the format used by SNOMED International's MRCM. This format uses the SNOMED CT Reference Set mechanism to provide a file structure with inbuilt versioning, and the Expression Constraint Language to represent intensional SNOMED CT subsets referred to by the concept model rules. This allows distribution of the MRCM using standard RF2 reference set files and interpretation of the rules using tools that support the SNOMED CT Expression Constraint Language.
This document is a publication of International Health Terminology Standards Development Organisation, trading as SNOMED International. SNOMED International owns and maintains SNOMED CT®.
Any modification of this document (including without limitation the removal or modification of this notice) is prohibited without the express written permission of SNOMED International. This document may be subject to updates. Always use the latest version of this document published by SNOMED International. This can be viewed online and downloaded by following the links on the front page or cover of this document.
SNOMED®, SNOMED CT® and IHTSDO® are registered trademarks of International Health Terminology Standards Development Organisation. SNOMED CT® licensing information is available at
. For more information about SNOMED International and SNOMED International Membership, please refer to
An 723589008 | MRCM domain reference set| enumerates the concept domains to which SNOMED CT attributes may be applied, and provides additional information to support these concept domains.
Each concept domain is uniquely identified by a SNOMED CT concept. When the scope of a domain covers the concepts in a particular hierarchy (or subhierarchy), the supertype concept of this hierarchy (or subhierarchy) is used to identify the domain. When a domain is defined based on membership in a reference set, the associated reference set concept is used to identify the domain. In some situations, a query may be required to define a complex domain. In these cases, the query's expansion reference set (referred to by the 'referencedComponent' of the relevant Query reference set) is used to identify the domain.
For each domain in the SNOMED CT concept model, the 723589008 | MRCM domain reference set| will contain exactly one member. This reference set member will include an Expression Constraint that defines the concepts in the domain, the identifier of the immediate parent domain (or domains), the domain constraint defined in terms of its proximal primitive concepts and associated mandatory refinements, a generic Domain Expression Template for both precoordinated and postcoordinated content, and a reference to the associated guidance that provides additional human-readable text describing this domain. Please note that it is anticipated that the generic Domain Expression Templates will be specialized further for authoring of specific subdomains using specializations stored in a Template Library.
The following metadata hierarchy supports this reference set:
The table below shows the reference set descriptor for a reference set that follows the pattern.
refsetId
referencedComponentId
attributeDescription
attributeType
attribute Order
The table below shows some example rows from a reference set that uses the format of the .
Please note that the generic domain templates defined for the SNOMED CT International Edition are designed to support a proximal primitive parent authoring approach. However, domain templates included in an extension's **** may be designed to support a proximal parent authoring approach if required.
refsetId
referenced Component Id
domain Constraint
parent Domain
proximal Primitive Constraint
proximal Primitive Refinement
domainTemplateForPrecoordination
domainTemplateForPostcoordination
guideURL
effectiveTime
Time
The inclusive date or time at which this version of the identified reference set member became the current version.
Note: In distribution files, the effectiveTime should follow the short ISO date format (YYYYMMDD) and should not include the hours, minutes, seconds or timezone indicator.
The current version of this reference set member at time T is the version with the most recent effectiveTime prior to or equal to time T .
YES
YES
(Full)
Optional (Snapshot)
active
Boolean
The state of the identified reference set member as at the specified effectiveTime .
If active = 1 (true) the reference set member is part of the current version of the set, if active = 0 (false) the reference set member is not part of the current version of the set.
YES
NO
moduleId
SCTID
Identifies the SNOMED CT module that contains this reference set member as at the specified effectiveTime .
The value must be a of within the metadata hierarchy.
YES
NO
refsetId
SCTID
Identifies the reference set to which this reference set member belongs.
In this case, a subtype descendant of:
NO
NO
referencedComponentId
SCTID
A reference to the SNOMED CT component to be included in the reference set.
A reference to the SNOMED CT concept that identifies the relevant concept domain.
NO
NO
domainConstraint
String
An expression constraint, which defines the set of concepts included in the given concept domain.
This string can be parsed using the ABNF syntax defined for the Expression Constraint Language.
YES
NO
parentDomain
String
An expression constraint, which represents the set of immediate parent domains.
An immediate parent domain is a domain that is a proper superset of the given domain, and which is not a proper superset of any other parent domain.
YES
NO
proximalPrimitiveConstraint
String
The domain constraint, as it would be represented for proximal primitive modelling. If the domain concept is sufficiently defined, then its proximal primitive parent will be used instead, while if the domain concept is primitive, then the concept itself is used. Additional constraints on the proximal primitive parent are also included.
The expansion of the given constraint must be further filtered to find those concepts with a definitionStatusId = .
This string can be parsed using the ABNF syntax defined for the Expression Constraint Language.
YES
NO
proximalPrimitiveRefinement
String
The template representation of any additional refinements that are required to model in the given domain using proximal primitive modelling. These mandatory refinements reflect the defining relationships of the domain concept when it is sufficiently defined.
This string can be parsed using the 'refinement' rule in the ABNF syntax defined for the Expression Constraint Language.
YES
NO
domainTemplateForPrecoordination
String
A general template that may be used to author precoordinated content. This template incorporates all of the mandatory attribute domain and range rules rules for precoordinated SNOMED CT content.
This string can be parsed using the Expression Template Language (currently under development).
YES
NO
domainTemplateForPostcoordination
A general template that may be used to author postcoordinated content. This template incorporates all of the mandatory attribute domain and range rules rules for postcoordinated SNOMED CT content.
This string can be parsed using the Expression Template Language (currently under development).
YES
NO
guideURL
URL
A Uniform Resource Locator (URL) that references a web resource in which the given domain is described in further detail.
This URL uses the following pattern: "<conceptId>"
The column entitled PK indicates if the attribute is part of the primary key of this table
Metadata
Reference Set Descriptor and Example Data
Notes on the tables used to show descriptors and examples
The reference set example tables on this page have been revised as follows to aid clarity and understanding:
The first four columns which are present in all release files are not shown. The omitted columns (id, effectiveTime, active, moduleId) are used in the same way in all referenced sets to support identification, versioning and packaging. They do not directly affect the specific features of a particular reference set or reference set type.
Reference set columns that contain SNOMED CT identifiers are expanded to show details of the concept or description referenced by that identifier. In some cases, the term is shown in the same column using the expression syntax, in other cases an additional column with a name suffix '_term' has been added. In the standard reference set files only the identifier is present in the column and there is no added column for the term. When using reference sets, the term and other details of the component are looked up from the relevant component release files.
