09.04.2013 Views

SNOMED CT® Release Format 1 (RF1) Guide - ihtsdo

SNOMED CT® Release Format 1 (RF1) Guide - ihtsdo

SNOMED CT® Release Format 1 (RF1) Guide - ihtsdo

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!