Skip to end of metadata
Go to start of metadata

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.

Purpose

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. 

Scope

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. 

Audience

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.

Document Overview

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.

Glossary

The following table contains the definition of terms used within this document. Please refer to the SNOMED Glossary for additional definitions.

Term

Definition

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. 1

A structured combination of one or more concept identifiers used to express a clinical idea.

Expression Constraint

 

A computable rule that can be used to define a bounded set of clinical meanings.

Machine Readable Concept Model (MRCM)

 

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. 2

A SNOMED CT file structure consisting of a set of references to SNOMED CT components.

Substrate

The SNOMED CT content over which an expression constraint is evaluated or a query is executed.



Footnotes
Ref Notes
1 Please note that this definition differs from the OWL 2 rdfs:domain axiom, which asserts that "the subjects of such property statements must belong to the class extension of the indicated class description".
2 Please note that this definition differs from the OWL 2 rdfs:range axiom, which asserts that "the values of this property must belong to the class extension of the class description or to data values in the specified data range.".
 


Feedback