A reference set designed to support representation of Machine Readable Concept Model.
Notes
There are four types of MRCM reference set each of these represents different elements of the Machine Readable Concept Model (MRCM).
MRCM Domain Reference Set enumerates the concept model domains to which attributes may be applied. The set of concepts that are in each domain is represented by an expression constraint.
MRCM Attribute Domain Reference Set associates each concept model attribute with the domains or domains to which it may be applied.
MRCM Attribute Range Reference Set associates each attribute with the valid concept model range for values that can be applied to that attribute. The value range is represented by an expression constraint.
MRCM Module Scope Reference Set specifies the set of MRCM reference sets applicable to content in each module.
components and reference set members, that are part of the same module, share the same moduleId "Reference term: moduleId (field)") value.
components and reference set members are part of only one module , at any given time.
The organization responsible for maintaining an extension must:
create and maintain at least one module identified by a moduleId that it has created;
apply a moduleId that it has created to all components and reference set members in its extension ;
The organization responsible for maintaining an extension may:
create and maintain multiple modules ;
organize its components and reference set members within the modules it manages in a way that best meets its business needs;
Components and reference set members may be moved between modules maintained by different organizations. However, such moves must only be made:
with the consent of the organizations responsible for both the source and target modules; and
in accordance with rules specified by SNOMED International.
Module
manage and distribute information about the dependencies of its modules in accordance with SNOMED CT specifications.
move a component or reference set member between its modules by creating a revised version of that component or reference set member with a different moduleId(It is then part of the new module from the effectiveTime of the revised version).
An advisory body to SNOMED International that optimizes collaboration and coordination amongst Members.
Notes
The Member Forum supports the objectives of SNOMED International by promoting consultation and communication, at an operational level, between SNOMED International and its Members.
The Member Forum :
Facilitates collaboration and cooperation between Members
An indication of whether a release file field value can change between two released versions of the same component or reference set member.
Notes
All released versions of the same component or reference set member have the same id (field), but each version has a different effective time (field).
If a field is mutable (Mutable=YES), its value can differ from one version to the next without changing the identifier.
If a field is immutable (Mutable=NO), its value must be the same in every version of a component. To change the value associated with an immutable field, the existing component must be inactivated and a new component must be created to replace it. The new component must have a previously unused identifier. The field values are set to replace the inactivated concept with the updated information.
The mutability for each field, in each type of release file, is indicated in the release file specification table for that component type or reference set.
A person responsible for creating or editing SNOMED CT concepts, concept definitions, and descriptions.
Alternatives
Author
Editor
Modeler
SNOMED CT editor
SNOMED CT modeler
model of use
An information model designed to align with or meet specific intended purpose.
A model or use may represent information in a way that directly relates to the way data was captured or specific requirements for reporting arising from a particular use case.
In contrast, a model of meaning provides a common representation of particular types of information that supports a range of different uses.
Family history information be recorded in different ways depending on when and how the data was collected. Three of the many possible methods of collection are shown below.
A decision support rule may need to show an alert in patients with a family history of heart disease. An effective model of meaning needs to ensure the required information is accessible to the rules engine irrespective of the way it was originally recorded. The table below shows one way to resolve each of three model of use records into a common form to support effective retrieval.
model of use
Notes
Examples
Method of Collection
Possible Model of Use Record
Checkbox in a questionnaire
"Yes" recorded against the label "Family history of heart disease"
Coded entry in a family history record section
Family history record entry containing: [ 56265001
Coded entry from a picklist or search
Clinical record entry containing: [ 275120007
Model of Use Record
Possible Model of Meaning Resolutions
"Yes" recorded against the label "Family history of heart disease"
Map "Yes" response to questionnaire entry to [ 275120007
Family history record entry containing: [ 56265001
This is an abbreviation for monohierarchical classification.
monohierarchical classification
A hierarchy in which each node is linked to only one parent node.
Notes
Each node in a the hierarchy is linked to the top of the hierarchy by a single path.
Example
The figure below shows a monohierarchy. Each node has one parent so there is only one route from each node to the top of the hierarchy.
For example from node P the path is P→G→C→A.
A representation of the SNOMED CT concept model rules in a form that is processed by software.
Notes
The machine readable concept model supports consistent authoring and validation of SNOMED CT content. It also facilitates effective creation and validation of postcoordinated expressions when using SNOMED CT.
The machine readable concept model uses expression constraint language to represent domains and ranges.
Alternatives
MRCM
Concept model
mca
This is an abbreviation for managed content addition.
An implementation strategy in which additional concepts, descriptions, and relationships are created in an extension.
A managed content addition allows the use of precoordinated expressions to record electronic health information at the required level of detail.
To support data retrieval, the description logic classifier creates an updated inferred view of the terminology.
A terminology binding that represents the clinical meaning of a data item or collection of data items.
Notes
A meaning binding associates a clinical meaning with either a data entry context or a defined collection of data items in an electronic health record information model. The clinical meaning of an instance of a data item with a meaning binding is determined by applying the meaning binding to the value or set of values in that instance.
SNOMED CT meaning bindings should be represented by expression templates containing one or more template slots that can be replaced by concepts entered or stored in a particular context.
Example
An application that manages surgical procedure requests could identify requested procedures using concepts that are subtypes of . In this case, the data item in which that concept is recorded should have a meaning binding that explicitly indicates that this is a request for that procedure. The expression template below represents this meaning binding. It indicates that the procedure selected should replace the "@procedure" template slot, resulting in an expression that means procedure has been requested, rather than suggesting incorrectly, that it has been done.
/* Expression Template */
:
{ = [[ +id < @procedure ]] }
/* Resulting Expression if "38102005 Cholecystectomy (procedure)" is entered */
:
{ = }
mapping reference set
A reference set designed to support the process of mapping data from one code system, classification, or terminology to another code system, classification, or terminology.
There are several types of mapping reference set each of these supports different types of mapping.
Simple Map from SNOMED CT Reference Sets and Simple Map to SNOMED CT Reference Sets support one-to-one maps from or to SNOMED CT.
Complex and Extended Map from SNOMED CT Reference Sets support maps where additional information is required to determine the correct mapping from SNOMED CT to a statistical classification such as ICD-10.
Maps which have a requirement to indicate the degree of correlation between a SNOMED CT concept and other codes. (See Map Reference Sets which use "correlation" within their type / name.)
Code to Expression Reference Sets support maps from other code systems in cases where some or all the source codes may need to be represented by a postcoordinated expression.
An information model that provides a common representation of particular types of information.
Notes
The objective of a model of a meaning is to enable similar types of information collected, stored or communicated in different ways to be integrated for analysis and reuse to support a range of uses.
A model of a meaning requires structural and terminological components that contribute to meaning to be resolved into a common form that minimizes the risk of ambiguity and misinterpretation. Thus a model of meaning can also be thought of as a set of rules for transforming different representations of the same information into one or more forms suitable for analysis and reuse.
In contrast, a model of use refers to a representation of information that meets the requirements of a limited set of use cases.
Family history information be recorded in different ways depending on when and how the data was collected. Three of the many possible methods of collection are shown below.
A decision support rule may need to show an alert in patients with a family history of heart disease. An effective model of meaning needs to ensure the required information is accessible to the rules engine irrespective of the way it was originally recorded. The table below shows one way to resolve each of three model of use records into a common form to support effective retrieval.
monohierarchical classification
monohierarchical classification
A hierarchy in which each node is linked to only one parent node.
Notes
Each node in a the hierarchy is linked to the top of the hierarchy by a single path.
Example
The figure below shows a monohierarchy. Each node has one parent so there is only one route from each node to the top of the hierarchy.
For example from node P the path is P→G→C→A.
An indication of whether a release file field value can change between two released versions of the same component or reference set member.
Notes
All released versions of the same component or reference set member have the same id (field), but each version has a different effective time (field).
If a field is mutable (Mutable=YES), its value can differ from one version to the next without changing the identifier.
If a field is immutable (Mutable=NO), its value must be the same in every version of a component. To change the value associated with an immutable field, the existing component must be inactivated and a new component must be created to replace it. The new component must have a previously unused identifier. The field values are set to replace the inactivated concept with the updated information.
The mutability for each field, in each type of release file, is indicated in the release file specification table for that component type or reference set.
Mutable
mrcm
MRCM
This is an abbreviation for machine readable concept model.
machine readable concept model
A representation of the SNOMED CT concept model rules in a form that is processed by software.
Notes
The machine readable concept model supports consistent authoring and validation of SNOMED CT content. It also facilitates effective creation and validation of postcoordinated expressions when using SNOMED CT.
The machine readable concept model uses expression constraint language to represent domains and ranges.
Alternatives
MRCM
Concept model
mapping
mapping
The process of converting data from one code system, classification, or terminology to another code system, classification, or terminology.
Notes
The mapping process includes the preparation and maintenance of resources used for converting data.
SNOMED CT mapping resources are distributed as mapping reference sets.
Alternatives
Cross mapping
metadata
This is a synonym for SNOMED CT metadata.
SNOMED CT content (including concepts, descriptions, and relationships) that provides additional information about SNOMED content and derivatives (including reference sets).
All SNOMED CT metadata concepts are subtypes of .
The top level of the metadata hierarchy represents broad groups of metadata as follows:
metadata concept
A SNOMED CT concept that is a subtype descendant of the root metadata concept.
All SNOMED CT metadata concepts are subtypes of .
The top level of the metadata hierarchy represents broad groups of metadata as follows:
Top level of the SNOMED CT metadata hierarchy
Method of Collection
Possible Model of Use Record
Checkbox in a questionnaire
"Yes" recorded against the label "Family history of heart disease"
Coded entry in a family history record section
Family history record entry containing: [ 56265001
Coded entry from a picklist or search
Clinical record entry containing: [ 275120007
Model of Use Record
Possible Model of Meaning Resolutions
"Yes" recorded against the label "Family history of heart disease"
Map "Yes" response to questionnaire entry to [ 275120007
Family history record entry containing: [ 56265001
