SNOMED CT® Release Format 1 (RF1) Guide - ihtsdo
SNOMED CT® Release Format 1 (RF1) Guide - ihtsdo
SNOMED CT® Release Format 1 (RF1) Guide - ihtsdo
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Consistent representation is a prerequisite for effective retrieval and reuse of clinical record information.<br />
Requirements for reuse are many and varied, ranging from direct support for the care of the individual patient,<br />
through to aggregate analysis for research, statistics and audit. The common theme of these requirements<br />
is the need to retrieve particular items of information reliably and consistently, irrespective of the environment<br />
in which the data was entered and stored.<br />
Since both the information model and <strong>SNOMED</strong> CT contribute to the processable meaning of an entry in a<br />
clinical record it is essential to manage the interdependencies between these two components.<br />
Simple requirements can be addressed by specifying a value-set consisting of the permitted coded values<br />
that can be used in a particular field. However, effective representation of clinical records requires a rich<br />
information model and an expressive terminology.<br />
Models such as EN13606 and the HL7 RIM provide the necessary structural flexibility and <strong>SNOMED</strong> CT<br />
post-coordinated expressions provide expressivity. An inevitable side-effect of a richer approach to information<br />
representation is an increase in the interdependencies and overlaps between the information model and the<br />
terminology. In order to specify and validate consistent representation of meaningful clinical records, constraints<br />
must be applied to both the information model and terminology. These constraints must address all the facets<br />
of the model and terminology (e.g. including the use of post-coordination and the effect of modeled record<br />
structures). The constraints on information model and terminology components must be integrated, or bound<br />
together, in ways that ensure consistency, avoid ambiguity and minimize the number of different ways in<br />
which the same meaning may be expressed.<br />
A terminology binding is an instance of a link between a terminology component and an information model<br />
artifact . Therefore, the document considers the representation of the required terminology components and<br />
the way these are associated with relevant information model artifacts .<br />
The information model artifact to which a terminology binding is applied may be a field of a class in a static<br />
model or a collection of fields of one or more related classes.<br />
Bound components include:<br />
• Information model artifacts :<br />
• Coded attributes in an HL7 Version 3 model, an EN13606 Archetype or in the proprietary information<br />
model of an operational application.<br />
• Terminology components:<br />
• Constraints on <strong>SNOMED</strong> CT expressions.<br />
2.1.4.4. Expression Constraints<br />
Structure and Content <strong>Guide</strong> | 25<br />
<strong>SNOMED</strong> CT contains hundreds of thousands of Concepts and this rich resource is greatly expanded by use<br />
of post-coordinated expressions. In any given situation the range of Concepts or expressions that are useful,<br />
relevant and meaningful is much more limited. This gives rise to a requirement to represent constraints on<br />
the content or a particular field in a way that can be interpreted and applied by application software.<br />
The simplest constraint requirements can be met by specifying the list of valid codes. This requirement is<br />
addressed by subsets specified using the Reference Set mechanism. In some cases, it is useful to express<br />
the range of possible values 'intensionally' by specifying rules rather than by listing every member of the set<br />
(e.g. to include all concepts that are subtypes of a specified concept).<br />
The use of post-coordinated expressions adds further dimensions to the requirement for constraints. It may<br />
be necessary to specify whether all post-coordinated refinements of concept are permitted or whether some<br />
types of refinement are prohibited or required. It may also be necessary to specify whether a post-coordinated<br />
expression that is equivalent to a permitted value is itself permitted.<br />
Requirements for representing expression constraints are closely related to the requirements for representing<br />
query predicates in queries.<br />
© 2002-2012 International Health Terminology Standards Development Organisation CVR #: 30363434